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:
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.
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.
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:
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.
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.
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.
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.
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.
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
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)
Next code is for light ./light/xiaomi_aquara.py
This might not needed, but it’s quick and dirty
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()
Restart HA and wait 2.5 hours
Check traffic by ngrep. You should see read and read_ack every 30 sec.
