Why do you want the switch itself to maintain these values? Assuming the LED strip can be made into a property that your hub can set, shouldn’t having that data stored and controlled by the hub be all that’s needed?
I noticed you mentioned homeassistant elsewhere in this thread. If you’re using HA, you can accomplish “press and hold for dimming” functionality in node red. The switch sends start and end events for a long press - so you just create a loop in node red that initiates on the long press start event and then loops until the long press end event. I have this running currently and it works as expected.
I’ve been moving further and further away from home assistant in favor of node red (with zwave2mqtt), and I think I could be convinced that provided I can set the led bar to a percentage and have it outputting full power always (no exception) then it would do what I want. Though I have some reservations about how smooth the “animation” of the notification bar filling up would be if it relied on a round trip to the hub.
I think it would be ok if the firmware for the LED bar internally handled the animation.
In my case for example, I’m incrementing the brightness of my bulbs by 10% per loop (each loop is 200ms). You’d think that’s way too high to get smooth looking dimming, but the lights themselves (ikea tradfrii bulbs in this specific light fixture) natively fade so I don’t need to worry about making my loop fast enough and incrementing brightness in quicker, smaller steps. Basically, as long as my loop is faster than whatever pre defined timing ikea uses to internal fade the bulb - then I could even move in 50% steps and it would still look smooth since the bulb is handling the animation internally
I see that joshfee already gave his response. But there are several good reasons for wanting it. One is so zwave associations continue to work as expected (same as they have before) . Also any existing rules or automations would not need to be changed. Another reason is that using the switch paddles to dim smart bulbs should still have the switch “look like” its dimming even though the load is held at 100% the intern “logical level” and the LED bar should reflect the desired setting as well as what is being sent back to the hub.
I can’t speak to your first point as I don’t use any zwave bulbs directly. For that though, I can understand why you need the switch the essentially be a hub, since it plays the role of orchestrator in that system.
I was more referring to a hub based setup. As long as all button presses (including HOLDs) are exposed to my hub, and the LED level is exposed to my hub - then my hub should be able to do everything. I feel like it keeps it cleaner to not have the same piece of information (the brightness of my smart bulb) held in 2 distinct locations.
mamber’s suggestion is the correct one, IMO. Any z-wave dimmer already maintains the dim level internally, hence why when you go back to turn on a dimmer locally it will default to the last level it was set at (some dimmers can be programmed to override/change this). All the Red Dimmer is doing that is different in SBM is keep the voltage constant on the triac (or whatever load controller they using). The dimmer then operates like a Z-wave remote dimmer accessory.
Having to have the hub to feedback to the dimmer what the dimmer is doing is actually a kludge, IMO.
If you’re talking about direct zwave dimming with no hub, then I’d agree.
But if your hub sees the bulbs, then I think having that data stored in the dimmer is the kludge. I mean, when I press a button - the switch technically doesn’t even know what’s going to happen. That button is just sending an event to my hub, which then might be doing various things dependent on various other conditions. Is the switch supposed to contain all the internal logic that’s contained in my hub so it can independently calculate the same value as my hub, and then internally update it’s led bar? Seems a lot more reasonable for my hub to just tell the switch what’s it’s led bar should be.
I don’t follow your logic, why should the dimmer have to calculate anything?
That’s like saying Z-wave remote accessory dimmers shouldn’t maintain their own dim state??
Most modern Z-wave dimmers support instant status on most hub platforms. My hub always knows the dim level of my remote Z-wave dimmers.
If I want to dim a light to 10% at the remote dimmer then the dimmer tells the hub, “hey, the human just set me to 10%.” You can then do whatever you want with that information at your hub to take action on whatever you want.
You’d need to spell out a specific use-case where this doesn’t make sense.
I’m using the long press events to cycle colours after the config button is pressed. Basically, I’m listening for the config button in node red, and starting a 4 second counter. If I get a long press up or long press down event before that 4 seconds end - instead of triggering my dimming functions, I’m cycling RGB values on a loop.
Also, during straight dimming, when I hit the lowest dimming level (the level where I can continue dropping the brightness but there is no longer a visual change in the light output) I start turning off bulbs. I should clarify, the light fixture in question is a 3 bulb fixture. So at10% brightness, I continue dimming by turning off bulb 3, then bulb 2 - I never let it dim all the way to zero (which in this case would mean turning off the last bulb).
Thank you for sharing that. In your use-case you’re not really dimming, you’re using events.
And again, according to the Z-wave specification and how dimmers and remote dimmers work, your hub could calculate to whatever % you think the virtual/group/whatever dim level should represent and send that command back to the remote dimmer, ie, “hey, set yourself to 10% now” and the dimmer’s status lights would show 10%. This would alter the status lights but not affect your load levels since you’re using events (long hold on paddle) to trigger your action logic that sets your load levels on the devices elsewhere…
There’s zero reason to alter how a Z-wave remote dimmer should fundamentally operate as per the Z-wave specification and command classes.
Exactly. That’s what I was saying. As long as my controller can control the status light, then its irrelevant for the switch itself to know anything.
But I understand in your context where the dimmer is controlling the light directly why it would need to know that.
I was just saying that in a hub scenario, I want to have only one canonical source for the status of various entities. If that data is in two places, and different things are running logic based on reading that status from different places - then I feel it adds extra complexity into the system (and potential bugs).
It is a shorter route/more instant for the switch to be in control of it’s downstream components locally via association. That’s why z-wave even has this feature. The hub can control anything, but for speed of local control (the end user experience toggling the switch) I have/will always desire association and local control from the switch over hub control.
No disagreement, but Z-wave associations only works between Z-wave devices. Many of us want to use SBM on the Red Dimmers to control Philips Hue (Zigbee) lights which in many opinions have better color fidelity.
I absolutely agree and do the same, and that should/must be completely hub based, the switch is effectively a scene controller at that point (load stays 100% forever).
Not to derail the topic of SBM, but I wanted to also get some clarification from @gbenrus25 around the hold-delay so we can see about enhancing that experience.
Eric and I are still a tad confused around this ask.
Are you saying there’s a delay from when you hold down on the switch to when the bulb turns on? Sorry, I know we discussed this, and I feel dumb asking, but for some reason it’s not clicking either.
What would be helpful too is a video if you wouldn’t mind. Not just for Eric and I, but so we can show our manufacturer as there is a language barrier there and videos typically clear things right up.
It’s the delay between starting to hold down the button and the dimming (up or down) to start. There has to the some time that it waits to differentiate between a rather slow push (that does on or off) or an intentional hold (that starts the dimming behavior).
I suppose this delay could be shortcut in one case - if the light is on, and you push the top of the rocker, the only useful intent would be to brighten the light, so that could start immediately? (Though I have seen a request to make an ‘on’ push of an already on light ramp to full - if you are ever considering this, then the delay is still needed; if release is within the time, it’s a push & should go directly to 100%, if not released in the time, start the dim up process)
As you can see, it takes some time after I press the down paddle for both the LED strip and the actual light fixture to start dimming down (maybe about 1s). The time it takes is what I’m calling the hold delay. It’s the time the switch needs to figure out whether you’re trying to dim downwards or to turn off the light fixture.
I just did my first 1.52 update and I’ve got a bit of a situation. The switch no longer turns the lights on/off or attempts to dim, locally or zwave. The LED notifications still work and it’s still reporting status to Hubitat. I’ve air gap reset a few times, not sure what else to try?
This is interesting… I have a similar issue after upgrading firmware, ALSO from 1.35. I moved the switch to another location, a non-neutral location and now I am also stuck in a boot loop.