I installed the Insteon PLM integration a few weeks ago and have been slowly moving devices over from an ISY. When I added a leak detector, while the device added, the integration didn’t know what it was. Found that both the cat & subcat were zeros in insteon_devices.json. Edited that to the correct values for the leak detector, and after a HA restart the integration recognized the device correctly and exposed two sensors, heartbeat & wet (but not dry/test?). Added a second leak sensor, and had to go thru same process. But they’re there. Wet sensor works, but not heartbeat.The heartbeat should be triggered once a day (in theory) by the Insteon device. I assume, like in the ISY integration, the Insteon integration will monitor the device input and trigger a problem if heartbeat is not seen for some time (maybe 48-72 hours since some times the triggers aren’t caught by the PLM). I’ve left the battery pulled for a few days now on one of them and have never seen the sensor change value - still says “ok”. Has anyone got this working?
I’m a recent convert as well, just last month. Rather than adding devices, I unplugged the fully configured PLM from eisy and plugged it into HA green. I watched the Insteon Integration page below Devices and Services below Settings and over time all the devices and scenes were discovered and added.
My Lovelace dashboards reported the leaks sensor batteries as good, but the device activity log for the device in ‘Devices and Services’ showed nothing.
Since I also moved over a yolink hub and devices, I took the opportunity to migrate all Insteon motion, leak and iolinc sensors to yolink.
Probably not the answer you were looking for. The rest, the imported Insteon switch devices, imbedded, outlet, plugin modules and scenes work great and all of my migrated automations that include insteon work as expected as well.
Thanks for the info. Decided against letting it import what Polisy had done, and instead used a backup PLM I had to create a second network during the transition. Wanted to see that it could be programmed from scratch. Have found a few things. For example, if the HA integration is used to create an Insteon scene, it has not added the cross links in the devices, so all comms go over HA. I’ve manually programmed them without a problem. Without that, the switch LEDs in a 3-way get out of sync, and multi-device scenes will go on or off in a daisy-chain fashion rather that all at once. Expect you didn’t see that as your links were already in the devices. Would be interesting, if you have leak detectors, to pull the battery in one for a few days to see if you’re notified. I worry about that as I kind of forget about them once they are in.
The iox internals for Insteon are more developed when it comes to deep Insteon tweaking / configuration in my opinion. I like the HA Insteon integration for operational things like on/off and controlling scenes with automations, and the HA Insteon Integration author has made it an officially supported integration and continues enhancing it. So I’m patiently watching that while keeping my eisy handy for making changes when needed.
The heart/soul of the Insteon network is in the PLM’s ALDB (All links database). In HA, the PLM’s ALDB is the system of record, and in the UDI products the system of record inside iox, and iox is better and managing the details.
My approach is when I need to make insteon config changes, I get the eisy back ou,t plug the PLM in there and make them so they update the ALDB and devices, then reconnect to the HA
That’s another reason i kept the scenes originally created by eisy in the PLM/ALDB.
ONE REALLY IMPORTANT NOTE ABOUT SCENES: When you start using scenes in your HA automations, DO NOT create/use HA scenes or you’ll lose Insteon’s instant scene responsiveness and get ‘pop corn’ lighting when you turn on a scene with HA. There’s a specific YAML call to use for Insteon scenes You’ll see your Insteon scenes in the Insteon option when you first open Settings. Probably a discussion for another thread.
I only have a handful of Insteon switch installs left in this house and that will be the last time I hook up eisy to add them and not expecting use eisy again afte that. But it saved me reinstalling 40+ devices and 20+ scenes.
I’m standing up a few Matter/Thread experiments to see how it does for lighting. So far, Insteon lighting outshines the matter/thread products in scenes convenience, speed and controller independence HA and the PLM can die and my lights will still work.
I don’t have the Insteon sensors any longer, I sold/shipped them. My limited experiments with trying to get battery info failed and led me to moving all sensors off of Insteon and over to yolink where yolink shines. My suggestion for that is to go to the Insteon Integration’s page on HA, and go to its get hub and open an issue so the author sees it.
One other note, you will likely run into problems if you have 2 PLMs, one connected to a running policy and one connected to a running HA instance configured for the same set of devices. Insteon devices are not designed to integrate with more than one PLM.
The write up makes it sound like you’re keeping it separate, but that could explain some of the problems you mentioned with HA.
I don’t have the same device programmed on both PLMs, been deleting each device from ISY & factory resetting them before adding it to HA. Yes, that would be a conflict!
Been using Insteon for many years, and actually X10 before that, back to BSR days, so pretty familiar with it’s operation. Direct links between Insteon devices are the best! What you called pop corn is what I meant by daisy-chained. If you want to have fun, try an All Lights scene using HA scenes. I did, and in the time it took to activate all the devices, I could have walked the house and flipped the switches by hand.
Moved over to the Polisy the day the music died. It has worked well. Been running HA about a year now, up until recently using the ISY HA integration to the Polisy. That has been for the most part fine, but there are a few things:
- double-tap switch events do not show up in the ISY integration.
- ISY controlled scenes show up as switches in HA - so cannot be dimmed. Can work around that with automations, but direct control is cleaner.
- Now Polisy is going legacy, so time to decide …
Have to say ISY is mush more developed in handling Insteon links than the Insteon HA integration, but the nice thing in HA is it is easier to tweak the links.
Insteon Leak Sensors have worked well for me. Have programs in Polisy to support them, and even give reports periodically on them. Figured I’d ask here before going to GitHub in case I was missing something, but that’s next.
I have Insteon leak sensor heartbeats working now, but not using the heartbeat monitoring features built into the Insteon Integration… The heartbeat event is exposed to HA as “insteon.heartbeat_event”, but not only does that trigger when the leak sensor sends an actual heartbeat, it also triggers about once an hour when the Insteon Integration does a check if it’s been too long since the last one. That seems to be the source of the problem that the integration will never flag a loss of heartbeats. I have not figured out what the problem is with the internal heartbeat logic, but I did find the code in heartbeat.manager.py that causes the triggers. I’ve commented that out and now that event only fires when the sensor sends a heartbeat. That has been working well with automation monitoring it, and in fact doing it this way I can easily access & display on dashboards the last time the heartbeat triggered. E.g.:
My question is: can anyone confirm if the internal heartbeat function in the Insteon Integration is working for them? I.e., pull the battery on a sensor for 36 hours or so and see if the heartbeat sensor ever shows not OK. If no one can, I think I will propose that code be commented out until the function is looked into deeper. It’s a pain as it is, as I have to overwrite the .py file with a modified one every time there is a HA update.
quite interesting to hear from others still using insteon in home-assistant.
clarification for @SCHibbard regarding scenes and linked: if you have “cross-linked” devices (e.g. multiple switches in virtual n-way configurations) and you use insteon scenes and you intend to have the cross-linked switches remain in sync with each other, then you must include the full set of all cross-linked devices in any scene that changes the state. this is true of the insteon integration or any other system you can use to control insteon devices.
let’s say you have switch-a which is actually wired to a light bulb and switch-b which acts as a “slave” switch. let’s assume you want these to remain sync’d so they behave similar to what we’d expect from a hard-wired dumb switch in a 3-way circuit. so you “cross link” the switches, meaning you have a link where switch-A is the controller and switch-b is the responder and vice versa. now let’s say you want to have an insteon scene such that the light bulb attached to switch-a turns on at the same time as some other lights/devices in your house. you must include both switch-a and switch-b in your scene if you want them to stay in sync with each other. otherwise, e.g., turning on only switch-a with a scene command will NOT result in switch-b turning on, nor is it the case that switch-a will send an extra command to make this happen. “cross linking” only makes it so that switch-a can act as a controller for device-b when operated from its physical controls (and vice versa).
many find this unintuitive, but X-linking does not make it so that switch-a receiving an “on” command (e.g. from HA, whether its a “direct” command or a group/scene command) will automatically cause switch-b to also turn on. if you want “sync’d” behavior (and it sounds like perhaps you do), you either need to ensure that any scenes affecting switch-a also include switch-b OR you need to arrange to send separate commands to switch-a and switch-b (such as might be done for example by having an automation in HA that forces the devices to stay in sync).
reply to @SCHibbard on heartbeats: i have lots of leak detectors (model 2852-222). heartbeats have never seemed to function for me in the “obvious” way.
expected: heartbeat entity has state “ok” when heartbeat has been received within last . heartbeat has state “problem” otherwise.
what i see: heartbeat stays “ok” 100% of the time.
i have the same general problem with hidden door sensors (model 2845-222) but with different details (they have both “battery” and “heartbeat” entities - neither seem to work) and likewise with motion sensors (have “battery” but no heartbeat). none of these have ever worked for me.
i would very much like for this to work better. about a year and a half ago or so, i had opened several related issues but afaik, they all got closed after a few months of being ignored. i believe this was during an interval when the primary integration developer went dark for a while.
anyway, i still have a lot of battery-powered insteon devices in my network and no reliable way to monitor them for low-battery. i am willing to help/develop/test.
One thing I found is that I had a working insteon leak sensor with a dead battery and getting “Ok” on dashboard for it’s battery.
I was at the point of swapping out all insteon sensors so I didn’t pursue it that hard… but I would add that as a test case if you’re going this direction.