Xiaomi gateway light unavailable after exactly 2,5 hours

xiaomi
Tags: #<Tag:0x00007f2048b49ca8>

#1

Most things working well, except this and humidity of the temperature sensor possibly being wrong.

  • Even when available, the switch in HA will move to turned off seconds after being turned on, while the light itself is still on.
  • But after a while the gateway light becomes unavailable. Control not working.
  • The hardware button stops working.

Model is the lumi.gateway.v3. hw_ver=MW300. Firmware 1.4.1_150.0143.
(Available firmware is 1.4.1_161.0143.)

Anyone with similar experiences?


#2

cant help with issue, but i wouldn’t upgrade your firmware, numerous posts about being unable to connect anymore after upgrading to that version


#3

You could start with turning on debug logging for the Xiaomi components, by adding this to your configuration.yaml:

logger:
  default: warn
    logs:
      xiaomi_gateway: debug
      homeassistant.components.xiaomi_aqara: debug
      homeassistant.components.switch.xiaomi_aqara: debug
      homeassistant.components.switch.xiaomi_miio: debug
      homeassistant.components.sensor.xiaomi_aqara: debug
      homeassistant.components.sensor.xiaomi_miio: debug
      homeassistant.components.binary_sensor.xiaomi_aqara: debug
      homeassistant.components.binary_sensor.xiaomi_miio: debug
      homeassistant.components.automation: debug
      homeassistant.core: debug

If you need more help, please share your configuration.yaml and the logging.


#4

Back to this topic after having been busy with a BLE issue that required >5d no restarts.

@aidbish thanks, I read about it too. Hope it will be solved soon for all those having trouble now.
Running a non cube compatible firmware here, with a cube on the way from Ali.

@tedsluis
Logging enabled as suggested and I looked 5 min’s before and after the ‘unavailable’ event. No possible related events found.

These are the logs for the gateway light as well as illumination sensor becoming unavailable:

Jan 17 00:42:22 Home_Controller 4bc2c954e063[20415]: 2019-01-17 00:42:22 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.illumination_4cf8c8fb621, old_state=<state sensor.illumination_4cf8c8fb621=15.0; unit_of_measurement=lm, friendly_name=Illumination_4cf8c8fb621, device_class=illuminance @ 2019-01-16T22:12:21.207806+01:00>, new_state=<state sensor.illumination_4cf8c8fb621=unavailable; unit_of_measurement=lm, friendly_name=Illumination_4cf8c8fb621, device_class=illuminance @ 2019-01-17T00:42:22.007117+01:00>>
Jan 17 00:42:22 Home_Controller 4bc2c954e063[20415]: 2019-01-17 00:42:22 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=light.gateway_light_4cf8c8fb621, old_state=<state light.gateway_light_4cf8c8fb621=off; friendly_name=Gateway Light_4cf8c8fb621, supported_features=17 @ 2019-01-16T22:12:21.225174+01:00>, new_state=<state light.gateway_light_4cf8c8fb621=unavailable; friendly_name=Gateway Light_4cf8c8fb621, supported_features=17 @ 2019-01-17T00:42:22.012464+01:00>>

(The gateway device itself is not part of any automation or whatever in HA. It’s just a pass-through device for the sensor information.)


#5

I am having the very same problem.
Using the lumi v3 gateway.

  • The state of the gateway light is reported incorrectly - will always report off
  • I can switch the gateway light on but cannot switch it off, unless i set brightness to 0
  • After switching the gateway light from HA few times the gateway is unresponsive untill HA restart
  • I am on the newest firmware - 1.4.1_164.0158

Let me know if you figure anything out


#6

Interesting to hear. I was starting to think that maybe my ‘pretty old’ firmware is less compatible with much more up to date (0.84.6) HA. So I went looking in the change log. Searched for ‘xiaomi’ up until version 0.65.0.

In 0.74 I found a related item:
Fix confused brightness of xiaomi_aqara gateway light (@amelchio - #15314) (light.xiaomi_aqara docs)

Yet it doesn’t seem like this patch was necessary because something changed in the gateway firmware and of course with you metioning the same kind of problems, it seems to be firmware version unrelated.

I did notice my HA also seems to lose connection with the Philips Hue bridge sometimes, but that never breaks things. Just ‘unavailable’ for a few seconds. It’s a bit weird since I never experience network problems here. High quality STP cables are being used.

Since an hour I am doing manual discovery for the Philips Hue bridge and disabled discovery in configuration. Let’s see what happens.

My next test will be an automation to turn on the Gateway Light for 1-2 sec every hour, see if it won’t become unavailable then. Kind of a ‘keep alive’ trial.

What is your setup @h4xxx?
I am running in Docker on Raspberry Pi 3 with DietPi operating system.


#7

I just found something odd.

Have a look:

12:48 Home Assistant started
15:18 Gateway Light changed to unavailable

16:00 Home Assistant started
18:30 Gateway Light changed to unavailable

19:47 Home Assistant started
22:17 Gateway Light changed to unavailable

3 samples and in all of them it is exactly 2,5 hours after starting HA that the gateway light becomes unavailable. Can you reproduce this @h4xxx?

Some more logs:

Here I turn on the light via the Mi Hub app on iOS:

2019-01-18 22:47:38 DEBUG (Thread-2) [xiaomi_gateway] MCAST (report) << {'cmd': 'report', 'model': 'gateway', 'sid': '(removed)', 'short_id': 0, 'data': '{"rgb":1694498815,"illumination":333}'}
2019-01-18 22:47:39 DEBUG (Thread-2) [xiaomi_gateway] MCAST (report) << {'cmd': 'report', 'model': 'gateway', 'sid': '(removed)', 'short_id': 0, 'data': '{"rgb":1694498815,"illumination":333}'}
2019-01-18 22:47:39 DEBUG (Thread-2) [xiaomi_gateway] MCAST (report) << {'cmd': 'report', 'model': 'gateway', 'sid': '(removed)', 'short_id': 0, 'data': '{"rgb":1694498815,"illumination":407}'}

Here I turn it off:

2019-01-18 22:48:12 DEBUG (Thread-2) [xiaomi_gateway] MCAST (report) << {'cmd': 'report', 'model': 'gateway', 'sid': '(removed)', 'short_id': 0, 'data': '{"rgb":0,"illumination":1041}'}
2019-01-18 22:48:12 DEBUG (Thread-2) [xiaomi_gateway] MCAST (report) << {'cmd': 'report', 'model': 'gateway', 'sid': '(removed)', 'short_id': 0, 'data': '{"rgb":0,"illumination":969}'}

#8

I am currently away, I will check in 2 days and let you know. Thanks for the update


#9

the 2.5hrs is a built in variable of the xiaomi component when it cannot contact the device. there are numerous posts on this


#10

Thanks, didn’t thought any further yet than the number itself.
To me, especially with the behaviour described in the topic start, this is a ‘bug.’ Will report soon.


#11

As @aidbish wrote there are many posts about this. You should do some reading


#12

Thanks, I did found stuff like that weeks ago. The difference is that my sensors keep working perfectly. The Mi Hub light/illumination is the only problem, not only concerning connection but also it’s behaviour in the first 2,5h, as described in the topic start.

Lot’s of the things said in that topic I have applied already, like Mi Hub has a static IP, MAC is called for in the config, interface is set to the one in the same subnet as HA, the PyXiaomiGateway component seems present.

HA is able to receive any Mi Hub sensor data (that’s one way) and in the first 2,5h it is able to control the light (that’s the second way), although buggy. Multicast is reported to be enabled on both Docker host and HA container adapters (some overlap ofc.). So I don’t know what would be wrong network-wise.

Trying echo 0 > /sys/devices/virtual/net/docker0/bridge/multicast_snooping on the Docker HA host now. Main router already has it set to 0. But this should not be necessary since, as said, sensors keep working.


#13

I am still having the very same issue. Even though the gateway is reported as unavailable after the 2h 30min timeout, the sensors continue to work.

The gateway is on the same subnet, multicast appears to be working as the gateway is found without issue.

The router firewall has no rules set up for internal traffic


#14

I would also like to stress that unlike the issue described at length in the above linked topics, for this issue the sensor data (which is reported in multicast afaik?) is working correctly.

Hass is receiving updates from sensors connected to the gateway, even when gateway reaches the timeout.


#15

@h4xxx did you solve it? i have same problem.


#16

@h4xxx @Rodolfo_Vieira

I opened a bug report. It would help if you also post there that you have this same issue.


#17

I have now updated your bug thread. It seems we are running pretty different setups as I use hass.io primarily and have set up a windows based python-virtual evnvironment home assitant installation for debugging of this issue and both suffered the same issue. We also have different gateway firmware version but the very same gateway hardware - which seems to be the common theme.

What is your gateway HW @Rodolfo_Vieira?


#18

@h4xxx i use hass.io , my fw is 1.4.1_164 and hw_ver is MW300 model lumi.gateway v3


#19

@Saturnus added to your created issue on github too…


#20

So, I think this quick and dirty fix will help. I’ve checked it on 1.4.1_164.0158 firmware and HA 0.87.0

Don’t forget to backup files!
Right now I have no other xiaomi sensors, so can’t check. But I hope they should work as usual.

  1. Enable polling.

Find this code in the xiaomi_aquara component (xiaomi_aquara.py)
In my venv it’s located here at /opt/homeassistant/lib/python3.6/site-packages/homeassistant/components/

    @property
    def should_poll(self):
        """Return the polling state. No polling needed."""
        return False

And change False to True

    @property
    def should_poll(self):
        """Return the polling state. No polling needed."""
        return True
  1. Illumination sensor still does not change the value, no matter we turn light or not.
    Let’s add update def for sensor.
    File is nearby: ./sensor/xiaomi_aquara.py
    def update(self):
        """Get data from hub."""
        _LOGGER.debug("Update data from hub: %s", self._name)
        self._get_from_hub(self._sid)
  1. Next code is for light ./light/xiaomi_aquara.py

This might not needed, but it’s quick and dirty :slight_smile:

Add this to turn_on and turn_off defs:

self.schedule_update_ha_state()

Result should be like this:

    def turn_on(self, **kwargs):
        """Turn the light on."""
        if ATTR_HS_COLOR in kwargs:
            self._hs = kwargs[ATTR_HS_COLOR]

        if ATTR_BRIGHTNESS in kwargs:
            self._brightness = int(100 * kwargs[ATTR_BRIGHTNESS] / 255)

        rgb = color_util.color_hs_to_RGB(*self._hs)
        rgba = (self._brightness,) + rgb
        rgbhex = binascii.hexlify(struct.pack('BBBB', *rgba)).decode("ASCII")
        rgbhex = int(rgbhex, 16)

        if self._write_to_hub(self._sid, **{self._data_key: rgbhex}):
            self._state = True
            self.schedule_update_ha_state()

    def turn_off(self, **kwargs):
        """Turn the light off."""
        if self._write_to_hub(self._sid, **{self._data_key: 0}):
            self._state = False
            self.schedule_update_ha_state()
  1. Restart HA and wait 2.5 hours :slight_smile:
  2. Check traffic by ngrep. You should see read and read_ack every 30 sec.