I have a number of the WD200+ dimmer switches in my house, and use the group 2 association to create multi-way circuits. This has worked great until this weekend, allowing me to have visually matching switches for multi-way circuits, instead of using the 100+ switch that does not have LEDs on it. The setup is simple - connect the “master” switch to the load, and just connect the “slave” switches to power. Then create a group 2 association for all the switches, and put the switch ID of the OTHER switches in the group, in the group members field for each switch. Works great … until this weekend. I installed WD200+ switches on two three way circuits, followed the procedure defined above, and in both of the new circuits, the slave switch is not syncing to the master - the status on the switch (ie, the LEDs and on/off status) does not update when the master switch is activated, and the slave switch cannot control the load (ie, the master switch is not syncing to the slave switch status). I have compared the settings of the new switches to other switches in multi-way circuits that are working and I cannot see any differences. I have triple checked the ID’s of the new switches to make sure I have configured this correctly. I cannot see anything wrong or different between the working circuits and the failing circuits. HELP!
Do you see any difference in the IDE between one of the new ‘not working’ switches and the old?
Check the security level of each switch in the I DE. Although Z wave is backwards compatible for most things, because of the increased security requirements of newer S2 devices, you cannot set up an association between devices at different security levels. this has tripped up quite a few people who had devices which were originally added with legacy security because the smartthings hub at that time did not support the S2 level, but the newer devices added at the higher security level because the hub has been updated in the meantime. So they then could not be associated with the devices which had been added previously. 
If that’s what the problem is, the only way around it is to remove one or the other of the switches and add it back at a security level that matches the other switches.
Also, what DTH are you using to set the associations?
In the IDE I see no differences. I’ve compared them side by side multiple times. This is making me crazy as it has worked before! No security settings on any of the devices … since I didn’t have security at first I’ve gone w/none for all so they’d be compatible. No way I’m going back and deleting every device and automation and then re-adding it all back in! To create the group I switch the DH to zwave tweaker in the IDE, then I can set the group through the app, then I set the DH back to the WD200+ DH when I’m done.
Interesting data point, I tried using one of the old, working switches w/the new non-working switch that is connected to the load. In this mode, I was able to control the load through the old, working switch through the association BUT the new non-working switch would not update the status of the old working switch. So it seems like there is something with the new switch that prevents it from sending the association command (or whatever is happening there) to the associated devices. Thoughts?
The only other thing I can think to try at this point is a full reset on the non-working switches to see if that clears something that is causing the issue.
There has to be some network security level listed in the IDE for each switch even if it’s just “legacy non-secure.“ it will be in the zwave details for each switch once you are using the regular DTH.
Here’s a screenshot from another thread where you can see what it looks like. It’s under data for the device.
Already checked that … all of my devices are ZWAVE_S2_FAILED.
Did you read the second part of my last post? One of the old, working “slaves” (ie, device connected to power but not load) worked with the new “master” device … half way. Once they were put in an association group together the slave could control the master switch, and hence the load. BUT when activating the master switch, the status of the slave was not updated to match. On the old, working switches once the association group is created, either switch syncs it’s status w/the other. Once I put the old slave back into it’s original group it worked fine in both directions. So clearly there is some issue w/the new switch transmitting it’s status. I’m guessing all the new switches share this issue since both of the 3-way circuits I tried to create, failed. Question is, what is the issue and can I fix it? Or is it a hardware problem?
That’s not normally how zwave association works unless you set it up in both directions.
All association does is give the trigger device permission to send a basic (that has a specific meaning in a Z wave context) command directly to the Devices in the Target group. It’s not bidirectional. So if you want to keep them in sync, you have to set up an association in each direction. A as trigger, B as target. B as trigger, A as target.
If I were working this on a field assignment, I would begin by using the Z wave Tweaker to query one of the old switch pairs and see what the association groups were for each. But I’m hesitant to recommend changing anything that’s working for you right now, since there may be some other smartthings strangeness. 
That’s exactly what I did … for every device in a group, I put all the other device’s IDs into the group members field. That’s how I set it up for all the working groups, and the two new groups that aren’t working. And that’s how I set it up for my experiment as described above. So, in my experimental group and in my new groups, the commands should have been working in both directions. With the new switches they didn’t work in either direction. With a combination of old and new, they only went from old to new (and new received and responded correctly). So I still think this all points to an issue specific to the new switches.
BTW if there is anything specific you’d like to know about the configuration that could help debug please ask!
OK here is even more data. First, naming conventions:
Master - switch that is connected to load.
Slave - switch that is connected to power but not to load.
Switch 1 - old switch, slave, works with group associations in 4-way circuit A with two other old switches.
Switch 2 - new switch, master in 3-way circuit B.
Switch 3 - new switch, slave in 3-way circuit B.
When configuring switches 2 and 3 in an association group, setting the group members for each switch to the other switch, there is no communication between the switches - physically activating one does not change the state of the other.
When configuring switches 1 and 2 in an association group, physically activating switch 1 changes the state of both switches - they stay in sync. But physically activating switch 2 does not change the state of switch 1.
When configuring switches 1 and 3 in an association group, physically activating switch 1 changes the state of both switches - they stay in sync. But physically activating switch 3 does not change the state of switch 1.
It appears that switches 2 and 3 are not sending commands to their association group despite being configured to do so. The only reasons I can come up with are, there is some hidden setting that is disabling this, that I am not aware of and can’t see (since comparing the device settings in the IDE shows no differences between the working and not working switches), or there is some other issue (HW/FW/SW) that is causing the new switches to fail.
Thoughts? Suggestions? I’m out of ideas.
Looking at the certification information, it appears that the most current model of the switch does not use association except for lifeline reporting. It relies instead on central scenes. So I wouldn’t expect anything in group 2 to work.
https://products.z-wavealliance.org/products/2676?selectedFrequencyId=2
You could confirm this with Homeseer to be sure. 
Interesting … I see now that the information sheet that came in the box w/the old switches, that work w/association group 2, does only say that they work with group 1. And the sheet that came in the box with the new switches specifically says that they work with groups 1 and 2. Something ain’t right here.
I saw your other post before you deleted it and checked out the Inovelli page … and actually had already started the process of excluding both devices and then reincluding them w/security enabled. Successfully included one w/security but the other one failed. So, need to exclude that and then try to include it again. That said it’s late and I’m tired and I’m bailing for the night. I also have a ticket open w/Homeseer, we’ll see what they come back with. Really hoping group 2 is supposed to work and they can get me there, or replace the switches. Without it there aren’t any 3-way circuit solutions that I really like w/their setup, unless I switch over to their hub which would be a nightmare given how many devices I have!
You can use the smartlighting mirror option, but of course that doesn’t run locally since I assume you’re using a custom DTH with this.
I deleted the other post because it was a lot of work to go through if it turned out the issue is just the number of supported association groups. There’s no harm in going through those steps, but it might be unnecessary work.
Let us know what homeseer says.
I think I tried the mirror option back when and it had a problem but I don’t remember what the issue was. Suppose I could try it again but first I’m gonna work w/Homeseer to try to get this going. It should support it according to their own documentation!
FYI I was able to included both devices w/security on, * networkSecurityLevel: ZWAVE_S2_AUTHENTICATED, set up an association group, still doesn’t work.
It doesn’t work if you just associate those two switches to each other? If that’s true, then it’s not the security level, it’s the association support.
Agreed … and the documentation very clearly states that they support association groups 1 AND 2, and all the old switches do support this. Hopefully they will just swap out my switches for ones that support the association groups as advertised …
@JDRoberts, re/mirroring, does this work w/switches, and is it bidirectional? You understand, what I want is for the light status to get updated on the second switch even tho it’s not connected to the lights (in other words, the LED’s on the second switch, that show light dimming level, should match the first switch, which is connected to the lights), and conversely, I want to be able to control the lights from the second switch, and have the first switch also reflect the lights status. If mirroring will do this then I"m golden but it looks to me like it’s one way.
You have to set up two automations. A mirrors B and B mirrors A. Then whichever one you turn on or off, the other one matches it.
See the FAQ