I've paired a few xiaomi devices next to the hub, then moved them to the other end of the house near a tradfri outlet. It never dropped so either that's not true or the HE hub has great range
I think you're just maintaining a good signal. I have an XBee so I can see what devices are connected to what. The Xiaomi devices I pair to the hub will stay that way. The ones that I pair next to a TrÄdfri outlet that is far from the hub, will stay with the TrÄdfri outlet. Whereas, devices that are fully Zigbee spec compliant do tend to move around. Sometimes I find them connected directly with the hub, sometimes I find them connected to one of my two TrÄdfri outlets.
1 Like
If Xiaomi ever makes a fully compliant Zigbee device at the same/similar price point, it will be hard for other companies to compete on the sensor side of things. The form factor and price are simply awesome.
Maybe the new Xiaomi devices that are (reportedly - I'll believe it when I see it in-hand) Zigbee 3.0 compliant will be the turning point. Who knows?
1 Like
Yes, that will undoubtably be a huge blow to any company competing in the same product range that can't price match them. I'm hoping for that 3.0 compatibility as well.
1 Like
I tend to find that mine move around on their own.
From what I've seen so far using XBEE for live-mapping there's three scenarios:
- A device does a rejoin to the same router, in this case it seems to get issued with a new 16-bit address
- A device does a rejoin, but to a different router, in this case it also seems to get issued with a new 16-bit address
- A device just moves between routers, in this case the 16-bit address doesn't change
For me this seems to be consistent behavior across a mix of 28 end devices from Hue, SmartThings, Nyce and Xiaomi Aqara with a mix of 8 routers from XBEE, Xiaomi Aqara and Salus.
I completely disagree with the practice of pairing any ZigBee devices next to the hub and then moving it to it's install location. As @mike.maxwell has mentioned at least a few times, ZigBee devices should be paired in situ, so that they establish the network route they will be using from the start.
I also disagree that Xiaomi / Aqara devices aren't able to change their mesh routing on their own. I've watched it happen using one of my XBee devices. Stubborn to change in some cases, yes, but not all the time. Again, they should be paired at their intended install location, like all ZigBee devices.
Under normal circumstances, the user has no control over what nearby repeater a ZigBee end device will choose to route through, and without the use of an XBee (or ZigBee sniffer), there's no way to confirm the routing of an end device.
With apologies for repeating what I just posted over on the Xiaomi / Aqara device driver thread, I also want to add:
The main goal for the harmonious existence of Xiaomi / Aqara devices on your Hubitat's ecosystem is to ensure they do not route through "incompatible" ZigBee repeater devices. When I say "incompatible" repeaters, it's not always just because they get "impatient" waiting for Xiaomi / Aqara devices to check in. I have witnessed and read about a host of other issues such as difficulty during pairing, devices never getting past the initialization stage of pairing, and also messages not being sent through to the hub.
If you want to make sure there's no way your Xiaomi / Aqara devices will connect through an incompatible repeater, there are three methods:
- Don't use any incompatible repeaters at all.
- Make sure incompatible repeaters are distant enough that Xiaomi / Aqara devices don't route through them. Only an XBee or ZigBee sniffer can help verify this.
- "Sandbox" your Xiaomi / Aqara devices on a different hub (e.g., a second Hubitat, or another home automation solution that works with Xiaomi / Aqara devices - but preferably not a SmartThings hub because too much functionality can be lost)
Therein lies the rub. Lumi/Xiaomi have made it clear they want to enter the U.S. home automation market, and these new ZigBee 3.0 compliant devices are likely part of the plan. This means selling through "normal" channels (i.e., not through Banggood, etc. with super-cheap direct-shipping of "ePacks" from China that take advantage of the Chinese-US Postal agreement that is soon to end). That will raise costs. And selling to wealthier Americans / Europeans? Of course it would be in their best interest to raise prices!
But time will tell...
3 Likes
This brings up a question though...I have some SmartThings buttons and Iris keyfobs. I usually pair them close to the hub just to make sure they will pair OK. But since they can and do move around, will that be a problem with the ZigBee network? Sometimes it seems like the Iris keyfobs fall off the network but come back just fine, though I've never done any deep diving into that. I haven't used the SmartThings buttons in a while so have no history there.
Hmm, a very good question, and one I honestly can't answer with 100% confidence.
I would hope that ZigBee devices designed to be moved around are configured to handle changes in their routing with greater ease. But would not be surprised if there's hiccups in their connection due to changes in their routing.
In that case I'd guess that it would be best to pair those kind of devices where they would spend most of their time. For example, I have a Xiaomi Cube controller and I mainly use it around my living room, so I paired it there.
1 Like
Zigbee devices are designed to pair 'in place'; since there is a fair bit of data transfer during the pairing process, being close to the hub facilitates this and makes it quicker-- but it isn't required in a properly functioning network. This is in contrast to Z-Wave where pairing in place only works if the joining device and routing devices support network wide inclusion (recent ones do, some older ones don't depending on vintage). But Zigbee isn't really designed for mobile devices. It does a reasonable job of accomodating devices that move, by discovering broken routes and repairing them. A good discussion of the topic: Evaluating Mobility Support in ZigBee Networks
TLDR:. "Our results reveal that existing ZigBee provisions for mobility is inadequate,
and mobility problem was not thoroughly considered by the standard. Moreover, we
found that the current recovery mechanisms are not reliable, or responsive enough in all
mobility cases"
So nothing bad will happen to your Zigbee network when devices are moved, but you may need to be patient while it reorganizes itself.
4 Likes
This appears to be a fairly old paper, as they reference the ZigBee 1.0 spec, and other references only as recent as 2006. I wonder what improvements have been made with regards to mobile ZigBee end devices in the 1.2 spec, and also whether ZigBee 3.0 will fully address the requirements needed for device mobility.
Some of the XBEE docs on ZigBee seem to suggest setting the sleep period / cycle timeout on routers / coordinators to match your longest end device polling time to ensure no devices drop-off. Obviously if you're designing and developing your own hardware then that's possible.
But you would think that it would be possible for that to be managed dynamically across the network by the coordinator i.e. as each end device joins it notifies the network of its polling time and the coordinator sends some configuration out to all all routers to update them appropriately.
You would also hope that the clearing of stale end devices from the router is done as a reaction and not preemptively i.e. just because the device hasn't checked in there's no need to clear it unless there's a new device that's asking to connect to that router.
I may be wrong here but my understanding is that the end device timeout settings are communicated (or can be, depending on capabilities and the requirements of the end device) from the end device to the parent router, not necessarily the coordinator (unless it is the parent device). It is then up to the parent router to manage the space it allocates for storing and forwarding data from the end device; ageing it out when it sees fit. It doesn't seem like the coordinator would need to be involved in this.
Thanks for the feedback Keith. I haven't seen them change routes and a few other commented the same, but I haven't anywhere near the number you have or the level of experience. Good information as always.
I haven't deep-dived into all of the ZigBee documentation, but regardless of whether this is true or not, I do know from a post by SmartThings Engineering Lead Tom Manley that if an end device that has been dropped does subsequently attempt to check-in, the parent or coordinator sends a "leave & re-join" request to the end device. For unknown reasons, Xiaomi devices leave, but never rejoin as requested.
My guess is that because they were only ever intended to be used with a Xiaomi / Aqara hub, some parts of the official ZigBee communication methods are skipped or proprietary methods are used, because some elements of negotiation aren't needed when the coordinator / potential parents are known entities. My further belief is that this is not because the Xiaomi (Lumi?) engineers were being "lazy", but all in an effort to eek out as long a battery life as possible. That would help to explain why the standard ZigBee commands to adjust the frequency of reporting are ignored, for example.
Here's a quote from part of the post by Tom Manley, which was part of an answer to explain why an earlier firmware of the SmartTHings V2 hub seemed to be dropping the connections of Xiaomi / Aqara devices:
Although they arenât officially supported I know a lot of people use these sensors so Iâve been looking into the issue with the 0.18.X firmware on my own time and I think I may know whatâs going on.
As you probably know, the Xiaomi sensors are very sleepy. Most sleepy end devices that we support will wake up every 6 seconds to 2 minutes to check for messages and to make sure its parent knows it is still there. The Xiaomi sensors do this closer to once an hour. That is zigbee compliant behavior so everything is fine so far.
The zigbee specification includes a section called End Device Aging. It states that a parent must forget about a child that doesnât check in for a certain amount of time. In other words if the parent (like the hub or another router on the network) hasnât heard from a device within a certain amount of time it must tell the device to leave and rejoin the network. This isnât an uncommon thing to happens on a zigbee network and most devices will handle this just fine. When the device does it right youâll never even notice it was gone for a brief period.
By using a zigbee sniffer I can see all the communication between the sensor and the hub. The sensor is quiet for about an hour and then sends a checkin message to the hub. The timeout for end devices has elapsed so the hubâs zigbee radio doesnât recognize the sensor anymore. Therefore per the specification it sends the sensor a leave and rejoin request. The sensor replies with a message saying it is going to leave and rejoin. Then it does leave but it does not attempt to rejoin. Instead it appears to factory reset itself. This is why it drops offline and I believe is non-compliant behavior.
5 Likes
Good info there; sounds like to be compliant a parent device must evict a child that it has aged out. Probably that is the only way to avoid the scenario where no new devices can join once the router's child table entries get filled should the entries no longer be in use. In the Xiaomi ecosystem this obviously isn't an issue so their parent devices can tolerate fewer checkins.
So in theory if the stack is compiled above 14400 that's no longer an issue?
Asking myself if that was what was done in ST....
Yes, if the end device aging timeout was increased to a value that equates to over 60 minutes, then it would allow Xiaomi / Aqara devices to check in before the parent "forgets" about it.
However, I'm not sure that's what was changed in SmartThings' stack which led to Xiaomi / Aqara devices working again. Again, from that post by Tom Manley:
The end device aging timeout has not changed between the 0.17 and the 0.18 release. However we did upgrade the zigbee stack between these two releases. The zigbee stack is provided by the radio vendor and they frequently update it to introduce new features and fix bugs. I suspect that the cause for the change in behavior between 0.17 and 0.18 is due to a bug fix to make the stack compliant with the zigbee specification. The 0.17 firmware did not send the leave and rejoin request after the end device timeout which I believe was likely a bug in that version of the stack. Just to be sure I am double checking with the radio vendor on this.
This information is from a number of firmware revisions ago, so I don't know what happened since then, but it's possible that subsequent versions of SmartThings' version 2 hub firmware use a stack that does not send the leave & rejoin request.
As for what Hubitat did in this case, either increase the end device aging timeout value -or- disable the leave & rejoin request sequence, I have no idea. I think only @mike.maxwell would be able to answer that.
Regardless of what the coordinator's end device aging timeout value is set to, I don't believe that value propagates to all routing (repeater) devices, though. So that's probably one of the reasons why the Xiaomi / Aqara issue still exists for people with "incompatible" repeater devices.
2 Likes
The ST 'fix' to acomodate Xiaomi did not propagate to routing devices; I had to take pains to keep my Xiaomi buttons to keep from joining through Iris plugs. As child devices of the ST hub, they usually worked fine until their was a power failure lasting longer than an hour.
Interesting.
Anyone know the Ikea outlet value?
I meant the check in value
1 Like
