Meross strip not reconnecting about meross HOT 32 CLOSED

Hi there,
I had the same problem with my Meross MSS425F (Smart power strip, https://www.amazon.de/gp/product/B07PMWYNSW/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1).

After a little bit of testing I figured out that you have to specify at least two MQTT brokers so that the power strip reconnects automatically even after a long time.
I just specified my MQTT broker twice for this and it works fine:
./meross setup --gateway 10.10.10.1 --wifi-ssid <ssid> --wifi-pass <password> --mqtt mqtts://192.168.178.186 --mqtt mqtts://192.168.178.186

I hope I was able to help you.

Regards,
Dominic

from meross.

Sorry about that, I thought it was unnecessary, which is why I left it out of my first message. I have specified the port on one MQTT server and not on the other (which is however generated by the script itself).
So my actual correct command was:
./meross setup --gateway 10.10.10.1 --wifi-ssid <ssid> --wifi-pass <password> --mqtt mqtts://192.168.178.186 --mqtt mqtts://192.168.178.186:8883

I'm not sure right now if this has already been addressed here after the fact. If so, please excuse the duplication.

from meross.

@wsw70 @andrew-schofield @Skyleiger

I have updated the develop branch to no longer strip out extra MQTT arguments even if they are identical. I've also updated the code to include the second duplicate broker if only one is passed. can you see if this helps solve the issue of never reconnecting after broker down/reboot?

from meross.

I'm not sure right now if this has already been addressed here after the fact. If so, please excuse the duplication.

Since this thread looks like a TV series about some supernatural events happening in the neighborhood I think that any extra element is useful :)

On the serious side - do you remember whether the output from the command listed two MQTT servers?

Yes, the output listed two MQTT servers.

from meross.

Not a behaviour I have observed but I only have single plugs and my MQTT broker runs 24/7. What happens if you power cycle the device once the MQTT broker is back online?

from meross.

When I unplug and plug back the power strip it connects without problems. The problem seems really to be in the reconnection routine (after a lost connection with the broker). I see some strange messages on the broker (Client <unknown> closed its connection.) which seem to come from the power strip (I need to check that by running a tcpdump on the broker and check the IP).

Single plugs do not have this issue.

My broker also runs 24/7 (I use it for an awful lot of things, not only home automation) but it sometimes goes on and off (when a new version is available for instance, or the docker host is updated and restarts). I am actually considering getting a pi zero just to run it so that it really never ever goes offline :)

from meross.

from meross.

No, it is updated to the latest version. Still, the firmware on the strips and the plugs are different.

If you do not mind, I would like to leave that open for a few more days in case someone chimes in, ok?

from meross.

Should someone be interested attached below is a pcap file of the traffic between a meross strip (192.168.10.176) and the local MQTT server (192.168.10.2).

It is started right before the MQTT server is brought down, and then stopped 10 minutes after the MQTT server is back again.

For some reason, the device would do SYN connections, receive a RST back (because there is server), but when the server is up again it does not attempt to do a SYN anymore.

meross.zip

from meross.

Do you have the mosquitto log for the same time frame?

from meross.

I do not have it handy but beside normal connections (reconnection, actually - as the mosquitto logs obviously starts when the broker is back on line) from various clients, I got a bunch of

Client <unknown> closed its connection.

There were about a dozen of them, for 4 power strips. What is surprising is that there is no traffic from the strip taht would trigger that message so it may be something else.

I am considering starting a new temporary MQTT server and test one client only (the strip) to make sure all the logs I have come from it. I will try to do that tonight.

EDIT: I started a new MQTT broker and re-did the test. Attached is a pcap file started when the strip was unplugged, I then plugged it in, it started and connected, then I shut down the MQTT broker, waited for the strip to disconnect (blinking) and restarted the broker. Then waited 10 minutes and stopped the tcpdump.

The result is disheartening, the strip stops to try to reconnect after having received a few RST.

meross-test.zip

from meross.

That's really interesting! I knew the device has a list of MQTT brokers but never expected it to get hung up if the fallback one wasn't specified.

@wsw70 can you confirm this fix works for you?

from meross.

@Skyleiger : wow, this is fantastic news, THANKS A LOT. I will see whether having both times the same MQTT broker is enough, or whether there is a need for a true fallback.

@bytespider: I will test this tonight when everyone is asleep as I have to break the lightening in the house :)

from meross.

@Skyleiger @bytespider oh yes, it works !

I had to unexpectedly disconnect my server a moment ago so I used the opportunity to do the test.

node meross setup --gateway 10.10.10.1 --wifi-ssid MYSSID --wifi-pass MYPASSWORD --mqtt 192.168.10.2:8883 --mqtt 192.168.10.2:8883

The above did not work (no reconnection).

I then realized you used a full URI

node meross setup --gateway 10.10.10.1 --wifi-ssid MYSSID --wifi-pass MYPASSWORD --mqtt mqtts://192.168.10.2:8883 --mqtt mqtts://192.168.10.2:8883

This worked fine: switching off the MQTT broker, then switching it back brought back the strip online. I did not test with a full URI and just one --mqtt instance but I assume it will fail (I had to bring back the lights as I felt some tension at home...)

This is truly a relief, thank you very, very much for the information.

from meross.

Yeah, you need to specify the full URI with the mqtts:// in front of it, but this was already described in the documentation of @bytespider .

I'm glad that I could help you.

from meross.

I'm in the process of testing this with an MSS420F.
I had to tweak the instructions though. Since I'm using the same server as the "primary" and "secondary", I had to specify 1 without the mqtts:// prefix and 1 with.
If I didn't do that, the map function in the code strips one of them out.

from meross.

@andrew-schofield

I ran

node meross setup --gateway 10.10.10.1 --wifi-ssid MYSSID --wifi-pass MYPASSWORD --mqtt mqtts://192.168.10.2:8883 --mqtt mqtts://192.168.10.2:8883

→ so twice the same -mqtt mqtts://192.168.10.2:8883 option

The output was

Setting up device with IP 10.10.10.1
Setting MQTT servers [ { host: '192.168.10.2', port: '8883' } ]
sending payload { header:
   { method: 'SET',
     namespace: 'Appliance.Config.Key',
     messageId: '667097667afc9d7dd89ad169589f02d0',
     timestamp: 1612265693,
     sign: '718a23ab8fe6bcb8ce2f7764e6a56f6a' },
  payload:
   { key:
      { gateway: { host: '192.168.10.2', port: '8883' },
        key: '',
        userId: '' } } }
sending payload { header:
   { method: 'SET',
     namespace: 'Appliance.Config.Wifi',
     messageId: 'a967e3e4cf6f366e8f06ad7540158a24',
     timestamp: 1612265693,
     sign: '3e543c20a7aabeb7f849bd8d9b639d97' },
  payload:
   { wifi:
      { ssid: 'XXXX',
        password: 'XXXX' } } }
Got response: { header:
   { messageId: 'a967e3e4cf6f366e8f06ad7540158a24',
     namespace: 'Appliance.Config.Wifi',
     method: 'SETACK',
     payloadVersion: 1,
     from: '/appliance/2007161799249290820048e1e92596e8/publish',
     timestamp: 94,
     timestampMs: 161,
     sign: '3fda916c3fc780d69682168c4c9c6023' },
  payload: {} }

So the answer was showing just one MQTT server, and this is the same response I was getting everytime (with one or two --mqtt, and with URI or without).

The difference with that command above is that it miraculously set up the stripe to reconnect.

from meross.

Interesting. I mean logically it makes no sense as the payload is the same, so I'm confused as to why it makes a difference.

With my above changes, I did in fact send 2 mqtt servers to the device, and this was confirmed by querying the Appliance.System.Debug namespace.

Anyhoo, I've just taken down my mqtt server, and my smart strip started blinking, restarted mqtt and the strip reconnected within about 5 seconds.

from meross.

@Skyleiger

Yeah, you need to specify the full URI with the mqtts:// in front of it, but this was already described in the documentation of @bytespider .

Ah, I missed that in the docs, thanks.

This said, when using the first command line

node meross setup --gateway 10.10.10.1 --wifi-ssid MYSSID --wifi-pass MYPASSWORD --mqtt 192.168.10.2:8883

the strip was configured correctly: it connected to the MQTT and worked. It was just not reconnecting. A single plug configured that way was working and was reconnecting.

from meross.

@andrew-schofield

Interesting. I mean logically it makes no sense as the payload is the same, so I'm confused as to why it makes a difference.

Absolutely, if this was not for @Skyleiger I would not have ever thought about something like that.

Now, how the parameters are interpreted really depends on the firmware. It is not particularly robust because it gives up after a few RST when the MQTT server is down (I am battling with the Meross support so that this is brought top the devs) so who knows how it interprets what it gets (maybe "try the second MQTT server when the first is down, and keep trying")

BTW, I now see it reconnecting when bringing up the MQTT server also within a few seconds.

from meross.

But as far as I can tell, you've only actually configured 1 mqtt server, as the payload the config tool sent to your device only has 1 server in it (at least that's the behaviour I observe if I pass the same parameters as you did above).

Conversely, mine sends:

Setting MQTT servers [
  { host: '192.168.1.124', port: '8883' },
  { host: '192.168.1.124', port: '8883' }
]
sending payload {
  header: {
    method: 'SET',
    namespace: 'Appliance.Config.Key',
    messageId: 'c29c99b1ed4bdbfc028f881545e3ad4c',
    timestamp: 1612280459,
    sign: '86adb8547635ac3c672ab8092be4bfcd'
  },
  payload: {
    key: {
      gateway: {
        host: '192.168.1.124',
        port: '8883',
        secondHost: '192.168.1.124',
        secondPort: '8883'
      },
      key: '',
      userId: ''
    }
  }
}

If you GET the Appliance.System.Debug namespace, what do you see?

from meross.

@andrew-schofield

There is only one server defined:

"cloud": {
        "activeServer": "192.168.10.2",
        "mainServer": "192.168.10.2",
        "mainPort": 8883,
        "secondServer": "",
        "secondPort": 0,
        "userId": 0,
        "sysConnectTime": "Tue Feb  2 11:36:40 2021",
        "sysOnlineTime": "6h1m35s",
        "sysDisconnectCount": 2
      }

This is really weird (not really the fact that there is one, but that it reconnects only when sending the two identical parameters)

There are two more things I need to test:

• using only one --mqtt parameter, but with the full URI (mqtts://...) - all my tests until today were by just passing the IP
• trying your method, with one parameter and the URI and the other one with just the IP

from meross.

Given what the config tool does to the parameters you pass to it, I can't help but feel this must be coincidence.

It doesn't matter whether you specify the protocol or not if you pass the port in as part of the URL, as internally only the IP and port number are extracted anyway. The protocol is used to infer the port if you don't pass one in.
Furthermore, if multiple identical MQTT options are passed, one is dropped, and the output is identical to only passing in one, i.e. it does nothing further with that second server.

What gets sent to the device is identical if you pass a duplicate server or not, so unless there is something else in play, it cannot be the duplicate server option that is causing the difference.

from meross.

@andrew-schofield

Given what the config tool does to the parameters you pass to it, I can't help but feel this must be coincidence.

I get what you are saying.

Then, on the same strip, from the same laptop, with the same utility ((...) is the gateway and wifi setup):

• long press → pairing mode → node meross setup (...) --mqtt 192.168.10.2:8883 → connects but does not reconnect when the MQTT broker is down, then up
• long press → pairing mode → node meross setup (...) --mqtt 192.168.10.2:8883 --mqtt 192.168.10.2:8883 → connects but does not reconnect when the MQTT broker is down, then up
• long press → pairing mode → node meross setup (...) --mqtt mqtts://192.168.10.2:8883 --mqtt mqtts://192.168.10.2:8883 → connects and reconnects
• long press → pairing mode → node meross setup (...) --mqtt mqtts://192.168.10.2:8883 → I need to check sometimes it reconnects, sometimes it does not
• long press → pairing mode → node meross setup (...) --mqtt mqtts://192.168.10.2:8883 --mqtt 192.168.10.2:8883 → I need to check two MQTT servers are set up, the strip reconnects systematically

My wild guess is that with one mqtts://192.168.10.2:8883 server the reconnection is not systematic because there is no fallback, with two servers the strips try to connect to one, then the other, back to the one etc. - if they are both the same server at some point one of these switches reaches the sever once it is up.

from meross.

I wonder what happens if you try and send the payloads directly from postman/insomnia/cURL?

from meross.

As a completely unrelated aside, I tried sending the same parameters to my uncooperative smart light, and it didn't fix the inability to connect to a local MQTT server ☹️

from meross.

I'm not sure right now if this has already been addressed here after the fact. If so, please excuse the duplication.

Since this thread looks like a TV series about some supernatural events happening in the neighborhood I think that any extra element is useful :)

On the serious side - do you remember whether the output from the command listed two MQTT servers?

from meross.

Not strictly related to this bug, but useful nonetheless, some devices also seem to require that userid and key are set in the config: albertogeniola/Custom-Meross-Pairer#3 (comment)
MSS310 and MSS420F don't seem to care, but MSL420HK won't connect without a userid and key.

from meross.

@andrew-schofield that's actually facinating. So the firmware despite being practically the same across devices has subtle differences.

from meross.

I have some exciting news!

I have gotten an MSS310 working with Mosquitto as an authenticated user.

However, the devices break the MQTT 3.1 spec and send a ClientId > 23 characters. You can get around this by setting use_username_as_clientid true.

This can't be set in HA due to the way they currently apply additional config.

from meross.

The solution was found, everything works :)

See albertogeniola/Custom-Meross-Pairer#3 for the details, the short story is that the new version of @bytespider utility fixes everything.

from meross.

A small utility I wrote to manage these devices (once they are connected to the local MQTT): https://github.com/wsw70/meross-local-mqtt

from meross.