Attempt at a primer for association groups

Community Playground General Discussions
#1

Hi,

As I learn more about Vera(Plus) and Z-Wave networks I find my number of question increase. In my attempt to associate two switches I had many questions regarding how association groups work. This summarized what my research on association groups found.

The below information is preliminary and likely to have some misinformation. I’m hoping folks with more experience will critique it and folks with questions after reading the below will ask them so the wording can be changes to make it clearer.

I thank everyone in advance for their input, good / bad or questions.

JohnRob

Associations / Groups:

Associations are a way to allow communication between two z-wave products without a z-wave controller. An example can be a motion sensor that directly turns on a light switch.
A device has one or more association groups. Multiple devices can be added to one group. These groups usually have different functions. It?s possible that association group 1 sends a ?Basic? command to multiple products and association group 2 sends a temperature report to the main controller.

[ul][li]There is no Group 0, never was.[/li]
[li]Group 1 is a special group ### more info needed ### which by default all devices ?listen to? or monitor. Sometimes called Lifeline.[/li]
[li]Every device is by associated with Group 1 by default during Vera include.[/li]
[li]The number of Groups available for a device is determined by that device (not by Vera). In the above example, the motions sensor may have three groups.[/li][/ul]
o Group 1 by default is used to send all the data the motion sensor generates (say motion and brightness) ### need to verify this###
o Group 2 might be motion only status from the sensor (determined by the sensor design)
o Group 3 might be brightness only from the sensor (again determined by the sensor design)

    Another example might be a light switch: 
       o   A single tap on the lightSwitch ID:5 would send a Group 1 signal to lightSwitch ID:#6.
       o   A double tap on the same lightSwitch ID:5 would send a Group 2 signal to lightSwitchID: 7.

[ul][li]Groups are not global. I.e. it is possible for motionSensor ID:5 to be associated with lightSwitch ID:7 using Group2. At the same time is it possible for motionSensor ID:8 to be associated with lightSwitch ID:9 also using Group2.[/li]
[li]In this case motionSensor ID:5 will not affect the operation of lightSwitch ID:9. [/li]
[li]In theory there can be 255 groups (#1 to #255).[/li]
[li]Group 255 is a special group for Hail all. ### need more information here ###[/li][/ul]
I have yet to understand endpoints and how they would / should be entered into the field next to the target Set checkbox in UI7 association screen.

end Rev 0.2

1 Like
#2

Unfortunately how Association groups are used varries from device to device.
You “Groups are not Global” Statement is Correct, and the example there is correct.

Other generally true statements are that while any device can be the target of an association (aka be controlled by another device via association), only some devices have the ability to setup/create associations. You usually can’t have more than 5 devices in a group on a single device. For devices that support multiple groups there is usually a max limit for the device as well (like 5 per group ID but no more than 10 total).

The purpose of the group ID for a given device device varies. Most devices use either group 1 or 2 for basic on/off or on/off/dim commands. Some devices have a special Hail group that only supports 1 device, it is usually group 255 or 1., generally you can put the Vera Z-Wave in there if instant status is not working properly on the device (hail is usually only available on instant status devices).

Some devices let you define what a group ID does with parameters you set on the device. other devices use different groups for different behaviors. Like Group 1 might support on/off, while Group 2 only support On (you see things like that on motion sensors some times). Some like on the Fibaro button define how many clicks are associated with sending on/off with the group ID. 1 click controls devices in Group 1, 2 clicks send on/off to group 2. So basically you have to read the documentation for the device.

It is also important to note that associations really only exist on the device you set them on (not the target, and not the Vera). Vera cannot poll what associations you have setup on the device but it does try to remember what associations you setup via Vera and show you in the UI. If you have to delete and re include a target device for example, and reset up the association, the old broken association may still be there but Vera won’t know about it. Tip if the device you configured the associations on is being very slow to trigger the target devices there are probably some broken associations on the device.that Vera doesn’t know about. The on,y way to clear them is to remove the device from the Vera, re add it and start over.

Some statements like every device is associated with Vera in group 1 is false.

#3

Interesting! Subscribed…

#4

Thank you shallowearth. If it is OK with you I would like to incorporate some of your wording in the the “primer” (with credit to you of course).

For Group 255:
It not clear what group 255’s function is for. From you post it seems it might be an alternate path for “instant status”. Although I can only assume status would be in the aggregate data sent to Vera “normally”?

Thanks

JohnRob

#5

Yuck. This is such a difficult concept to explain because of the poor choice of naming that Zensys started with. Lots of ambiguity and complication here. What follows are some random thoughts that may simplify things a bit.

Think of groups as a list of other Z-Wave nodes(devices) that a device stores internally. Following your example; a motion sensor may store a list of light switch node numbers. When tripped the motion sensor sends an On command to all switches in its list. It doesn’t send a Group 1 command or anything about group. It just sends an On command to any device in the list.

The lists indicate targets for commands or notifications. Whether it is a command or notification will depend on the device type and manufacturer’s choices. There’s no requirement that a particular Group number be used for temperature notifications or On commands. But, the motion sensor will send the command or notification to all devices specified in its list.

Since some devices can store multiple lists, the lists are identified by a number arbitrarily set by the motion sensor’s manufacturer. It’s only logical that they start at 1. Group 1, Group2… Group 255. They are just list identifiers and they are just local to the motion sensor. Group 1 on one motion sensor is totally different than Group 1 on another motion sensor. They are two separate lists.

[quote=“JohnRob, post:4, topic:194694”]For Group 255:
It not clear what group 255’s function is for. From you post it seems it might be an alternate path for “instant status”. Although I can only assume status would be in the aggregate data sent to Vera “normally”?[/quote]
Group 255 is not special, except for that device manufacturer. The likely reason that the manufacturer chose 255 is to separate it from any other groups because the manufacturer intended it to only be used to notify the controller for Instant Status and putting it at 255 eliminates or reduces the chance of someone using it accidentally or on purpose for anything else. But, they could just as easily have chosen to use Group 1 for Instant Status updates.

Vera is not “normally” notified by most devices. For example, most switches will not ever notify Vera that they have been turned on. Vera polls Z-Wave devices periodically to determine their current state. Only switches that support the Instant Status feature will notify Vera, and other controllers, of a state change and some of them use 255 as the list identifier for the list of controller nodes that the updates are to be sent to.

#6

@Z-Waver

Thank you. I will try to word the group definition better.

If I understand your reply correctly; No groups are special in a Z-Wave network. Its just by some convention some device mfg use Group 255 for instant status.
That leads me to ask: If a device mfg decides to use Group 255 to communicate “instant Status” does that mean I must associate Group 255 to Vera somehow to be able to trigger a scene? In the “set” page would I choose (in Unassigned devices) “ZWave” or “_Scene Controller”? Or both?

If they don’t use Group 255 for “instant” status, is there another path to get IS to the controller (besides another Group #)?

Thanks

JohnRob

#7

Yes. But remember that it’s still just a list of node(s).

That leads me to ask: If a device mfg decides to use Group 255 to communicate "instant Status" does that mean I must associate Group 255 to Vera somehow to be able to trigger a scene?
No. You should not have to do anything. The device or Vera, I'm not certain which, will add the controller's node number to the list. Sometimes things don't go as they should and those rare cases will cause you to see posts on the forum about people configuring Group 255. I don't think any of the manufacturers actually disclose Group 255 in their docs, as they expect it not to ever be touched by the end user.
In the "set" page would I choose (in Unassigned devices) "ZWave" or "_Scene Controller"?
Again, you shouldn't be setting Group 255 under normal circumstances. However, I believe that ZWave represents Vera in this case.
If they don't use Group 255 for "instant" status, is there another path to get IS to the controller (besides another Group #)?
Again, a group is a list of nodes. Group 255 is a list of controller nodes. It is not a communication path. It is just the list of nodes that the device is supposed to send its status to. Instant Status updates use the same communication path as any other command class.
#8

@Z-Waver,

Many thanks. I will regroup and absorb your comments then re-issue for another try (hopefully much better).

I plan on giving credits you you and shallowearth if you don’t mind. (i.e with much help from …) or something like that.

JohnRob

#9

Does “instant status” even need association? That is, would it not be possible for the switch device to simply know to send the updated status to the controller (is this at a fixed address or known from the initial configuration) whenever its state changes?

Similar question: how does a temperature sensor or door sensor know where to send its updated status? Is that through an association (presumably default association)? Or does it simply always send to the controller, and you can add associations (if possible) when you want it to send to something else?

#10

Most sensors, switches etc use a “pull” model meaning ,that they only update on the Vera when the Vera asks them for the data. Vera can ask as frequently as every 1 minute for data so it often appears like the devices are pushing data to Vera, when in fact they are not.

The two protocols that I know of that are “push”, those are security protocols for motion/window door sensors and instant status.

Direct association back to the Vera is generally not needed for either of these, but where the security protocols seem to be fairly standardized with message so going out to both other neighbor nodes and the Vera and passed along to get there. Instant Status has been implemented in different ways by different devices and so can be a little unpredictable.

For example GE switches have the most weak implementation of instant status (it is not even considered true instant status), they send out a broadcast on a state change that only the Vera will listen to and neighbor nodes don’t listen to and won’t pass on, so if your GE switch is not within direct radio distance to the Vera, instant status won’t work and it does support direct association either.

Cooper switches support direct association, with out any special configuration, and state changes will be passed on by other nodes to get to the Vera, however if you have a secondary controller (like a scene controller or minimote) that has scenes that control that switch, the Cooper can get confused where to send the instant status info to, and it can get routed to the secondary controller instead and never passed on to the Vera. You can fix this by either using a 255 group association, or a group 1 association back to the Vera to help get the packets routed to the right controller. Levitons (which instant status works very similar to the coopers) may also be susceptible to this issue and can sometimes be straightened out with a group1 association to the Vera.

Dragon (homeseer switches), have some kind of new instant status that works more like the security protocols, that Vera doesnt support yet. The dragons also recently added the abilities to go direct association, may a direct association to the Vera will work arround the lack of Vera support for the protocol, who knows?

Fibaro relays and Aeon Micro switches also support instant status with not special direct association needs. Don’t know if they have the same weakness as the cooper/Levitons.

Note that you can tell if a device supports creating Direct Associations if it has number 133 in its capability string.

#11

@JonRob - You’re welcome to do whatever you like. I’m fine about you doing this with or without attributing me. No thanks necessary, really.

These two subjects, Associations and Instant Status, are such a wretched rabbit hole. None the less a couple of clarifications.

@jswim788 - Technically Association groups are not required to implement Instant Status. The two are separate concepts, though implementations seem to make Instant Status dependent on association groups. The switch could set the master controller as the notification target at inclusion and be done. But, this is less flexible in that should the controller’s node number change with a controller shift, or a user preference, the only option would be to exclude and include. Using a “hidden” group allows the added flexibility of being able to change the specific controller to notify and offers the option for the manufacturer to notify more than one controller if they wish.

This plays into @shallowearth’s reference to cooper switches. They use group 255 as their list of targets for Instant Status notifications. But while Cooper allows 5 nodes in their group 1 list, they only allow one node in their group 255 list that they use for Instant Status notification targets. I don’t know if Leviton has similar limits.

In any case, by using group 255 it is possible to change the desired target for the Instant Status updates.