add an else if

[rrathke]

What you are talking about is essentially a change in the programming interface experience, not so much a change in capabilities since nested "if" already exists, just in a different format.

If
   whatever
Then
   run if program 2
Else
   run if program 3

There is essentially unlimited nesting in this fashion.  Being able to see all of your flow on the screen at once is the advantage to nesting as you displayed.  Organizing is very nice in ISY with folders and all the programs have a note section to remind you of what is up which does alleviate the issue.

 

If ISY just had an program export display application much of the display issues would be taken care of.   You can already export the programs, all you need is a program to read the exported file and display them consecutively for ease of viewing.

 

Also, the program you wrote:

If
  Control 'Kitchen Island' is switched Fast On
Then
  If
    $Guests_Flag is 0
  Then
    Set Scene 'Lighting Scenes / Kitchen Lights' On
  Else
    Set Scene 'Lighting Scenes / Guests In Kitchen' On
  EndIf
Else
  - No Actions

could be written in ISY's current construct as a single program

If
    Control 'Kitchen Island' is switched Fast On
    and $Guests_Flag is 0 (where this is an int variable)
Then
    Set Scene 'Lighting Scenes / Kitchen Lights' On
Else
    Set Scene 'Lighting Scenes / Guests In Kitchen' On

Seeing as how all these things can be done as is with ISY and only marginally easier (and that is subject to opinion), I would much rather see UD developers work on other features that don't exist at all.  

I agree, it may be nice to have but certainly much lower priority than keeping functionality/devices current.

[gduprey]

My example was super simplified to keep it short and convey the concept succinctly.   In my actual case, it would be at least two levels deep.  

 

And as I mentioned, I am doing it now using programs, but it's incredibly messy, even with folders and using naming conventions to show relations.   In my case, each "scene" actually delegates to one of 4 possible scenes (home/normal, home/guests, away/normal, away/guests).  So I have 3 programs per scene and I'm up to 9 scenes making 27 programs just to make this all work.  

 

You have to be forever jumping around between programs to see what each one has and it's a pain.  And it's error prone.

 

I agree that in a way, this is "syntatic sugar" - adding code for humans sake when the basic ability, no matter how difficult, is already possible.

 

I'm a software developer (low level stuff -- assembly and C) and one indisputable fact I've found is the harder it is to see your logic as one related piece, the harder it is to produce error free logic and/or to debug it.  That ability to understand the entire program on a single screen and edit it has tremendous value to both authoring logic, getting it right the first time and understanding it again later, 6+months down the road when it's no longer all in your head.

 

If making the logic more understandable wasn't a priority, even the current ISY logic/programs wouldn't need to look like they do.  You could simply have event tables, bit patterns and links to things like scenes and get the same result.  But it would be difficult to understand, difficult to conceptualize and incredibly difficult to debug and modify. 

 

Presentation is a huge part of usability in any system.  Burying logic in a dozen little pieces, even organized into folders, works against this in all but the simplest use cases.

 

Within reason, anything you can do to make logic more understandable and less opaque is worth it when considering human time and energy expended in the process.

 

Gerry

 

P.S. 'Within Reason' is important.  You cannot break compatibility with existing code and you have to keep in mind the resource limits of the environment the ISY O/S works in.  Both of which my suggestion attempts to take into account

[gduprey]

EDIT: Keep in mind that the program you wrote above is probably not a very good program.  I am just assuming that a switch in the kitchen that turns the kitchen lights on would be one that you want an "instant" response to.  Using a program to turn lights on always introduces a significant delay which would probably be quite annoying.  You would probably be better off programming your ISY to reprogram the switches whenever your guest variable is initiated.

 

I'm still getting use to some of the powers of the ISY and Insteon and agree your idea of reprogramming as environment changes is a very interesting concept and capability!

 

That said, I like having once place to look at the scenes to edit/add/drop lights in the scene editors.  But for other uses, I can absolutely see that.

 

Gerry

[apostolakisl]

 

You have to be forever jumping around between programs to see what each one has and it's a pain.  And it's error prone.

 

 

Presentation is a huge part of usability in any system.  Burying logic in a dozen little pieces, even organized into folders, works against this in all but the simplest use cases.

 

Within reason, anything you can do to make logic more understandable and less opaque is worth it when considering human time and energy expended in the process.

 

Gerry

 

P.S. 'Within Reason' is important.  You cannot break compatibility with existing code and you have to keep in mind the resource limits of the environment the ISY O/S works in.  Both of which my suggestion attempts to take into account

 

I do agree.  Frankly, I don't really like the Java interface at all for programming.  I understand how it is good for real time control of the ISY, but writing programs doesn't require being live on the unit.  

 

I would much rather have a locally running editor with options on how to display things.  Multiple programs per screen and stuff like that, faster menus, all that kind of thing.  I sometimes feel like I am working in quick sand when I am writing any significant programs.

 

Nested programs can get quite confusing to follow as well.  It is kind of like using parentheses in the "if" section.  You have to carefully follow your indents.  In this respect, it is easier to follow if one program calls another, provided you can display those programs simultaneous.

[apostolakisl]

I'm still getting use to some of the powers of the ISY and Insteon and agree your idea of reprogramming as environment changes is a very interesting concept and capability!

 

That said, I like having once place to look at the scenes to edit/add/drop lights in the scene editors.  But for other uses, I can absolutely see that.

 

Gerry

 

When you want a light switch to control a scene differently at different times, it is usually best to use the "adjust scene" command.  For example, when visitors arrive, you might turn a KPL button on.  Turning the KPL button triggers a program which runs an "adjust scene" on all the scenes you want changed.  This means that when you go to use those scenes, they run "instant" . . . which is where "Insteon" got its name.  When you turn the KPL off, it triggers  a program that adjustst the scenes back.  In your situation, you would need only 4 programs where each one writes all the scenes to each of your 4 situations.  Insteon switches memory can be re-written a huge number of times before it starts to fail, so no worries there . . . .your Insteon setup will probably be long time obsolete or otherwise broken before the memory re-writes screw it up.

[larryllix]

When you want a light switch to control a scene differently at different times, it is usually best to use the "adjust scene" command.  For example, when visitors arrive, you might turn a KPL button on.  Turning the KPL button triggers a program which runs an "adjust scene" on all the scenes you want changed.  This means that when you go to use those scenes, they run "instant" . . . which is where "Insteon" got its name.  When you turn the KPL off, it triggers  a program that adjustst the scenes back.  In your situation, you would need only 4 programs where each one writes all the scenes to each of your 4 situations.  Insteon switches memory can be re-written a huge number of times before it starts to fail, so no worries there . . . .your Insteon setup will probably be long time obsolete or otherwise broken before the memory re-writes screw it up.

It took me quite a took of experimenting to figure all that out. I use quite a few X10 motion sensors in my system and by the time they get translated to powerline, received in the ISY, decided what brilliance to get, sent out and respond to it I was sometimes out of the room already.

 

With Insteon modules, at least at one end, some of that time is cut off but the real advantage is when I have an Insteon MS I  preset the lighting scene to the desired response, on a side program based on sunset and clock times. This is especially important in the bedrooms, where I have 100W equiv. LED bulbs in night table lamps, and if they ever come on full in the middle of the night I will have to get some suntan lotion for our eyeballs. The response time is much better as Apostolokisl posted.

[Michel Kohanim]

Hello everyone,

 

Invaluable input! Thanks so very much to all. I especially like the program editor idea. #153 Low.

 

With kind regards,

Michel

[ravedog]

What would be awesome is a flow chart/state machine diagramming app that could convert the graphic into code. Swoon!!!! Of course it would probably be only windows :/

 

 

Sent from my iPad using Tapatalk

[larryllix]

What would be awesome is a flow chart/state machine diagramming app that could convert the graphic into code. Swoon!!!! Of course it would probably be only windows :/

 

 

Sent from my iPad using Tapatalk

We would need t know the format of the backup file and some ambitious coder could develop this and the code could be pulled in as a backup file. I don't know any other way ISY could take drag 'n drop code into it.

[Jimbo.Automates]

Yes a GUI would be cool, but a nice editor would be awesome. Support for extensions like subroutines would really simplify things a lot. Oh, and as long as we are wishing, a simulator to run an ISY and show and set device status would be amazing.

 

Sent from my Nexus 7 using Tapatalk

[ravedog]

Yes a GUI would be cool, but a nice editor would be awesome. Support for extensions like subroutines would really simplify things a lot. Oh, and as long as we are wishing, a simulator to run an ISY and show and set device status would be amazing.

 

Sent from my Nexus 7 using Tapatalk

the Mac side, BBEdit is an awesome code editor for a huge list of supported code:

Direct integration with Mac OS X native Perl environment, as well as Python, Ruby, and unix shell scripts. Also web development as well. And a lot of third party modules as well. Just my 2¢

 

 

 

 

Sent from my iPad using Tapatalk

Yes a GUI would be cool, but a nice editor would be awesome. Support for extensions like subroutines would really simplify things a lot. Oh, and as long as we are wishing, a simulator to run an ISY and show and set device status would be amazing.

 

Sent from my Nexus 7 using Tapatalk

 

On the Mac side, BBEdit is an awesome code editor for a huge list of supported code:

Direct integration with Mac OS X native Perl environment, as well as Python, Ruby, and unix shell scripts. Also web development as well. And a lot of third party modules as well. Just my 2¢

 

 

 

 

Sent from my iPad using Tapatalk

[ravedog]

Just got to thinking. In FileMaker Pro, for linking tables, one of the displays will show you each table with the field links to other tables and their relationships. What if the ISY interface would allow for a GUI representation of each program with their links between. So you could follow the flow of a group of programs when troubleshooting. Just trying to think of ways to get more than one program up on cap screen at a time so you can troubleshoot and develop.

 

 

Sent from my iPad using Tapatalk