[RELEASE] Neo Coolcam / MCO Z-Wave Light Switch

Devices & Integrations Community Created Device Types
125

Thank you very much for this post and the Device Handlers, @hongtat , appreciate it.

I am new to SmartThings. I installed my first few devices on my SmartThings hub (V3) yesterday. Indeed, I am so new that yours are the first device handlers I have installed on my hub. Adding the Device Handlers is easier than I thought.

I have plenty of MCO Home MH-S312, but even more MH-S314 switches around my house (on a different controller, not SmartThings) which I now would like to migrate to SmartThings. They’re not the ultimate switches I’d like, but they will - temporarily - have to do so I don’t spend a lot at one go.

I have not as yet tried moving even one switch to Smartthings, but I will most certainly try - your post above seems pretty recent (well, some 5 months old) so I am hoping the Device Handler will work with the new Samsung app just the same. (Please let me know if you don’t think this is the case).

I see that the code was only tested with MH-S312 (as per your text on GitHub), but not MH-S314 (which I have the most of)… Is this still the case please? And would you reasonably expect it to work nonetheless?

126

So there goes my first attempt… I managed to exclude one of my MCO Home switches from my Zipato controller, but I now cannot join it to my SmartThings network… I scanned from the app and held one of the buttons on the device for 8 seconds (and longer actually) - and nothing. I followed the manufacturer’s instructions to do this but it seems that I must be doing something wrong. It’s pretty much how I set up the other devices I have so far on SmartThings (which is not many), but no luck.

Anyone knows how to at least join this device to my SmartThings network, please?

127

Update - I managed to joing the MCO Home MH-S314 switch to my SmartThings neywork after my 11-yr old son showed me a video on how to exclude a device and re-include it :smiley:

And then I proceeded as per above instructions from @hongtat - and guess what, I now see four separate switches for my Dining room - so well done to @hongtat , the solution does indeed work!! I just hope I don’t get the lights going on/off on their own as some users seem to have suffered.

The only thing is that I see them on the home screen like 4 different devices, unlike for example my Aotec Wallmote Quad device, where the switches appear to be bundled as buttons belonging to the same device. That said, I am extremely happy to have my MCO fully operational, because I can detach them from my Zipato, finally, and have them acting as repeaters for me all over the home.

In any case - thanks a million :slight_smile:

POST EDITED LATER…

As always, after the initial euphoria, reality smacks you in the face…

The MCO Home MH-S314 worked pretty well with the device handlers up here, but then I realised something that basically means I would not be able to use these switches. That’s the lag…

So basically, switching them on from the app is fine - there’s a lag of maybe half a second, it’s acceptable in my view… Switching from Alexa is almost the same, perhaps just a little longer… But switching the device (any of the four keys) on or off physically doesn’t register on the app for a whopping 20 to 30 seconds. That, then, is not really acceptable, of course. Any automations attached to the devices, e.g. if you have them set up as a two-way switch at the ends of a corridor - that won’t work well, because you’ll have to wait a minimum of 20 seconds for the light to go on.

This has happened to me on 2-gang switches, actually, and so there are MH-S312, as well as on MH-S314… All suffer from the same problem, and only when pressed physically. Has anyone else been through such a problem? Do I have anything set up wrong?

128

Make a new “room” named “MCO dining room” and move the 4 devices there, as a workaround.

Grtn Ben

1 Like
129

Thanks @benerkens , appreciate that. I am already at the room limit (it’s not a small house and I needed the room granularity)… Actually I am over the limit as I set them up on the old app and they were all migrated to the new one, but cannot set up any new rooms. It doesn’t matter much, really - I see four different devices, I’ll get used to it.

Using the switches from the app works great - the device handler is indeed great at showing the 2-gang devices as a parent and a child, and the 4-gang devices as a parent and 3 children, and that’s great.

My biggest problem is the response when I use the physical switch. I realised that it is taking an average of 30 seconds to show up the response on the app, and it’s something that has to do with the dth (I suppose) because if I use the device with the default device handler allocated to it by SmartThings, it works fine - you press a button and half a second later it goes on, or off, on the app. Once you change the dth from the IDE and allow it to create the children - than from that point on you have this 30-second (could be 1 second, could also be 60 seconds) delay for the app to register the new status of the switch. Seems like there’s some 1 minute checking intervals somewhere I can’t get rid of.

I guess only @hongtat can answer that one if he is still on the community, I’ll wait for now before adding more devices.

130

Here I have the Neo CoolCam 2-button wall switches (Z-Wave) with the @hongtat DTH (1 parent and 1 Child)

Response is within 2 seconds by the app. The control is via the cloud. Sometimes, bad internet, the response is slow.

How is the routing between the switch and the hub? Many hops?

Route This Device (42) ↔ Home Hub

And the error?

Metrics
Received Messages From Device: 2735
Received Messages From Device (Duplicates): 22
Messages Transmitted to Device: 2699
Messages Transmitted to Device (Failures): 0
Updated Time: 2021-02-21 6:38 PM CET

131

Thanks again @benerkens. I trust you understand that mine are MCO Home, not Neo CoolCam. I use 2-gang (MH-S312) and 4-gang (MH-S314) types, and have loads of these all over the house.

If it were 2 seconds - I wouldn’t be very unhappy… Yes, you expect a light to go one sooner, but things get better over time (I suppose). But 30 seconds is not Internet latency or slowness or “busy periods”, it’s something wrong, and as I said, any other device, the moment I touch it (let’s say up to a second later) - it shows up on the SmartThings app. I tried this with Dimmers, Aeotec Wallmote, TV, everything shows up on the app instantly when physically activated, except these MCO Home with this dth - but using them without the dth is not an option, as at least the dth allows me to see ALL the child switches and makes them available to Alexa.

Anyhow, I digress…

Route is very simple: Route This Device (0A) ↔ Main Hub

I don’t understand what you mean by error, but here are the Metrics:

Metrics

  • Received Messages From Device: 586
  • Received Messages From Device (Duplicates): 25
  • Messages Transmitted to Device: 540
  • Messages Transmitted to Device (Failures): 0
  • Updated Time: 2021-02-22 8:24 PM CET

That seems like a lot of messages considering I only created it maybe 20 hours or so ago… But that’s what it says :slight_smile:

132

Could you try going to your parent device (the 1st switch gang) settings, make a change, and see whether it improves the response time?

It should be ~1 sec to reflect in the app when you use the physical switch.

133

Thanks for replying @hongtat … Let me start by saying, thanks for the DTH… Whether it works 100% or not - I am using it for all the switches that do not require automation upon a physical press of a button… For the others, I am leaving them on the old (non-Smartthings) controller for now, but at least like this, I get plenty of “extenders” for my Smartthings Z-wave mesh.

I tried what you said - went to the device (from the portal, not from the app) and changed just the name, and pressed Update… No change for me, unfortunately, still an average of 30 seconds to see a change on the app… I experimented a little further, by pressing multiple keys at once - and it seems like on the app they all refresh very late, but nearly simultaneously - just a fraction of a second difference. It looks like something is polling the switches every minute (hence the average is 30 seconds) to get the status, and only then it refreshes on the app.

Now if that were 1 second - I’d certainly be more than happy! :slight_smile: In any case - thanks for any help you may be able to offer.

134

Try in the app, not portal. Tap on the “3-dots” on the top right > “Settings”.

135

Ok @hongtat - thanks again… I did it in portal earlier because I thought that “Update” button possibly did a more substantial change. Now I did it in the app as you suggested, went to Edit, changed the name to “Dining Light 1 - test” (added " - test"), and still app took 51 seconds to reflect switch being physically turned on. THat means any Automations would also take that long (I tried).

Whilst in the process of doing this, I noticed the devices with this DTH have Settings in the menu - something they do not have before I installed the DTH… Ad in that menu I have two settings:

  • Run Check-in procedure
  • Show last Check-in info

inside the first option, Run Check-in procedure (Allows Check-in procedure to run every so often), are options ranging from 1 minute to 1 hour… But all devices are set to 1 minute by default. And I am starting to suspect that is how frequently SmartThings checks in with these devices and refreshes their status - makes sense considering that all my tests took under a minute to refresh and an average of 30 seconds.

Is there any way you know of to avoid having to wait for that check-in?

EDIT

I delved into the code a little, not that I am a developer, and saw that it is in fact the DTH that is making these parameters available in the app… So that much is certain. Whether my suspicion that it is only this check-in that refreshes the MCO switch’s status on the app… that much I do not know.

EDIT

I should add I have tested the time it takes by clicking the switch various times over a period of time and watching the app, and it appears the refresh rate between updates is indeed 1 minute - or very, very close.

136

Hi, so just an update… As I get used to Smarthings, I realise there’s more stuff I can do, so I finally started to suspect that these MCO Home switches are actually sending messages to Smarthings, but Smarthings (or the DTH) is unable to decipher the messages sent from these switches.

And so I went to live logging, and filtered to get only the logs of the switch of my Dining Room, which is a 4-gang MCO Home switch. I found that every time I pressed any of the buttons, a message is always received by Smartthings, so I turned on and then off each of the 4 buttons on the switch… And this is the result:

450cbed5-2403-4938-9857-b4ef4849bde4 9:15:50 AM: debug Parsed zw device: 13, command: 2001, payload: 00 to BasicSet(value: 0) to [:]
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:50 AM: debug Command () called - Dining Light 1 BasicSet(value: 0)
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:50 AM: debug Event: zw device: 13, command: 2001, payload: 00
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:48 AM: debug Parsed zw device: 13, command: 2001, payload: FF to BasicSet(value: 255) to [:]
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:48 AM: debug Command () called - Dining Light 1 BasicSet(value: 255)
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:48 AM: debug Event: zw device: 13, command: 2001, payload: FF
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:45 AM: debug Parsed zw device: 13, command: 2001, payload: 00 to BasicSet(value: 0) to [:]
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:45 AM: debug Command () called - Dining Light 1 BasicSet(value: 0)
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:45 AM: debug Event: zw device: 13, command: 2001, payload: 00
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:44 AM: debug Parsed zw device: 13, command: 2001, payload: FF to BasicSet(value: 255) to [:]
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:44 AM: debug Command () called - Dining Light 1 BasicSet(value: 255)
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:44 AM: debug Event: zw device: 13, command: 2001, payload: FF
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:43 AM: debug Parsed zw device: 13, command: 2001, payload: 00 to BasicSet(value: 0) to [:]
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:43 AM: debug Command () called - Dining Light 1 BasicSet(value: 0)
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:43 AM: debug Event: zw device: 13, command: 2001, payload: 00
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:38 AM: debug Parsed zw device: 13, command: 2001, payload: FF to BasicSet(value: 255) to [:]
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:38 AM: debug Command () called - Dining Light 1 BasicSet(value: 255)
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:38 AM: debug Event: zw device: 13, command: 2001, payload: FF
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:37 AM: debug Parsed zw device: 13, command: 2001, payload: 00 to BasicSet(value: 0) to [:]
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:37 AM: debug Command () called - Dining Light 1 BasicSet(value: 0)
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:37 AM: debug Event: zw device: 13, command: 2001, payload: 00
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:29 AM: debug Parsed zw device: 13, command: 2001, payload: FF to BasicSet(value: 255) to [:]
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:29 AM: debug Command () called - Dining Light 1 BasicSet(value: 255)
450cbed5-2403-4938-9857-b4ef4849bde4 9:15:29 AM: debug Event: zw device: 13, command: 2001, payload: FF

Now I won’t pretend to understand what on earth is happening there, though I can tell that every press logs 3 lines, and I can see basic differences between “on” and “off”, but strangely - I see no difference to advise the hub which button was actually pressed (and I suspect this is one of the problems, or perhaps THE problem).

If anyone can help decipher what is wrong and why Smarthings is not managing to understand what has happened, physically, on the switch - I’d greatly appreciate that, as I have many of these switches, and changing them would be a major expense for me…

Many thanks!

137

I am afraid I also am not a developer really, but know my way around a for loop, if you know what I mean. Anyway, the author of the MCO handler made a change a few months back which involved adding:
vid: “generic-switch”
To the DH metadata. From what I gather this is needed by the new app and without it, everything behaves very oddly and refuses to update. The strange thing is I had some MCO S314s that worked and some that didn’t with the same DH. I suspect it may have had something to do with whether I added them with the old app or the new one but I found that when I added this VID to my DHs it resolved most of my issues.

I do still wonder if I have other DHs in this state, that are only working because I added them with the old app or maybe haven’t noticed the problems. I get the feeling having these dodgy devices hanging around causes delays as I have other switches that seem to have a delay and I wonder if it is because the system is wasting time waiting for dodgy devices to timeout or something? I really need to go through all devices and check them one-by-one to know (as STs sucks at telling you!), and who has the time…

The original issue caused by firmware 30.3 was resolved by ST as I recall. Basically the devices were sending messages with an invalid endpoint number. It had always worked fine, but by the letter of the law (well z-wave standards) the manufacturers shouldn’t have been doing it so ST started filtering out messages to invalid endpoints. Anyway, I assume ST changed it to not filter out messages from “invalid” endpoint numbers again and it has been fine since.

Finally, and it takes a while to get your head around all this, but the log doesn’t log all (or indeed any) physical communication as such, so it is very hard to draw any firm conclusions from it. Messages are encapsulated as multi-channel, so in the code you can know which channel a message came from without the DH developer actually logging it. So don’t worry too much about the fact the logs don’t appear to show the switch number, they are many levels of de-encapsulation higher in the process.

2 Likes
138

Thank you @HeMan , appreciate you taking time to answer this one… I’m a little stumped and it seems I have to learn to deal with this delay - and yet I know there must be a way. When I use the switch with the default DTH (Smartthings one) the app shows physical button presses happening immediately, but only for the first button - the others are essentially incontrollable from the app. So the device is definitely sending something that the Smartthings DTH is able to capture and interpret correctly. But without hongtat’s DTH - it becomes utterly useless for me, as most of my switches are 4-gang.

In any case, as I said, thank you for taking the time, appreciate it a lot. Hopefully someone will resolve this and save me (and others) from having to change so many switches.

139

Yes, as I said on the webCoRE forum it is the BasicSet command. If you look at something like Z-Wave Switch Generic it doubles up on the BasicReport with BasicSet.

You could simply try adding

def zwaveEvent(physicalgraph.zwave.commands.basicv1.BasicSet cmd) {
    log.debug "BasicSet() called - ${cmd.inspect()}"
    createEvent(name:"switch", value: cmd.value ? "on" : "off")
}

just to see what happens, but I rather suspect all you’ll get is the same switch being turned on and off. However if that is what happens then perhaps you could call your refresh command instead of createEvent, so effectively using it as a trigger to instantly refresh?

It really needs the input of someone who knows what they are talking about. As I mentioned, it could be a Z-Wave v Z-Wave Plus thing.

1 Like
140

Hmmm…

@martin.borg

Any chance that with all the stuff you’ve done on these switches you accidentally cleared the association group one setting? The “basic set” would normally be communicated through association.

Can you query the switch and let us know what the association groups and the parameter settings are? unless you think this better belongs in your other thread.

Association did change a lot between zwave and zwave plus, but the settings will tell us if that’s a factor.

BTW, A difference in association group settings is sometimes the explanation for why two switches of the same model using the same DTH behave differently.

1 Like
141

Thanks @orangebucket , I will certainly try that out, though I have no clue about Groovy code at all :slight_smile:

@JDRoberts - I am not into association group settings as yet… But I now have 11 of these already on the network, and all of them behave in exactly the same way, i.e. app does not immediately show the status when used physically. So not sure I could have done exactly the same thing on 11 switches, but I will give it a try :slight_smile:

So - should I use the Z-Wave Tweaker DTH to query the switch? As you can see, I am still a beginner…

142

Oh just shove that code at the bottom of the file, save, and publish ‘for me’ and you should be rolling. Then if it doesn’t work just remove it and save and publish again. I know I said just replace the createEvent() with refresh() but on reflection you might need something a bit more than that to actually run the Z-Wave commands (depends on how the handler is written).