Also some of the flags don’t get updated until ozwdaemon is restarted.
Ok, so, i can confirm this did yield improvements. After i applied that change when i disable the device the end state ends up being disabled (this is for a 14294 dimmer device).
This is much better than before where after a disable it’d initially flip back to enabled and it’d remain as such.
It’s still not perfect though - i.e. i observe the following pattern:
- I flip the switch to disabled in lovelace
- The toggle flips to disabled
- Soon after it flips back to enabled
- And a few seconds later back to disabled. (before the change this did not happen)
I suspect this is why some folks added the “delay” setting in the old zwave configuration for light integrations.
I’m not sure if there’s anything equivalent with the new approach ?
Actually, i was able to fix that aspect as well by setting “dim rate” to 1. This likely forces the value changes to be more aggressive which makes it so that the “verifychanged” configuration yields optimal results. I’m not sure if there’s a better / cleaner fix here though?
Regardless, Seems to be working nicely now!
Thanks everyone!
@Fishwaldo want me to send a PR for this config on those 2 devices ? This ain’t perfect by default (as i had to change my dim rate) but it’s a step in the right direction for these devices.
You’re a little late, already added. 
https://github.com/OpenZWave/open-zwave/commit/de5ef9d53d0b19395d7809c7c0a8a6b61939e544
1 Like
Oh, my bad 
There you go. Thanks!
For my 14294 the dim step and rate are the defaults, 1 and 3, and I don’t observe any flip-flopping of the UI switch. Perhaps it just depends on how quickly/slow the individual device responds or how quickly/slowly OZW queries the device.
You’ll should notice that that if you set a long dim duration (transition in HA) of something like 10 seconds, the state in HA will still be incorrect. The implementation still needs some improvements, but that’s a known issue.
I suspect this is why some folks added the “delay” setting in the old zwave configuration for light integrations.
Actually that delay is what causes the flip-flopping. It’s the exact same idea as VerifyChanged, except it’s the application (HA) that is doing the refresh but only one time after the delay. In comparison VerifyChange will poll the value very quickly until it reaches a stable value (not the target value, which is the problem above).
For my 14294 the dim step and rate are the defaults, 1 and 3, and I don’t observe any flip-flopping of the UI switch. Perhaps it just depends on how quickly/slow the individual device responds or how quickly/slowly OZW queries the device.
Interesting. I wonder if there’s any settings i can tweak here. I did try it with a device that is both far and a device that is near the zwave stick and got the same experience in both devices.
I imagine what’s happening here is that because the dim rate is slower (30ms instead of 10ms) the valuechanged will more likely see two matching values and thus yield that update ? I’d imagine a way to mitigate this would be for OZW to query the device at a slower pace or, alternatively (and likely better), require a longer period of matching values ?
How are you “adjusting” the dim rate? are you using the duration valueid or a config param?
If its via the Duration - I will add some delays in if the Duration is “long” (will have to experiment a bit to see what is a long duration and how long to delay the verification…)
@Fishwaldo below:
Essentially tweaked my zwave command setting to 1.- i.e. a config param.
Also, if you think it may help, i’m happy to give you ssh or rdp access to my Hassio instance.
Does anyone know of a Zigbee equivalent fix? This worked great for my Zwave light switches, but I’m finding I’m having the same issue with my Zigbee bulbs 
1 Like
Hi,
Could you add the CommandClass id=“38” section into:
wenzhou/tz67.xml
I have confirmed that it operates exactly as described without that section in the xml file and properly with it in.
Thanks
Having the same issue with a Qubino mini dimmer - ZMNHHD. Commands are instant but HA has no idea what has happened, despite the energy use reporting being almost instant.
Possibly related, with an HS-WD200+ running OpenZWave Version 1.6.1207, qt-openzwave Version: 1.2.0, QT Version: 5.12.8, remote dimming goes in insane slow-motion. MQTT logs show commandclass 38 “Dimming Duration” and “Target Value” messages flooding the network (2-4/s). Dimming from 100-0 takes > 3-5 minutes right now. I’ve verified this on multiple other identical hardware. Unsure if it’s me, this specific version of ozw, or the alignment of planets. Happy to provide any specific details if it’ll help.
build-150 is the most recent build compatible with HA.
Newer builds change the API that is used for setting dim durations, so HA will not set the correct values.
1 Like
Build 150 of what? Having this issue as well, running it in docker openzwave/ozwdaemon:allinone-latest.
Thanks.
Answering my own question: openzwave/ozwdaemon:allinone-build-150, working fine on this version.
Thank you! I also needed to add this to Aeotec ZW098 LED Bulb when using OZW 1.6 Beta. It is now working as expected.
Hi @Fishwaldo,
Thanks for the input above. I also had to add the ‘VerifyChanged’ xml snippet in domitech/ze27eu.xml
to get my led bulbs off-status working properly.
1 Like
In Version 4 of MultiLevelSwitch CC and Version 2 of Binary Switch - the devices now send a “instant” value, and a “target” value - I’ve explained how this works to the integration team and asked them to use the Target Value instead of “level” but I’m not sure how many devices in reality are out there currently that meets this criteria.
My GE 46201 switches report Version 2 of Binary Switch and show the transition state in ozwadmin,
and yet the switch in lovelace still pops back on before it turns off. Its odd since they are switches and turn off right away without dimming. My 46203 dimmers also do this but at least that’s more understandable. Do you know whether the integration team plans to implement this? Another way to fix it?
Doing this has no impact:
<CommandClass id="38">
<Compatibility>
<VerifyChanged index="0">true</VerifyChanged>
</Compatibility>
</CommandClass>