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.
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 ).
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.
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,
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 think this is an area that may need an official Inovelli statement regarding SBM in a 3-way.
3-Way (or Multi-Way) Setups w/a Dumb (Existing) Switch
I’m not sure if this is a hardware or firmware issue, but as of right now, if you enable local protection and use a dumb switch on the end of a multi-switch setup, operating the dumb switch will override the local protection on the Inovelli. (1/28/21)Smart Bulb Mode Optimization Thread - Firmware Discussion - Inovelli Community
I guess EricM will follow up if it’s any different with this release.
a 3-way dumb switch overrides local protection
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
3-Way Compatibility: SBM should work in a 3-Way setting with a dumb switch or aux switch. Currently this is supported with an aux switch and Z-Wave bulb only via Associations.
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
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?
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?
Unless I misunderstood, you felt this firmware wasn’t working because you were able to turn the bulb off with the dumb switch.
Yeah, you misunderstood
- 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
ALL of those things happen at the SMART switch (or via zwave) not the dumb switch. i.e. I can turn the load on/off with the paddles on the smart switch when it has 3-way and SBM enabled. The really weird one is #3 where a zwave setLevel(x) command TOGGLES the load on/off with each command. I don’t see local protection explaining that weird behavior.
I know that you, Bry, are very knowledgeable in electrical wiring so I’m sure you can understand my explanation how a dumb switch should still be able to work since the relay in the smart switch is toggling the output between the Load and Traveler terminals. As long as the Traveler terminal does the same thing as the load terminal in SBM mode, then a dumb switch (spdt) should not interfere with SBM.
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.
Yeah thats basically it. The fact that there is a Traveler terminal does add a small wrinkle. I believe what’s currently happening is the Load terminal is doing exactly what we expected it to do in SBM mode. If you have a non-3-way where the load is connected directly to the load terminal and nothing connected to the Traveler terminal then it appears to all work as expected. But, it appears that the Traveler terminal is the one that is not ‘always on’ when the relay is switch to that circuit. There also seems to be some weird setLevel toggling when in that mode also.
It sounds like with 1.54, a dumb aux switch is still causing the switch to turn the load off.
I didn’t actually test that. Its probably true, but not the issue I’m reporting. With SBM and 3-way with the dumb switch flipped to the traveler circuit, I could turn the load off from the smart switch (and also get the weird on/off toggling with each dimming level change)
I know that you, Bry, are very knowledgeable in electrical wiring so I’m sure you can understand my explanation how a dumb switch should still be able to work since the relay in the smart switch is toggling the output between the Load and Traveler terminals. As long as the Traveler terminal does the same thing as the load terminal in SBM mode, then a dumb switch (spdt) should not interfere with SBM.
Yep, I get it but I can’t explain why. The only thing I can think of is that the switching concept is different depending on if you’re using a dumb switch or an Aux. When you’re using a dumb switch, that involves the relay. When you’re using the Aux that involves the um, MCU maybe? Not really sure. That difference alone might explain why the dumb switch will override and the Aux won’t. I don’t really know much about the dimmer’s internals, so this is all supposition on my part.
Yep, I get it but I can’t explain why.
Totally a SWAG on my part, but my supposition is that the offshore firmware coder forgot about the Traveler terminal when adding SBM.
I flashed 1.54 to a single pole non SMB dimmer. The default value for 52 was 1 (or previous… I forget) and I freaked for a moment when the lights didn’t dim. The led bar did dim! Yay! Changed 52 to 0 and everything was fine. Previous firmware was 1.52.
May have found either a bug or just a 1 off. Flashed three switches and one of them doesnt want to work at all. The light its connected to is on at about 25%, the switch is completely unresponsive and the LED bar is off when it should be 40% pink. If I pull the air gap and put it back in the LED bar comes on like normal, starts to go back to normal by switching to pink but then immediately goes red/blue/green (or whatever the sequence is) then goes off and ends up in the same state as before. I wasn’t able to flash the .bin file because it became unresponsive after flashing the .otz file. I flipped the breaker to it once and saw no change. When trying to use the config button for any of the extra functions like disabling the relay or factory resetting it I get no response. I think I covered everything I tried. Any info would be greatly appreciated.
Forgot to mention, the light is wired with a neutral and no bypass and has worked flawless up until this point.
You can try a factory reset. Hold config button 30 seconds until it turns red. If that works try reflashing the otz.
Sadly I’ve already tried that and got no response from the switch at all.
With this release I am seeing an issue in on / off mode where the physical down button does not turn the light off. Smart Bulb mode does seem to be working.
I had an issue where some scenes were not reporting but after a factory reset they were. Not sure if that was a fluke or not. I did try to change some config options and change them back.
3-way in Smart Bulb mode with a dumb switch hasn’t / doesn’t work. This would require “juggling” the power output across the load and the traveler when the dumb switch is toggled. This can result in power being cut to the bulb for a short amount of time.
With this release I am seeing an issue in on / off mode where the physical down button does not turn the light off.
Agreed. I am seeing the same thing.
This would require “juggling” the power output across the load and the traveler when the dumb switch is toggled. This can result in power being cut to the bulb for a short amount of time.
Agreed. This could be problematic for smart bulbs in ‘always on mode’ SBM (param52=2). However, it should not be an issue for ‘on/off mode’ SBM (param52=1).