How to use in Home Assistant

[gianky69]

How to use in Home Assistant

[albertogeniola]

Hi Vincenzo,
I could spend just an hour to look at the code and I think I've found a problem. It occurred to me that, if the connection is dropped while the client is waiting for the ACK from the meross cloud, something bad would happen. Most probably, that causes the error you've reported. Unfortunately, I did not have enough time to test my hypothesis, but that is something that you can help me with.

I've updated the library to the version 0.2.0.3. This version does print more info when an exception is raised. I'd ask you to repeat the tests with this version of the library.

My suspect is that the 'NoneType' object does not support item assignment is raised at power_plugs.py:328, since the ack waiting queue is released but no ack_response is there. If your tests will confirm that, I'll spend some more time to figure out a nice way of handling this error.

[albertogeniola]

Hi Vincenzo,
Well done. I believe that the Meross mqtt broker will kick out a client if it tries to connect more that once. In particular, the method list_supported_devices() calls the GenericPlug() constructor for every discovered device. The constructor, in turn, starts the connection to the mqtt broker, kicking out the previous client.

So, in order to make your code 'cleaner' I might add a method that only lists the supported devices uuid, name/type and online status. Or, even better, I might handle the connection to the mqtt broker in a 'lazy' way, so that the connection is established only when really needed (and not within the constructor). I'll see what fits the best and let you know!

[vincenzosuraci]

Dead Alberto,
I was wondering if there is a way, in Python, to catch when a status change occurs (e.g. switch on/off or new power/current values available).

Right now, the custom-component polls periodically the meross_iot library to get the current status. It means that whatever happens between two consecutive scan intervals must wait until the next scan (e.g. 5 seconds).

I guess that I can do better. In particular, knowing that your library relies on a mqtt client, I was wondering if I can catch some important state changes: e.g. the switching ( on>>>off or off>>>on) or new current values.

If possible, I would prefer to listen to a trigger rather than continuosly poll the library.

Meaningful triggers are:

1. New Meross Device connected;
2. Meross Device disconnected;
3. Meross device's switch on >>> off
4. Meross device's switch off >>> on
5. Meross device's sensor new value
6. Connected to the Meross mqtt broker
7. Disconnected by the Meross mqtt broker

I really do not have an idea how to do that, but I think It would decrease the number of interactions.

VS

[albertogeniola]

Hi Vincenzo, what you ask is certainy posible and is generally referenced as "callback" or "event", depending on the programming language used. Honestly, I was already thinking about adding such functionality. Let me mark this request as enhancement. I'm not sure about when will I be able to implement such request, but that's definetely something to do.

…

On Wed, Apr 17, 2019 at 1:55 PM Vincenzo Suraci ***@***.***> wrote: Dead Alberto, I was wondering if there is a way, in Python, to catch when a status change occurs (e.g. switch on/off or new power/current values available). Right now, the custom-component polls periodically the meross_iot library to get the current status. It means that whatever happens between two consecutive scan intervals must wait until the next scan (e.g. 5 seconds). I guess that I can do better. In particular, knowing that your library relies on a mqtt client, I was wondering if I can catch some important state changes: e.g. the switching ( on>>>off or off>>>on) or new current values. If possible, I would prefer to listen to a trigger rather than continuosly poll the library. Meaningful triggers are: 1. New Meross Device connected; 2. Meross Device disconnected; 3. Meross device's switch on >>> off 4. Meross device's switch off >>> on 5. Meross device's sensor new value 6. Connected to the Meross mqtt broker 7. Disconnected by the Meross mqtt broker I really do not have an idea how to do that, but I think It would decrease the number of interactions. VS — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEbvi5UG6BJQW3gprTdmtc76IRDvsSNeks5vhwuugaJpZM4aU20N> .

-- Dott. Alberto Geniola [email protected] [phone] https://www.linkedin.com/in/albertogeniola <https://github.com/albertogeniola>

[albertogeniola]

Hi Vincenzo,
All the custom exceptions I've implemented do extend the Exception class, which in turn extends the BaseException class. Therefore, if you catch BaseException you will definitely catch also my custom exceptions. I guess the error log you receive is misleading, there must be something else wrong...

Edit:
Just to be 100% sure, I've performed some tests and they confirm my idea.

[albertogeniola]

Ok, I found the problem. I've looked at your code and it seems you are importing the MODULE CommandTimeoutException, but you need to catch the class, not the module. So, just change the import line as follows:

from meross_iot.cloud.exceptions.CommandTimeoutException import CommandTimeoutException
from meross_iot.cloud.exceptions.StatusTimeoutException import StatusTimeoutException

Yeah I know, sometimes Python is a real beast :)

[albertogeniola]

Well, this is the first time I hear about Hassio and I have to say that looks awesome. Unfortunately I don't have much time to play with that, but I'm pretty sure that a simple Add-On can be implemented. Beside, the hard work has been already tackled by this API, so it'll be just a matter of integrating the API into the Hassio environment.

[gianky69]

I've not a programming skill.
Will anyone do this integration?

[aslafy-z]

Here's a working Addon for hassio: https://github.com/carlosatta/hassio-addons/tree/master/hassio_meross
It have been discussed on HA community discourse: https://community.home-assistant.io/t/are-meross-switches-compatible-with-any-existing-components/51548/91

[vincenzosuraci]

I'm a happy owner of 2 MSS310 and 1 MSS210 and wanted to make them work on Home Assistant. I'm working on a custom_component here. Any support to improve it, is more than welcome.

[vincenzosuraci]

Dear Alberto,
I'm developing Home Assistant custom-component on top of your precious library (v 2.0.1). Basically, Home Assistant, is assumed to be installed on a always on platform. For example, in my case, I use a specific distro of Home Assistant called Hassio, running 24/7 on a Raspberry Pi.

Thanks to your library, it can be possible to:

1. discover the Meross devices and their sensors (in particular electricity values: A, V, W) and switching (e.g. power plugs or usb) capabilities;
2. operate on the switches (on/off);
3. update periodically the status of the sensors (A,V,W) and switches status (on/off).

I'm experimenting a random issue on point (3). Randomly, after some time, the component stops showing updated status of the Meross devices (A, V, W and switches on/off). I receive no error, simply, the values of A, V, W and switches status stops to update and provides always the same values, even if (e.g., using the Meross App or doing it manually) I operate on the Meross device switches changing their status.

When I restart Hassio, during the component setup, a MerossHttpClient is created once (this object remains the same and is never re-instantiated). This MerossHttpClient object is used to perform the point (1). The discovered devices (using list_supported_devices() method of MerossHttpClient object) are stored as python objects. The discovered list is updated every 15 minutes (to check if a device has been added or removed). Each 5 seconds, each device update its status (calling the get_channel_status(channel) and, when possible, the get_electricity() methods).

Randomly, after some time (sometime after few minutes, sometimes after several hours), the status update process fails.

I checked the log, and got these messages:

[...] File "/config/deps/lib/python3.7/site-packages/meross_iot/supported_devices/power_plugs.py", line 433, in get_electricity return self._get_electricity() File "/config/deps/lib/python3.7/site-packages/meross_iot/supported_devices/power_plugs.py", line 339, in _get_electricity return self._execute_cmd("GET", ELECTRICITY, {}) File "/config/deps/lib/python3.7/site-packages/meross_iot/supported_devices/power_plugs.py", line 325, in _execute_cmd raise CommandTimeoutException() meross_iot.supported_devices.exceptions.CommandTimeoutException.CommandTimeoutException [...]

[...] File "/config/deps/lib/python3.7/site-packages/meross_iot/supported_devices/power_plugs.py", line 170, in __init__ self.get_status() File "/config/deps/lib/python3.7/site-packages/meross_iot/supported_devices/power_plugs.py", line 498, in get_status self._state = self._get_status_impl() File "/config/deps/lib/python3.7/site-packages/meross_iot/supported_devices/power_plugs.py", line 375, in _get_status_impl data = self.get_sys_data()['all'] File "/config/deps/lib/python3.7/site-packages/meross_iot/supported_devices/power_plugs.py", line 442, in get_sys_data return self._execute_cmd("GET", "Appliance.System.All", {}) File "/config/deps/lib/python3.7/site-packages/meross_iot/supported_devices/power_plugs.py", line 325, in _execute_cmd raise CommandTimeoutException() meross_iot.supported_devices.exceptions.CommandTimeoutException.CommandTimeoutException [...]

In the following log I obfuscated the device_id with XXX:

[...] 2019-04-11 07:35:59 ERROR (Thread-132) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:36:01 ERROR (Thread-131) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:36:08 ERROR (Thread-132) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:36:11 ERROR (Thread-131) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:45:55 ERROR (Thread-135) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:46:01 ERROR (Thread-135) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:46:08 ERROR (Thread-134) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:46:08 ERROR (Thread-134) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:56:03 ERROR (Thread-137) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online 2019-04-11 07:56:08 ERROR (Thread-138) [meross_powerplug] XXX failed to process message because: Unknown/Unsupported namespace/command: Appliance.System.Online [...]

In general, once these types of log messages occur, the status update stops working.

Do you have any idea on how to recover from these situation? For example, if I manage to catch these exceptions, I'm supposed to generate a new MerossHttpClient object?

Many thanks in advance for any help you can provide on that,
VS

[albertogeniola]

Hi Vincenzo,
I realized that there was a small error in the version 0.2.0.0. I suggest you to update the version to 0.2.0.1 and let me know if the problem persists.

[gianky69]

Hi, I'm using Vincenzo Suraci custom component and it keeps hangs after 0.2.0.1 update.
This is what I've done:
I've updated the init.py in custom_components/meross as you wrote, changing REQUIREMENTS = ['meross_iot==0.2.0.0'] to ['meross_iot==0.2.0.1'].
Restarted HA all seems ok, but let's wait some minutes, hours, days...
After some time (random, from minutes to hours) it seems hanging.
The merossiot seems updated (in config/deps/lib/phyton3.7/site-packages/ I find 2 folders - meross_iot and meross_iot-0.2.0.1.dist-info).
Using Meross APP or GoogleHome voice command the status doesn't change in HA, (but switching in HA continues working and also in App or GH).

[vincenzosuraci]

Dear Alberto,
I updated to version 0.2.0.1, but I still get, randomly, this logs:

Unknown/Unsupported namespace/command: Appliance.System.Online
2019-04-12 12:08:19 ERROR (Thread-2) [meross_powerplug] Unknown/Unsupported 
namespace/command: Appliance.System.Online

I think the issue can be found in power_plug.py file, at row 371:

def _handle_namespace_payload(self, namespace, payload):
    with self._status_lock:
        if namespace == TOGGLE:
            self._state[0] = payload['toggle']['onoff'] == 1
        elif namespace == TOGGLEX:
            if isinstance(payload['togglex'], list):
                for c in payload['togglex']:
                    channel_index = c['channel']
                    self._state[channel_index] = c['onoff'] == 1
            elif isinstance(payload['togglex'], dict):
                channel_index = payload['togglex']['channel']
                self._state[channel_index] = payload['togglex']['onoff'] == 1
        else:
            l.error("Unknown/Unsupported namespace/command: %s" % namespace)

It seems that if namespace is not TOOGLE (that is equal to Appliance.Control.Toggle) or TOOGLEX (that is equal to Appliance.Control.ToggleX), the library logs an error.

Indeed, the returned namespace is Appliance.System.Online and it explain why the error is logged.

I do not know why the Appliance.System.Online is returned by the Meross Cloud, but it "smells" to be a sort of keep-alive message. Could it be?

However, crawling on google, I found a reference belonging to another (your) project: https://github.com/albertogeniola/mqtt_dissector/blob/master/messages.py
In that file, the Appliance.System.Online string occurs on rows 75 and 79.

However, I suggest to handle this callback message, instead of logging an error and do nothing more that acknowledge that the device is still Online.

I hope this reasoning can help you.

Regards,
Vincenzo

[albertogeniola]

Alright @vincenzosuraci ,

I've checked what you said. In my tests I did never receive such keep-alive. I guess it's very long-lived and that would explain why this is the first time I see that. Nevertheless, the error message should not harm the functionality of the library. I've accepted your suggestion by updating the library to the 0.2.0.2 version: now the Online keep alive message is simply ignored (I'm not sure if it's a good idea to rely on that). I've looked at the code of the Meross APP and it looks like that such Online message is handled just as an "online" event.

Regarding your issue, @gianky69 , I'll try to investigate. I will set up a raspberry to randomly use the plugs and see it it hangs as you say. I'll let you know.

[vincenzosuraci]

Hi @albertogeniola , @gianky69 ,
the hangs is my fault. To keep updated the list of available Meross devices, I was calling periodically (each 15 minutes) the list_supported_devices() method.

Unfortunately I did not notice that doing so, it was forcing the conneted devices to disconnect. I found the problem and solved it.

I ask @gianky69 to help me in doing long lasting tests (days) to see if now the HA custom component works.

I sincerely want to thank @albertogeniola , since he is doing the hardest job of interfacing with the variety of Meross devices using a black-box approach. That is not easy and, more important, it is not his job (I guess you do it in your spare time, as me).

Regards,
Vincenzo

[albertogeniola]

Hi @vincenzosuraci ,
I'm happy you found the problem, well done. Also, thank you for the appreciation: also your job in bringing my low-level library to the HomeAssistant OS is relevant and is definitely contributing to the success of the library itself. Keep up the nice job.

So, we now wait for @gianky69 to confirm it's working also on the long term. Does he need to update the library version of your component?

[gianky69]

I've updated the custom_components/meross and the meross_iot to 0.2.0.2 (as in init.py), now let's wait some time...

[gianky69]

After an evening and a night the Meross custom component in Home Assistant continues working... let's wait some days...

[vincenzosuraci]

Dear Alberto,
we are doing some tests on Hassio environment (have a look here), using the 0.2.0.2 version of the library.

Sometimes, when some CommandTimeoutException occur, meross_plug casts one of the following ERRORs:

2019-04-16 02:32:18 ERROR (Thread-533) [meross_powerplug] 18081882593706290835xxxxxxxxxxxx failed to process message because: 'NoneType' object does not support item assignment

2019-04-16 04:07:03 ERROR (Thread-73) [meross_powerplug] Unknown/Unsupported namespace/command: Appliance.Control.ConsumptionX

It seems to me that, after these ERROR, the meross_iot library stops working and freeze the custom-component. I was wondering if there is the possibility to handle such situations and cast an Exception, so that the code could continue.

I admit to be not an expert on Python language and I'm just trying to figure out where the source code stops working and how to avoid it. So, maybe, it could be just my fault, but studying the log file it seems that the last word is from power_plug.

Regards,
Vincenzo

[albertogeniola]

Hi Vincenzo,
Thank you for the tip. I will investigate.
Anyways, for future issues, I'd ask you to open separate issues on GitHub, so that I can better track them.

As soon as I get the chance to investigate on the issue I'll let you know. For now, that k you again!

[vincenzosuraci]

Dear Alberto,
many thanks for sharing your findings. Menawhile, also I did some achievements. I discovered that, calling periodically the list_supported_devices() method, makes disconnect all the previously created devices (that are instances of GenericPlug class). The disconnection put the devices in a ClientStatus.CONNECTION_DROPPED state. From that state the devices cannot do nothing.

The only way to discover the list of available Meross devices, without affecting the already active ones, would be to call the list_devices() method, that returns a dictionary and allows to get the device_id from the uuid key. However, once I have the device_id, if it is a new Meross device, I still need to call the build_wrapper(self._token, self._key, self._userid, deviceType, dev) method.

For this reason, in the new committed version of the custom-component, I wrapped some of your classes to add several functionalities to avoid to call periodically the list_supported_devices() method that, in turn, was causing a lot of unwanted and uncontrolled disconnections.

My suspect for the previous mentioned errors:

2019-04-16 02:32:18 ERROR (Thread-533) [meross_powerplug] 18081882593706290835xxxxxxxxxxxx failed to process message because: 'NoneType' object does not support item assignment
2019-04-16 04:07:03 ERROR (Thread-73) [meross_powerplug] Unknown/Unsupported namespace/command: Appliance.Control.ConsumptionX

is that they occured due to a too high number of calls of the list_supported_devices() method.

Right now I did some tests with the new version of the code (relying on your 0.2.0.2 and 0.2.0.3) versions, a everything seems to work fine.

However, as usual, let's see what happen in a long period of time.

VS

[vincenzosuraci]

Dear Alberto,
to avoid the disconnections, I extended the GenericPlug and MerossHttpClient classes to add the needed methods:

class HomeAssistantMerossGenericPlug(GenericPlug):
def __init__(self,
             token,
             key,
             user_id,
             **device_info):
    super().__init__(token, key, user_id, **device_info)

def get_client_status(self):
    return self._client_status

def is_connected(self):
    return self._client_status == ClientStatus.CONNECTED or self._client_status == ClientStatus.SUBSCRIBED


class HomeAssistantMerossHttpClient(MerossHttpClient):
def __init__(self, email, password):
    super().__init__(email, password)

def supported_devices_info_by_id(self, online_only=True):
    supported_devices_info_by_id = {}
    for device_info in self.list_devices():
        device_id = device_info['uuid']
        online = device_info['onlineStatus']

        if online_only and online != 1:
            # The device is not online, so we skip it.
            continue
        else:
            supported_devices_info_by_id[device_id] = device_info
    return supported_devices_info_by_id

def get_device(self, device_info, online_only=True):
    online = device_info['onlineStatus']
    if online_only and online != 1:
        return None
    return HomeAssistantMerossGenericPlug(self._token, self._key, self._userid, **device_info)

[vincenzosuraci]

I could spend just an hour to look at the code and I think I've found a problem. It occurred to me that, if the connection is dropped while the client is waiting for the ACK from the meross cloud, something bad would happen.

I had the occasion to test Home Assistant in a very harsh situation: a high speed train from Milan to Rome. The internet connection was very unstable and I was able to face exactly what you described. It seems that, in case of internet instability, if the PowerPlug class does not receive back some messages from the Meross MQTT broker, it hangs. And, since the custom-component, need this information to proceed, also Home Assistant freezes.

I wonder if I can found a workaround for avoding HA to freeze when PowerPlug class hangs.

VS

[virtualdj]

I wonder if I can found a workaround for avoding HA to freeze when PowerPlug class hangs.

I do not know HA (but I'm reading a lot on it, recently) nor Python but doesn't Home Assistant support async components? If the waiting for information from the Meross library is done on another thread, maybe HA shouldn't freeze.

[vincenzosuraci]

I wonder if I can found a workaround for avoding HA to freeze when PowerPlug class hangs.

I do not know HA (but I'm reading a lot on it, recently) nor Python but doesn't Home Assistant support async components? If the waiting for information from the Meross library is done on another thread, maybe HA shouldn't freeze.

@virtualdj , I kindly ask to you to have a look here. We are trying to develop a robust custom-component for HA (we are testing it both on HA and Hassio). Since you are studying HA, it would be helpful to have some suggestions on how to avoid Lovelace UI to hang.

I read about async implementation of HA sensor and switch entities and, indeed, I developed all their methods using a async approach. Nevertheless, when the underlying PowerPlug communication hangs, it seems that also the custom-component hangs, even if, using the async methods, I was expecting that just the Meross custom-component was hanging without affecting the whole Lovelace UI...

If you have any suggestion, please open a new issue here arguing your proposals, I'll be more than happy to implement them.

VS

[vincenzosuraci]

@albertogeniola after days of testing, it seems that using Fiber Optic it may occur the case (one after two/three days) that an ACK message get lost and the powerplug class hangs. With poor ADSL connections, it is sufficient to activate a download to recreate the hangs.

I'm studying a workaround but I guess that the best solution would be to add a timeout to a ACK message and cast a TimeoutException, avoiding to wait forever.

[albertogeniola]

Hi Vincenzo,
I've just released a new version of the library, which should address the ACK problem. In particular, I've implemented auto-reconnect in case of exceptions. This might not be the best solution (definitely must be an option, not the standard way to use the library), but for now it will make it.

During the weekend, thanks to some donation, I've bought new Meross devices to enlarge the supported hardware for this library. Again, I had to refactor the code structure in order to make this library support different devices (bulbs, garage openers and others). I'd kindly ask you to check if the new version (0.2.1.1) is working as expected with your plugin.

[gianky69]

I've updated the MerossIot package (0.2.1.1) under Home Assistant (in Vincenzo custom-component). Let's see how my poor ADSL will stress the system ;-)

[gianky69]

ALL BREAKED!
After update to 0.2.1.1, HA doesn't see Meross devices no more!
I get:

ERROR (MainThread) [homeassistant.loader] Error loading custom_components.meross. Make sure all dependencies are installed
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/homeassistant/loader.py", line 183, in _load_file
    module = importlib.import_module(path)
  File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 728, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/config/custom_components/meross/__init__.py", line 16, in <module>
    from meross_iot.api import MerossHttpClient
ModuleNotFoundError: No module named 'meross_iot'

I've also tried to manually update the directory but no way...
Only restoring a backup did the trick!

[vincenzosuraci]

ALL BREAKED!
After update to 0.2.1.1, HA doesn't see Meross devices no more!
I get:

ERROR (MainThread) [homeassistant.loader] Error loading custom_components.meross. Make sure all dependencies are installed
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/homeassistant/loader.py", line 183, in _load_file
    module = importlib.import_module(path)
  File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 728, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/config/custom_components/meross/__init__.py", line 16, in <module>
    from meross_iot.api import MerossHttpClient
ModuleNotFoundError: No module named 'meross_iot'

I've also tried to manually update the directory but no way...

@gianky69: it is normal. From v. 0.2.0.3 to 0.2.1.1, Alberto changed some APIs of meross_iot.
Right now I updated the custom-component to get rid of these issues.

It is better discuss of the custom-component in the rigth issue.

VS

[vincenzosuraci]

Dear @albertogeniola after updating to version 2.2.1 I'm having more "disconnection". Have a look at this log:

[...]
2019-04-25 14:05:39 DEBUG (MainThread) [meross_init] async_setup()
2019-04-25 14:05:39 DEBUG (MainThread) [meross_init] async_load_devices()
Current client connection status is: ClientStatus.INITIALIZED
The client needs to connect to the MQTT broker. Attempting it now...
Initializing the MQTT connection...
Current client connection status is: ClientStatus.SUBSCRIBED
2019-04-25 14:05:42 DEBUG (MainThread) [meross_init] New Meross device found: Vetralla Scaldino
Current client connection status is: ClientStatus.INITIALIZED
The client needs to connect to the MQTT broker. Attempting it now...
Initializing the MQTT connection...
Current client connection status is: ClientStatus.SUBSCRIBED
2019-04-25 14:05:43 DEBUG (MainThread) [meross_init] New Meross device found: Lavastoviglie
Current client connection status is: ClientStatus.INITIALIZED
The client needs to connect to the MQTT broker. Attempting it now...
Initializing the MQTT connection...
Current client connection status is: ClientStatus.SUBSCRIBED
2019-04-25 14:05:44 DEBUG (MainThread) [meross_init] New Meross device found: Asciugatrice
2019-04-25 14:05:44 DEBUG (MainThread) [meross_init] async_update_devices_status()
2019-04-25 14:05:44 DEBUG (MainThread) [meross_init] Device Vetralla Scaldino: ClientStatus.SUBSCRIBED
Current client connection status is: ClientStatus.SUBSCRIBED
2019-04-25 14:05:44 DEBUG (MainThread) [meross_init] Device Lavastoviglie: ClientStatus.SUBSCRIBED
Current client connection status is: ClientStatus.SUBSCRIBED
Current client connection status is: ClientStatus.SUBSCRIBED
2019-04-25 14:05:45 DEBUG (MainThread) [meross_init] Device Asciugatrice: ClientStatus.SUBSCRIBED
Current client connection status is: ClientStatus.SUBSCRIBED
Current client connection status is: ClientStatus.SUBSCRIBED
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] registering async_track_time_interval(hass, async_poll_devices_update, meross_devices_scan_interval)
2019-04-25 14:05:46 WARNING (MainThread) [homeassistant.loader] You are using a custom component for meross.switch which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-04-25 14:05:46 WARNING (MainThread) [homeassistant.loader] You are using a custom component for meross.sensor which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Vetralla Scaldino >>> 0 >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Vetralla Scaldino >>> 0 >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Lavastoviglie >>> 0 >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> 0 >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Asciugatrice >>> 0 >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> 0 >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] async_setup_platform called
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> power >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> power >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> current >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> current >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> voltage >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> voltage >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> power >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> power >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> current >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> current >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> voltage >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> voltage >>> __init__()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> 0 >>> unique_id() >>> switch.meross_1812172657826925182734298f19b2c3
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> 0 >>> unique_id() >>> switch.meross_1812172657826925182734298f19b2c3
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> 0 >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> 0 >>> entity_id: switch.meross_1812172657826925182734298f19b2c3
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> 0 >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Asciugatrice >>> 0 >>> name() >>> Asciugatrice
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> 0 >>> unique_id() >>> switch.meross_1812173483906925182734298f19b411
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> 0 >>> unique_id() >>> switch.meross_1812173483906925182734298f19b411
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> 0 >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> 0 >>> entity_id: switch.meross_1812173483906925182734298f19b411
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> 0 >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Lavastoviglie >>> 0 >>> name() >>> Lavastoviglie
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Vetralla Scaldino >>> 0 >>> unique_id() >>> switch.meross_1812045949328525182434298f18c43d
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Vetralla Scaldino >>> 0 >>> unique_id() >>> switch.meross_1812045949328525182434298f18c43d
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Vetralla Scaldino >>> 0 >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Vetralla Scaldino >>> 0 >>> entity_id: switch.meross_1812045949328525182434298f18c43d
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Vetralla Scaldino >>> 0 >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Vetralla Scaldino >>> 0 >>> name() >>> Vetralla Scaldino
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> current >>> unique_id() >>> sensor.meross_1812173483906925182734298f19b411_current
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> current >>> unique_id() >>> sensor.meross_1812173483906925182734298f19b411_current
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> current >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> current >>> entity_id: sensor.meross_1812173483906925182734298f19b411_current
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> current >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> current >>> unit_of_measurement() >>> A
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> current >>> name() >>> Lavastoviglie
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> current >>> icon() >>> mdi:current-ac
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> voltage >>> unique_id() >>> sensor.meross_1812173483906925182734298f19b411_voltage
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> voltage >>> unique_id() >>> sensor.meross_1812173483906925182734298f19b411_voltage
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> voltage >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> voltage >>> entity_id: sensor.meross_1812173483906925182734298f19b411_voltage
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> voltage >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> voltage >>> unit_of_measurement() >>> V
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> voltage >>> name() >>> Lavastoviglie
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> voltage >>> icon() >>> mdi:power-plug
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> power >>> unique_id() >>> sensor.meross_1812172657826925182734298f19b2c3_power
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> power >>> unique_id() >>> sensor.meross_1812172657826925182734298f19b2c3_power
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> power >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> power >>> entity_id: sensor.meross_1812172657826925182734298f19b2c3_power
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> power >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> power >>> unit_of_measurement() >>> W
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> power >>> name() >>> Asciugatrice
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> power >>> icon() >>> mdi:flash-outline
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> current >>> unique_id() >>> sensor.meross_1812172657826925182734298f19b2c3_current
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> current >>> unique_id() >>> sensor.meross_1812172657826925182734298f19b2c3_current
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> current >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> current >>> entity_id: sensor.meross_1812172657826925182734298f19b2c3_current
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> current >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> current >>> unit_of_measurement() >>> A
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> current >>> name() >>> Asciugatrice
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> current >>> icon() >>> mdi:current-ac
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> voltage >>> unique_id() >>> sensor.meross_1812172657826925182734298f19b2c3_voltage
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> voltage >>> unique_id() >>> sensor.meross_1812172657826925182734298f19b2c3_voltage
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> voltage >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> voltage >>> entity_id: sensor.meross_1812172657826925182734298f19b2c3_voltage
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> voltage >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> voltage >>> unit_of_measurement() >>> V
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Asciugatrice >>> voltage >>> name() >>> Asciugatrice
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Asciugatrice >>> voltage >>> icon() >>> mdi:power-plug
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> power >>> unique_id() >>> sensor.meross_1812173483906925182734298f19b411_power
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> power >>> unique_id() >>> sensor.meross_1812173483906925182734298f19b411_power
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> power >>> async_added_to_hass()
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> power >>> entity_id: sensor.meross_1812173483906925182734298f19b411_power
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> power >>> available() >>> False
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> power >>> unit_of_measurement() >>> W
2019-04-25 14:05:46 DEBUG (MainThread) [meross_init] Lavastoviglie >>> power >>> name() >>> Lavastoviglie
2019-04-25 14:05:46 DEBUG (MainThread) [meross_sensor] Lavastoviglie >>> power >>> icon() >>> mdi:flash-outline
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Asciugatrice >>> 0 >>> name() >>> Asciugatrice
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Lavastoviglie >>> 0 >>> name() >>> Lavastoviglie
2019-04-25 14:05:46 DEBUG (MainThread) [meross_switch] Vetralla Scaldino >>> 0 >>> name() >>> Vetralla Scaldino
Disconnection detected. Reason: 1
Disconnection detected. Reason: 1
Disconnection detected. Reason: 1

I was not expecting (and I'm not able to justify why) the 3 Powerplug instancies have been disconnected (connection is dropped) by the Mqtt broker. This disconnection causes the need to re-connect them in a sort of infinite cycle.

VS

[albertogeniola]

Hi Vincenzo,

that is strange. From the logs, I don't see any anomaly. It just looks like that Internet connection went down... After the disconnection occurred, what happened?

[vincenzosuraci]

@albertogeniola , I have an idea regarding the "Disconnection detected. Reason: 1".
I implemented a custom-component that make use of async functions. I have 3 Meross physical devices. I instantiate one instance of HttpMerossClient class that generates 3 instances of PowerPlug class (one for each physical device). The way I call the get_channel_status() and get_electricity() methods, is inside an async function. It means that may occur the case that these fuctions are called concurrently.

I did not study so much in details your library, but I'm wondering if calling two of these methods in parallel (from the aforementioned async functions), it may occur that the Mqtt message sequence is not respected and the Meross Mqtt server disconnects the clients.

VS

[vincenzosuraci]

Hi Vincenzo,

that is strange. From the logs, I don't see any anomaly. It just looks like that Internet connection went down... After the disconnection occurred, what happened?

Internet is stable, I think the Meross Server is dropping the connections for some reasons.

To cope with gianky69 internet leakages, I developed an aggressive approach, based on the use of async functions (to guarantee no freeze to the main thread that is in charge to excecute also the HA web-based UI), that forces the system to reconnect in case of disconnections. But I'm wondering why these disconnections are so frequent.

VS

[albertogeniola]

Hi Vincenzo,

I'm under the impression that the Meross MQTT broker implements anti-flooding: if you send too many messages it will kick the client out. Now, instead of issuing so many commands with async functions, we should find another approach. I'm already thinking to a massive refactor of the architecture to make it "async" like with a single MQTT connection to the broker.

For the moment, I guess you should simply avoid using async connections...

[vincenzosuraci]

Hi Vincenzo,

I'm under the impression that the Meross MQTT broker implements anti-flooding: if you send too many messages it will kick the client out. Now, instead of issuing so many commands with async functions, we should find another approach. I'm already thinking to a massive refactor of the architecture to make it "async" like with a single MQTT connection to the broker.

For the moment, I guess you should simply avoid using async connections...

It makes sense.

VS

[vincenzosuraci]

Hi Vincenzo,

I'm under the impression that the Meross MQTT broker implements anti-flooding: if you send too many messages it will kick the client out. Now, instead of issuing so many commands with async functions, we should find another approach. I'm already thinking to a massive refactor of the architecture to make it "async" like with a single MQTT connection to the broker.

For the moment, I guess you should simply avoid using async connections...

I found the problem. It was my fault. While doing tests with the custom-component on my PC, I forgot to disable Hassio on RPi. So the two Meross custom-component implementations were competing to get the unique access to the Mqtt server. Indeed, I have only one account.

I discovered that other Cloud services (e.g. eWeLink/Sonoff and Tuya) provides multiple accounts sharing the same devices. Meross doesn't seem to allow that. It is a limitation or I miss something?

Using different accounts (e.g. one e-mail for the mobile App and another e-mail for the RPi Hassio custom-component) would avoid conflicting situations...

[albertogeniola]

Hi Vincenzo, you are right. I've come across the same thing while testing the refactored library: the current version of the library always uses the same "APP-ID". So, in case you run it on two different devices, they will compete. However, I think this can be avoided by simply randomly generating the APP-ID used by the library. Let me implement such feature (it'll take just 5 minutes to me). When done, would you mind repeating the test with the "competition"? It would be useful for us to better understand how the Meross cloud works!

…

On Fri, Apr 26, 2019 at 1:42 PM Vincenzo Suraci ***@***.***> wrote: Hi Vincenzo, I'm under the impression that the Meross MQTT broker implements anti-flooding: if you send too many messages it will kick the client out. Now, instead of issuing so many commands with async functions, we should find another approach. I'm already thinking to a massive refactor of the architecture to make it "async" like with a single MQTT connection to the broker. For the moment, I guess you should simply avoid using async connections... I found the problem. It was my fault. While doing tests with the custom-component on my PC, I forgot to disable Hassio on RPi. So the two Meross custom-component implementations were competing to get the unique access to the Mqtt server. Indeed, I have only one account. I discovered that other Cloud services (e.g. eWeLink/Sonoff and Tuya) provides multiple accounts sharing the same devices. Meross doesn't seem to allow that. It is a limitation or I miss something? Using different accounts (e.g. one e-mail for the mobile App and another e-mail for the RPi Hassio custom-component) would avoid conflicting situations... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDO7C275FBRI2VQEQPFZZ3PSLTAPANCNFSM4GSTNUGQ> .

-- Dott. Alberto Geniola [email protected] [phone] https://www.linkedin.com/in/albertogeniola <https://github.com/albertogeniola>

[vincenzosuraci]

When done, would you mind repeating the test with the "competition"? It would be useful for us to better understand how the Meross cloud works!

Sure. Didn't know it, otherwise I would have tried this workaround yet!
If it works, it is a very good news.
VS

[albertogeniola]

Alright, go ahead with the "competition" test: version is 0.2.2.3.
Let me know if that solves the issue!

[vincenzosuraci]

Alright, go ahead with the "competition" test: version is 0.2.2.3.
Let me know if that solves the issue!

Dear Alberto, I think that with version 0.2.2.3 the competition issue has been solved. If I got it correctly, in the prvious version each PowerPlug had an APP_ID calculated as a hash (md5) function depending only on the actual UUID of the device. Now, each device instance has its own APP_ID, generated randomly.

It seems that this solution did the trick, indeed I have 2 running custom-components (one on Hassio, the other on HA) and I had no disconnections.

VS

[albertogeniola]

Hi Vincenzo, thank you for your precious test. Well done, now the library will allow multiple components to co-exist with no problem.

…

On Fri, Apr 26, 2019 at 7:09 PM Vincenzo Suraci ***@***.***> wrote: Alright, go ahead with the "competition" test: version is 0.2.2.3. Let me know if that solves the issue! Dear Alberto, I think that with version 0.2.2.3 the competion issue is solved. If I got it correctly, in the prvious version each PowerPlug had an APP_ID calculated as a hash (md5) function depending only on the actual UUID of the device. Now, each device instance has its own APP_ID, generated randomly. It seems did the trick, since now I have 2 running custom-components (one on Hassio, the other on HA) and I had no disconnections. VS — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDO7C33JAEWHHAUWUOVZSDPSMZN3ANCNFSM4GSTNUGQ> .

-- Dott. Alberto Geniola [email protected] [phone] https://www.linkedin.com/in/albertogeniola <https://github.com/albertogeniola>

[vincenzosuraci]

@albertogeniola I have an issue with version 0.3.0.0b0.

I'm using the Android app version 1.6.0. If I change the switch status from the Android App, the event_handler is not called. Instead, if I switch from HA, the App correctly detects the status change.

Since it is the first test I did, I cannot say if before updating to Android app version 1.6.0 the custom-componnet was working. However, I guess this issue is independent from the android App version.

VS

[vincenzosuraci]

@albertogeniola I have also another issue with version 0.3.0.0b0.
It seems that the meross_iot exceptions do not inherit from BaseException, so I cannot catch them anymore.

Traceback (most recent call last):
  File "C:\Users\Vincenzo Suraci\AppData\Roaming\.homeassistant\custom_components\meross\__init__.py", line 174, in update_sensor_status
    electricity = self.device.get_electricity()
  File "c:\users\vincenzo suraci\homeassistant\lib\site-packages\meross_iot\cloud\devices\power_plugs.py", line 135, in get_electricity
    return self._get_electricity()['electricity']
  File "c:\users\vincenzo suraci\homeassistant\lib\site-packages\meross_iot\cloud\devices\power_plugs.py", line 21, in _get_electricity
    return self.execute_command("GET", ELECTRICITY, {})
  File "c:\users\vincenzo suraci\homeassistant\lib\site-packages\meross_iot\cloud\device.py", line 126, in execute_command
    return self.__cloud_client.execute_cmd(self.uuid, command, namespace, payload, callback=callback, timeout=timeout)
  File "c:\users\vincenzo suraci\homeassistant\lib\site-packages\meross_iot\cloud\client.py", line 300, in execute_cmd
    raise CommandTimeoutException("A timeout occurred while waiting fot the ACK: %d" % timeout)
meross_iot.cloud.exceptions.CommandTimeoutException.CommandTimeoutException: A timeout occurred while waiting fot the ACK: 10

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Vincenzo Suraci\AppData\Roaming\.homeassistant\custom_components\meross\__init__.py", line 241, in async_update_plugs
    await meross_plug.async_update_status()
  File "C:\Users\Vincenzo Suraci\AppData\Roaming\.homeassistant\custom_components\meross\__init__.py", line 137, in async_update_status
    self.update_sensor_status()
  File "C:\Users\Vincenzo Suraci\AppData\Roaming\.homeassistant\custom_components\meross\__init__.py", line 179, in update_sensor_status
    except CommandTimeoutException:
TypeError: catching classes that do not inherit from BaseException is not allowed
2019-05-01 09:10:59 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "C:\Users\Vincenzo Suraci\AppData\Roaming\.homeassistant\custom_components\meross\__init__.py", line 174, in update_sensor_status
    electricity = self.device.get_electricity()
  File "c:\users\vincenzo suraci\homeassistant\lib\site-packages\meross_iot\cloud\devices\power_plugs.py", line 135, in get_electricity
    return self._get_electricity()['electricity']
  File "c:\users\vincenzo suraci\homeassistant\lib\site-packages\meross_iot\cloud\devices\power_plugs.py", line 21, in _get_electricity
    return self.execute_command("GET", ELECTRICITY, {})
  File "c:\users\vincenzo suraci\homeassistant\lib\site-packages\meross_iot\cloud\device.py", line 126, in execute_command
    return self.__cloud_client.execute_cmd(self.uuid, command, namespace, payload, callback=callback, timeout=timeout)
  File "c:\users\vincenzo suraci\homeassistant\lib\site-packages\meross_iot\cloud\client.py", line 300, in execute_cmd
    raise CommandTimeoutException("A timeout occurred while waiting fot the ACK: %d" % timeout)
meross_iot.cloud.exceptions.CommandTimeoutException.CommandTimeoutException: A timeout occurred while waiting fot the ACK: 10

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Vincenzo Suraci\AppData\Roaming\.homeassistant\custom_components\meross\__init__.py", line 241, in async_update_plugs
    await meross_plug.async_update_status()
  File "C:\Users\Vincenzo Suraci\AppData\Roaming\.homeassistant\custom_components\meross\__init__.py", line 137, in async_update_status
    self.update_sensor_status()
  File "C:\Users\Vincenzo Suraci\AppData\Roaming\.homeassistant\custom_components\meross\__init__.py", line 179, in update_sensor_status
    except CommandTimeoutException:
TypeError: catching classes that do not inherit from BaseException is not allowed

[vincenzosuraci]

I started learning Python because of home assistant (approx 3 weeks ago) and I've a lot of doubt when programming with it.

Thanks for your hint!

VS