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.
1 Like
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.
1 Like
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).
I see what you are saying though.
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)
Here’s a video:
https://1drv.ms/v/s!Ai8d7v4m9cAQnNc69_XGqDcRL7Houg?e=mEiWhM
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.
Press config button 8x. Maybe disable local control got triggered on?
I just factory reset the switch and I have it working again so I can’t try that. I did try disabling/enabling local control via the GUI in Hubitat to no avail. Odd we both had this issue coming from 1.35, perhaps something to look into.
In short a factory reset brings it back to life.
1 Like
It seems that I can reproduce the issue. If I disable the local relay (config x8) and then enable ‘smart bulb mode’ the switch will start a boot loop. The only way I can recover is to hook up the switch to an alternate power source and factory reset. Not sure if @wogfun had similar settings (disabled local relay and smart bulb mode toggled on in a non-neutral set up)?
I disagree. A zwave dimmer switch should always “know” the current state of all its settings, including dimming level.
I think this discussion got a little side-tracked. There should be no debate about whether the device knows this or not because I believe its a zwave requirement and I doubt it would pass zwave certification if it didn’t do it. The debate is about the value that will be stored/reported when the dimmer is set for SBM and locks the physical load at 100%. Many of us believe the internally stored SetLevel() value should still follow the requested dimming range (either locally or remotely) even though the physical load terminal is being locked at 100%. This is currently how it behaves without SBM and we think there should be no change to this behaviour even whan SBM is enabled. The only change that SBM should do is lock the physical load terminal at 100%. Everything else should work the same as before, including the appearance (LED Bar status and internal dimming level) of dimming.
1 Like
First time using the dimmer as a regular dimmer. (I’ve used the dimmer as a smart bulb controller.)
When I dim up or down (at the physical device or via Z-Wave) there is a very slight stutter in the lights during the ramp. Other dimmers do not exhibit this behavior. Is this expected behavior?
Also, I had the inability to control the device, both physical and via Z-Wave, after updating from 1.35, similar to one of the above posts. I was able to regain control by changing a parameter, but I don’t remember which one
I believe he is saying there is a delay from when you hold down the paddle with the intention of dimming up or down there is a noticeable delay before it starts dimming. I don’t mean to speak on his behalf, but I’m seeing the same thing.
I think we were expecting that the new parameter which allows us to configure the “Button Press Delay” would also apply to the delay before dimming. Basically, one timer that is used to determine if the switch is “pushed” or “held”. That appears to not be the case. The hold-delay for dimming seems to still be very similar to the old delay (around 700ms) even with the new firmware and the delay set lower
@Eric_Inovelli @EricM_Inovelli Please do you guys expect to have a firmware with a configurable delay for the on/offs soon?
Thanks!
Yeah, we’re working on it – we’re trying to get the Dimmers correct before implementing the same/similar changes to the On/Off’s.
It’s also Chinese New Year so the manufacturer won’t be back in the office until the 18th 
Thanks for the response… Wasn’t sure if you already had a file somewhere that just needed to be discovered like the 1.52 file :)… Would wait for it then!
Also, please are you clear on the hold delay now?
Thanks!
Got it – ok, yes this is clear now. I guess I just never noticed this honestly (or just got used to it), but I see what you’re talking about.
I’ll have to figure out a way to better explain this across the language barrier, but the good news is at least I understand what the feature you’re asking for is.
Got it, makes sense – thank you!
Yes – thanks for your patience 
4 Likes
Just upgraded to this firmware, verifying all the functionality. Right away I notice something odd with Parameter 3 (how fast or slow the light goes from on to off to on). No matter what I set this to (Tried as high as 10 seconds) the light (incandescent dumb load) goes inconstantly on and off from the switch paddle.
Can anyone else confirm this?
Smart bulb mode enabled?