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

Yeah its probably not the most elegant way to handle that basic set command, but probably the easiest if it works. It will cause the state of the switch to be polled when that command comes in which should cause the status to be almost instantly updated.

Let me know how it works.

Hi @mwav3, @orangebucket, @JDRoberts

I am happy to report improvement. It’s not perfect, but it’s much better than before I inserted the code, so I am happy that thanks to you guys I’ve made a step in the right direction. These are the logs of one switch press on a switch close to the hub:

152696b5-76d4-4596-b363-79b90da295fc 9:34:24 AM: debug Parsed zw device: 49, command: 600D, payload: 04 04 25 03 00 to MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [0], sourceEndPoint: 4, command: 3, commandClass: 37, bitAddress: false) to null
152696b5-76d4-4596-b363-79b90da295fc 9:34:24 AM: debug MultiChannelCmdEncap mapped - [name:switch4, value:off]
152696b5-76d4-4596-b363-79b90da295fc 9:34:24 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [0], sourceEndPoint: 4, command: 3, commandClass: 37, bitAddress: false)
152696b5-76d4-4596-b363-79b90da295fc 9:34:24 AM: debug Event: zw device: 49, command: 600D, payload: 04 04 25 03 00
152696b5-76d4-4596-b363-79b90da295fc 9:34:24 AM: debug Parsed zw device: 49, command: 600D, payload: 03 03 25 03 00 to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 3, command: 3, commandClass: 37, bitAddress: false) to null
152696b5-76d4-4596-b363-79b90da295fc 9:34:24 AM: debug MultiChannelCmdEncap mapped - [name:switch3, value:off]
152696b5-76d4-4596-b363-79b90da295fc 9:34:24 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 3, command: 3, commandClass: 37, bitAddress: false)
152696b5-76d4-4596-b363-79b90da295fc 9:34:24 AM: debug Event: zw device: 49, command: 600D, payload: 03 03 25 03 00
152696b5-76d4-4596-b363-79b90da295fc 9:34:23 AM: debug Parsed zw device: 49, command: 600D, payload: 02 02 25 03 00 to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 2, command: 3, commandClass: 37, bitAddress: false) to null
152696b5-76d4-4596-b363-79b90da295fc 9:34:23 AM: debug MultiChannelCmdEncap mapped - [name:switch2, value:off]
152696b5-76d4-4596-b363-79b90da295fc 9:34:23 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 2, command: 3, commandClass: 37, bitAddress: false)
152696b5-76d4-4596-b363-79b90da295fc 9:34:23 AM: debug Event: zw device: 49, command: 600D, payload: 02 02 25 03 00
152696b5-76d4-4596-b363-79b90da295fc 9:34:23 AM: debug Parsed zw device: 49, command: 600D, payload: 01 01 25 03 FF to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 3, commandClass: 37, bitAddress: false) to null
152696b5-76d4-4596-b363-79b90da295fc 9:34:23 AM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
152696b5-76d4-4596-b363-79b90da295fc 9:34:23 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 3, commandClass: 37, bitAddress: false)
152696b5-76d4-4596-b363-79b90da295fc 9:34:23 AM: debug Event: zw device: 49, command: 600D, payload: 01 01 25 03 FF
152696b5-76d4-4596-b363-79b90da295fc 9:34:22 AM: debug Parsed zw device: 49, command: 2001, payload: FF to BasicSet(value: 255) to null
152696b5-76d4-4596-b363-79b90da295fc 9:34:22 AM: debug refresh() called
152696b5-76d4-4596-b363-79b90da295fc 9:34:22 AM: debug Event: zw device: 49, command: 2001, payload: FF

It includes the full refresh log of course. Turning the switch off is much the same, except the first entry (chronologically), which is:

152696b5-76d4-4596-b363-79b90da295fc 9:36:14 AM: debug Event: zw device: 49, command: 2001, payload: 00

There seems to be no information on which channel/surce endpoint it is that has been toggled.

The problem is that:

a) A whole refresh takes a while, especially on 4-gang switches, up to 2 seconds. It’s good enough for certain automations (e.g. circulating hot water when entering a bathroom), not so much for others (e.g. 2/3-way lighting).

b) If a user presses multiple of these at one go (e.g presses 1,2 & 3 on a 4-gang switch, tends to happen in real life), the hub seems unable to process so many refreshes, and might easily show only 1 or 2 of the pressed switches going on (in Smartthings app). Again this may be related to the overall load generated by refreshes. The only way to be sure that the app reflects the correct status of the device is to leave approx. 6 seconds in between button presses, which is not realistic.

Does anyone think there is a more efficient way of handling this than a refresh?

So I quoted this as perhaps it might be worth looking into, but as I said - I see nothing in the logs that identifies WHICH button was pressed on the device, so that may be a little hard, unless there is some way of extracting more detailed information than that shown by the log (I am sure this information is being received from the switch somehow - otherwise how would they have worked on my current non-Smartthings controller?).

In any case - many thanks in advance!

EDIT

I improved the functionality a little by commenting out the following line in the code:

//if (lastRefreshed && (now() - lastRefreshed < 5000)) return

As I realised that is where the 6 seconds was coming from. Behaves much better now, though still a little slow because of the speed of the refresh (device sends a message to hub to inform it what happened, and hub asks it to kindly send a full report of the status of all its children, which the deice duly sends… you get my point)…

1 Like

This thread on Openhab reveals some more clues how this switch works:

According to it, each button is capable of direct association to another Zwave Device. Also, the “gateway” (in our case the Smartthings hub itself) is associated in group 1, the lifeline group, by default.

So what’s happening now is the hub is associated with the device only in group 1. When a button is pressed, it’s detected by the hub as a BasicSet command with an on or off value (0 for off, 255 for on). The problem with that is that any of the two up buttons create the same on response here, and the two down buttons create the same off response. Code can be added to create a button with “up” and “down” values, but the problem is the same up press will be triggered with either up button being pressed, likewise for the down press with either down button being pressed. The hub will have no idea which down button was pressed when it triggers the “down” button, and there does not appear to be a way around that.

Polling will be a good workaround to update status, but Smartthings is a cloud based hub, using Groovy in the cloud, so it won’t be instant. In fact, Smartthings is looking at getting away from Groovy and the IDE all together. Most programmers don’t use Groovy anymore, and the only reason I understand it somewhat (I’m not a professional developer) is from Java programming classes I took in college 20 years ago. Combine those issues with this particular switch and it gets even worse, because its only supported command class is BasicSet. Take a look at the specifications for this switch - Product Command Classes versus a newer switch Product Command Classes and you will see the difference. Although this switch looks cool and futuristic, in terms of Zwave command processing its ancient. New Zwave devices use Central Scene control for button presses, which are different for each button, and even each press (held, released, double tap, etc), sent instantly, and can easily be decoded by Smartthings with some coding to interpret the central scene command. This switch doesn’t have that.

The nature of the way Smartthings runs will inevitably create processing delays. This switch and smartthings are far from an ideal pairing. Using the refresh() will help, but the delay built into the refresh() method was to cut down on excessive processing from too many refresh commands. Removing the delay will allow for more refreshes, but that’s more processing needed. If those delays are not acceptable, a cloud based hub like Smartthings probably isn’t the best choice, and one should look into a hub that processes commands and automations locally like Hubitat, OpenHab, or Homeassistant.

One other possibility is based on the Openhab thread, direct association from this switch to other Zwave devices is possible for each button. That could lead to faster processing, but programming would need to be added to allow setting associations in groups 2 - 5. I have association programming setup for groups 2 and 3 in this switch if you want to see how it looks - smartthingscode/ge-46201-on-off-switch.groovy at master · mwav3/smartthingscode · GitHub . Additional programming would be needed for groups 4 and 5.

Direct association though has its own issues with status updates, etc where the hub is left out of the process.

1 Like

This is why I suggested step one should be querying the device (probably with the zwave tweaker) to find out what the current association groups are.

Also note that it might be using ONLY group one if it’s sending the endpoint information as a parameter value. That’s how it’s done in multi channel association.

BTW, you mentioned “two up and two down.” Normally this particular device is handled as 4 individual momentary buttons, each as a toggle for a separate target, which works because that’s how the basicset works: it’s implicitly a toggle. Of course that gets screwed up when you try sending the command through the hub since you might then want to use the event for something other than a zwave basic command. So just one more complication that the smartthings architecture adds that another hub might not have. :thinking:

2 Likes

This is the concept document for multi channel association in zwave

Give me a second and I will see if I can find the byte structure

1 Like

Ok, this is old, But includes a detailed analysis by the person who wrote the Z wave Tweaker, so hopefully it will be helpful. You can compare what is written in the following thread to the tweaker itself to see if anything has changed over the years.

Anyway, the point of including these two links is that if the MCO device is using multi channel association, it likely only needs the hub in group one and then it’s expecting the hub to use the endpoint information.

Also note that the byte structure Assumes that either the trigger device or the Target device or both can have multiple endpoints. That’s explained in the first link I gave. If I recall correctly, the smartthings overlay reversed the usual order of these, so people tend to get really confused, but the link I provided in this post should clear that up. hopefully. :thinking:

1 Like

I’ve found the zwave tweaker was optimized for the classic app. Can it still do all this in the new app? I saw it seemed to only have partial functionality now.

I really don’t have a good understanding of how multichannel association works. I think it will allow association to other zwave devices, but I don’t see if there’s a way for the hub to decode which button was pressed if you try to add the hub as an association for each group.

1 Like

If it’s using multi channel association, Both the trigger and the target are encoded in the byte structure for the wrapper around the basic set command. See the link above with all the details.

Now when the association group is triggered, the device should send one instance of the relevant command(s) (e.g. a BASIC_SET) that is not encapsulated, plus another two instances of the command(s), each encapsulated within a MultiChannelCmdEncap() wrapper to the appropriate endpoint destination.

But you have a point: I have no idea how you get to the wrapper in a smartthings context. Or if you even can.

As far as what the Tweaker does or doesn’t do under the current V3 app, I don’t know for sure, you would need to ask in that thread. But I know there are still people using it with the new app.

[BETA] Z-Wave Tweaker

1 Like

Well then there’s hope to getting something beyond just these basicset commands by actually associating the hub to the other channels and then decoding the encapsulated methods. This handler uses the multichannel wrapper to do that it looks like - SmartThings/fibaro-dimmer-2.groovy at master · codersaur/SmartThings · GitHub

Still, without the device, I don’t think I’d be able to figure all that programming out.

1 Like

Good point, I didn’t think about doing it that way with the hub in each association group, but you’re right, that should give you access to the wrappers.

Can I just say here that programming for the smartthings environment is really confusing if you’re used to a typical Z wave hub? Thank goodness for people like you who have actually done it, I would’ve given up along time ago! LOL! :laughing:

1 Like

The work of many developers over the years is the only way I could figure this out, and your high level knowledge of zwave @JDRoberts.

It’s too bad so many have left for other platforms and that’s left a big void to fill. Every now and then I think about moving things off but when i spend an entire day figuring out how to mirror devices in Home Assistant, when it’s a simple automation here, I decide to stay put with Smartthings. It’s still easier for me to update code for these device handlers then figure out home assistant. How long it will all last and what the future holds is anyone’s guess. Whatever happens i’m still thankful i ditched Wink and got this Smartthings hub and for the excellent community here.

1 Like

I only have the MCO Home 2 gang switch, they do work for me. Associations (single/multi-channel) are automatically added to report the actual switch status (on/off) when the switch is pressed physically.

I have seen others reporting it works on the 4 gang switch as well.

Does the real-time status reporting work on the 2-gang switch for you?

2 Likes

Ok - thanks again guys for your responses - it’s greatly appreciated.

I might be going out of my depth here, and I see I have a lot of reading to do. Frankly - I have not experimented with associations as yet, and still have to understand them and need to find a really good write-up to understand how and when it makes sense to use them.

@hongtat - your DTH is the best one around for these switches - even for me, but the only problem I have is that they do not show their true state on the app when pressed physically - though it is clear it has worked for many others. With the new refresh() called whenever a BesicSet command is sent, that has improved somewhat, except if a user decides to press all 4 buttons (or even 2/3 sometimes), the refresh does not work perfectly, perhaps the hub is overwhelmed by the number of refreshes it needs to do all at once. So an alternative solution might prove to be better.

Ao to all of you who have referred to associations, I queried the device with Z-Wave tweaker, and there is literally nothing set… As per the following pics:

So basically - everything appears as “Tap to set”… Which I am starting to suspect is not right. Was the initial installation of the DTH expected to set up “membership” of an Association Group? If so, that part did not work, even though child devices were created flawlessly, every time. If there is something to set up, I’d like to know - if need be I will set it up manually, not a big deal. I have 11 of these switches already on the hub (plenty more to go) and all of them (well - I tried 5 with the Tweaker) look like this!

Whatever your response I will use the weekend to catch up on reading all the stuff in the links sent by @mwav3 and @JDRoberts… Many thanks to all, once again.

I’ve only used the tweaker a couple times, but I believe you need to set the scan the association group scan ranges in those preferences, then look at the live logs to see results. You can probably do that for endpoints to. Nothing is set when you first apply the handler.

I think it can set associations as well aside from having to recode your existing device handler.

If you have this newer Zwave plus model, there are a ton more configuration options. Looks like paremeters can actually be set to support central scene control

http://mcohome.com/ProductDetail/3894254.html

Product Manual:
mcohome.com/index.php?c=Front/DownDetail&a=downloadFujian&name=MH-S314&path=L2NvbWRhdGEvOTUzMDEvcHJvZHVjdGZ1amlhbi8yMDIxMDIwMzE3MjA0MzYwMWE2YWViNjIxZWUucGRm

If we can figure out how to set the parameters for central scene that should provide a lot more options for interpreting those values to corresponding buttons on the switch.

1 Like

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.

@mwav3

2 Likes

Found the original fibaro multisensor manual. Note that they used association group 3 for a lifeline group. :wink:

Fibaro Motion Sensor allows for the association of three groups.
1st Association Group is assigned to the device status - sending the BASIC SET control frame to the associated devices having detected motion.
.
2nd Association Group is assigned to the tamper alarm. Alarm frame will be sent to the associated devices once tampering is detected.
.
3rd Association Group reports the device status and allows for assigning a single device only (the main controller by default - the device reports its status to the main controller). It’s not recommen- ded to modify this association group.
.
The Fibaro Motion Sensor allows for controlling up to five regular and up to five multi-channel devices per an association group. However the 3rd association group is recommended for the Z-Wave network main controller (e.g. Fibaro Home Center 2).

1 Like

Thank you both for your replies. I won’t pretend to have understood everything, but I am trying :slight_smile:

So - as I said - there seem to be no associations on my switches. Like zero - none at all, so I really don’t know where i stand.

About this - to be honest, I don’t know. Mine look exactly like that switch, and are indeed MH-S314, except that the 2-gang is MH-S312s. (In my title I now realised I used the wrong model umbers (Left out the “S”). I’ll fix the title if I can… But I have no clue if the manual you sent corresponds exactly to the version of these switches that I have. I was told by MCO Home there was more than one version of this product, and mine is the “older” version. And it’s not a matter of what I can get for me - it’s a matter of - ideally - getting these switches to work properly with the network, as I have too many (slightly over 40) in the house to change them just because I moved to Smartthings. I would love to have different switches, but I cannot afford to change them just 3.5 years after I go the MCO’s.

Thanks @JDRoberts for the write-up about the associations, at least I have understood the history and why they are used. How to use them to actually configure one of these switches is another thing - but I know these switches - for sure - can be associated, and multi-channel too. When I was using an alternative controller, some switches were associated with others - I could tell from the speed with which 3-way or even 4-way switches were being triggered by one simple button click (also because there were no rules, so it had to be an association). Regrettably, a supplier did that installation for me, so the knowledge was not imparted to me. Also, I am not sure it will solve the current problem of the hub not knowing about button presses, but it would alleviate the problem a little because at least, for corridors/staircases that require 3/4-way switching, I get near-instant lighting. If the hub gets to know about it - even better, of course, but not sure how to get there.

Anyway, I will keep digging a little further. I added the Association Group ID to 1 on one of these switches, but that changes nothing for me :slight_smile: same behavior.

@hongtat missed this question earlier… And my answer is no, the mobile app does not show any switch (2-gang or 4-gang) going on or off if physically pressed. Only after adding the refresh() part in your code am I getting the app to show the status, and I would say, not reliably enough. The bahaviour of the 2-gang switches however is markedly better than that of the 4-gang switches… the behaviour worsens the more button presses you make on the same switch in rapid succession… And so, of course, on the 4-gang switches especially, from the thid button press onwards, there is no guarantee the refresh will work. Sure - the lights go on, but Smartthings is very often none the wiser.

Thanks everyone , as I said, I will keep digging.

Ask your questions about the tweaker in the tweaker thread. As Tim said, you need to be able to run a scan in order to fill in those fields, but I don’t know how to do that. (Voice navigation issue again.)

1 Like

Thanks, will try that…

1 Like