Tap up on dimmer for max brightness

Switches Firmware Discussion
, ,
21

My home is built on adaptive lighting, which auto-dims in the morning or night based on circadian (lights also color). The default level is also set to this varying level such that when a user hits up once when the light is off, it automatically applies the level the circadian level is at. The user then can manually apply a hold of up or down to dim and it remains until the reset time (I set at 3am) or the light is turned off and back on again.

This works really well but I also may implement scene control for a touch up when dimmed goes to 100%. Easy enough with scene control and an automation or Node Red flow. Good idea, but doesn’t need firmware to make it happen IMO.

1 Like
22

Yes, agree – I’ll admit, I haven’t read this entire thread, but am going through and updating the category and tags and saw this. But, this can be done via button control and/or default value.

Everyone who is wanting this feature, can you achieve this via setting the default value to 99?

image
image780×288 13.1 KB

I likely am missing something, but thought I’d throw it out there!

1 Like
23

Only problem is that I love the ability to remember the last level as you might have a preferred level for a dimmer 90% of the time, and this would sacrifice that functionality.

By comparison, a Fibaro led strip controller with momentary buttons will remember the last level with one tap and go full brightness with a double tap with zero delay (since it’s built in).

24

FWIW I’m one of these people.

Here’s the use case:
I turn on the light, say, to 20%
Now I want to turn it up to 99%. So instead of holding the up paddle, I can just tap the up paddle once as ‘on’.

Resulting behavior would be tapping the up paddle always sets it to the default level set in that parameter, whether it is currently on or off.

Right now I get this behavior with a scene- IF up paddle is pushed once, THEN set dimmer to 99%.

25

I agree that double tapping isn’t necessarily intuitive. So that’s why I use Inovelli’s Config/Favorite button, i,e, the little side button (which is a Button 7 push) for the default dimmed value I want. I found everyone quickly learned to push that. Plus, for switches with no other scenes you can then change Config 51 to “on” to disable the 700 ms delay, together with setting parameters 1, 3 and 4 to zero to get that near instant on effect. (Just BTW, I set param 2 to 3 for physical dimming from the switch).

As I posted above, I think a singe tap up should set the associated light(s) to whatever the current default value is set to regardless if the light is off or already on.

1 Like
26

The problem is that doesn’t work if the dimmer is already ‘on’. If the dimmer is already on this setting is ignored.

In other words, if you set the default value to 99 and the switch is ‘off’, then tapping the up paddle will turn on at 99. But if the dimmer is already on at some other level, lets say 50, and you tap the up paddle, it stays at 50. The ‘default level’ is not applied if the dimmer is already ‘on’ at some other level.

I agree. The key point here is “if light is already ON or off”. The current dimmer firmware only applies parameter 9 (and I suspect parameter 10 also) if the dimmer is off.

1 Like
27

I understand that. I’m just wishing it could be changed so that a tap up would apply default setting regardless if the switch was off or already on.

2 Likes
28

I agree.

@Eric_Inovelli @EricM_Inovelli can we get this added to the feature request list for a future firmware update?

FEATURE REQUEST: Enable smart dimmers to use the "Default Level" (Parameter-9) whenever the paddle switch is tapped up 1x. Currently it only does this if the switch is in the off state. Tapping up 1x when the switch is already on does not apply the default level.

6 Likes
29

Ok, I have added this request.

3 Likes
30

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

  1. “Light was off. Pushed on. Lights turned on, but not bright enough. User wants more light and pushes button again immediately.”
  2. “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.

31

If it’s possible to use double-tap-up for full brightness, and double-tap-down for nightlight, then you won’t have to contend with the switch changing states since it’ll only send the central scene command.

32

What do you have the delay for scenes set to? That would delay the scene behind the switch turning on.

I suppose you could setup an internal “switch” that follows the light but had a delay. Turn the light on and the internal switch is turned on after 0.5 seconds or 1 second. That could be used as the reference for ignoring the scene.

33

The result, in a sense, would be that when the switch is off, tapping the off paddle toggles between actually ‘off’ and night light.
If the switch sends a SwitchMultiLevelReport and a CentralSceneNotification at the same time, the only way to do this would be to have a separate variable that updates more slowly in the hub firmware. Call it SwitchState.

So you create one rule: IF Light Switch setting changes, THEN wait 1 second, THEN set SwitchState to be the light switch level.
Then for your other rules, have them reference the SwitchState variable rather than the switch itself. IE: IF down button is pushed, AND IF SwitchState = 0, THEN set LightSwitch to 5%. and IF up button is pushed, AND IF SwitchState > 0, THEN set LightSwitch to 99%.

Personally what I do is just reinforce the on action. IF up paddle is pushed, THEN set level = 99%.
There are one or two where this doesn’t work though. For example the hallway light, I have a few events that change its default on % so it doesn’t blast with light if I get up at night to use the bathroom. Because the default level there doesn’t change, I’d have to have more complex control logic for that, I just don’t bother.

Not really. The delay is to see if multiple taps are coming. If you tap once, it will wait 700ms to see if you’re going to tap 2+ times. But until then, it doesn’t react at all (either as central scene or as a switch). Otherwise let’s say you tapped 3x- it’d send a 1tap, a 2tap and a 3tap central scene command.

You could in theory use the switch in one of the smart bulb modes- no paddle control of the dimmer, just use purely hub logic for that. You’d have to code in hub logic the on, off, and StartLevelChange / StopLevelChange for hold-to-dim.

The ideal really would be if an option for single tap = set to default level even while on could be added to the firmware. Unfortunately I don’t see that happening quickly. Right now I think the new Blue series switch is pretty essential to Inovelli’s continued health, simply because lead times on Z-Wave chips have gotten so absurdly long that they spend more time out of stock than in stock; can’t sell switches = can’t make any money to pay the bills. ZigBee certainly isn’t perfect, but whatever its other sins may be, at least when you order the chip you can expect to actually get it.