WAIT needed in program when setting a scene?

[jtara92101]

I have a little program that turns off my master bathroom lights when I turn off my master bedroom lights:

 

If
       Control 'Master Bedroom / Master Bedroom Keypad' is switched Off
    Or Control 'Remote / Remote A MBR' is switched Off

Then
       Wait  1 second
       Set Scene 'Master Bath / Master Bath Default' Off

Else
  - No Actions - (To add one, press 'Action')

 

This didn't work at all until I added the Wait statement. Actually, it works unreliably with the 1-second wait - I haven't determined yet just how much delay is needed, but it seems to work reliably with a 5-second wait, and it seems OK right now with a 2-second delay.

 

It is completely reliable if I set the individual dimmers in the bathroom, rather than setting the scene. But, then, the lights go out in sequence, rather than all at the same time, which is annoying.

 

(Aside: is there a way to avoid the "sequencing" if I turn them off individually? Maybe make a program for each one, and run the programs? When a program runs another program, it doesn't wait for completion, before continuing, right?)

 

Also, I guess I should really be testing for the status of all of the dimmers in the MBR, rather than control actions, right? As it is, it won't turn the bathroom lights off on a fast-off or a fade-down to 0. (By habit, I normally fade-down the RemoteLinc.)

 

Why do I need the wait? Is there a better way to do this? I discovered the "fix" of using the wait quite by accident. I'd thoroughly convinced myself that "set scene" simply didn't work at all, until I tried sticking in a Wait.

 

This post seems somehow relevant:

 

http://forum.universal-devices.com/view ... cene+delay[/code]

[jtara92101]

OK, this version is insensitive to how I turn the MBR lights off. It still needs the delay, though. I know I can get rid of the delay by switching off the master bath lights individually, but then there is a delay as each light is turned off.

 

Program "MBR Occupied"

 

If
       Status  'MBR / MBR Overhead' > Off
    Or Status  'MBR / MBR Track' > Off
    Or Status  'MBR / MBR Floor Lamp' > Off

Then
  - No Actions - (To add one, press 'Action')

Else
  - No Actions - (To add one, press 'Action')

TRUE if MBR is "occupied" - i.e. at least one MBR light is on. Use a higher level than OFF if a "night light" function is desired.

 

Program Master Bath off with MBR

 

If
       Program 'MBR Occupied' is False

Then
       Wait  2 seconds
       Set Scene 'Master Bath / Master Bath Default' Off

Else
  - No Actions - (To add one, press 'Action')

[LeeG]

Using a Scene is the only way to get a group of responders to react simultaneously. A Scene (Group as far a hardware is concerned) starts with a special Group Broadcast message that causes all responders of the Group to react at the same time. Individual Direct device commands must be ACKed by the device before a Program can proceed with the next Direct command. Insteon cannot handle multiple Direct commands on the powerline at the same time.

 

The reason the delay is required is that Insteon architecture will cancel a Scene execution if another Scene execution overlaps.

[paulw]

Lee,

 

I have never had to use a wait on a scene, has this always been the case? Or, have I just not hit the right mix of commands to create a problem?

 

I have had to use a wait with x10 commands.

[Sub-Routine]

You should not have to use a Wait.

 

Would you try a program that only watches for the KPL Off?

 

Rand

[LeeG]

Paul,

 

The conflict between multiple Scenes has always been there. In a pure hardware situation (no automation) there is generally no visible result of hitting a second paddle/button while one Scene is in progress. The hardware Group protocol initiated from a paddle/button press starts with a Group Broadcast message which all responders react to nearly simultaneously. At this point all the visual changes from the first paddle/button button press have been initiated.

 

After that the Group protocol generates a Group Cleanup Direct message to every responder device in the Group (Scene) which requires each responder to send back an ACK to the controller where the paddle/button was pressed. This Group Cleanup Direct/ACK message exchange sequence can take some time depending on the number of responders in the Scene. The follow up Group Cleanup Direct message exists for the rare case where all responder devices failed to receive the initial Group Broadcast message. Normally all responders see and react to the Group Broadcast message so if the remainder of the Group protocol, the issuing of the Group Cleanup Direct messages, is canceled as a result of a second paddle/button press there is no adverse visual effect.

 

With Home Automation it gets more complicated. With Programs being initiated by the Group protocol generated with a paddle/button press and that Program initiating a new Scene, what was a rare conflict between multiple paddle/button presses can now be a common occurrence. Another area is a Program initiating multiple Scenes in a row. Without HA pushing multiple paddle/buttons in a row was rare. With HA it is more common to initiate multiple Scenes. Timing is everything. Depends on whether there are multiple responders to a paddle/button press. If so, where is the ISY PLM in that list of responders. In other words, where in that series of powerline messages is the ISY PLM notified of the paddle/button press.

 

I tend not to think of these potential problems when writing automation. Only if something is unreliable or just “should work†but does not then think about where a conflict might exist and if a Wait could resolve it.

 

Sorry for the long winded response. It is necessary to know how the Group protocol works to see what and where potential conflicts can arise. HTH

 

Lee

 

 

I see from Rand’s post that the ISY will handle these conflicts. I defer to the expert.