I have also verfied that they support associations.
Can some one please guide me? I have tried to use the z-wave tweaker, and while the devices seems to be associated, turning on off had no impact on the other.
Is the DTH supposed to be modified to handle the on/off event? Can some one please guide me? I am new to ST and z-wave.
So from the manual I gather that group 2 is for the on/off detected by L1, and group 3 is for L2. So assuming you put a swich on L1, you need to include the Aeotec in group 2 of the Qubino device using the tweaker.
The setup is: Microwave connects to the heavy duty switch. L2 on the relay is blank; but I want to control the heavy duty switch with the L2.
One basic Q: If the association is one way, meaning control the HDSS via L2, do I need to tweak just the L2 or both (L2 & HDSS)? Are associations one way or 2 way? Do I need to tell HDSS to listen to L2?
I had tried to tweak L2 and had added group association. While I could see the parameter update, the switch function didnt toggle HDSS. Does the handler need tweaking of HDSS need to be tweaked?
Associations aren’t two way. Groups are always tied to 1 device, it depends on the device definitions what kind of groups it has and what they do. In this case since your Qubino triggers your Aeotec you need to use Qubino’s group. So you put the Aeotec in group 3 of the Qubino, which will have the Qubino send on/off events from L2 to that group and effectively to the Aeotec. You also need to configure the state of the L2 (normally open or closed).
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.
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.
“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.
”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.)
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.”
Since this is a zwave plus device, we expect to see Association group one as a lifeline group, and so it is. Note that the Aeotec device is only going to send reports to this group. It’s not going to send a basic on/off command. So normally the only device ID that would be listed in this group is the hub itself.
But we also see that there is a second Association group available, group 2. You will be allowed to add five different device IDs to this Association group. And when you turn on/off the Aeotec device, it will in turn send a basic command to any target devices in this group.
So to create an association such that turning on the Aeotec would turn on the Qubino, all you have to do is add the Qubino device ID to the association group 2 list kept by the Aeotec.
( i’m guessing you will have to actually identify the Qubino endpoint, but I’m too tired to go into all that today. Just read the tweaker documentation and it should explain.)
To set up an association so that the Qubino would turn on the Aeotec, you go through a similar process. Read the user manual for the qubino or check the official zwave website and figure out which Association group you need to add the Aeotec ID to. Then assign the tweaker DTH to the QUBINO, And save the Aeotec ID in the correct Association group. That will give the Qubino permission to send a basic command to the Aeotec.
Don’t just choose an association group at random: each manufacturer will have decided how it handles each group and what the triggers will be for that specific group and what messages will be sent. (For example, it is common to put on/off switch targets in knee association group and dimmer switch targets in a different group, because the basic command for dimmers has to include the desired dim level.) So you always need to look up the details for the trigger device to make sure you understand which association group you should use for which target device IDs.
Also note that most of the time, if you have a smartthings hub, you won’t want to use Zwave direct association, even between 2 Zwave devices. You will have three advantages if you let the messages go through the hub instead:
the devices can be much farther apart physically. So you could turn on the switch in the entryway and have all of the outside lights come on all around your house. Direct association will limit you to one hop between the two devices.
The devices don’t have to both be zwave. They can be any protocol that can communicate with the hub, including Z wave, zig bee, LAN, cloud to cloud, etc. you can even include virtual devices.
the hub will always know what’s going on, so the App will stay in sync.
One of the most popular alternatives to zwave direct association is the “mirror” feature. If you are using SmartThings classic, this is under the official smart lights feature. If you are using SmartThings (Samsung connect) it’s just in the regular automation section.
Note the “mirror” sets up a two way communication, so it’s much easier to set up and maintain then a virtual three-way using Z wave direct association.
Honestly, at this point the only reason to use z wave direct association if you have a smartthings hub is if you are trying to plan for smartthings outages. But otherwise I would just use the regular hub automation features instead.
@JDRoberts thanks for the great explanation.
One thing I am curious about: does the z wave security have any impact on the ability to setup direct associations?
@JDRoberts Thanks a ton for the explanation. This could easily become a guide for anyone trying to do association and automation.
I see your point of routing the request through the hub. It does make sense in many cases.
I however have very basic requirement of on-off (Aeotec heavy duty switch doesnt work off a physical switch and I have to get this done for my parents who arent phone savvy); also network isnt stable in this part of the house. So I would try direct association atleast for this one.
Unfortunately, I was not successful in the direct association. Setting device network ID of Aeotec in Qubino Group 5 (switch 2 basic set) (via tweaker) didnt yield desired result. What could I be doing wrong?
I would ask your question in the tweaker thread. The author will be automatically notified when new posts are added to that thread, and other people who are using the same code may also be able to help.
In the mean time, could you please let me know if there is something obvious that I may have done wrong?
Following is the raw data of heavy duty switch (Device network ID 08):
zw:Ls type:1001 mfr:0086 prod:0103 model:004E ver:3.26 zwv:3.92 lib:03 cc:5E,86,72,98,56 ccOut:5A,82 sec:25,32,31,27,2C,2B,70,85,59,7A,73 role:05 ff:8700 ui:8700
In my Qubino, I have set Group 5 to 08. I can also see the following in the properties of Qubino when updated
Because I rely on text to speech software, I really can’t help you with the details at this point. Just ask in the tweaker thread, someone will be able to help there.
Once set up, association is handled by the firmware of the trigger device, the DTH won’t affect it all because the commands don’t come back through the hub/cloud. They just go directly from the trigger device to the target device.
I think you’re right about Z-Wave Security being the problem. It looks like the heavy duty switch is using Security (S0). It is probably rejecting any non-secure commands, like the one from the Qubino.
Most of the Aeotec Gen5 devices can be included without security by tapping the button once, and with security by tapping twice, but I’m not sure the Heavy Duty Smart Switch has that feature. I can’t find mention of it in the manual.
Even if it doesn’t have a way to initiate non-secure inclusion, this device would still work without Security. The issue is that the SmartThings hub always tries to include securely if it’s supported by the device. If you have another controller, even an Aeotec Minimote, removing and re-adding the switch with that could work.
I was looking for something else in the public specification, and came across this, which does look like security may be the issue in associating these two devices:
4.3.3 Security considerations
A node which has been S0/S2 bootstrapped MUST NOT accept Association commands unless the commands are received via the highest security key granted to the node during bootstrapping.
.
A controlling node SHOULD NOT create an association if the source and destination nodes are bootstrapped with different security levels.
