add an else if

[larryllix]

You did that backwards. The old program "if" would move to the new program "when". The "when" things would be triggers and conditions and work exactly the same as the current "if". No need to change anything if you don't want to. All programs would run exactly the same with no changes needed. In fact, if it were me, I would only use the new section on new programs. There is no reason to change programs that already work as intended even if it means getting rid of a couple.

 

If you have a firmware update that renders a bunch of programs non-functional, you are going to really really annoy a lot of people.

 

It would be a little like Elk. In an Elk rule, the first condition is also a trigger, all subsequent conditions are only tested if the first condition occurred. The only difference is that in ISY we get the option of having multiple "first lines"

 

That may work. Having a tested condition in the "Triggers/When" section may not interfere with anything in logic except for the extra processing it may take. Minor issue. Now when a user wants to upgrade or separate his triggers conditionals without complicating the issue with more unwanted triggers he can either toggle the "If/conditionals" enable box and enter straight conditions into it or leave it alone and functioning as in past firmware revisions.

 

The only trouble I can foresee with that is that the "Triggers/when" section contains code that determines whether "then" or "else" gets executed so when the "if/conditionals" enable checkbox is toggled the internal processing of the "triggers/when" section would have to change logic and not decide that passing the decision on to the "If/conditionals" section. It would probably be too much clean-up to be able to toggle the option in the middle of already written user code.

 

Although the learning curve going to separate and non-overlapping sections would be much smaller than learning user programming with combined triggers and conditionals, there is always the option to leave past user programming style alone and never update firmware revisions if that style is desired. Think of the forum questions then! They would be mostly one sided and confusing!

[Goose66]

I addressed this in the old thread, but it seems to me what would be appropriate is to pull the trigger events that trigger programs today (a determination that is already being done by the ISY) and simply move them to the "When" section, leaving everything else in the If. This could be done by the firmware upgrade process.

 

So for example:

 

If Status X = On

 

would become:

 

When Status X Changes

If Status X = On

 

and

 

If Device X Command On received

 

would become

 

When Device X Command On received

If <-no conditions->

 

and

 

If DrivewayMotion is switched On AND Time between Sunset and Sunrise AND Variable VacationState = 1

 

would become

 

When DrivewayMotion is switched On OR Time is Sunset OR Time is Sunrise OR Variable VacationState changes

IF Time between Sunset and Sunrise AND Variable VacationState = 1

 

In the latter case, the user would have to cleanup the program to get the benefit of the change, but in the interim it would work as expected.

[larryllix]

If DrivewayMotion is switched On AND Time between Sunset and Sunrise AND Variable VacationState = 1

 

would become

 

When DrivewayMotion is switched On OR Time is Sunset OR Time is Sunrise OR Variable VacationState changes

IF Time between Sunset and Sunrise AND Variable VacationState = 1

 

In the latter case, the user would have to cleanup the program to get the benefit of the change, but in the interim it would work as expected.

 

apostolakisl is concerned about porting the user programs over to the new firmware version without any maintenance or rewriting. I don't feel that is an issue for me based on two things.

- my user programmes are only a week old

- most users of the ISY are hobbyists and love the challenge (for a while)

 

I don't see the final example being automatically portable to a new revision. The ANDs have to become al ORs. Perhaps you were considering and including the style select enable in your example?

 

Anybody's brain sore yet?

[Goose66]

Conversion of the ands to ors would not be an issue, because all trigger events would inherently have ors between them. In other words, you would trigger the program on any of the listed events occurring. As I mentioned before, determining the trigger events from the if conditions is already something that the ISY is doing. The remainder of the if conditions would remain exactly the same, ands and ors notwithstanding. As far as my brain hurting, not at all, because this is just the natural way this should work, IMO.

[LeeG]

There are thousands of ISY users with Programs that must continue to run as is. Every day users type new Programs from other user input with no idea why the Programs are written as they are. These cannot be broken. It is fine to discuss ideas in the theoretical, new program sections, new rules that make it easier to understand (will it ?), reverse the direction of the earths rotation. The more these new things involve changing the very basics of the existing ISY world the lower the probability they would ever be implemented. I feel certain a large part of the existing ISY world does not look at their environment as a hobby.

 

Thinking outside the box is fine but the end result has to apply to the real ISY world.

[Goose66]

Well, I believe this accomplished exactly as described above. Nothing would change for those that don't change their programs. The logic to convert from old format to new is trivial and is basically being done today inside the ISY. This is not "out of the box" or. "Pie in the sky " as you suggest, but very doable in the real world. Now going to a true scripting engine--that is out of the box thinking.

[kck]

I think what is being said by kingwr but missed is that the user would not need to do anything for his old programs to work. They would simply appear different after the upgrade. This is rather like the 100% vs "On" thing (though more complex) where old programs look different but still do the same thing. Since the semantics of existing programs are fully known, post an upgrade they human readable form of those programs would simply appear a bit different. From what I can tell, by the way, (Michel could say for sure) programs are stored, once entered, in an internal code form and not in the form you typed them. They then appear to be regenerated in human readable form when you open them later. I say this because of what happens to things like variable names and the like if you delete them. So this reverse parsing to create a human readable from would match very closely with what you would need to make this trigger/condition separation change anyway.

[LeeG]

There are four pages thus far with a few what I consider “out of the box†from page 4. The idea that users would not be able to upgrade to the latest firmware to gain new device support without learning a new Programming; the idea that there will be “casualties of upgrading†with these new Program concepts.

 

“there is always the option to leave past user programming style alone and never update firmware revisions if that style is desired.â€

 

“I don't know if that would be avoidable in a major upgrade. Casualties of upgrading? Would we perpetuate lack of progress in that endevour? Probably not.â€

 

Putting forth these ideas is fine to create talking points but the thought that existing users will be frozen at current device support levels or users will be casualties is well out of the box in my view.

[larryllix]

I feel certain a large part of the existing ISY world does not look at their environment as a hobby.

...but the thought that existing users will be frozen at current device support levels or users will be casualties is well out of the box in my view.

We do not need to discuss the whole ISY world, only the users that want to get the latest and greatest. The systems that are updated every beta version that comes out are typically hobbyists and initial system installers. I doubt that many serious applications are being run on an RF communication system or Insteon quality modules.

 

Commercial and industrial control systems, are not likely to be upgraded every few months, or ever for that matter. Control systems would typically be designed to do a job and then left alone. Industry cannot afford to pay to play with software and experiment once the product is functioning satisfactorily.

 

I wasn't here for the IY99i or revision 1.0 of the firmware. Anybody know if those programs will still run on v4.1.2? I am told that the Wiki had to have so many programmes stripped out due to obsolescence.

What happens if the 2413S gets discontinued in this USB port world?

It's too bad ISY99 users cannot upgrade past v3 but we can't totally stagnate because a user's stuff won't run without some work if he wants to change his whole system.

 

You can't have it both ways. If you want the latest and greatest, it's gonna' cost you.

Hobbyists want improvements. It's gonna' cost us.

[LeeG]

The are no user Program changes required moving from a 99i to a 994i.

[apostolakisl]

There is just no way you could change the ISY firmware and have it "break" already functioning programs. I know you could say "well just don't update" but then those people would get none of the other upgrades either. So then you could really get confusing and start two separate lines of upgrades, one with the old and one with the new, but that is just crazy. Many ISY users are perfectly happy after having copied a few programs off the forum and wiki and would be lost if this happened.

 

Like I said, just move the "if" to "when" and have "when" work just the same as the current "if"

 

Add a new "if" section that are conditions which don't trigger and the whole thing is solved. You don't need to change any of the coding language or anything. The "when" section would be connected to the new "if" section by an an "and" . . . which is why I like to call it "and If the following conditions are met".

 

It would also perhaps be simpler to just put a check box next to each line of code that activates/deactivates it as a triggerable condition.

[larryllix]

Like I said, just move the "if" to "when" and have "when" work just the same as the current "if"

 

Add a new "if" section that are conditions which don't trigger and the whole thing is solved. You don't need to change any of the coding language or anything. The "when" section would be connected to the new "if" section by an an "and" . . . which is why I like to call it "and If the following conditions are met".

 

It would also perhaps be simpler to just put a check box next to each line of code that activates/deactivates it as a triggerable condition.

 

The checkbox sounds most feasible, cleaner, better option control, keeps the most familiar GUI, and easier to port existing code over.

 

My guess is whichever way UDI implements this almost everybody is going to rewrite their programmes, anyway, to disable the triggers they didn't want in the first place. I think the user code portability is not as big as being promoted.

 

I was looking through the backup files and it wouldn't be too hard for a "recompiler" programme to rearrange the file contents based on a given set of rules that understand how each new section would work. Option boxes in the "recompiler" could give some user options of how the user wants certain trigger devices handled. eg. all "To" times will not cause triggers. The recompiled backup file would then be reloaded into the updated ISY version. This may be another possibility for bigger concept changes that don't support old user code so smoothly.

 

Interesting stuff!

[Goose66]

The problem with the checkbox idea is, while it provides the desired functionality, it doesn't clear up the difference between what triggers a program and what the if condition is. For example, 'If Time is between Sunset and Sunrise," if I check the checkbox, does the program run at Sunset, Sunrise, or both? (I know the answer, I am just saying it's not clear). Similarly, 'If Status of Device X is On' with the checkbox checked, does the program run only when Device X is turned on or anytime the status of device X changes?

 

The proposed "When" or "Triggers" section makes this distinction clear while not really departing from how the ISY works today. It's just showing the distinction in the UI instead of it being inherent in the way that it works. The only downside I see is the redundancy in the programming for status conditions, e.g. you have to add 'Status of Device X Changes' to the "When" section AND 'If Status of Device X is On' to the "If" section. A minimal inconvenience, IMO.

[kck]

Neither the "when/if" proposal nor the trigger dropdown proposal requires any user changes to any existing programs. So I think the real decision criteria should be the human factors one. On that front personally I think I favor the when/if syntax because it makes it very clear to a user what the events causing things to happen are. Trigger boxes do that but is a less clear manner since they are scattered within other conditions and the leave unclear questions like the schedule one raised above (and by the way - do schedule to/froms get 2 trigger boxes? After all it isn't required that both times be triggers.) Overall, I think folks should strive to make where you go with the syntax as consistent a base as possible for whatever ongoing future changes may occur. Accreting "properties" alongside conditions just seems to me to be asking for a long term confusing situation. Nevertheless, I could live with either approach but I would certainly like some way to separate trigger conditions from normal conditionals.

[larryllix]

The problem with the checkbox idea is, while it provides the desired functionality, it doesn't clear up the difference between what triggers a program and what the if condition is. For example, 'If Time is between Sunset and Sunrise," if I check the checkbox, does the program run at Sunset, Sunrise, or both? (I know the answer, I am just saying it's not clear). Similarly, 'If Status of Device X is On' with the checkbox checked, does the program run only when Device X is turned on or anytime the status of device X changes?

 

The proposed "When" or "Triggers" section makes this distinction clear while not really departing from how the ISY works today. It's just showing the distinction in the UI instead of it being inherent in the way that it works. The only downside I see is the redundancy in the programming for status conditions, e.g. you have to add 'Status of Device X Changes' to the "When" section AND 'If Status of Device X is On' to the "If" section. A minimal inconvenience, IMO.

I would think two checkboxes would be needed for the from-to time construct. My position is to scrap the whole compatibility thing and start fresh.

 

"ElseIf" has to be giving the designers a run for their money and may be the major driving force in separating the triggers out of the conditionals.

 

Who knows? A new ISY995i may be on the horizon with much of this ironed out. With a couple of USB ports and more expansion room for modules, a 9v battery clip for battery carryover, a mic/speaker for support of the voice command module and voice/alarm reports, actual webpage server with no Java usage, and BNC for antennae, the hobbyist home control freaks will drop the old system without a blink.

[apostolakisl]

The advantages to checkbox are 2:

 

1) The checkboxes could show up in a new firmware version and be totally ignored by a user who doesn't care to use them and they break no programs that currently work.

2) You can still keep all of your parentheses and various and/or combinations allowing the trigger clauses of a program to show up in any order.

 

I can't think of any other way to do it that satisfies those 2 conditions.

[larryllix]

The advantages to checkbox are 2:

 

1) The checkboxes could show up in a new firmware version and be totally ignored by a user who doesn't care to use them and they break no programs that currently work.

2) You can still keep all of your parentheses and various and/or combinations allowing the trigger clauses of a program to show up in any order.

 

I can't think of any other way to do it that satisfies those 2 conditions.

I liked the checkbox idea but I don't think we would even need a checkbox to satisfy everybody.

 

A new GUI firmware update could just relabel the "If" section to "If/Triggers" and absorb all existing code.

 

Then a new section labelled "Conditions" could contain conditional/without trigger lines. This would keep old programmes finding a section labelled similarly, in an identifiable way, to newbies and ambitious users could adapt their programmes to eliminate unwanted triggers. Should satisfy most of the arguments put forth here.

If / Triggers                                  '* same old section and compatible logic
              Motion is switched to On 
         AND                                  '* OR logic for triggers, AND logic for conditions
              more_old_trigger _lines                   


Conditions   (AND)                             '* no trigger conditional section      
              From    Sunset
              To     Sunrise

Then
              Set night_lights On
              Wait, etc...

Else
              Notify My text "People are on my new seeded lawn" 

Maybe this was being promoted previously and the night_light just ramped on to 85%!

[kck]

That is essentially the when/if proposal just with different (and probably not as clear) labeling. It isn't quite enough though since, e.g., in the case of time intervals many are both triggers and conditions and the implication of the trigger section is that these only describe actual events that trigger execution. So a time interval in the trigger section is actually equivalent to "at starting time" or "at ending time" whereas in the conditional section it is a truth test. So if there is currently code that looks like:

 

if

switch is on

and

from t1 to t2

then

 

the new code would need to be something like

 

trigger

switch status changes

or at t1

or at t2

 

condition

from t1 to t2

and switch is on

. . .

 

 

This can all be converted automatically in an upgrade because the semantic are all there now - just combined. That is to say, the code today actually does what the new code says.

[larryllix]

 

 

That is essentially the when/if proposal just with different (and probably not as clear) labeling. It isn't quite enough though since, e.g., in the case of time intervals many are both triggers and conditions and the implication of the trigger section is that these only describe actual events that trigger execution. So a time interval in the trigger section is actually equivalent to "at starting time" or "at ending time" whereas in the conditional section it is a truth test. So if there is currently code that looks like:

I totally agree with you and I also like the looks of what you gave as a sample, but others are complaining it would confuse old code users and trying to hang on to the current style. That is why I was hypothesising the "If/Trigger" section as remaining the same logic parameters (programme level compatible) and looking familiar, but still give the options for newbies and ambitious ones to isolate the triggers from the conditions in a newer programming style.

[apostolakisl]

The advantages to checkbox are 2:

 

1) The checkboxes could show up in a new firmware version and be totally ignored by a user who doesn't care to use them and they break no programs that currently work.

2) You can still keep all of your parentheses and various and/or combinations allowing the trigger clauses of a program to show up in any order.

 

I can't think of any other way to do it that satisfies those 2 conditions.

I liked the checkbox idea but I don't think we would even need a checkbox to satisfy everybody.

 

A new GUI firmware update could just relabel the "If" section to "If/Triggers" and absorb all existing code.

 

Then a new section labelled "Conditions" could contain conditional/without trigger lines. This would keep old programmes finding a section labelled similarly, in an identifiable way, to newbies and ambitious users could adapt their programmes to eliminate unwanted triggers. Should satisfy most of the arguments put forth here.

If / Triggers                                  '* same old section and compatible logic
              Motion is switched to On 
         AND                                  '* OR logic for triggers, AND logic for conditions
              more_old_trigger _lines                   


Conditions   (AND)                             '* no trigger conditional section      
              From    Sunset
              To     Sunrise

Then
              Set night_lights On
              Wait, etc...

Else
              Notify My text "People are on my new seeded lawn" 

Maybe this was being promoted previously and the night_light just ramped on to 85%!

 

Yes, as mentioned this is the same thing as the "when"/"and the following conditions are met" scheme I had mentioned earlier. It works, but has the shortcoming of losing the ability to run parenthesis or use "or" statements between the first section and second section.

 

The other thing I suggested in a thread a while back is to just add 2 new conditions. One would be time parameters that are not triggers, and the other would be to add status parameters that aren't triggers. That would pretty much take care of 99% of all your unwanted triggers. Similar in concept to state and integer variables.

[Goose66]

The other thing I suggested in a thread a while back is to just add 2 new conditions. One would be time parameters that are not triggers, and the other would be to add status parameters that aren't triggers.

 

I missed this suggestion before, but this is not a bad solution. I still think separating the trigger events from the if conditions is more intuitive and more powerful, but this solution may be simple to implement and make the else clause far more useful. I would certainly rather have this than nothing.

[larryllix]

The other thing I suggested in a thread a while back is to just add 2 new conditions. One would be time parameters that are not triggers, and the other would be to add status parameters that aren't triggers.

 

I missed this suggestion before, but this is not a bad solution. I still think separating the trigger events from the if conditions is more intuitive and more powerful, but this solution may be simple to implement and make the else clause far more useful. I would certainly rather have this than nothing.

Not bad.

 

OTOH, agreeing with your separation idea, the GUI and language may be painting itself into a corner, only making the eventual jump to a cleaner, more intuitive language harder for users upgrading, with each work-around supporting the original language quirks.

[gduprey]

So having recently (very recently) started working on my ISY994, I've run into this already.  In my case, I have a home/away variable and a guests/no-guests variable and the combination of them is used to select and execute an appropriate insteon scene.  It's ugly and difficult to edit as the logic for once "conceptual" program is split over 4 programs.  I have 8 of these, so am working with a mess of 32.  No amount of naming and folders makes this easy to maintain (though both obviously do help).

 

I'm very keen on compatibility with previous versions.  While I may not have much code now, if there is a "just re-write it" mentality about, I would already be fearing for the future, disabling automatic updates, etc, etc.

 

I do think there is a solution here that is both 100% compatible with existing code and provides some flexibility that would address at least many of the cases above (but not all).  That would be allowing nested IF/THEN/ELSE blocks.  

 

1) They are new and do not change any meaning of anything already in place.  You do not need to change existing code or use them.

 

2) They'd come with an obvious caveat - event checking only applies to the top-most IF statement.  That means the ISY isn't digging down multiple levels to see if the IF should execute.  Top level basically becomes the WHEN/ON block people have mentioned (but that is a conceptual thing -- actual code doesn't change a bit).

 

3) Ideally, there would be a few levels of nested IF/THEN/ELSE logic supported.  While I like unlimited, realistically, the ISY is unlikely to have resources for that.  5-8 levels would seem like a "solves 99%" solution.

 

4) As such, all 'inner' IF/THEN/ELSE would only be able to test status of devices, variables, etc - static items (vs events/changes).

 

For example:

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

(the "EndIf" or maybe just "End" would be used only for nested IF/THEN/ELSE)

 

I recognize things like this are not easy and as a solution, it's doesn't address 100% of what folks are asking for, but again, it seems like something that can solve 80+% of the needs for more complex logic with no negative impact on existing code.

 

Thoughts?

 

Gerry

P.S. Looking over the thread again, I see variations on this same theme, so not suggesting something ground breaking here.  Just my thinking plus looking over what folks are writing and keeping backward compatibility in the fore-front.

[larryllix]

So having recently (very recently) started working on my ISY994, I've run into this already.  In my case, I have a home/away variable and a guests/no-guests variable and the combination of them is used to select and execute an appropriate insteon scene.  It's ugly and difficult to edit as the logic for once "conceptual" program is split over 4 programs.  I have 8 of these, so am working with a mess of 32.  No amount of naming and folders makes this easy to maintain (though both obviously do help).

 

I'm very keen on compatibility with previous versions.  While I may not have much code now, if there is a "just re-write it" mentality about, I would already be fearing for the future, disabling automatic updates, etc, etc.

 

I do think there is a solution here that is both 100% compatible with existing code and provides some flexibility that would address at least many of the cases above (but not all).  That would be allowing nested IF/THEN/ELSE blocks.  

 

1) They are new and do not change any meaning of anything already in place.  You do not need to change existing code or use them.

 

2) They'd come with an obvious caveat - event checking only applies to the top-most IF statement.  That means the ISY isn't digging down multiple levels to see if the IF should execute.  Top level basically becomes the WHEN/ON block people have mentioned (but that is a conceptual thing -- actual code doesn't change a bit).

 

3) Ideally, there would be a few levels of nested IF/THEN/ELSE logic supported.  While I like unlimited, realistically, the ISY is unlikely to have resources for that.  5-8 levels would seem like a "solves 99%" solution.

 

4) As such, all 'inner' IF/THEN/ELSE would only be able to test status of devices, variables, etc - static items (vs events/changes).

 

For example:

(the "EndIf" or maybe just "End" would be used only for nested IF/THEN/ELSE)

 

I recognize things like this are not easy and as a solution, it's doesn't address 100% of what folks are asking for, but again, it seems like something that can solve 80+% of the needs for more complex logic with no negative impact on existing code.

 

Thoughts?

 

Gerry

P.S. Looking over the thread again, I see variations on this same theme, so not suggesting something ground breaking here.  Just my thinking plus looking over what folks are writing and keeping backward compatibility in the fore-front.

This sounds like the best solution so far. I Iike it for all concerns involved.

 

This unwanted trigger problem has been resolved in inconsistent ways in different places.

- in programs by using more programs with an enable/disable checkbox  controllable from obscure places to the code reader. 

- in programs by disabling residing folders, fairly obscure

- in variables by having two different categories (State and Integer). Adding "string" we will have variable types and categories.

 

This technique could eliminate the need of usage of the above techniques in a fairly consistent and easily programmer discernible method. It also fits the "typical" look of other language styles offering more comfort to programmers.

 

I doubt the ISY has to dig down during execution. I believe the triggers are installed in a table attached to each virtual device at compile time. The "digging down" would only be at entry and not complicate or slow down execution.

 

If UDI is installing "elseif" constructs I don't know how else they could accomplish it and this style would certainly seem to resolve the unwanted trigger problem, the confusion of two different types of variables,  and the "elseif" construct addition in one swoop.

 

+1

[apostolakisl]

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.  

 

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.