Leviton VRMX1 behavior

openhab2
zwave
Tags: #<Tag:0x00007fe05e520a30> #<Tag:0x00007fe05e520698>

(Mark) #1

@chris I wanted to get your perspective on an issue I’m seeing with the Leviton VRMX1 dimmer.

The device included successfully, and works as expected with one exception. When sending the command to set the dimmer level, the binding sends the SWITCH_MULTILEVEL_SET and then immediately sends the SWITCH_MULTILEVEL_GET. The problem is that the SWITCH_MULTILEVEL_REPORT that comes back in response to the GET is the original dimmer value before the device has applied the value in the SET.

What I think is happening is that the device is processing the GET before it has finished ramping up/down to the dimmer level in the SET command. Here’s a snippet from the log viewer that shows the behavior.

What do you think, and do you have any thoughts on how to deal with this?

I’m running the standard zwave binding in build #905.

Edit: I should mention that this manifests itself in some odd UI behavior. When you move the slider on the UI to a certain dimming level, the slider immediately bounces back to the previous dimming level.


Strange behavior of Z-Wave and dimmer items
(Chris Jackson) #2

Yes - I’ve seen this sort of thing before, although not the fact that a device is sending an unsolicited report (I think that’s against the rules these days).

There are ways to solve this - the binding does have the ability to defer some of these commands and I think there’s already an open issue about this actually.

If you can live with it for a couple of weeks it would be good, then I’ll take a look. I suspect that adding some sort of holdoff on these updates might be best in general.


(Mark) #3

I did look through the open issues list, but I didn’t see one specifically about this scenario. I looked again and there is an issue relating to the dimmer value when using restore-last-value.

The fix was to poll the device if we change the multilevel switch state. This appears to be causing the behavior I’m seeing.

This situation doesn’t involve an unsolicited report. The report in in response to the GET, which is sent around 50 ms after the SET is sent – definitely not enough time for the device to ramp to the new level. :wink: