Aqara Door and Window Sensors Go Offline Despite Proximity to ZigBee Repeater

Devices & Integrations
1

I’ve been setting up some Aqara Door and Window Sensors (the E1 style shown below) with the ZigBee Contact Mc edge driver. I paired four sensors next to my ST hub and installed them on windows. Two work perfectly but the two that are furthest away from the hub don’t respond to window open or close actions and eventually go offline. I unplugged the ST hub for 20 minutes for force a ZigBee mesh heal to that didn’t help.

I deleted the devices, reset them, and installed a ST ZigBee outlet as a repeater right next to the window and checked that it responds ok. I tried to pair the sensors next to the ZigBee outlet without success. I then paired the sensors next to the ST hub once more and moved them back to the window but once again, they don’t respond. I once again forced a ZigBee network heal by unplugging the ST hub but these two sensors still don’t work and don’t seem to be routing through the ZigBee outlet.

I don’t know what else to try - anyone have any ideas?

image

1 Like
2

Does the outlet stay online?

Typically when I think I’m having range problems, I will add a new repeater about halfway between the current device That’s having the problems and the next available repeater. If the issue is that the sensors were right on the edge of range, then the outlet is likely to have the same problems if you put it in about the same location. :thinking:

3 Likes
3

Yes, the Outlet stays online and can be switched without problems. Do powered outlets have more powerful ZigBee transmitter/receiver hardware though I wonder? In any case, I followed your advice and installed a second ZigBee outlet about halfway between the first one and my ST hub. Finally I then paired an ST contact sensor and put that temporarily in the same window as the Aqara sensors for comparison and that is working just fine but the Aqara’s are not. Interestingly though, whilst neither Aqara sensor is reporting open/close events, one was showing as Offline (I read somewhere that they might do that as they report infrequently) and when I opened the window, it went online, though still not reporting open/close events. Curious.

Edit: I’ll force another ZigBee mesh repair and see if that helps…

4

@black-paladin

Pair the devices and put them in place.
Place the repeaters and let the mesh reconfigure itself, patiently.

Zigbee devices usually find their way and change routes following their own rules.

The repeaters will send messages every 5 minutes to the hub and nearby devices end up realizing that they have neighbors. I don’t know if the aqara will be different in this, but with Tuya and others it works.

You can wake them up from time to time by opening and closing

2 Likes
5

Not typically, most devices broadcast at the max power allowed under their profiles. The Mains power devices just stay awake while the battery powered devices sleep most of the time. :sleeping:

1 Like
6

Ok, they are all paired an in place. After a forced ZigBee mesh rebuild, the repeaters and ST contact sensor are working fine but the two Aqara sensors are not responding and one has now gone “offline”. I will be patient and just leave them for a day or two.

Thanks, that’s useful to know. I’ve been trying to learn about ZigBee. I had hoped to be able to map the mesh somehow but I gather that’s not easy. I think you used to be able to see the next “hop” in the mesh from a device in the old IDE but I can’t see how I can check that now.

I was going to say “surely they would all behave exactly the same” but I’m getting older and a little bit wiser :slightly_smiling_face:

1 Like
7

It’s a bit tricky if the issue is the child device not communicating often enough and the platform incorrectly marking the device is unavailable.

Since the child device can always reach its parent, it doesn’t think there is anything wrong, so it doesn’t look for a new route.

So while it’s true that zigbee is self-healing if a router goes off-line, it honestly doesn’t pay very much attention if an end device goes off-line. After all, it might just be a battery powered sensor getting new batteries.

The off-line check is something unique to the smartthings platform which they have created for themselves. The Zigbee profile being used says that devices should check in once an hour, but some of the devices will do it at the start of the 60th minute and that can throw off the smartthings algorithm. So there is definitely a difference between different models. And it’s also why the devices don’t have any trouble staying connected to their own brands hubs.

So sometimes it’s just trial and error until you find a configuration that works well for you.

1 Like
8

@black-paladin
These devices are sent the default configuration like switches, sending reports at 5 minute intervals.

I would like to see the pairing logs to see if it is accepted by the device.

In case anyone is interested, this is my experience. I have spent a lot of time looking may logs, firmware lua zigbee libraries and trying with several devices to understand a little about the offline and online process on zigbee devices and I have managed to identify two different cases.
This was the case until recently, but may have changed at any time without notice.

As an example, for devices that have configured some attribute with reports of maximum intervals of 5 minutes:

  • If the device remains offline after about 23 minutes, the reports are not received every 5 minutes, but if the sensor opens or closes, it will be marked online:
    When no reports are received from the attribute for 1.5 times the configured interval, (about 8 minutes), then the Health check is started and the attribute is read every 8 minutes for a response.
    If the reading is not answered twice, 16 minutes, it is marked as offline and the attribute continues to be read indefinitely or until a message from the attribute is received, then it is marked online and the process is reset.
    If a message is received from another attribute, battery for example, then it is also marked online but the health check process continues for the attribute that does not answer and it will be marked offline again after the established time.
    In these cases, it is not a signal problem, it is a configuration not accepted by the device.
    This is the case with some Sonoff sensors, they do not accept the IASZone configuration (300 sec interval) and the solution is to configure the battery attribute to report at intervals less than 12 minutes, the stock driver configures it every 10 minutes. But you have to pair it directly with the stock driver, a driver change is not worth it
    Something similar also happens to some TS0207 water detectors or some Heiman smoke or CO sensors.

  • If device is marked offline and it is not return to online again when the sensor is opened or closed, then it is more of a zigbee network problem, weak signal, … and it should be possible to solve it with zigbee repeaters or rebuilding the zigbee mesh

Reviewing the data I had, zigbee devices powered by external energy, light bulbs, plugs, switches are marked Offline after 20 or 25 minutes without receiving messages.

Zigbee devices powered by battery, smoke, contact, fingerbot, … are marked Offline after approximately 2 hours 30 minutes without receiving messages from the device

For zwave devices, I do not understand what the offline marking process is, since the externally powered devices do not send periodic reports and are not read it periodically, they are only read after a command is sent to device or a refresh command is performed and their status is updated.

The battery-powered zwave devices have a wakeUp interval established, and it can be understood that this interval is taken into account to mark it offline.

What I have noticed is that some zwave devices that are working fine, if I change the driver, for example to zwave thing, when you go back to the original driver they start to be marked offline and they are marked online when wake it up or do some action on it.
The solution, exclude it and pair it directly with the driver again.

2 Likes
9

That’s interesting and got me digging around some more and I found a post from @veeceeoh who had written a DTH for Aqara/Xiaomi devices:

Based on this, my ST branded outlet repeaters might actually be part of the problem rather than the solution. I’ve ordered a Tradfri outlet from Ikea to see if that helps, though delivery is 6 days away, time enough to see if the ZigBee mesh heals itself somehow.

4 Likes
10

Yet more interesting material. In case you are interested, of my two identical window sensors (same window frame, one on the left window and one on the right), “Left” is showing “Closed” and “Right” is showing as “offline”, with both paired a few minutes apart. The very useful Signal Metrics in your edge driver tells me that Left has LQI:152 & RSSI:-91 (reported 2 hours ago) and Right has LQI:134 & RSSI:-92 (reported 3 hours ago). I’m new to signal metrics but from what I’ve read, those are poor signals and I’m suffering from your second case, a ZigBee weak signal.

I just tried opening the windows again and Left now appears to be working normally. Right remains offline however. Perhaps the mesh is healing itself? Or perhaps a weak signal is sometimes working and sometimes not working?

Which logs exactly would you like to see? Do you mean the CLI logs from your driver whilst I (re)pair one of the window sensors?

11

Yes, they are low intensity signals and about 50% lqi quality

Yes, to confirm if the device accepted the configuration

1 Like
12

@black-paladin
Every time driver receive an open/close message, the signal metrics will be updated, every 5 minutes

You can activate in preferences that the metrics are shown in the history and you can analyze how they trend

1000012505
1000012505864×1920 114 KB

1 Like
13

Your signal is weak, any Aqara contacts, motions and leak sensors that I have are all at LQI:254 & RSSI:-65 or better. When first using them any with rssi:-75 would always go offline especially if the hub was rebooted.

I added some Sengled plugs to beef up my signal strength. I am also of the opinion that especially with the Aqara devices to pair them in place. if they don’t connect then they will not stay on line in that location if you pair at the hub and move them. I will also say that the problems are not as bad now as the were earlier in edge.

3 Likes
14

Got it, thanks. Hopefully some Tradfri outlets will similarly beef up my ZigBee mesh.

1 Like
15

I was going to suggest the ikea tradfri plug. I use it as a repeater for my Aqara sensors and chose it based on the discussions you found. I also found that the Keen Smart Vent Bridge will play nice with Aqara sensors.

4 Likes
16

Useful, thanks. I turned on metrics logging last night. This morning the “Aqara Left” sensor and “ST Test” sensor looked normal and “Aqara Right” was showing offline. I opened all three and all reported correctly, and “Aqara Right” no longer shows as offline, so everything is working - for now at least. Signal metrics LQI trends are:

  • ST Test: 172 (on open), 172 (on close) … 176, 202, 198 (three most recent readings from the 5 minute log events)
  • Aqara Left: 170 (on open), 166 (on close), no log events since then
  • Aqara Right: 90 (on open), 104 (on close), no log events since then

So, it would seem:

  • Aqara Left LQI has improved and is now the same as ST Test, which implies it has somehow picked up a new mesh route despite not yet having a Tradfri repeater
  • Aqara Right LQI has got worse yet the sensor is now reporting open and close events for the first time

Which just leaves me confused :thinking:

Later today I will delete and try and pair the Aqara Right sensor in place at the window (though this failed before) and if that fails, at the hub, with CLI logging running on your driver @Mariano_Colmenarejo .

Thanks all.

17

Ok, so I deleted the “Aqara Right” sensor, reset it, tried to pair it in place on the window, and that worked first time. A few open and close events worked just fine with LQI values in the range 182-214. By comparison, “Aqara Left” is still working fine, though reporting lower LQI values in the range 108-182. My “ST Test” device also continues to work with LQI values in the range 176-204. So everything is now working. So it seems (re)pairing the “Aqara Right” sensor in place on the window, instead of at the hub, means it is now using the same/similar route as “ST Test” using the ZigBee repeaters.

@Mariano_Colmenarejo : Although everything is now working for me, I did record a log if you wanted it and I did notice one recurring WARN message which might interest you:

WARN Zigbee Contact Mc  Encountered error calling can_handle for dispatcher defaulting to false: [string "smartsense-multi/init.lua"]:40: attempt to index a nil value (field '?')

Tentative conclusions and summary of the collective advice and actions in case others stumble across this:

  • Being able to get signal metrics from @Mariano_Colmenarejo 's ZigBee Contact Mc sensor has been really useful
  • Additional ZigBee repeaters help, and it’s best to install them before the end point devices
  • Despite the many comments elsewhere about requiring Sengled or Tradfri repeaters, it appears that my SmartThings/Aeotec outlets are working fine with this particular Aqara Door and Window sensor (Type E1)

Thanks for all your help here. Time to press on and install sensors on the other 25 windows now, once I’ve installed a few Tradfri repeaters first of course :slight_smile:

I have just one final question: it would be very useful to get some insight into the mesh network and whilst I understand that a whole map is complex, is there any way to just see which router or coordinator a ZigBee device has as it’s first hop on the mesh?

1 Like
18

Don’t worry, the smartsense-multi subdriver is an error, it also happens in the stock driver and then the error disappears.

but I’ll remove it, it’s useless

1 Like
19

One note…

The specific device named “tradfri signal repeater” from IKEA is a really low power device intended just to get signal to their window covering devices. Lots of complaints about it when used for any other purposes.

The tradfri smartplug, on the other hand, has generally been reported as working well as a Zigbee repeater in a smartthings set up. There have been a few individuals who have had some problems, but that’s true of pretty much every model from every brand. :thinking:

2 Likes
20

Ah yes, good point. I have ordered the “Tradfri Control Outlet” (IKEA article number 003.644.77 in the UK) and not the “Tradfri Signal Repeater” (IKEA article number 804.242.55 in the UK). That said, I actually have a spare Signal Repeater that came with a Fyrtur blind that is now directly paired with SmartThings. I’ll experiment with it as my “Aqara Right” sensor has now gone offline again and can’t be woken despite behaving perfectly earlier :roll_eyes:. Even if weak, I’d hope the Tradfri Repeater could at least pick up Aqara sensors that are 2m away and relay to a ST Outlet that is only 10cm away.

1 Like