Support for lists in programs

[JacquesB]

Hi,

 

A way to reduce traffic on the Insteon network would also be a very useful function for a new kind of programs : the use of lists. As a first step, scenes could be used as lists.

 

Ex:

 

For Device In "Scene A"
Do
[ If Device is On
Then
Set Device Off
Run program ABC (Then part)
Else

]
Run program "Check done" (If part)
Done

 

Here, only Scene A is a parameter configured by the user. "Device" (or node or any other name you wish...) is an internal variable used by the ISY. It is set to the address of the first device in the scene before processing the IF. Once done, "Device" is incremented to the second address listed in the scene and the IF is re-processed. When the list is over, a last list of action is available for any other thing to do.

 

Should the list create an impossible test, like an On Level of 50% on an OutletLinc, the result is just automatically "false". For impossible actions, like setting an OutletLinc to 50%, the ISY should just skip the impossible action and go to the next line (not next device).

 

This kind of loop could reduce the traffic for an "All On" or "All Off" programs by testing each device before sending the command. It would also be useful for regrouping actions and devices of the same kind, like polling all thermostats.

 

That would also be a way for testing manually if some scenes turn true. The program could only tests scene where all On Level are the same, because the same IF tests all of them, but still, it would be an improvement.

 

Such a program would not be triggered by events, so would have to be started by another program. That would offer a way to prevent races and status conflicts by preventing the run of two instances of the program or by stopping it as a consequence of its own actions.

 

The more programming functions the ISY offers, the more we can do with it...

 

Jacques

[ergodic]

Having just spent several days coding up a lot of fussy programs (all working well BTW), I have to second this idea or something like it - possibly apply operators to a device list or list variable.

 

For example, I have several rooms where I manage the lighting at different times of the day automatically, with fast-on / fast-offs used to disable / enable the control program.

 

This leads to a pair of programs that look like.

 

if control 1 is fast off

or control 2 is fast off

or control 3 is fast off

...

 

and likewise

 

if control 1 is fast on

or control 2 is fast on

or...

 

You know the idea. I haven't spent much time yet considering the traffic implications, but overall this kind of thing turns out to be more difficult to keep maintained than I would have expected - I have several scenes with 8-10 controllers in various places. Each change has to be remembered to be manually synchronized to changes in the various control programs affected. And this is a simple example, the logic of some of the program sets I have now seem so tortured 5 minutes after I get them working I hate to even twiddle with them at all.

 

And I know this has been discussed before, but I would suggest considering one modification to the excellent post above. Off is off. Anything else is on. To me, if you set an SL Relay or Outletlinc to off it should go off. If you test it for off and it's off that's true and anything more than off is false. If you set it to anything other than off it should go on. This is how these devices typically respond, how I would expect the logic to work, and how I think the feature would be most useful.

 

There also could be another way to implement this. For instance add a new item under "Conditions" (Scene Device Test, Device List, or some such). For the is/is not operators just add the various likely tests: all switched on, any switched on, all status off, etc. While the programmer in me would love variables, loops, etc., this might be more in keeping with the current, more minimalist nature of ISY programs.