krahabb
commented
8 months ago Hello @Write , This issue is really persistent! One thing I notice is the newer device (hw 6.0.0) does not have the timezone set. I cannot say it is for sure the reason but you could try set it the same as the older hw version ones ('Europe/Paris'). To be honest, if I remember it right, it was not necessary for hw 2.0.0 to have this configuration set in order to work but maybe newer fw has an issue with that.
Also, it looks like their MQTT binding is different. If the traces were taken at the same time i.e. without rebooting HA, they're showing different values for the MQTT bind server/port/userId (the obfuscation algorithm would match the same server name to the same obfuscated value) but this is just a question for me to understand the 'context' in which these trace were done.
All in all, one point for investigating this issue is the fact that when the devices boot up and connect to the (private) broker, they're expecting a particular warm-up sequence which has been implemented in latest meross_lan (4.5.2 has it in place) but the meaning and real behavior of this sequence is a bit obscure at the moment (see #346). In details, the mss devices send a kind of 'configuration payload' to the server and expect a response for this. Now, the actual implementation for the content of this response is to just reply the same payload the device sent to the broker but it could be wrong since the test/implementation was done with an mss315 device
In order to better investigate this warm-up sequence, actual meross_lan version lacks the needed debugging facilities (initial warm-up is not beeing logged) while the actual 'dev' branch has better support for this. The only option to see what happens when the device boots and connect to the HA broker would be to use the 'sniff' feature of the HA MQTT component and watch all the packets sent to the wildcard topic /appliance/#
I'll follow up with a (working?) pre-release in order to have the option to better log the boot sequence and try to understand what's going on
Write
hamid-elaosta
Similar to : https://github.com/krahabb/meross_lan/issues/300 This issue has been marked as fixed in https://github.com/krahabb/meross_lan/pull/337 but it's not, or at least not for 310 w/ HW 6.0.0 and update >= 6.3.21
Version of the custom_component
v4.5.2
Describe the bug
I have 4 MSS310 (Hardware 2.0.0), w/ update 2.1.17 which works perfectly fine since forever.
I just bought 3 new MSS310 (Hardware 6.0.0) with update 6.3.21
On which I can only on/off the outlet and the DNDmode, but I got no data from the consumption : no current value no energy value no power value no voltage value
I have an OPNsense router.
Back then, for readings to works correctly on my MSS310 (2.0.0), I had to add a rule to forward all NTP requests going outside to be forwarded on my local NTP server, since I have blocked internet access, so they could correctly set their own time.
Now, once I received my new MSS310, I have done the same, and with the helps of OPNsense logging, I can confirm that I DO receive NTP requests from those new MSS310 (6.0.0), and they are correctly forwarded to my local NTP server, exactly as the MSS310 (2.0.0).
Note : All my devices are paired with https://github.com/bytespider/Meross, w/ an empty key. Resetting and repairing an "older" MSS310 (2.0.0) still work perfectly, and readings are still fine after re-adding them to HA.
Debug log
Trace logs for an MSS310 w/ Hardware 6.0.0, unused
Trace logs for an MSS310 w/ Hardware 2.0.0 connected to the same power strip, unused