Add support for Meross lights (like the MSL120B)

[almico]

I have a Meross light bulb model MSL120B. It is not automatically detected by your component. This is the message it publishes when powered on:

{
    "header": {
        "messageId": "78d740c90859d05fc18036e7fb9e6c75",
        "namespace": "Appliance.Control.Light",
        "method": "PUSH",
        "payloadVersion": 1,
        "from": "/appliance/1912126573785090806548e1e9131505/publish",
        "timestamp": 1616667203,
        "timestampMs": 450,
        "sign": "71d77e14018753b9de7a1e055d626e2f"
    },
    "payload": {
        "light": {
            "onoff": 1,
            "capacity": 6,
            "channel": 0,
            "rgb": 16753920,
            "temperature": 100,
            "luminance": 100,
            "transform": 0
        }
    }
}

[sushiat]

Too bad your msl120b wasn't cooperating, got one of my mss310 switches working perfectly, but I have those msl120b's all over my house and whish they too could have the same response time to switching on/off. The current delay from the cloud version is truly annoying.

[krahabb]

Hello @markuskorbel ! To be honest I would expect the MSL120 are working with the current iteration since they shouldnt be that different from the msl100 which I tested and were working nicely. My implementation supports the color handling feature from HA so it could just be there. Sadly @almico couldnt confirm they were working but I don't know if that was an issue with the mqtt environment or other. If you want to give it a try and pair one of yours with a local mqtt we could have a final answer on the topic :)

[sushiat]

I did, the light connected to the Wifi correctly, I could see it's identifier showing up in the mqtt log but it never showed up in HA. And it kept "resetting/disconnecting" every half minute or so, quickly dimming down and back up. I currently moved the light back to the cloud solution but managed to find the conversation in the docker logs of mosquitto which I will attach.

msl120b.txt

[krahabb]

Thank you for your effort, It seems the light and the integration (through HA) start a conversation. That should be the part of the discovery procedure managed by meross_lan. Then, somehow, the light disconnects...I guess I'll reorder one to finally resolve this Keep in touch!

[sushiat]

Is there a more detailed log I can capture that might help you without ordering one?

[krahabb]

You could try enabling debug logging for meross_lan in HA:

Add this entry to configuration.yaml

logger:
  default: info
  logs:
    custom_components.meross_lan: debug

and then cut/copy the relevant section from HA log. It should dump the (almost) detailed handshake I suggest you to temporarily disable the other meross_lan config entries else it will overflow a bit...

Thank you for trying!

[sushiat]

Ok performed those changes but there isn't mutch more detail in there:

2021-05-22 14:39:00 DEBUG (MainThread) [custom_components.meross_lan] MerossApi: MQTT RECV device_id:(1912125898290790806548e1e9130e44) method:(PUSH) namespace:(Appliance.System.Report) 2021-05-22 14:39:00 DEBUG (MainThread) [custom_components.meross_lan] MerossApi: MQTT SEND device_id:(1912125898290790806548e1e9130e44) method:(GET) namespace:(Appliance.System.All) 2021-05-22 14:39:00 DEBUG (MainThread) [custom_components.meross_lan] MerossApi: MQTT RECV device_id:(1912125898290790806548e1e9130e44) method:(PUSH) namespace:(Appliance.Control.Bind)

Those three log messages then repeat every 20 seconds

[krahabb]

Well, it looks more or less the same behaviour as mine (the one I sent back since I thought it was bugged). At the time there was no way to get the bulb reply to 'Appliance.System.All' which is the first message needed to setup the configuration. Here, meross_lan sends the 'GET' for 'Appliance.System.All' but only receives unsolicited 'PUSH' for '..Report' and other misc messages. The strange part was that I was instead able to get correct responses by querying the bulb http interface from the command line

I'm developing on the msh300 (Meross Hub) right now and it was behaving the same initially. I paired it to my mqtt right out of the box without testing on meross cloud and the behaviour was like that. Then I've paired it with the Meross app to its own cloud services and now it works flawlessly (as a mock of course since I still have to implement part of the integration).

To be honest I am now implementing also the HTTP interface for the devices so there's a big upgrade coming to the integration: The idea is to have a kind of hybrid approach to communication in order to support different scenarios where you can have a private MQTT environment with devices unpaired and isolated from the cloud and a 'wild' one where you can talk HTTP to the devices without having to pair them to any private or meross mqtt service. In the end, if the need arise, users could let the devices work as 'per factory' with their own app and infrastructure but still being able to integrate them in HA through a local link talking directly HTTP to the devices. Of course this would result in a 'polling' behaviour but I think there's enough room to make it useful for someone. Also, and that's the important part, if you're in the mood to clone the 'dev' branch, we could try talk directly HTTP to the bulb and see if there's an improvement (like I said the code is there, just ...the bulb doesn't answer my requests over mqtt)

Tell me if you're up to try it so I cleanup a bit and commit the current working set to github 'dev'

[alesurli]

I did, the light connected to the Wifi correctly, I could see it's identifier showing up in the mqtt log but it never showed up in HA. And it kept "resetting/disconnecting" every half minute or so, quickly dimming down and back up. I currently moved the light back to the cloud solution but managed to find the conversation in the docker logs of mosquitto which I will attach.

msl120b.txt

Same issue here, instead ms310 connects flawlessly.

Both devices appears correctly in MQTT broker:

[krahabb]

Yeah, I guess I've finally figured out what the issue is, at least the hidden reason behind: I have some new devices which I'm currently working on and they experience the same behaviour when I send them a 'malformed' packet (like incorrect spell or missing keys and so on). When this happens the device firmware behave like it's crashing in software and so it reboots the device. So this is probably happening with the MSL120B. The unexpected behaviour is that the MSL120B crashes right on discovery where other devices with the same supposedly malformed packets are working right. I will try to investigate online if there's a better description of meross packets syntax but in the end I've already programmed a purchase of the MSL120B so to have real testing and not guesses and hopefully fix this. Like I said, while I'm currently working on the code, there's a lot of development going on so I can't say this will be a 'quick' fix (unless it is really quick when I'll receive the new bulbs) Thank you for reporting this. I hope you'll enjoy the functioning part at least :)

[alesurli]

Thank you! The functioning part is perfect :)

[krahabb]

Hello @almico, The new release (Rebirth) with working MSL120 is 'online' so I'm closing this down (hopefully and finally!) I can confirm the MSL120 was rebooting after receiving my packets due to a missing header field (which instead was not an issue for other appliances). For the techies out there the field was the 'from' one which in turn is used from the device as the topic needed to publish mqtt responses (other devices instead use a default one when this field is missing)

Thank you

[sushiat]

Hi @krahabb, I can confirm that the msl120b in my office is connecting to my mqtt broker successfully now, but the control from ha is still not working 100%. After powering the lightbulb it will grab an IP and report in. I can then turn it off and on again fine. But if I want to turn it off again, it sends the requests but nothing happens and 2 seconds later the toggle button in ha just jumps back to on. I can adjust the brigthness or rgb color as often as I want and it works perfect but off seems bugged, turning on seems to work fine. Also (not sure if might point you towards the problem) I noticed it will react to a "turn off" command correctly if I change the brightness first.

I can see these entries in the log when trying to turn the light off: 2021-06-27 20:58:16 DEBUG (MainThread) [custom_components.meross_lan] MerossApi: MQTT SEND device_id:(1912125898290790806548e1e9130e44) method:(SET) namespace:(Appliance.Control.Light) 2021-06-27 20:58:16 DEBUG (MainThread) [custom_components.meross_lan] MerossApi: MQTT RECV device_id:(1912125898290790806548e1e9130e44) method:(SETACK) namespace:(Appliance.Control.Light) 2021-06-27 20:58:18 DEBUG (MainThread) [custom_components.meross_lan] MerossApi: MQTT RECV device_id:(1912125898290790806548e1e9130e44) method:(PUSH) namespace:(Appliance.Control.Light)

[krahabb]

Hello @markuskorbel , I noticed the same behaviour when I was testing it and thought it was my mouse 'double clicking' and just discarded that as a glitch. I've retested and it happens sometimes but it looks a bit 'subtle' and I still haven't figured out the problem. I'm guessing the status gets sometimes updated too soon and the UI reacts a bit inconsistently. Working on it anyway

[sushiat]

Awesome thank you for digging back into this. The not turning off is actually pretty consistently not happening for me, doesn't matter if I click on the UI or the light switch triggers the automation doing the toggle.

[krahabb]

Thank your @markuskorbel for replying, To be honest, my fix is just a guess about how HA behaves in-between status updates. Further testing showed me that sometimes the device (or the http protocol stack in somewhere) doesnt complete the command transaction reporting a timeout error in the communication and the HA status is not updated correctly. I'll keep an eye on this since, even though this happens quite rarely it happens and could be annoying.

[almico]

I see no control. I tried to remove and add again, but same result:

[almico]

If I need to reset something to start "from scratch", please point me at some document, or tell me what to do, and I will do. I put up a test NUC for this, thus I can do virtually any test with little harm 😄

[almico]

After upgrading to "core-2021.6.6", things looked much better:

Might there be some minimum "core" requirement? By the way: I can confirm I am unable to turn it off.

I also noticed that if I set brightness to 1 (the minimum value, I guess) and change the temperature between the highlighted two values, the light goes first into an intermediate color / temperature and then switches to the requested one. I don't know if this is an internal behaviour of the lamp or if it's due to your handler.

A huge leap forward, anyway, compared to a few weeks ago. Well done!

[krahabb]

Hey @almico, yeah, the last couple of versions, beside requiring HA 2020.0.0 and on (which doesnt even exist!) were not really 'past-proof' so they were just working only on a recent code base (probably around april-may). I've now reverted a bit of code to be more 'compliant' but also updated the HACS manifest to require 2021.4.0 so..to be sure...

Regarding the 'glitches' when you set brightness, temp or color they are known to me but there is nothing coming to my mind in order to easily solve them at the moment: they are probably due to the UI refreshing while some state updates are occurring and so it might happen you see the UI jumping back and forth. It happens also when just switching the light: I see the toggle moving 'on' then 'off' and finally 'on' again. This might either depend on the protocol HTTP or MQTT (MQTT should be more graceful) because your UI actions are overlapping with state polling messages in the background (this is for HTTP mode for sure) I've started putting some 'software guards' here and there but things were really getting too complicated and I know complication is a big enemy of good and reliable code so I've reverted that back until I find a clearer explanation of things.

I hope the software is usable 'as is' without too many tweaks.

If something arises or comes to mind let me know so I can try improve

Thank You ;)

[almico]

@krahabb Is the inability to switch off something you are currently investigating or did I miss anything. In my setup, I am unable to turn off the bulb 😢

[krahabb]

That's bad :( ! I'm sorry for that but at the moment I don't find anything preventing the switching and color/temp settings from working. It is just a bit glitchy here and there and, like I said, I'll see if I can find a more robust message management in order to reduce or even defeat this behaviour. I don't think I can really solve it very soon. If any, and you are using 2.0.2, try to collect a trace of your bulb interactions by activating the 'debug trace' feature in the bulb integration configuration. It will dump all of the message exchange for like 10 minutes (or maximum 64Kb of data). After that it will stop collecting data and you'll find the trace under 'custom_components/meross_lan/traces'. After activating the tracing try to use the bulb: on, off, set color/temp/brightness

Then send me the trace and I'll see what's happening.

[sushiat]

Tried switching a couple of times, didn't work on it's own. Then changed brightness, switched off fine, switching on always works. Then also tried color temperature, that also worked for turning it off. But when just turning it on, doing no other changes then it simply doesn't turn off. Not sure if a brightness/color temp change first sets/resets something in the bulb that then allows the switch off to work.

msl120b-1912125898290790806548e1e9130e44.zip

[krahabb]

Thank you @markuskorbel , Your trace point me to a surprising discovery. Somehow my msl120j is 'a bit' different in payload structure so I couldn't find out some inconsistencies. I've now identified the issue in (not) turning off and will fix this soon. I don't know if this is related to the fw version (mine is msl120j fw 3.1.4) or the specific different 'flavour' between msl120b and msl120j but that's it

I guess this is the same as @almico issue and hope to (finally) solve this

[sushiat]

Awesome news, thank you so much for all your work. Can't wait to finally fully move all those meross devices over to your integration and finally clean up my home assistant instance :)

[almico]

@krahabb it really seems to work now! I can deterministically and reliably turn on and off the light. Well done! ❤️

[almico]

By the way: is there a way to change the speed with which the light turns off? Is it something that is / can be in the message you send to the bulb, or something in HA?

[krahabb]

@almico There's an undocumented field I could try and use to see if any light transition works but that would be total-guess-reverse-engineering and I don't see having the time at the moment (unless somehow it works at the first try one of these nights). I anyone out there (!) has some clues that would be much appreciated! (and speed up things a lot)

[krahabb]

Anyway: history says my msl120j to test is slightly different from your(s) msl120b so I could end up in something working for me and not in the field (as usual)

We'll see ;)

[sushiat]

Hi @krahabb, finally had some spare time this morning and reprogrammed all my light bulbs and switches to your plugin and I'm happy to report that everything is working perfect. Thanks again so much for your work, deleting meross cloud integration as I'm writing this :)

Also looking forward to test the MSS420F multi power strip I just ordered for the fishtank when it comes in to check if there is any differences to the model you already list as supported.

But if @almico doesn't object, I think you can finally close this issue for good 👍

[krahabb]

Thank you @markuskorbel , I'll keep this open as a 'superstitious' way to keep the lights 'on' for the coming days but yeah