Ah, I was doing “Refresh”. “Configure” seems to fix it. Now to wake up those other dimmers…
You’re on a roll, that did the trick. Thanks again!
I ran the gambit of tests on this last night, and I feel like I am living in a utopian future world where I have literally zero requests to improve this switch. I am truly thankful to @EricM_Inovelli and his dev team for making this a literal “dream” switch.
Piggybacking off of others, I do think there is room for research and development on the following, either for firmware updates or v3 of the dimmer switch (in no particular order):
3-way On/Off SBM mode
Min level increase (corresponding max level min input increase)
Ramping choppiness fix
Toggle dimmer to default level on button 1 press, regardless of state (currently only when off).
I’m just over the moon right now!!!
3 Likes
I mostly agree 
but did you mean “utopian” world? 
A dystopian world is bad and undesirable 
Beta 1.54 was unusable for me (due to the non-tap-off bug) but the quick fix to beta 1.55 solved that and I can run with it now 
Thanks @EricM_Inovelli for getting that out so quickly! 
However, 3-way SBM mode is still acting very weird. Since this is beta firmware that’s ok with me. But in my utopian world, this would either need to be fixed, or at least dis-allowed in the device handler before it becomes official production release.
I agree with that wish-list
But I would modify #1 to include both modes of SBM (mode1=on/off, mode2=always on)
And I would add #5
Better LED bar dimming using gamma curve (top example in illustration below)
(initial request posted here: LED Bar Intensity values - big gap/jump between 10% and 20%)
Haha you are correct! Fixed.
I remember another one I’d like to add:
#6 Make the Dimming Speed and Ramp Rate params be 100mS increments not 1-sec increments
3 Likes
Thanks, that is a huge compliment. We will continue to try and bring the features and enhancements that the community is asking for!
3 Likes
Hi @EricM_Inovelli ,
I updated all of my red dimmers to the 1.55 target 0 firmware (with hubitat) and that went fine.
However, when I updated the target 1 firmware to 1.44 the first time on one of my dimmers it failed and bricked the device. Right now its not responding to anything. I ried air gapping it and also resetting it by holding the button down for 20s with no luck.
Anything more I could try or is it dead?
Does the LED bar do anything when you air gap it? I had a switch that would boot up after air gap but became completely unresponsive after booting. I was able to get an exclusion to happen as it was booting and that allowed it to start working again.
Nope. Completely dead after attempting the update. No lights or anything. Even after the air gap.
I updated the target 1 firmware to 1.44
Hopefully you used the v1.44.bin file for target 1 and not the v1.44.otz file
Yup. Double checked that. Used the right file. One of my switches is fully upgraded. This one failed partly through and got bricked. I can’t get it back to life.
Has anyone else noticed that this firmware or another recent version (I was updating from 1.48) seems to have resulted in a different minimum dimming level being required?
Example, I have ~15 Halo RL56129S1EWHR on a four different circuits. Since updating to firmware v1.55 I’ve had to increase parameter 5 to as high as 50 on one of these circuits where a value 38 was working 100% reliably previously (and continues to work on the other circuits). Really the only thing different about this circuit compared to the others is that it has two extra lights and is also using a dumb auxiliary switch.
I have not tried flashing back to v1.48 to confirm if this issue goes away.
EDIT: I am actually still able to reproduce this on the older firmware. Very strange. I’m now wondering if changing the CCT setting makes a difference (I’ve changed it twice since I originally tested these).
What platform are you using? That parameter is supposedly limited to 45 max - although its been requested to update the firmware to allow higher values. Even with v1.55 I still can’t set it above 45 with the Hubitat driver but I wish I could set it to 50 or even higher…
I’ve read this thread, but i’m still not sure how SBM different than me disabling the relay by hitting the config button 8 times. Does SBM also ignore zwave actions to turn off/on power?
I’m using Z-Wave JS on Home Assistant. I can definitely set this to higher than 45 on v1.55.
Have you queried the device parameters to see if it actually gets set in the device? This previous thread indicates that the limit is hardcoded in the firmware not the device handler. Its possible that HA is not restricting the range, but the internal firmware may just be ignoring the 50 and internally limiting it to 45 (or less).
I’m having some issues with my 3-way with this update, on a non-smart bulb. It seems like my AUX switch turns on and off the dimmer, I hear a click and the LED dims and it says “off” in Hubitat, but the load does not turn on and off unless I use the master switch. I’ve tried 3-way toggle and 3-way momentary. I had to have it on 3-way momentary before this update.
We don’t say “disable the relay” anymore; it is now “disable local control”. SBM just ensures that the load always has 100% power, so if you turn the switch device itself on/off it will just affect the LED and switch state, but it will still be outputting 100% power to the smart bulbs, which you would have to control using scenes. Same for dimming, it will change the level of the LED but will still output 100% power to the load.
We definitely do say it still. @Eric_Inovelli has a sweater that says it. It will be here forever!
3 Likes