Dimmer Control (Z-Wave; GE 12724)

Setup, Configuration and Use Scripts & Rules
1

Hello all, I’m trying to control my GE 12724 dimmer based on input from the dimmer itself, rather than a web interface or other command. Basically, I would like to have the dimmer go up to full power during the day, but only up to about 20% at night. I have the dimmer in my master bathroom, so the idea is that if I wake up in the middle of the night, I only need minimal lighting.

I’ve seen some example rules that use the “received command” event, but that only appears to work (i.e., that event is only triggered) in response to sending a command or the web interface. So I tried the following rules (testing, so I didn’t include code for the time-of-day changes):

rule “MBR Lights On”
when
Item sMBRLight received update ON
then
sendCommand(diMBRLight, 100)
end

rule “MBR Lights Off”
when
Item sMBRLight received update OFF
then
sendCommand(diMBRLight, 0)
end

In practice, these rules resulted in the dimmer going straight to 100% rather than ramping up (fine by me, and I can add a delay loop to make it ramp if I choose). But the rule has also prevented the dimmer from shutting off. It appears that when I press the off button, the switch updates the dimmer value but again updates its status to ON. And from the logs, it looks like the switch is never updated to OFF:

2016-01-07 16:50:09 - diMBRLight state updated to 0
2016-01-07 16:50:09 - diMBRLight received command 0
2016-01-07 16:50:09 - diMBRLight state updated to 0
2016-01-07 16:50:12 - sMBRLight state updated to OFF
2016-01-07 16:50:12 - diMBRLight state updated to 0
2016-01-07 16:50:12 - diMBRLight received command 0
2016-01-07 16:50:12 - diMBRLight state updated to 0
2016-01-07 17:27:23 - sMBRLight state updated to ON
2016-01-07 17:27:23 - diMBRLight state updated to 90
2016-01-07 17:27:27 - sMBRLight state updated to ON
2016-01-07 17:27:27 - diMBRLight state updated to 2
2016-01-07 17:30:07 - sMBRLight state updated to ON
2016-01-07 17:30:07 - diMBRLight state updated to 90
2016-01-07 17:30:12 - sMBRLight state updated to ON
2016-01-07 17:30:12 - diMBRLight state updated to 20

Also, here are my item definitions:

Switch sMBRLight “MBR Light:” { zwave=“12:command=SWITCH_MULTILEVEL” }
Dimmer diMBRLight “MBR Dimmer: [%d %%]” { zwave=“12:command=SWITCH_MULTILEVEL” }

Are there any events that I can capture that will allow me to have the OFF rule work properly?

2

You have two different definitions for the same physical device at zwave:14. And you are using a change in state in one of the device definitions to trigger a change in state of the other definition. And you are using received update rather than changed from/to as the trigger. This is pretty much guaranteed to end up in a race condition.

You want multiple pathways to manipulate the dimmer setting: the actual physical dimmer, Openhab’s lowest level logical mapping to that dimmer via an item defined at zwave:14, and a proxy for the dimmer where you will intercept actions at runtime to conditionally alter proposed behavior (in form of sendCommands) to different target values.

Generally speaking, you will target all automation commands and UI commands to the PROXY for the dimmer, intercept that via “WHEN diMBRLIght_PROXY received command xx”, examine conditional states in the THEN clause of that rule to modify desired state of the real device, and issue a sendCommand to the zwave-mapped logical mapping of the dimmer. viz.,

RULE "Proxy intercept"
WHEN
    Item diMBRLight_PROXY changed from 0
THEN
    var new_state=diMBRLight_PROXY.state
    //conditional changes to new_state value go here
    sendCommand(diMBRLight,new_state)
END

You will also need a sync-ing rule to update the value of the proxy when your manual change of the physical dimmer is the proximate cause. viz,

RULE "PXY_SYNCH..."
WHEN
    Item diMBRLight changed from 0
THEN
    postUpdate (diMBRLight_PROXY,diMBRLight.state)
END

It is important to use “changed to/from” form here rather than a bare “changed” to avoid triggering race conditions. See Design Patterns Discussion

3

Thank you, Bob. Unfortunately, I’m not really interested in automation commands per se or UI commands. I’m only interested in controlling the dimmer level based on user input on the actual switch. With that said, I think your point about having two different items point to the same switch is a good one. I think that I can accomplish what I want with some timers (e.g., only go to time-of-day dimmer level if the switch hasn’t been used for X minutes). I’ll keep everyone posted.