Parameter 52 (Switch Mode / Smart Bulb Mode) set to "On/Off" in 3-Way configuration: Why do two "on()"s turn the lights off?

Switches General Discussion
#1

Has anyone run into this issue before? Is it a bug or a feature? Seems more like the latter.

Switch configuration: I’m using a LZW31-SN (Red Dimmer Gen 2) / firmware version 1.57 with SmartThings. Edited to use the custom (not stock) “Inovelli Dimmer Red Series LZW31-SN” Device Handler version 2021-11-24 provided by Inovelli.

Problem symptoms: When Parameter 52 (aka “Switch Mode” or “Smart Bulb Mode”) is set to 1 (“On/Off Mode”), AND parameter22=1 (Multi-Switch Setup (Dumb/Existing)): If the switch is asked to turn on (such as via a smart assistant) when the switch is ALREADY ON, then:

  1. Lights actually turn OFF, rather than STAYING ON. I would have expected the lights to “stay on” when asked to turn on, similar to how the switch would behave in a single-pole mode or ‘normal operation’ (parameter52=0) mode.
  2. Even though the lights just turned off, the LED indicator on the switch itself remains bright blue, which suggests the switch still is in an “on” state, which contradicts the fact that the lights turned off.

I CAN reproduce this for switches in a 3-WAY configuration with a dumb switch (parameter22=1), but CANNOT reproduce symptoms for switches in SINGLE POLE mode (parameter22=0). So the 3-way configuration seems related to the puzzle.

I cannot reproduce the issue by pressing physical buttons on the switch itself; the behavior seems more tied to SmartThings or Z-Wave integration. For example, if I tap the “up” button of the paddle when the lights are already on, the lights stay on. This is good. I originally ran into this issue via SmartThings integration. I first noticed the issue when using Google Assistant and Alexa to turn on rooms, but it might also explain some weird “turn on” automation quirks I’ve been running into.

Workaround: Since I was mainly using parameter52 to repurpose my Dimmer as an On/Off switch, I’m working around the issue by setting the parameter52 to 0 (“normal operation”), and setting the minimum brightness level to 98 (which is as close to 99 as I can get without causing the setting to be ignored). When parameter52 = 0, then two "on()"s keep the lights on.

Example repro steps:

  1. Configure Red Dimmer Gen 2 switch with parameter52=1 (Switch Mode = On/Off) and parameter22=1 (Switch Type = Multi-Switch Setup (Dumb/Existing))
  2. Ensure that the light switch is turned off (e.g. “alexa, turn off kitchen light switch”).
  3. Turn the light switch on via smart assistant (e.g. “alexa, turn on kitchen light switch”)
  4. Expect that the lights turn on.
  5. Turn the light switch on via smart assistant (e.g. “alexa turn on kitchen light switch”)
  6. Expect that the lights STAY on.
    ^^ Test FAILS here. The light bulbs turn off, but the dimmer’s led indicator is still “bright blue”, which suggests power is still on somehow.

Example “Live Logging”:
CAUTION: This is in reverse chronological order; the “first” events are at the bottom.
6:21:24 PM: info Kitchen Light Switch: Power report received with value of 1.6 W
6:21:24 PM: debug Kitchen Light Switch: MeterReport(scale2: false, scale: 2, rateType: 1, precision: 1, meterValue: [0, 0, 0, 16], deltaTime: 0, meterType: 1, size: 4, scaledPreviousMeterValue: 0.0, scaledMeterValue: 1.6, previousMeterValue: [0, 0, 0, 0])
6:21:21 PM: info Kitchen Light Switch: Basic report received with value of on (99)
6:21:21 PM: debug Kitchen Light Switch: BasicReport(value: 99)
6:21:21 PM: info Kitchen Light Switch: on()
6:21:13 PM: info Kitchen Light Switch: Power report received with value of 61.9 W
6:21:13 PM: debug Kitchen Light Switch: MeterReport(scale2: false, scale: 2, rateType: 1, precision: 1, meterValue: [0, 0, 2, 107], deltaTime: 0, meterType: 1, size: 4, scaledPreviousMeterValue: 0.0, scaledMeterValue: 61.9, previousMeterValue: [0, 0, 0, 0])
6:21:10 PM: info Kitchen Light Switch: Basic report received with value of on (99)
6:21:10 PM: debug Kitchen Light Switch: BasicReport(value: 99)
6:21:10 PM: info Kitchen Light Switch: on()

Thanks in advance for any hints.

#2

So when SBM is enabled, the switch is now just a scene controller. Pressing up on the paddle is sending a button 1 pushed message to the hub. So you need to examine whatever you are using for scenes, SmartLighting, Automations, a button controller, etc to see what it’s doing with the button 1 pushed message.

With SBM enabled, the switch has nothing do with turning lights on or off, it simply sends the scene message. Since you are seeing the light toggling, my guess would be whatever you coded that button push to also has “turn on and off” enabled.

You are correct that the switch is still in an on state because that is what SBM does. It insures the powered load does not have the power cut to it via paddle presses. If you have SBM enabled and you want the LED to turn on and off with whatever you are controlling via a scene, then you’ll need to do that with a routine. You can enable a child object for the LED to allow you to do that.

#3

Thank for the response!

So when SBM is enabled, the switch is now just a scene controller. Pressing up on the paddle is sending a button 1 pushed message to the hub.

Ahh, drat, I’m realizing that I misspoke about what it means to set parameter52 to a value of 1. Sorry for the confusion. I’ll try to rephrase:

In other words, I have parameter52 (confusingly labeled as “Smart Bulb Mode” by the Device Handler; alternatively labeled as “Switch Mode” in the community manual) set to “1”. I misspoke that this means “enabled”, though. Instead it means:

0 = Normal operation
1 = On/Off Mode - Switch will either be in the state of 0% power or 99% power, not allowing dimming. Useful for non-dimmable bulbs or other unique loads
2 = Smart Bulb - Switch always at 99% for use with loads like an Inovelli Bulb or Philips Hue Bulb. Use in conjunction with associations or scenes to achieve an awesome smart bulb experience

I think you’re referring to the “2” setting, whereas I’m trying to troubleshoot the “1” setting. The bulbs in my sockets are regular “dumb” bulbs.

#4

Yep, you’re correct. I saw “SBM” and ignored the parameter value.

I don’t have any dimmers on 1.57 so I can’t replicate your condition, but it doesn’t make any sense to me either that a press up on the paddle would turn the light off. There was a fix related to parameter 52 in 1.55, but since you are on 1.57 you should be fine.

Someone with this firmware will have to comment. In the interim, make sure that you don’t have anything coded scene-wise that could be causing an issue. Even with P52 set to 1, button 1 pushed will still be sent. I think you can set the delay to 0 and that will cause it to not be sent. Or to be absolutely sure, exclude, factory reset and re-add the switch. The latter may not be a bad idea in any event.

#5

Thanks again for the response. I’ve overhauled my original post a bit, to edit for clarity, and to note a few other findings in case they help solve the mystery. Mainly:

  1. I can’t reproduce the issue when pressing “up” on the paddle. Physical paddle behavior seems fine. The issue seems more to do with something Z-Wave-y or SmartThings-y.
  2. I can’t reproduce the issue for my single-pole switches, i.e. where parameter22 (Switch Type) is set to 0 (“Single-Pole”). This problem only shows up for my switches with parameter22=1 (“Multi-Switch Setup (Dumb/Existing)”). I wonder if there’s a bug in how the “On/Off” mode behaves in a 3-way setting.

Good point. I just installed the switches in the last ~week, and I’ve been avoiding automation/scenes to simplify the troubleshooting. So I don’t think there’s anything to interfere, but I hear where you’re coming from!

#6

So far I have only tested this on Hubitat with firmware 1.61, but it doesn’t seem to do this in that setup. I’ll switch over to SmartThings and try that next.