I’ve made a different thread to discuss, but I believe the supporting feature of the zigbee protocol that would solve such a problem would be scene recall. It would be nice to see that feature implemented since it would allow the switch to be a ‘local/hub-less’ scene controller.
In the Blue series project discussion thread, Eric mentions a firmware change regarding the use of the mechanical relay when in Single Pole, On/Off, neutral mode:
What I got out of that was that originally, when in Single Pole On/Off mode, the switch was a dimmer switch, but the only brightness options were 0 and 100%. But after the change, an option was added to have the switch behave like a dumb on/off switch, where the mechanical relay would connect/disconnect the load, and the dimming circuitry would not be involved at all.
I thought the dimming circuitry would be disabled due to the mention of that option fixing the scenario where someone has non-dimmable lights that flicker when powered by a dimmer switch even at 100% (as I mentioned earlier in this thread; I looked at the waveform coming out of the switch when it’s set as a dimmer at 100% brightness, and it’s still not a perfectly smooth sine wave; the switch still chops out part of the wave).
However, I tested the switch in Single Pole, On/Off, neutral mode, relay enabled (parameter 261, Disable Relay, “Click” Sound set to 0), and to my surprise, even though I hear the mechanical relay click, the dimming circuitry is still being used, and the switch isn’t putting out a clean sine wave. It’s almost exactly the same as when the switch is in Single Pole, dimmer mode at 100% brightness.
So unless I misunderstood the purpose of the firmware change, it doesn’t seem to be working as intended. While the relay makes the click sound, it’s not actually changing anything in terms of what the switch is doing. If someone has a load that requires the full, smooth, sine wave, it’s not going to work even with the switch in on/off relay enabled mode.
“doubleTapUpForFullBrightness” should be usable even with “buttonDelay” set to 0. If enabled, a second tap during a change event should instantly warp to the final value. This should be possible for transitions both up and down.
Some adjustment options for the dimming ramp curve. Right now, the values appear to be evenly spaced resulting in a linear set of values out. For many dimmable devices, changes near the “almost off” end of the dimming spectrum have a much bigger perceptual difference than the same size steps at the top end of the curve. Light perception is logarithmic, not linear, and not all devices correct for this. I’d love to see an option or two for a non-linear curve where it takes smaller steps near off and bigger steps near on. (this doesn’t make sense to implement for smart bulb mode since devices should already implement it, but it is quite important for non-smart bulbs, since dimmable LED bulbs are all over the map about this)
The way I understand it, the purpose of the buttonDelay is to know how long to wait for the next tap so that a decision can be made whether the to generate a single, double, triple, etc tap. So, it cannot be both ways - 0 means report a single tap right away. >0 means report a single tap if no other tap comes in before the delay timer, else increment tap counter and reset timer to zero to wait for the next tap up to the buttonDelay timer.
How are notifications supposed to be handled on Hubitat? Currently I’m only seeing custom commands instead of the child device setup like the red series. Am I missing something or is this how its intended to work?
New Lutron Diva uses a single click when already ON to go to max and it works fine.
Your second point should be addressed. The brighter the lights get they need a lot more power for our eyes to distinguish the increase. Its not a simple solution but they need to take a shot at fixing this dimming curve to be visually smooth.
Right, that is the standard behavior, and I’m sure it’s how they implemented the feature.
However, my point is that with buttonDelay = 0, you can still infer a “I want it all the way bright” if a (different) tap occurs while the switch is in the process of ramping to full. So it’s less a “double tap” and more a request for “If a press occurs during ramping, complete the ramping instantly to full”.
An alternative behavior (with or without buttonDelay=0) might be “if a light is on at any level (or ramping in that direction), and an ‘up tap’ occurs, ramp to full instead of set point”. Ditto for down.
This may all be moot, since it seems “return to previous level” isn’t super intuitive for (my) users at least, so I may have to default to 100%. This is probably ok since you can still ramp up from zero with press-and-hold.
Fair enough I was trying to see if there was a better way to suggest approaching it, definitely agree that it makes more sense for the light to just ramp down from current brightness, but not sure how that would work. When you set the Max dim level to 5, and then turn light on to max brightness, the brightness is still at 254, it doesn’t get locked in to 12/13~ when you lower the max dim level (since it still lets you dim over the full min/max range) so that’s why it occurs this way.