Same thing here. I reverted back to 0.5.1 and all is good again. It appears to be all of my battery devices that have the issue. The mains powered devices have a extreme lag in performing any action.
I had the same thing happen to my system but i am trying to push through. I have restarted a couple of times and my devices are starting to come back but it has been hours. OpenZWave kept most of the names but the OZWAdmin lost all of my device names.
I have some other strange issues with setting config parameters for my Aeotec Nano Switches. Config param 101 is supposed to be set to a decimal value that is converted from hex. Iāve calculated this value and Iām publishing the following to MQTT:
OpenZWave/1/command/setvalue/
{
āValueIDKeyā: 28428973849182227,
āValueā: 2369280
}
It appears that the value string is adjusted to a different value (768) when written. This parameter is for what is reported to group 1 in the metering report. It has to be the specific value and it appears something is adjusting it to another value. The new service in 0.113, OZW-Admin, and directly publishing to MQTT all exhibit this behavior. Anyone else see this or know how to work around it? The value is within the min/max values of the parameter in MQTT.
Keep pushing. I wish that I could tell you what sequence of events finally got my network back up again, but after a day and a half I was, quite frankly, just flailing in the wind. The only thing I can say for certain is that MQTT is a big part of the issue. Possibly helpful tip - whatever I did didnāt appear to be successful at first. This happened to me once a couple of weeks ago as well. I got distracted by something at home and at some point later I began receiving Pushover notifications for some Z-Wave triggered events.
How did you get a value of 2369280 (0x242700)? If I am looking at the correct document (ZW116?), the maximum value would be 15 (0xf), which would enable all 4 reports.
I forgot to include ādualā in my post. I have the dual nano switch for two switches. This has more configuration values in value 2 and 3.
@freshcoast Sorry to bother you again, just wondering if you know where/what that bug is? Someone earlier mentioned that you reported and/or fixed the bug in the past.
Thanks again for the help!
I think you can use this sheet to get the values.
https://aeotec.freshdesk.com/helpdesk/attachments/6103460023
I found it later, the link in the tech docs to the ZW132 is wrong, you have to go down to find it.
And yeah, the max value for the 2nd and 3rd MSB is 27 decimal, which is 0x1b (0b00011011).
Iāve always used their excel sheet to configure the reporting parameters
1 Like
BTW, that configuration option would be a good candidate to become a BitSet value type.
Thank you!
donāt curse at me 
FWIW, I just upgraded to 0.5.2 and everything lined back up for me.
I havenāt set custom names or anything (yet).
This upgrade was actually pretty smooth for me compared to previous versions as I didnāt have to mess around with a bunch of restarts of MQTT and OpenZWave.
Update - my Ecolink motion sensor (non plus) seems to no longer be communicating. But my Honeywell thermostats appear to be communicating without issue.
Well it was a blissful 12 hours, but my network is belly up again. This has unfortunately gotten to be more than what I can handle. Iām going to have to resort to either HS4 or an old Vera Edge I recently discovered at the bottom of a drawer for my Z-wave duties for perhaps the next year or until things smooth out a little.
Because the cache file versioning changed, so the entire thing is re-generated. Losing the cache file means losing the names. A good reason to stick to HA for naming. https://github.com/home-assistant/core/issues/38068#issuecomment-663305036
Regretfully, I could not agree more. Response time with Vera Edge turned out to be much better that Zwave dongle.
Been watching https://github.com/OpenZWave/qt-openzwave/issues/60, but Iām unclear: are double-tap events (via the Basic Command Class) still not supported? I have lots of GE switches and being able to double-tap them in a way that HASS recognizes is the final things standing in my way of a full cutover to OZW.