detailed write-up of a programming example

[johnradams]

I am impressed by your ambition.

 

How does your site differ, in purpose, from the wiki?

 

I intend to add my content to the wiki Real Soon Now. Until I am set up to edit the wiki, I am happily hacking away on my own.

[apostolakisl]

I use programs to turn off scenes (including those with controller devices) all the time, without issues that I know about. In fact, I thought the response to scene commands was more robust than the response to individual devices. Like Sub-routine and gviliunas, I am having trouble understanding why you think this is a bad idea.

 

 

I too put scenes in my programs which are controller/responders and have found it to be superior to listing devices separately. Aside from the obvious added work of listing all the devices I find it executes more quickly and I don't encounter any surprises. In fact, if my program targets more than two devices and an appropriate scene doesn't already exist, I will create a scene specifically for the program (although it will be a responder only).

[Chris Jahn]

Chris,

 

Thank you very much for taking the time for your last post. That is what I got from the Wiki but so many different opinions were being posted that did not agree I was beginning to think I had interpreted the Wiki wrong. Really appreciate an explanation from the experts.

 

Lee

 

Thanks Lee, just trying to keep the record straight.

 

 

Consider me to have spoken up. I believe this is not correct.

 

Thanks for your input. I'm glad this discussion is getting some visibility. As I noted, I was advised by UDI to list the devices, and avoid putting the multi-way scene itself in the Action list. ...

 

... In other words, if you want to turn off all the lights in a virtual circuit with 3 lights, you want to have 3 separate Off commands in the list of Actions. You should not take the short-cut of simply setting the scene (that manages the multi-way circuit) to Off. ...

 

I'm not sure who would have said this, or maybe an explanation was misinterpreted somehow; but it is not correct.

 

It is almost always better to use a scene rather than setting devices individually. In fact, the only time I wouldn't use a scene is if I have only a single responder.

[TJF1960]

Consider me to have spoken up. I believe this is not correct.

 

Thanks for your input. I'm glad this discussion is getting some visibility. As I noted, I was advised by UDI to list the devices, and avoid putting the multi-way scene itself in the Action list. ...

 

... In other words, if you want to turn off all the lights in a virtual circuit with 3 lights, you want to have 3 separate Off commands in the list of Actions. You should not take the short-cut of simply setting the scene (that manages the multi-way circuit) to Off. ...

 

I'm not sure who would have said this, or maybe an explanation was misinterpreted somehow; but it is not correct.

 

It is almost always better to use a scene rather than setting devices individually. In fact, the only time I wouldn't use a scene is if I have only a single responder.

 

I wonder if it had to do with ACK's being sent with single commands vs no ACK's sent with scenes? In other words the ISY receives ACK's after it sends a single command so it knows the command was received. But with scenes the ISY assumes all responders received the command (if I understand correctly)?

[LeeG]

TJF1960

 

Only the initial Group Broadcast message issued for a Scene is not ACKed by any individual Responder because it is not sent to any specific responder device. Following the Group Broadcast message the controller sends Group Cleanup Direct messages to every Scene responder in sequence and this message must be ACKed or it is retried. A Scene responder failure is known.

 

Lee

[TJF1960]

Hi Lee,

 

Sorry then for the mis-information. I thought I read somewhere on this forum that the ISY did not send Group Cleanup Direct messages after scene commands.

 

So if the controller doesn't receive an ACK from every responder after the group cleanup then the scene command is re-sent?

[LeeG]

TJF1960

 

I would have to trace a Scene command sequence where the ISY is the Controller but I would doubt the Group Broadcast is the only message sent. Scenes could/would be very unreliable if only the Group Broadcast message was sent. Positive command acknowledgment and command retry is a hallmark of Insteon protocol and a major reason Insteon enjoys the reliability it has. All Insteon devices being a repeater and the mess RF/powerline network is also a major factor.

 

There is a specific PLM serial command that initiates a Group/Scene. The PLM does all the heavy lifting to send the Group Broadcast message and follow up Group Cleanup Direct messages to each responder, including retrying any Group Cleanup Direct that is not ACKed. The PLM sends back a message to the application (ISY) if any responder fails to ACK the Group Cleanup Direct after all retries have been attempted. It would not be normal protocol for an application to reissue the PLM serial command to initiate the Scene again for an individual responder failure. The responder has already failed multiple attempts by the PLM to initiate the Scene command. No reason to think the next set of retries would be any more successful.

 

All Insteon devices when functioning as a controller issue both Group Broadcast and Group Cleanup Direct messages. There are some exceptions for Dim and Bright Group command sequences. These are very time dependent sequences. It would be impossible to issue a Start Manual Change followed by a Stop Manual Change to every responder in sequence when a paddle/button is pressed and held. For normal On/Fast On/Off/Fast Off Group commands Insteon controllers always send both Group message types.

 

Lee

[TJF1960]

I just found the link (or one of them) discussing group clean up.

 

http://forum.universal-devices.com/viewtopic.php?t=3033&highlight=group+cleanup+direct

 

I noticed the post is over a year old so maybe things have changed that I am not aware of.

[LeeG]

I will have to think about my response to that 2009 post. What I just wrote and deleted would not be appreciated by some.

[Michel Kohanim]

Hello LeeG,

 

Please do not delete your posts just because it might offend us.

 

We spent months with group commands and how the PLM handles the responses before deciding on not using the PLM's Group Command. Instead, we modify the raw INSTEON command to act as a group command but the PLM does NOT know that it's sending a group command. In short, we do send a group command but the PLM does not know it's a group command so it does not send cleanup etc.

 

The major problems with group commands are more visible when you have programs that activate large scenes (more than 5) and if you have multiple programs that might want to do something while the PLM is processing the cleanup. This caused major unpredictability issues and thus we had to forego using it. As a matter of fact, we still have the code #defined so that it's not compiled.

 

With kind regards,

Michel

[LeeG]

Michel

 

Many thanks for taking the time to detail the thinking behind the ISY approach to running Scenes. That was helpful. I have some experience queuing PLM requests, having to wait for the Group report message before issuing the next PLM command. It is a pain to say the least!

 

However, I think the designers had a reason for using follow up Group Cleanup messages so I think we just agree to disagree on this one. I still think ISY is the best Insteon product on the market and the support provided is a major reason for its success!

 

My deleted post was way over the top even for me.

 

Thanks again Michel.

 

Lee

[Michel Kohanim]

Lee,

 

My pleasure!

 

I am not sure we agree to disagree since I really do NOT disagree that this feature is a good feature. The only questions are:

1. Should the PLM stop processing clean up commands in case another device is sending status updates?

2. Should the PLM stop processing other commands if it receives clean up responses?

3. Which is more important: program responsiveness especially when one has programs based on status of devices which are part of activated scenes (from ISY) or a little more accurate status of devices

 

I truly believe that if the PLM started using a more powerful CPU with FIFO queues for each request (based on transaction ids), then we would not be having this conversation.

 

With kind regards,

Michel

[arzoo]

Hi - I'm very new to ISY programming, so I may be totally wrong here, but I was able to create a very similar basement control setup with less complexity. I'll explain what I did and please let me know if I'm missing something or there is some reason my solution is not good.

 

I have a KPL at the top of my stairs and I use each button to control a zone in the basement. Each zone may have multiple sets of lights. For example, my theater zone has overhead cans, back sconces, and side sconces. Button A on the KPL will turn on or off all the lights in the theater zone. If any one circuit in the zone is on, then the KPL LED is lit, otherwise it is not lit. So this is the same as your basement scenario, just with multiple zones (and buttons) rather than all together.

 

Here's what I did (I'll stick with the theater zone for the example). First I created a scene which included the KPL Button A as a Controller and each of the load wired switches (overhead cans, back sconces, and side sconces) as Responders.

 

At this point, pressing KPL button A will turn on all the lights in the theater zone (and the KPL button is illuminated). Pressing KPL button A again will turn off all the lights in the theater (and the KPL button turns is off).

 

Next I created a second scene which only included KPL Button A as a responder.

 

Lastly, I created a program to monitor the status of the theater zone;

 

If
       Status  'Basement Lights / Theater Cans' is not Off
    Or Status  'Basement Lights / Theater Rear Sconces' is not Off
    Or Status  'Basement Lights / Theater Side Sconces' is not Off

Then
       Wait  1 second
       Set Scene 'Basement Lights / Stairs Top Keypad (A) LED' On

Else
       Wait  1 second
       Set Scene 'Basement Lights / Stairs Top Keypad (A) LED' Off

 

I'm not even sure if the wait statements are necessary.

 

Since the scene fired as the action 'Basement Lights / Stairs Top Keypad (A) LED' only includes the KPL button as a responder, the button LED lights up correctly but the actual scene for the zone does not change - hence no race or looping issues.

 

So far this seem to work.

[Michel Kohanim]

Hello arzoo,

 

Your scenes and programs are sound. The only thing I would do is to remove the Else path and, if necessary, create another program to set the LED off.

 

With kind regards,

Michel

[oberkc]

I use a similar logic to turn a keypad button on if any one (or more) lights are on. I don't use the wait statements. My program works fine and I expect yours will, also.

[arzoo]

Hello arzoo,

 

Your scenes and programs are sound. The only thing I would do is to remove the Else path and, if necessary, create another program to set the LED off.

 

With kind regards,

Michel

 

Thanks - good to know I'm getting a handle on this. Why is it better to use a 2nd program to turn off the LED rather than the else statement?

[johnradams]

Why is it better to use a 2nd program to turn off the LED rather than the else statement?

 

Note that your program as listed herein will always execute either the 'Then' portion or the 'Else' portion. This might cause additional internal activity, overhead, etc. within the ISY (we'll let someone at UDI clarify).

 

If you use a 2nd program, then each program can be structured to only use the 'Then' portion. This means that unless the 'If' expression evaluates to True, then the program essentially does nothing. Which might, or might not, be useful. As you gathered, ISY advised me to use the "two program" method.

[johnradams]

I'm not even sure if the wait statements are necessary.

 

Unless I am mistaken, the Wait statement avoids the race condition that describe in my write-up, here: http://adamsj.com/isy/

 

The race condition is a concern is you have lots of devices (I have over 100 devices), and some occasional Insteon network delays due to a large configuration (lots of breaker panels, etc.). Your mileage may vary. I didn't like the flickering keypad button, as it was confusing to use.

 

BTW, I plan to post the write-up to the wiki when any final nits are resolved, such as a clear explanation of why it is "better" to use 2 programs instead of a single program with an Else.

[oberkc]

If you use a 2nd program, then each program can be structured to only use the 'Then' portion. This means that unless the 'If' expression evaluates to True, then the program essentially does nothing.

But now you have two programs, one of which is guaranteed to evaluate as "true". Since one of the two programs is always true at each evaluation, where is the savings in internal activity? I don't see where two programs (one always true) is is more effiecient than one program (always true or false).

 

My gut reaction is to suspect the opposite. Now I have two programs undergoing evaulation rather than one.

[arzoo]

I'm not even sure if the wait statements are necessary.

 

Unless I am mistaken, the Wait statement avoids the race condition that describe in my write-up, here: http://adamsj.com/isy/

 

The race condition is a concern is you have lots of devices (I have over 100 devices), and some occasional Insteon network delays due to a large configuration (lots of breaker panels, etc.). Your mileage may vary. I didn't like the flickering keypad button, as it was confusing to use.

 

I've tried my single program solution without the wait statements and it still works fine - no race condition, no flickering.

 

I think the reason you're running into the problem with the race condition is because your solution involves a program to turn the scene on or off (the actual lights) where as with my solution the program only controls a scene that sets the KPL LED. The control of the lights ("All On/Off" scene) is handled by the KPL button as a controller in the scene.

[arzoo]

But now you have two programs, one of which is guaranteed to evaluate as "true". Since one of the two programs is always true at each evaluation, where is the savings in internal activity? I don't see where two programs (one always true) is is more effiecient than one program (always true or false).

 

My gut reaction is to suspect the opposite. Now I have two programs undergoing evaulation rather than one.

 

I would agree with this also - two programs vs then/else should be no different - either way an action will be executed.

 

I wonder how the ISY evaluates the "status" of a device. I'm would assume that for efficiency, the ISY keeps and internal state (on/off) for each device and only runs the program when the status changes.

[oberkc]

I'm would assume that for efficiency, the ISY keeps and internal state (on/off) for each device and only runs the program when the status changes.

This is my understanding. Status is shown at the admin panel. Programs (at least the example) "evaluate" upon status change. Whether they run is based on results of the evaluation.