Z-Wave dimmer "restore last value" setting

I’m a bit confused about the “restore last value” setting available on zwave dimmer channels. When set, at least for my HomeSeer HS-WD100+ dimmers, the lights do return to the previous value when I turn the switch on remotely. However, the OpenHAB dimmer item value is always set to 100%. This leads to inconsistencies between the item value and the actual dimmer level.

Is there a way to make the item value reflect the previous value when this setting is enabled? Looking at debug logs, it doesn’t appear that the value is actually sent from the switch when turning it on remotely, so I’m not sure how OpenHAB would know what the value should be without polling.

This is a feature of the device - it remembers the last value and sets it back when it receives the ON command (ON with a specific value that means to return to the last value).

In general, the binding requests an update of the state after sending any commands - it should do this here as well, but it’s possible that it’s done too quickly. We could delay this request by a few hundred milliseconds reasonably easily.

Anyway, hopefully this helps explain how this works at least - different devices of course might do different things…

Thanks, Chris. That makes sense. Is the follow-up update something I should see in debug logs? When turning the switch on remotely, I only appear to be seeing the multilevel set command.

2017-03-29 16:27:47.072 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:d3d50f00:node2:switch_dimmer --> ON
2017-03-29 16:27:47.076 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 2: Creating new message for command SWITCH_MULTILEVEL_SET
2017-03-29 16:27:47.086 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2017-03-29 16:27:47.086 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-03-29 16:27:47.087 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 02 03 26 01 FF 25 C4 DE 
2017-03-29 16:27:47.089 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0A 00 13 02 03 26 01 FF 25 C4 DE 
2017-03-29 16:27:47.107 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
2017-03-29 16:27:47.113 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-03-29 16:27:47.114 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8 
2017-03-29 16:27:47.116 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8 
2017-03-29 16:27:47.117 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01 
2017-03-29 16:27:47.125 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 2: Sent Data successfully placed on stack.
2017-03-29 16:27:47.126 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 C4 00 00 02 2D 
2017-03-29 16:27:47.130 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-03-29 16:27:47.136 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 C4 00 00 02 00 00 23 
2017-03-29 16:27:47.148 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 C4 00 00 02 00 00 23 
2017-03-29 16:27:47.151 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=C4 00 00 02 
2017-03-29 16:27:47.157 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 196, Status = Transmission complete and ACK received(0)
2017-03-29 16:27:47.158 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Starting initialisation from DONE
2017-03-29 16:27:47.160 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@8355ae already registered
2017-03-29 16:27:47.162 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=2, callback=196, payload=02 03 26 01 FF 
2017-03-29 16:27:47.164 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=C4 00 00 02 
2017-03-29 16:27:47.166 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=196, expected=SendData, cancelled=false        transaction complete!
2017-03-29 16:27:47.167 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2017-03-29 16:27:47.169 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2017-03-29 16:27:47.170 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 2: Response processed after 77ms/4736ms.

One behavior of my switches that may be problematic is that they always report their current dimmer value, even when they’re in the middle of a ramp up or down. So depending on the ramp rate even a few hundred milliseconds may not be sufficient. I believe OpenZWave has a feature that polls repeatedly until it receives two equal values in a row. Seems like a hack but it might be useful in this case.

Would another option be for OpenHAB itself to remember the previous level? My event log reports that, for example, the dimmer has changed from 30% to 0 when I switch it off. So the previous value is available, but it would need to be stored and recalled the next time the switch is turned on.

I just checked and the follow up request is only made under certain circumstances, so this can be changed to improve this issue (please feel free to open a request on github).

I’m aware some switches report the current value and the binding can work with this - it can make a number of requests every few hundred milliseconds until it’s static from memory (it’s been a while since I looked at that code, but I think that’s what I implemented). So, we can potentially deal with this ok…

Thanks. Opened an issue: https://github.com/openhab/org.openhab.binding.zwave/issues/438

I’ve made a change to the binding - let me know if it helps (or causes any side effects :wink: ).