Addons: Leviton DZPA spamming label state to OZW after update to 0.5.2.

[sheepster-9k]

The problem

Latest Open Z Wave integration update results in abnormal behavior with Leviton DZPA1-15A switch. On switch, log is showing Value Refreshed: Node (X), Instance 1, Label Target State 6 or 7 times per second according to the log. MQTT is receiving these messages as well. Hundreds of packets per minute.
Have tried with 3 other DZPA1-15A's, same behavior. Behavior only observed when switch is in one state vs the other, messages stop when switch is switched. Tried to see if there were any settings regarding polling however there appear to not be.

Everything worked properly in 0.5.1

Environment

System | HassOS 4.11
Deployment | production
Supervisor Version| 229
Core Version| 0.113.3
OZW Integration Version| 0.5.2
MQTT Version 5.1

Problem-relevant configuration.yaml

Integration is not in config

Traceback/Error logs

I have no errors, however below is the log from OZW switching from off to on twice waiting a couple seconds in between each actuation.

[11:50:09] INFO: Starting ozw-admin...
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
ozwadmin: Settings Path is at "/root/.config/OpenZWave/ozw-admin.conf"
ozwadmin: Checking "/data/ozw/config" for manufacturer_specific.xml
ozwadmin: Checking "/data/ozw/config" for options.xml
ozwadmin: DBPath: "/data/ozw/config/"
ozwadmin: userPath: "/data/ozw/config/"
ozwadmin: Settings Path: "/root/.config/OpenZWave/ozw-admin.conf"
ozwadmin: Using Saved Network Cache Size: 1000
QT_MESSAGE_PATTERN: %{backtrace} is not supported by this Qt build
md5-a3f18dc6eece1ca6311f2b38ff98d1b4

Additional information

Reverted to a backup with 0.5.1, fully updated everything but OZW, working fine again. Switches return a single state change message on change. Fairly sure it's something in 0.5.2

[sheepster-9k]

Update: transitioned over to ozwdaemon in a docker container given I had no snapshots to fallback on, same behavior. I cycled backwards through the builds to find one that worked, problem stopped at build 152.

[mcgibbaa]

I had the same behavior on the DZ15S switch.

[l3arcf]

FWIW, I tested with the new HA core (0.114.0) that stated "unnecessary polling of devices has been reduced". I just wanted to check if that potentially fixed this issue, or worked around it, but it doesn't.

[kpine]

This is an upstream OpenZWave issue, not an addon one. See https://github.com/OpenZWave/qt-openzwave/issues/146 and https://github.com/OpenZWave/open-zwave/issues/1321.

However, the addon could choose to revert to an earlier version of code that does not have the problem. Doing so would possibly wipe the ozwcache.xml file though, which is very upsetting to users. I have not tried it recently, but upgrading from older ozwdaemon to the latest does wipe the cache.

Build-150 of the standalone container is the last stable version at this point, depending on what kinds of devices you have (download it while you can). Build-152 includes an incompatible version of QT5 and may or may not have some stability issues, YMMV.

[whitepa]

Just wanted to mention that this PR by @l3arcf fixed this issue for me: https://github.com/OpenZWave/open-zwave/pull/2370

[andyf101]

I can confirm that I too have this issue with 0.5.2 after trying to switch from the traditional Z-Wave implementation in HA. Because I cannot install a specific/previous version of the Hassio Add-On I'm unable to use OpenZWave at all, the messages cause my Z-Wave to come to a halt.

[l3arcf]

PR was merged. I pulled the latest docker image and my system remains stable. IMHO, this issue is resolved in openzwave now. Possibly something needs to be updated in HassOS, but my OpenZwave (beta) installation is 100% now.

[OverZealous]

IMHO, this can be closed.

Don't we need a supported way to upgrade the Open-ZWave add-on before this is closed? I'm not sure how to upgrade the image used for OZW with the add-on.

[l3arcf]

Opps, sorry @OverZealous , you are right. I updated my comment above when I realized the error of my ways.

[GeekGoneOld]

Any suggestions as to what those of us using Home Assistant install of HA (i.e. image install) can do in the meantime? The AddOn is at openzwave version 0.5.2 and has been for a couple of months. Can we edit something and build the AddOn easily (and safely)?

[l3arcf]

There is a git for the zwve2openzwave add-on here https://github.com/hassio-addons/addon-zwave2mqtt. Assuming that's the version you're after, it may be as simple as bumping the version used there. Interestingly enough it looks like the most recent change was at about the time this issue was fixed, so it may have just been missed. I assume you'll get better advice on that repo!

[OverZealous]

@l3arcf That's for a different add-on, which is very similar, but not the "official" Open-ZWave (beta) add-on, which is hosted in the main hassio-addons repo. Supposedly, this is going to be the recommended (or only) solution for using ZWave with HA in the future at some point. One of the primary reasons stated for this add-on was making it easier to update the Open-ZWave library without depending on a HA core release.

A lot of us jumped ahead to start using it now (partially for support in finding issues, and partially so we wouldn't have to migrate our network in the future). Hence why we're hoping that the beta addon gets a version bump to include this fix.

EDIT: That being said, there's already a PR which should take care of this. :-)

[l3arcf]

Right. I guess this is the one time I'm lucky to be on hassio core in my own docker. Though, most of the time the grass seems greener for the addon folks. For the record, I think running core and managing my own docker images will continue to be supported. On this 'platform' I too am using OpenZwave (beta) and am able to select my version of openzwave and mosquitto.

This issue was a big blocker for a bunch of folks so getting the add-on tested and bumped to this version will help many people I think. As always, based on your link, there are other things at play too.

[l3arcf]

@GeekGoneOld, I feel bad for suggesting this was fixed 3 weeks ago, but noticed that there was a new version 3 days ago now that appears to include a version of OpenZwave that has the fix. So... can someone confirm if this has been resolved with the new version, or still exists?

I'm also personally interested in understanding the lag of up-stream fixes making it to the add-on, more so in beta software. This is not a criticism at all, just informational.

[Ambrotos]

@l3arcf I can confirm that this is fixed by updating to 0.7.0 of the "official" OpenZWave plugin.

Just FYI, there's a conversation about this in the HA community forums as well https://community.home-assistant.io/t/openzwave-beta-leviton-dz15s-flooding-zwave-network/217842/9

[GeekGoneOld]

@l3arcf Don't be silly. Your comments were very helpful and appreciated.

As little as I know about the lag (some of which may be inaccurate), in the case of the add-on OpenZWave (not the integration OpenZWave (beta)), the code contains OpenZWave/open-zwave (not part of HA) code. Since it is an add-on, it is updated separately from the HA core updates. after V0.5.2 of the add-on, HA developers changed to incorporate a new (buggy) version of OpenZWave/open-zwave and their simple solution to correct that was to go back to 0.5.2 until OpenZWave/open-zwave was fixed (beyond their control). A good decision at the time. After the buggy OpenZWave/open-zwave was fixed, it took time for HA to test and trust it and then to incorporate the new (fixed) code into the add-on. The lag, therefore, is partly caused by waiting for a third party (OpenZWave/open-zwave), partially by testing third party code and partially by add-ons not getting as high priority as core.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.