HTTP vs MQTT

Why this question and what does it mean for Meross devices and meross_lan being able to talk either protocol?

First of all, the initial implementation of meross_lan was based on the MQTT reverse enginered protocol and allowed the integration to work only on 'unofficially re-paired' devices. This was obvious in the beginning since I wanted to detach the devices from the cloud and being able to control them without any external (cloud) compromise. This was though tho because setting up MQTT for these proved to be an adventure of its own. Like reported in this wiki and in many other threads, there were (and there are), a lot of little issues to overcome in order to put everything together. So I've learned the devices were detectable and queriable also on HTTP (they provide a standard HTTP API). This is the very same interface the official Meross App and any other 're-pairing' tool uses to intially configure the device. This HTTP endpoint, nevertheless, exposes the same protocol/api as the normal MQTT endpoint so I thinked to put this at use: Why not using it to control the devices instead of going through MQTT? And it worked!

Soon this option gained 'traction' in my todo-list since it could have allowed meross_lan to talk to the devices without the need of any re-pair or so. After the first experiments I learned that I could control the devices together 'side-by-side' with the Meross app. I just needed the ip address of the device on my LAN in order to gain control of it (more on this later).

So now we have these two options: HTTP vs MQTT. Which is better and why should I care? Like I've said meross_lan supoorts both and tries its best to use any. When it detects a relevant DHCP broadcast from a Meross device or when you configure the integration by host address/name, it tries to connect via HTTP to the device and communicate with it. This has some advantages over MQTT:

• speed: the message exchange is direct (no hops through a lazy broker)
• easy configuration: no MQTT config pain, no device pairing, nothing
• no key needed: if you look through the protocol documentation you see you need a 'key' in order to properly communicate with a device. This key is used to sign the message exchange and if you don't know it (it is configured into the device when you pair it) you can't control the device. The Meross HTTP protocol implementation is 'faulty' and leave us an hole through which we can fool/hack a device without knowing the key. This is not true (to my knowledge) for MQTT. In my attempts I've never been able to fool them
• 'side-by-side' behaviour with official Meross App. This could be good/bad it depends, but if you like the official app and want to keep using it you can. Of course you're still on the Meross cloud : it just adds up
• resiliency (compared to MQTT): when the broker fails (or shutdowns on purpose) you don't 'loose' your devices since you only need your LAN infrastructure to communicate

Now to the befits of MQTT:

• push behaviour: when something happens on the device the broker (and HA) get instantly notified so you know of a state change when it happens (maybe 1-2 seconds later). On HTTP the integration works by periodically polling the device state
• naming/addressing independence: in order to talk via HTTP we need to know the device address. If the address changes or name resolution fails (why not?) you can't contact the device anymore. On MQTT the integration doesn't have to bother: the device presents itself whatever its address is

So in the end: which is better? Let meross_lan decide. In the integration configuration there is a field which instructs meross_lan to use HTTP or MQTT or...both. By default it's empty (the same as AUTO) which means meross_lan will use the 'best' available transport every time.

• If a device was discovered by DHCP or manually entered via host address it tries to use HTTP all the time but will also listen for MQTT messages so it will get 'push updates': the best of the two worlds (of course you have to pair your devices to your broker too, else 'no push'). Also, when the integration receives any MQTT message related to the device, it starts skipping polling update requests (saving bandwidth and computation) since it knows the updates will come by themselves and will eventually start talking MQTT itself should the HTTP protocol transaction fail.
• If a device was discovered by meross_lan internal MQTT handler the integration will try all the time to use MQTT. When the MQTT flow timeouts for some reason it will then switch to HTTP using the last known ip address of the device (this is always cached internally by the integration)

So everything's good at least on paper and in my mind: of course the logic behind this might fail beacuse of bugs or unforeseen behaviours so you might start having inconsistent 'bugs'. When this happens try to maybe force the protocol and see if it stabilizes. Also to note: HTTP works generally best but presents a lot of 'connection timeouts' at least in my development sessions. You might not see this if you're in an hybrid scenario since the protocol failover is hiding the issue.