I am trying to create a direct association between a new Zen34 (battery-powered remote) and a zwave plug. I am using the z-wave js mqtt integration so I have the UI to configure things. I selected the zwave node and clicked on the groups tab. Here I added an association.
Endpoint 0. ( I don’t know what this actually is but its the only choice)
Group On/Off Control ( The pug doesn’t support dimming)
Target Node 5 ( The node id of the plug)
Target Endpoint ( I don’t know what this but I left it blank)
I then press the button on the Zen34 7times to wake it up. I then get a popup that says setAssociations called successfully.
After all of this, the remote doesn’t seem to work. Any ideas what I am doing wrong?
I have been having issues with the “grouping” of Z-Wave devices since upgrading to the latest release of the integration. What I have also found out from Zoos is that both devices need to be the same security level in order for them to be grouped together. They actually recommended to use not security so that you can group with older devices.
Does the grouping show up in the group list? When I first set up groups it did, now it doesn’t. Which leaves me to believe the group is either not setup, or the integration is not saving it.
Well that turned out to be the issue. I re added the device with no security. The plug was connected as unathenticated s2. The remote was connected as no security.
I couldn’t get the remote to add as unathenticated s2 so I used no security on the plug. Now it seems to work.
It makes sense that devices with the same security level can’t communicate. The question I have though is do devices with different security levels create a mesh and repeat signals ?
Resurfacing this thread as I am trying to setup associations with my ZEN34 for some Graber Virtual Cord shades. They are using the same security (none) as the switch but not having any luck in getting them to communicate.
I just bought a Zooz ZEN32 scene controller and am trying to get it to directly associate with my Bali Autoview shades (same as Graber, just the DIY line). I have made some progress-- if I add a group association in ZWaveJS2MQTT on the ZEN32 (e.g., node 0, group 2 (main button press), to shade node 0), I can successfully control the shade if it is already awake – if the shade is in motion, the ZEN32 will successfully change its direction; if the shade is in inclusion mode it will respond to button presses on the ZEN32. What I can’t figure out is how to get the same results when the shade is asleep. The somfy remotes succeed (obviously) as secondary controllers, and no amount of debug log review helps me figure out what’s missing.
I know that when you assocate a somfy remote control as a secondary controller to the somfy autoview shade, the shade is put into the usual inclusion mode (3-second press, flashing green light), but the remote is not put into “inclusion” mode (2-3 second press), rather the remote is put into an association mode (quick press on set button) and the shade acknowledges with a jog.
I have tried using the inclusion mode on the ZEN32 simultaneously with the inclusion mode on the shade, and I just can’t get the shade to ever jog in acknowledgement (which I assume is when it records the node_ID of the secondary controller somewhere in its local memory, which I can’t see in any of the debug info for the shade node in ZwaveJS2MQTT).
For anyone still looking for an answer to this issue, see Dr. Zwave’s blog entry on the topic of associations and F requently Li stening R outing S laves (FLiRS) for insight on how to get an association to “wake up” a battery powered device before sending it a command.
The insight is, as you suspect, that we need to assign a return route so that the secondary controller sends a “wakeup-beam” to the shade before sending a command. ZWaveJS UI does not appear to do this (as I have never been able to get the shades to respond to switches to whose group associations they were added unless the shade was “awake.”
I connected my Aeotec Z-Stick 7 to a windows computer and followed the steps at the blog entry to create an association with the “assign return route” checkbox checked, and lo! and behold! the switch functions as it should to open and close the shade, whether it is awake or not.
Some quirks:
Re-connecting the Z-Stick 7 to my Synology so the ZWaveJS-UI docker can control it again, I discovered that the group association I had created in the wall switch was not detected, nor detectable by, the ZWaveJS software - refreshing the associations on the switch shows only the lifeline… but the switch is definitely controlling the shade.
I created a feature request for assigning return routes, and then appended a comment about the lack of detection of the changes made in PC controller here: https://github.com/zwave-js/zwave-js-ui/issues/2723