Yeah you probably missed this in my lengthy post…
ooo shiny. distracted. you got it.
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
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.
@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 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.
@EricM_Inovelli I submitted a pull request on the SmartThings device handler to add parameter 50
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.
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.
@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.
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.
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.
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.
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.