Child Device Status Updates After ZWave Direct Association

Devices & Integrations
1

Hello - I have set up several Zwave direct associations from Switches and Remotes to control other switches and outlets. The associations are working great for On/Off control on Association Group 2. The problem I am having is that when a child device is turned on or off by its parent through Direct Association, the child device’s status is not updating in SmartThings. Example: Switch 1 (Parent) turns on Outlet 1 (Child). Outlet 1 (Child) will be on, but the SmartThings status will remain as “Off”

Is there a way to make the child device status update the hub when it has a status change via a direct association command from its parent?

2

AFAIK you will have to take that up with the device manufacturer… Unless the device itself announces a state change theres nothing SmartThings can do short of periodic polling and thats just not a good idea.

This came up with Leviton a while back…

Read the thread and who knows if you have Leviton stuff - there was a firmware for it.

3

I’m confused. :thinking:

In a smartthings context, a parent/child relationship is for a multi component device, like a power strip with five sockets. The strip is the parent and has the network ID. Each of the individual sockets is an endpoint on that address. Smartthings calls this a parent/child relationship. The independent third-party protocols, Z wave and Zigbee, don’t use the term children for these: they call them endpoints.

image

Nothing in this relationship is based on zwave direct association.

The relationship between a switch and a socket where each has its own network address and turning on the switch sends a radio message to the socket to turn on is a trigger/target relationship. That’s what you set up with zwave direct association.

If you are saying that when you turn on the switch, the socket, a separate independent device, does turn on but the hub doesn’t know about it, so the app doesn’t get updated, that’s correct. That’s how Zwave direct association works: the two devices are allowed to communicate directly without going through the hub.

If you want the app to update, usually all you have to do is add the hub to the association group so it also becomes a target. That way it will receive the command and it should know enough to know what happens next.

But as @nathancu mentioned, it does depend on the specific brand/model of each device, so we will need to know that to be able to help more.

That would also tell us whether you are talking about a parent/child relationship or just a target/trigger one.

(Also, I suppose we should note that Zigbee does use the terms parent and child, but it has to do with route construction, it’s not the same as the smartthings usage.)

1 Like
4

@JDRoberts thank you for clarifying! You are correct that I should have described what I am trying to do as a trigger/target relationship.

I’m using a Zooz ZEN34 Remote (as trigger) and controlling a Minoston MP21ZD dimmer outlet (as target). I have both devices set to Group 2, and the ZEN34 (trigger) set with MP21ZD as a group member.

Are you saying that I should add the hub as an associated member on the MP21ZD? And can I associate the MP21ZD to both Group 1 and Group 2? Sorry for so many questions - I can’t seem to find instructions on this part anywhere.

5

For newer Z wave devices, which includes the two that you listed, association group one is always the lifeline group. That should have the hub in it and only the hub.

As far as the other Association groups, that’s entirely up to the manufacturer and different models will use different groups for different purposes. But however they are going to use them, it has to have been listed as part of the application for Z wave certification. So the information should be on the official Z wave alliance products site.

When you create a direct association in zwave, literally all you are doing is having the hub give the trigger device permission to send direct network commands to the Target devices without going through the hub first. Seriously, that’s all there is to it. So you don’t do anything with the Target device. It’s going to get the message and then it’s going to act on a message, and it doesn’t care whether the message came from the hub or came from another device. Policing that is left up to the hub.

Creating an association means updating the firmware of the trigger device with the network IDs of the Target devices that it is allowed to speak to directly.

I don’t understand what you mean by saying “I have both devices set to group 2.“ That’s something you could do with zigbee, but it’s not how zwave devices work. :thinking: so for now, I’m going to ignore the fact that you said that. You should not have to change anything for the minoston for this use case.

So let’s see how that Zooz model uses associations.

https://products.z-wavealliance.org/products/4114?selectedFrequencyId=2

OK, it looks very straightforward. It uses association group 2 for basic on/off and association group 3 for dimming.

image
image2048×1536 324 KB

Now the first trick. With most zwave hubs you would just put the id of the minoston into group 2. But with SmartThings, you may find that the app status works better if you also put the hub into group 2. So start by trying that and see if it fixes the problem. Still leave the hub ID in association group one also, by the way. And don’t do anything with the association groups for the minoston. The association groups for the minoston are used when the minoston is the trigger, not when it is the target.

If that doesn’t fix it, then it seems likely that the minoston is just not reporting its change in state, which isn’t that uncommon for a plug.

I would report that to minoston and support and see what they say.

What DTH are you using for the minoston?

1 Like
6

The only quirk I’m aware of with the ZEN34 associations is that devices in group 3 don’t get sent anything when the up/down paddles are tapped once so if you want to be able to turn on/off and change the dimmer level of a device you need to add it to groups 2 and 3, but that’s not related to this issue.

I’ve seen some devices send reports to the lifeline group last so I can see how adding the hub to the other groups could fix status update issues for the trigger device, but I don’t see how that could have any impact on the target device…

This is most likely the problem.

1 Like
7

Zwave direct association literally just gives the trigger device permission to send “basic” (that has a specific meaning in zwave) commands directly to a list of device IDs that the trigger device keeps in its own firmware. Exactly what gets sent and when is then up to the trigger device’s own internal logic. With the exception, as of zwave generation five, of association group one, which is now reserved for Messages sent to the hub. But otherwise it’s up to the device manufacturer how many association groups a target device can have and what they will be used for.

Some devices have a dozen or more different association groups used for different purposes, and the same target device might be put in multiple groups.

Just think of an association group as a file folder that the target device keeps for itself. Then the target device might have internal logic that says “when my button 2 is pressed, I’ll send a basic “turn on” message to the IDs in my group two.” And “if My cover is removed, I’ll send a tamper alert to the IDs in my group 11.” Etc.

The point is that in zwave, each trigger device keeps its own set of file folders. So different trigger devices might use their own association group 3 differently. And a target device might be in many different association groups for different trigger devices. Or, as in @krlaframboise ’s example, a target device can even be in two different association groups for the same trigger device. Maybe one group for on/off and a different group for dim level.

Or in a multi button device like the zooz zen32, a target device might be in multiple association groups because of how the buttons were being used. Maybe button 1 turns off all lights, button 2 turns off all downstairs lights, and button 3 turns off just the living room light. Then the living room light switch might be in association groups 4, 6, and 8 on that particular zen32 because those are the file folders where the zen 32 keeps the list of IDs for those functions.

image
image1000×1000 300 KB

image
image2048×1536 391 KB

In zwave, a target device doesn’t even know which groups it’s in. Groups are just internal organizing structures used by the trigger devices for themselves. A Trigger device can tell you What device IDs it has on its own lists. Target devices don’t know what lists they are on, and they don’t care. They just respond to the network commands.

Note that this is VERY different from how groups are organized in Zigbee. In Zigbee, there is only one group 2 for the whole network and each device can only belong to one group. But that’s not how it works in Zwave.

@garrett.kranz

1 Like
8

A couple more thoughts this morning…

  1. When you were starting out, I believe you also made some changes to the target device. Those would not have been necessary. Check one more time to make sure that the hub ID is still in the Minoston’s association group one and you didn’t delete it by mistake.

Also after that make sure you reassign the minoston to its original DTH and don’t leave it on the Tweaker. The Tweaker is just an administrative tool to update device configurations. Once those changes are made and saved in the device itself you need to go back to the original DTH in order to use the device again.

  1. once you know the hub is correctly listed in the lifeline group (association group one) for the minoston and it’s using the right DTH, try just pressing the power button on it. Does the status change in the ST app? If it doesn’t, or if it changes in the ST app but not from the command sent through direct association, then report those details to minoston support and see what they say.

3);If you’re not sure exactly what you did or should do with the minoston, the safest thing is to delete and readd it, preferably through a “Zwave replace” so you don’t have to redo your routines and the zooz association groups yet again. I’m sorry, I’m not up to date on ST: I don’t even know if you can still run a zwave replace or not. :thinking: @nathancu might know. (Historically the ability to do a zwave replace for ST has been removed a couple of times, although it should be a standard zwave utility.)

If SmartThings doesn’t offer the replace option, you have to do a lot of manual housekeeping, including redoing the associations for the zooz to use the new network ID. :scream: if you can use a replace, the very good news is that that process will reuse the original device ID, so that housekeeping isn’t necessary.

9

Replace isnt working at the moment… Theres the Hex ID replacement trick in the IDE that may work but I don’t advise it.

10

:disappointed_relieved:

That’s, well, appalling for a certified zwave hub. But so it goes…

1 Like
11

@JDRoberts I appreciate all the help! I didn’t include the Hub as a target for the Minoston Outlet. I will give that a try tomorrow. I had thought that when a device changed status (even through an association command by a trigger device) it would automatically update the hub. I didn’t realize the target device also needs to be associated to send the Group 1 commands to the hub.

12

@JDRoberts your advice worked! Thank you for all your help. The problem was that I hadn’t set the target device to send commands back to the hub. I just set the Minoston to Association Group 1 and added device 1 (Hub) as an associated group member and now the Minoston status is correctly updating via the hub when it’s turned on by the ZEN34.

2 Likes
13

Happy to hear it!

All zwave plus or newer devices are now required to put the hub in association group one at the time of joining so that they can use that group to send “lifeline“ messages to the hub. And that includes status messages such as when a device is turned on, or in the case of battery powered devices when the battery gets low.

You shouldn’t have to put the hub in that group, it should happen automatically at the time of joining, so my guess is that you accidentally deleted it when you changed the association groups for the target device.

In any case, I’m glad it’s fixed now! :sunglasses:

1 Like