Meross Smart WiFi Indoor/Outdoor Plug MSS620 - Inconsistent Results

triggers
#1

I recently purchased the captioned product (Model mss620, firmware 4.1.22, hardware 4.0.0). It is installed in their proprietary app and I am able to control both power outlets through that app. It is likewise installed in Apple Homekit and I can control both outlets through Homekit. Finally, it is installed as a device in Smartthings. There, results are spotty.

I have the following piston that runs at dusk. Note the Meross plug is part of “ExteriorLights”:

execute

every day, at 20 minutes before sunset
do
with
{@ExteriorLights} and {@InteriorLights}
do
Turn on;
end with;
end every;
end execute;

That works as intended. At dusk, the plug turns on and the connected lights illuminate. I have the opposite piston run at dawn, same code except the “Do” statement is “Turn off”. That works for every device in “ExteriorLights” except the Meross plus, which remains on. Here is the log from today, at dawn. The SmartThings device name for the Meross plug is “Courtyard Outlet 1”:

5/15/2020, 5:52:59 AM +62ms
+1ms ╔Received event [MYHUB].time = 1589536380000 with a delay of -938ms
+100ms ║Runtime (37384 bytes) successfully initialized in 49ms (v0.3.109.20181207) (99ms)
+101ms ║╔Execution stage started
+167ms ║║Executed [Dining Room Chandelier].off (4ms)
+171ms ║║Executed [Family Room Main Lights].off (3ms)
+175ms ║║Executed [Kitchen Main Lights].off (3ms)
+179ms ║║Executed [Office Main Lights].off (3ms)
+185ms ║║Executed [Wemo A - A Lamp].off (4ms)
+191ms ║║Executed [Wemo B - Floor Lamp].off (4ms)
+195ms ║║Executed [Wemo C - Guest BR Lamp].off (3ms)
+200ms ║║Executed [Wemo D - FR Lamp].off (4ms)
+204ms ║║Executed [Wemo F - F Lamp].off (3ms)
+216ms ║║Executed [Courtyard Outlet 1].off (7ms)
+517ms ║║Executed [Front Porch Sconces].off (301ms)
+520ms ║╚Execution stage complete. (420ms)
+521ms ║Setting up scheduled job for Sat, May 16 2020 @ 5:53:00 AM EDT (in 86400.417s)
+530ms ╚Event processed successfully (529ms)

So to summarize, my piston is able to toggle the device to its on-state, but it cannot toggle it to its off-state.

Anyone have experience with this device or can help explain the behavior?

#3

I’ll reply to my own post in case it helps others. As is often the case, the solution was just delete the device from SmartThings and re-add it. Specifically, I followed these steps:

  1. Deleted the device from IDE (https://graph.api.smartthings.com)
  2. In the New SmartThings app, selected the hamburger menu in the upper-left, then the settings gear in the upper right. Under “Connected Services”, deleted Meross.
  3. Added a manual device by manufacturer, selecting Meross again. Completed the authentication and re-added the device.

I had to do step 3 twice before the device showed. Don’t know why. Once done, I could (can) control on/off with the SmartThings app again. The piston I mentioned above doesn’t fire until dusk, but I assume it will work.

There are some anomalies. In IDE, the device type is “placeholder” and the status is “inactive” despite the fact that I can control the devices through the app. I suspect that Meross didn’t do a great job of implementing the device handler for their products. If I was a more enterprising person, I might have a go at writing a device handler that works better. But I’m not. Good luck.

#4

Thanks jkp. I typed out my other reply before I saw yours. I don’t think that the device was unreachable in the general sense. I was awake today when the “dawn” piston fired and all of the prescribed lights (except the Meross-connected lights) turned off. I pulled up the Meross app and toggled the lights off from there. Worked fine. I think its just a poor implementation of the SmartThings device handler.

#5

You can skip this part and just go to #2 and remove the meross integration in connected services. That will remove any devices. Plus graph.api is not to be used by everyone as it will not forward them to their appropriate SHARD. https://account.smartthings.com is the URL to post for folks to use. Otherwise some users might get confused when they can not find anything :slight_smile:

Glad you got it resolved.

#6

To help others who may find this thread…

Normally, a device can have only one master. So if we tell a device to report all of it’s data to a particular hub, then we can expect other hubs to be (mostly) clueless.

For clarification:

A good device should be able to accept commands from multiple sources, but usually only reports status changes to a single hub.