I am currently working on greatly improving the support for the ISY994 Insteon controller in Home Assistant. In 0.60, my improvements to leak and door sensors (aka, they work!) went out, and now I am working on a fairly large refactor of the ISY994 component to aid in further development.
The biggest problem with working with the ISY994 is that it supports an enormous number of devices, many of them discontinued. Even more when we start considering the Z-Wave support, which I don’t use. And then there are an infinite number of potential devices available with the new Node Server support in the 5.0 firmware.
So I would like to use this thread to hear from other ISY994 users. There are two things I would love:
Tell me about how the ISY994 integration works for you, good or bad. What’s missing? What’s working well? What do you like or dislike about it?
It would really help me if you would be willing to dump your nodes endpoint for me, so I can see what systems with other devices look like. To get this, open http://isy/rest/nodes and save it out to a file and attach it here (depending on your network you may need to change isy to your isy’s IP address, but that URL works by default.) You should double-check that it doesn’t contain any sensitive information. If you don’t want to post it publicly and are willing to email it, you can send it to [email protected]
At the end of all this, I want the ISY994 component to be one of the best possible choices for new people to use if they are setting up whole-house lighting control that is never required to phone home to a cloud service.
I have changed my ISY configuration a lot to work around Insteon’s inability to send dim commands to scenes and ISY not willing to “fake it” in their api. I expose only the device to HA and then I have some programs in ISY that “fixes” on states for the scene. That is one of the reasons in my nodes output you’ll see a lot of “hides”.
I saw on github some changes in progress to expose the ISY control events. That would open a lot of things up and give the potential to move more things away from ISY programs.
The 0.6.0 version broke my leak sensors and smoke alarm. My guess is that the entity names changed and I need to fix my configuration files.
Are the new leak sensors named xxx-Dry, xxx-Wet, xxx-Heartbeat (like the isy994i shows) or just xxx? My old sensor names were just xxxdry, xxxwet and xxxheartbeat in my configuration files.
My understanding from the new documentation that there will now only be 2 leak sensors - 1 for the wet/dry and 1 for the heartbeat (I use both in my automations).
Do leak sensors still have the “switch.” prefix on them?
Do you support smoke alarms/sensors? Previously they looked like 7 switches. You should see them in my nodes.xml file.
One feature I’d like to see is that, anything that we “hide” using the hidden_string is not imported into HA at all. Not sure if that would break some users. We might need a different option, like “ignore_string”.
@wrique: thank you for the info! I do not have any smoke detectors or bridges, so this should help me get them better supported. Right now I have no idea how they may or may not work in Hass but I’ll work on it!
As for leak, door, and motion sensors in 0.60, yes they will be binary_sensor now, since they can’t actually be switched. The ISY994 docs page explains some of the quirks in the device names: the leak sensor will use the ‘-dry’ node’s name, which I recommend renaming in the ISY because it’s confusingly backwards.
Could you share how you were working with the heartbeat nodes pre-0.60? As far as I understood, it was impossible to use them effectively before due to them never actually changing state. The new heartbeat device in 0.60 will actually switch to “on” (and the UI will say it’s an empty battery) when the heartbeat is missed.
I was just displaying the status on the HASS page of both the sensor wet state and the heartbeat state. My isy994i actually does the simple automation - send me a text whenever the wet “switch” is on or the heartbeat “switch” is off. And, yes, the heartbeat did change state if my isy994i couldn’t communicate with it any more. It aslo seems to change when the wet sensor fires off and goes true.
So if my isy994i name shows: “Kitchen Sink-Wet” and my old HASS name was “switch.kitchen_sinkdry”, then my new name will be “binary_sensor.kitchen_sinkdry”?
Sorry for the confusion, but getting the entity name perfectly correct for 15 leak sensors takes time.
If your code can’t parse the isy994i node type, like the smoke sensor, why not just create a switch like before? It would help us that are heavily using this component to be backward compatible even if it is entirely not correct (i.e. it is not really a switch).
I renamed my “switch.kitchen_sinkdry” and “switch.kitchen_sinkheartbeat” to “binary_sensor.kitchen_sinkdry” and “binary_sensor.kitchen_sinkheartbeat” and I now see them in the UI, but both states show as “unknown” (see pic). And when the state changes in the log it also shows up as unknown:
Ah yes - that’s a bug in 0.60. I noticed it a few days ago and plan on fixing it for the next release. The sensor will stay Unknown until a leak is detected, at which point it will switch to “On” (and say moisture detected in the UI). Any automations that trigger to: 'On' will work just fine, but the display is annoying.
You should be able to fix this yourself by pressing the button on the leak sensor, which should send a Dry signal to the ISY and then it’ll properly say dry in Hass.
Yep, that’s because the smoke detector is, indeed, a binary sensor. Unknown values here are true: the ISY doesn’t know the state, so now Hass properly reflects that. This is the case for most binary sensors in the ISY: until it gets an on or off event from the hardware, the ISY can’t know what state its in (in the ISY admin panel, the state shows up as blank.)
(I’ll probably pick up a smoke bridge so that I can figure out how to make these devices all show up more logically in Hass, if they still make that device.)
As for the leak sensors - they turn “On” when there is a leak. This is to keep consistent with all moisture sensors in Hass, and so that the UI will actually say “Wet” when the device is “On”.
Thanks for your work and quick responses. I got everything renamed and it is working good after using the button to set the state. I have one leak sensor that sometimes loses contact and its heartbeat is showing “Low” but the others show “Normal”. The isy admin app says that the heartbeat is “On”, so that seems a bit strange. I’m not sure what “Low” means.
You’re now seeing Home Assistant work better than the ISY does (out of the box, that is)!
The quirk about the heartbeat node is that it ONLY sends “on” commands, and it sends them once per day. That means in the ISY, the state will never actually change to Off! The only way to make the heartbeat nodes useful inside the ISY is to create a couple programs that watch for the ON command, and then wait ~25 hours and do something if it’s missed. This is what I set up for all of my leak sensors and it’s definitely cumbersome when you have several of them.
Home Assistant on the other hand is now doing it internally: it watches for the ON command, and if it doesn’t get one for 25 hours, the binary sensor switches to “On” (“Low”). You can then set up your own automations to notify you, or if you expect them to sometimes go silent, you could have it only notify you if it’s bee “Low” for a few days or something.
Thanks, good to know. I just also noticed something else. When I restarted hass, the states all went to “Unknown”. Are the states getting saved anywhere? The isy app still has them correct.
My biggest annoyance with the ISY is the inability to brighten/dim a scene. One possible thought would be if a scene can be imported as a light, and either have HASS use an internal variable to hold the brightness value, or have a user set the “primary” device in a scene and automatically copy that brightness variable to others in the scene. This would allow automations to more easily change brightness, maintain the ability to send native insteon bright/dim commands from switches and keypads (HASS today can’t control individual keypad buttons, so an insteon scene is required, killing the automations others have posted in the forums), and work with the emulated hue platform to allow Alexa to brighten and dim ISY controlled scenes.
One of the top items on my list is to add special ISY-specific services you can call to issue the bright/dim/faston/fastoff commands. So you’ll be able to do this, albeit less “invisibly” than your proposal of faking it as a light component.
Excellent news. One other thought I had. I currently use ISY scenes with no responders as a trigger for automations to turn my Philips hue lights on and off (since Philips can’t seem to make a normal light switch). It’d be awesome if HASS could capture in real time the brighten/dim commands my Insteon switches send to these scenes to automatically brighten and dim my hue lights. I have written an automation that will pull the brightness level whenever it changes and push that to the hue lights, however, it only changes after you stop pushing the insteon switch. Would be great if it occurred in real time like insteon lights brighten and dim.
