Communication Collisions

[matapan]

I can reliably turn on and off a group of lights in a scene and toggle another Switchlinc if wait a second or two between paddle or key presses. If I press both paddles or keys in rapid sequence, the scene fails to toggle, even though the keypad button shows the scene was enabled or disabled by its illumination.

 

Is this a case of too much communication going on at once? Or something else?

[LeeG]

matapan

 

Insteon does not allow multiple Scenes to be running at the same time. When a button/paddle is pressed multiple Insteon messages are issued by the Controller. How many depends on how many Responders are linked to the button/paddle. If another Scene is started before the current Scene is complete it is aborted by Insteon hardware/firmware.

 

Lee

[matapan]

Thanks for the details LeeG.

 

What is the proper coding practice then to prevent incorrect state displays on the controller/responder when scene or device status change command is issued immediately after a different scene command is issued?

 

Example:

 

Toggle a device.

Immediately toggle a scene.

 

Result:

Scene is not activated. The keypad or switchlinc indicator no longer matches the actual scene state.

 

How does one prevent this, programatically or otherwise?

[LeeG]

matapan

 

I'm not clear about what is occurring.

 

Toggle a device.

Immediately toggle a scene.

 

If "Toggle a device" is pressing a paddle/button the device hardware/firmware is driving a Scene. If "Immediately toggle a scene" is pressing a paddle/button that device hardware/firmware is driving a Scene. If this is the scenario there is no control over what is going to happen. The respective device hardware/firmware is in control.

 

If my description of events is not correct please expand on what is actually happening.

 

Lee

[matapan]

To clarify, the device is a Switchlinc or other device directly controlling a load.

 

If I toggle a scene from a Keypadlinc then immediately toggle a device controlling a load, the Keypadlinc shows the status change, but the devices in the scene don't always respond.

[LeeG]

matapan

 

When a button/paddle is pressed it initiates a Group protocol message sequence. It starts with a Group Broadcast message that goes to every device on the powerline. Most of the time all the Responders of the button/paddle see the Group Broadcast message and react to it. To insure that all Responders react each Responder is sent a dedicated Group Cleanup Direct message. This message must be ACKed by the Responder and is retried by the Controller if an ACK is not received. On a good powerline the Group Cleanup Direct messages are redundant and perform no actual function.

 

When the KeypadLinc button is pressed the above Group message sequence is initiated. When the SwitchLinc paddle is pressed the KeypadLinc sees the Group protocol sequence initiated by the SwitchLinc and aborts the remainder of the KeypadLinc Group Cleanup Direct messages. On a good powerline this has no affect because the Group Cleanup Direct messages that are aborted are redundant. If the powerline is not clean and some of the Responders must see their individual Group Cleanup Direct message to react, those Responders whose Group Cleanup Direct message is aborted do not respond.

 

Insteon architecture has worked this way since Insteon was release in 2005.

 

Every device button/paddle press initiates a Scene regardless of whether an explicit Scene has been defined for that Controller. The ISY PLM is a Responder to every button/paddle so that the ISY is aware of button/paddle press. This is necessary so that Programs can be triggered as well as maintaining device statue for the Admin Console and other applications.

 

Lee

[matapan]

Thanks for the explanation LeeG.

 

To summarize, I think what you are saying is:

 

1. All commands generated by key or paddle presses initiates a scene group message.

2. The scene group message actually consists of two messages. One that is broadcast to the entire network, and another that requires an acknowledge from each responder in the scene.

3. If two group messages are sent together in rapid sequence, only the second one will be completed. The first one is aborted.

 

If this is the case, my understanding is that only a single group message can actually be sent reliably on the network. Multiple group messages broadcast at the same time will not be reliable.

 

Is there a way to force the Keypadlinc button state to match the actual acknowledgement state of the group scene command. In other words, can you programmatically ensure the button state matches the success or failure of the group scene command being processed?

 

I hate the fact that the Keypadlinc button states can so easily be out of sync with the scene state. There must be a better way to keep button states in sync with the state of a group scene message acknowledgement.

[LeeG]

matapan

 

The answer to 1,2,3 is Yes to all three with a clarification. There is a separate Group Cleanup Direct message sent to each Responder. If a button/paddle has three Responders then 4 messages flow from the Controller. One Group Broadcast and three Group Cleanup Direct messages, one to each Responder.

 

"my understanding is that only a single group message can actually be sent reliably on the network."

 

Two devices initiating a Group sequence that overlap, one device will cancel the other device out. If the powerline is good it does not make any difference. If the powerline is marginal or has transient interference then some Responder devices may not see the initial Group Broadcast and would not see the aborted Group Cleanup Direct. In practice having multiple paddle/buttons pressed at the same time is not common plus the situation has to exist along with some powerline issues. There is nothing at the device level to prevent this.

 

Lee

[matapan]

Being that this is the reality, I go back to the original question: Is there a way to keep the Keypadlinc button state tied to the success or failure of the scene command? If the keypadlinc is toggled on to initiate a scene, and the scene fails, is there a way to turn off the keypadlinc button to reflect final state?

[LeeG]

Trigger a Program with the KeypadLinc button press. Wait long enough for all Responders to react to the KeypadLinc button press. Issue a Query for each Responder. After the last Query Invoke another Program with a complex If that checks the current status of each Responder. If the combined status of all the Responders is not correct, turn a Scene Off that has the KeypadLinc button as a Responder. This must be done with a Scene as Secondary KeypadLinc buttons cannot be controlled with Direct commands.

 

EDIT: be sure the Wait is long enough for all Responders to react. This includes the possibility of multiple retries for some of the Responders. Since the presumption is the Group Broadcast does not reach all Responders because of powerline issues the need to retry some of the Group Cleanup Direct messages is possible.