MCO Home MH-S312 and MH-S314 - Anyone has these working properly?

Zwave Direct Association was a very simple concept. The idea was that since most zwave applications initially were for lighting, and this was all before people had smart phones, it would be sometimes useful if one Z wave device was allowed to talk directly to another Z wave device without having to go through the hub. In fact, the hub would not even be aware that this had happened.

The most common use case was a “virtual three-way“ where you have two switches which control the same Light. One is the master, which actually controls that circuit branch with an on/off relay. The other is an accessory switch which simply sends a message to the master switch telling the master to turn the light on or off. There is no physical wiring between the two switches, they communicate by Z wave message.

Normally in a Z wave network all messages are either to the hub or from the hub, although they may go through repeaters along the way.

Z wave Direct Association said “let’s give the accessory Switch permission to send a message directly to the master switch so everything will work faster and the light will come on sooner.”

So when you set up an association, the trigger device is asking the hub for permission to be able to in the future send a “basic“ (that has a specific meaning in a zwave of context) Message directly to another device on the same network. The hub has to approve this initial setup for security reasons. Then all the trigger switch does is store the network IDs of the allowed target devices in its own firmware.

From then on, when whatever event that was specified by the manufacturer occurs, typically a button press, The trigger device sends the basic command to the target Device IDs stored in its own firmware for that event. Again, The hub doesn’t even know that this happens.

Supporting association is optional, and because it does take some memory, not all manufacturers choose to support it. And if they do choose to support it, it is up to them how many targets and how many different Association groups they choose to implement for any one device. Historically, I think Fibaro has probably done the most with these, if you can find one of the manuals for their first generation multisensor you will see what I mean. :wink:

How Smartphones Changed Everything

This worked really well for the early generations. But then came smart phones, and suddenly everybody wanted instant status updates of everything. Yet the whole idea of direct association had been to bypass hub communications in favor of speed to action.

So… People started adding the hub into association groups so it would also get the basic message when the button was pressed. It was up to the hub to decide what to do with it, and usually all that it did was toggle status displayed in the phone app. So it didn’t slow down the process of turning on the light.

And, once again, Fibaro historically led the way in using this approach for all its many different association groups.

Many hub manufacturers, including smartthings, started automatically adding the hub to association group one Whenever a new device was added to the network if it supported associations. But that could cause some problems (again, see Fibaro) because initially manufacturers were allowed to use association groups anyway they wanted to as far as what was assigned to each group, and some were using group one for a different purpose. And if you wanted the smart phone status update, you really need it to have a group two or even three.

Also, many manufacturers limited the number of group members, typically to either two or five, and if the hub was taking one of those slots it could get messy.

This issue was not resolved until zwave plus. More about that later.

Multichannel association

People started getting clever with using association (and once again, see Fibaro), and instead of just using it to simply tie together two light switches, it began to be used for multisensor reports. A multisensor would have multiple endpoints: say a temperature sensor, a humidity sensor, tamper tamper alert, and A lux sensor. The multi sensor itself only has one network ID, but each individual Sensor is given a different “endpoint“ number by the manufacturer.

Some manufacturers wanted to be able to send information along with the direct association Basic command so that the target device would do different things depending on which endpoint from the trigger device was sending the message.

This was important both for actuating target Devices and for smart phone status displays.

You don’t, for example, want the same thing to happen if the multisensor reports humidity is 80% as if it reports temperature as 80°.

This was also used for tamper alerts. If regular motion was detected by the trigger device, you would want the target light to come on. But if the tamper alert was detected by the trigger device, you might want to target light to blink on and off.

So “multi channel association“ was born. This allowed a trigger device with multiple end points to tell the target device which endpoint was sending the basic command through association.

Note that once again the hub is not automatically involved unless you also add it as a target device to the same association group.

Also note that some target devices might have multiple end points, and that might be useful information as well.

There is a good discussion of all of this with examples in the Vesternet article that I linked it to earlier.

Zwave Plus

After a couple of years of many different manufacturers using direct association in many different ways, and, to be honest, Fibaro pushing the envelope and driving all the hub manufacturers crazy, A decision was made by the zwave alliance to standardize association in the new Z wave plus specification.

There’s a community FAQ on this which I will link to, but most importantly, Association group one now became the “lifeline“ group and every Z wave plus device was supposed to be able to act as a trigger in this group and send reports to the hub as the target. And association group one was not supposed to be used for anything else.

Battery Power Devices could send battery status reports, other devices could send tamper alerts, things like that.

And buttons could send a pushed report to the hub.

90% of this was intended to allow hubs to update their smart phone apps, but it was also useful for multi platform hubs like smartthings.

This works pretty well except for the fact that manufacturers still try to get tricky and use it for stuff it wasn’t intended for, and that can confuse things, but it’s definitely better than it used to be.

But it does mean that a construct that was originally designed to allow devices to talk to each other without going through the hub became the main way that status reports were sent by every device on the network to the hub. Which is why it’s really important to know which Z wave generation people are talking about when they are discussing association.

Here’s the detail FAQ (as always, the topic title is a clickable link)

why we don’t use direct Association for everything

So far, direct association sounds pretty good, right? It’s way faster than going through the hub. In some ways it’s more reliable. It works well. And overtime they even figured out how to deal with multi endpoint devices. Of course you can only use it between two zwave devices on the same network, but why wouldn’t you use it every time?

The answer turns out to be pretty simple, which is that each individual Switch is pretty dumb, and battery powered devices are trying to do as little processing as possible in order to extend their battery life.

Let’s say you set up a direct association so that a motion sensor triggers a light to come on. So far so good. However that means every single time that motion sensor is triggered, that light will come on. Even in the middle of the day. Regardless of who is home. Regardless of what else you’re doing. It’s a very very basic If statement. If motion is detected, light turns on.

Or suppose that motion sensor is on a garden shed, And your target device isn’t a light, but a siren. Every single time that sensor detects motion, the siren will go off. Every single time. :rotating_light: :confounded:

It’s very reliable. It doesn’t require the Internet. It doesn’t require the hub after initial set up. It’s really quick. But… It’s really dumb logic.

So that’s why we don’t use it for every situation where we want a trigger event on one device to actuate an event on a target device. Because often we only want it to actuate if other conditions are met, and direct association just doesn’t do that.

But it’s really good for virtual three-way switches. And status updates. :sunglasses:

Tim already knows all of this except the historical stuff, but I’m going to tag him anyway just so we’re all on the same page.