Preview release of the next Moonlight.

Some good features are coming like support for (new) devices encryption and better MTS960 management together with continuous improvement on message handling (trying to lessen some current issues).

features

• added support for LAN (HTTP) protocol encryption (#456 #430)
• improved management of MTS960 climates (#449)
• added support for humidity sensor in MTS200 (#459)
• added independent 'room temperature' sensor to all thermostats

fixes

• error in some timezones database parsing (using pytz)
• miscellaneous errors in unexpected payloads parsing/handling

fixes

• resolve a bug in namespace parsing likely affecting a wide range of devices (#439 - #457)

fixes

• configuration error when recovering cloud key (#448 #451)
• missing placeholder definition (Translation error #451)
• mrs100 KeyError (#447)

Quality improvement on recent Moonlight.1 expecially about new HA core compatibility issues. This release also ensures compatibility with HA core 2024.6 mqtt component which has seen some api refactoring so that previous meross_lan releases up to including Moonlight.1 (v5.1.0) are not working with local mqtt anymore.

features

• moved timezone loading code out of main thread (fixing some warnings from HA)
• optimized default polling (over HTTP) by reducing the size/number of requests (especially impacting Smart Hubs polling performance)

fixes

• garage door opening transition ending too quickly (#439 )
• error in light service invocation with temperature out of range (#440)
• custom entity name overwriting (#441)
• possible corruption in Smart Hub polling (possibly leading to missed states updates)
• error in pytz usage when re-configuring the device timezone
• fixed (severe) incompatibility with HA core 2024.6 mqtt component.
• fixed a possible issue during modules import ('circular import error') introduced in Moonlight.1 (trying to fix #427 #433)

Polished release over latest alpha. This also fixes an incoming incompatibility with HA core 2024.6.

features

• more refinements and improvements on polling.

fixes

• fixed (severe) incompatibility with HA core 2024.6 mqtt component.
• fixed a possible issue during modules import ('circular import error') introduced in Moonlight.1 (trying to fix #427 #433)

Experimental release with some deep refactoring/optimizations in polling behavior trying to reduce the amount of messages sent per polling cycle without compromising usability

features

• moved timezone loading code out of main thread (fixing some warnings from HA)
• optimized default polling (over HTTP) by reducing the size/number of requests (especially impacting Smart Hubs polling performance)

fixes

• garage door opening transition ending too quickly (#439 )
• error in light service invocation with temperature out of range (#440)
• custom entity name overwriting (#441)
• possible corruption in Smart Hub polling (possibly leading to missed states updates)
• error in pytz usage when re-configuring the device timezone

Major update to Moonlight release.

features

• added support for MSL320 (and the likes) light effects.
• added 'sw emulated' light transitions for any light device (with low update rate if the device is Meross cloud connected).
• the Meross cloud MQTT rate-limiter has been 'relaxed' a bit: the rate limiting is now calculated for each device independently (please check this).
• added new mac address range (likely related to the new MSH450 Hub) for Meross devices discovery over DHCP.
• refactor of MFC100 (smart fan) and many other 'toggle-like' devices trying to improve quality/reliability (#393).
• refactor of MRS100 (smart roller shutter) trying to improve quality/reliability (#419, #321).
• refactor of MSG100/200 (smart garage door) trying to improve quality/reliability (#428).
• it is now allowed to pass the payload as a dictionary (or a string) in meross_lan.request service call (#404)
• various improvements and glitches removal in protocol switching behavior.

fixes

• "Detected blocking call to import_module..." HA 2024.5 core warning (#427)

(Almost) final preview of the new release. Features are now stable and this release is expected to work flawlessly. Here the improvements against latest beta (5.1.0-beta.1)

features

• light devices (all of the currently supported) now offer software emulated transitions. This might be far from ideal (in smoothness of light transition) since the code needs to quickly and repeatedly send updated light commands to establish a light trajectory and this has several limits in this implementation (details maybe in a dedicated post). Smoothness is better experienced if devices are totally unbinded from Meross cloud (local MQTT) since there are some limits trying to prevent cloud brokers message flooding (and thus ban). If your devices are still Meross paired transitions will work but with a 'very low' rate of update (roughly 1 update in 10 seconds)

fixes

• hopefully improved stability of mrs100 http connection (#419)
• hopefully fixed a bug in setting open/close time for mrs100 (#321)

features

• it is now allowed to pass the payload as a dictionary (or a string) in meross_lan.request service call (#404)
• previous new features have been 'polished' a bit especially for msl320 light strip

fixes

• various fixes against release 5.1.0-beta.0

Beta preview with some minor fixes and improvements. Light entities were heavy refactored in order to implement msl320 light effects. This could have consequences on some light(s) since they're a very mess. This release has been ground-tested over an old msl120 (RGB/Temp bulb) and a brand new msl320cp (Pro strip) and looks promising but given the long story of 'lights' failures I could expect some flaws here and there. If you have any positive/negative feedback (confirmation that your device is still working or not) I would greatly appreciate it in order to proceed with 'public' release

features

• Implemented support for msl320 light effects.
• the Meross cloud MQTT rate-limiting has been re-implemented: now it applies an average rate of 6 outbound messages over 1 minute thus improving the bandwidth available to each device (it was 5 messages over a minute for single broker connection before). This change would raise (depending on the number of devices binded to the Meross account) the MQTT cloud traffic a bit so increasing the risk of 'Meross account ban' due to high traffic. Any other policy trying to reduce outbound MQTT traffic is still in place so there shouldn't be any big change if your devices have proven reliable HTTP connectivity. On the other hand, when HTTP fails (see issues around about this), the MQTT channel will be used more often than before.
• the Fan entity device (map100 and mfc100) has been refactored to try improve its behavior (#393)

fixes

• removed module imports in the main loop (HA core 2024.5 new warning #427)
• minor cosmetic/compatibility fixes against new HA cores