With the new beta you need to add
<CommandClass id="38">
<Compatibility>
<VerifyChanged index="0">true</VerifyChanged>
</Compatibility>
</CommandClass>
to the manufacture config files. If you’re running the add-on, it will be impossible to do this.
If you send me a list of devices that need it, I’ll add it to the upstream config files
I think it’s a band aide. @freshcoast knows the details. I guess we are waiting on a fix that has been in the works for some time.
Its the only band aide available for dimmers that support MultiLevelSwitch CC Version 3 or less, and BinarySwitch CC Version 1
The problem is the specifications in these versions did not say if the value returned should be the “instant” value, or the final value. Each Vendor did what they wanted and hence we have some devices that “work” and some that exhibit this behavior.
That config block forces OZW to ask a 2nd (or 3rd or 4th…) time for the value and doesn’t publish it to the application till the last 2 values retrieved from the device match (ie, have the same value).
The issue that @freshcoast reports is if you have a very long duration value for a dimmer. OZW will ask in quick succession for values, and its possible that 2 consecutive values come back the same. I will look incorporating the “duration” value into this check and delay the consecutive gets so its more likely we don’t run into that situation.
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.
I added that to the following files:
/ge/14294-dimmer.xml
/ge/12724-dimmer.xml
<CommandClass id="38">
<Compatibility>
<VerifyChanged index="0">true</VerifyChanged>
</Compatibility>
</CommandClass>**
This is awesome! Thank you Petro and Fishwaldo for your great work! Indeed i was arriving at that conclusion based on the similar report here:
Thanks for incorporating into upstream.
Indeed I’m running this as an add-on in Hassio. I wonder if I could just SSH into the host, bash into the add on container and edit the config XML files directly there similarly to what this PR seems to do ? https://github.com/OpenZWave/open-zwave/pull/2272/files
I am seeing this with a Lutron Caseta HA integration as well. Checking the status it reports brightness as “0” and “on”.
If you restart the container it should grab the latest config files for you and automatically refresh
So please test the VerifiedChanges flag posted above and let us know if it works. I wont add it till someone confirms they see success after testing.
So, i did try adding the above change to:
/ge/14294-dimmer.xml
/ge/12724-dimmer.xml
which are effectively my devices and restart the container. It didn’t appear to work - which is odd given above description.
Is it possible i need to rediscover the devices ? Any logs i can look at to confirm the option is actually taking effect ?
I’ll try to debug some more later today once i have more time outside of regular work hours (PST timezone).
You need to refresh the node after adding that param. In mqtt explorer (assuming you only have 1 zwave network):
OpenZWave/1/command/refreshnodeinfo/
with
{
"node": 14
}
change the node to whatever you need it to be
I suspect my verifychange xml change is not kicking in for whatever reason. Even after the refreshnodeinfo i still see the response yielding (“ChangeVerified”: false, looks suspicious):
{
“Label”: “Level”,
“Value”: 0,
“Units”: “”,
“ValueSet”: true,
“ValuePolled”: false,
“ChangeVerified”: false,
“Min”: 0,
“Max”: 255,
“Type”: “Byte”,
“Instance”: 1,
“CommandClass”: “COMMAND_CLASS_SWITCH_MULTILEVEL”,
“Index”: 0,
“Node”: 10,
“Genre”: “User”,
“Help”: “The Current Level of the Device”,
“ValueIDKey”: 172589073,
“ReadOnly”: false,
“WriteOnly”: false,
“Event”: “valueChanged”,
“TimeStamp”: 1593186220
}
Actually, i take it back. The problem was the topic name should be:
OpenZWave/1/command/refreshnodeinfo/
Rather than
/OpenZWave/1/command/refreshnodeinfo/
(heading slash). Waiting for it to complete refreshing…
Yeah i was going off memory. Removed the / from my post.
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 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
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).