I’ve set up the ISY994 integration in HA. Everything works as expected when Insteon devices are controlled from HA but not from the switch itself or the ISY. For instance if you turn on a light using the Insteon wall switch, HA doesn’t see the status change and so the light still shows as “off.” So then if you want to turn off the light within HA, you have to first turn it on then off.
Does the ISY integration support responding to switch status in real time, and if so, how is this configured?
Instant status works fine for me when controlled manually from the device, whether it’s a wall switch, keypad, or remote. Maybe go into Developer Tools -> Events, listen for isy994_control, manually flip and switch, and see if you get a DON or DOFF event? I get an immediate event and the state of the switch flips in Dev -> States for my in-wall Insteon dimmers (just checked).
What firmware version are you running on your ISY? I’m using 5.0.16C.
Are you using the built-in ISY994 integration? There were custom_components floating around for a while, but the built-in version is now up-to-date and you should be able to get rid of the custom_component. You may still be using an old custom version that doesn’t play well with the new PyISY.
My ISY is running 4.6.2. I installed the ISY integration using Configuration > (+) Sign > and chose Universal Devices ISY994 - there were no others so I think I am using the built-in one.
I did the Developer Tools test, no events were detected. So either the ISY is not sending events or for some reason they are not getting onto the HA event bus. Thanks.
Does anything work? Do you see the entities from the ISY?
What version of TLS is your isy running?
I haven’t been on the 4.x versions for years so I don’t know if it has been updated. Just a thought that maybe you chose the wrong version in the integration setup possibly?
Yes, all 64 Insteon devices (total of 198 entities) ISY were discovered when I first added the ISY integration. They all appeared in the Overview panel and I can switch/dim things from HA. They just don’t update when you use the actual wall switch or keypad.
I can’t tell which version of TLS the ISY is running and since the devices are discovered and controllable from HA this would seem to be a non-issue. However it turns out the ISY’s certificate expired in 2018. I guess it’s possible this breaks entity updates from the ISY to HA but doesn’t affect discovery or updates from HA to ISY…?
Strangely this just happened to me starting last night. HA “sees” all the ISY entities, and I can control the ISY entities from HA, but HA doesn’t receive any event notifications from the ISY. If I flip a switch I see the state change in the ISY Admin Console, but that state change is not reflected in HA. So this is not a PLM issue. I’m also not receiving Z-Wave update events at HA, either. So this is clearly an issue between ISY and HA.
I had already turned on extra debugging for the ISY and I’m not seeing anything come in, so either HA stopped asking for it or the ISY just stopped sending it.
I am running 5.1.0 on the ISY and 0.114.4 on HA. I am not using TLS on the ISY.
Restarting HA did not make a difference. I plan to restart the ISY shortly and will report back.
So I restarted the ISY, then I had to execute the isy994.reload service on HA, and now I appear to be getting updates again. I hope this is not a frequent requirement.
How do you execute the isy994.reload service on HA?
UPDATE: Well I figured out to use the developer panel “call service” button. There was no confirmation that the service actually ran. My ISY entities are still not updating so I may try updating the ISY firmware.
Did you solve this? I am having issue. I monitored the isy994_control I am getting events from node servers and other data on the Insteon but no events from Insteon devices like flipping a switch.
It turned out some of my Insteon devices were updating and some were not. I realized the ones that weren’t updating in HA were also not updating in the ISY console. This suggested the problem was not with the HA integration but the Insteon network itself.
Doing a “Restore Device” for each non-updating device fixed the problem.
FWIW I’ve found the Restore Device command will fix many odd misbehaviors in an Insteon device.