Paging @JDRoberts. Here's where we need an expert reading on this.
Thanks,
Looking to 6.4:
"
Check-in Interval (u32CheckinInterval): This is the period between the
server’s checks of whether a client requires the poll mode to be changed,
expressed in quarter-seconds, with a default value of 14400 (1 hour). It should
be greater than the ‘long poll interval’ (see above). Zero is a special value
indicating that the Poll Control cluster server is disabled. Otherwise, the valid
range of values is 1 to 7208960 but a user-defined minimum value for this
attribute can be set via the optional ‘check-in interval minimum’ attribute
(u32CheckinIntervalMin). This limit can be used to ensure that the interval
is not inadvertently set to a low value which will quickly drain the energy
resources of the End Device node. Alternatively, minimum and maximum
values can be specified through the compile-time options (see Section 6.10)."
So my question is in the likely event that the Xiaomi devices will not report an Optional check in time (mostly because these values are defined on the Xiaomi Gateway Zigbee Stack) the stack will default to whatever value it has as default.
Two points here:
The fact that they are not in sync does not mean that one or the other is not complaint. It just means that one is speaking at different speeds than the other.
Secondly if the issue is the check in time would not be ok to have preconfigured check in times on the driver or Zigbee stack?
Is that really the issue with these devices?
Interesting. Took a look at my Occupancy Sensors and the SKU's dont match up. Looks like I have older models. I've had them since last year though. So they might have done updates to make them 3.0 compatible and probably more reliable overall. But I'm pretty sure most of my stuff is all older anyways. But good to know they are moving in that direction.
As the intent of the standard profile is to ensure interoperability between devices of different manufacturers I don't think that it follows that two devices (say, an Iris plug repeater and a Xiaomi button) could implement features of the specification and still be said to be compliant with the profile. Is that what you mean? I assume that there is certification testing (which costs money) to verify compliance with the profile; perhaps this was intentionally not done by Xiaomi since their devices are targeted to their own ecosystem.
It would make sense that there is a default end device timeout interval; but again for interoperability I would assume that compliant routers and end devices would be on the same page with this.
You're repeatedly asking for why they are not complaint, they are not compliant because they are required to send a check-in interval if it's not going to use 1 hour. It doesn't use 1 hour, and it doesn't send the different one. That is why they are not compliant. Other devices (HE) have changed the default 1 hour since the 'downside' is minimal. Devices acting as repeaters have not all done this, so they drop off.
If a device "times out" and then attempts to ping the network, there is a built in way to do that, it needs to do the rejoin procedure (which they don't).
3 Likes
Con: they're Chinese
1 Like
99% of what we use is MIC.
1 Like
While I can't control the origin of components in any given device, I can buy from specific manufacturers and exclude those with known corporate espionage practices.
2 Likes
Now that is a more specific statement than the original of which I can agree.
3 Likes
Was wondering when someone was going to throw the china card, surprised it took so long lol
2 Likes
Our hub too....
Kidding
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.
1 Like
Thanks Chris
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...
2 Likes
Complete out of context statement from you:
- 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.
1 Like
The Xiaomi hub is cheap, if that is true updating all aqara sensors will be great.
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...
