Moving from custom_components to HA version not working

[jcastro]

Hello!

I've been using it for months now, as you know! However I've now moved to the official HA version and it seems to not work anymore. AFAIK It shouldn't have changed the token as I haven't repaired or changed anything on the Mi Home app and the robot.

I've deleted the .py file from custom_components and also the pycaches folders just in case.

I'm getting this error:

[31m2017-07-17 11:29:01 ERROR (SyncWorker_122) [mirobo.device] got error when receiving: timed out�[0m

�[31m2017-07-17 11:29:01 ERROR (MainThread) [homeassistant.helpers.entity] Update for switch.limpiador fails�[0m

Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/mirobo/device.py", line 129, in send
data, addr = s.recvfrom(1024)
socket.timeout: timed out

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/src/app/homeassistant/helpers/entity.py", line 225, in async_update_ha_state
yield from self.hass.async_add_job(self.update)
File "/usr/local/lib/python3.6/asyncio/futures.py", line 331, in __iter__
yield self # This tells Task to wait for completion.
File "/usr/local/lib/python3.6/asyncio/tasks.py", line 244, in _wakeup
future.result()
File "/usr/local/lib/python3.6/asyncio/futures.py", line 244, in result
raise self._exception
File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/app/homeassistant/components/switch/xiaomi_vacuum.py", line 112, in update
state = self.vacuum.status()
File "/usr/local/lib/python3.6/site-packages/mirobo/vacuum.py", line 87, in status
return VacuumStatus(self.send("get_status")[0])
File "/usr/local/lib/python3.6/site-packages/mirobo/device.py", line 143, in send
raise DeviceException from ex
mirobo.device.DeviceException�[0m

This is my current config:

switch:
  - platform: xiaomi_vacuum
    name: 'limpiador'
    host: 10.0.1.15
    token: XXX

IP also hasn't changed, so I'm not sure what's going on here!

Also my robot is perfectly connected to the Wifi and I can control it without problems with the Mi Home app!

[TribuneX]

Same issue for me after upgrading to the HASS component in version 0.49

[rytilahti]

Ok, this is obviously bad. I'm unsure what's the reason for this, but one possibility is the lack of doing a rediscovery now and then (I think I saw miiojs doing it every 120 seconds or so). @jcastro are you still using an older FW?

[jcastro]

Umm nop, I'm on the latest firmware available (just checked for new one just in case)

[szmania]

Latest firmware and experiencing issue. Tried the changing of the start_id in Device class to random value from 0 to 9999 between commands, to no avail. That did work when running without HA, but with HA, not working.

[rytilahti]

I think the problem is time-outing for the long-lived instances (besides some random timeouts now and then), which require a new discovery. For the time being making Device's send() to call enter() for each invocation could be a potential solution.

[szmania]

So change this:

    def send(self, command: str, parameters: Any=None) -> Any:
        """Build and send the given command."""
        if self._devtype is None or self._serial is None:
            self.__enter__()  # when called outside of cm, initialize.

To this:

    def send(self, command: str, parameters: Any=None) -> Any:
        """Build and send the given command."""
        self.__enter__()  # when called outside of cm, initialize.

[szmania]

Its the start_id. I just tested it with enter solution to no avail. But with a random start_id with success.

[rytilahti]

So, there are (at least) two separate things which may cause connection failures:

1. The sequence number is below the number received last time from the robot and there has been no pause of a minute or so between the messages.
2. There has been no discovery handshake for a while (this is just an assumption)

For the first point, randomizing the start_id won't do any good if the chosen ID will be below the previously received one, but will just get it ignored by the robot. Assuming that the ID loops after 9999 (as seen in miiojs), maybe it would make sense to send 9999 as the first ID every single time and start then counting to make sure it works. I have not yet tested this though.

To the second point, I modified it locally to do a discovery for every send as I mentioned, and even if it sometimes fails, it seems to recover just fine (running this since yesterday without problems).

[szmania]

Hi rytilahti,

I tried your second point by calling __enter__ in every send call, without success. I still get OP error.

I will test first point, instead of randomizing but rather decrementing from 9999 as you say.

[syssi]

It's more or less a hack but it is working for some people:

syssi/xiaomiplug@399f8a7

[Isstum]

Same problem here!
Switched from custom_components to official. Running on HA 0.49, newest firmware on the vaccuum.

[szmania]

syssi's fix seems to work. I guess capturing the exception and then refiring __enter__ did the trick.

[rytilahti]

Ok, so the cause is expired discovery/handshake, I'll release a fixed release today and make a PR to homeassistant then.

[rytilahti]

I just released 0.1.2 which should finally fix this (by incrementing the message id and retrying on errors), I'll prepare a PR for homeassistant soon enough, but it would be nice if someone could test it before it hits the new release. Changing xiaomi_vacuum.py inside the homeassistant to depend on version 0.1.2 should be enough :-)
edit: PR is here: home-assistant/core#8602

[syssi]

I think you didn't pushed your changes. :-)

[rytilahti]

Indeed, sorry! It's been pushed now.

[syssi]

Can you prepare a new release or update the release tag? tag 0.1.2 points still to commit 4ab8efd.

[rytilahti]

Hm, that's the correct one though (it is the last commit on master, which bumps the version to 0.1.2 too).

[syssi]

You are right. Perfect! :-)

[azogue]

Hi! I've done a PR in Home Assistant to covert the switch to a component to integrate sensors and services. The new integration, with the new release should fix this issue and more.

I'm testing it with mirobo 0.1.2 and the last firmware (3.3.9_003077), and it's working perfectly, thank you all for your work with this device!

[rytilahti]

Thanks for getting back and for your work on the homeassistant component! :) I think this can be closed now.