LOL. I was thinking more along the lines of some combination of âdisable relayâ, âdisable local controlâ, and âdisable remote controlâ. Might get me close, but admittedly I donât fully understand the meaning and function of those settings 
disable local control - Disables control of the relay via physical interfaction. Commands are still send to the hub via zwave and scenes work. This is useful when a switch is associated with zwave bulb. The dim, on, and off commands are forwarded to the bulb which then does what you want.
disable remote control - same as local except it blocks zwave commands vs physical interaction with switch
1 Like
Just so Iâm understanding correctly, is it as simple as youâd like a way to turn on/off a non-dimmable load without using scene control? Iâm likely missing something, and the caffeine hasnât kicked in yet lol.
1 Like
@EricM_Inovelli Iâm planning on replacing pretty much all of my switches with Red Dimmer switches, even in places where I may not really care about dimming (since installing hardware takes some effort Iâd rather have the red dimmers everywhere for future flexibility). This means I will have a variety of device types hooked up to my Red dimmers, and theyâll each need slightly different behavior.
Dumb bulb, dimmable
This one is easy - it should behave like the red dimmers behave out of the box. I should be able to toggle on/off, as well as set level locally and remotely. The on/off/level is reflected in the load.
Dumb bulb, non dimmable
For these I obviously want to control the load on/off (both locally and remotely). I also want to disable the dimming function so that the LED bar always shows 100% when on, and pressing/holding the paddle does not send level updates. If the I try to remotely set a level, the switch should ignore it. I believe this is what @mamber wants. I planned on just replacing my non-dimmable bulbs with dimmable ones to avoid this problem, but it would be nice if there was a setting for this setup.
Smart bulb
Smart bulbs should always be powered⌠always. No set of commands local or remote should be able to cut power to the device, as it is important for home automation that the device is always connected to the hub. This is especially important for non-zwave bulbs (unfortunately there are just not that many zwave bulbs on the market - zigbee is king for now). If I want an automation that will fade a zigbee light from off to on, it needs to be connected to the hub even when it is âoffâ (i.e. brightness 0%). If I first had to âturn on the switchâ so the bulb can get power, the bulb will come on to its last state rather than ramping on.
Depending on your smart bulb, you may or may not want to disable dimming as well (in the same way as the non-dimmable section above). For instance, with a zwave bulb thatâs associated, dimming works really nicely and Iâd want enabled. For a zigbee bulb, I may or may not want dimming to be enabled (depending on if Iâm okay with the latency when pressing/holding to change level).
My ideal solution
(While I am a software engineer, I know nothing about firmware development or what limitations you have)
The way I see it, I think that there are two distinct things that people want to be able to control. Thereâs the logical mode (whether the device keeps track of its dimming level), and the physical mode (how does the switch reflect its logical state on the load wire).
Note that the âDisable local/remote controlâ options are orthogonal to the logical state, and would still make sense. For instance: âI want the switch to be dimmable (logical option), but always send 100% power (physical option), but donât let me change the level from the switch (local control option)â
For the logical mode, I think all that is needed is an option for âDimming enabledâ or âDimming disabledâ. When dimming is disabled, any attempts to change it (local or remote) are ignored, and therefore the level is always at 100% or 0%.
For the physical mode, I think there would be either 2 or 3 options:
- Always on - This is effectively the same as hardwiring load to line, but through configuration (which makes it easier to change later than having to rewire - i.e. when you go to sell your house and want things to âjust workâ for the buyer)
- All or nothing - Send either 100% or 0% depending on the on/off state of the switch. While the switch may or may not have âDimming enabledâ, the level is ignored when determining the load.
Iâm not 100% sure what the use case for this would be, but it doesnât seem like an unreasonable option.@Mamber suggested that they like to be able to use the level LED display as a countdown timer, so this would be a great use case. - Conventional dimming - Send a variable load depending on the level. When âDimming disabledâ the level will always be 100% or 0%, so this is effectively the same as âall or nothingâ.
Depending on how hard it is to add new options, there are only a few combinations so a single option with the 6 combinations wouldnât be too bad.
2 Likes
Donât jump off a bridge. LOL, I probably worded that incompletely. 
I understand their meaning individually. But it was comments in this other thread that muddied the water for me. LZW31-SN Internal Relay Disable - What's the point?
Yeah, pretty much its that simple. Thatâs how it works now with V1.47. The changes to v1.52 will break that.
My long diatribe was explaining that I realize the setting called âsmart bulb modeâ probably makes more sense to work like v1.52 so Iâm just looking for another way to get the v1.47 behaviour which should probably be called ânon-dimmable loadâ or âdimming disabledâ or something like that.
One way to do this, which I think would be very simple - without needing to create a new parameter - is to allow the existing parameter #5 âMinimum Levelâ to be 99 (allow a range of 1-99 instead of the current restriction of 1-45). This would have a two-fold benefit:
- Some dimmable LEDâs need minimum of 50 or more to turn on. (They can often be dimmed lower, but they donât turn on unless the minimum is over 50)
- Allowing a value of 99 here would effectively disable all dimming but otherwise retain full control both local and remote.
2 Likes
YES. This is the same situation I am in. Prefer to install Red Dimmers everywhere (for consistency and future flexibility) and able to disable dimming when they happen to have non-dimmable loads.
I mostly agree. However, Iâm on the fence about the LED bar always showing 100%. Iâve grown accustomed to how it works now in v1.47 where the load is 100% on or off but the LED bar still tracks the logical level setting. Its another way to give some visual indication of things. Clearly a non-dimmable bulb is on or off, but one way I use this now is when the light is timed to go off after a certain amount of time. The way it works now with v1.47, the LED bar will slowly âcount downâ giving a visual indication of how much time is left before the light turns off. So even though the light is not getting dimmer, its still handy to see the âdimmingâ LED bar as a countdown indicator.
Having the LED bar continue to track logical level allows me to send a SetLevel() command and have the LED bar indicate various levels of something other than bulb intensity. There is currently no way that I know of to do that with LED Notifications parameters.
Donât get me wrong. Iâm not saying its a requirement. I could be swayed away from it. But since thatâs how it works now, Iâve been taking advantage of that âfeatureâ and its never fun when we have to give up features 
Thatâs a great use case, and would fit perfectly into the solution I described. You would set the logical mode to âdimmableâ and the phyiscal mode to âall or nothingâ. I didnât originally have a good use case for the âall or nothingâ option but a countdown timer is a really great one.
1 Like
@EricM_Inovelli can you make the v1.51 (or v1.49) firmware available? Looking at the release notes, it appears I can get the new âmulti-tap delayâ setting in 1.49 (or .51) without having to lose my âsmart bulb with on/offâ that goes away (always on) in v1.52
V1.52 - 01/22/2021
Modified Smart Bulb Mode so that the output can only be turned off by sending a BasicSet(0x00).
Fixed: Solve the problem that the power measured by the light is 5W when the load is not connected (caused by inaccurate power measurement at extremely low power consumption).
V1.51 - 01/08/2021
Fixed: Low brightness would brighten and then darken when being dimmed.
Fixed: Issue where the same value of parameter 5 (Minimum Level) appears inconsistently when both parameters 21 (Power Type =1 - Neutral) and 22 (Switch Type = 1 â 3-Way) are set to 1.
V1.49 - 12/16/2020
Remove local configuration mode (to make space for extra features).
Adding parameter 50 to adjust the delay when parameter 51 is set to 1. 1=100ms, 2=200ms, 3=300ms, etc.
In 1.52, you should still be able to press the config button 8x to âdisable the local relayâ and get the same functionality you were seeing in previous firmware versions.
You rock, thanks!
I also just posted the Hubitat driver update. I will be releasing the black series info soon as well.
3 Likes
Just to make sure we understand each otherâŚbecause Iâm pretty sure that wonât get the same functionality
Are you saying that disabling the internal relay will still allow local on/off control but only disables dimming? That does not match with anything else Iâve read about it. I thought a disable relay would also disable the physical on/off of the load (always on or always off).
And as I understand it I need the relay to work in a 3-way or 4-way with standard aux switches, right? (most of my switches are 3-way)
I must have misread your post and didnt realize what you were trying to do. I think I understand now (turn off the light instantly, but after a delay, and use the LED strip to show a âcountdownâ until the lights turn off). If my new understanding is correct, disabling the local relay will not do what you are looking for.
Personally, I think what you are trying to do would be better served by a separate config parameter, similar to parameter 8 (auto-off timer), but as a 1-time command and to have it show a progress bar âcountdownâ
No thatâs not it. Now youâre reading too much into it
In the simplest terms, I want to disable dimming but still turn the load on/off from the switch.
The common use for this is with non-dimmable lights. This is how it currently works, and according to the Release Notes, still works in v1.51 if I can get my hands on it. V1.52 breaks this (although I understand it fixes the true purpose of the âsmart bulb modeâ)
(Please @EricM_Inovelli 
if you donât want to post v1.51 publicly can you send it to me privately?)
âdisable dimmingâ could be implemented as a new parameter but is not really necessary since it could also be implemented very simply by allowing the existing Param5 âMinimum Levelâ to have a range of 1-99. That would solve two issues by providing a non-dimming function (set min level to 99) as well as supporting lights that need more than 50% to turn on (set min level to something higher than 50)
The âcountdown timerâ was just an example of still using the LED bar even when the load is non-dimable. That was my rebuttal to the suggestion that LED bar should always be 100% if a non-dimming mode was enabled (which I donât agree with). A delayed countdown function is not my request here, that was just one of many possible uses for the LED bar even if the load is non-dimmable
Iâm having a problem after installing the new Hubitat driver. Iâve updated most, but not all of my dimmers to 1.52 and they worked fine before the driver update. But now the âcurrent statesâ information doesnât update and I see no log activity with local or remote control. The only exception is two dimmers that are running with no security and 1.52 work properly, but the dimmers with S2 security and 1.52 arenât updating their status (not sure if security level is related or a coincidence). I have a couple dimmers still running 1.48 and they update their current state properly. I didnât save the previous version of the driver to try switching back and confirm for sure itâs the cause. Is anyone else seeing this?
Try this: Set parameter 1 to â0â and set default z-wave and local levels to â99â. Reportedly, this will mimic the Smart Bulb Mode in 1.47.
1 Like
I like easy lol.
Makes sense. Iâll let @EricM_Inovelli comment on ignoring level updates as Iâm not sure if thatâs possible.
Question for ya around the remote level protection â is this just a security feature (ie: if you by accident set the level on the switch in your UI) or is there another reason Iâm not seeing? Just curious.
I just wanted to note that the overall premise is possible right now aside from the remotely ignoring level updates. If you set Parameter 1 to 0, you should be able to turn the dimmer on/off instantly from 0-100. From there Parameters 2-4 will sync so that when you press/hold it will be instant.
(sorry for the low-res image)
Yes, correct. This is how itâs setup now if you disable local or remote control, nothing will cut power to the switch be it at the switch itself (local) or via your hub/gateway (remote). With SBM enabled, the switch delivers 100% power to the bulb and then disables local control of the switch.
We kept Remote control enabled bc of safety reasons (ie: youâre away from your house, but your smart smoke alarm alerts you to a problem â you can cut power to that bulb). If you want to disable remote control, there is a separate feature to do so (similarly to how you can disable local control separately from SBM).
Iâm confused here â can you clarify? The bulb should always be receiving 100% power from the switch. The bulb is instead dimmed down in intensity via the, âsmartsâ inside the bulb itself, not the amount of power being throttled from the switch. Iâm not an electrician nor engineer so apologies if that didnât make sense or I used the wrong vocab lol.
I believe you can accomplish this via scene control if Associations are not an option (ie: tap up 1x = smart bulb turns on via switch sending a signal to your hub, tap down 1x = smart bulb turns off via switch sending a signal to your hub).
There may be a better way to do it â but this is how Iâve accomplished it on Hubitat using Hue bulbs and our switches.
Good news for you is that I know little about either! I can make you a cool picture that sells switches and hang out with you guys in the forum though lol.
Agree.
Fun fact, this is an actual screenshot from a convo a couple weeks back:
@Bry used the word segue and I had to look it up bc I thought it was some French word (said: seg-oo).
That said, you can imagine my brain with the word orthogonal lol.
anywayâŚ
Iâll have to have @EricM_Inovelli or someone from the manufacturer tackle this one. Itâs my understanding that the hardware is different in the switch in that it does not have a relay similar to the on/off switch â so it canât do a binary on/off, but rather we, âtrickâ it into turning on and off fast.
This is why we do not suggest putting these on non-dimmable loads. While we can trick it to do work, what happens if it fails and reverts back to being a dimmer? Weâd hate to be liable for that expensive non-dimmable appliance.
So, while we may be able to solve this via firmware, the hardware in a dimmer is much different and the reason why we canât endorse putting it on outlets or other non-dimmable devices.
My brain is fried right now â Iâll have to come back to read this tbh. I love the energy and passion though. Thank you for breaking this down.
LA_MATT.T, yes, I am having the exact same issue with two 31-SN switches. Was working just fine prior to 1.52 firmware update.
@Bry 's solve below is how you would accomplish what youâre trying to do. Good news is we havenât changed that feature since the beginning 
Bad news is we still do not recommend putting dimmers on non-dimmable devices for safety reasons and it will void the warranty, but below is how you would accomplish it if you want to take a chance!
I can post it up on the server, but the recommendations about changing a couple parameters may work for you so try that out first.
@jtronicus I get what you are saying about being able to turn off the device via z-wave commands. I originally thought maybe just have it turn off with a âbasicSet(0x00)â but do not have it turn off when using switchMultilevelSet(0x00). If all hubs use switchMultilevelSet when turning the device off then this would take care of it. Iâm not sure that is the case, but will look into it. Either way we will get it working the way you are describing.