ISY-994i QuickStart: scenes and link tables

I’ve written extensively about Insteon Scenes, and discussed some things to consider when diagnosing problems with scenes, but I thought for the sake of completeness in the ISY-994i QuickStart mini-series, scenes should be included. So here’s a question from reader Ashu:

I do understand the use case for creating a scene where multiple devices need to controlled together but if there is a need to control just one device, say a lonely light bulb in the spare room – would you still create a scene for that device?

The reason why I ask is becasue per ISY documentation: “Once programmed, scenes operate completely independent of the ISY for the quickest response time and most reliable operation” — does that mean there is some performance/efficiency to be gained?

Here’s my response:

In general, I create scenes for virtually everything, even those single-bulb scenarios like Ashu mentions. Here are a couple reasons why I do it:

• I use MobiLinc and there are separate screens for “scenes” and “devices” so I don’t want to have to switch back and forth to control one or the other.
• Oftentimes even if you do have a lonely light bulb, you may end up adding another switch to control it. For example, maybe you have a KeypadLinc in another room that you want to control that lone bulb; a scene allows you to connect multiple devices later on.
• Insteon devices fail, so by controlling devices through scenes it provides a bit of an abstraction so that when you replace a device you don’t have to change the scene you’re controlling (or any programs or Amazon Echo commands that may reference that scene).

All of those reasons are a bit nebulous and don’t really answer the technical question about whether you should create a scene to control just one device. First off, let’s explain what the ISY doc means. Basically, they’re talking about multi-device scenes, and they’re referring to the fact that all Insteon devices have a built in “link table”. You can see this in the ISY by right-clicking a device, then going to “Diagnostics: Show Device Link Table”. The link table is how the device knows who to send messages to and receive from. Take this example – I’ve got lights in my attic and I control those lights with an open/close sensor so that the lights go on when the ladder is dropped down:

I have a “scene” called “Attic Lights” with two devices in it – the Open/Close sensor as a controller and the Light switch itself as a responder. Open the door, lights go on. But under the covers what the ISY does is write to the link table for those two devices so that they send messages directly between them without having to communicate with the ISY at all. So even if I unplugged the ISY, this would all still work because the devices are communicating “completely independent of the ISY for the quickest response time”.

As an academic side note, you’ll note there’s actually another device in the link table for my lights at position 0. This address is actually the PLM that the ISY uses to communicate to the Insteon system. THAT is why, when you turn on the lights, you can actually see the status go on in the ISY: the light is sending a signal to the PLM that the ISY reads. [As a side note we’ll discuss in another post, it’s also why, if your PLM goes belly-up, it is a GIANT PAIN to restore everything – because you need to re-write every single device on your insteon network to get the address of the new PLM in the link tables.]

So, is there a performance gain to adding a single device to a single scene? No. In your spare bedroom when you push the switch, the power goes on. Insteon has nothing to do with it at that point; it’s just a “dumb switch”. If you’ve added the switch to your ISY, a link to the PLM created so that the state of the switch can be detected by the ISY – which, arguably, is a “scene” in the sense that you’re linking the switch to the PLM. If you have multiple devices, then you have to create “scenes” because they’re abstractions for Insteon’s link table mechanism. Performance of the device isn’t compromised by the ISY being linked because the devices still talk directly to each other rather than through the ISY.

One last academic note: scenes and programs can behave in similar ways. A good example is linking a motion sensor to a light: you could just create a scene so that when the motion sensor goes on, the light responds and goes on as well. But you could also do the same thing with a program. If you implement this functionality as a program, then the ISY is a weak link in the chain: unplug the ISY or PLM and suddenly the lights no longer go on when motion is detected. This is because the ISY isn’t there to receive the signal from the motion sensor, run the program, and send the signal to the light. On the other hand, programs offer additional benefits that a scene itself can’t do, such as only running at specific times of the day.