You paired the Trådfri Outlet and then paired the button near the outlet? I never had one of the buttons drop off either before or after I added Trådfri Outlets. The Xiaomi devices will not voluntarily move to a repeater. If you paired a button that is almost out of range of the hub, and then added the Trådfri Outlet afterward, it probably would drop, because it was still communicating directly with the hub, not through the outlet.
I paired it next to the hub actually. The place I had it sitting had a Tradfri outlet in-between the hub and it.
The free trial from my friend didn't go well so it's getting returned to his Home Assistant madness. 
1 Like
Well that's most likely what happened then. The device was paired to the hub and when you moved it into place, it dropped the connection with the hub, so the Trådfri Outlet didn't help. Have to pair them through the outlets. They don't change on their own like other compliant Zigbee devices do.
I like the Xiaomi button because of the lower cost as you pointed out and the fact number of devices or actions possible. I think the SmartThings button only has tap, hold and double-tap right? Xiaomi has up to five programable taps, plus a hold. So up to 6 devices and actions are possible. 
Kind of a bummer that it couldn't heal it's way back though.
I tend to need to bring devices close to the hub if they're being stubborn during the pairing process. The ST button was paired next to the hub and walked to almost the same location as the Xiaomi button and it works fine.
To me, and here's an opinion 
, it's not worth the $5 difference.
Maybe less if you buy directly from China and wait forever for shipping.
You're correct.
I find playing the tap matching game difficult though.
I prefer to only use tap and have rules that know what my tap means based on time, mode, light status.
1 Like
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....
