Auto-add default links and support device cross-linking in the Insteon panel

Feature Requests
1

I migrated from my ISY994 to the native Insteon integration (with 2413S PLM) and it’s working quite well. From a functional perspective, I can’t see any difference, and I’ve taken a link out of the proverbial chain. One thing to note is that I initially had terrible performance issues, generally unreliable operation, and periodic failure to remove devices from Insteon scenes when I simply imported the PLM links, but I factory reset everything, re-added everything, and all the problems went away.

On to my requests -

  • When adding a new device, only the controller record in the PLM and responder in the device are added automatically. Once the device is added, there’s a handy link to “add default links”, where the controller record in the device and responder in the PLM are added, but it’s not clear why that’s not done automatically when the device is added. The result is that devices can be controlled, but the state changes aren’t reflected in HA until the user takes the explicit step to add the default links.
  • There’s no (obvious) way to set up device cross-linking from the Insteon panel, such as supporting synchronized n-way switches. Records can be added manually, but data 1/2/3 are not well-documented and it would be great if this common operation was abstracted for users. The ISY994 supports this by creating a “scene” in the admin console where each device is both a controller & responder, even if the user never intends to trigger the scene from the PLM. I tried to puzzle through the links created when manually cross-linking by going through the docs and just got lost.

There are several ongoing threads on the UDI forum about the pros/cons/issues with migrating to the native HA Insteon integration, often with misinformation and FUD, but there’s some truth to the statements that the HA Insteon panel is missing some small items like the ones above before it’s truly a viable replacement for the ISY994 admin console. It’s so close, and much less clunky, so I really hope the remaining gaps can be closed.

2

Just got your new PLM from Insteon? Me too. Only I’m migrating from a failed ISY 994 (probably the PLM) and a half-assed switch to an old Insteon Hub2 that never quite worked out well with HA. I have the new EISY and a fresh usb PLM and am resetting everything as I go.

I’m going with the EISY just because of the cross-linking issue. Dealing with the KPL6 and 8’s showing status when updated from various switching or HA has always been a pain for me and I feel I’m rediscovering how every time I try. I also would like an easier way. HA automations have made it somewhat easier, but I find I fall into a trap of circular activation from multiple lights being turned on from multiple sources and HA thrashing into a constant On/Off. I’m sure I’m doing something simple just wrong, but I agree there should be a more user-friendly method to it.

The only reason I had played with an Insteon Hub2 (off ebay and of questionable health) was that their mobile app makes it pretty trivial to setup a KPL with a FanLinc and those types of operations.

Definitely going to follow here for everyone’s suggestions.

3

Please do vote in the upper-left corner!

I have a couple of spare PLMs from several years ago and migrated to a new one because I was seeing some unreliable & slow performance. I don’t know if it was switching the PLM or rebuilding all the links from scratch, but it’s dramatically better now. Luckily, I only have a few places where I needed to manually cross-link. Certainly not enough to warrant adding more hardware to simplify that aspect of my setup.

One gotcha if you do go the manual route is that you need to re-load the ALDB for the affected devices in the HA Insteon integration to avoid having it overwrite the links you added with an older database. I went back and forth a few times before I realized that it doesn’t seem to read the current database before modifying it.

Since it’s not (yet) abstracted, I really want to better understand the link structure and data values. I appreciate that selected docs from Insteon are available in the pyinsteon package repo, but the parts around the ALDB structure are annoyingly vague and device-specific without clear definition of what that means for each device (controller & responder). I tried to reverse engineer it and eventually gave up. I may be making it more complicated than it really is, and I think I understand the “responder” links, but the “controller” side is a bit of a mystery.

Edit: I think I finally figured out the controller links. The data1/2/3 values seem to be poorly understood and different tools (and manual linking) set them differently. They don’t appear to contain meaningful values for proper function, but are generally set as follows:

data1: Target device category
data2: Target device subcategory
data3: Target device firmware version

The default controller link from each device back to the modem in my case has these values:

data1: 0x03 (category: network bridge)
data2: 0x11 (subcategory: 2413S PLM)
data3: 0x9E (firmware version of the PLM)

From my research, it sounds like each device just looks for a controller link in its database corresponding to a status event from a specific device/group and the data1/2/3 values in the actual controller link aren’t important. I’ve seen them set to 0/0/0, or some values set to 0, or data3 set to the group (which is already present elsewhere in the link record).

The data fields are important in responder links because they tell the device what to do when it sees an event from a device that’s acting as a controller for it - on level, ramp rate, etc.