[ST EDGE] Edge Developer needed: MCOHome MH-S312 and MH-S314

[martin.borg]

I would like to ask whether there is a device handler for these specific devices. So far I have used a Groovy DTH (developed by the community, mostly the work of @hongtat with some modifications by @mwav3 (I am not a developer myself), with a lot of assistance from @JDRoberts.

The drivers would likely be almost identical (perhaps even the same driver as was the case for the Groovy DTH), as these are near identical switches, the MH-S312 being the 2-gang version, whereas the MH-314 is the 4-gang version - otherwise exactly the same. I am aware that Smartthings is perhaps not the best at multi-endpoint switches, but I would be happy to test any multi-endpoint switch Edge driver that has been created with these switches to check for potential compatibility.

If there are no such Edge drivers, what are my options? I have over 40 of these switches around the house, and with the impending death of Groovy in the pipeline, this will render my automation pretty much obsolete. So I would really like to know what are my options for getting an Edge driver for these switches.

[philh30]

What are the fingerprints for your devices? The fingerprints below are in the zwave-switch driver in the ST beta, and I’m guessing that 015F/3102/0202 and 015F/3102/0204 are yours. If so, I’d suggest starting with that driver (instructions to join the ST beta channel are in this topic). You’ll need to have a computer running the CLI so you can monitor logs while testing to see what does/doesn’t work.

  - id: 015F/3102/0201
    deviceLabel: WYFY Switch 1
    manufacturerId: 0x015F
    productType: 0x3102
    productId: 0x0201
    deviceProfileName: switch-binary
  - id: 015F/3102/0202
    deviceLabel: WYFY Switch 1
    manufacturerId: 0x015F
    productType: 0x3102
    productId: 0x0202
    deviceProfileName: dual-switch
  - id: 015F/3102/0204
    deviceLabel: WYFY Switch 1
    manufacturerId: 0x015F
    productType: 0x3102
    productId: 0x0204
    deviceProfileName: switch-multicomponent-4
  - id: 015F/3111/5102
    deviceLabel: WYFY Switch 1
    manufacturerId: 0x015F
    productType: 0x3111
    productId: 0x3111
    deviceProfileName: switch-binary
  - id: 015F/3121/5102
    deviceLabel: WYFY Switch 1
    manufacturerId: 0x015F
    productType: 0x3121
    productId: 0x5102
    deviceProfileName: dual-switch
  - id: 015F/3141/5102
    deviceLabel: WYFY Switch 1
    manufacturerId: 0x015F
    productType: 0x3141
    productId: 0x5102
    deviceProfileName: switch-multicomponent-4

[martin.borg]

Thank you so much for your answer - I am so grateful someone answered, thought these switches would not gain any attention because admittedly, they’re old and not super popular with Smartthings users, I have come to realise. That said, my initial smart home installer had me make a substantial investment in these switches and I’d hate to throw it away.

So - my fingerprints are as follows:

1. Most of my MH-S314 switches have fingerprint: 015F/3141/1302

2. All of my MH-S312 switches have fingerprint: 015F/3121/1302

3. Just one of my MH-S314 switches has fingerprint: 015F/3141/5102

If I understand well, these fingerprints are not included in the above piece of code except for one switch (for some reason the supplier had provided that switch at a later stage, probably a replacement of a faulty one).

In any case, I will try to modify and add them myself and see what works over the rest of this week.

Once again - very grateful to you for pointing me in this direction.

[martin.borg]

Hi @philh30

So I tested the above switches. The single switch with fingerprint 015F/3141/5102 was identified by the hub as a WYFY Switch. To my understanding, WYFY is/was a Singaporean company which re-branded MCOHome switches as WYFY - MCOHome itself being (to my knowledge) a Chinese brand. In fact, as per the ZWave Aliiance list, the 015F code is of MCOHome, NOT of WYFY, which does not appear to have a Manufacturer ID.

That said, the switch was included, and it took the Zwave Switch driver found in the beta, with the profile switch-multicomponent-4. To my surprise, it works a bit better than the old stock DTH did: It actually recognised the device as ONE single device, and therefore only one tile in the app. If you click the tile, you get a list of 4 switches in the one switch. This is the first real attempt by Smartthings to adrress a multi-endpoint switch and treat it like a proper single device - or at least, if there was a previous attempt I never came across it. When I tried with the old stock DTH for this device, it installed four separate devices for me. The following are the screenshots from the app, the device in question being the WYFY Switch one (see first screenshot). the other 2 screenshots are wht appears after you click that tile.

So yes, that looked good. But then I noticed the names of the buttons: Main, Switch1, Switch2, and Switch 3. I tested quickly noticed that both Main and Switch1 refer to button 1, Switch2 refers to button 2, Switch3 refers to button 3. There is no way of controlling button 4. Main and Switch1 do the same thing together, if you switch one on, the other goes on, etc. I have reported these as flaws in a separate post on this community (The End of Groovy Has Arrived - #202 by martin.borg), but perhaps I should open a ticket with Smartthings.

That said, I also tried adding the fingerprints of the other S314 MCOHome switches to the code. They actually install, though with the same problems as the switch above, but also with an added problem: the hub (and therefore the app) never knows if any button on the switch is physically turned on or off from the switch itself. I know that this is related to the version of the switches, I had a long thread on here several months back and I understand it’s something to do with the Basic Command Set, but it gets too technical for me to understand with my limited knowledge of Zwave - and development. So, even if Smartthings fix the above problem for me (which one would expect them to do given that the fingerprint is in there), I would still be stuck with this other problem that will affect 40 switches in my home, and will have a huge effect on the automation associated with these switches.

What do you think should be my next steps?

1. Wait for Smartthings to fix their driver for the 015F/3141/5102, then pick this up again?

2. Do some monitoring with a computer “running the CLI”, as you suggested, even before the Smartthings fix? I do have the CLI running on my laptop but not sure how to do the monitoring you suggested.

Finally, I wanted to ask - should I keep this conversation in here? I just saw a post by @JDRoberts: Post Requests for Edge Drivers Here (community-created), and thought perhaps my request for a driver should have gone in there.

Many thanks in advance.

[philh30]

@martin.borg

The single switch with fingerprint 015F/3141/5102 was identified by the hub as a WYFY Switch.

@martin.borg

There is no way of controlling button 4.

Since this fingerprint is supported in the official driver, this error should be reported to SmartThings so they can look into it and make sure the stock driver will work correctly. @nayelyz

[philh30]

@martin.borg

What do you think should be my next steps?

The older switches are a separate issue since they aren’t officially supported.

I had seen your thread on them and would be willing to see if we can get them sorted. Older devices have their limits, but we should be able to at least get the same functionality out of them as you’re getting on a different hub. If you can work on getting the CLI and live logging running (I have instructions here), I’ll throw together a custom driver in the next few days that will let us test some different options.

@martin.borg

should I keep this conversation in here?

Yes

Edit: It didn’t click in my head that you already had the CLI up and running. If you can capture some logs when physically pressing the buttons then that would be a good start.

[martin.borg]

Thank you - I’ll re-join a 4-gang (as well as a 2-gang) switch to the hub using Edge drivers (with the fingerprints added). Please note, however, that I have made no changes to the code other than adding the fingerprints, and therefore the code will suffer from the same flaw as the one reported to Smartthings above, that is Main and Switch 1 are the same, and no way to control button 4 of the device - this problem was visible also on the old switch.

I will get back to you soon as I have these devices re-joined with Edge drivers and after doing some monitoring/logging, and results.

Many thanks once again!

[JDRoberts]

These devices work by using multichannel association.

340724_mh_s314_eu.pdf

My guess (just a guess) is that for whatever reason the hub has not added itself to the association group for button 4, which is why those commands are not being processed.

Regrettably ST has never done a good job of exposing zwave associations through its UI, and support typically does not understand questions about devices that use it unless you luck out and it gets escalated to a zwave engineer.

I think this will need its own edge driver which exposes the association groups, and you will probably need to manually add the hub to the last button group.

But this is just a guess as a place to start looking.

[JDRoberts]

Also: main and switch one are the same because the device itself doesn’t offer any functions for the main ID except some reporting functions which should have been put into association group 5 in this case.

So it becomes a UI choice: should Main do nothing? Do the same as actuating all 4 buttons? Or, as in this case, do the same as button 1? There’s no right or wrong decision on this: it’s just up to the UI designer since the functionality is not built into the device itself.

[JDRoberts]

Also I agree that this detailed discussion should have its own thread, so let’s continue here.

The request thread is only intended to have one post per device, “I need an edge driver for device Acme 1”. And then a response if an edge driver already exists, if not, creating a new thread like this one is good, it keeps the request thread from getting too cluttered.

[philh30]

@martin.borg

the same flaw as the one reported to Smartthing

No worries. We’ll get the UI fixed too, but for now I just want to see if any zwave commands show in logs when you physically manipulate the buttons. There’s a chance we won’t see anything, which means we immediately start playing with Association groups.

Thanks @JDRoberts ! User manual from 2013, and a useful one that has real z-wave info, is a solid start!

[philh30]

I put together a driver for you to try. I’m hoping this will get switch 4 working on your newer one, and it’ll also display command classes and association groups at the bottom of the detail tab that will help figure out the older ones.

• Enroll in this channel
• Install the MCOHome Z-Wave Switch Test 1 driver
• Post screenshots of the command class and association group capabilities for each of your three models (they may take a minute to fully populate)

[martin.borg]

Wow, thank you!

I just installed the driver, changed the driver of the single newer version switch to your driver, and voilà, Switch 4 now works just fine. There is the problem that Main seems to affect Switch one, i.e. whatever action you do to Main actually happens instantly also to Switch1 - but the reverse is not true, i.e. any actions performed directly to Switch 1 have no effect on Main. That is a shame and probably a UI inconsistency/flaw in Smartthings’s code. But at least, all 4 buttons now work.

Initially, I also created a routine to replicate what happens to Switch 1 on all other Switches (2, 3 & 4), and initially it was so, so slow that I thought I was better off with the DTH. I disabled the two routines, re-enabled them, and now they are as quick as they can get - good enough for 2-way lighting, I suppose, and most certainly faster than the cloud Groovy DTH ever was.

So - anyhow, massive improvement, and I’m very thankful. Meanwhile, I have the screenshots of the command class and association group capabilities for this one switch, pasted here:

Hope this helps somehow, wish I fully understood the Zwave protocol so I could help out.

We have identified a couple of switches (an old S312 and an old S-314) that we will bind to your driver in order to be able to send you the same for those devices. please bear with me a little until we get this sorted out.

Many thanks!

[martin.borg]

Hi @philh30

I have added an S312 and an S314 switch to the hub, and assigned them your driver. (The S314 initially adopted my own modified driver - the one to which I had just added its fingerprint, then I manually assigned your driver).

This post is about the S312 switch, and here are the respective screenshots:

As you can see the buttons are displayed as disconnected, and the only interaction is to flick the “main” switch at the top, which turns on or off switch one. Physical interaction with the switch is not reflected on the app at all. Let me know if you need me to do anything at all to further help you. Many thanks.

[martin.borg]

@philh30 - and these are the screenshots for the old S314 with the old fingerprint (015F/3141/1302):

As you can see, switch 4 remained “unconnected”. Switch initially was not behaving well to my commands from the app - I realised that this could be because I was testing it whilst it was gathering data. Eventually, the switch disappeared from the app, then reappeared as “Unknown device… Identifying…” or similar message, then finally re-settled to its original name with your driver. Works decently if controlled from the app now (not perfect - but decent), but no physical interaction is reflected on the app.

Hope all this helps, and once again, many thanks!

[philh30]

@martin.borg

There is the problem that Main seems to affect Switch one

There’s a choice for you to make since we can handle this two different ways:

• I can make main work as an all on/off for the four real switches.
• I can remove main. (Technically, I would remove switch1 and change the label on main so it shows as Switch 1 in the app)

Both options are probably the same level of effort for me, so it’s just a matter of what you prefer.

I have a new version, MCOHome Z-Wave Switch Test 2 in the channel for you to try on just the two old ones. This time:

• Install the driver
• Start CLI logging on the Test 2 driver
• Swap to the new driver
• Toggle each button on the device physically
• Copy the logs and paste them here. If you put them in a code block they will be easier to read - put ``` (three of the backwards single quotes that are on the same key as ~) on a separate line above and below the logs

[JDRoberts]

The one you show in post #13 has a different zwave chip, not just different firmware: it’s zwave plus and is using the lifeline group and supports central scenes. We’d need to look for the user manual for that one. But if it’s working, great.

The one you show in post#15 appears to match the user manual I previously posted. Adding the hub as a node to each group should let it see the button presses.

FWIW.

[philh30]

MH-S314 (newer Z-wave Plus model) - 015F/3141/5102

The issue with this device was just a mismatch in the way the stock driver maps components to endpoints. The logic is that endpoint n maps to component switchn, and main maps to endpoint 1. So both main and switch1 map to endpoint 1, switch2 maps to endpoint 2, etc. The profile in use, switch-multicomponent-4 lacks a switch4 component, so events from endpoint 4 weren’t being mapped to a component. The fix to that was simply adding the missing component. Overall, the naming of profiles in the stock driver seem a bit inconsistent - while the switch-multicomponent-4 profile maxes out at switch3, the switch-5 profile goes up to switch5.

One oddity that I see in the screenshots for this device is that the hub isn’t currently in the Lifeline Association Group, which should’ve happened automatically. I would’ve expected that omission to make the whole switch seem non-responsive, but maybe something else is going on. The next version of the driver will handle adding the hub to Lifeline.

The fact that this switch has the SWITCH_MULTILEVEL command class, plus the naming of association groups 3, 6, 9 and 12, have me wondering if it’s actually a dimmer (or maybe it just supports sending dim start/stop commands through association). It also has the CENTRAL_SCENE command class, so it may produce some multi-tap or held button events. I’m also wondering whether there’s actually an Association Group 13 that just wasn’t showing - the pattern of 3 association groups per button would support it existing.

MH-S314 (older model) - 015F/3141/5102

The 5 association groups shown match the document @JDRoberts found, including the number of nodes allowed (5 each in groups 1-4 and 1 in group 5). Since the document says group 5 acts like the lifeline group, the Test 2 version of the driver is trying out the hub in that group. Hopefully that starts the Reports flowing, but if not then the next step will be to add the hub to groups 1-4 to see if that generates Set commands that can be interpreted as switch state.

MH-S312 (older model) - 015F/3121/1302

This one is a bit odd. Association groups 1-3 show up as I expected - presumable groups 1 and 2 are for Set commands from the 2 switches and group 3 acts as the lifeline. Groups 4 and 5 are unexpected though - I’m betting they reused the firmware from the 4 button model and didn’t bother to remove these groups. The Test 2 version of the driver is trying the hub in group 3, and if that fails we’ll either try 5 or 1 and 2 depending on results from the 4 button model.

[martin.borg]

Thank you @philh30 and @JDRoberts for the invaluable input you both are putting into this, can’t tell you how much it is appreciated and I can finally see the light at the end of the tunnel.

I will do the testing and CLI logging soon (have done some already but had to stop - will resume later today or maybe tomorrow.

In the meantime, let me tell you about something I found out. The newer switch - the single MH-S 314 (newer Z-wave Plus model) - 015F/3141/5102, is sometimes appearing offline/disconnected, as per the following screenshots:

The only way to get it back online is to press a button on the app - but sometimes the app does not allow that at all and I have to physically press a button on the switch. To be honest, this was happening also with the old custom DTH I was using, so I do not know if it was an issue with the code or the device (since I have no others of the same exact model), but somehow, I believe it was something in the code that has been carried across to the Edge driver.

As for the results of testing with the CLI, I will post those the soonest I can, but let me tell you right away that the older switches now seem to work perfectly when there is physical interaction (hooray!), not so perfectly when used from the app (e.g. when there are intensive tests carried out, switching all 4 buttons to on, then to off, then to on, then to off - with very short intervals between button presses… Sometimes, (let’s say on the fourth cycle through the button presses) you see the buttons reverting to their previous state after a second or two. Still, a massive improvement in that physical button presses seem to work absolutely perfectly now, and quite fast too. I daresay that physical interaction has never been so good even with the Groovy DTH, where I had to insert a bit of code to refresh the status from the switch every time there was a button press (then repeat the refresh 5 seconds after the final button press through a Webcore piston, which was very, very clunky). Massive thanks.

[martin.borg]

@philh30

The issue with this device was just a mismatch in the way the stock driver maps components to endpoints. The logic is that endpoint n maps to component switchn, and main maps to endpoint 1. So both main and switch1 map to endpoint 1, switch2 maps to endpoint 2, etc. The profile in use, switch-multicomponent-4 lacks a switch4 component, so events from endpoint 4 weren’t being mapped to a component. The fix to that was simply adding the missing component. Overall, the naming of profiles in the stock driver seem a bit inconsistent - while the switch-multicomponent-4 profile maxes out at switch3, the switch-5 profile goes up to switch5.

Strange about that inconsistency. I should have dug a little deeper into the code - I don’t know Lua but perhaps could have seen that with some effort.

@philh30

oddity that I see in the screenshots for this device is that the hub isn’t currently in the Lifeline Association Group, which should’ve happened automatically. I would’ve expected that omission to make the whole switch seem non-responsive, but maybe something else is going on. The next version of the driver will handle adding the hub to Lifeline.

The above might indeed be a reason for the switch repeatedly going offline, but can’t be sure, will have to verify after the next driver release from your end.

@philh30

The fact that this switch has the SWITCH_MULTILEVEL command class, plus the naming of association groups 3, 6, 9 and 12, have me wondering if it’s actually a dimmer (or maybe it just supports sending dim start/stop commands through association). It also has the CENTRAL_SCENE command class, so it may produce some multi-tap or held button events. I’m also wondering whether there’s actually an Association Group 13 that just wasn’t showing - the pattern of 3 association groups per button would support it existing.

Unfortunately, I do not know enough about the Zwave protocol and associations to fully understand these. it was not my intention to learn in the first place - I had a supplier install all the home automation devices for me (on a different hub/cluster, not Smartthings), and they abandoned the project before completion as they couldn’t get everything to really work well. I inherited a failed project and had to learn the basics of Smartthings and WebCoRE, but that was never the intention. Nevertheless i enjoy it to some extent, just need to start understanding ZWave a lot better than I do, obviously. Tried to understand associations in the past but need some good reading material as from the community I seem to get bits and pieces, and I prefer a more step-by-step (spoonfed, perhaps) approach.

In any case, the switch might have dimming functions. The afore-mentioned vendor was supposed to supply us with switches capable of dimming, we underwent a huge expense to get almost all lights in the house dimmable - only to find the switches do not support dimming (or at least that is what we were told) - so now we have the old MH-S312s and MH-S314s and we cannot dim out lights at all. But perhaps this switch can actually dim - I saw multiple references to dimming functionalities in the document I am attaching here (just found on the MCOHome website), which I believe pertains to this newer switch.

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

@philh30

MH-S314 (older model) - 015F/3141/5102

The 5 association groups shown match the document @JDRoberts found, including the number of nodes allowed (5 each in groups 1-4 and 1 in group 5). Since the document says group 5 acts like the lifeline group, the Test 2 version of the driver is trying out the hub in that group. Hopefully that starts the Reports flowing, but if not then the next step will be to add the hub to groups 1-4 to see if that generates Set commands that can be interpreted as switch state.

MH-S312 (older model) - 015F/3121/1302

This one is a bit odd. Association groups 1-3 show up as I expected - presumable groups 1 and 2 are for Set commands from the 2 switches and group 3 acts as the lifeline. Groups 4 and 5 are unexpected though - I’m betting they reused the firmware from the 4 button model and didn’t bother to remove these groups. The Test 2 version of the driver is trying the hub in group 3, and if that fails we’ll either try 5 or 1 and 2 depending on results from the 4 button model.

We’ll know more after I send you the CLI logs. Sorry, I couldn’t do that today as I had other things to do, but you know the basic result of the testing. Will send the logs at the earliest possible tomorrow.