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)