OpenZWave dimmable modules don't report final state

[ve6rah]

The problem

When using OpenZWave with plugin dimmers or dimmable bulbs, and you turn them "on" or "off" from the UI the following sequence occurs:

1. user toggles switch in UI
2. dimmer starts dimming process
3. Hass queries the dimmer and gets the current state (partially dimmed)
4. Hass updates the frontend with the partially dimmed state
5. dimmer finishes dimming process
6. There is no 6, the frontend is never updated with the final state of the dimmer

Environment

• Home Assistant Core release with the issue: 0.115.0
• Last working Home Assistant Core release (if known): Never with this integration
• Operating environment (OS/Container/Supervised/Core): HassOS 4.13
• Integration causing this issue: OpenZwave
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/ozw/

Problem-relevant configuration.yaml

Traceback/Error logs

Additional information

This is not device specific as I've tried at least 4 different models of dimmer, my current ones are:

• Linear LB60Z-1 Dimmable LED Light Bulb
• Linear PD300Z-2 Plug-in Dimmer Module

In the old Z-Wave integration (https://www.home-assistant.io/docs/z-wave/installation/) this was solved by using device_config with refresh_value and a delay, however I don't see any way to do that on OpenZWave

[MattiasC]

I can add that the Qubino ZMNHDD1 Flush Dimmer is showing the same symptoms.

[FuzzyMistborn]

Have you tried enabling polling?

[MattiasC]

@FuzzyMistborn I have not tried that, not sure how to enable that.

I need to add though, that it would be better to not need to poll for values since that will increase network traffic always, when a single refresh_value would only create one extra read.

[FuzzyMistborn]

https://github.com/OpenZWave/qt-openzwave/blob/master/docs/MQTT.md#enablepoll

I have an automation/script set to run on restart that sends that to every device that I need polling on. I 100% agree that it's not ideal/annoyingly increases traffic but for now it's the only fix I am aware of.

[ve6rah]

@FuzzyMistborn a couple issues there:

1. I looked at the OpenZWave Home Assistant docs. Nowhere does it show polling as an option, nor do I see it anywhere in the WebUI.
2. Polling generates a LOT of extra ZWave (and MQTT?) network traffic for something that should be a matter of simply waiting a few seconds after a change and verifying the result (as was the case in the old Z-Wave integration)

(seems like more of a solution to 40187 than to this bug)

As for your github URL:

1. if this is needed for OpenZWave to function properly, it should be included in the Hass version and/or documentation
2. Looking at that link, I still don't have a clue where to start to actually enable that feature. Can you translate that in to a usable automation that I can understand?

[FuzzyMistborn]

1. OZW is still beta. We just got a UI in .115. Not everything is workable in a UI yet. If that's not acceptable to you, go back to the old integration. In terms of documentation, not everything should be documented in HASS since it's documented in OZW.
   1.5) I completely agree with you on the traffic issue, as I said, but the workaround is polling for now since not all devices supported the instant status reporting that is now common among Zwave devices.
2. Here is an example that I have in my script:

    - service: mqtt.publish
      data:
        topic: "OpenZWave/1/command/enablepoll/"
        payload: "{\"ValueIDKey\":1078558737,\"Intensity\":1}"

You need to get the ValueIDKey by using something like MQTT Explorer. Here's a discord conversation about it: https://discord.com/channels/330944238910963714/332357267364249621/744385440756269217

[ve6rah]

@FuzzyMistborn First of all, thank you very much for posting your current workaround (and in a way I can understand), I will be using that method for now until this bug is properly addressed. I will not however be closing this bug, as what you have posted is simply a workaround, not a solution.

I do however have to go on a slight rant here though about your point 1. No offence is intended here, however I see this attitude too often. Telling someone who is submitting a bug report to try to improve an integration that they shouldn't expect usable software because this is just the way beta works is a sure-fire way to never fix the bugs, and never get out of beta. I'm using this new integration, and submitting bugs, because I want to help this get past beta, and be usable for all. Don't belittle my observations as not relevant, work to improve the software!
I will be the judge of whether or not I'm willing to put up with the bugs to help improve things, but attitudes of "don't use it if you don't like it the way it is right now" are not helpful to anyone, and leave the distinct impression that there is no desire to improve and move beyond beta. Observations like that might be helpful in the forums for people who aren't submitting bugs but they are not helpful in bug reports.

Again, I do truly wish to thank you for your workaround. I will be using it until these bugs get fixed.

[FuzzyMistborn]

Sorry if I sounded like I was belittling your observations. I'm fairly certain that adding a button to enable polling is a known issue and something being worked on. My point was that you need to temper your expectations a little (there's nothing wrong with pointing out bugs/issues). I may have mis-interpreted your comments as a complaint, not a constructive comment. Sorry, I just see a lot of "UGH WHY DOESN'T THIS WORK RIGHT NOW."

[ve6rah]

Apology accepted.
I still do not believe that enabling polling is the correct solution here. I think enabling verified changes (I see "changeverified": false in MQTT, would setting that to "true" somehow be helpful?) or replicating the old refresh_value functionality may be more appropriate.
If, as you said, this is an already known issue, please link me to the correct bug and I'll happily close this one as a duplicate. (I didn't find anything in my search)

[FuzzyMistborn]

It's more known based on conversations I've seen in discord in the #zwave channel.

[ve6rah]

@FuzzyMistborn On a side note, is there a way to increase polling frequency? (Yes, I know the risks associated, but it's currently very long, it refreshes each of 5 devices once every 6 seconds, meaning that it takes a full 30 seconds between each poll of a single device)

[FuzzyMistborn]

You could try changing the polling intensity but I haven't done that so I don't know what it does.

[ve6rah]

Polling intensity specifies how often to poll. 1 means poll every cycle, 2 means every second cycle, 3 means every third, etc. 1 is already the lowest, so to go lower you need to reduce the interval between polling cycles.

[probot-home-assistant]

ozw documentation
ozw source
_{^{(message by IssueLinks)}}

[probot-home-assistant]

Hey there @cgarwood, @marcelveldt, @MartinHjelmare, mind taking a look at this issue as its been labeled with an integration (ozw) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[nemith]

This seems similar to the issue i reported in #36616

[ve6rah]

Ok, I now have a better workaround. instead of polling the light, we can do a refreshvalue via mqtt after each time we set it.
To accomplish this, I have a node-red flow which listens to the MQTT topic for the light (OpenZWave/1/node/<node_id>/instance/1/commandclass/38/value/<value_id>/), then has a 5 second trigger, and after that a 4 second delay and then publishes {"ValueIDKey":<value_id>} to topic OpenZWave/1/command/refreshvalue/ (5 second trigger just prevents an infinite loop, 4 second delay is the experimental time it takes for the light to fully transition)

[kpine]

I still do not believe that enabling polling is the correct solution here. I think enabling verified changes (I see "changeverified": false in MQTT, would setting that to "true" somehow be helpful?)

If the dimmer's multilevel switch command class is >= V4, then OZW already will refresh the value until it reaches the target value reported by the switch.

If the dimmer's multilevel switch command class is < V4, then yes, you can setting the VerifyChanged compatibility flag to true in the device XML file to force OZW to refresh the value until it reaches the target value. Example here. It works for my GE switch, but there are some quirks (see issue linked below). Since you are using the addon though, it is a difficult workaround because the addon does not provide easy access to the device files. I know some have done it, but as a container user I don't know the details.

In both cases, OZW is polling the value during the transition time. However, the way it's currently implemented results in behavior that is a little erratic, and broken in some cases (some buggy Leviton devices). The issue is still open and in progress. Hopefully this can be addressed when the developer returns from his hiatus.

Note that the above behavior applies to OZW container images after build-150, and includes the addon v0.5.2.

A single refresh value (using mqtt or the zwave integration device configuration) is an OK workaround but falls short when you want to use transitions that are long (e.g. 30 seconds). You either need to globally configure the refresh value to the longest duration you can ever imagine using, or manually issue a refresh as part of an automation or script. It's not a general purpose solution.

Ideally OZW handles this for us, which it is on the path to doing so. If that were not that case, then I would hope that HA would implement a general purpose solution this time.

One minor correction:

1. user toggles switch in UI
2. dimmer starts dimming process
3. Hass queries the dimmer and gets the current state (partially dimmed)
4. Hass updates the frontend with the partially dimmed state
5. dimmer finishes dimming process
6. There is no 6, the frontend is never updated with the final state of the dimmer

In Step 3 replace "Hass" with "OZW". HA is not querying the switch for the dimmer level, OZW is reporting it. By default, OZW does a GET immediately after every SET. In this case the GET is replied to before the dimmer has transitioned to the final level. HA is just reporting the information it gets back from OZW.

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[ve6rah]

Still unfixed near as I can tell.

[jinx8402]

I'm also experiencing this issue in my home assistant which uses ozw 1.6. I have a GE 14294, which apparently has the VerifiedChanged setting configured already. Turning on through the UI works, but turning off it fails to update the state correctly.

@kpine any thoughts?

As a workaround, I created a script to simulate the toggle action. When turning off, I have a 5 second wait then a second turn_off call. This keeps allows to not continuously poll for status.

[airdrummingfool]

I have this issue with GE Enbrighten ZW7101 bulbs. Since the bulb's multilevel switch command class is only version 1, I was able to work around it by setting the VerifiedChanged in the device configuration XML as discussed by @ve6rah and @kpine. I have access the ozw configuration files because I am using Docker and mapped the container's /opt/ozw/config folder into a subdirectory of my home folder, e.g.:

    volumes:
      - /home/user/config/openzwave:/opt/ozw/config

Here's what I did (note that due to permissions issues, I had to edit the files using sudo):

1. Stop ozw container
2. Find the correct device config file. My device has multiple model numbers, so I found it under /home/user/config/openzwave/ge/ze26i.xml
3. Add the following command class code to the xml config file on a new line before </Product> at the end of the file:

  <CommandClass id="38">
    <Compatibility>
      <VerifyChanged index="0">true</VerifyChanged>
    </Compatibility>
  </CommandClass>

4. Rename /home/user/config/openzwave/ozwcache*.xml file so it will regenerate on the next ozw start (might be able to just refresh the node info instead, I'm not sure)
5. Start ozw container

Now when I turn off the GE bulbs, I see the following message in the OZWAdmin logs: Changes to this value are verified..

[prairieit]

I have this issue with GE Enbrighten ZW7101 bulbs. Since the bulb's multilevel switch command class is only version 1, I was able to work around it by setting the VerifiedChanged in the device configuration XML as discussed by @ve6rah and @kpine. I have access the ozw configuration files because I am using Docker and mapped the container's /opt/ozw/config folder into a subdirectory of my home folder, e.g.:

    volumes:
      - /home/user/config/openzwave:/opt/ozw/config

Could you elaborate on how you mapped the containers config folder to a sub directory? Having this same issue with every single one of my older Linear dimmers (about 12) and sure would like a fix. I'm going to guess you aren't using Hassio but bonus points if this works on Hassio as well :). Havent been able to figure out an user friendly way of accessed OZW configs when using the add on in Hassio

[airdrummingfool]

I don't use Hassio, and unfortunately I don't think the method I used to fix the problem would work with it. I use Docker Compose to run Home Assistant and OZW, and in the docker-compose.yml file I use to configure it, I added an entry to the volumes key to map the OZW container's config folder (/opt/ozw/config) into a local folder I created (/home/user/config/openzwave).

[MattiasC]

I also have this problem with the Aeotec Dual Nano Switch (ZW140), I couldn't find where to add the Verified Change parameter in the device configuration file since there were no entries for the binary switches there.

I hade to manually edit the ozwcache.xml file instead and change the "verify_changes" parameter to true in CommandClass with id=37. (Don't forget to first shutdown OpenZWave before editing the file if trying this)

[nevir]

It looks like this may be mitigated/resolved via Z-Wave JS (zwave-js/node-zwave-js#452) for those willing to make the switch once it's out/stable

[nemith]

I am still having issues with zwave-js as well were the dimmers and the state in HA don't match. Only with dimmers.

[marcelveldt]

I am still having issues with zwave-js as well were the dimmers and the state in HA don't match. Only with dimmers.

Z-Wave JS should handle this way better than OZW... But maybe you have one of those devices that need to be active polled. Are those Z-Wave plus dimmers ?

[PrplHaz4]

I am still having issues with zwave-js as well were the dimmers and the state in HA don't match. Only with dimmers.

Z-Wave JS should handle this way better than OZW... But maybe you have one of those devices that need to be active polled. Are those Z-Wave plus dimmers ?

It would be great if we could capture the models of GE Dimmers and issues or quirks on the HA Z-Wave JS integration docs - finding good info on them has been nearly impossible despite the fact that so many people mention having problems or needing to use a special configuration with them...I'd even support a known issues section for the older Z-Wave integrations, but I don't have good enough info to be the one writing it all down...

GE 12724 (Z-Wave)

• zwave: requires polling_intensity: 1
• ozw beta: ??
• zwave_js: TBD?

GE 14294 (Z-Wave Plus)

• zwave: requires refresh_value: true and delay: 3, still buggy
• ozw beta: requires verifyChanges
• zwave_js: TBD?

GE Enbrighten 46203 (Latest, Z-Wave Plus, S2)

• zwave: ??
• ozw beta: ??
• zwave_js: TBD?

[marcelveldt]

@PrplHaz4 see this for the discussion on how/where we're going to specify device specific quirks:
zwave-js/node-zwave-js#1576

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[tareko]

This issue remains currently

[helppp]

I confirm, this issue still exists