GE and HomeSeer Dimmer unreliability with turning on and off

[kylehendricks]

I recently started testing the home assistant openzwave beta and noticed an issue with all of my dimmers. If I toggle the dimmer on and off over and over I will quite quickly get into a state where the "Level" in openzwave gets out of sync with the actual state of the dimmer.

To simplify things, I switched to just using MQTT to reproduce. I toggled on and off by publishing to OpenZWave/1/command/setvalue/ with the ValueID for the dimmer's Level. Without fail, I can set the dimmer's level to 255 (or 99?) and openzwave's level won't update and will stay at 0 even though the light is on. Any subsequent attempt to set the level to 0 does nothing. Essentially, I need to set the dimmer to 255 twice to get the state correct so that the dimmer will turn off when setting the level to 0.

I did try to search around for anyone else having similar issues. If there is an existing discussion going, I'll close this and go add to that.

I'm using the latest docker image openzwave/ozwdaemon:allinone-latest but can't seem to figure out which version that is because dockerhub seems to be messed up right now.

[ghost]

I have a Gocontrol PD300Z-2 lamp module that has the same issue. Unfortunately, I think it's a device bug. The Leviton dimmers I have work properly. The issue was also in the OZW 1.4 implementation found in homeassistant. You might not have noticed it in the old implementation because in 1.4 hass does device polling while in 1.6 you must explicitly enable it per ValueID over MQTT. When the device is polled, it returns the right dimmer level.

Here is a simple script to do so. With Intensity set at 10, it polls every minute. You only need to send the command once. Afterwards the change in polling will be saved to the cache file.

#!/bin/bash

if [ -z "$MQTT_SERVER" ] ;then
        MQTT_SERVER="127.0.0.1"
fi

for valueid in $@ ; do
        payload='{"ValueIDKey": '$valueid', "Intensity": 10}'
        mosquitto_pub -h $MQTT_SERVER -t "OpenZWave/1/command/enablepoll/" -m "$payload"
done

[kylehendricks]

Interesting. Does hass do some kind of single-shot poll or something? It appears that it would get "corrected" very quickly after a state change. I wonder if they did a single "poll" after X seconds after a toggle? Seems like this 60s polling solution wouldn't be ideal.

I'm surprised both my HomeSeer and GE dimmer both do this. I'm willing to switch to different dimmers if they don't have this problem.

I'm not sure if this is related but the GE dimmer is hooked up to a nodered automation that "syncs" some other zigbee bulbs to it. For some reason with OZW 1.6, the delay has gone from 300-400ms to 2-4s.

[kpine]

Most dimmer problems now are caused by https://github.com/OpenZWave/open-zwave/issues/1321.

You didn't specify which models of switches you have, or provide any logs, so it's only an educated guess. For old dimmers, you'll need to turn on the VerifyChanged compatibility flag in order to get the level refreshed. Otherwise, OZW will do a single Get after the Set, which is usually the wrong value. You would need to manually issue another Get in order for OZW to know the actual value.

If the compat flag is already turned on, or if the command class is Multilevel >= 4, then the refresh is already enabled. In that case, because of https://github.com/OpenZWave/open-zwave/issues/1321 there are still problems handling the refresh, so it doesn't always get the final value correctly.

[kylehendricks]

The dimmer models are: Homeseer HS-WD200+ GE 14294 Smart Dimmer

I think these models are fairly recent so would VerifyChanged not have any effect?

[kpine]

The WD200+ should be new enough to have Multilevel V4.

The 14294 has several different versions (product IDs are different). Mine is old and doesn't support Multilevel V4, but the compat flag is enabled. The latest iteration does support V4.

Either way you are probably covered, but you can check via MQTT or the ozwcache file.

If you are toggling the switch of and on fairly quickly, then the refresh code is probably having trouble handling the level changes, due to the issue I posted.

But, for the WD200+ there was also an issue posted to HA prior to these verify changed code changes being committed. It looks like the WD200 might be buggy, so that could be another factor. You might try forcing Verify Changed for that device.

[blhoward2]

I don’t know if this is related but I noticed similar behavior with my 462XX series GE switches and dimmers. If I turn the same one on and off repeatedly it goes out of sync (didn’t happen on 1.4). And, if I turn 3-4 off in rapid succession (via my dashboard) the last one or two will delay a half second Before going off and the log shows that the command is queued. This never happened in 1.4.

I actually don’t notice this in my 14294s though most of those are an older model.