Here is where I disagree with. The standard itself is not for the device to checkin every hour. The standard is for the device to check in. The 1h threshold is a default value and seen as best practice but is also a customizable value, something that can be set when the stack is being compiled.
This does not make the device or the stack more or less compliant as that value is not an value that is rigid on the standard.
In fact as far the end device has a check In interval between the ranges of values 1 to 7208960 they are in fact being compliant with the standard. 14400 is an hour.
You can say that a device is not compliant with a given implementation of the zigbee stack by xyz but that's very different of saying that a device is not compliant with the standard.
This is not semantics by the way but calling things for what they are.
The standard is for the device to check in either at the standard time specified by the server (default 1 hour but as noted can be changed depending on the stack) or tell the server something different, which it does not. That is why it is not compliant. It is not semantics, you are correct, it is very clearly:
Check in when the server wants you to
or
Tell the server when you're going to check in
Their devices do not follow the standard of doing one or the other and are therefore out of spec, no interpretation needed.
I will need to read further the standard.
The question I might agree with you is that per default the Xiaomi devices do not send the polling information and the connection needs to be kept open for that information to be sent.
This occurs because by default it is assumed the coordinator knows this information. But they do send it if the connection is left open.
They might be still compliant as they in fact do send the information but not on the initial request.
I'm still not clear if the standard requires either the default server to be used or the client to send the information.
I'm suspicious that what the standard asks for is that either the 1h (server default) is used or the minimum and maximum thresholds are set during compile.
A minimum/maximum value range is how the standard can in theory be adaptable and resilient.
But as said I need to read further to be clear.
After all the client will not know what definitions are set on the coordinator per default as such assumes it has the correct interval set and as far the client is concerned if it transmits on the supported range it will be fine.
I suspect that is the responsibility of the coordinator to say hey I'm not using range xyz but ABC or default value w, please send me your polling information.
That's when the Xiaomi devices will forward the information if the connection is left open.
If this is the case than the Xiaomi devices are still compliant.
Sniffers are cheap, specs are available, my time is neither, so vs endless theorizing maybe you could sort through a days worth of packet captures and let everyone know why these things fall off...
I never asked for you or anyone of the HE to spend time on this.
Theorizing is part of the scientific method, without it there is no hypothesis, without hypothesis potential solutions are not found.
You don't know my cost per hour as I don't know yours. However regardless the value each one of us is paid the time that we have for side activities depends on each one individual circumstances. But just to give you a hint. I have done 65 international travels last year for work. Free time is a scarce thing.
Lastly I'm an enabler, strategizing and helping others to think outside the box is what I do best. However that only works if others are willing to listen and set aside preconceived notions that they have. I challenge preconceived notions to reach either a validation or trigger new formulations that will drive new solutions.
It's really fine if you simple ignore my comments on this topic if it is of no interest for you.
The new ZigBee 3.0 Certified devices have only been announced. They have not started shipping that I am aware of.
They have different model numbers than the version that people are using now, which is documented in my detailed list of Xiaomi / Aqara devices (found in my opening post for the Xiaomi / Aqara device drivers thread.)
I am crossing my fingers that all the issues will be a thing of the past with the new ZB 3.0 models.
As soon as someone has seen them for sale, I'm sure we will all hear about it!
Willing to support your testing. Let me know.
Also someone also mentioned that is likely old devices will receive a few upgrade via the gateway, but I guess is just a rumour.
The thing that more caught my eye on my quest to understand ZHA 1.2 is the move that IKEA s doing on this space. Just check the devices that are certified by the ZigBee alliance, some of them are not yet on sale at least here.
If this is true they become a very nice alternative to Xiaomi cost wise.
Pitty that the devices are ugly as hell...
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.
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.
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.
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?
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.
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!
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.
, it's not worth the $5 difference.
