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:
- Putting one in place of the existing Enbrighten switch with no traveler.
- 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:
- Associating Groups 2,3, and 4 from each switch to the other
- 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. 
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
Dude!!! Thanks a bunch!
Yeah, that does help me come up to speed on that stuff much better.
Thanks for the detailed explanation!
So–are the groups “whatever the manufacturer chooses” or are the uses for each group (beyond 1) set by Z-Wave protocol requirements?
Manufacturer decides. HomeSeer’s HS-WD200+, their equivalent of the Inovelli LZW31-SN (Red dimmer), only has a Group 2 which sends all updates. I have one paired to a plug-in dimmer module, it live dims on Group 2.
My water sensor is like HomeSeer, Group 2 just sends a BasicSet command of either On or Off (configurable) when water is detected.
1 Like
So now that I’ve got my dimmer wired in with an aux switch, I am either doing something wrong or a little disappointed. While the LZW31-SN behaves like I’m pressing the physical buttons (from the aux switch) I don’t see any button presses in the logs. I see the dimmer level being changed and reported, but I thought I could get scene control working from the aux switch. It will work the way I’ve got it in this particular location, but some of my future plans are going to have to be reworked.
Running firmware 1.47, installed with a neutral wire, and set as a 3-way momentary using a GE 47334. Driver is the latest as of today from the hubitat git repository.
@fatherdoctor - The Inovelli switches do NOT support scene triggers from the Aux switch. Possibly in the future, but it’s uncertain at this time.
1 Like
Thanks @harjms. That information is very difficult to find and is a function I assumed (and I’m thinking many others) was supported. The functionality of both a toggle and momentary 3-way add-on switch really needs some formal documentation rather than requiring a bunch of digging through forum posts. I’m guessing that interactions with external switches happens at a hardware layer prior to the z-wave processor getting involved.
@fatherdoctor - Correct. Hopefully a future firmware upgrade could allow the switch to monitor pulses between traveler/neutral or line/traveler to enable scenes from the switch. The memory is pretty packed right now, but if the give up some space, it may be possible.
1 Like
As of right now the only way to get scene control at a second location in a 3-way is to use a 2nd Inovelli switch with associations set up. We are working on bringing the feature to the Red series devices though.
4 Likes