Firmware v1.52 (Beta) | LZW31-SN | Dimmer - Red Series (Gen 2)

Switches Firmware Discussion
42

@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:

  1. 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)
  2. 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.
  3. 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
43

@EricM_Inovelli I submitted a pull request on the SmartThings device handler to add parameter 50 :grin:

44

:laughing: Don’t jump off a bridge. LOL, I probably worded that incompletely. :blush: I understand their meaning individually. But it was comments in this other thread that muddied the water for me. :blush: LZW31-SN Internal Relay Disable - What's the point? - Wiring Discussion - Inovelli Community

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:

  1. 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)
  2. Allowing a value of 99 here would effectively disable all dimming but otherwise retain full control both local and remote.
2 Likes
45

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 :wink:

46

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
47

@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.

48

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.

49

You rock, thanks!

I also just posted the Hubitat driver update. I will be releasing the black series info soon as well.

3 Likes
50

Just to make sure we understand each other…because I’m pretty sure that won’t get the same functionality :thinking:

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). :thinking:

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)

51

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”

52

No that’s not it. Now you’re reading too much into it :wink:

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 :pray: 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

53

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?

54

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
55

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.

image
image1432×296 93.7 KB

(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:

image
image1094×784 86.5 KB

@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.

56

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.

57

@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 :slight_smile:

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!

58

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.

59

Pretty much to prevent accidental level changes. Like @mamber pointed out it would be nice to be able to intentionally set the level remotely to update the led bar but without having it affect the load at all.

I reallllly encourage you to stop thinking disabling local/remote control is a solution here, as it is not. I DO want to be able to update the logical state of the switch (turn it on, off, set its dim level) both locally and remotely - I just don’t want it to change the load.

It is really useful to have a smart device on the wall that I can use to communicate with the hub. Scenes are not a replacement, as scenes don’t allow you to press and hold to gradually dim the value from 0 - 100%. Also even for on/off, to use scenes to accomplish this in home assistant I would have to create a virtual switch and have automations that turn it on and off when it sees

the scene events… this is so unnecessarily complicated when I already have a switch device that does all of the things I want… I just don’t want it to affect the power sent to my smart bulb.

Seems like a farfetched use case IMO - people will still have smart bulbs plugged into always-on outlets and not be able to kill power to them remotely. Maybe someone wants this as a feature, but it is definitely not required from a safety perspective.

I haven’t upgraded to 1.52 beta yet to test this, so maybe it is close to working, but it still sounds like power will be cut if I flip the switch off remotely (i.e. from automation), which prevents automations talking to the bulb until I remotely flip the switch back on

See above for why scenes are not a solution - they fire every time you press the button (i.e. I only want an event when there’s a state change), and also there is no dimming. I want to press and hold the dimmer to change the switch level, have that level reported to the hub, and automate based on that level. Scenes are great for 1-time events, but not for controlling state (that’s what the switch is supposed to do for me).

Haha! Basically just trying to say that disabling local/remote control is useful, but that it is not related in any way to the problems here.

Fair enough, and I don’t think its a problem. Key point is remotely setting the level to 50% should update the LED to 50% but keep the power output at 100%.

Haha completely understand. Yeah I just got my 10 switches in and started installing and was pretty disappointed when I found out that the “disable relay” option doesn’t completely disable the relay. But seeing you guys engage with the community to improve the firmware has me optimistic.

60

Ok, but I guess what is the point of the LED bar moving and not reflecting the status of the load? I’m not pushing back, I promise – I’m just trying to really understand the use-case here. I see count-down timer suggested, but outside of that, I’m not sure what the use-case would be. Again, just curious more than anything as we also have to explain this to the firmware engineers where English is not their first language.

I’m really trying to understand, I promise. I’m not sure why it’s not computing in my head or the rest of the team’s.

I think I understand what you’re saying and I think what it boils down to is you want the LED bar to sync with the smart load, right?

Can I ask what the point of this is? Why do you want to change the switch but not have it reflect the at the load?

The way it’s setup now is that the power going to the load is constant (as smart bulbs need 100% power) and if you want to change the intensity of the smart bulb you do so via either your app/voice assistant (by telling the bulb to raise/lower intensity) or you do it via the switch (association or scene control – and yes, I’ll get to your next paragraph below to address that concern).

So, I can’t figure out why you’d need control of the switch to turn on/off or dim your bulb. Again, I’m likely missing something and I apologize.

Scenes do allow you to do this, but I think I may be tracking in my theory that really what everything boils down to is a way to have the LED bar indicate where the smart bulb needs to be at virtually.

I can’t remember off the top of my head how to do this and maybe @EricM_Inovelli can explain better, but essentially with scenes you have a hold down scene and a release scene. When you hold down a scene command is sent and with some hubs (I know Hubitat can do this as I have this setup with Hue bulbs) it starts the dim up (or down) process and then when you release the paddle another scene command is sent to the hub and it tells the bulb to stop digitally dimming.

The disconnect is the LED bar will not notify you where you’re at so there’s a bit of guess work.

However, as I was messing around with it a bit more, I think I have had a breakthrough in how we could solve this potentially – again, I’m not a firmware engineer, so I’m not sure if it’s possible.

Under normal circumstances, when SBM (or local and/or remote control) are not active, when you dim up and down on the switch and release, the switch sends a, “SwitchMultiLevelReport” to the hub (ie: 60 = 60%). However, when SBM/local/remote are enabled, the switch no longer sends that report (it only reports the scene commands).

So, if we could somehow make the switch send the SwitchMultiLevelReport while SBM is enabled, you could set an automation to send that level to the smart bulb and if we can isolate the LED bar, it could tell the bar as well to go to 60. Does that make sense and is that what you’re getting at?

Noted – you can still enable remote protection separately, so we’ll likely keep this as is. I’m not familiar with HA though, so is it a PITA to do this?

Yes it will be cut remotely unless remote control is on. For your automations, we would encourage you to use your bulbs instead of the switch if you want to automate your bulbs. But again, I’m likely missing something as to why you’d want to use the switch.

Well I guess I should’ve read further down before having my breakthrough – I think we’re saying the same thing now, right (ie: SwitchMultiLevelReport value)?

Fingers crossed I’m finally understanding. I also may move our convo over to the Smart Bulb Mode convo just an FYI.

1 Like
61

This is more or less what I mean by the “logical state”. The switch would still keep track of the logical state (i.e. the LED, starting value next time you press/hold the paddle), but would not necessarily use that state to change the load (depending on what smartbulb mode you have).

Let me maybe try to explain the general desire differently. Forget about controlling a load at the wall entirely - chop the load screw off of the inovelli red dimmer. There’s still a super useful device there - it keeps track of a value, lets you toggle it on/off, shows you its state on the led, display notification effects on the LED. It wires directly into your wall so that you don’t have to change batteries, and you can reuse that hole in the wall that would otherwise be wasted. That is a great piece of hardware that integrates nicely into my room and lets me do cool home automation things with it. If you sold this device I’d probably buy it.

Now adding the ability to control an electrical load is a killer feature, because now I can use it in cases where there was already a ceiling light or whatever wired into that hole in the wall. But I don’t always need that feature and with smart bulbs its an anti-feature.

To give you a real life example, the first zwave switch I bought (which I’m planning to replace with an inovelli red) was a jasco toggle switch. I got it because I had an existing switch on my wall that controlled an outlet that made perfect sense as the living room light, but the outlet was not where I wanted to put lighting. So I put in the jasco and can control some bulbs across the room. When I flip the switch a loud relay clicks and it toggles power to the outlet - but I don’t want it to toggle power because I don’t want that outlet to be switched anymore (since I’m not using it for lighting). Its annoying. My other options were to get a battery powered wall controller and stick it on my wall… but then I’d still have this toggle switch that does nothing.