LZW31-SN Internal Relay Disable - What's the point?

I’ll check and report back, honestly I haven’t needed to as all of my switches are colored/dimmed by Circadian Daylight Coordinator.

Am I correct in assuming that your LEDs on the switches in these cases don’t do anything?

Yes, they are on 100% always (which can be set to any intensity). There are ongoing conversations (see above with EricM) on adding this featureset.

Lol same for me, at least for the color. I still want the ability to dim via the switch though, hence this whole conversation. Although TBH the dimming function with ST is pretty crappy because of the latency…the first room I did doesn’t have the load side connected (long story, essentially the people that built this house wired many of the switches to outlets for lamps instead of having lights in the ceiling…even more odd considering this house is from the early 2000s, not 1960s…). For that room I didn’t even mess with this 8-tap thing (whatever you want to call it) so this didn’t come up. When I switch to HA at some point, I expect the dimming function to be better since it’ll all be local.

Got it – so it’s the local and remote vernacular that is throwing us off. Disable internal relay should be clarified to split out the remote and local portions as @kreene1987 suggested. I’ll try to clarify moving forward. Thank you.

Yeah, it will kill them if you enable, “disable remote relay control” – but if you only enable, “disable local relay control” commands will still be sent to the hub. In other words, tap up 8x disables local (at the switch) control, provides 120V to the load (if the switch was on prior) and you can still send remote commands to/from the switch.

Yeah, makes sense – I’ll have to wrestle @EricM_Inovelli to see which vernacular wins. I’m assuming everyone likes the DTH version better, so I’ll surrender and save us both from a wrestling match.

In my case at least (tapping the config button 8 times and getting a red led blink three times for confirmation), this is almost right except for the “commands will still be sent to the hub” part. Without installing any extra SmartApp, when this mode is on, pressing or holding the paddles doesn’t change anything at all in the switch’s “controls” page in the ST app. Maybe installing the Z-wave association thing and doing a bunch of additional configuration changes this, I’m not sure yet. I’m still not sure if I want to spend the time mucking with trying that or just pull the switches and hardwire load to line…then I can just leave this 8-tap mode off and use the switch like I had expected it would work.

This shouldn’t do that; what you see is right. The events (Central Scene events in Z-Wave terms, but interpreted as “button” events on SmartThings) are sent to the hub regardless of whether local or remote control is enabled or disabled and regardless of whether you have a specific SmartApp on your hub to “listen” for them. It’s just that when you disable local control, then taps (or holds and releases) on the paddle cause only these scene/button events to be sent instead of on/off and level events as well. (That is desirable; you don’t actually want to “dim” power going to smart bulb. There is currently a tradeoff where the LED bar on the switch can’t reflect the dim level and some challenges to making that work, but it looks like they’re exploring a few options.)

The second side of this, again, is whether you have something set up on the ST side to respond to these scene/button events. ABC is a popular app that can do what you want. There’s nothing the Inovelli DTH can really do — this is how SmartThings works. DTHs tell the hub how to talk to devices and generate events on the ST platform in response to reports from the device; it is the role of a SmartApp (any automation: ABC, webCoRE, Smart Lighting, etc.) to create automations based on these events. In your case, you want an automation that adjusts smart bulbs according to button events generated by the switch.

Unfortunately, most devices on ST have an additional shortcoming here: you have commands that can set them to a specific level and, in most cases, apps that can adjust the level up/down by some about, but no good way to emulate the behavior of a “real” dimmer where a bulb might slowly dim up/down (in response to the button event sent when the paddle is held) and stop (when the button event is sent on release of the paddle). Other platforms like Hubitat address this issue with “Start Level Change” and “Stop Level Change” commands, which I haven’t seen on any ST DTHs. ST further complicates things by involving the cloud for most apps and DTHs in general but custom apps (like ABC or webCoRE) and custom DTHs (like the Inovelli dimmer) in all cases, adding some delay (or total outage if ST is having one of their infamous cloud problems). Therefore, instead of trying to get that “dim while held” functionality that probably won’t work well in the first place as-is, you might want to try something else like “single tap up = set bulbs to 100%”, “double tap up = set bulbs to 75%” and whatnot. There may still be some delay, but at least the outcome is predictable.

Assuming you don’t have Z-Wave bulbs and aren’t using Z-Wave Association, then the above is pretty much what you want to do. This all involves controlling the bulbs and thinking of the switch/dimmer as just another way to control the bulbs (think of it like a button device/remote — just one that happens to be hard-wired — and ignore its switch and dimmer capabilities, which disabling remote control can help with if you don’t trust yourself to not accidentally send one of these commands from the hub/app). Almost all of my Inovelli switches/dimmers are set up to control Hue smart bulbs via the Hue Bridge, except I happen to be doing this on Hubitat where the “Start/Stop Level Change” command exists (but see alternative ideas above) and where execution is local so I don’t have to worry about cloud issues. :slight_smile:

interesting that disabling physical load control also disables the switch and dim % being sent to the hub. (do I understand that right?) That really cripples you on SmartThings. If those states still got sent, you could easily use the mirror function in Smart Lighting to control a wifi or zigbee bulb. if the default SmartThings handler was used, it could even run locally this way (but then you lose a lot of the other features).

Yes, the dimmer won’t send “fake” switch (on/off) or level events back to the hub, only its actual states. With local control disabled, physical paddle taps on the switch won’t do that and so will only send the associated scene event. With remote control disabled, you can’t do it over Z-Wave (e.g., from the ST app or SmartApp) either, and in most cases you wouldn’t really want to, either, since the goal is to prevent changes like this on the dimmer.

I think newer Zooz dimmer firmware has a “smart bulb mode” where the dimmer will still try to track a level internally but not actually adjust the load. You could then use some automation to “mirror” that to a real bulb or other device. Unlike Inovelli, however, that’s the actual term I’ve seen them use for this. :slight_smile: (I still prefer just using the scene/button events and creating the automation myself — I never updated my Zooz to the version that allowed this, as the one I had already scent scene events and allowed disabling local control — but I understand everyone has different preferences here.) But that sounds like what you want. I’m curious to see if Inovelli comes up with anything interesting here for people who do want that.

I would live to see this on Inovelli switches. Basically, a config parameter that would lock the load at 100%, but still simulate everything as if it wasnt. Pressing the buttons on the device would still send status updates to the hub as if it was doing something, and the LED strip would show the dimming level based on the simulated level. You could then process automations based on status updates from the switch even without scene support (such as keeping zigbee bulbs in sync with the switch status).

If you use group 2 association, it would also keep your zwave bulbs in sync. Instead of controlling each bulb individually, you control the switch. The switch simulates the command, and then relays the information to the associated bulbs.

I agree. Honestly, I assumed that’s the way it worked. Glad I got tagged in this thread.

Hey @BertABCD1234, @jtronicus or @prjct92eh2 – do you know what version of the Zooz switch has this?

We’d like to take a look to see how they’re doing this and compare it to ours to see if we can optimize and send to @EricM_Inovelli

I remember it being earlier than this, but according to their changelog for the ZEN27, it happened last October with firmware 2.07. This is the only one I’ve used, but my understanding is that they were going to do something similar on all their current dimmers also.

I should note that the Zooz doesn’t have an LED bar, so the requirements are a bit different. :slight_smile:

Sounds like the Zooz does what I had thought “internal relay disable” did…bypass the internal relay and act exactly as if load were hardwired to line (except for the front pull out disconnect still killing voltage on the load side, but I dunno if the Zooz has that pull out or not). My plan as of now is to do just that…hardwire the load to line and leave load disconnected on the switch. Then I still get the messages to the hub and can set the bulbs to mirror the switch without any extra SmartApps beyond Smart Lighting. And the LED on the front still works as a bonus.

1 Like

I dont have any of the Zooz switches/dimmers, but this is what I was able to find:

ZEN26 Firmware 2.02: Added on/off reports to the hub and LED indicator status changes with disabled physical / Z-Wave control [changelog]

ZEN21 Firmware 3.03: Added on/off reports to the hub and LED indicator status changes with disabled physical / Z-Wave control [changelog]

ZEN27 Firmware 2.07: Added on/off and live dimming reports on paddle presses when physical control is disabled for easier smart bulb control [changelog]

1 Like

If you put quotes around internal relay disable one more time like it’s some non-existent festure, I may lose my mind lol. C’mon man, it disables the internal relay!

Just messing with you. But also I may lose my mind.

3 Likes

Henceforth I shall refer to it as “internal” relay disable. Or maybe internal “relay” disable.

2 Likes

Wow… I really wish I had seen this thread before spending a few hundred dollars on switches. @Eric_Inovelli the OP is 100% right on this - these switches do not allow disabling the relay (which is the feature I bought them for). There are 3 separate pieces at play:

Z-Wave controller/devices <------> Switch state (on, off, dim level) --------> Light bulb
                                                                         ^this is the relay. this is the only part I want to disable

I want to disable the relay and leave the rest of it intact. I still want to control the switch’s internal state both locally (pressing and holding to dim - this is not the same as scene control, I though I was going to be able to have an actual dimmer switch), and remotely (from home assistant, node red, etc). I just don’t want the switch’s internal state to ever have an impact on the voltage… but the way it is set up now makes it so I can’t even control the internal state.

Smart bulb mode gets really close, and almost acknowledges the problem, except that when you turn the switch off it still cuts power. When I have a smart bulb it should never cut power - smart bulbs don’t like turning on/off.

That’s not correct.

Exactly. Turn on Disable Local Control and the switch will not physically cut the power to the light.

You can do that now, but a new firmware 1.52 (beta) was just released that you should consider.

1 Like

How is that not correct? When setting Disable Local Control, changing the switch brightness or on/off from home assistant still affects the power because the relay is still enabled (if the relay is disabled then how is the voltage changing?)

I’ll take a look at the beta firmware, from that thread it looks like it’s almost there, other than remote toggling still cutting power. But sounds like they’re open to feedback on that part

Disable Local Control prevents you from cutting power at the switch. Disable REMOTE Control prevents you from cutting the power via the hub. Generally, the thought was if you have a smart bulb you usually wouldn’t want someone to work the switch in the traditional way, turning the bulb off but would still want control from the hub for whatever reason. So you would just Turn on Smart Bulb Mode and Disable Local Control and then you couldn’t physically cut the power via the switch.

There have been varying viewpoints on how this has been implemented, so the new firmware is trying to address this.

The only part of this that I don’t think you can get around is making the switch internally “track” some state (on/off, level, etc.). But otherwise, everything you want is possible — and Z-Wave Central Scenes are indeed part of it. You need to create an automation that responds to the scene events and manipulates the actual bulb devices accordingly. For example, the scene for single tap up can turn on the lights, single tap down turn them off, hold up begin raising the level, release up stop changing the level, two taps up do…whatever you want (or not). This is now mine are set up and they work exactly like a “real” dimmer with a “real” load would; the only difference is that the hub is in the middle (not a problem for me — I did get a smart switch for a reason :slight_smile: ).

But in any case, the goal is that you need to manipulate the bulbs with your automations, not the switch/dimmer (this also applies to things like voice assistants or other ways you might want to manipulate the lights). The switch/dimmer is just a powered button device if you aren’t using it to directly control the load. You’d definitely need local control disabled for this to work. Whether you disable remote control is up to you, though I don’t do that myself since I know not to manipulate the device from the hub, and that’s entirely within my control. There are different ways that this feature could be implemented (one of which could be as you described), but I personally actually prefer it this way because it avoids me needing to put yet another automation between the bulbs and me, one that would “mirror” the switch/dimmer state to the bulbs.