Strange issue with EcoDim dimmer's value

Checklist:

• I am not using HomeAssistant. Or: a developer has told me to come here.
• I am not using ZWaveJS2MQTT. Or: a developer has told me to come here.
• I have checked the troubleshooting section and my problem is not described there.
• I have read the changelog problem was not mentioned there.

Describe the bug

This is a continuation of the little chat we had on discord. A few people contacted me about really weird problems with their EcoDim dimmers in recent Z-Wave JS integration. Basically it boils down to the state (currentValue) being not in sync with the actual state of the device.

By trial and error we came to a few conclusions:

• The issue is NOT present in zwave-js 6.1.0 and below.
• The issue is present in 6.2 and above. We couldn’t test a version in between.
• The issue is most likely caused by the additional GET after set for MultiLevelSwitch CC, introduced in zwavejs 6.1.1
• The device is using supervision.
• When sending a new brightness (setValue to targetValue) command, there are 2 responses (value updated event) immediately returned (so no 5 seconds delay, they both come in within 100’s of milliseconds).
• The value that in the second “value updated” event is wrong, causing the state mismatch.
• Issuing a pollValue some time after corrects the issue but this should be properly tested again to be 100% sure.
• It seems that this device does not need that additional get after set. Without that all is fine and the currentValue always matches the actual lightdimmer’s state.

Some things to consider:

1. Maybe there’s a compat flag needed to not perform the GET on this device ?
2. Why is the second “value updated” event returned right after the SET. You would expect this to be 5 seconds after the SET

Device information

Which device(s) is/are affected (make/model)?
What are the node IDs?

Did you change anything?

• Yes: (please describe)
• No

Did this use to work before?

• Don’t know, this is a new device
• No, it never worked anywhere
• Yes, in: zwavejs version 6.1.0 and below

How are you using node-zwave-js

• zwavejs2mqtt (latest) docker image
• zwavejs2mqtt (dev) docker image
• zwavejs2mqtt Manual Docker build
  • node-zwave-js branch:
  • zwavejs2mqtt branch:
• ioBroker.zwave2 adapter
• HomeAssistant version XYZ
• Pkg
• Manual Docker build
  • node-zwave-js branch:
  • zwavejs2mqtt branch:
• Manually built (as described in the docs)
• Other:

To Reproduce

See description above.

Scenario 1: device is already on, we want to adjust brightness Issue a setValue to MultiLevel CC for e.g. value 35 value updated event with value 35 value updated event with value totally out of order, e.g. 0 or 20 the brightness “slider” in the client application (in this case HA) doesn’t match the light

Scenario 2: device is off (currentValue 0), we want to turn it on Issue a setValue to MultiLevel CC with value 255 (previous state) or some other brightness value updated event with value set above value updated event with value 0 the light is off in HA it’s actually ON

Additional context

Strangely enough, there seems to be a little bit of difference between these devices (firmware level maybe) ? @MarkGrootObbink contacted me with the above issue report (and I tried debugging it remotely) while another user, @pascalwinters has this same dimmers (although with newer firmware version) and in his case the issue is reversed. First the wrong value event comes in and seconds report is the correct one. Because these value events were still not 5 seconds apart, I still think it’s strange.

In anyway people with these dimmers (and maybe other devices too) will have issues when using a newer version of zwavejs so that’s the reason I created this issue.

Logfile:

@pascalwinters are you available to provide more details such as logging on request ?

[blhoward2]

Ok, makes sense.

[blhoward2]

Not necessarily. I’m not sure that SmartThings uses the Supervision CC and some things work differently. We have seen devices that only have bugs discovered once they’re used with zwavejs, but which are actual bugs with the device fw.