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

I just uploaded the updated driver for Hubitat and the updated device handler for SmartThings for those that want to test the change to parameter 52.

1 Like

Awesome! Looks like this has a few features I was waiting for.

I recently upgraded my home assistant to zwave js, does anyone know what the upgrade path looks like to get the new 52 parameter value added for smart bulb only? Is this something I can still enable through zwave_js.set_value?

I dont think zwavejs will allow you to pass a value that is outside the range defined in the config file. Since the current config file has a maximum value of 1, you cannot pass a 2 to it. You will likely need an updated config file.

However… If you are using the web interface for zwavejs2mqtt you may be able to use the custom configuration option to set the value outside the range defines in the config file.

1 Like

OMGEEEEEEEEEEEEEEEEEEEEEEEEEEE, so excited to try!

A HUGE shoutout to Inovelli for not only creating the best switch on the market, but continual improvement based on end user feedback. Their words and actions are one and the same!

I’ll get started as soon as the house is empty!

2 Likes

Added ZwaveJS config PR:

1 Like

Oooooh I’m loading it up right now. Looking forward to trying it out. :nerd_face:

@EricM_Inovelli I see Parameter 5 (Minimum Level) is still limited to 45, which is too low for some LEDs to turn on. Based on previous discussions I was hoping to see this value increased in this new beta release. Is this change still on your list and something we can hope to see in the near future?

Well…I’m sorry to report its not looking good from my testing :slightly_frowning_face:
Several things I’ve noticed so far:

  1. Parameter52=2 (Smart Bulb Enabled) does not keep the load on all the time. Load still turns on/off with local tap up/down and zwave on/off

  2. Parameter52=1 (On/Off Only) seems to work exactly the same as above … no difference between setting 1 or 2. And, yes, I have set/saved/unset/saved the parameter to make sure the memory is initialized properly after the firmware update.

  3. Every level change toggles the load on/off. This includes dimming up/down with the paddle as well as setLevel(x) zwave commands. Unfortunately this makes it unusable in either mode 1 or 2 :cry:

I’m still testing, but so far its unusable for me like this. I usually have no problems running beta firmware and working around some of the limitations. But I sadly have to fall back on this one and maybe load it on a spare for testing only. :neutral_face:

This is how I updated my own config file. It seemed to work, but I am not sure if it is the correct way to do it (showing only the parameter 52 part):

		"52": {
			"$if": "firmwareVersion >= 1.47 && firmwareVersion < 1.54",
			"label": "Smart Bulb Mode",
			"description": "Optimize power output to be more compatible with smart bulbs. This prevents the dimmer from being able to dim & makes it act like an ON / OFF switch.",
			"valueSize": 1,
			"minValue": 0,
			"maxValue": 1,
			"defaultValue": 0,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": false,
			"options": [
				{
					"label": "Disabled",
					"value": 0
				},
				{
					"label": "Enabled",
					"value": 1
				}
			]
		},
		"52": {
			"$if": "firmwareVersion >= 1.54",
			"label": "Smart Bulb Mode",
			"description": "Optimize power output to be more compatible with smart bulbs. This prevents the dimmer from being able to dim & makes it act like an ON / OFF switch.",
			"valueSize": 1,
			"minValue": 0,
			"maxValue": 2,
			"defaultValue": 0,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": false,
			"options": [
				{
					"label": "Normal",
					"value": 0
				},
				{
					"label": "On/Off",
					"value": 1
				},
				{
					"label": "Smart Bulb (Always On)",
					"value": 2
				}                
			]
		}

This is working fine for me. turned the switch itself off by zwave or on the physical switch, and the bulb still has power. Did you flash both target 0 and target 1? Perhaps the firmware update didnt take properly?

I did, and actually did it twice and watched it to successful completion just to make sure :slight_smile:

With that said, this particular dimmer was updated from v1.51, skipping v1.52. That shouldn’t usually matter, but maybe in this case? I’ll try updating a different dimmer that is at v1.52 now…

Mine went from 1.53 (I updated before it got pulled) → 1.54.

I found that I did have to re-save parameters 50 and 51 after updating the firmware though.

Yeah I was wondering about that. I did the re-save on param 52, but not 50 and 51. I’ll try that…

I said the same in my PR, I have no idea how they are presenting different firmware version filters lol.

Glad to hear you are having positive results!

OK, I’ve been doing a lot more testing and think I have it narrowed down better. The first switch I had problems with is in a 3-way with a dumb switch. I subsequently updated a different “load only” non-3-way to v1.54 and that seems to be working properly.

What I’m seeing only happens in a 3-way-toggle situation (parameter 22=1). And interestingly, it only happens when the dumb switch is in one of the two positions. I haven’t opened the wallboxes to see which path it is, but I highly suspect the problem is happening when the 3-way circuit is flowing through the Traveler terminal instead of the Load terminal.

Thinking about it now, I don’t recall any discussion about how ‘smart bulb’ mode should work in a 3-way. This is probably not as common, but still should be possible (I think :thinking:). I suspect what I’m seeing is that the Traveler terminal is still being switched on/off even when smart mode is enabled. So when the 3-way is switched through the Load terminal its ‘always on’. But when the 3-way is switched through the Traveler terminal weird things happen.

I know what you’re thinking :laughing: that I probably don’t have the 3-way wired correctly. :smile: And while I haven’t yet opened up the wallboxes to double-check, I am very familiar with 3-way wiring, how it works, and the proper way to wire them. I acknowledge we all can make mistakes, but I can also tell you that the 3-way works properly if smart-bulb mode is disabled and also the 3-way has been working properly for months with no changes to the wiring. The only change was to the firmware.

It would be nice if someone else can try this new firmware in a 3-way setup and test if/how it works with Smart Bulb Mode enabled.

Sadly, it’s not. :cry: At least with prior firmware, a 3-way dumb switch overrides local protection. I don’t know if the latest firmware is supposed to change that, but guess is that what you’re seeing is expected behavior.

TBH, 3-way SBM is not something I need. It just happened to be the first dimmer I chose to update to v1.54 and start testing.

With that said, I don’t understand why it shouldn’t be possible (for other people who might want it). The internal relay should be toggling the output between the Load and Traveler terminals. The SBM logic should apply equally to the common (input) side of the spdt relay. That way it should still all work regardless of which position the dumb switch is in.

Of course I’m talking just ‘in theory’. I don’t know the specific details of the sensing logic in the switch that allows it to detect which terminal (load or traveler) is the active one. It may be complicated in a way that makes my previous paragraph more difficult than it should be.

In any case, I think this is an area that may need an official Inovelli statement regarding SBM in a 3-way. Should it work? If so, my testing indicates its still buggy in v1.54. If its not intended to be supported then we need to document that and probably update the driver to disallow the unsupported mode(s).

I guess EricM will follow up if it’s any different with this release.

I understand that disabling local protection on the line (smart) switch does not prevent the dumb switch from turning on/off. But what is the connection between local protection and SBM? With SBM enabled we still want the buttons to work on all the switches

I also found this quote from the SBM Optimization Thread

It says SBM should work in a 3-way setting with a dumb switch. It then goes on to say “currently” only with aux or zwave association. That was back in January so that kinda-sorta tells me that there is some level of expectation for it to work in one of these beta releases :thinking:

Up until this release, local protection (i.e. local control) and SBM were two separate functions. SBM keeps the bulb at 99% and disabling local control prevents the switch from physically cutting power to whatever is wired to it.

As I understand it, this release puts the 2 functions together (because, apparently, some just couldn’t understand how to work it in two pieces . . but I digress). Unless I misunderstood, you felt this firmware wasn’t working because you were able to turn the bulb off with the dumb switch. I think that was always the case and I don’t think this release changed that.

So I guess you would now say that DLC is sorta related as both functions have been combined into one.

@Eric_Inovelli Seems to have said two opposite things in the same thread. I was just basing my comments on the comment I quoted.

I think what @mamber is saying is that when Smart Bulb mode is turned on, the load should always output 100%, regardless of whether it is being controlled via zwave, locally, smart aux, or dumb aux.

It sounds like with 1.54, a dumb aux switch is still causing the switch to turn the load off.

Is this a correct understanding?