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

Are you just basically asking for a remote but that’s hard-wired in the wall that can dim up/down and turn on/off other smart devices (in addition to being a hardwired light switch)?

If I’m not getting it, I’ll likely have someone else jump in as I just don’t get it :frowning: .

I have this exact setup in two of my daughter’s rooms so this is where I’m struggling to understand how our switch doesn’t do what you’re asking (aside from the LED bar tracking and reporting the switchmultilevelreport).

My example:

  • Red Series On/Off switch is wired to a switchable outlet
  • I don’t want this outlet to be switchable as it has an Amazon Alexa plugged in
  • I’ve disabled local and remote control on the switch so that now no one can turn off the outlet (so power can’t be cut to the outlet)
  • There are two bulbs in the room that are Philips Hue bulbs (not connected to the outlet)
  • Using the LZW30-SN, I’ve setup tap sequences to turn on/off the lights and change their colors

Granted, I didn’t put a dimmer on the outlet bc of code, but if I did, I could do the same thing (ie: make the switch a remote).

Then by adding in the switchmultilevelreport feature, we’d be able to have better control over the dimmable Hue bulbs while reflecting the proper status on the LED bar.

Sorry if I’m just not getting it – I’ll likely have @EricM_Inovelli or @jtronicus chime in as maybe they can explain better. I still need to read @jtronicus’s explanation in the other thread.

Yep, you’ve pretty much got it

This is kind of a big thing for an “aside from”. I want every switch in my house to behave the same, regardless if its wirelessly controlling a smart bulb or an electrical load (I don’t want to have to explain to my fiance or guests “Well this room doesn’t show you the brightness level on the LED, and instead of pressing and holding you have to double tap. But this other room is actually dimming the load so you press and hold… etc”. I’m looking for unification.

I can have what I want right now if I hardwire load to line - this is what I’m doing in my bedroom. But I’m going to be annoyed when I want or need to change (e.g. sell the house - light switches should work like people expect without a hub) and instead of changing a setting I have to pull the switch out and rewire.

Yeah I completely understand and meant no offense by insinuating this was not a big deal. I was merely trying to isolate the issue to understand what we currently have vs where the gap is. So apologies if it came off as otherwise.

One of the big things we’re focusing on in 2021 is user experience. Super important to us and me personally. Completely understand the pain-point in having to explain to the significant other and/or guests how the house works. Not fun at all.

I think I’m clear now in understanding what needs to be done. Thanks for hanging in there with me. Now time to try to explain this to the firmware engineer!

@jtronicus – is what @joshfee talking about and/or asking for align with how you envisioned SBM to work in your post here: Smart Bulb Mode Optimization Thread - #3 by jtronicus?

Hello all,

I attempted to update two of my dimmers to 1.52 tonight.

The first one went off without issue, upgraded ok, maintained functionality have tested a bunch and it is working as expected.

Went I went to update the second switch, it completed the upgrade and things looked ok. I went to disable the relay and enable smart bulb mode and it is now stuck in a loop (red/green/blue flashing in a continuous loop with my smart bulbs flickering on and off for a second or two). I tried air gapping and attempting to factory reset, but nothing has worked. Any thoughts on how I can force a factory reset easily so I can get a stable switch to edit settings or reflash?

I actually pulled it out and threw a dumb switch in place for now as it is currently unusable.

All suggestions appreciated :wink:


P.S. This is a non-neutral setup and I did enable option 52 (I came from a very old FW, 1.35). I’m thinking it has to do with option 52 and the non-neutral setup as that should be the only thing that was changed as far as settings are concerned. The first switch that updated without issue is a neutral setup and I also enabled the smart bulb option, but it looks to be working just fine.

No, that does NOT accomplish the same thing. That is how I had it set in V1.45 BEFORE Smart Bulb Mode was added in v1.47. It was close but not the same because setting the dimming rate to 0 does not DISABLE dimming, it just dims very fast. The killer is that Parameter 5 is restricted to 1-45 so the Minimum Level can not be set any higher than 45. Setting the dim rates and ramp rates to zero still allows the load to “dim” down to 45 instead of being fixed at 100%. V1.47 provided what I needed when it introduced Smart Bulb Mode which keeps the load at 100% with any SetLevel other than 0. V1.52 changes it so the load is ALWAYS 100% with any SetLevel INCLUDING 0 which breaks things for me because I want the load to be off when SetLevel is 0 and the load to be 100% with and SetLevel other than 0 (this is the v1.47 smart bulb behaviour).

@EricM_Inovelli PLEASE :pray: make v1.51 available as the parameter changes do NOT mimic the same behaviour as I have explained above.

YES YES THIS ^^^^^^^ ALL THIS ^^^^^^^
Although, I still like being able to turn the load ON/OFF (100% or 0%)

Understood and I certainly wouldn’t be using it for outlets, motors, appliances, etc. But there are many lights that are not dimmable, including most CFL’s and many types of modern LED bulbs. I have non-dimmable LED bulbs and CFLs in locations today that may get replaced with dimmable LEDs in the future. I may be wrong but I don’t believe running these lights with dimmers fixed at 100% can be much of a risk. And forcing us to swap out switches whenever the bulb type changes seems a bit excessive if the firmware would simply support a non-dimmable mode.

Yes, exactly!

If the only use for the LED Bar was to reflect status of the load then it might as well just be a single LED just like on the on/off switches. The multi-segment bar is what makes the Inovelli distinctive and stand out from other brands. EMBRACE IT :smiley: Start thinking outside the box :slight_smile: For starters, with Smart Bulbs, the load output from the switch should always be 100% but the LED Status Bar should reflect the Level of brightness (SetLevel) of the bulbs. There are MANY other possibilities. A countdown timer is one good example where the level of the bar is indicating time left rather than light intensity. This happens now with V1.47 and a Fade command is sent with Smart Bulb Mode enabled. Another example could be indicating relative number of bulbs lit when there is more than one bulb being controlled (versus the intensity of all bulbs). I have some ceiling can lights that have a “LED Halo” ring. Its activated by switching the fixture on/off/on. I can use the LED bar to indicate (0%=lights off, 50%=Halo on, 100%=main light on). Or how about using it to indicate the relative value of a luminance sensor that controls outdoor lights. Also possible could be the relative position of the garage door (garage closed=0ff, garage moving=50%, garage open=100%). Another thought is using it to indicate a Battery level. Basically, ANYTHING with a relative value could be indicated. I realize some of these examples belong in the “LED notifications” category, but there is [currently] no way to set the LED Bar “level” via the LED notifications. However a SetLevel() command currently does set the LED bar level and could be used for various indications when the load is non-dimmable.

I would really like to see an official response from Inovelli on this suggestion. I think it would be very easy to implement (possibly no more than text editing the restriction in the DTH) and it would effectively disable dimming as well as address issues with LEDs that need more than 50% to turn on. Is there some reason this is not being considered? I think I’m going to try a modified DTH just to see if that works. Its an easy edit to change the range from 1-45 to 1-99, but I don’t know if there is something hard-coded in the switch firmware that will override or prevent Minimum Level higher than 45. If the firmware is restricting it, then WHY? If this were implemented, it might also limit the range on the LED Status Bar (maybe or maybe not?). That might possibly limit some of the current LED Bar functionality and would not be ideal if it does. But I think its an easy way to provide a “non-dimming” setting without having to create a whole new parameter. Currently, setting the Minimum Level to 45 (the max) and sending a SetLeve(1) outputs 45% to the load but only lights up the lowest segment on the Led Status Bar, so it looks like the Led Bar still tracks SetLevel from 0-99 and hopefully will still do that if the Minimum Level were set to 99 and a SetLevel() was sent with something less than 99 (expecting load to stay at 100% but Led Bar track the SetLevel)

OK, that was @EricM_Inovelli’s thought. But that’s a good point about the max value on the lower threshold. Eric will have to comment.

@mamber It is a firmware limitation that was introduced to reduce the complications if a user were to set the minimum level higher than the maximum. For example, if you set the minimum to 99 and the maximum to 75. At the time we did not see a need to have a minimum that high, but do see it now. We can program around that scenario though. That’s why we have beta releases is to figure this stuff out.

Has anyone tested the new parameter 50? I set the delay to 100ms and 900ms and I can’t perceive a difference. I already tried excluding and including after updating the firmware to 1.52.

Is it coded into the actual firmware in the switch or just the Device Handler? Its pretty easy to program it so setting any Minimum forces the Maximum be the same or greater. Has that been done in any of the beta releases?

BTW, thanks for making 1.51 available on the download site :+1:

1 Like

Its coded in the firmware on the switch. There was a discussion about it a long time ago (I cant find the post), but I believe the main concern at the time was the lack of space on the device (firmware flash size). If you allow the minimum value to be set to anything up to 99, then you have to add additional checks/logic to ensure that the minimum value is not set higher than the maximum value.

The 500 series chipsets in these switches has very limited firmware space, and some features have already had to be removed to free up enough space for some of the enhancements added in the beta versions.

No problem. I did a total organizational change for the dimmer on the firmware site. Hopefully that didn’t cause any confusion.


@Eric_Inovelli I’m testing 1.52. I just want to say THANK YOU for adding an adjustable delay between 100ms and 900ms. That’s amazing. Now the switch reacts really fast when i single click.

Thank you so much for listening to our requests !


Thanks man, that means a lot :slight_smile:

That’s why I prefer to buy my stuff from Inovelli, they are listening ! Just to compare, ask for a change at GE…



I managed to get out of the loop by yanking the switch and powering it via an extension cord temporarily. Factory reset and managed to get it back.

As soon as I would disable the local relay and then attempt to enable smart bulb mode, it would get stuck in that boot loop and the only way I could seem to recover is to pull it out and hook it back up to external power (extension cord) to adjust the settings to default.

As an FYI, I am running 6 11W smart bulbs on that switch.

I understand space is limited, but lets be real. Its an extremely simple code segment:

  • IF (Min>Max) THEN Max:=Min

Also, v1.49 removed the local config mode which I’m sure freed up a LOT more space than one line of code :slight_smile:

V1.49 - 12/16/2020

Remove local configuration mode (to make space for extra features).

@stu1811 I have it working on 5 switches. If you set it to 100ms you should have to tap the switch at near superhuman speed to get scenes to activate. Are you sure you don’t have the delay disabled altogether?

I noticed that and I like the new layout. Thanks! :smiley:

I assume that the way you grouped the 1.41.bin with the 1.51 otz means that I should NOT use the v1.43 bin with it? Is that correct? If you hadn’t grouped them that way, I would’ve assumed I should use the v1.43 bin with v1.51 otz.

@EricM_Inovelli I just want to make sure the v1.41.bin + v1.52.otz grouping is intentional and not a typo. Can you confirm?

I agree completely! Many thanks to the crew at Inovelli for listening to us!:v:

If there’s something developers love to hear from a 3rd party, it’s how easy some sort of feature would be to implement…

I’m sure you mean well, but unless you’re involved with inovelli’s firmware, you really don’t know how easy or not something would be to implement. You’re making an assumption.


You should flash the set of files that are in the folder. otz 1.51 should be flashed with bin 1.41.