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

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

I would say 99% based on that you have the older non plus version and my manual and central scene suggestion won’t work. Delayed or no status updates was a common complaint of the non-plus jasco switches. People got around it with polling, like what we are doing here with the refresh. It was fixed with the new plus version.

Obviously ripping these all out and replacing them is not an economical solution, but I have found smart home devices don’t last as long as we would like. @JDRoberts has spoken about this in great detail. Think how often we have to replace our cell phones.

The only thing I can think of at this point is possibly associating the hub to the other button groups, but that may result in the same blanket basic set command that doesn’t provide enough info other then to trigger the refresh. For 3way applications where you need instant on off, like i push this then the other light must come on immediately, i would recommend direct association from one switch to the other. Be aware of the caveats JD mentions about status update issues this can create with bypassing the hub though, and limited ability to make any advanced automation condition. The zwave tweaker should be able to set associations, but i would post over there like jd said for more directions on how it works.

I’ll also see if I can find the older manual to match your switch to see if it has any other clues. JD also frequently points out “the model number matters”. Sometimes it goes beyond that to the version of the model even matters.

And thanks @JDRoberts for more info on the history and back story on how we got to where we are today in clues. It helps understand more behind the “why” things work this way.

2 Likes

Not sure about this, I’ll try to find one of the the boxes, won’t be easy… MCO Home did say in an e-mail “It seems that they are old version (300 series Z-wave chip), it can’t be upgraded.”

Running the zwave tweaker and verifying which parameters are supported should tell you which switch you have. Almost all 300 series chip devices are not plus, but some were.

If it supports the central scene configuration and values show for parameters 16-36 you should have the newer switch.

1 Like

When you first assign the device to the tweaker DTH, have another live log window open. Then you will see this in your logs:

2:39:04 PM: info Supported Command Classes: [APPLICATION_STATUS (0x22), SWITCH_BINARY (0x25), SCENE_ACTIVATION (0x2B), SCENE_ACTUATOR_CONF (0x2C), TRANSPORT_SERVICE (0x55), ASSOCIATION_GRP_INFO (0x59), DEVICE_RESET_LOCALLY (0x5A), CENTRAL_SCENE (0x5B), ZWAVEPLUS_INFO (0x5E), SUPERVISION (0x6C), CONFIGURATION (0x70), MANUFACTURER_SPECIFIC (0x72), POWERLEVEL (0x73), FIRMWARE_UPDATE_MD (0x7A), ASSOCIATION (0x85), VERSION (0x86), SECURITY_2 (0x9F)]

2:39:04 PM: info Device has new-style fingerprint: zw:L type:1001 mfr:0063 prod:4952 model:3135 ver:5.53 zwv:6.04 lib:03 cc:5E,25,85,59,86,72,55,5A,73,5B,9F,6C,70,2C,2B,22,7A

You’ll see the command classes supported right in the log - look for central scene. You can paste the log here.

Hi @mwav3 - tried this without success… Kept a tab open on Chrome in Live Logging on the IDE, then assigned the Z-Wave Tweaker DTH to the Dining Room switch, nothing happened on the log - and I mean zero…

When I switch it back to its original, the log is filled with numerous entries, but not when I assign to it the Z-Wave Tweaker DTH. I did this several times to be sure, and can confirm that assigning the Z-Wave Tweaker DTH produced zero entries in the log.

And now I have a further concern at the back of my mind… I am going around the house removing devices from my old (non-Smartthings) controller and adding them to the Smartthings one, but it all seems a little bit shaky. Many of my devices are a bit old - installation was towards mid-2017, and I have had to find and use Groovy DTHs on here for quite a few devices… So when Smartthings eventually does pull the plug on the Groovy cloud, will I lose all these devices? That’s quite an expense for me, and not one I’d be willing to go into for sure. But I digress, even though it’s connected in a way - as I am trying to solve the problem with these MCOs only to have them stop working a few months down the line.

Anyhow, back to the Z-Wave Tweaker - any ideas on this?

Also, reading back in the original post of the DTH, I see there were others who faced same issue, and they only solved it by associations.

Maybe, we just don’t know yet. Smartthings still hasn’t published details on how hub connected Device DTH ‘s are going to work on the new platform, and whether custom code will even be possible For those. :thinking:

Or whether they might instead provide stock zwave DTHs which are comparable to their competition, thus removing the need for some of the custom code. (There has been some speculation that the Aeotec partnership would tend to lead them in this direction, but again nothing official has been announced.)

We just don’t know.

One alternative for most zwave Devices would be to add a Hubitat hub as your Z wave controller and then integrate that back to smartthings through the API. It would be a little clunky, but it should be doable even if smartthings drops groovy all together.

1 Like

That’s a horrifying prospect for me… I seem to have joined the party late in the day, and I’d hate to have to go through the pain again - but worse than that - the idea of suddenly losing numerous wall-switches, open/close sensors, combustible gas sensors, motor controllers, sirens, etc… in one fell swoop, that’s just unthinkable in terms of expense and effort.

Just hope you’re right about this - my devices appear to be pretty standard in functionality, so I don’t expect highly customised code beyond stock Z-Wave DTHs… I have no guarantee that these devices would integrate well with Hubitat either, and to think I would need a second hub to integrate with Smartthings, after all the pain of setting up Smartthings and learning WebCoRE (which itself may be biting the dust), it’s just a lot…

1 Like

The zwave tweaker was written for the classic app, and the developer no longer updates it. I found a workaround to still use it now using an option in the IDE called "the simulator ". I posted about it here. [OBSOLETE] Z-Wave Tweaker - #207 by mwav3 with screenshots. The simulator will be under the device handler for the zwave tweaker. It will ask to select location, then a device. Pick one of your 4 button switches. Then click the commands- log info will be right on that same page. The simulator is a tool for developers to test codes and commands and will work well in this case.

We can keep our fingers crossed this custom code will work some other way after the ide phaseour. If not though, you’d probably be better off just getting another hub that works for theses switches instead of replacing everything else. Hubitat, Openhab, and zwavejs in home assistant should all support these switches. I run home assistant with Smartthings so if everything goes south here I’ll just move everything over to that. We can be optimistic for a bright future with Smartthings, but a “plan b” is good to have.

2 Likes

@martin.borg I updated the Zwave Tweaker to work with the new Smartthings app. I posted about it here - [BETA] Z-Wave Tweaker - #209 by mwav3 and you can get the updated version here on my Github - SmartThings-1/zwave-tweaker.groovy at master · mwav3/SmartThings-1 · GitHub

You should be able to use this updated tweaker now to perform scans of your switches to try and gather more information on them. The scans we are most interested in are “perform general device scan”, “association scan”, and “endpoint scan”. You can perform those then perform “Prints” (ie print endoints) on each one to put the values out to a live log.

2 Likes

Lovely… Thank you very much, will try this out as the current Z-Wave Tweaker I have is severely reduced in functionality. Many, many thanks.

I’ve been busy adding more and more devices to my Smartthings and so far it is handling them decently, though I hope one day they will allow clustering of hubs as I can tell it’s feeling the load somewhat… That said, my testing is intensive and when I test these MCOHome swithces - many at one go, in rapid succession, each button press generates 2 refreshes (one by the handler, one by WebCoRE), so yeah, it’s clunky, but works somewhat. Real life use will be a few button presses at a time at most - there can only be so many people in a house…

Anyhow, I will try this out as it would be great to get association to work… My only worry is the hub not knowing that a button has been pressed if there are associations, and I might have to live with that.

I checked out the Hubitat forums… Users seem to have had problems integrating these switches with that hub as well. I’ll stick to Smartthings for now until I have no option, but if I see things going south, I will of course consider, Hubu=itat especially because I can keep the pistons I am creating and they have a ton of logic inside them.

Many thanks, once again!

1 Like