MSH300 support

[almico]

This is a sort of "documentation" issue. If I missed something, please forgive me 😃
I have an MSH300 with 4 MTS100v3 that are connected to the Meross cloud and app.
I just pulled the trigger and accepted your "Meross Lan" suggestion to add that newly discovered device. It then asked for an IP (that it automatically suggested, and I didn't touch it) and a "Device key". I left the "Device key" field empty. If this is the expected thing to do, I think that field should be hidden.

The question is: what can I do with the 4 MTS100v3 devices? Can I turn things on and off? Set target temperatures? Or is just for monitoring?

And how do things work? Since I didn't give your component any credential, I guess you can talk to the device, forcing it to do whatever you want. But... Will your commands force the MSH300 to access the cloud to execute your commands, or would everything work even if I disconnected the internet router?

Thank you 😃

[krahabb]

Hey @almico,
Thank you for reporting this: it gives me the option to explain a bit.

• The 'Device key' is something needed in order to correctly communicate with the device and is usually associated with your Meross account (i.e. every account has it's own device key which is then set on every device you pair using that account).
  This key is then used to 'sign' (no encryption just signing) every message so the device can check if you know the key and 'authenticate' you. If the signing is incorrect (because the key is wrong or whatelse) the device reject the message/command.
  So the field is required in configuration in order to communicate correctly.
  There is a trick anyway. The authentication system of the device can be 'fooled' so you can issue commands even without the correct key by just using a simple hack (I've tested it working only on HTTP while on MQTT the hack itself doesn't work as it is now)
  By leaving the configuration field empty in the integration you're instructing it to attempt an 'empty' key or the key hack. So it's up to you: you might want to enforce your infrastructure security (as per best practices) by ensuring you are communicating with a legitimate target device by setting (i.e. 'forcing') a device key in configuration. This way meross_lan will not attemp any 'hack' and will just be unable to communicate when an incorrect key is set (the protocol itself and my implementation by the way are easily 'foolable': I just check the received signing for diagnostic/adaptation purposes and accept anyway the messages)
  So, in the end, if your devices are paired to the Meross cloud they have a 'secret' key which you need to use (this is the way the popular merossIot library (and https://github.com/albertogeniola/meross-homeassistant) works: it uses your credentials to log in to the meross infrastructure and recover this key used to sign the messages beside other features. If you don't know your account devices key you're left with the 'hack' and so the field can be left empty.
• The MTS100v3: the following works per any device my library recognizes (so the valves too but everything else). When your devices are paired with the Meross cloud and you access them by HTTP on meross_lan the devices work at the same time with both: you can use the Meross app to issue command and see the state and meross_lan will report every update (with some delay due to the polling system inherent in the HTTP implementation). At the same time meross_lan can issue commands on the HTTP channel and the devices will follow as if they received a command from the meross infrastucture so it's like you have 2 controllers in place playing with the same device(s). So yes you can use the valves like in the app: turn on/off, set target temperature or working mode. Of course the app gives you plenty of features which are not implemented in meross_lan like setting a schedule or alarm or so but this is (almost) unneeded in HA since you can use HA itself with automations and scripts to do what the Meross app do. Of course, since the schedule set by the meross app is running on the device itself this gives less 'points of failure' and would be nice to have but I guess that's too much work in order to implement for something not really critical. In the end, if your devices are still 'officially' paired you have the meross app as a nice interface to all of these features.
• Following this: what happens when you have no internet or the meross servers are down (is it happening?). My integration is not using the meross infrastructure (cloud servers) so, as far as the device is reachable on your lan, HA would still be able to communicate and manage it

I guess I will sometime resort this info in a proper wiki but as you said this is the option to start some documentation on how this works.
Thank you

[almico]

Thank you so much for the detailed explanation, @krahabb ❤️
Two questions: how do I retrieve the device key for devices that are currently paired to Meross Cloud? And, is it correct if I say that your "trick" might be made unusable by a future firmware update?

[krahabb]

Hey @almico,

Here the 'tutorial' I've used in my initial testing and learning so I'm sure it works (at least a couple months ago!)
https://github.com/albertogeniola/MerossIot/wiki/HTTP-APIs.
This describes the official Meross HTTP endpoint used to login and retrieve essential information about your own account (or any account you know;)
By using the login API (with your account name and password) you'll be able to recover the device key used to sign communication with your devices

And yes, any firmware update could break the trick but also break any other feature if the update is 'incompatible' with any previous API. Of course the latter is unlikely to happen while a 'fix' for the protocol signing weakness might be reasonable and logical. I don't think that would really happen anyway though since that weakness (to my knowledge) is only exploitable over HTTP and that means local network access to the device which is generally not a real threat. But this is just an opinion and maybe I'm too optimistic