Dumb switch for 3-way

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:

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?

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.

Sweet. Thank you again!

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

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

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

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

So, with this parameter now able to be set (Hubitat), can I do what @Chris was suggesting so that the dimming AND LED bars stay in sync? I think that involves:

  1. Associating Groups 2,3, and 4 from each switch to the other
  2. Changing the association parameter to “11” (Timer + 3way + Local) on one of them

Thoughts? Suggestions?

Thanks!

Fingers crossed that my dimmers arrive Thursday–they hit the local distribution center today, about 3 days late (Thanks USPS).

Just 3 and 4…

1 Like

So, you made it work without anything in Group 2?

It sounds like you originally had 2, 3 & 4 synced each way. The, that made for a loop. So, you tried 2&4 one way with 3 the other way–but that didn’t dim quite properly.

Then, @EricM_Inovelli mentioned the parameter 12 =11 change.

So, after all that–you have the LED strips syncing AND the dimming/on/off all working with parm 12=11 and only groups 3 & 4 associated BOTH ways?

Largely, I just don’t have my head wrapped around all the “Group Associations” very well yet. :slight_smile:

Thanks

Correct.

Your missing piece is the group functionality.
Associations are so a device sends reports of its activity or commands directly to other devices. Every device always has Group 1 (the Lifeline group), which sends activity reports back to the hub. Beyond that, a device may have no groups or it may have one or several. Each group is for a specific type of report or command.

For example- I have a Z-Wave flood sensor at my place. It has Group 1 for the hub, and it also has Group 2, where it sends a command when water is detected. I also have a Z-Wave water shutoff valve. So I associate the sensor’s Group 2 to the valve, and thus when water is detected the valve will shut off, even if the hub is offline.

Inovelli Red dimmer has 3 groups in this regard.
Group 2 sends a BasicSet command, namely just an ‘on’ or ‘off’ when the top or bottom paddle is pressed.
Group 3 sends a SwitchMultiLevelSet command- when you change the level of the dimmer, it sends the resulting level. This can keep multiple dimmers in sync.
Group 4 sends MultiLevel(Start/Stop)LevelChange commands- when you hold down the paddle, it sends StartLevelChange and when you let go it sends StopLevelChange.

Thus groups 3 and 4- Group 4 gives you live dimming / LED bar response when you dim. Group 3 keeps multiple dimmers in sync.

So for example let’s say you have 2 dimmers associated to each other with Group 3 / Group 4. But let’s say the first dimmer has a dimming time of 3 seconds, and the second has a dimming time of 1 second. If you hold down the first dimmer’s paddle for 1.5 seconds the first dimmer will dim halfway, but the second dimmer will have dimmed all the way (because 1.5 seconds between StartLevelChange and StopLevelChange). However when you let go, the Group 3 association will send the correct level, and they will stay in sync.

Does that all make sense?

The problem is, when you just have the associations, as one dimmer is ramping it’s sending commands to the other dimmer, which is a bit behind. Other dimmer gets the command, then sends its state back to the first, which interprets it as a control command, so they keep going in a loop.
That’s what P12=11 does- control what signals get forwarded to associated devices. Thus, no loop.

Does that explain it better?

1 Like