Meros MRS100 NOCLOUD/local only setup

[hkuehl]

Hey there!

I want to share my setup here since I have not explicitly read about it in any of the given docs.

Meross devices that I have: MRS100 Shutter/Blind Switches only, 14 in total.

How I added them to my HomeKit-based setup:

• When device was brand new, added the device to HomeKit using the QR-Code printed on the device
• Right after that, blocked any internet traffic from the device

This setup seems to work well AT FIRST, but the devices go into unresponsive state after some random time (sometimes days, RNG FTW!). So I did this to avoid that:

• Reconfigure them using the Meross-CLI-tools to connect to my own MQTT-broker that is reachable on mqtt.meross.com

There was one thing that I was still missing which is switching off the light (DND-mode) for some of them and I completed that just today! After installing meross_lan and adding the devices without using a device key, I was able to successfully turn the lights off where needed.

I did not use the Meross-App in any step.

Things that might be nice to have:

• Firmware updates
• Re-establish liveness after power outage (after a power outage the HomeKit-state of the devices is in limbo, you just need to touch them in the app once and then it works again)

[krahabb]

Hello @hkuehl,
Thank you for your contribution!
I'll add my knowledge and considerations especially pointing at what I'm working on for meross_lan at the moment:

• once the devices are paired by HomeKit, I guess (this is actually based off what was happening here Cannot pair MSS315 via MQTT #346) they are in a state where they are reachable on the LAN and they are binded 'in some limbo' to the Meross brokers.
• totally blocking outbound traffic works good as the devices are still reachable over LAN (homekit works locally - meross_lan too would use local HTTP) but, out of homekit (which I don't know), you'd need a device key to actually talk to them over HTTP. This is what meross_lan usually do (so, in this state, you could already configure the device in meross_lan if you know the key and the ip address) and this is also the protocol used by the @bytespider utils.
• Using @bytespider utils you basically change the brokers (from cloud to your preferred local one) and the device key (by default the utility sets to "" (empty) the key when reconfiguring the device.
• Once the device is binded to the same HA broker meross_lan starts discovering the device and helps you out (provided the key was empty else you'd need to provide the right key to meross_lan in order to proceed)

What's next (development right now)

• meross_lan will be able to to re-bind a device without the need of the @bytespider utils (actually, the same logic used in the utils will be embedded in meross_lan) - again, you'll need the device key (or add the configuration for your Meross account to meross_lan so it recovers the key for you) to actually be able to talk to the device.
• the firmware updates, through my researches which might be partial for sure, are only 'available', i.e. known, by querying some Meross api. To query this api you need a Meross account. Also, this api, only provides the list of updates for the devices you own in your Meross account (this implies that in order to know if an update is available you have to bind the device to your Meross account, at least temporarily). This feature is already embedded in meross_lan when you configure a Meross account. The actual level of implementation anyway is only notifying you when an update is available by querying the aforementioned api. I didn't get beyond this point since my devices never had an update since then so I cannot test the process. Also, the fw update process is not documented so it is a 'risky business' you know, messing with firmware updates. Nevertheless, this is still an open feature work.
• "Re-establish liveness after power outage.." this will need to be better inspected by testing the device connections available when in this state since nobody (?) knows what is happening there. So, we need you or someone else experiencing this behavior to tinker into what is happening to the device at the network level: a lot of work maybe!