core: Multiple Xiaomi Gateways via Integration page not working

The problem

Recent update to 0.112 introduced an error when setting up multiple Xiaomi Aqara Gateways. This was doable through the configuration.yaml file in 0.111.4. The error comes when trying to add the second gateway using either (any, internal ip of Home Assistant, or the gateway ip): image

… and then the error: image

Multiple reboots on both Home Assistant and the Gateway doesn’t solve the issue.

Environment

arch x86_64
chassis embedded
dev false
docker true
docker_version 19.03.8
hassio true
host_os HassOS 4.10
installation_type Home Assistant OS
os_name Linux
os_version 5.4.44
python_version 3.7.7
supervisor 227
timezone Europe/Copenhagen
version 0.112.0
virtualenv false
  • Home Assistant Core release with the issue: 0.112
  • Last working Home Assistant Core release (if known): 0.111.4
  • Operating environment (OS/Container/Supervised/Core): Home Assistant OS
  • Integration causing this issue: MI XIAOMI AQARA
  • Link to integration documentation on our website: https://www.home-assistant.io/integrations/xiaomi_aqara

Problem-relevant configuration.yaml

Latest working configuration.yaml code.

xiaomi_aqara:
  discovery_retry: 20
  gateways:
    - key: !secret xiaomi_key1
      host: 192.168.1.91
      mac: !secret xiaomi_mac1
    - key: !secret xiaomi_key2
      host: 192.168.1.92
      mac: !secret xiaomi_mac2

Traceback/Error logs


Additional information

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 12
  • Comments: 92 (51 by maintainers)

Most upvoted comments

same issue here, Single Xaomi Gateway stop working too after upgrade from 0.111.4 to 0.112

Why are you slow to fix the error? Return everything back and correct as much as you want. How many people still have to express their displeasure to you?

You should be ashamed of yourself for posting this. People are donating their own time to an open source project and they don’t owe anything to you. Without this HomeAssistant wouldn’t even exist.

Single Xaomi Gateway stop working too after upgrade from 0.111.4 to 0.112

Alright, I made a bunch of changes fixing some additional bugs and also including a way to specify the IP and MAC manually so you can setup the gateway if SSDP fails and Auto-discovery also fails.

I am almost certain this will fix the issues mentioned here, have tested it myself extensively.

Now I am just wainting on @Danielhiversen or @syssi to merge https://github.com/Danielhiversen/PyXiaomiGateway/pull/172

How about making it possible to enter IP address of the gateway as a fallback whenever discovery fails?

The PR has merged an PyXiaomiGateway has released version 0.13.0 on Github. However PyPi is still showing 0.12.4 as the newest version so we can not yet install it using pip. I think @Danielhiversen still needs to upload the latest release to PyPi, but honestly I have no idea how releasing something on PyPi works…

Almost there!

@artbrayko Good luck learning python, because I’m not helping you anymore.

For the rest of the people that can appreciate the time I am putting into resolving an issue that I do not have, can’t reproduce and is probably caused by the gateway beeing on some seprate subnet, a VPN blocking communication or some other stupid network issue:

I will look into how the old code managed to setup the gateway withouth knowing all information gathered during discovery.

Am I correct that all of you specified both the IP-adress and MAC of the gateway in your config.yaml in the old integration?

Because withouth knowing both the MAC (sid) and IP I do not see a way you could setup the integration withouth the discovery step…

@fliphess the integration was converted to a config flow which enables many many new features. Like adding devices to an area using device automations. Managing the devices from the UI. An easier way for new users that don’t know yaml to setup the integration. All integrations are being converted to this new setup. Yaml was also deprecated for integration setup if you recall a few months ago (https://www.home-assistant.io/blog/2020/04/14/the-future-of-yaml/). There are just some lingering bugs that need to be fixed and tested.

I’m not sure about this path: wouldn’t it be better to just revert the change made back to what it was in 0.111.4 with the mindset of “Do not change when it’s not broken”?

I prefer have the old yaml configuration which was always working perfectly for my aqara gateways and it worked for years and years never resulting in any problems with it…

Does anyone know why the travis build fails here: https://github.com/Danielhiversen/PyXiaomiGateway/pull/177?

@starkillerOG the problem is that the discovery via multicast does not always work hence, previously, it was possible to directly specify the gateway ip with the ‘host’ entry in the configuration. So it is not something new or a change in PyXiaomiGateway.

See #37661

Can you please rollback the change until you get it working as before? thanks

But maybe it is better to test it myself first… Will not have time today, but can test tommorow.

@dshokouhi yea now the order of the arguments has changed. I just made another commit to fix the rest of the order in the init.py file in the lib.

also line 142 to 151 in init.py of HomeAssistant needs to change from:

    xiaomi_gateway = await hass.async_add_executor_job(
        XiaomiGateway,
        entry.data[CONF_HOST],
        entry.data[CONF_PORT],
        entry.data[CONF_SID],
        entry.data[CONF_KEY],
        DEFAULT_DISCOVERY_RETRY,
        entry.data[CONF_INTERFACE],
        entry.data[CONF_PROTOCOL],
    )

to:

    xiaomi_gateway = await hass.async_add_executor_job(
        XiaomiGateway,
        entry.data[CONF_HOST],
        entry.data[CONF_SID],
        entry.data[CONF_KEY],
        DEFAULT_DISCOVERY_RETRY,
        entry.data[CONF_INTERFACE],
        entry.data[CONF_PORT],
        entry.data[CONF_PROTOCOL],
    )

have fixed that issue, as I sad: I had not tested it myself…

Ah! you cannot place named arguments before unnamed arguments in python , so this has to be something like:

    def __init__(self, ip_adress, sid, key, discovery_retries, interface, port=MULTICAST_PORT, proto=None):

(Will add this comment on the PR as well)

@zacharynguyeenx thanks for the feedback, I added a link to that section in the error message in this PR: https://github.com/home-assistant/core/pull/39617 The wrong translation was already fixed by someone else (sorry for that, that was my fault)

@yecine06 just looked at the code, the error you are seeing is because you did not specify the MAC and IP during the config flow, or you are not on the 0.114.0b2 release.

Take a look at the code: https://github.com/home-assistant/core/blob/b626368b6a65ad9aab4dd4cc0abb554a7db3fd97/homeassistant/components/xiaomi_aqara/config_flow.py#L69-L115

You are getting the error of line 114, while if you specify both the MAC and IP (you need to fill in both!), at line 78 the host, mac and sid will be set such that at line 87 a direct connection to the gateway is made, then there are 3 possiblities, or you get a succesfull setup, or you get an “invalid_host” or “invalid_mac” error which are diffrent than the error you are having…

@maury77 FYI - the fix got bumped from the 0.113.2 milestone. It should be in an upcoming release though!

The PR was not originally tagged for the milestone of 0.113.2 I went ahead and tagged it but can’t make promises it will be included. It also still needs to be merged so it can be included in any release.

@starkillerOG fantastic! Perhaps this could even make it to the hotfix release if we are all lucky.

@starkillerOG yes, that is correct, I specified both IP and MAC, if I remember correctly, MAC was mandatory for 2+ gateways but I might be wrong.

I really don’t mean to be rude or anything and “be gentle with the coder, not with the code” always applies. but in the real world you don’t leave a core feature broken for few releases. You roll back, fix it, and deploy again.

Worst problem of the world right now? absolutely not. but, strange as it may seem, some of use relies on HA to be functioning and not consider it a toy anymore.

Rolling back HA has its own issue. with 0.112 the db schema has changed. it means you need to delete your now migrated db and lose all the data collected so far. That’s what I’ll do anyway. Again, not to be an ass, just speaking frankly

Well I gotta tell you that this might happen in the perfect world, but unfortunately this is not something even the big companies are following.

I do also rely on Home Assistant and my better half also looks funny at me, when it is night and the lights does not turn on, but the only person I can blame is myself for evolving into a project where tons of people dedicate much of their sparetime, but with no payment or obligations whatsoever. But the fact so many people are a part of this, we also get way more and better integrations than any other product (in my opinion) is able to deliver. So I think we should learn to be more patience and perhaps a habit of using backup even greater might be a good solution, so a roll back wont be such a pain for people. Maybe several versions back like I do myself in case of something like this happens.

So Thumbs up for @starkillerOG for gathering as much information as possible, so we can continue to develop this!

Hi @starkillerOG I’m happy to test, I have a single gateway in same subnet that refuses to be found.

How do I test your PR? Per your previous comment, do I only need to edit the files: venv\lib\python3.7\site-packages\xiaomi_gateway\__init__.py home-assistant\homeassistant\components\xiaomi_aqara\__init__.py

I need to edit these with the content of your PR?

Yes that is completly right! Would be great if you could test

This PR #37469 includes the changes for home-assistant\homeassistant\components\xiaomi_aqara\__init__.py and This PR Danielhiversen/PyXiaomiGateway#172 includes the changes for venv\lib\python3.7\site-packages\xiaomi_gateway\__init__.py

@starkillerOG

>>> import platform
>>> print(platform.system())
Linux

yea then we can’t properly handle it because it is a windows PC right? So I think this is something pretty specific to running on Windows Subsystem for Linux…

I think the try catch of my latest comment schould fix it for WSL and I think that is the best we can do.

@dshokouhi latest commit schould catch that OSError, but still would like to know what system is reported in your test env.

@dshokouhi if you run this python code inside of the virtual env where your test HomeAssistant runs, what is the result?

import platform
print(platform.system())

Take your time, there is a workaround available (temporary downgrade to 0.111.4), so no rush needed 😃

Thanks for your effort so far!

I made a first attempt to fix this issue in this PR: https://github.com/Danielhiversen/PyXiaomiGateway/pull/172/files I have not tested it yet on my system, but it schould work I think.

Could someone experiancing problems try this fix and see if it works?

Single Xaomi Gateway stop working too after upgrade from 0.111.4

Was working for me though in 0.111.4.