Dumb switch for 3-way

Switches Wiring Discussion
#8

@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
#9

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).

#10

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:

#11

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?

#12

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.

#13

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.

#14

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
#15

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.

#16

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…

#19

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.

Paddle Remote | Project BFF
Community Badges
#20

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…)

#21

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?

#22

Yes, unfortunately it will :frowning:

#23

Thanks @Eric_Inovelli. If I use an LZW31 with dimmable bulbs instead, what determines the brightness of the bulbs when they are toggled via the dumb switch? Will the dimmer just be bypassed and go full bright or full off?

#24

Yeah no worries, happy to help. The dumb switch will turn the bulb on and off (no dimming) so whatever the smart switch sets the dim level to prior to being turned off is what level the lights will turn on to when the dumb switch is turned on.

Whereas with an aux switch, you will have full dimming control from either side.

#25

Sweet. Thank you again!

#26

Yeah, for sure. I don’t remember why it wasn’t put into the documentation. I believe it may have been a parameter that got pushed through at the end of development before z-wave certification. I’ll see what I can do about getting it added to the documentation.

1 Like
#27

So, where do you do that “def getParameterNumbers” call on a Hubitat?

If the dimmers I ordered ever show up (you sent them out in a quite timely manner–but the USPS has had them in limibo for days now), I think I’ll be setting up two Red Series Smart dimmers, with one as the “3way” dumb switch.

I’m a bit confused about the best way to wire them up and bind them together–and to try syncing the LEDs up as much as possible.

For the easy part, I’m thinking:

  1. Putting one in place of the existing Enbrighten switch with no traveler.
  2. The other hooked only to neutral/line/ground.

Then the tricky stuff:

Figuring out how what associations to create (and how to do it on the Hubitat).

And, trying to understand this business about editing/setting parameters??

Thanks!

(Given that the USPS has my dimmers stuck in limbo between MI and MO, I guess I have some time to get this sorted out–they were supposed to have arrived Monday evening).

#28

I just made a PR for this exact thing before noticing this thread. But I’m guess you’ve already made the change on the “development” branch anyways, and it’s just not been pushed to master yet.

1 Like
#29

Yep, this change is going to be in the next device handler update. Can you leave your PR open until I push out the update? In case someone wants to use the change now.

@robstitt This parameter will be in the next driver release for Hubitat as well.

1 Like