Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSS310 no sensor readings but switchable #55

Closed
kr0ner opened this issue Aug 6, 2021 · 50 comments
Closed

MSS310 no sensor readings but switchable #55

kr0ner opened this issue Aug 6, 2021 · 50 comments

Comments

@kr0ner
Copy link

kr0ner commented Aug 6, 2021

Version of the custom_component

v2.1.1

Configuration

Mosquitto

logins:
  - username: mqtt
    password: mqtt
  - username: 48:e1:XX:XX:XX:XX
    password: 0_4684bc65ed8e066290f6ceadcac68b67
  - username: 48:e1:YY:YY:YY:YY
    password: 0_d47fbc97e0b43b3d1f027562adc425f8
customize:
  active: false
  folder: mosquitto
certfile: /data/server.crt
keyfile: /data/server.key
require_certificate: false
allow_anonymous: true
port: 8883
cafile: /data/ca.crt

Describe the bug

First of all thanks for all the effort you put into this component :)
I have some trouble to get it to work with two MSS310, that work with the official App and are able to read the power consumption. In HomeAssistant I can see the device but the sensor readings are always zero. Surprisingly I can switch it on and off without any problems. Any hint on how to fix this is appreciated. Thanks in advance 👍

image

Debug log

The output I get running mosquitto_sub -h <IP> -u <USER> -P <PASSWORD> -v -t '#'
I've noticed that here I get the more values filled in Appliance.System.All than in the trace output.

appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"9521817f6705e4c4a645422ecfd11ea8","namespace":"Appliance.Control.ToggleX","method":"PUSH","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1033,"timestampMs":727,"sign":"2a61c0d476df5a0a9966b06d43421183"},"payload":{"togglex":[{"channel":0,"onoff":0,"lmTime":1033}]}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"80ae164d36546d28222f526cb2653a6a","namespace":"Appliance.Control.ToggleX","method":"PUSH","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1040,"timestampMs":855,"sign":"440612ed77e2331f6f8c2057025baee2"},"payload":{"togglex":[{"channel":0,"onoff":1,"lmTime":1040}]}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "bbbbb1fe557b4a8cb9864b7bc55003f1", "namespace": "Appliance.System.All", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628230271, "timestampMs": 0, "sign": "865acc3a7ddee084d77a2f0746d89316"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"bbbbb1fe557b4a8cb9864b7bc55003f1","namespace":"Appliance.System.All","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1120,"timestampMs":589,"sign":"51077886a393fa0ca9af3fe6168fe052"},"payload":{"all":{"system":{"hardware":{"type":"mss310","subType":"un","version":"6.0.0","chipType":"rtl8710cf","uuid":"2103098878720390845048e1e960d6bb","macAddress":"48:e1:e9:60:d6:bb"},"firmware":{"version":"6.1.4","compileTime":"2021/02/27-16:55:22","wifiMac":"f0:b0:14:17:78:99","innerIp":"192.168.178.65","server":"192.168.178.45","port":8883,"userId":0},"time":{"timestamp":1120,"timezone":"Europe/Berlin","timeRule":[[1616889600,7200,1],[1635634800,3600,0]]},"online":{"status":1}},"digest":{"togglex":[{"channel":0,"onoff":1,"lmTime":1040}],"triggerx":[],"timerx":[]}}}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "2d509fcf7cd8416c9bc369e60819a8da", "namespace": "Appliance.Control.Electricity", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628230271, "timestampMs": 0, "sign": "a0386ae8af7e4d8d0c2eef27edf7c538"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "fc056d764d804469ba24d5d0ab822362", "namespace": "Appliance.Control.ConsumptionX", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628230271, "timestampMs": 0, "sign": "c4339dc38ff5b5623f6be8989205217c"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"2d509fcf7cd8416c9bc369e60819a8da","namespace":"Appliance.Control.Electricity","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1120,"timestampMs":793,"sign":"8d662f569a0cd7fb7fb9f292822f5f76"},"payload":{"electricity":{"channel":0,"current":0,"voltage":0,"power":0,"config":{"voltageRatio":188,"electricityRatio":102}}}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"fc056d764d804469ba24d5d0ab822362","namespace":"Appliance.Control.ConsumptionX","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1120,"timestampMs":831,"sign":"2dc8cc655e187e8a34a3f683880db272"},"payload":{"consumptionx":[]}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "51470cdd9fbc454980fec11049efa15a", "namespace": "Appliance.Control.Electricity", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628230289, "timestampMs": 0, "sign": "232c578327b7233e6df632731f496ea6"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"51470cdd9fbc454980fec11049efa15a","namespace":"Appliance.Control.Electricity","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1137,"timestampMs":790,"sign":"bd85d8334d5c9c91bf86ed19d49f2046"},"payload":{"electricity":{"channel":0,"current":0,"voltage":0,"power":0,"config":{"voltageRatio":188,"electricityRatio":102}}}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "a21708c8edf54323896e7a4690fa2a7f", "namespace": "Appliance.Control.Electricity", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628230319, "timestampMs": 0, "sign": "e2fdda8b7069eca0fd0f2741725ca760"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"a21708c8edf54323896e7a4690fa2a7f","namespace":"Appliance.Control.Electricity","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1167,"timestampMs":793,"sign":"9dd4a9c9231fd147f19d34854171991b"},"payload":{"electricity":{"channel":0,"current":0,"voltage":0,"power":0,"config":{"voltageRatio":188,"electricityRatio":102}}}}

And here the output from the debug trace

2021/08/06 - 08:10:56   auto    GETACK  Appliance.System.All    {"system": {"hardware": {"type": "mss310", "subType": "un", "version": "6.0.0", "chipType": "rtl8710cf", "uuid": "", "macAddress": ""}, "firmware": {"version": "6.1.4", "compileTime": "2021/02/27-16:55:22", "wifiMac": "", "innerIp": "", "server": "", "port": "", "userId": ""}, "time": {"timestamp": 328, "timezone": "", "timeRule": []}, "online": {"status": 1}}, "digest": {"togglex": [{"channel": 0, "onoff": 0, "lmTime": 95}], "triggerx": [], "timerx": []}}
2021/08/06 - 08:10:56   auto    GETACK  Appliance.System.Ability        {"Appliance.Config.Key": {}, "Appliance.Config.WifiList": {}, "Appliance.Config.Wifi": {}, "Appliance.Config.Trace": {}, "Appliance.System.All": {}, "Appliance.System.Hardware": {}, "Appliance.System.Firmware": {}, "Appliance.System.Debug": {}, "Appliance.System.Online": {}, "Appliance.System.Time": {}, "Appliance.System.Clock": {}, "Appliance.System.Ability": {}, "Appliance.System.Runtime": {}, "Appliance.System.Report": {}, "Appliance.System.Position": {}, "Appliance.System.DNDMode": {}, "Appliance.Control.Multiple": {"maxCmdNum": 5}, "Appliance.Control.ToggleX": {}, "Appliance.Control.TimerX": {"sunOffsetSupport": 1}, "Appliance.Control.TriggerX": {}, "Appliance.Control.Bind": {}, "Appliance.Control.Unbind": {}, "Appliance.Control.Upgrade": {}, "Appliance.Control.ConsumptionX": {}, "Appliance.Control.Electricity": {}, "Appliance.Control.ConsumptionConfig": {}, "Appliance.Digest.TriggerX": {}, "Appliance.Digest.TimerX": {}}
2021/08/06 - 08:10:59   http    GET     Appliance.System.All    {}
2021/08/06 - 08:10:59   http    GET     Appliance.Control.Electricity   {}
2021/08/06 - 08:10:59   http    GET     Appliance.Control.ConsumptionX  {}
2021/08/06 - 08:10:59   http    GETACK  Appliance.System.All    {"all": {"system": {"hardware": {"type": "mss310", "subType": "un", "version": "6.0.0", "chipType": "rtl8710cf", "uuid": "", "macAddress": ""}, "firmware": {"version": "6.1.4", "compileTime": "2021/02/27-16:55:22", "wifiMac": "", "innerIp": "", "server": "", "port": "", "userId": ""}, "time": {"timestamp": 1107, "timezone": "Europe/Berlin", "timeRule": [[1616889600, 7200, 1], [1635634800, 3600, 0]]}, "online": {"status": 1}}, "digest": {"togglex": [{"channel": 0, "onoff": 1, "lmTime": 1040}], "triggerx": [], "timerx": []}}}
2021/08/06 - 08:10:59   http    GETACK  Appliance.Control.Electricity   {"electricity": {"channel": 0, "current": 0, "voltage": 0, "power": 0, "config": {"voltageRatio": 188, "electricityRatio": 102}}}
2021/08/06 - 08:10:59   http    GETACK  Appliance.Control.ConsumptionX  {"consumptionx": []}
@krahabb
Copy link
Owner

krahabb commented Aug 6, 2021

Hello @kr0ner ,
Thank you for your comments. I'm happy to say I've already seen this with mines and I can at least hint you to the solution.
The problem lies in the fact that the mss310 is not able to get a correct time at boot.
Every meross device does an NTP query at boot and if it fails there are different behaviours:

  • some devices 'halt' until they can't get an NTP update
  • some other work without issues
  • the mss310s work but their power readings are zeroed

Also, in some other docs I've read that the time setting could be done through MQTT but I've never tried to accomplish this in meross_lan (even tho it should be doable and I'm planning to try implement it)

So, in the end, easy fix (maybe):
by the look of it your meross(s) are firewalled from the internet and can't reach any NTP. I don't know which servers they use but I guess you can safely (?) open up (full) NTP traffic for these devices in order for them to query their NTP server and do a clean-complete boot

@kr0ner
Copy link
Author

kr0ner commented Aug 6, 2021

Thanks a lot for the input :) I'll give it a try and report back. You should setup a "Buy me a coffee" link in the meantime 😁

@kr0ner
Copy link
Author

kr0ner commented Aug 6, 2021

@krahabb I've checked my router setup and NTP seems to be accessible. No ports are blocked and NTP works fine on my workstation. When using the official app I think I saw something with timestamps and they were correctly set.
Could it be that the device tries to get the time via MQTT? 🤔
There are some CLOCK related messages in the log that I did not see before:

/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"58bdee655e3aaa240e92e6275c02040f","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":25,"timestampMs":272,"sign":"fbad6cacc57d16fbdff08db6b4bebfcb"},"payload":{"clock":{"timestamp":25}}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"f94b3218ec59ca1c5a88e3f752b441fe","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":27,"timestampMs":312,"sign":"37a6c03b1de0fdd97762480be7520257"},"payload":{"clock":{"timestamp":27}}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"c3f8101b84d93f9518c4abe3ccb19a8a","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":30,"timestampMs":477,"sign":"2e2e2cb2d7416f43fdab253aab5b9823"},"payload":{"clock":{"timestamp":30}}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"4f5d1e5be310e83132011011e48b880a","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":34,"timestampMs":549,"sign":"62b96c68b7cd786c8c736d89948e1354"},"payload":{"clock":{"timestamp":34}}}

@kr0ner
Copy link
Author

kr0ner commented Aug 6, 2021

Ok, played around a bit and I was able to (re?)set the clock of the device via MQTT^^

mosquitto_pub -h 192.168.178.45 -p 1883 -u mqtt -P mqtt -t /appliance/2103098878720390845048e1e960d6bb/subscribe -m "{\"header\":{\"messageId\":\"f4bbc1a2bf6e469750590d311be0c3cd\",\"namespace\":\"Appliance.System.Clock\",\"method\":\"PUSH\",\"payloadVersion\":1,\"from\":\"/appliance/2103098878720390845048e1e960d6bb/publish\",\"timestamp\":18,\"timestampMs\":1
42,\"sign\":\"0b91f0db0fca0b62b499235889e268f4\"},\"payload\":{\"clock\":{\"timestamp\":18}}}"

Not able to test, if I can use this to properly set the time since I am getting a "sign error" when I change the payload 😟

before
...publish","timestamp":1156,"timestampMs":187," ...
after sending the message
...publish","timestamp":18,"timestampMs":142,...
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"b0fb8f0fe1da48b484314e1d417b0641","namespace":"Appliance.Control.Electricity","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1156,"timestampMs":31,"sign":"f9820cad59bc4d5339d58666aeec6b45"},"payload":{"electricity":{"channel":0,"current":0,"voltage":0,"power":0,"config":{"voltageRatio":188,"electricityRatio":102}}}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"1b4c2509e4174649987729b739ca68bd","namespace":"Appliance.Control.ConsumptionX","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1156,"timestampMs":187,"sign":"cec0424064638045b7ce3582becd7e0c"},"payload":{"consumptionx":[{"date":"1970-01-01","time":28,"value":0}]}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"f4bbc1a2bf6e469750590d311be0c3cd","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":18,"timestampMs":142,"sign":"0b91f0db0fca0b62b499235889e268f4"},"payload":{"clock":{"timestamp":18}}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "8346b280f84a486fa6b8bd5a00b88ddc", "namespace": "Appliance.Control.Electricity", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628245931, "timestampMs": 0, "sign": "2027675a78539cf9550a35e79e5864c4"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"8346b280f84a486fa6b8bd5a00b88ddc","namespace":"Appliance.Control.Electricity","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1186,"timestampMs":973,"sign":"4817f7468b907445e5b4d88422a82fd2"},"payload":{"electricity":{"channel":0,"current":0,"voltage":0,"power":0,"config":{"voltageRatio":188,"electricityRatio":102}}}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header":{"messageId":"f4bbc1a2bf6e469750590d311be0c3cd","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":18,"timestampMs":142,"sign":"0b91f0db0fca0b62b499235889e268f4"},"payload":{"clock":{"timestamp":18}}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "b62891236ef5448280ccfaa4122f88f6", "namespace": "Appliance.Control.Electricity", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628245961, "timestampMs": 0, "sign": "c46a6a00dca44defd2315d62c2bf8b30"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "0409a0991a0b4baeb7581323a5d819d9", "namespace": "Appliance.Control.ConsumptionX", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628245961, "timestampMs": 0, "sign": "d8e1fc3471de1bd1e4e61cf406781235"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"b62891236ef5448280ccfaa4122f88f6","namespace":"Appliance.Control.Electricity","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":33,"timestampMs":976,"sign":"d7f134a41d5ad8123367b81763d208c1"},"payload":{"electricity":{"channel":0,"current":0,"voltage":0,"power":0,"config":{"voltageRatio":188,"electricityRatio":102}}}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"0409a0991a0b4baeb7581323a5d819d9","namespace":"Appliance.Control.ConsumptionX","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":33,"timestampMs":24,"sign":"d53fa32814f918245a97a9d51c7606c8"},"payload":{"consumptionx":[{"date":"1970-01-01","time":28,"value":0}]}}

@krahabb
Copy link
Owner

krahabb commented Aug 6, 2021

Hey @kr0ner ,
lot of stuff here ;)

If you want to play a bit with mqtt you could do that from HA 'Developer Tools' -> 'Services': there's a meross_lan.request service which you can use and it will manage the signing/filling of the payload header. This way you can easily test any payload structure and see what's happening. Sure you'll have to monitor the mqtt flow since HA doesn't contextually shows you any reply from the device.

It is very strange btw the issue with NTP. I'm pretty sure my mss310 started working correctly right after opening the NTP ports (I've opened UDP dest port 123) but well..maybe there's also a DNS issue or whatever

Anyway, in meross_lan there's a section of code which sets the timezone and DST of the meross and it now works just for that. My intention was to use the same piece of code to also set the (actual) timestamp for 'erratics' devices but I've delayed this in order to be able to think and test it thoroughly since I guess it might be subtle when you deal with time.
If your tries are succesful that could be a big insight on this option feasibility

@kr0ner
Copy link
Author

kr0ner commented Aug 6, 2021

Hey @krahabb,
thanks for the hints, found the developer setting 👍
I was able to set the device time using the following config (had to switch to YAML) cause clock is the only option that uses PUSH -_-

service: meross_lan.request
data:
  namespace: Appliance.System.Clock
  method: PUSH
  device_id: 2103098878720390845048e1e960d6bb
  payload: '{"clock":{"timestamp":1628250886}}'
/appliance/2103098878720390845048e1e960d6bb/subscribe {"header": {"messageId": "a04f7ff162a54a1095602df57668f720", "namespace": "Appliance.Control.Electricity", "method": "GET", "payloadVersion": 1, "from": "/appliance/2103098878720390845048e1e960d6bb/publish", "timestamp": 1628251211, "timestampMs": 0, "sign": "3906568925a396430efcbdf623a7e8bb"}, "payload": {}}
/appliance/2103098878720390845048e1e960d6bb/publish {"header":{"messageId":"a04f7ff162a54a1095602df57668f720","namespace":"Appliance.Control.Electricity","method":"GETACK","payloadVersion":1,"from":"/appliance/2103098878720390845048e1e960d6bb/publish","timestamp":1628250991,"timestampMs":755,"sign":"106f7ca2f5a33c6a055fdc1d796f3bac"},"payload":{"electricity":{"channel":0,"current":0,"voltage":0,"power":0,"config":{"voltageRatio":188,"electricityRatio":102}}}}

The sad part is ... I still get all zeroes 😢

If your tries are succesful that could be a big insight on this option feasibility

Happy to help 👍

@krahabb
Copy link
Owner

krahabb commented Aug 6, 2021

Aww..
well..maybe the firmware wants the time setup correctly at the very beginning and it wont 'catch-up' after the initial failure
....
I was writing this and decided to give it a fast try...
and the answer is:
yes it expects a 'PUSH' reply after it's own PUSH so I've modified meross_lan to intercept these pushes and reply the actual timestamp and it works.
I've completely firewalled my mss310 and it now reports correct reading (after implementing Clock-PUSH-reply)

If you're up to you can find the modified code in #dev a11a948

@kr0ner
Copy link
Author

kr0ner commented Aug 6, 2021

@krahabb holy sh** you are fast <3
Will try it immediately

@kr0ner
Copy link
Author

kr0ner commented Aug 6, 2021

works like a charm ...
image
I really need to ask again for that "Buy me a coffee" button 😄

Thanks a lot for your help. If there is anything I can do now or in the future when it comes to testing just mention me :)
Now I can go ahead and push the fix for the mac address auth problem in mosquitto so that everything is usable out of the box again 👍

@krahabb
Copy link
Owner

krahabb commented Aug 6, 2021

Hey @kr0ner ,
thank you very much, I've pushed (together with the missing 'const' definition related to the previous patch :) a bunch of updates in order to implement sensors long_term_statistics. Since you were already playing around I would really appreciate if you could clone the dev and see how it goes, so to be sure a public release would work correctly.

Basically, I've just added the new properties to all of meross_lan sensors so they could partecipate in statistics. Also, the energy meter sensor has it's own 'last_reset' setup according to what I've learned from the docs.
I'm still not able to see how it works in the long term especially since there is not enough time frame at the moment and also because my mss310 is actually powering a small light so there's no real big consumption and the numbers are so 'tiny'

Thank you again

@kr0ner
Copy link
Author

kr0ner commented Aug 10, 2021

Hi @krahabb I have some quick update for you
The dev branch also seems to work 👍

For testing I used two devices with slightly different firmware.
The first device

mss310 un rtl8710cf (hardware:6.0.0 firmware:6.1.8) 

the second one

mss310 un rtl8710cf (hardware:6.0.0 firmware:6.1.4) 

Some findings:

  • Setting the timestamp works with both devices
  • If the device is already running and connected to the MQTT server, but meross_lan is not ready yet (for whatever reason) the clock will not be set. -> Maybe a periodic set-time would fix this. Possibly before polling for the sensor values.
  • If a device is unplugged, the sensor values stay forever. They should probably be reset to 0 when polling the next time and not getting an answer from the device
  • Apparently the sockets do not work reliably :'-( ... either they work right from the beginning and send proper values, or do not work at all and we are back at all zero values. --> It looks like powering the device off for some time (~1 or 2 minutes) can fix this issue. Unplugging a device and directly plug it back in does not work, because the previous time value is still there.

Looks like the timestamp needs to be very precise, so possible fix could be:
instead of

{ mc.KEY_CLOCK: { mc.KEY_TIMESTAMP: int(self.lastupdate)}}

use

{ mc.KEY_CLOCK: { mc.KEY_TIMESTAMP: int(datetime.datetime.now().timestamp()}}

@krahabb
Copy link
Owner

krahabb commented Aug 10, 2021

Hey @kr0ner,
Thank you for reporting.

meross_lan should recognize the plug going offline but it's a nightmare: on MQTT I rely on some timeouts not seeing any response after some request but this conflicts with polls (which are repeated until it's offline) so the code will eventually fool itself. I've already fixed/broken this several times :) and actual iteration is broken....

I'm patching this so even on MQTT I can (reliably?) determine device availability just to fix one point.

As per the device being configured 'asynchronously' (i.e. not right after its own initial CLOCK-PUSH) I'll check if it works and fix that. If instead the firmware only accept the CLOCK-Config right after the PUSH that could be a dead end: If meross_lan is not available when the plug connects to MQTT we will never be able to configure it (from what I see so far..)

As per the precise timing I don't think we can get any further since we still would have the HA-Python-MQTT services in between and we're not able to determine how much time it takes for our payload to reach the plug..so being 'that precise' when sending might be useless..I'll see anyway, my code was using a relatively freshly cached time() reading so to optimize it a bit and it shouldnt be that far from real time()

@Ostepanov
Copy link

Ostepanov commented Aug 15, 2021

Version of the custom_component

v2.1.1

Configuration

Mosquitto

logins:
  - username: mqtt
    password: mqtt
  - username: 48:e1:XX:XX:XX:XX
    password: 0_4684bc65ed8e066290f6ceadcac68b67
  - username: 48:e1:YY:YY:YY:YY
    password: 0_d47fbc97e0b43b3d1f027562adc425f8
customize:
  active: false
  folder: mosquitto
certfile: /data/server.crt
keyfile: /data/server.key
require_certificate: false
allow_anonymous: true
port: 8883
cafile: /data/ca.crt

Hello kr0ner
How you avoided mqtt limitations about username? Because mqtt is not allowing to use ":" in usernames.
Because of this issue, I can't connect my plugs to mqtt and receive data from their sensor. And without mqtt, I only can just turn on/off them using meross_lan

Thanks!

@krahabb
Copy link
Owner

krahabb commented Aug 15, 2021

Hello @Ostepanov,
For the mqtt part I know it's a bit of hell and you're likely falling in home-assistant/addons#2020 like @kroner reported here.
I personally have a 'raw' mosquitto (no HASSIO no ADDON) with an unauthenticated setup working like a charm (I've even stopped APT updates on mosquitto since they often break something).
As per your devices talking over HTTP to meross_lan I've seen from your logs everything was ok, just there was no 'memory' of energy consumption inside the device and you have to wait the clock ticking to start seeing the numbers (some big load on the plug itself could help but not sure ;).

The mss310 energy reporting is a bit tricky if the plug doesn't have the correct time (from your logs I see they don't) and timezone.

The new version of meross_lan I'm about to release is able (or should since it could also depend on device firmware) to configure the device time and in my tests with my plugs works correctly even if the plug cannot synchronize it's time on boot by itself (Meross devices mostly need to complete an NTP query at boot in order to work correctly).

In my network setup I allow meross devices to go through my firewall for NTP queries.
This is what happens if they don't (devices totally isolated from internet)

  • mss310: works correctly but reports '0' in energy readings (power, voltage,current too)
  • msl120 (light bulb): works correctly (has incorrect time though but it doesn't hurt)
  • msh300 (hub): doesn't boot. It keeps rebooting

With the new version of meross_lan (2.2.0) you'll be able to fix mss310 time setup even without NTP connectivity.

@krahabb
Copy link
Owner

krahabb commented Aug 15, 2021

Quick info about the 'release' (2.2.0):
The time config/setting for mss310 from meross_lan is generally working only when paired over MQTT since if a device is only reachable via HTTP it is likely still paired to the original Meross cloud and so I don't even try to conflict with that

@kr0ner
Copy link
Author

kr0ner commented Aug 15, 2021

Version of the custom_component

v2.1.1

Configuration

Mosquitto

logins:
  - username: mqtt
    password: mqtt
  - username: 48:e1:XX:XX:XX:XX
    password: 0_4684bc65ed8e066290f6ceadcac68b67
  - username: 48:e1:YY:YY:YY:YY
    password: 0_d47fbc97e0b43b3d1f027562adc425f8
customize:
  active: false
  folder: mosquitto
certfile: /data/server.crt
keyfile: /data/server.key
require_certificate: false
allow_anonymous: true
port: 8883
cafile: /data/ca.crt

Hello kr0ner
How you avoided mqtt limitations about username? Because mqtt is not allowing to use ":" in usernames.
Because of this issue, I can't connect my plugs to mqtt and receive data from their sensor. And without mqtt, I only can just turn on/off them using meross_lan

Thanks!

home-assistant/addons#2137

Hi @Ostepanov , as @krahabb correctly pointed out, there is some issue with mosquitto addon for home assistant. The PR above is still open and I did not manage to build a docker yet :/ if you are familiar with docker you can open a shell in the existing container, change the files manually and commit the changes to the container. I'm running this setup and it works.

@kr0ner
Copy link
Author

kr0ner commented Aug 15, 2021

Quick info about the 'release' (2.2.0):
The time config/setting for mss310 from meross_lan is generally working only when paired over MQTT since if a device is only reachable via HTTP it is likely still paired to the original Meross cloud and so I don't even try to conflict with that

Will test the recent dev branch tomorrow to see, if it fixes my startup problems 👍

@kr0ner
Copy link
Author

kr0ner commented Aug 20, 2021

Hi @krahabb, I've again had some time to test the latest 2.2.0 release.

  • Seems that the devices no longer get a proper time. Looks like if no NTP sync happened, the same (wrong) time value is send back to the device.
  • mss310 un rtl8710cf (hardware:6.0.0 firmware:6.1.4) still works most of the time
  • mss310 un rtl8710cf (hardware:6.0.0 firmware:6.1.8) could not get this one to work :-/
    Will see if I can find the root cause for that and report back. Thanks :)

@krahabb
Copy link
Owner

krahabb commented Aug 21, 2021

Hello @kr0ner ,
I'm actually on a small vacation and cannot test anything. I'll see next week if I can figure out why. In my setup, the feature seemed to work correctly

@kr0ner
Copy link
Author

kr0ner commented Aug 21, 2021

Hello @kr0ner ,
I'm actually on a small vacation and cannot test anything. I'll see next week if I can figure out why. In my setup, the feature seemed to work correctly

No need to hurry :) enjoy your vacation 👍

@userMak
Copy link

userMak commented Aug 25, 2021

Hi
2 months ago with the help of @bytespider and meross_lan I managed to configure few meross switches I have and were working fine. The last few days (after my vacations) I tried to install a few things in HA and updated to 2021.8.8. I also updated meros_lan from hacs etc.

This morning I have the following problem. Although all my switches (lights) are working fine all of my switches are blinking fast with red light as if they are not connected! But all of them still available in HA and working fine.

My mosquito broker version is 5.1.1.
I have the following configuration
logins: [] anonymous: false customize: active: false folder: mosquitto certfile: fullchain.pem keyfile: privkey.pem require_certificate: false

and in the logs I am getting the following errors.
Can someone help a bit because I am completely lost here.

1629911944: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911944: Socket error on client <unknown>, disconnecting. 1629911944: New connection from 192.168.1.47 on port 8883. 1629911944: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911944: Socket error on client <unknown>, disconnecting. 1629911944: New connection from 192.168.1.49 on port 8883. 1629911944: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911944: Socket error on client <unknown>, disconnecting. 1629911944: New connection from 192.168.1.50 on port 8883. 1629911944: New connection from 192.168.1.48 on port 8883. 1629911944: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911944: Socket error on client <unknown>, disconnecting. 1629911944: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911944: Socket error on client <unknown>, disconnecting. 1629911947: Client connection from 192.168.1.51 failed: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher. 1629911947: New connection from 192.168.1.53 on port 8883. 1629911947: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911947: Socket error on client <unknown>, disconnecting. 1629911948: New connection from 192.168.1.52 on port 8883. 1629911948: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911948: Socket error on client <unknown>, disconnecting. 1629911948: New connection from 192.168.1.47 on port 8883. 1629911948: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911948: Socket error on client <unknown>, disconnecting. 1629911948: New connection from 192.168.1.49 on port 8883. 1629911948: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911948: Socket error on client <unknown>, disconnecting. 1629911948: New connection from 192.168.1.50 on port 8883. 1629911948: New connection from 192.168.1.48 on port 8883. 1629911948: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911948: Socket error on client <unknown>, disconnecting. 1629911948: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911948: Socket error on client <unknown>, disconnecting. 1629911951: New connection from 192.168.1.51 on port 8883. 1629911951: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911951: Socket error on client <unknown>, disconnecting. 1629911951: New connection from 192.168.1.53 on port 8883. 1629911951: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911951: Socket error on client <unknown>, disconnecting. 1629911952: New connection from 192.168.1.52 on port 8883. 1629911952: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911952: Socket error on client <unknown>, disconnecting. 1629911952: New connection from 192.168.1.47 on port 8883. 1629911952: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911952: Socket error on client <unknown>, disconnecting. 1629911952: Client connection from 192.168.1.49 failed: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher. 1629911952: New connection from 192.168.1.50 on port 8883. 1629911952: New connection from 192.168.1.48 on port 8883. 1629911952: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911952: Socket error on client <unknown>, disconnecting. 1629911952: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911952: Socket error on client <unknown>, disconnecting. 1629911955: New connection from 192.168.1.51 on port 8883. 1629911955: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911955: Socket error on client <unknown>, disconnecting. 1629911955: New connection from 192.168.1.53 on port 8883. 1629911955: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911955: Socket error on client <unknown>, disconnecting. 1629911956: New connection from 192.168.1.52 on port 8883. 1629911956: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911956: Socket error on client <unknown>, disconnecting. 1629911956: New connection from 192.168.1.47 on port 8883. 1629911956: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911956: Socket error on client <unknown>, disconnecting. 1629911956: New connection from 192.168.1.49 on port 8883. 1629911956: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911956: Socket error on client <unknown>, disconnecting. 1629911956: New connection from 192.168.1.50 on port 8883. 1629911956: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911956: Socket error on client <unknown>, disconnecting. 1629911956: New connection from 192.168.1.48 on port 8883. 1629911956: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911956: Socket error on client <unknown>, disconnecting. 1629911959: New connection from 192.168.1.51 on port 8883. 1629911959: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911959: Socket error on client <unknown>, disconnecting. 1629911959: New connection from 192.168.1.53 on port 8883. 1629911959: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911959: Socket error on client <unknown>, disconnecting. 1629911960: New connection from 192.168.1.52 on port 8883. 1629911960: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911960: Socket error on client <unknown>, disconnecting. 1629911960: New connection from 192.168.1.47 on port 8883. 1629911960: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911960: Socket error on client <unknown>, disconnecting. 1629911960: New connection from 192.168.1.49 on port 8883. 1629911960: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911960: Socket error on client <unknown>, disconnecting. 1629911960: New connection from 192.168.1.50 on port 8883. 1629911960: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911960: Socket error on client <unknown>, disconnecting. 1629911960: New connection from 192.168.1.48 on port 8883. 1629911960: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911960: Socket error on client <unknown>, disconnecting. 1629911963: New connection from 192.168.1.51 on port 8883. 1629911963: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911963: Socket error on client <unknown>, disconnecting. 1629911963: New connection from 192.168.1.53 on port 8883. 1629911963: OpenSSL Error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 1629911963: Socket error on client <unknown>, disconnecting.

@homonto
Copy link

homonto commented Aug 25, 2021

I am struggling as well with the same symptoms:

  • all sockets working but
  • all blinking and
  • no communication with MQTT broker on HA

@userMak
Copy link

userMak commented Aug 25, 2021

I am struggling as well with the same symptoms:

  • all sockets working but
  • all blinking and
  • no communication with MQTT broker on HA

aha, that's good news (in a way) not to be alone with this problem,
because I thought I have done something wrong in my setup and I have very limited knowledge with MQTT, mosquito etc so I am sure I will not be able to fix it by myself. Hope someone here could help us

@homonto
Copy link

homonto commented Aug 25, 2021

the only difference is: my Meross sockets never worked with HA alone yet - I am moving from Meross connected to HA connected (after Meross company started turning off my lights at home and disabling my sockets remotely)
I am on "high alert" how to solve it and the other link is here where good people try to help me with the same:
here

@userMak
Copy link

userMak commented Aug 25, 2021

I am looking for it all day. after so many hours and still don't know what the problem is. at least the switches still working.

@homonto
Copy link

homonto commented Aug 25, 2021

true, but the guys on the other thread say, that socket will self reset and go OFF after some timeout ;-(

@userMak
Copy link

userMak commented Aug 25, 2021

true, but the guys on the other thread say, that socket will self reset and go OFF after some timeout ;-(

why? Yours are off? Mine are at this stage 16 hours. I hope that I don't have to do all from scratch.

@homonto
Copy link

homonto commented Aug 25, 2021

mine are ON still
but if they go OFF and my fridge goes OFF in the night... ;-)

@nao-pon
Copy link
Contributor

nao-pon commented Aug 26, 2021

@userMak , @homonto I experienced the same problem, but I solved it by creating my own certificate and using it.

I put the ssl/mqtt that files.

certfile: mqtt/server.crt
keyfile: mqtt/server.key
require_certificate: false
cafile: mqtt/ca.crt

@homonto
Copy link

homonto commented Aug 26, 2021

we solved the problem as well - see the other thread here #63 (reply in thread)

@userMak
Copy link

userMak commented Aug 26, 2021

@userMak , @homonto I experienced the same problem, but I solved it by creating my own certificate and using it.

I put the ssl/mqtt that files.

certfile: mqtt/server.crt
keyfile: mqtt/server.key
require_certificate: false
cafile: mqtt/ca.crt

are you using a seperate broker for meross devices other than HA's mosquito? Bytespider helped me before a while to setup HA mosquito broker to accept messages from meross devices too, so I never followed the above procedure to set it up, thus now I don't know how to continue. For the certificates I had installed duckdns addon.

@nao-pon
Copy link
Contributor

nao-pon commented Aug 26, 2021

@userMak I'm using HA Addon's Mosquitto broker 5.1.1. In order to connect Meross devices in 6.0.1, I need to add a HA user for each device, which I hate and use 5.1.1.

Also, the certificate created by Duckdns (Let's encrypt) addon will fail to authenticate on older Meross devices, so you will need to create your own certificate and use it.

@userMak
Copy link

userMak commented Aug 26, 2021

@nao-pon
So I have to do the following commands in my Ubuntu 18.04 NUC? Is there any more detailed instructions I could follow ?

Set up the Certificates
Make sure that your CA Root uses a different Common Name to your server and the common name for the server is the server IP address

##Create the Certificate Authority

openssl genrsa -des3 -out ca.key 2048
openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
##Create the certificate signing request. It's important when asked for the FQDN in these next step to use the IP or domain name of the machine your MQTT instance is on.

openssl genrsa -out server.key 2048
openssl req -new -out server.csr -key server.key
##Create the final certificate

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360

@nao-pon
Copy link
Contributor

nao-pon commented Aug 26, 2021

@userMak I'm not an expert so I don't know the details. However, with the certificate created by the Duckdns add-on, I could not connect with the same error message as you, but by using the certificate created by the procedure myself, I can connected.

I think it doesn't matter what machine you make the certificate on, and it doesn't take too long, so it's worth a try.

P.S. I thought -days 360 was short, so I chose -days 3650.

@homonto
Copy link

homonto commented Aug 26, 2021

. I thought -days 360 was short, so I chose -days 3650

I did EXACTLY the same ;-) next recreation: 2031 ;-)

@userMak
Copy link

userMak commented Aug 26, 2021

. I thought -days 360 was short, so I chose -days 3650

I did EXACTLY the same ;-) next recreation: 2031 ;-)

I will try them tomorrow when I return home. I hope I don't mess my system more than it is now. After this procedure you had to reconfigure all the switches in HA or it just worked out?

@homonto
Copy link

homonto commented Aug 26, 2021

After this procedure you had to reconfigure all the switches in HA or it just worked out?

I was working on certs for the whole day almost and sockets were not connected (blinking)
once I sorted out certs, all sockets connected AUTOMATICALLY - no need to reconfigure them
I think this is because the command you execute on pairing says: "this is your AP and password, and this is your broker" - nothing else in that command
Am I right? Or left? ;-)

@homonto
Copy link

homonto commented Aug 26, 2021

. I thought -days 360 was short, so I chose -days 3650

I did EXACTLY the same ;-) next recreation: 2031 ;-)

I will try them tomorrow when I return home. I hope I don't mess my system more than it is now. After this procedure you had to reconfigure all the switches in HA or it just worked out?

Nothing, as even before all was working except all blinked
With regards to messing up: "full snapshot before" could be the key word here

@userMak
Copy link

userMak commented Aug 26, 2021

With regards to messing up: "full snapshot before" could be the key word here

Yes, I will do that, but Ideally I would like to avoid it :)
Please clarify the below code I have to execute it step by step (5 steps)

##Create the Certificate Authority

  1. openssl genrsa -des3 -out ca.key 2048

  2. openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
    ##Create the certificate signing request. It's important when asked for the FQDN in these next step to use the IP or domain name of the machine your MQTT instance is on.

  3. openssl genrsa -out server.key 2048

  4. openssl req -new -out server.csr -key server.key
    ##Create the final certificate

  5. openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360

Is there anything else I should consider?

@homonto
Copy link

homonto commented Aug 26, 2021

Is there anything else I should consider?

the complete guide is here:
#63

@kr0ner
Copy link
Author

kr0ner commented Aug 26, 2021

Hello @kr0ner ,
I'm actually on a small vacation and cannot test anything. I'll see next week if I can figure out why. In my setup, the feature seemed to work correctly

I think the problem was that my sockets were in a corner of my appartment with very bad wifi coverage. I moved them closer to the router an everything seems to be working fine again :)

@kroner
Copy link

kroner commented Aug 30, 2021

Hi all,
I appreciate you keeping me in the loop, but I'm on this thread in error. Just wanted to let you know.

@krahabb
Copy link
Owner

krahabb commented Sep 18, 2021

Closing this since it appears stale and mostly 'out of band' with original issue.
That was likely fixed anyway and any new issue will follow up
Thank you

@krahabb krahabb closed this as completed Sep 18, 2021
@kr0ner
Copy link
Author

kr0ner commented Sep 18, 2021

Closing this since it appears stale and mostly 'out of band' with original issue.
That was likely fixed anyway and any new issue will follow up
Thank you

Thank you for the great work! 🙂

@Write
Copy link

Write commented Oct 15, 2021

Hello. I'm having the same issue because all my meross are firewalled, I can turn them on / off from the interface no problem, but some don't have any power readings after a reboot or power loss, either because of the firewall, or because there was no internet at the time (power loss in the whole house).
What's the easiest way to fix it ? I'v read trough all the messages here but there are TONS of stuff
I don't use MQTT, i've just added my devices trough Meross LAN (automatically detected all my devices on the network) and put the key that I got from Homberidge when loggin with my cloud account.
Removing the firewall, then unplugging and replugging the outlet, then turning on the firewall on again seems to work but that's really annoying

EDIT : I fixed it by port forwarding (Firewall > NAT > Port forward) all NTP requests trough the firewall (OPNsense) which comes with a NTPd server.

image
Where 192.168.1.2 is the IP of my OPNsense.

No need to replug the devices, once the NTP server is reachable by the meross device, the power reading works again.

@krahabb
Copy link
Owner

krahabb commented Oct 15, 2021

Hello @Write ,
that's a known 'issue' : when the meross(s) power meter boot and can't reach an NTP server their timestamp is wrong and their power readings are 'nulled' too.
I've implemented a protocol transition in MQTT in order to set them up but that's only working on MQTT since it involves responding to a 'PUSH' message incoming through the broker and originated from the device.
On HTTP the transition is really 'poor' i.e. it's just a 'request' (from meross_lan) -> 'response' (from the device) so I can't, or at least I don't know how to, establish a proper 'session' with the device in order to set the time

If you plan to not pair the devices to your own MQTT broker and let them be managed via MQTT by meross_lan, allowing them to correctly reach the NTP server looks like the only solution I know so far.

@Write
Copy link

Write commented Oct 15, 2021

Hello @Write , that's a known 'issue' : when the meross(s) power meter boot and can't reach an NTP server their timestamp is wrong and their power readings are 'nulled' too. I've implemented a protocol transition in MQTT in order to set them up but that's only working on MQTT since it involves responding to a 'PUSH' message incoming through the broker and originated from the device. On HTTP the transition is really 'poor' i.e. it's just a 'request' (from meross_lan) -> 'response' (from the device) so I can't, or at least I don't know how to, establish a proper 'session' with the device in order to set the time

If you plan to not pair the devices to your own MQTT broker and let them be managed via MQTT by meross_lan, allowing them to correctly reach the NTP server looks like the only solution I know so far.

As it says in my edit, redirecting/forwarding all outgoing NTP requests to my local ntp server (which is included by default in OPNsense) is enough and seems to work great so I'm happy with that, thanks for your thorough answer ^^

@PixelPusher247
Copy link

PixelPusher247 commented Feb 17, 2022

Hi, I'm having this issue with my MSS310s. They are switchable but report 0 values for electricity. They have access to NTP and are not blocked in any way, I also see that they report the correct timestamp.
Here one of the messages on the local MQTT broker:

{
  "header": {
    "messageId": "a403be8693a047c2beb6735eb3a8ac5a",
    "namespace": "Appliance.Control.Electricity",
    "method": "GET",
    "payloadVersion": 1,
    "from": "/appliance/2102038745709490841348e1e94a8ad9/publish",
    "timestamp": 1645136103,
    "timestampMs": 0,
    "sign": "9c73ba9fb6c65a05a8e59a828c53a86a"
  },
  "payload": {
    "electricity": {}
  }
}

{
  "header": {
    "messageId": "7f6c94ee4bf7450d80fdaa8a31fa55ea",
    "namespace": "Appliance.Control.Electricity",
    "method": "GETACK",
    "payloadVersion": 1,
    "from": "/appliance/2102038745709490841348e1e94a8ad9/publish",
    "timestamp": 1645136132,
    "timestampMs": 679,
    "sign": "b9b4423c6f9834026b404ba8216dea64"
  },
  "payload": {
    "electricity": {
      "channel": 0,
      "current": 0,
      "voltage": 0,
      "power": 0,
      "config": {
        "voltageRatio": 188,
        "electricityRatio": 102
      }
    }
  }
}

What could be the reason for them not reporting the correct electricity values?

@krahabb
Copy link
Owner

krahabb commented Feb 18, 2022

@czornikk ,
Hard to say...since it looked in the past the issue was related to an incorrect timing setup/initialization I might consider checking the 'timezone' setting of the device too. You can configure it in the integration configuration for the device and maybe try set/reset it. On my mss310 the timezone setting looks like it doesn't modify the electricity readings and correct values are reported with it either set or not but who knows....
Also, you could try uploading a device trace so I could have a look around it for clues anyway.

@PixelPusher247
Copy link

PixelPusher247 commented Feb 18, 2022

My Timezone was set correctly. Here you have the device trace
mss310-1645175812.csv

Thanks so much for taking the time to look into it. I was using the MSS310 connected to the cloud to get correct readings, but really wanted to switch everything to local MQTT. My MSS210 are working flawlessly with a local MQTT, so I'm already really thankful for that, great job and thank you!

EDIT: right as I was posting this I wanted to get another device trace where I disconnect the device and reconnected/turn it on and off a couple of times and now I'm getting readings! So you can close this again, sorry for the inconvenience :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants