Dumb switch for 3-way

I have a number of 3-way switches I’m contemplating replacing with LZW31-SNs. From what I gather, the aux switch just puts neutral (or open circuit?) on the traveler wire, and the LZ switch interprets that, but I think I must be oversimplifying… maybe a proper aux switch uses a pulsed signal?

In either case, I’d like to keep the dumb switch in place rather than buying an aux switch, but don’t understand how the LZ switch would interpret the state changes from the dumb switch. I assume the dumb switch does not directly control the load as in a traditional three-way. Ideally I’d like dumb switch state changes to be broadcast to the hub where rules can be evaluated.

You guys are the best. Help this lowly mechanical engineer interpret the electrical magic that is woefully under documented.

From personal experience, get a Aux switch. The GE is (relatively) cheap. With
it you/significant other can control dimming remotely. But be awhere that as far as I know no one makes a Aux switch that will send commands to the hub, so no scene activation from the remote. Though you could set rules based on the state of the main switch.
Sorry! Something went wrong!

Thanks @djordan2112. The more I read, the more I resign myself to it, but wish I understood the why better.

I feel like I must be missing something fundamental about the way the LZ switches interact with the aux switches, because it seems like a no-brainer to expose it to the user as another set of buttons. There must be other limitations.

It has to do with the fact the the main switch (LZW31-SN) needs power all the time, and does all the processing. The Aux “talks” to the main using the traveler wire. The Aux also has no radio in it to talk to your hub.

In the 3-way configuration the LZ switch is never unpowered no matter what position the dumb switch is in. I have a motion detecting switch set up from the previous home owners and every time the dumb switch it’s attached to is toggled, I can here the relay in the smart(er) switch toggling and controlling the load.

It does in a sense. Per the Inovelli wiring diagrams, what should happen is the Load and Traveler of the Inovelli switch go to the dumb switch, then the dumb switch’s common wire goes to feed the light. All the dumb switch does is connect one terminal or the other to its Common. The Inovelli switch has the dimmer circuit, and after the dimmer is a relay so it can send the dimmed power to either the Load or Traveler terminal.
Inovelli then constantly measures both Load and Traveler terminals, sensing which terminal is connected to neutral (via the light fixture) and which one is just floating. If which one floats and which one is neutral changes, it knows that you’ve clicked the remote switch. So it turns the dimmer on/off and clicks the relay to the opposite position.

That said- as others have suggested you would be better off getting the HomeSeer or GE remote switch unit and using that. A dumb switch will be toggled either in up or down position, while the remote switch will be a neutral paddle like the Inovelli. More importantly, the remote will enable dimming and multi-tap same as you would get at the Inovelli switch itself; a dumb switch is on/off only, no dimming, no scene control.

1 Like

The Aux is connected to the smart switch via 2 conductors. One conductor is a traveler that’s used for signaling. The other either sends a hot or a neutral depending on the smart switch’s installation.

If your smart switch is installed in a non-neutral configuration, you don’t have a choice. You must use an Aux. If it’s a neutral installation, then you can use either.

What @djordan2112 said about no radios.

@Chris Your second paragraph states that the LZ switch works exactly as I would hope it would. The switch is evaluating the input on the traveler pin and then applying logic to the output relay. If that’s the case (and it’s done via firmware and not via an electrical circuit), it might be possible to treat it as a digital input. Not saying that’s how it works now.

@Bry I don’t mean for the dumb switch to broadcast to the hub, but the LZ switch to broadcast the dumb switch state change.

All that said, I definitely know now that’s not how the LZ’s work today, so I’ll plan for some aux switches.

1 Like

Yes that is correct- the Inovelli knows the position of the dumb switch. And in theory, a firmware could be written that would report the position of the dumb switch to the hub, either as a status or as a scene control command, so flipping the dumb switch could be used to trigger other commands.
Currently the switch firmware doesn’t expose this information at all, it’s only used as an on/off toggle command for the lamp (which triggers the dimmer circuit and relay to react accordingly).

You do have another option if it helps- buy another Inovelli dimmer and put it in the 3way box. In this setup, your traveler romex would only be used to bring hot and neutral over from one box to the other. Both Inovelli switches would get raw hot and neutral power. One of them would then have the lamp connected to its load terminal. You would then create a Z-Wave association between the two switches (as long as they are within direct RF radio range of each other).
Result of this is any action taken on one switch immediately happens on the other switch, including dimming or on/off. One switch would functionally dim the light, the other would have no load at all attached to it but since they are in sync controlling it would control the other and thus control the light. Unlike a 3-way aux switch, you could have multi-taps do different actions on each switch. And each side of the switch would have a LED bar that could be individually addressed (by color and flash pattern, the status (how full it is) would sync with the other switch).

All good except for the syncing of the LED bars. They do not synchronize.

Take a look at this KB for multiple smart switch limitations:

I have a hard time understanding why tapping the “aux” switch would NOT intrinsically have the exact same result as tapping the main one? Just like all the switches in a 3/4/x-way configuration control the same fixtures identically–it is certainly reasonable that actions on the aux-switches would be indistinguishable from those on the primary switch.

Since the primary switch is clearly “reading” the aux switches to detect up/down pushes and holds, the primary switch would just need react to those pushes/holds the same way it reacts to pushes/holds on it’s own paddle. That seems like an incredibly obvious issue (i.e., it’s how I’d expect it to work–so, I wouldn’t think it would be some insane patent issue, as it certainly doesn’t seem “novel”).

IOW: If you “double tap” the aux switch, the primary switch certainly sees those two taps. It just needs to pass that along to the hub or z-wave associations. ???

Am I missing something?

If you have a real aux switch, like the HomeSeer or GE aux switch, then NO power flows through the aux switch. It’s just a button that sends button presses to the main switch. Pushing the aux switch or tapping / holding / whatever does EXACTLY the same thing as if you tapped the main switch. That includes scene control commands and multi-tap actions if you have a red series main switch.

//edit: apparently the remote switch doesn’t work for multi taps.

It’s a dumb 3way switch that works differently, turning it on/off turns the light on/off.

I don’t know the mechanics behind the communications, but multi-taps of the Aux are not supported. Confirmed by @Eric_Inovelli earlier this year. AFAIK, there have been no firmware modifications that address this.

I found mention in the JASCO manual indicating it must pulse neutral to the controlling device.

“The auxiliary switch does not actually control the power; instead, it sends a momentary voltage signal through the traveler wire to the primary switch which in turn, controls the power to the load.”

1 Like

That’s interesting. I wonder why it doesn’t just let the primary switch handle all of that.

I did learn the hard way that the earlier models of these Aux switches are NOT compatible with the latest GE/Jasco S2 Enbrighten dimmers (but are compatible with earlier ones, it seems). The “pig tail” ones and, I believe, even the generation of ones with screw-terminals don’t necessarily work. So, there clearly is SOMETHING odd going on inside those things.

This KB article is wrong, I tested this just now. I have two LZW-31SN (red dimmer) running firmware 2.48 right next to each other. I paired one to the other in Group 2, Group 3 and Group 4, then tried various operations on it. The LED bars stay in perfect sync, for both on/off and hold to dim functions. The loads dim in sync too.

//edit- hmm, this may have a few bugs in it. Seems like sometimes during the dim ramping the switches get stuck in a loop of updating each other.

//edit2- if you associate one way it works PERFECTLY. If you associate both ways, the switches get stuck in a loop updating each other and nothing works now. Dunno why it works before and not now.
What I found is doing one assocation with Group 2 and Group 4, and associate the other way with only Group 3 seems to work. This means in one direction holding the paddle live-dims both lights, but in the other direction it only dims once you release the paddle. But it does keep both bars in sync.

I’m sure this could be fixed in firmware, maybe just ignore commands from associated nodes while a local command is currently processing…

On one of the dimmers change parameter 12 to 11. If you are using SmartThings or Hubitat you will need to edit the device code. Change this:

def getParameterNumbers(){
    return [1,2,3,4,5,6,7,8,9,10,11,13,14,15,17,18,19,20,21,22,51,52]
}

to this:

def getParameterNumbers(){
    return [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,17,18,19,20,21,22,51,52]
}

Then go into the device preferences and change it to 11 which will stop the loop from occurring.

Interesting. I don’t see Parameter 12 in any of the documentation but found it in the Z-Wave alliance site

Says it’s ‘association behavior’ with the options as Local, 3-Way, Z-Wave Hub, and Timer in various combinations.
I’m curious to know more about what this option does on a technical level?
And I’m using HomeSeer so setting any parameter is easy++ :slight_smile:

(as a side note, it might be worth posting a new version of the manual or at least a parameter list as a few new ones have been added since initial release…)

So I’m about to order some more switches, but if I wanted to install hue bulbs using a red series in a 3-way config using a dumb switch, will power be cut to the bulbs even when disable local control is on?

Yes, unfortunately it will :frowning: