Xiaomi Aqara Devices Frequently Unavailable

alright, i will try moving it to another locaton. right now i have an access point right above the GW.

They maybe different, but can still overlap, if you can see in the gateay which channel its on, you can try and move your wifi channel to be further away.

Have a look at my post further up and check out the links, it can show you how the channels overlap

Alright no problem. I’ve physically moved the GW to a more central location and checked the channel. My GW is on channel 25 and my 2 access points are on channels 1 and 6. I also changed the key 3-4 times. I’ll keep monitoring what’s going on. I’ve deployed build 0.70 to see if anything helps as well

Nice that your Zigbee channel is all the way over there, so channel 1 and 6 WiFi shouldn’t overlap

Hi,
I’m using a ConBee stick with Deconz as Zigbee platform.

in my experience the Aqara sensors (door/temperature) seem to have an inferior range compared to the Xiaomi Mi sensors despite their almost identical look.

I had issue a range issue with door sensor (became unavailable after a few days and never came back). Switched it out against a XIaomi door sensor and never had any issues since.

And I see the same thing with my temperature sensors. While some of the Aqara sensors sometimes don’t report values (probably range issue) my Xiaomi temp sensor is stable.

So, I would personally favor the Xiaomi Sensors. The door sensor is also easier to use since it does not require minimal gaps between the magnet and the sensor and thus allows for a more flexible placement.

1 Like

so i did end up moving it further from my AP and regenerated the code 4 times. So far its been holding up for the past 3 days without issue. Hopefully it stays like this.

Kirichkov, already answered why they are showing unavailable.

Anyone have a clue why all my Binary Sensors hooked up to the Xiaomi Gateway are not showing up in HA? I have a mix of first and second gen. motion sensors, leak detectors, and temperature sensors. The temp sensors work fine, the motion and leak sensors just stopped reporting to HA. They are working correctly in the Mi app.

I noticed this behavior after updating from HA 61 to 70. I haven’t updated anything in the Mi app.

Do you have the correct component for xiaomi listed in configuration.yaml
xiaomi_aqara

it may have changed from the version u had before upgrade

WiFI interference?

xiaomi_aqara:
  discovery_retry: 10
  gateways:
    - key: !secret xiaomi_key

The key matches that in the Mi app. Now on HA 71 but the problem persists.

Is there anything in the communication protocol that would be different between the temperature/luminance sensors and the motion/leak detectors? The luminance sensors are working fine and they are literally embedded into the motion detectors that aren’t working.

Are the motion detectors supposed to auto-discover and create binary sensors that can be seen in the states panel? That’s how I believe it used to work, there hasn’t been a change to that has there?

The only thing i can suggest is regenerate the LAN key on the gateway. I have had it where i have had to regenerate when an update has happened on the gateway. (best to perform lan key retrival on android devices as getting from IOS seems hit and miss)

Failing that, reset gateway and re-add devices?

Had exactly the same issue when all sensors started loosing connection. I think it started after I enabled Bluetooth add-on and added the following code to the config:

device_tracker:

  • platform: bluetooth_tracker

Tried to enable mi flora component, which doesn’t work with hassio.
So after I removed the code it started working again.

1 Like

im having this issues in non aquara sensors in last 0.80.1 the aquara sensors are working ok!

On which sensors does that happen to you? Same happens at least to me for motion/illumination sensors. Everything else seems fine.

I think i’m having same issue since y change from Hassio (resinos based ) to Hassos and i enabled bluetooth _tracker.

Besides , i notice all aqara motion sensors doesn’t work when i config HA on raspberry ethernet interface (Wireless interface works fine).

Any one has same issue or knows how to solve it (i’d rather using ethernet connection in order to improve pi_hole DNS server response time)?

I have the same issue since installing hass io.

  • Pi 2 with official current hass os.
  • Pi 2 using built in ethernet port
  • single xiaomi gateway
  • aqara devices always available in Mi Home, but always unavailable after 6-7 hours in hass.io whether they’re operated during that time or not.
  • hass.io reboot makes them available again for 6-7 hours.

I tried everything in this thread, no fix.
Oddly, when i regenerate the key in Mi Home, close the app and return, the key reverts back to the old key. Not sure if this is related.
Also getting ERROR (SyncWorker_17) [xiaomi_gateway] Got error element in data {“error”:“Invalid key”} at least once before the devices become unavailable.
Used to get these errors a lot before adding interface: ‘192.168.0.15’ in the xiaomi_aqara section in configuration.yaml.

Anyone have any other ideas?
Thank you

PS - same problem happening on a Pi 3B+. Strongly considering moving to OpenHAB :frowning:

Why this IP?

That was Home Assistant’s eth0 IP on the network. The thought was that maybe it’s not listening on the right interface.

I tried OpenHAB, similar issues. Decided Home Assistant was much more straight forward to set up with Aqara.

Bought a Pi3 B+ in case it was something software related, same issues.

Then I brought the whole setup to my work office, to test on the corporate network and suddenly everything was working perfectly!

The problem was my router. It’s a ZTE ZXHN H298N as supplied by Hyperoptic ISP in the UK.
The router was either filtering out or just ignoring the status messages from the Xiaomi Gateway.

I replaced it with a TP-Link AC1750 Archer C7 (no reason other than same day Amazon delivery :slight_smile:) and it worked solid out of the box. Console now full of Xiaomi sensor status updates and no authentication issues.

I’m very happy. (well, not happy I had to buy a new router!)

1 Like