core: OpenZWave dimmable modules don't report final state

Still unfixed near as I can tell.

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.

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

@PrplHaz4 see this for the discussion on how/where we’re going to specify device specific quirks: https://github.com/zwave-js/node-zwave-js/issues/1576

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?

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

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>

1. 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)
2. 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..

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)