-
Notifications
You must be signed in to change notification settings - Fork 52
Meross LAN details
Some useful infos on the way meross_lan works for some specific features. This is of course a work in progress and this page is just a quick summary of some 'special' behaviors to take care of when using this integration.
meross_lan used to be a 'local only' integration preventing any cloud connection by just using HTTP to connect directly your devices in LAN or MQTT to a private broker. Starting with version 4.0.0 (Cloudy), configuring a 'Meross cloud profile', suddenly enables MQTT communication to the Meross cloud brokers for your devices officially paired with the Meross app. I'm not going over any concern with this, everyone has it's opinion, but here are the features and options of this new behavior
- instant status updates for asynchronous events (switch toggles, garage opener and so on..)
- connection of remote devices (second home or wherever your devices are installed)
- synchronization of device names stored in your cloud profile (only Meross profile -> HA)
- increased device connection resiliency since it can now be reached in HTTP (LAN mode - default) and over cloud MQTT at the same time
When a cloud profile is configured and enabled meross_lan keeps defaulting to HTTP (if it works!) for any 'solicited' connection (commands, polls) and just listens for push updates over cloud MQTT. This should prevent cloud bans (by limiting cloud queries) or unneded WAN traffic. Beside the specific MQTT sessions for managing each device, meross_lan also queries the Meross cloud http api endpoints (once every 24 hours) in order to refresh it's own copy of the cloud profile info's (list of devices, names).
If you don't want Meross cloud traffic, just disable the cloud profile configuration entry (this is slightly better for meross_lan than totally removing the configuration since it allows some internal optimizations) or delete it. Both of these will 'shutdown' the meross cloud features and so prevent any outbound traffic.
Or, you can decide you still want the cloud discovery and profile synchronization working, but you don't want to use cloud MQTT (no instant pushes, no protocol failover) and you can force this at the device configuration level by forcing the protocol use to HTTP
This is a light entity representing what Meross calls 'DND' (do not disturb) in its implementation and usually represents a visual hint on the device (like a sort of 'presence' light) about its own state. On plugs for example, you can enable this light in order to see the state of the plug (on/off, connecting, etc) or disable it if it annoys you in the dark. This entity is marked as a 'configuration entity' in HA terms and is by default visible in the device page in HA UI. If you want to access it in your lovelace cards you have to manually add it.
This (diagnostic) sensor is available for every meross wifi device and could be accessed on the device page. It is refreshed every 5 minutes.
This is a diagnostic sensor (disabled by default) useful if you want to see the actual connection state of the device i.e. if it is using MQTT or HTTP to communicate (or nothing when disconnected) and the state of the underlying services exposed as attributes. You can find it in the device page and eventually enable it if you want to 'inspect' what is going on.
Some Meross plugs are able to measure the energy consumption (Wh or kWh) of the appliances connected and this value is internally reset every day. What you usually see on the official app might be longer term statistics (weekly-monthly-or so) but the device itself (at least at the current level of knowledge/implementation) just reports daily reset consumptions. It also carries a short history (about 1 month) of the last daily consumption values which meross_lan ignores.
In actual implementation (but also since the beginning) this daily value is provided to HA which in turn, knowing its an energy entity, allows you to build any kind of statistics 'the HA way' and so allows you to get long-term values, if you wish, by leveraging these features.
The device itself provides Wh readings but now you can change the unit from HA too (be careful about this HA feature since changing the unit of measure, at the moment, doesnt 'convert' past values in history and statistics so you're going to invalidate all of your historic data should you change this).
Another 'good-to-know' behavior, is that the device resets its daily reading and so starts a 'new day' at the midnight in device local time. This could 'disalign' the energy reading on your device (a kind of sawtooth depending on your power usage) from the expected pattern of the reset happening at midnight in HA local time. This has no big effect on long term statistics the way HA computes that but still you might end up reading a daily value which is not what you expect. Of course you're likely to have configured the local time of the device the same as your HA instance and where you live but still...good-to-know.
Up until meross_lan version 'Lazy.3' (3.0.3) this daily value exposed to HA was totally unprocessed in order to not bias the already complex behavior with the risk of subtle bugs but an issue in some device firmwares (issues #181 and #264 hard to detect though since it is very random) led me to decide to 'patch' the device readings a bit, hopefully for the best. This is an extract from the issue:
There are now 2 energy measures per device in meross_lan and they work as this:
- 'energy' (the legacy one): This sensor is just reporting the energy measure computed inside the device. This sensor, usually resets at midnight in device local time (this is important to know if you want to see the reset 'aligned' to HA local time midnight). HIstorically, meross_lan didn't process at all this reading so, the values reported in HA, were exactly the (last in time) values reported by the device with almost no 'data processing'. This has changed in Lazy.3 in order to fix the bug (in device firmware 2.1.4) reported on this issue. Now meross_lan tries to detect if the energy reset (which still occurs at device midnight local time) is 'reasonable' (it should always reset to 0 or 1 in a simple world but this is not true, actually depending on the average power consumption level during the update period, so, if you have a big consumption across midnight, the value starting the new day is not 0 but a bigger level). The fix then is trying to compute a reasonable value for the starting level and if it detects the device is not reporting a good value, meross_lan will offset the readings for the day (on next midnight it will compute the reset/offset again). This behavior (and the fact meross_lan is 'offsetting' readings) is inspectable in the sensor attributes: you will see an 'offset' attribute in case meross_lan is patching the value or nothing if the reading was 'good' at midnight and is not being patched. In the end you should always see a proper reset after midnight (always in device local time!) even for devices experiences this and maybe other accumulation/tripping bugs. This offset is persisted through reboots so, if you'll restart HA during the day, you should still see the sensor data 'patched' for the day. Important to note: meross_lan will detect the issue only at midnight tripping so it will not patch any value 'in the wild' when you re-start HA
- 'energy_estimate' (new sensor in Lazy.3): While working on the fix, I've found it reasonable to provide a 'completely new' sensor reporting energy in a different way. This sensor is implemented in meross_lan and is not reporting energy computed in the device. It just provides an integral (trapezoidal) sum of power readings (something you could even implement with templates or with https://www.home-assistant.io/integrations/integration/). This sensor is initially disabled to not clutter your UI and HA with an almost duplicated sensor but you could easily put it at work should you prefer it over the legacy one. Check the pros-cons for hints on deciding
Details
-
- provides almost native values computed in hw (should be very accurate)
- as far as the device is powered it measures energy even if not connected to HA (so you don't lose data should you have HA offline or any connection issue)
- resets at device midnight local time
- even if unusual it sometimes fails because of firmware bugs (not always 'patchable' at meross_lan level)
- on HA restarts, if meross_lan was offsetting (this happens when the device 'bugs' its correct midnight reset) the data for the day, it will try keep (restore) the patch offset for the day
-
- it is slightly less accurate since it estimates energy only on power sampling (which happens every 30 sec by default) by HA/meross_lan
- if HA is not running it doesnt measure (so you lose data)
- it resets at midnight HA local time
- doesnt suffer any device firmware bug (unless power readings are bugged!) and you can always blame me for any inconsistency. Any bug, being in meross_lan, could be fixed
- on HA restarts it restores its previous reading for the day and re-starts accumulating energy (so you just lose energy consumed while offline)
This feature appears starting from Moonlight version (v5.0.0) and could be seen as a very powerful tool in helping identifying the device behavior for new (still unsupported) features. In order to understand how it works, a little explanation of the overall Meross protocol architecture is due:
device features, like toggling a switch on/off, reading a temperature, or setting a configuration parameter for example, are each exposed through a dedicated 'message namespace' which has its own protocol fields and semantics. When coding for a particular function in meross_lan (like toggling a switch) we have to use correctly the related namespace and encode/decode the message for the purpose. Now, all of the features actually managed and exposed by meross_lan work this way but, over the time, Meross has added new features (for completely new devices or enriched the existing ones) which have been, over time, inspected, understood, and then implemented in the component. In order to understand how these new features work the 'diagnostic tracing' was invaluable since it was (and still is) able to query any new device/feature and report it in the trace file providing hints on the type of data carried through the protocol.
The 'Diagnostic entities' brings the tracing feature (i.e. the ability to query the device for unknown/new namespace messages) to a new level where the component is able to actually map these unknown new messages to (sensor) entity values in the HA UI so that these informations are available at hand without the need to inspect the trace file. Moreover, these are actual sensors, regularly updated, which, beside their name (which just represents the low level naming used by Meross for the data), are readily available for use.
For example, if we have an hypothetic new device featuring a light sensor (or whatever physical measurement), the 'diagnostic entities', once enabled, will show a corresponding sensor value (with no unit of measure or any other info since meross_lan is unaware of the semantics) which could be already used in automations or any other custom feature in HA as if it was a real measure (since, it is in the end!) without the need to wait for a patch implementing the new feature support.
Diagnostic entities are now only sensors, i.e. you can't expect to 'toggle' them or use any other high level predicate to operate since at the moment, there's no way to know which feature is 'behind the numbers'. Some euristics might come in future releases in order to maybe figure out 'diagnostic switches' or so but, right now, you'll just see the values as reported by the device.
In order to enable diagnostic entities, you have to hit the 'CONFIGURE' button for the device in the meross_lan integration page and select the 'Diagnostics' menu. Here, among all other options you'll see a check where you can enable/disable the creation of these entities for the device.
Keep in mind, the diagnostic entities are only created for namespace messages which are not currently decoded/implemented (i.e. they are 'new') and for which, the device tracing euristics are able to query those new namespaces (these might fail for whatever reason since they work based off the rules learned in these years of Meross protocol reverse engineering)