This firmware has several bug fixes and further tries to optimize smart bulb mode. Please let us know any feedback!
Edit: We just released 1.55 as a quick fix for the physical button not turning the device off in on / off mode.
1 Like
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. 
@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 
Several things Iāve noticed so far:
-
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
-
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.
-
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
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. 
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 
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 
). 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 
that I probably donāt have the 3-way wired correctly. 
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. 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 