How Insteon Really Works

From Cinemar Wiki
Jump to: navigation, search

Definitions

For the purposes of communication between Insteon devices, there are two types of devices:

Controllers - Devices that can send messages.

Responders - Devices that accept and act upon messages.

Most devices are both Controllers and Responders. It is important to understand the role a device in when describing a specific behavior.

A lot of Insteon discussions use the term linking or link database. An Insteon link is really entries in two device link databases that configure the sending and receiving of messages.

An Insteon group is a collection of links that enable a controller to send one message to one or more responders.

Device Communication

There are two types of messages used in the Insteon protocol. Direct and Group broadcast.

A direct message is sent from one device specifically to another. Direct messages are reliable, once the message is sent, an acknowledgment is expected. If the acknowledgment is not received, the device retries the send multiple times. The only devices that can be programed to send direct messages are the controller type devices, PLC, PLM, and devices based on those. Other devices use direct messages, but only as a backup to a group broadcast. The MLInsteonPLM plug-in can use this method to control individual devices. For instance, an automation rule could be created to turn on a light at sunset and turn it off at sunrise. The plug-in could also be used in a lighting scene that controls individual lights like the one below. Lighting scene1.jpg

A group broadcast message is sent from one device to all devices on the Insteon network. The sender doesn't know which devices will respond. This point is important. The advantage of this type of message is that many devices can respond simultaneously. When a ON broadcast is sent, 5 lights could all turn on at the same time. Using direct messages the lights would sequence on, one after the other. The main disadvantage is that a device could miss the message. The sender does not get any acknowledgment that the message was received. To improve the group broadcast reliability, senders will follow up with a direct message to each device it expects to receive the message. Another important point. If the sender doesn't expect a device to receive its group broadcast, it won't follow up with that device. Group broadcasts are typically used to create lighting scenes. A single device button or switch is used to control many other devices. The MLInsteonPLM plug-in can send group broadcasts in response to automation events or through a lighting scene like the one below. Lighting scene2.jpg

There is one other special message. All devices are suppose to respond to a group broadcast message sent to group number 255. This allows a controller device like the PLM or PLC to send a message to all devices. This can be used to implement "All On" and "All Off" commands.

Links

Links are the heart of Insteon. The links between devices are what allows one device to control another. You could install a SwitchLinc and not link it to anything else, but then it is really nothing more than a regular light switch. To take advantage of the Insteon protocol, you have to create links between devices.

The the general meaning of the word link doesn't match what actually happens with Insteon devices. Typically, when two things are "linked", there exist a two way communication between them. This isn't true of Insteon so forget link. Instead we'll refer to devices as either sending a message or receiving a message. The device configuration data that controls the communication will be referred to as a link entry.

Below are some examples of link entries needed to accomplish specific configurations. The examples will make use of 4 devices; Switchlinc SW1 (00.00.01), Switchlinc SW2 (00.00.02), Lamplinc LP1 (00.00.03), and a PLM (00.00.04). Assume that SW1 is connected to an overhead light and SW2 has no lights connected (i.e. used as a slave).

Example 1: SW1 and SW2 in a typical 3-way configuration. Either switch can control the light attached to SW1.

SW2 has a controller link entry specifying SW1 as a responder   (SW2 sends ON/OFF to SW1)
SW2 has a responder link entry specifying SW1 as the controller (SW2 accepts ON/OFF from SW1)
SW1 has a controller link entry specifying SW2 as a responder   (SW1 sends ON/OFF to SW2)
SW1 has a responder link entry specifying SW2 as the controller (SW1 accepts ON/OFF from SW2)

A couple of notes about this example. Notice that there are really pairs of link entries one on the controller and one on the responder. Also notice that even though SW2 doesn't have a light attached, it is still considered a responder. This is so its status lights stay updated. This is really for aesthetics, if SW2 didn't have status lights, the second set of link entries wouldn't be needed.

Example 2: SW1 and SW2 in a typical 3-way configuration plus the PLM is notified of the state change of either switch. Either switch can control the light attached to SW1, however, the PLM cannot control the light.

SW1 has a controller link entry specifying SW2 as a responder   (SW1 sends ON/OFF to SW2)
SW1 has a controller link entry specifying PLM as a responder   (SW1 sends ON/OFF to PLM)
SW2 has a controller link entry specifying SW1 as a responder   (SW2 sends ON/OFF to SW1)
SW2 has a controller link entry specifying PLM as a responder   (SW2 sends ON/OFF to PLM)
SW1 has a responder link entry specifying SW2 as the controller (SW1 accepts ON/OFF from SW2)
SW2 has a responder link entry specifying SW1 as the controller (SW2 accepts ON/OFF from SW1)
PLM has a responder link entry specifying SW1 as the controller (PLM accepts ON/OFF from SW1)
PLM has a responder link entry specifying SW2 as the controller (PLM accepts ON/OFF from SW2)

In this example the only device added is the PLM, and it is added only to receive status updates. This allows us to put a picture of the light on a MainLobby scene and have the picture reflect the status of the actual light. When the light is on the picture is bright, when the light is off, the picture is dim. Notice that the PLM has to accept the commands from both switches and both switches have to send the command to PLM.

Example 3: SW1 and SW2 in a typical 3-way configuration. In addition, the PLM is configured to allow MainLobby commands to control the light. Either switch or the PLM can control the light attached to SW1.

SW1 has a controller link entry specifying SW2 as a responder   (SW1 sends ON/OFF to SW2)
SW1 has a controller link entry specifying PLM as a responder   (SW1 sends ON/OFF to PLM)
SW2 has a controller link entry specifying SW1 as a responder   (SW2 sends ON/OFF to SW1)
SW2 has a controller link entry specifying PLM as a responder   (SW2 sends ON/OFF to PLM)
PLM has a controller link entry specifying SW1 as a responder   (PLM sends ON/OFF to SW1)
PLM has a controller link entry specifying SW2 as a responder   (PLM sends ON/OFF to SW2)
SW1 has a responder link entry specifying SW2 as the controller (SW1 accepts ON/OFF from SW2)
SW2 has a responder link entry specifying SW1 as the controller (SW2 accepts ON/OFF from SW1)
PLM has a responder link entry specifying SW1 as the controller (PLM accepts ON/OFF from SW1)
PLM has a responder link entry specifying SW2 as the controller (PLM accepts ON/OFF from SW2)
SW1 has a responder link entry specifying PLM as the controller (SW1 accepts ON/OFF from PLM)
SW2 has a responder link entry specifying PLM as the controller (SW2 accepts ON/OFF from PLM)

By adding a couple more link entries we give the MainLobby scene the ability to control the light. Notice here that the PLM is sending the command to both switches. Again so the second switch can set its status lights correctly.

Example 4: A typical room lighting scene with two lights. One light is attached directly to SW1 and the other light is plugged into LP1. Both SW1 and the PLM can control both lights.

SW1 has a controller link entry specifying LP1 as a responder   (SW1 sends ON/OFF to LP1)
PLM has a controller link entry specifying LP1 as a responder   (PLM sends ON/OFF to LP1)
PLM has a controller link entry specifying SW1 as a responder   (PLM sends ON/OFF to SW1)
SW1 has a responder link entry specifying PLM as the controller (SW1 accepts ON/OFF from PLM)
PLM has a responder link entry specifying SW1 as the controller (PLM accepts ON/OFF from SW1)
LP1 has a responder link entry specifying SW1 as the controller (LP1 accepts ON/OFF from SW1)
LP1 has a responder link entry specifying PLM as the controller (LP1 accepts ON/OFF from PLM)

Here we have a "scene" that is triggered by either a switch or a MainLobby button. Scenes in Insteon specify an end-state for all the devices that respond to the scene. With this scene, either the switch or the PLM will turn the lights on and off.

Example 5: A typical room lighting scene with two lights. One light is attached directly to SW1 and the other light is plugged into LP1. Both SW1 and the PLM can control both lights. In addition, the PLM can set both lights to 50% brightness.

SW1 has a controller link entry specifying LP1 as a responder   (SW1 sends ON/OFF to LP1)
PLM has a controller link entry specifying LP1 as a responder   (PLM sends ON/OFF to LP1)
PLM has a controller link entry specifying SW1 as a responder   (PLM sends 50%/OFF to SW1)
PLM has a controller link entry specifying LP1 as a responder   (PLM sends 50%/OFF to LP1)
PLM has a controller link entry specifying SW1 as a responder   (PLM sends ON/OFF to SW1)
SW1 has a responder link entry specifying PLM as the controller (SW1 accepts ON/OFF from PLM)
PLM has a responder link entry specifying SW1 as the controller (PLM accepts ON/OFF from SW1)
LP1 has a responder link entry specifying SW1 as the controller (LP1 accepts ON/OFF from SW1)
LP1 has a responder link entry specifying PLM as the controller (LP1 accepts ON/OFF from PLM)
SW1 has a responder link entry specifying PLM as the controller (SW1 accepts 50%/OFF from PLM)
LP1 has a responder link entry specifying PLM as the controller (LP1 accepts 50%/OFF from PLM)