z-wave groups, scenes and associations

[RPerrault]

i think i will exclude the pc controller from the network and add a new device to see if it shows the command classes to create associations

 

[RPerrault]

exclusion went well - does not remove devices from pc controller but the reset button removed them

pc controller reverted to primary controller status (its own network)

added a new blind motor to the pc controller - this is what was added

obviously different - and it does show as eligible for association in the pc controller 

the difference

i added this directly to the pc controller and its discovery process (interview?) added the parameter support list directly

before, i included the pc controller to the eisy network with the pc controller acting as a secondary - the pc controller added the devices with information provided from the eisy (the parameter support list) - this list is incomplete when adding the device indirectly (from the eisy) - a possible explanation is the security level used when the blind was added to the eisy 

is the eisy not providing all the information to the pc controller when it is included?  or is the pc controller not handling the information from the eisy correctly?  

i doubt the pc controller's role as secondary matters because the older blind motors correctly

interesting that the pc controller shows support for all the command classes - the eisy never shows window_covering

i suppose i need to eliminate the security setting at inclusion caveat - i do not recall the security level i chose when including the blinds to the eisy - i'll exclude the device from the pc controller and add it to the eisy using the same security settings

 

[RPerrault]

excluded from the pc controller

added to the eisy - shows the same as the other newer devices

same command classes and parameters

i still do not get other entries in the above images - other people have an enter with basic association (or something similar)

 

[RPerrault]

opened a ticket and asked 2 things - does the eisy support z-wave beaming - and what parameter in the include (or interview) process determine eligibility for associations

the manufacturer says it does support associations

the pc controller sees it as supporting associations

the eisy does not

 

 

[RPerrault]

the 944 is listed as having support for beaming - the eisy is not listed at the z-wave alliance but i bet it does

my guess is that z-wave 'certification' is less than stringent on its process - that is speculated on here and from what i have read, associations are not widely supported among controller manufacturers 

i also suspect ud has no interest in supporting it - all the abandoned threads here add to that suspicion - i wish they would just tell us there is no interest in it - i can see why they are not interested in it - it is not easily understood - and the verbiage used by both z-wave and insteon can add to the confusion - without understanding it, it would be difficult to implement - and its not ud's job to teach us about associations

fortunately, i use few z-wave devices and none of them are for lighting - if i used more z-wave, i'd use a different controller 

we do have another shot at this though - if matter has stringent certification standards that are enforced, we might have an integrated solution with a choice of vendors - sounds like z-wave's goal but that seems to have gone awry

i'm still holding out for an answer on what parameter causes a z-wave device to be eligible for associations and why the eisy does not mark them as such

 

[peterathans]

15 hours ago, RPerrault said:

i also suspect ud has no interest in supporting it

I certainly hope not, as I'd like to migrate entirely from Insteon (where scenes work quite well) to Zwave.  Hopefully as long as the standard can support this behavior, then UD will find a way to have ISY support it too.

[RPerrault]

got some responses - first question was

>> does the eisy support z-wave beaming?

"eisy doesn't have any specific support for Z-Wave beaming, it is all done implicitly by the network."

ok so i am unsure what triggers beaming - if its a command to wake or what - or just part of the command that is sent - and will have to pursue this and flirs  - but for now, i'll assume it works

the second question

>>what parameter in the inclusion (or interview) process determine a device's eligibility for associations?  

"A controller can associate with other devices if it supports the Association and/or Multi-Channel Association command classes.  Any device can be associated with the controller as long as it supports the command being sent by the controller and was included at the same security level as the controller.  To actually use associations you create an ISY scene and add your controller and responders to it.

"You can get a detailed look at the command classes for a device by doing right+click | X-Ray | DH Command Classes | GO"

i am continuing this discussion with support and will let you know what i find

the ugly truth that i don't want to admit - i am going to have to understand associations and groups better - and have had difficulty finding an explanation for dummies

this comes closest

 

[RPerrault]

I see a lot of confusion about what zwave direct association does, so it might help just to go back to the beginning.

First, for those who don’t know how to change the parameters/associations on a Z wave device, see the following FAQ (this is a clickable link). This will also explain what we mean by “tweaker” in the remainder of this post.

 FAQ: How can I change the parameters on a Zwave device? FAQ

Many Z wave devices have “configuration parameters” which let you do a one time set up of the device. For lighting, this is typically things like the rate at which a dimmable light fades to off, whether the Indicator LED is on when the light is on or on when the light is off, etc. For a siren, it might define whether both the sound and a strobe light were triggered at the same time. For a motion sensor, it might be the duration of the inactivity period before it reports again. Other devices will have other configurable parameters. And it’s up to each manufacturer to decide exactly what parameters will be configurable for each model. Typically the options will be listed in the user guide for the device. So far, so good. But now how do you actually set those parameters what you have a dev…

Now on to how zwave association works. 

Back before people used smart phones and apps to control home automation, Z wave was introduced primarily for lighting control. The idea was to come up with a very low power system that could work quite quickly When a motion sensor triggered a light switch or when an auxiliary light switch triggered the Master switch.

These devices would be physically quite close together, typically in the same room.

Zwave also tried to keep its individual messages as tiny as possible, because that would require less power to transmit.

This led to the introduction of two features.

1. “Basic” commandsets. “Basic” has a very specific meaning in zwave. The hub might send a single “basic” command to a group of devices. Maybe one is a switch, one is a siren, and one is a window shade. Normally each of those would have its own device-class specific commandset. That is, turning on a switch is not the same command as opening a window shade. But when you send a basic commands you tell the receiving device to perform its “primary” function, whatever that function is. So the light switch knows that it’s a switch and the siren knows that it’s a siren, but in that moment the hub doesn’t care: it is just telling each of them to do what it was designed to do. This keeps the message small.

2. ”Direct association" .One of the original use cases for Z wave was having a motion sensor trigger either a light or a siren. And people wanted thIs to happen as quickly as possible, usually under one second. In order to make it very fast, “direct association“ was introduced. In direct association, a trigger device (the sensor) was given permission to send a “basic“ command directly to a nearby target device (the light switch or the siren) Without sending that message through the hub.

So the trigger device just kept a list of the device IDs of the devices that it was permitted to send the basic command to. That was all association meant. The hub approves a specific list of device IDs to be used by the trigger device to send basic commands to the target devices.

The hub doesn’t care why the trigger device Will send the command. It doesn’t need to know when the command is sent. It’s just approving the creation of the list, which is then stored in the firmware of the trigger device.

So, “Sensor 4, you have permission to send a basic command directly to light switch 2. “

Or “auxiliary switch 15, you have permission to send a basic command directly to master switch 9.”

That’s what direct association is.

Note that only the trigger device has to “support association.” Most devices can receive a basic command, so you don’t actually have to do anything special with the target device. (The exceptions are “controllers.” A lot of them won’t accept a basic command, especially if they are battery-operated. They are intended to be triggers, not targets.)

If you want two switches to be able to trigger each other, They have to each support association, and you have to set up the association twice, once for each trigger switch.

Later on more capabilities were added to association, in particular the ability to send some reports like energy levels for energy monitoring devices, but the basic concept is the same. The trigger device will decide what to send and when. It will send that message to the list of device IDs that were approved by the hub when the association was set up.

So far so good. 

association groups

Then device manufacturers started getting fancier. They said, “wait. I’m making a motion sensor, but it also has tamper detection. If the motion sensor detects motion, I want to immediately turn on the light. But if the motion sensor detects tampering, I want to turn on the light and the siren.”

Remember that the whole goal of all of this is to keep the messages as simple and small as possible.

So zwave introduced “association groups.” That just means that the trigger device will be allowed to keep more than one list of target device IDs. It’s still just going to send a “basic” command, but it might have a different trigger condition for the different groups as in the example we just gave.

Group 1: just the light.

If the motion sensor detects motion, send the basic command to the devices in group one.

Group 2: the light and the siren

If the motion sensor detects tampering, send the basic command to the devices in group 2.

That’s all there is to it.

Some manufacturers build devices that can only support two association groups. some can support more than a dozen.

Usually each group will be limited to a maximum of five target devices, but again that’s up to the manufacturer.

You can always look up the exact Association group details for any certified Z wave device by checking its conformance statement at the official Z wave alliance products site. (Remember that you want to look up the details for the trigger device. The target device won’t actually use its own association lists when its acting as the target. In fact, the target device doesn’t have to support association at all. It’s just going to get the basic command and then act on that.)

https://products.z-wavealliance.org 37

changes with zwave plus

Originally all association was optional. Some devices would support it, some would not. Manufacturers could use the association groups however they wanted to.

But by the time of zwave plus, many hubs also had mobile apps, and there was a lot more concern about keeping the hub updated with what was going on with the wall switches. So association changed a lot. Almost all devices are now required to support an association group one, which would be used only for communication with the hub itself. This is called the “lifeline” group and is mostly used for status reports.

So while we used to just ask if a device “supports association” now we have to ask if the device “supports more than just lifeline group association.”

See the following FAQ (this is a clickable link)

FAQ: How zwave direct association changed with zwave plus 37

 

link to post - https://community.smartthings.com/t/faq-zwave-association-between-2-devices/132016/6

 

[RPerrault]

FAQ: How zwave direct association changed with zwave plus

You have to be careful with this question because the functionality of zwave association changed significantly with zwave plus.

In the older Z wave generations, association was optional, and manufacturers could and did implement it pretty much any way they wanted as far as which command sets were used in which association groups. For example, Fibaro quite famously used one Association group specifically for tamper notifications. While other manufacturers who made multi-button Devices might use one Association group for each button. It got pretty confusing.

With zwave plus, they decided to regularize how association is used, while still maintaining backwards compatibility for previous generations.

So…

ASSOCIATION GROUP ONE IS NOW RESERVED FOR THE HUB

Almost all zwave plus devices must now support Association group one as a “lifeline” Group which reports status to the hub. For example, Battery operated devices are now supposed to report their battery status via the lifeline group. Association group one in zwave plus is not used to trigger events on other end devices. This is almost the opposite of how it used to be, because most manufacturers used to use Association group one for the communication between two end devices and then use additional association groups for other purposes, including notifications to the hub.

If the zwave plus device is supposed to be able to trigger events on another end device without going through the hub, it will probably use Association group two for that, as that is not considered a lifeline condition.

So the answer to your question is going to be yes for any zwave plus device, because now they all support association. But they only are required to support it for the lifeline commands in Association group one. To get the direct communication to another end device, such as linear uses for their virtual three ways, you now have to look at exactly which association groups it supports, because the ability to send basic commands is now going to be in Association group 2 or higher.

But remember the backwards compatibility requirement for Z wave, which means there may be some devices on the network still using Association group one for something other than lifeline messages. 

All of which means you just have to look at each individual Device to see if it supports the specific use case you have in mind.

https://products.z-wavealliance.org/regions 86

HAIL IS NOW DEPRECATED

Also, Note also that the hail command class was deprecated for the newest Z wave plus devices, and they should be using lifeline association instead. But because zwave is required to be backwards compatible, hubs should continue to support hail so the older devices will continue to work.

See Section 4.17 in the Management Commands documentation.

zwavepublic.com

SDS13782-5%20Z-Wave%20Management%20Command%20Class%20Specification.pdf 69

 

 

S2 Secure devices can only be associated to other devices at the same level of security

Also, with the introduction of the S2 security framework you can now only make associations between two devices that both support that framework if you have the higher levels of security turned on.

THE AEOTEC MINIMOTE Can only be used to make associations for older Z wave devices since it can only create associations for group one

And finally note that the Aeotec minimote, which was a popular fourth generation device for making associations, is useless for Z wave plus associations because the minimote will try to put everything into association group one, and now nothing is supposed to go into association group one except the hub itself. And it can’t put anything into Association group two or three.

 

link to post - https://community.smartthings.com/t/faq-how-zwave-direct-association-changed-with-zwave-plus/89304

 

[RPerrault]

have to learn about associations and groups and scenes so you know what questions to ask

my question about my devices was 'do your devices support associations?' - the answer was yes - technically true - it must support association group 1 - 'lifeline' - reserved now for an association to the controller - it must support that for certification

that is the only group it supports - i need a second group to be supported to do what i want (group 3 devices together) - from above, i learned that those groups do not have to follow a standard (dimming or binary switch for group number 2) but is left up to the manufacturer

bad news for me - but what about all the people wanting a 3-way switch setup?  that seems to be fairly common

unfortunately, i don't have any z-wave switches - and it looks like all my z-wave devices only support group 1 associations 

i am not sure how its done with the eisy - how do i assign a device to group 3?  the device supports it - all i have read is that adding to a scene does the magic

i'll try to digest post more thoughts