Zwave OZWlog working, but integration/automations not responding

I am new to hassio, had my RPi running fine a few days with a Nortek HUSBZB-1 zwave/zigbee radio, and a couple of zigbee and zwave+ devices. The zigbee stuff is working fine. A zwave+ plug I have is also working great. I’m having problems with an Aerotec zw089-a battery door sensor. It was also working fine, until I (for some dumb reason) tried to remove and rebind it. Now I can’t seem to get hassio to respond to with any state other than initializing or sleeping.

The weird part (to me) is that when I tail the 0zw log in hassio, the darn sensor is showing up in the logs as if it is working fine still. Regardless, the overview page icons and tabs for the binary sensor are not updating. Automations I did in nodered don’t respond to it either. It’s as if it is a failed node.

I’ve tried many things to fix it. Even reinstalling hassio fresh, I was a bit surprised after reinstalling hassio to see the devices all still paired up. So I researched and tried using zensys tool to remove nodes, factory resetting the plug and the door sensor, rebinding… nothing… still the sensor looks good in 0zw logs (values changing properly), but it seems stuck initializing or sleeping to the rest of hassio. The sensor’s entity info shows normally as well (not failed, battery 100%, etc). I’ve been trying to solve this for 2 days straight and ran out of options… so came here fingers crossed someone can help.

Thanks,
Kevin

Does the device have a reporting mode (basic, hail, etc) or other configuration options? I have some door sensors I had to set to basic reporting before the value would update properly in HA. That was on a fresh pairing of the device though. The reason the devices showed up in HA even on a fresh install is probably because the device was still paired with the zwave controller. When HA booted up with the zwave component, it read the controller and built a device list of all the nodes from the controller. The only other thing I can think of why the device isn’t updating is if for some reason it’s a Zwave plus device and requires a network key be set and be paired securely and not just a normal device pair.

Thanks for the quick reply squirtbrnr. Yes I’ve been using secure add for all of the zwave devices. Now I feel like a fool… I just found the aeotec website troubleshooting guide for the device:

I sent a 121 = 272 (report mode = basic and binary) with hassio ‘zwave node config parameter’ for the door sensor. When I hit the send command button and the wake button on the sensor at the same time, and the darn thing started to work like before!

I learned that in my frenzy of configuration the other day, I used options 1 and 3 playing around with it. Hopefully my post about this helps someone else starting out. I should have been more patient when it came to adjusting parameters and testing. Lesson learned… moving on to expand the system. :slight_smile:

Battery powered devices spend most of their life asleep, so the states of the zwave entity you describe are perfectly normal.

However, if you’ve removed and added it, the entity IDs may have changed. Check that you’re looking at the right entities - in particular the door sensor itself will be a binary_sensor or sensor entity.

Thanks for the reply Tinkerer. I am learning a lot about ha, zwave, and zigbee in this process. I have the entities all sorted now… the issue was I accidentally turned off the sensor binary reporting. It took a day for me to figure out I did that and turn it back on to fix it (very frustrating day… I felt kind of heroic when I stumbled on the fix lol).

Hassio is doing a great job of updating the ui so the removed entities don’t stick around. On a side note, the removed entities still do appear in the zwave integrations page. I have to manually delete instances of those entities in the device registry and entity registry files to get those to dissapear. Using the zensys tool I can see hassio is managing nodes on the zwave stick properly… just not clearing them out of integrations upon removal.