Update README.md

README.md

@@ -9,7 +9,7 @@ This [homeassistant](https://www.home-assistant.io/) integration allows you to c
 
 These are the two main use cases:
 - Keep your devices paired with the offical Meross App (and cloud infrastructure) and communicate directly to them via HTTP. This will allow for greater flexibility and less configuration pain since you don't have to setup and configure the MQTT pairing of these devices. The integration will just 'side-communicate' over HTTP to the devices and poll them for status updates. (This is different from https://github.com/albertogeniola/meross-homeassistant since this componenent does not talk to the Meross Cloud service so it doesn't use credentials - except for key retrieval - nor it suffers from throttling or banning)
-- Bind your devices to your 'private' MQTT broker so to completely disconnect them from the Meross infrastructure and interact only locally (The procedure for MQTT binding is here: https://github.com/bytespider/Meross/wiki/MQTT or better, you can use the pairer app from @albertogeniola at https://github.com/albertogeniola/meross_pair )
+- Bind your devices to your 'private' MQTT broker so to completely disconnect them from the Meross infrastructure and interact only locally (The procedure for MQTT binding is here: https://github.com/bytespider/Meross/wiki/MQTT or better, you can use the [pairer app](https://play.google.com/store/apps/details?id=com.albertogeniola.merossconf) from @albertogeniola at https://github.com/albertogeniola/meross_pair)
 
 HAVE FUN! 😎
 
@@ -36,20 +36,14 @@ Once installed and restarted, your Meross devices should be automatically discov
 
 > ℹ️ If device(s) are not automatically discovered, try powering them off for 10s and then powering them back on. A notification that new devices have been discovered should appear in `notifications`.
 
-
 If you are using the 'MQTT way' devices will be automatically discovered when they publish any MQTT message topic.
 If you set a non-empty device key when binding your devices to your private broker, you must configure it in the 'MQTT Hub' configuration entry (this will popup too in the discovered integrations). Once the mqtt hub entry is properly set with the correct key, devices should be automatically discovered
 
-
-You can also manually add your device by adding a new integration entry and providing the host address and device key.
+You can also manually add your device by adding a new integration entry and providing the host address and device key (repeat this for every device to add).
 
 When configuring a device entry you'll have the option to set:
 - host address: this is available when manually adding a device or when a device is discovered via DHCP: provide the ip address or a valid network host name. When you set the ip address, try to ensure it is 'stable' and not changing between re-boots else the integration could 'loose' access to the device. Starting from version 2.7.0 any dynamic ip change should be recognized by meross_lan so you don't have to manually fix this anymore.
-- key selection mode: this option allows you to specify some 'helpful' behaviours when configuring the device key. Whatever 'mode' you select you should always set a proper key in the next configuration field since that is the one meross_lan will use. The 'mode' field is only an hint to meross_lan on how to process the key validation/configuration
-  - User set: this mode allows you to set the (non empty) key and meross_lan will accept it with no further actions (except checking it is valid by querying the device)
-  - Hack mode: this mode allows meross_lan to accept an empty key. Setting an empty key will try to use an hack to communicate with the device. This works or not depending on many factors and you could experience random issues due to the algorithm not always working. Be aware and use it only as a last resort!
-  - Cloud retrieval: this mode will automatically check the preset key (if present) and, in case of failure or empty, bring you to a Meross cloud login form which will automatically retrieve the device key from your account (username and password needed)
-- device key: this is used to sign messages according to the official Meross protocol behaviour. This should be prefilled with a known key from other devices if you already configured any before. If you need or want to use the 'Hack mode', leave it empty
+- device key: this is used to sign messages according to the official Meross protocol behaviour. This should be prefilled with a known key from other devices if you already configured any before. If you enter a wrong or empty key a menu will ask you if you want to manually retry entering a different key or if you want to recover the key from your Meross account. If your device is still paired to the Meross App, this is the way to recover the device key since it is managed by the Meross App and saved in your cloud profile.
 
 These other options are available once the device is setup the first time. To access them just access the integration configuration UI:
 - protocol: the software is able to communicate both over http directly to the device or through an mqtt broker. When you configure an entry by ip address (either manually or dhcp discovered) it usually 'prefers' to talk http for obvious reasons but can nevertheless automatically switch to mqtt if it recognizes it is available (by 'sensing' mqtt messages flowing through). If you set 'Auto' (or leave empty/unconfigured) you'll have this automatic 'failover' switch in both directions (HTTP <-> MQTT) trying to always ensure the best available transport to communicate. If you force it (either HTTP or MQTT) no automatic protocol switching will occur and the integration will only talk that protocol for that configuration entry (some minor exceptions are in place at the moment and some commands are tried over HTTP first anyway).
@@ -94,7 +88,7 @@ Most of this software has been developed and tested on my owned Meross devices w
 
 ## Features
 
-The component exposes the basic functionality of the underlying device (toggle on/off, dimm, report consumption through sensors) without any other effort, It should be able to detect if the device goes offline suddenly by using a periodic heartbeat.
+The component exposes the basic functionality of the underlying device (toggle on/off, dimm, report consumption through sensors) without any other effort. It should be able to detect if the device goes offline suddenly by using a periodic heartbeat.
 It also features an automatic protocol switching capability so, if you have your MQTT setup and your broker dies or whatever, the integration will try to fallback to HTTP communication and keep the device available returning automatically to MQTT mode as soon as the MQTT infrastructure returns online. The same works for HTTP mode: when the device is not reachable it will try to use MQTT (provided it is available!). This feature is enabled by default for every new configuration entry and you can control it by setting the 'Protocol' field in the configration panel of the integration: setting 'AUTO' (or empty) will do the automatic switch. Setting any fixed protocol 'MQTT' or 'HTTP' will force the use of that option (useful if you're in trouble and want to isolate or investigate inconsistent behaviours). I'd say: leave it empty or 'AUTO' it works good in my tests.
 
 If you have the MSH300 Hub working with this integration, every new subdevice (thermostat or sensor) can be automatically discovered once the subdevice is paired with the hub. When the hub is configured in this integration you don't need to switch back and forth to/from the Meross app in order to 'bind' new devices: just pair the thermostat or sensor to the hub by using the subdevice pairing procedure (fast double press on the hub).