Reply To: linking ouputs R1 & R2 2017-12-21T22:15:38+00:00

HOME Forums Input/Output EZIOxx linking ouputs R1 & R2 Reply To: linking ouputs R1 & R2

Anonymous
Post count: 1001

Bob

When most Insteon messages (Broadcast message is an exception) are sent to a device, Insteon protocol requires the responder device send an ACK back indicating the message was successfully received. This is automatic and not unique to SHN devices. Sending an On message to a LampLinc, the LampLinc sends an ACK back to the Controller device that sent the On message. This required and automatic ACK is one of the reasons Insteon is more reliable than X10 which has no ACK. Should the device that sent the On message fail to receive the ACK response, it will retry sending the On message up to three times before indicating the On message failed. The ACK and retry process is done automatically by the internal PLM which all Insteon devices contain. Intermittent powerline noise generally does not last long enough to prevent one of the multiple On messages from being successfully received and ACKed.

A Direct message sent from Indigo (through PLM) to control an EZIOxx relay will always be ACKed by the internal PLM or external PLM in the case of the EZIO8SA. An Insteon Direct message contains both the Controller Insteon address and Responder Insteon address which is why link records are not required for Direct messages. Applications (like Indigo) cannot suppress the message/ACK exchange.

All Smarthome devices send Group On/Off messages to signal state changes. Pressing a KeypadLinc button, a SwitchLinc paddle, a Motion Sensor indicating motion, and so on, all send Group On/Off messages which require the responding device to send an ACK message indicating the Group On/Off message has been received.

The SHN EZIOxx family of devices all have the capability to send Group On/Off messages in response to Input state changes, just like the Smarthome devices. As with the Smarthome devices, Group communication requires links be established between Controller and Responder devices. It is the link records that identify the Insteon addresses of the Responder(s) so the Controller knows what devices to send the Group messages to. The Responder link records have the Insteon address of the Controller device that is permitted to control the Responder device. The Set button (and sometimes the button/paddle) can be used to establish the required link records.

Most applications have implemented link management function that write the link records and any other configuration information programmatically without the need for running around pressing Set buttons and/or buttons/paddles.

Again, to reinforce, all Group On/Off messages must be ACKed by the responding hardware.

The Insteon protocol documents a Broadcast message as an alternate means of signaling state changes. This form of signaling Input state changes does not require the Controller device (EZIOxx) to be linked to the Responder device. Without the benefit of link records the Controller (EZIOxx) does not know the address of the Responder device(s) so the Broadcast message is sent on the powerline in the blind (to no specific responder device address). Every Insteon device on the powerline can look at the Broadcast message. Because the Broadcast message is not sent to any specific responder NO ACK is sent back by any responder device and no retry is possible. Broadcast messages are like X10, one way only with no ACK and no retry.

Utilizing the Broadcast protocol is comparatively simple since no link management is needed and very little device configuration is required. It is also the least reliable aspect of the Insteon protocol because ACK and retry are not possible.

Lee