Xiaomi & Aqara Devices - Pairing & Keeping them connected

Hehe, I picked 11 for the same reasons!

This was a network scan of my environment provided to me when I was using Systronics RF.

Okay, maybe I'll go with 20 (went with 25) and see where we get to.

1 Like

As a side comment here, Aqara/Xiaomi gateways run on either channel 15, 20 or 25. Their devices should work on other channels, but I have only ever run them on one of these 3 channels.

1 Like

Okay, based upon the neighbouring wifi noise around here I'm going to use channel 25 and move my wifi network to channel 6. Let's see how that works.

When changing channel there is a high likelihood your Xiaomi/Aqara devices will fall off, just re-pair and they will come back, no need to delete the device in HE before pairing again. There are plenty of guides on how to best change channels and to get your mesh back in a good condition again, so I will not repeat that part :wink:

2 Likes

I have been using Xiaomi devices for years first on Smart things and now since the beginning of Hubitat. I am using @veeceeoh drivers because I haven't changed to these yet.

Anyways I am on channel 11 and don't have any issues. I have a ton of Xiaomi's sensors but I am using @iharyadi sensors as my gateways.

3 Likes

That is good to know, due to the issues with Xiaomi/Aqara I always aim at replicating their environment as much as possible within the limitations of HE and what a driver can do. I don't have devices falling off and haven't had issues of that type except when I was first setting up my mesh, once stabilized it has been rock solid. That they can operate well on a channel other than the three used by the original gateways is great to have confirmed. It leaves more options available.

1 Like

Quick update; for good measure I hard reset the hub and set everything up from scratch.

My initial setup is now on Channel 25 with my wifi bumped down to Channel 1.

I have three IKEA Tradfri Repeaters, one by the Hub, one here in the study on the first floor and one up in the loft (attic) in this three-story townhouse. I've got two WXKG03LM wireless wall switches and one WXKG11LM button connected using @markus's driver and to show things were working (or otherwise) I rolled the dice on connecting a Salus SP600 outlet using the SP600 driver made by @martyn and modified by @Geoff_T. I've thrown the driver onto my GitHub there as I kept losing track of it.

/hub/zigbee/getChildAndRouteInfo gives me:

Parent child parameters
EzspGetParentChildParametersResponse [childCount=1, parentEui64=0000000000000000, parentNodeId=65535]

Child Data
child:[Test Wireless Switch, 1621, type:EMBER_SLEEPY_END_DEVICE]

Neighbor Table Entry
[Study Repeater, 76BD], LQI:255, age:3, inCost:1, outCost:1
[Main Repeater, 7EDA], LQI:255, age:3, inCost:1, outCost:1
[Test Plug, 7EFE], LQI:255, age:3, inCost:1, outCost:1
[Loft Repeater, 8423], LQI:254, age:3, inCost:1, outCost:7

Route Table Entry
status:Active, age:64, routeRecordState:0, concentratorType:None, [Hallway Wireless Wall Switch, 140D] via [Study Repeater, 76BD]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Test Button, 8DF2] via [Study Repeater, 76BD]
status:Active, age:0, routeRecordState:2, concentratorType:Low Ram, [Test Plug, 7EFE] via [Test Plug, 7EFE]
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused

So far this is better than the previous configuration for these battery devices. They're working pretty much reliably now, albeit with a few hiccups where the outlet will be toggled on, then off, then back on again.

Oddly the smaller WXKG11LM button has been faultless; it's only the WXKG03LM sitting next to it that has shown that odd behaviour and I am, at the moment, still getting occasional lost presses from it. Perhaps I need to give the mesh more time to settle, but given there are so few devices that feels a little odd.

Given the experience I had before I don't think I'll be adding any V1 devices to this network, unless I decide to do a complete reset again. I'm vaguely tempted to see if the SP600 outlets will hold up the network on their own, as they are reportedly an excellent strength repeater and it might be useful to other UK owners given the limited choices we have on some of these products.

Would anyone like me to give that a try while I'm still testing?

This latest setup is proving so reliable that I'm loathed to toy with it. I will be buying another Hub to support my Iris V1 devices, so I will test the Xiaomi devices with SP600 outlets with it before putting it into service... once I can find one!

What I will say is that a couple of Xiaomi devices have now chosen the SP600 outlets as their route to the Hub and are working perfectly. One of which is the Cube, which I've heard is supposed to be a tricky one to keep happy.

Parent child parameters
EzspGetParentChildParametersResponse [childCount=1, parentEui64=0000000000000000, parentNodeId=65535]

Child Data
child:[Test Wireless Switch, 1621, type:EMBER_SLEEPY_END_DEVICE]

Neighbor Table Entry
[Festoon Lights, 11C3], LQI:6, age:7, inCost:7, outCost:0
[Study Repeater, 76BD], LQI:255, age:4, inCost:1, outCost:1
[Main Repeater, 7EDA], LQI:255, age:4, inCost:1, outCost:1
[Study Desk Outlet, 7EFE], LQI:254, age:4, inCost:1, outCost:3
[Loft Repeater, 8423], LQI:239, age:1, inCost:5, outCost:7
[Garage Twinkly Lights, 9543], LQI:184, age:4, inCost:7, outCost:0
[Study Workbench, A1A6], LQI:255, age:4, inCost:1, outCost:1
[Living Room Lamp, DECC], LQI:255, age:4, inCost:1, outCost:1
[Living Room Console Outlet, FE43], LQI:255, age:4, inCost:1, outCost:1

Route Table Entry
status:Active, age:64, routeRecordState:0, concentratorType:None, [Hallway Wireless Switch, 140D] via [Living Room Console Outlet, FE43]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Study Button, 8DF2] via [Study Repeater, 76BD]
status:Active, age:32, routeRecordState:2, concentratorType:Low Ram, [Study Desk Outlet, 7EFE] via [Living Room Console Outlet, FE43]
status:Active, age:32, routeRecordState:2, concentratorType:Low Ram, [Garage Twinkly Lights, 9543] via [Study Workbench, A1A6]
status:Active, age:64, routeRecordState:2, concentratorType:Low Ram, [Festoon Lights, 11C3] via [Study Workbench, A1A6]
status:Active, age:0, routeRecordState:2, concentratorType:Low Ram, [Wall Twinkly Lights, E341] via [Study Workbench, A1A6]
status:Active, age:32, routeRecordState:2, concentratorType:Low Ram, [Study Workbench, A1A6] via [Study Workbench, A1A6]
status:Active, age:0, routeRecordState:2, concentratorType:Low Ram, [Living Room Console Outlet, FE43] via [Living Room Console Outlet, FE43]
status:Active, age:32, routeRecordState:2, concentratorType:Low Ram, [Living Room Lamp, DECC] via [Living Room Lamp, DECC]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Study Cube, 34F3] via [Living Room Lamp, DECC]
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused

Yes, the LQI on a couple of those is awful, but they're at the bottom of the garden and working!

Sad times.

I was very hopeful that the Salus SP600 outlets were going to be Xiaomi compatible, given the initial success. However, after 2 days connected without problems, the battery devices have started to drop from the network again.

I don't know if it's the same for anyone else, but I've found that the QBKG03LM and QBKG04LM wired wall switches are very solid regardless of the routers. They've been happy for extended periods on AlertMe V1 Outlets, SP600 and Hive Active Plug. It's those sleepy WXKG and MFKZ battery devices which spoil the party.

I'm going to zap this install one last time and dedicate this hub to only Xiaomi equipment and Tradfri Repeaters. I know that's the golden advice from you all, I just couldn't help testing out some combinations in hope.

1 Like

And why not? It costs nothing to test.

2 Likes

Ah, me again.

So, I'm just on the Tradfri repeaters and Xiaomi devices now. Wired gear continues to work just fine. Battery kit stays connected, but after a little time I get unresponsive devices which need a few presses to bring back to life. They're still present on the network, but when pressed they don't generate the usual "buttonPushed" messages in the logs, instead giving me this:

dev:6 2020-07-02 22:34:14.231 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 42) - description:read attr - raw: E7C40100003C01FF421A0121C70B03281C0421A84305212B01062403000300000A2120CB, dni: E7C4, endpoint: 01, cluster: 0000, size: 3C, attrId: FF01, encoding: 42, command: 0A, value: 1A0121C70B03281C0421A84305212B01062403000300000A2120CB | parseMap:[raw:E7C40100003C01FF421A0121C70B03281C0421A84305212B01062403000300000A2120CB, dni:E7C4, endpoint:01, cluster:0000, size:3C, attrId:FF01, encoding:41, command:0A, value:[raw:[battery:0BC7, deviceTemperature:1C, unknown1:43A8, RSSI_dB:012B, LQI:0000030003, unknown5:CB20], battery:3015, deviceTemperature:28, unknown1:17320, RSSI_dB:299, LQI:196611, unknown5:52000], clusterInt:0, attrInt:65281]

That one was a Button, this one is a Wireless Wall Switch:

dev:7 2020-07-02 22:38:16.813 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 42) - description:read attr - raw: 24AC0100004401FF421F0121C70B0328190421A8430521100106240400040000082109140A2120CB, dni: 24AC, endpoint: 01, cluster: 0000, size: 44, attrId: FF01, encoding: 42, command: 0A, value: 1F0121C70B0328190421A8430521100106240400040000082109140A2120CB | parseMap:[raw:24AC0100004401FF421F0121C70B0328190421A8430521100106240400040000082109140A2120CB, dni:24AC, endpoint:01, cluster:0000, size:44, attrId:FF01, encoding:41, command:0A, value:[raw:[battery:0BC7, deviceTemperature:19, unknown1:43A8, RSSI_dB:0110, LQI:0000040004, unknown3:1409, unknown5:CB20], battery:3015, deviceTemperature:25, unknown1:17320, RSSI_dB:272, LQI:262148, unknown3:5129, unknown5:52000], clusterInt:0, attrInt:65281]

Another couple of presses and we're back to normal.

Any advice? The mesh is only about 24 hours old, but it's only 3 repeaters, 6 wired switches, 2 buttons, 2 wireless switches and a Cube. Weirdly, the Cube has stayed connected this time and worked immediately. :joy:

UPDATE

Same this morning, nothing had dropped to the extent that re-pairing was necesary, but the first few button presses were always lost from each device, until suddenly an 'infoKNOWN' event appears and they come back to life:

dev:7 2020-07-03 09:55:13.369 infobuttonPushed(button=1)
dev:7 2020-07-03 09:55:13.364 infoButton 1 was pushed (t1)
dev:7 2020-07-03 09:55:11.087 infobuttonPushed(button=1)
dev:7 2020-07-03 09:55:11.082 infoButton 1 was pushed (t1)
dev:7 2020-07-03 09:55:07.454 infobuttonPushed(button=1)
dev:7 2020-07-03 09:55:07.449 infoButton 1 was pushed (t1)
dev:7 2020-07-03 09:54:56.393 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 42) - description:read attr - raw: 24AC0100004401FF421F0121C70B0328180421A8430521100106240600050000082109140A213C50, dni: 24AC, endpoint: 01, cluster: 0000, size: 44, attrId: FF01, encoding: 42, command: 0A, value: 1F0121C70B0328180421A8430521100106240600050000082109140A213C50 | parseMap:[raw:24AC0100004401FF421F0121C70B0328180421A8430521100106240600050000082109140A213C50, dni:24AC, endpoint:01, cluster:0000, size:44, attrId:FF01, encoding:41, command:0A, value:[raw:[battery:0BC7, deviceTemperature:18, unknown1:43A8, RSSI_dB:0110, LQI:0000050006, unknown3:1409, unknown5:503C], battery:3015, deviceTemperature:24, unknown1:17320, RSSI_dB:272, LQI:327686, unknown3:5129, unknown5:20540], clusterInt:0, attrInt:65281]

And more fodder. Here are the logs for one of the buttons not responding. I press it three or four times and eventually the Device Log shows:

dev:6 2020-07-03 13:40:16.215 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 42) - description:read attr - raw: E7C40100003C01FF421A0121BD0B03281D0421A84305212F01062407000300000A2120CB, dni: E7C4, endpoint: 01, cluster: 0000, size: 3C, attrId: FF01, encoding: 42, command: 0A, value: 1A0121BD0B03281D0421A84305212F01062407000300000A2120CB | parseMap:[raw:E7C40100003C01FF421A0121BD0B03281D0421A84305212F01062407000300000A2120CB, dni:E7C4, endpoint:01, cluster:0000, size:3C, attrId:FF01, encoding:41, command:0A, value:[raw:[battery:0BBD, deviceTemperature:1D, unknown1:43A8, RSSI_dB:012F, LQI:0000030007, unknown5:CB20], battery:3005, deviceTemperature:29, unknown1:17320, RSSI_dB:303, LQI:196615, unknown5:52000], clusterInt:0, attrInt:65281]
--- Live Log Started, waiting for events ---

And the Zigbee Log shows:

Other Button 2020-07-03 13:40:16.680 profileId:0x104, clusterId:0x0, sourceEndpoint:1, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-60
Other Button 2020-07-03 13:40:16.266 profileId:0x104, clusterId:0x0, sourceEndpoint:1, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-60
Other Button 2020-07-03 13:40:15.860 profileId:0x0, clusterId:0x13, sourceEndpoint:0, destinationEndpoint:0 , groupId:0, lastHopLqi:255, lastHopRssi:-59

There's always that "profileId:0x0, clusterId:0x13, sourceEndpoint:0, destinationEndpoint:0" following a 'disconnection', which gets resolved and permits events to be recognised again. No re-pairing required.

This is the Multistate Cluster event, this is usually sent on join.

Attribute FF01 from Cluster 0000 doesn't contain which button got pressed, that this is sent when you press the button is part of why the device didn't just fall off the mesh instead.

That these things happen is usually due to routing issues for the device in question. There are sometimes issues routing through QBKG03LM and QBKG04LM for other Xiaomi/Aqara devices, probably because routes are not maintained properly. I have a driver that is partially ready for QBKG03LM and QBKG04LM which MIGHT help improve this, but since I don't have these devices I still need some more debug logs when people have time for that.

Do you have an Xbee to look at the routing with? Do you have one of the IKEA Tradfri repeaters close to the HE hub? If not, do place one close by, at the very least in the same room, but preferably within a meter or so. The reasoning behind this is related to the big difference in transmit power and receiving sensitivity between the chip used in the IKEA Trådfri repeaters and HE. The IKEA Repeater has a much more powerful chip in this regard.

Interesting. I've never actually seen any device go through the QBKG03LM or QBKG04LM wired switches on the routing table. I wasn't aware they routed anything at all. I have noticed that the battery devices do change routes between the Tradfri repeaters more often than I might have expected.

I'm more than happy to provide any debug information you might want from this setup if I can be of help.

I do have an Xbee, though I've had some trouble with XCTU on macOS not talking to it properly, so will try again on Debian or Windows when I get some time. I was also a little nervous of introducing a temporary repeating device in case that made things unstable, but I guess that's not really an issue right now!

Yes, it may have been yourself who provided this advice earlier, so I set up the hub with this little battery-backup combo feeding it power and a close by Tradfri repeater. That's 'Main Repeater' in my setup, with a further three around the house; two on the floor above and an additional one on the top floor.

Thanks for your advice @markus, I really appreciate it. Let me know if you want me to test anything; we're unable to use this setup reliably at the moment anyway, so happy to tinker with it. :slight_smile:

It would be traffic logs using my latest beta version of the driver for QBKG03LM and QBKG04LM, but it requires us to chat live to get anywhere anytime this side of the century, maybe another day. There are others who have started this with me, just waiting for them to have time again. Thank you for offering though.

Hope you can get this sorted, it would help to better understand the quality of your mesh and were any issues reside. You will never get the full routing table in HE, that is limited to those devices that route directly with the hub.

It very well could be, it is advice repeated by a few of us here in the forum, for the very simple reason that it helps. Do make sure you can really get 1A out of that battery. The C-5 hub draws about 200mA continuously and peaks at 440mA with just the Zigbee radio running. I don't know what the peak is with Z-wave also active since I don't use that chip. The IKEA Trådfri Repeater peaks at 220mA and also draws 200mA normally.

At the moment I don't have more advice for you, other than if you can, try to run your mesh without the wired Aqara switches and see if you can get your sensors stable without them. Since you will be taking routing devices out of your mesh, it could take a bit of time before it stabilizes. You can make it settle faster by turning off HE for 30 minutes, that should bring most of your devices into panic mode and re-build the mesh faster.

1 Like

Well, well, well.

This is very interesting. I rebuilt the mesh yesterday and moved to Channel 20 because the QBKG wired switches kept trying to reattach (and obviously I can’t turn them off). I’ve tried Channel 20 in the past with all the same issues experienced before.

The new mesh is just two Tradfri repeaters and all of my Xiaomi battery powered devices, no wired wall switches, using your driver. It is stable. The devices check in when they’re supposed to. They are holding the same routing and respond on first press every time. We’re about 22 hours in and none have dropped.

It hadn’t occurred to me that Xiaomi’s own wired switches might be the cause of the trouble. Given they’re the right size (and voltage) for UK light switch back boxes I guess that they’re simply not used in the US, and therefore haven’t received the scrutiny that other Aqara products have.

If the network stays stable through to tonight I’ll try adding a few other devices, leaving the wired switches disconnected.

2 Likes

Okay, I've added three Tradfri 400lm lamps to the mesh.

I'm having some fun (actual fun, not the sarcastic kind) controlling them with the Cube - I forgot to mention in the previous post that it has also been paired for the past day and reporting in every hour. All features are working correctly, it's all very responsive!

It's been about an hour since they were added and no signs of devices jumping off the mesh; in fact, I have all of the battery button devices controlling the lamps. Then I don't need to look at a screen to check they're still working.

I'm not expecting anything to route through the lamps - they've always appeared with either an inCost or an outCost of 7 regardless of LQI, which I believe makes them bottom of the pile to be used. But I am certainly no expert in Zigbee networking!

If these hold up I'd love to see if an AlertMe (Iris V1) motion sensor stays connected now. They were dropping after only ten minutes or so previously, and never able to reattach.

Great to hear all is working! Hope it keeps working going forward!

If you make small and deliberate changes you will know what doesn't work, so how you are doing things now will let you find a setup that will be a good mesh. :slight_smile: Good luck!

1 Like

Thanks!

Everything is still stable and I've now added back most of the AlertMe motion sensors. :slight_smile:

Yesterday I went nuts and added two AlertMe SPG100 outlets. Not only do they stay connected, they're also incredibly quick to respond.

Because they're not yet automatically recognised by HE, on joining I have to select the Iris V1 Outlet driver. When I hit 'configure' the little orange LED lights up and stays on, like they did with the original AlertMe hub. When the Xiaomi wired switches were on the mesh this LED would go dark after an hour or so - I've never really understood what it's trying to tell me, but it being on seems to be a positive sign.

It's interesting to see that although I ran my AlertMe system purely with these smart plugs as repeaters for nearly a decade, they're actually nowhere near as powerful as the Tradfri repeaters.

Only one Xiaomi button has moved repeater recently, but nothing has chosen an SPG100 to route through yet, so my test is inconclusive for now. For now I can say that their presence on a network with Xiaomi devices doesn't cause any immediate issues (they've been connected about 12 hours now).

Is everything still going well with your mesh?

Still all good this morning!

That's with that one QBKG04LM wired switch on the mesh too, and it's still responding just fine.

The AlertMe endpoint devices seemed to be the most sensitive to QBKG0*LM switches being present (only surviving 10 minutes) and I'm getting regular battery and temperature measurements from all of them right now. :smiley:

1 Like