I also want this feature, and am trying and failing to implement it using hubitat. I’d also love to be able to get “night light” mode by single pushing down when the switch is off, without losing the ability to have pushing down when the switch is on simply turn the light off.
TL;DR: Hubitat can’t tell the difference between “pushed up when switch was on” and “pushed up when switch was off” because off becomes on faster than the scene command can be processed.
I set up a rule that is triggered by a single push up, with the condition that it only executes if the switch is on. It seems simple, but it doesn’t work as intended. It runs every time I push the up button, regardless of whether the switch was on before I pushed the button.
The issue is that when I push up when the dimmer is off, it sends two zwave events, SwitchMultilevelReport and CentralSceneNotification. The SwitchMultilevelReport is usually processed first, which updates the state of the switch in hubitat to “on”. Then by the time the CentralSceneNotification is being processed, the condition “if switch is on” has already been set to true, so the rule fires as if I had pushed up while already on.
At least in my mental model of zwave communication (which I think is decent but perhaps missing some details), the timing of the receipt of the SwitchMultilevelReport and CentralSceneNotification commands would be the result of a non-deterministic race. Even if the switch firmware always sends the multilevel report before the scene notification, they won’t necessarily be received in the same order.
The only 100% reliable solution I can see to this would be if the firmware used the Multi Command Encapuslation command class to send both messages at the same time. Then a device handler would be able to execute code that has special handling of a Multi Command Encapsulated Command containing both a multilevel report and a central scene notification. It looks like this command class is not currently supported by the LZW31-SN Red Series Dimmer. Perhaps this is something you could put on the wish list for if/when you develop a new z-wave dimmer on the 700 series chipset? It would have the additional benefit of reducing zwave traffic.
It seems like other people have successfully implemented this with a workaround, though, so I’m curious to hear how you overcame this fundamental problem. Do you use a timer that checks how long it’s been since the light changed state, or something like that? It seems like that would work most of the time, which would probably be good enough. It’s not obvious how I’d want to set the timer to tell the difference between
- “Light was off. Pushed on. Lights turned on, but not bright enough. User wants more light and pushes button again immediately.”
- “Light was off. Pushed on. Zwave network delay or hub processing slows down the processing of the Central Scene Notification to more than ___ milliseconds after the multilevel report was processed.”
At least for now I’m using the “remember last level” setting for the default level. I’ve got aspirations to implement something like @bpd mentioned with different default levels at different times of day, I just haven’t had time to sit down and plan out exactly what I want. But it would be great to be able to use “push up for more light” as a consistent user experience.
I’m currently using Hubitat, but am thinking about switching my zwave network to home assistant, so solutions using any hub would be welcome.
