MQTT message to restart Meross devices

[Pierremenard]

Hello, my Meross mss310 (on a local broker) sometimes stop sending power readings, randomly (reading are zeroes). They are firewalled and time is set at the boot through MQTT (there's a full thread on this topic).
The only way to make the power readings work again is by power cycle them. They reboot and time is set again.
I was wondering if there is a known NameSpace/Method/Whatever to make them reboot with a MQTT message.

Thank you

Francesco

[krahabb]

Hello @Pierremenard ,

If you can share that thread link I would be happy to look at it since I had to guess and try and still I don't have a clear picture of it but.

This is what happens in meross_lan and is actually working fine (at least on the 2 mss310 I have):

• when the device boots it's time is 0 (mines are firewalled so..) and right after connecting to the broker it starts pushing it's actual time with this kind of message:

"header": {
  "namespace": "Appliance.System.Clock",
  "method": "PUSH",
  ...
 },
"payload": {
  "clock" :  {  "timestamp": actualwrongafterbootdeviceepoch }
 }

meross_lan replies immediately by resending the same message structure with the correct timestamp (note it uses PUSH method)

"header": {
  "namespace": "Appliance.System.Clock",
  "method": "PUSH",
  ...
 },
"payload": {
  "clock" :  {  "timestamp": correctepoch }
 }

I've discovered (in a random test) that I could also send that PUSH message with the correct timestamp at any time in order to restart the procedure/reset the time. So now meross_lan does exactly this: when it detects a wrong timestamp (timestamp assumed wrong when more than 5 secs away from HA epoch) it pushes a "PUSH" - "Appliance.System.Clock" with the correct timestamp.

I've not tested that as I'm writing but it worked good at the time I implemented it.

[Pierremenard]

Hi @krahabb , thank you for your reply. I read deeply the thread on time setting and I've already implemented it in my script (I don't use HA). It perfectly works: at the boot the plug ask for time and the script sets the correct timestamp.
However after some times (hours or days, it's random) even with the correct timestamp one (or both) of the plugs stop sending power reading (sending zeroes). The only way to make it work again is by power cycling that plug. Re-setting the time does not help. The time setting by itselft works (the plug ask again for time and the time is sent back) but readings are still zeroes.
I was wondering if I can send a command in these cases to make them reboot.

Thank you

F.V.

[Pierremenard]

Just a question: when you send the 'PUSH' - 'Appliance.System.Clock' to fix the timestamp is it the same message you sent in reply of the request after reboot? I mean the "PUSH", "Appliance.System.Clock", {"clock":{"timestamp":int(time.time())}} just to be clear.

Thanks again

[krahabb]

Yes sure!

[Pierremenard]

Just to give an example, this plug was sending power reading until 1 hour ago. Now it's zeroed and answer is this:
{"header":{"messageId":"122e3e47835fefcd8aaf22d13ce21859","namespace":"Appliance.Control.Electricity","method":"GETACK","payloadVersion":1,"from":"/appliance/2104020442298751806048e1e969b15c/publish","timestamp":1637244572,"timestampMs":7,"sign":"45d90c95ec3ec90955c1a6ec90525b6f"},"payload":{"electricity":{"channel":0,"current":0,"voltage":0,"power":0,"config":{"voltageRatio":188,"electricityRatio":102}}}}
Timestamp (from plug) 1637244572 - Timestamp (from system) 1637244573

So it does not seems that there is a mismatch in timestamps.

I noticed that by sending this message to /appliance/2104020442298751806048e1e969b15c/subscribe
{
"header": {
"from": "/app/6549264-3512a18a5hf5c7354d00f250d5bd09ba/subscribe",
"messageId": "122e3e47835fefcd8aaf22d13ce21859",
"method": "PUSH",
"namespace": "Appliance.System.Clock",
"payloadVersion": 1,
"sign": "5715a129e24c0cee7858ac17f7b028ff",
"timestamp": 1637245187
},
"payload": {
"clock": {
"timestamp": 1637245235
}
}
}

I get no request from the plug. As per your message the plug should intitiate the time reset, have I understood correctly?

Thank you

F.V.

[krahabb]

Well..that's weird. The message looks ok, the only difference being the 'from' field which looks like could be any mqtt topic the device should reply on. meross_lan uses a different topic but I don't expect that neing an issue.

I've not yet tested it but I'll try to query my plug later in the day and send you an update though.

At any rate, the timestamp from the plug looks correct and so the issue might be somewhere else. I've always experienced these '0' readings only when the plug was unable to receive the timestamp after boot and never seen them blanking after few (or more) hours working.

[Pierremenard]

A small update. I noticed that checking the plugs after they start to send zeros again there has been always a wifi disconnection reported by Appliance.System.Debug.
My actual theory is that after wifi disconnection timestamp is still ok, but power reading are zeroed. I just disabled the fast roaming for these devices from my wifi mesh network, let's see if this helps.
Anyway maybe the plugs after a wifi disconnection wait for a kind of signal. Noticeable is that they don't ask MQTT for a time fix in these cases.

[krahabb]

I've finally checked the 'transaction' I suggested you and found that the message to trigger the clock synchronization is not what I told you :(

The scheme is the same but the payload need to be empty like this:

{
"header": {
"from": "/app/6549264-3512a18a5hf5c7354d00f250d5bd09ba/subscribe",
"messageId": "122e3e47835fefcd8aaf22d13ce21859",
"method": "PUSH",
"namespace": "Appliance.System.Clock",
"payloadVersion": 1,
"sign": "5715a129e24c0cee7858ac17f7b028ff",
"timestamp": 1637245187
},
"payload": {
}
}

Of course the subsequent 'pushes' from the device will be sent to the topic you set in the 'from' field here

My code in meross_lan was actually sending the payload as previously stated...I don't know what I was thinking at the time but it is likely not working.
meross_lan deals with this message in 2 different pieces of code:

• the first is the code that manages the time synchronization procedure initiated when the device 'PUSHes' it's first 'Appliance.System.Clock' and this is likely working though it only happens when the plug initially connects to the mqtt broker
• the second piece is actually triggered when meross_lan detects a 'big' (more than 5 seconds) time misalignment: if this happens and the device is communicating over MQTT it sends the trigger message (the one we're talking about in this thread) so the device starts the synchronization procedure

[Pierremenard]

Thank you! I'm out of home in these day, as soon as I'll be back I'll check

Bye!

F.

[Pierremenard]

Update: you are right, if I send the message with empty topic the tyme sync flow starts correctly, like at boot. But this is not solving the zeroes coming even after the time sync.
The problem should be somewhere else.

F.V.

p.s. I noted that I've recevied the message below even if I never asked for a GET of "Appliance.Control.ConsumptionX". Are the plugs automatically reporting the historical consumptions on a timely interval?

{ "header": { "messageId": "0301af5026622a2d67906b37d1e02319", "namespace": "Appliance.Control.ConsumptionX", "method": "PUSH", "payloadVersion": 1, "from": "/appliance/2104020442298751806048e1e969b15c/publish", "timestamp": 1638179708, "timestampMs": 984, "sign": "a3f0f89687b62be42856860d48925823" }, "payload": { "consumptionx": [ { "date": "2021-11-07", "time": 1636298344, "value": 26 }, { "date": "2021-11-10", "time": 1636588689, "value": 10010 }, { "date": "2021-11-11", "time": 1636675087, "value": 7937 }, { "date": "2021-11-12", "time": 1636761485, "value": 8158 }, { "date": "2021-11-13", "time": 1636847884, "value": 278 }, { "date": "2021-11-14", "time": 1636934282, "value": 4754 }, { "date": "2021-11-15", "time": 1637020680, "value": 1 }, { "date": "2021-11-16", "time": 1637107086, "value": 1023 }, { "date": "2021-11-17", "time": 1637193484, "value": 1 }, { "date": "2021-11-18", "time": 1637279889, "value": 35 }, { "date": "2021-11-19", "time": 1637366285, "value": 13872 }, { "date": "2021-11-20", "time": 1637452681, "value": 7343 }, { "date": "2021-11-21", "time": 1637539084, "value": 0 }, { "date": "2021-11-22", "time": 1637625483, "value": 3827 }, { "date": "2021-11-23", "time": 1637711883, "value": 28 }, { "date": "2021-11-24", "time": 1637754567, "value": 9597 }, { "date": "2021-11-25", "time": 1637884688, "value": 81 }, { "date": "2021-11-26", "time": 1637971085, "value": 9904 }, { "date": "2021-11-27", "time": 1638057480, "value": 19 }, { "date": "2021-11-28", "time": 1638143880, "value": 0 }, { "date": "2021-11-29", "time": 1638179647, "value": 6 } ] } }

[krahabb]

@Pierremenard,
As for the zeros still coming out I really have no idea..maybe is an issue with the device frimware.

The ConsumptionX payload instead is being pushed on mines too. I've never investigated its properties like if its on a timer or maybe some value changes triggering the PUSH. If I'm not wrong, the 'Appliance.Control.Electricity' too is being PUSHED sometimes but I'm not really sure.
I was thinking about setting up a long term tracing in order to catch these behaviours but...well this task never reached enough priority ;)

[Pierremenard]

@krahabb Thank you!
Just for my knowledge, what firmware are you one? Mine is as follows:
"firmware": { "version": "6.1.4", "compileTime": "2021/02/27-16:55:22" }

[krahabb]

Mines are on fw 2.1.4 with hw 2.0.0.

Out of curiosity..throwing in something just came to mind:
I've discovered by inspecting traces from a newer smart hub (through one of meross_lan issues) that it was keeping pushing 'Bind' messages to the broker likely waiting for a reply. This was the first time I've seen that and I've added a simple SETACK reply in meross_lan protocol manager which had (luckily) shutted it down. Maybe there's something pointing in this direction for your device(s) too?

[Pierremenard]

It seems that updating the firmware helped, 3 days without zeroes.

Ciao!

F.