Closed psmatter closed 1 year ago
bmizuhara
commented
1 year ago It seems like a network connectivity problem...
Please double-check:
Hope this helps..
psmatter
commented
1 year ago Thank you for the quick reply!
Pingin the device and it answers back, so I guess a network problem and a mac filter can be ruled out. Also the device did already connect with meross cloud some days ago, before I used the setup tool from Step 9. Which btw also does the setup when I point it to the devices current IP. (not in ap mode)
I also tried another cert setup with ca and server.crt but switched back to the mqtt_server.pem you suggested since it works fine. (at least with mosquitto_pub)
Here is the mosquitto (2.0.11) log:
1668428397: New client connected from 192.168.8.121:61943 as 48:e1:xx:xx:xx:xx (p1, c1, k120, u'48:e1:xx:xx:xx:xx'). 1668428397: No will message specified. 1668428397: Sending CONNACK to 48:e1:xx:xx:xx:xx (0, 0) 1668428397: Received SUBSCRIBE from 48:e1:xx:xx:xx:xx 1668428397: /appliance/2208022697555151xxx/subscribe (QoS 1) 1668428397: 48:e1:xx:xx:xx:xx 1 /appliance/2208022697555151xxx/subscribe 1668428397: Sending SUBACK to 48:e1:xx:xx:xx:xx 1668428397: Received PUBLISH from 48:e1:xx:xx:xx:xx (d0, q1, r0, m3, '/appliance/2208022697555151xxx/publish', ... (389 bytes)) 1668428397: Sending PUBACK to 48:e1:xx:xx:xx:xx (m3, rc0) 1668428397: Received PUBLISH from 48:e1:xx:xx:xx:xx (d0, q1, r0, m4, '/appliance/2208022697555151xxx/publish', ... (787 bytes)) 1668428397: Sending PUBACK to 48:e1:xx:xx:xx:xx (m4, rc0) 1668428402: Received PUBLISH from 48:e1:xx:xx:xx:xx (d0, q1, r0, m5, '/appliance/2208022697555151xxx/publish', ... (788 bytes)) 1668428402: Sending PUBACK to 48:e1:xx:xx:xx:xx (m5, rc0) 1668428407: Received PUBLISH from 48:e1:xx:xx:xx:xx (d0, q1, r0, m6, '/appliance/2208022697555151xxx/publish', ... (788 bytes)) 1668428407: Sending PUBACK to 48:e1:xx:xx:xx:xx (m6, rc0) 1668428412: Received DISCONNECT from 48:e1:xx:xx:xx:xx 1668428412: Client 48:e1:xx:xx:xx:xx disconnected.
This is repeated every 10 secs or so.
The funny thing even switches on/off with the meross_control script if I issue it quick in between connected and disconnected. But the led keeps blinking green, so it looks as if the device waits for something to happen and then disconnects unsatisfied. Maybe Meross added some extras in the latest firmware update.
I'm a little out of ideas, how this could be solved.
psmatter
commented
1 year ago I got me an older mosquitto to rule out a possible version issue, but that didnt change anything. What I found is a payload debug update available for 1.5.3 that at least seems to answer the issue:
1668458434: Received PUBLISH from 48:e1:xx:xx:xx:xx (d0, q1, r0, m3, '/appliance/2208022697555151200/publish', ... (389 bytes)) 1668458434: > payload: '{"header":{"messageId":"395c969c754cf981f9150a4315c458f4","namespace":"Appliance.System.Report","method":"PUSH","payloadVersion":1,"from":"/appliance/2208022697555151200/publish","uuid":"2208022697555151200","timestamp":1668458434,"timestampMs":752,"sign":"66e569a8e41f5c817e2a0"},"payload":{"report":[{"type":"1","value":"1","timestamp":1668458434}]}}' 1668458434: Sending PUBACK to 48:e1:xx:xx:xx:xx (Mid: 3) 1668458434: Received PUBLISH from 48:e1:xx:xx:xx:xx (d0, q1, r0, m4, '/appliance/2208022697555151200/publish', ... (788 bytes)) 1668458434: > payload: '{"header":{"messageId":"074a8b92fc2c48b7f5abdd20f19b41a5","namespace":"Appliance.Control.Bind","method":"SET","payloadVersion":1,"from":"/appliance/2208022697555151200/subscribe","uuid":"2208022697555151200","timestamp":1668458434,"timestampMs":796,"sign":"4870dc1d299743fa7314"},"payload":{"bind":{"bindTime":1668458434,"time":{"timestamp":1668458434,"timezone":"","timeRule":[]},"hardware":{"type":"mss210","subType":"un","version":"7.0.0","chipType":"rtl8710cm"," 1668458434: Sending PUBACK to 48:e1:xx:xx:xx:xx (Mid: 4)
The device seems to report the current switch status with the first pub, then 3 bind messages, then disconnects. So I guess this in fact is the new firmware, expecting a bind answer that does not come.
bmizuhara
commented
1 year ago Thank you for your extensive analyses. Yes, I agree with you that network/configuration problems are very unlikely because the device has successfully connected/subscribed/published to the mosquitto server.
The device seems to report the current switch status with the first pub, then 3 bind messages, then disconnects. So I guess this in fact is the new firmware, expecting a bind answer that does not come.
I think you're right. Meross would have changed their protocol to require proprietary handshaking between the server and the client. I did some internet search but couldn't find any article referring to this problem. So please be patient, as it would require laborious network sniffing and/or reverse engineering to resolve this issue.
Thank you again for reporting this important matter.
psmatter
commented
1 year ago No sweat, I have to thank you for getting me on track with mqtt.
I reconnected the device to the meross cloud and running the MerossIot sniffer I got:
{'header': {'messageId': '6be2ec1fcd6264fb893008d66af6ef67', 'namespace': 'Appliance.System.Online', 'timestamp': 1668536788, 'triggerSrc': 'CloudOnline', 'payloadVersion': 1, 'method': 'PUSH', 'sign': 'c58f950da17980b85c3dbd5d063dbfdc', 'from': '/appliance/22080226975551xxxxxxxx/publish'}, 'payload': {'online': {'status': 1}}}
The message showed up when I plugged the device out and back into the socket.
I played a bit with meross_control and sent a message
{"header":{"messageId":"08843e815100d364d51d390fa63bc245","namespace":"Appliance.System.Online","timestamp":1668549132,"triggerSrc":"CloudOnline","payloadVersion":1,"method":"SET","sign":"4433b3b8854b770fb26f9246d2c4c8b2","from":"/appliance/2208022697555151xxxxxxxx/publish"},"payload":{"online":{"status":1}}}
the device answered:
{"header":{"messageId":"9cc3684e5904691c265df07d072557e3","namespace":"Appliance.System.Report","method":"PUSH","payloadVersion":1,"from":"/appliance/2208022697555151xxxxxxxx/publish","uuid":"2208022697555151xxxxxxxx","timestamp":1668549141,"timestampMs":732,"sign":"89055f54860226797ab3f35184655d39"},"payload":{"report":[{"type":"1","value":"0","timestamp":1668549141}]}}
Well, thats where I currently am.
psmatter
commented
1 year ago Ok, I guess I got it working.
The MS210 with firmware 7.2.15 indeed does no longer pair a local mqtt just by subscribing.
The message it awaits can be sent with a modified meross_control script, just set namespace: Appliance.Control.Bind method: SETACK from: /cloud/hook/subscribe payload: bind_ack
After receiving the message, the led turns to constant green (or off, depending on the switches state) and the switches pings show up in the mosquitto log. Using the meross_control script, the switch can be toggled on and off.
I am not sure if the payload really is needed, an empty payload might work as well, was too lazy to redo the switches setup and test that. On setup I have set a key, maybe it also works with empty key.
The credits for the solution go to albertogeniola, I by chance found the sequence in his ha-meross-local-broker code.
Thank you again for your very instructive Howto!
bmizuhara
commented
1 year ago Thank you, you are very smart!
Based on your suggestion and what I skimmed off from albertogeniola's code, I have added a new file to the repository, meross_bind, which specifically sends the message you described. I have tested this script, which seems to be sending a MQTT message as intended, but could not see whether a Meross device with newer firmware would accept it, as I do not have such devices at hand. If you could look into this when you have time to spare, I would greatly appreciate it.
Thank you very much for your step by step guide to get a local connection to the meross switch, it did help a lot.
Steps 1-9 worked like expected, but in step 10 the switch dialed into the mosquitto service, sent its subscribe message but did not accept the SUBACK from mosquitto, so the light keeps to flash green and the switch continuously sends its subscribe and publish messages.
Any idea what the issue may be?