Aqara Door Sensors dropping connection

I installed three of these Aqara door sensors a little over a week ago: Aqara Door and Window Sensor, Requires Aqara Hub, Not Support Hubs from Other Brands, Zigbee Connection, Wireless Mini Contact Sensor, Compatible with Apple HomeKit, Alexa, Works with IFTTT (3 Pack) - Amazon.com

My HA network is running only ZHA starting from a SMLIGHT SLZB-06M and a mesh of about a dozen of these SONOFF smart plugs: SONOFF Zigbee Smart Plug with ETL Certified, S40 Lite 15A Smart Outlet, Zigbee Repeater, Works with SmartThings and Amazon Echo Plus, Hub Needed for Amazon Alexa 4-Pack - Amazon.com . I moved to channel 25 because the coordinator showed quite a bit less RF energy there than around ch 15. Scans this morning show that continuing with ch 15 just touching yellow (whatever that means) and 25 deeper into the green.

The door sensors paired pretty easily, and worked as expected. Really, everything I have tried so far seems to be pairing and working pretty easily including an Inovelli switch, a Moes remote and a Jinvocloud outlet strip.

The first problem: after about 36 hours, one of the door sensors went “unavailable.” I waited 24 hours and it didn’t come back spontaneously, so I pressed it’s button until the light flashed, it reconnected and ran fine for another 36-ish hours. The other two door sensors were working fine, 100% as expected.

Now, this morning, about 6 days after initially installing the door sensors, two of them are Unavailable and so far at least, pushing their buttons causes the lights to flash, but neither one is reconnecting. They were working as expected last night, but “went missing” around 3:20am according to the logs.

Looking in the SLZB-06M coordinator logs, I see this:

[02:20:04] taskZB | Client disconnected, id: 0
[02:20:06] taskZB | New client: 192.168.67.70 id: 0
[02:20:06] EventSender | [_handleNewClient] new client: 192.168.67.70

which corresponds with its Z2M/ZHA uptime of about 8 hours. The device uptime is over 20 hours, I did a manual firmware update on the SLZB-06M about 2pm yesterday, everything seemed to be working fine after the restart.

All I can guess is that the ZHA restart at 2:20am somehow lost the door sensors and they didn’t show up as missing until about an hour later?

But why, then, don’t they reconnect?

Somewhere, in Home Assistant I think, there’s a timeout interval for battery devices (and a shorter one for wired devices) - would it be worth extending that time to hopefully prevent dropping connection in the event of a missed “heartbeat”?

Any other suggestions are most welcome… I just want working door sensors.

Apologies, I have only been working with ZigBee devices for a couple of weeks.

Both door sensors did reconnect when I put Home Assistant Devices ZigBee Add Device active while putting the sensor in pairing mode.

Still leaves the question: why are they unpairing every few days in the first place?

Batteries report 84 to 100%, signal strength seems good, though the door sensors are connecting to smart outlet repeaters instead of the controller.

When you go into the sensor properties enable the RSSI option and show us what value it is.

I’ve had a simliar issue with a SLZB-06 zigbee stick. Certainly more erratic in losing their pairing although it seems to have died down a bit now after a few months.

Try this:

  • Unpair one of the door sensors from ZHA.
  • Go to the device page of the zigbee router which is closest to the door sensor’s final location.
  • Click the 3 dots next to Reconfigure > Add devices via this device.
  • Add the door sensor via the router instead of the coordinator.
  • Monitor for a couple of days - if it works, repeat for the others.

They were already on the closest smart plugs, like 8’ away with clear line of sight.

One is -84, two are -75 RSSI, what is considered marginal?

The SLZB-06 has a topology view that shows the sensors connected to smart outlets nearest them, when they are connected.

Nothing looks out of the ordinary in your setup.

Are you sure it’s not the routers that are dropping the connection, rather than the sensors?

Anything in the ZHA logs?

You need to improve the signal strength… that is the issue.

For reference these are all my current RSSI numbers in my setup:

Well, how far apart are your battery powered devices from the nearest repeaters? Mine are an average of about 12’ (4m), it seems a little unreasonable to expect closer than that?

I might have some bad news for you. Might be the S40 Lites that are causing your low RSSI values and your disconnection issues. Sonoff S40 Lite a disappointment

Might be the S40 Lites that are causing your low RSSI values and your disconnection issues.

And what would be better?

As for the S40s themselves, they have been 100% reliable so far - I stretched them to the limit with distance and intervening walls, and got some slow responses, but as deployed the switches themselves have been quite trouble free.

Now, their reported RSSI and LQI values are in the toilet, but RSSI isn’t traditionally a good absolute measurement in any application I have ever encountered it. It’s good to judge changes, but the number by itself is a terrible thing to base good vs bad on.

That, my friend, is your problem. If the S40s were already stretched to their limit before they were being used as router devices, adding end device traffic through them will definitely not make your mesh any more stable.

If you have an IKEA nearby, they make dedicated ZigBee router devices. I would slap in a couple to see if it improves things. Note that some IKEA devices have been reported to not play nice with Aqara, though that might only apply to their plugs

Less than 4m for in home devices as I have 3 hue bulbs (the two bedside lamps and the corner lamp in the lounge room), 1 hue led strip and a generic smart plug acting as routers for devices not at my rack in the lounge room.

The laundry room switch is 1 level below through brick as its in a shared laundry room to prevent someone from stealing power in the event the lock is broken.

So, you misunderstand: as a test I stretched them to the limit - much farther than where they sit now.

I have another SLZB-06 on the way to setup as a repeater in the 2nd building - not that I’m having noticeable issues with the switches over there, but it is the weaker side of the network and I already have PoE in there so adding a router is super easy.

24 whole hours with no door sensor drops now (since the 3 minute power company blackout yesterday). 2 weeks since I setup the system with no problems in any of the other devices.

This is one of the door sensors that dropped - the LQI and RSSI graphs appear identical, I suspect they’re using a direct linear transform one to the other:

That is all over the place to say the least here is the one for my bathroom door which is the furthest away from my skyconnect:

and here is its RSSI for reference:

I ran a quick test with my skyconnect and plugged into the powered usb3.0 hub I have plugged into my nuc just to sanity check things and my RSSI for devices shot up to -70 vs with the skyconnect being plugged in directly with the values as shown previous, both the hub and direct are using the 2 front ports on the nuc.

One main difference as well is that plugged in directly the skyconnect has the HA logo up where as when plugged into the hub its facing down.

Was just something of note to add to the various discussions when it comes to RSSI quality and deciding if you need more routers in the mesh or not based on how your current setup is connected to your host device.

I have decided that the metric that matters is how many times a device goes “unavailable” in the logs, and for how long… Also: unless performance is dismal, leave things in place for 2-3 days to “settle out” before trying to improve them.

LQI values seem mostly tied to RSSI, and while absolutely dismal RSSI (or LQI) indicates a problem, moderate to very strong RSSI doesn’t seem to indicate lack of a problem. Problems indicate problems…

One weird result I got was: by moving my controller 80cm closer to a cluster of 4 relays about 4 meters away and re-orienting its antenna from vertical to horizontal, reception in those relays got much weaker, but still mostly working, while the rest of the network improved dramatically.