@roborob Sorry for the delay. There are no ‘wet’ or ‘dry’ messages being received by the PLM. You have the PLM linked to group 2 as a responder which should allow the PLM to receive wet messages but no messages are being received. I would also think you would need the PLM linked to group 1 as a responder but that record is not there. I am not sure this will solve the issue but you can try this (it won’t hurt for sure).
Log into HA and navigate to “Developer tools” -> Services (that is the area at the bottom of the screen and the icon to the far left that looks like at radio giving off a signal).
From the “Service” pull down menu select “insteon_plm.add_all_link”
In the “Service Data” section add the following {"group": 1, "mode": "responder"}
Press the “Call Service” button to start the service. (This will put the PLM in linking mode)
Press the “Link” button on the leak sensor.
This will create a link with the PLM as a responder to group 1. Again, not sure if this will help but it won’t hurt.
I’ll give that a try as soon as I get a chance – probably later today.
BTW, It didn’t get in group 2 intentionally: I’m not even aware how I would do that on purpose. What happened was (I think) that after an update of the insteon components a few versions back, it just appeared there alongside another version of itself. In retrospect, I should have probably unlinked and removed all the existing insteon devices before a major update, but that thought didn’t occur to me a priori.
I tried the procedure from teharris1 post, and after I pushed the button in step 5, the leak sensor blinked promisingly.
Well, I just now put it on a damp rag to do a functional test, and again the sensor’s LED blinked rather profusely, something it hadn’t been doing before. On the Home Assistant dashboard, the water drop icon is no longer “slashed out” and the details show it’s “wet”.
However, I still don’t get anything in the log when I try:
cat /config/home-assistant.log|grep -E ‘32.1D.21’
But as I wrote above, the state on the dashboard is changed and that’s what I was hoping to see.
ed. The sensor’s been dry for a couple hours now, but the state on the dashboard hasn’t changed. Is home assistant waiting for the “dry” signal that the troubleshooting section of the manual seems to indicate will never come?
Problem: Leak Sensor can turn responder on, but
not off
Possible Cause: Leak Sensor is not designed to turn off
responders. This prevents warning lights
or other leak indication devices from
turning off in the event the leak dries.
Solution: None. As designed
If that’s the case, what do I do to reset the state in Home Assistant. If the sensor had turned on a lamp or a blower, I could turn those off from the dashboard, but what about the indicator itself?
Ok, was able to reset the dashboard state of the leak sensor to “dry” by restarting Home Assistant. I guess it must of reloaded all the insteon states on restart. Is there a less drastic way to update the dashboard icon for the leak sensor after the situation has been addressed?
Yes, it would reset the state on reload. I am guessing that the reset on a ‘dry’ message is not being seen. Let me do some more testing. By the way, you should repeat the process above for a ‘heartbeat’ but with group 4 ({"group": 4, "mode": "responder"}) This may help but I think it only sends a heartbeat once a day.
I see some changes with the latest version. My Insteon motion sensors now not only appear as motion sensors but also (1) a gear-like thing – that’s apparently a sun and I presume to be the state of the light sensor on the motion detector and shows a status of “On” – and (2) a battery icon with a status of “Normal” – perhaps this would change state if the battery were low.
The new items show up on the Home Assistant Overview page with same Insteon address of the motion sensor, but with “_2” and “_3” appended.
Any official word on how to use these new items?
I also noted that X10 support appeared a version or two ago. Thanks! (Unfortunately for me all my X10 devices are on the other leg of my house wiring, me having assumed that I’d never have to worry about X10 working on the PLM).
@roborob, yes those are the other sensors available in the motion sensor. The battery is (hopefully) obvious and the sun like thing is the light sensor. It senses light and dark. I cannot configure it yet but you can (using other software) set the light sensitivity. Working on an interface were these settings can be made right in HA.
I have recently moved over from openhab, because the integration you have done with insteon. It is amazing, thank you for the work!! I have all 29 of my various devices working flawless. I was able to monitor the door sensor battery in hidden door sensor in openhab. Can you explain how to get it going in homeassistant? I have a motion sensor and it is reporting the battery on group 3 just like this post suggests. I have tried different groups to get the battery for the door sensors “address: 1a2b3c_2” etc. and it is not reporting back anything. Are these battery devices different?
Thanks again on the work! You made it worth the hassle to move over.
Wow, thanks for the quick reply, it’s all good. That and the “fast-off” option are the only features I miss from Openhab. But the door sensor and keypads being responsive enough to trigger devices and automations is worth the switch! I appreciate the work put into this component, it shows. This component is why I switched.
On a side note, the “fast-off” would be a good future feature as well. I used “fast-off” to control under cabinet lights. The kitchen switch kicked the lights on. And an automation also kicked on mqtt under cabinet lights. Turning off the switch would leave them on (ambience lighting). Double taping the switch “fast-off” would turn the under cabinet lights off too, with an automation. Useful for having two switches in one.
This topic is admittedly pretty old, but I’m new to HA. I’m a long-time Insteon user looking to ditch my hub and most of its associated devices in favor of HA running on RPi. In fact I would’ve fully walked away from Insteon by now except that I’ve not found anything in the [ z-wave | zigbee ] world to match the design, feel, and responsiveness of the Insteon mini-remotes.
So my device needs are quite slim at this point: I want Insteon on/off mini remotes to trigger HA automations.
Q: is it the case that once I get an Insteon 2448A7 USB dongle into my RPi, the remaining work is:
add relevant lines to my configuration.yaml file
join my mini remotes to the USB dongle and vice versa
set up new automations with event handlers listening for insteon.button_on and insteon.button_off
If so, is Insteon missing from my manifest of configurable HA integrations simply because I don’t have the USB dongle installed yet?
I’ve successfully integrated an Insteon LampLinc-style dimmer, via HA’s native support for my 2245 Hub, such that I can control the dimmer via HA and work it into automations.
However I can’t seem to trap events from my mini remotes. I can hear them chirp when I put them in linking mode and then call the HA insteon.add_all_link service, as if they’re responding to the link request. But that’s the limit of my progress.
Is that only possible via (a) using a PLM instead of a hub, and/or (b) running HA on something other than hass.io on a Raspberry Pi (so that I can install certain Python libraries)?
I’ve not seen anything come across the HA event stream of the type insteon.button_on, even after attempts at pairing. So I can’t set up automations as you recommend.
I suspect I need more progress on the pairing side before mini remote events will pass through HA via the 2245 hub.
Also, with the insteon component in debug mode, if you press the buttons on the remote, the log with catch them. This will confirm the Hub can see the remote’s buttons.