Releases: krahabb/meross_lan
Cloudy.4.alpha.1
Maintenance/bugfix release for some pending issues
features
- initial (experimental) implementation of 'OverTemp' feature for newer smart switches
- improving timezone/daylight saving time configuration for locally mqtt paired devices (Thus trying to fix #300)
- recognize RollerShutter fw ver 6.6.6 as providing a valid native position (#319)
fixes
Cloudy.4.alpha.0
Maintenance/bugfix release for some pending issues
features
- removed warning on received signature error
- add calibration for MTS200 (experimental)
- add support for MTS200 Summer Mode (#323) (experimental)
- while implementing new HVAC cooling mode for MTS200, also MTS100 were a bit refactored (dropped HVAC auto mode - use preset instead)
- reload/reinit device configuration after detecting a firmware update
fixes
Cloudy.3
This release is mainly a maintenance with some fixes before HA core 2023.8 and some minor improvements here and there.
features
- add an option (user configurable) to the Meross cloud profile to inquire for devices firmware updates. This feature does not allow you to start the firmware update from HA/meross_lan but will just popup an HA-style update entity notifying you an update is available
fixes
- a possible incompatibility (breaking bug! - #304) incoming with HA core 2023.8. Many users on beta experienced this issue which is 'simply' preventing
meross_lanfrom working. - improved the management of the garage door opener open/close timeout entities (#301). The solution here is still not complete since I'm still missing 'real-life' field data in order to correctly manage the newer garage door firmwares (diagnostics welcome!). Still, a little improvement on actual behavior.
- improved the management of unknown (new releases) devices paired with the MSH100 Hub in order to provide at least a basic behavior (#303)
Cloudy.2
This release is a major refinement over the cloud MQTT protocol management in order to reduce even further the risk of Meross account ban due to 'wild' cloud usage
Release Cloudy.1 did the major step by absolutely limiting the rate of outbound traffic. This new one adds an even harder option (disable cloud MQTT publish) to completely stop, for the sake of extra-safety, outbound cloud MQTT traffic.
This option should not impact normal usage since, in general, meross_lan uses local HTTP to send commands even when cloud available but there might be cases (when HTTP is failing 'too much') where the automatic protocol switching would try to use the cloud connection to reach the device. If you feel like you can 'loose' connection when HTTP is failing then this option will add you that extra safety against cloud bans. Nevertheless, inbound cloud traffic is still always available so the devices will 'instantly' update their status (this, of course, when the cloud profile connection is configured and active)
features
- Added a configuration option (in Meross cloud profile) to disable cloud MQTT publishing (thus allowing only incoming cloud traffic and reducing even more the risk of Meross account ban)
- Added an option to enable diagnostic sensors in Meross cloud profile: this will create 1 sensor for each cloud MQTT broker connection reporting some statistics
- Added 'cloud token expired auto-refresh' management by either saving the password in configuration (Cloud profile) or raising an HA issue/repair
- Increased details when logging signature errors (#286)
fixes
- doorWindow (MS200) sensor state not updating when using cloud MQTT profile (#281)
- fix an (unreported) issue when garageDoor is connected to MQTT (be it cloud or local). This issue could lead to an MQTT msg exponential 'explosion' (correctly limited/prevented by the Cloudy.1 rate limiter features but leading to inconsistent states reported in HA)
Cloudy.1
This release adds better cloud MQTT traffic management in order to reduce the risk of Meross cloud account 'ban'
It does so by 'absolutely' limiting the rate of outgoing MQTT messages to a maximum of no more than 1 every 12 seconds per MQTT broker.
This means that if your devices are all (or a group of) binded to the same public broker, they'll share the bandwidth together.
When a mesage is about to be sent, the timeout will be checked and if not expired, the message will be queued. Maximum number of messages in queue will be 6 currently, meaning the queue could grow to more than 1 minute in duration before being fully flushed.
If the HA/meross_lan environment keeps trying to push messages (like toggling or setting entities), those will be discarded (a warning will be logged if this happens).
The overall rate of outgoing messages has also been reduced when devices are only communicating over MQTT (that is when the device is not reachable via HTTP)
Here a full explanation on the Cloudy release
fixes
- Meross account ban #285
Cloudy
warning
Due to a user signaling 'ban' from Meross cloud I've actually reverted back this as a pre-release while further investigating the issue
This release, as the name implies, brings in Meross cloud connection for your devices paired with the factory app.
This will give you:
- automatic discovery of devices binded to your Meross account wherever they are (if you have devices here and there around the world binded to the same cloud account)
- communication (via official Meross cloud mqtt brokers) to any device (not only local LAN then..despite the
meross_lanname, that is..) - instant updates of device state since this will come through MQTT (no more waiting polling cycles to see your toggle state updates)
- synchronization of the device name from the cloud (what you configure in Meross app will be 'copied' over to HA)
- ability to add more than 1 Meross cloud profile (so if it happens you want to connect and control devices binded to different Meross accounts you can do so from the same HA instance)
These new features will work in addition to the existing ones, so your devices will still be able to communicate over HTTP in LAN (this is actually enforced even for devices which are reachable over Meross cloud MQTT in order to reduce the need for outbound traffic)
Ideally, installing the update, your installation should work as usual with no differences until you complete the configuration of a 'cloud profile'. meross_lan could automatically guess your devices are Meross binded and suggest you to configure a cloud profile for these but that's only an helper and, even if it doesn't show up, you can manually add the configuration the usual way from the 'Integrations' page. Here, when you manually enter a new integration for meross_lan, a new menu will ask you if you want to manually add a device or a (cloud) profile.
Enter your account name (email) and password and save the configuration: this will be enough to activate all of the features.
Depending on many factors you could see no apparent change in your installation i.e. no discovery if all of your meross account devices are already setup in HA and no other UI changes (you could see the names of your devices being updated but if you've already customized the device name in HA this will 'win' over the 'native' device name. If you want to have HA show the cloud configured names you'll have to cancel the device name customization in HA UI)
Also, the cloud list of devices (to retrieve the names and to discover newly added devices) is polled once a day to reduce risk of cloud account banning due to high 'rate of requests'
You should see instead the devices state is now updated instantly in HA UI if you toggle them from the Meross app or on the physical appliance
This release, of course, is so new, many things could go wrong, even if deeply tested. Nevertheless, it is possible to revert back to the old stable Lazy at any time though. Just delete any 'profile configuration' from your integrations page if you plan to do so before downgrading since the old ones could mess a bit their configuration if they load a cloud profile.
Any comments or discussion is really welcome here!
warning
- A lot of backward compatibility code for HA cores back to 2022.1.0 (and earlier) has been removed: I didn't actually tested it but this version should be reasonably compatible with cores from 2022.5.0
features
- Meross cloud profile integration. Info here
- new Protocol sensor which reports the current state of connection i.e. it tells you if the device is 'actively' communicating over HTTP or MQTT.
- diagnostics were updated to support the cloud profile. Also the obfuscation logic was remanaged a bit (This would need a specific post to be explained)
- enriched support for smokealarm sensors (GS559) (#282 #183)
- basic support for doorwindow (MS200) (#281)
- added translation support for thermostat presets
fixes
Cloudy.alpha.2
Another step towards the new public release. The code for cloud profiles is now very stable and this release contains some fixes for current issues/discussions
warning
- A lot of backward compatibility code for HA cores back to 2022.1.0 (and earlier) has been removed: I didn't actually tested it but this version should be reasonably compatible with cores from 2022.5.0
features
- enriched support for smokealarm sensors (GS559) (#282 #183)
- basic support for doorwindow (MS200) (#281)
- added translation support for thermostat presets
fixes
Cloudy.alpha.0
Cloudy!
This release, as the name implies, brings in Meross cloud connection for your devices paired with the factory app.
This will give you:
- automatic discovery of devices binded to your Meross account wherever they are (if you have devices here and there around the world binded to the same cloud account)
- communication (via official Meross cloud mqtt brokers) to any device (not only local LAN then..despite the
meross_lanname, that is..) - instant updates of device state since this will come through MQTT (no more waiting polling cycles to see your toggle state updates)
- synchronization of the device name from the cloud (what you configure in Meross app will be 'copied' over to HA)
- ability to add more than 1 Meross cloud profile (so if it happens you want to connect and control devices binded to different Meross accounts you can do so from the same HA instance)
These new features will work in addition to the existing ones, so your devices will still be able to communicate over HTTP in LAN (this is actually enforced even for devices which are reachable over Meross cloud MQTT in order to reduce the need for outbound traffic)
Ideally, installing the update, your installation should work as usual with no differences until you complete the configuration of a 'cloud profile'. meross_lan could automatically guess your devices are Meross binded and suggest you to configure a cloud profile for these but that's only an helper and, even if it doesn't show up, you can manually add the configuration the usual way from the 'Integrations' page. Here, when you manually enter a new integration for meross_lan, a new menu will ask you if you want to manually add a device or a (cloud) profile.
Enter your account name (email) and password and save the configuration: this will be enough to activate all of the features.
Depending on many factors you could see no apparent change in your installation i.e. no discovery if all of your meross account devices are already setup in HA and no other UI changes (you could see the names of your devices being updated but if you've already customized the device name in HA this will 'win' over the 'native' device name. If you want to have HA show the cloud configured names you'll have to cancel the device name customization in HA UI)
Also, the cloud list of devices (to retrieve the names and to discover newly added devices) is polled once a day to reduce risk of cloud account banning due to high 'rate of requests'
You should see instead the devices state is now updated instantly in HA UI if you toggle them from the Meross app or on the physical appliance
This release, of course, is so new, many things could go wrong, even if deeply tested. Nevertheless, it is possible to revert back to the old stable Lazy at any time though. Just delete any 'profile configuration' from your integrations page if you plan to do so before downgrading since the old ones could mess a bit their configuration if they load a cloud profile.
Any comments or discussion is really welcome here!
other notably features
- There is a new 'diagnostic' sensor which is disabled by default and hidden from UI which reports the current state of connection i.e. it tells you if the device is 'actively' communicating over HTTP or MQTT and the state of the broker as attributes. You can find it in the device page and eventually enable it if you want to 'inspect' what is going on
- Diagnostics were updated to support the cloud profile. Also the obfuscation logic was remanaged a bit (This would need a specific post to be explained)
Lazy.4
Lazy.3
This is mainly a maintenance release fixing some known (and some less known) bugs and adding some news (both fixes and improvements) on the energy consumption sensor available on some plugs (mss310 and the likes)
features
- added an 'energy_estimate' sensor to devices reporting power consumption. This sensor computes the energy consumption (Wh) for the current day (it then resets at midnight in HA local time) by implementing the sum on the device measured actual power. This is different from the 'legacy' sensor in the fact that energy accumulation is done at the HA level in meross_lan and not in the device. This sensor is initially disabled on initial configuration so you'll not see that in the standard user UI. Check #264 (comment) for details
fixes
- MTS200 payload formatting (#259)
- energy consumption failing to reset at midnight (#264)
- a bug in polling which could increase the polling interval well over the configured value under some ciscumstances (after a device disconnection)
- various bugs in device de-initialization (they happen when HA stops or when you reload a configuration entry so they're usually no harm or hardly impacting any installation)
What's Changed
New Contributors
Full Changelog: v3.0.2...v3.0.3
