Not really. IMHO.
They simple used non standard methods or in other words methods that are not the recommended. They still use methods within the boundaries of ZHA protocol definitions. As I mentioned a few points above the ZHA protocol does not have as mandatory a drop and rejoin process for example, in fact there are configurations settings that can be added to the coordinator to disable this process even. This is just an example. By the way due to some problems with Z-stack with ZIGBEE_CHILD_AGING this nethod was largely improved in Zigbee 3.0 (Whatever that means, i just saw it in some documention regarding Zigbee 3.0).
Now if you ask me if there is legroom for everything. No there isn't. There needs to be sacrifices and being Xiaomi devices those that require in ZHA 1.2 the most unusual ZHA configurations than an alternative method should ideally be sourced. There needs to be a choice between brands and numbers. I do believe that all other brands in numbers that use more common configurations exceed IRIS and Xiaomi numbers (Even though Xiaomi is the largest single brand seller).
I would like to see how the sensors would behave in z-stack 3.0 and if the changes introduced to the z-stack are not enough looking to integrate the gateway might be the only other option.
This is not true, while the management leave and rejoin message is not required to be supported. if you do support it you can't support half of it. The methods we are talking about here are in the zigbee specification, they are not specific to ZHA.
Mgmt_Leave_req
Rejoin bit: This field has a value of 1 if the
device being asked to leave from the
current parent is requested to rejoin
the network. Otherwise, it has a
value of 0.
2.4.3.3.5.2
Effect on Receipt
Upon receipt, the remote device shall issue the NLME-LEAVE.request primitive
using the parameters supplied with the Mgmt_Leave_req command. The results
of the leave attempt shall be reported back to the local device via the
Mgmt_Leave_rsp command.
If the remote device does not support this optional management request, it shall
return a status of NOT_SUPPORTED. If the leave attempt was executed
successfully, the Mgmt_Leave_rsp command shall contain a status of SUCCESS.
If the leave attempt was not executed successfully, the Mgmt_Leave_rsp
command shall contain the error code reported in the NLME-LEAVE.confirm
primitive.
The problem with Xiaomi is that they accept the Mgmt_Leave_req command but they ignore the rejoin bit.
Here I'm in agreement and slightly disagree with you (I must be Bipolar ).
The fact that they recognize the leave request does not necessarily mean that they need to rejoin. IMHO the rejoin process is optional. It's like if you expell me from your home and say please leave and come back later it does not mean that I forcibly need to come back.
Understood, but this does affect plug and play interoperability in general though, not just with HE. At least that is what I am getting out of all of this.
I don’t think people (at least starting out) pick a hub around the devices they want. I read threads on ST, OpenHAB, HASS and here about issues with Xiaomi devices. Which is why I never got any despite the price and size sometimes being appealing.
I guess what I am getting at is that once someone goes down the HA rabbit hole and spends thousands of $ on it, they will be less likely to throw it out the window because one appealing brand of devices won’t play perfectly with it.
Right now it seems if you want to use Xiaomi devices you need to know that you have to plan around them, which most new users would never know.
Where in the zigbee spec does it say that? They are very specific about what is mandatory and what is optional. The Rejoin bit is not specified as optional, if you can point me to the specific section in the specification that says it is, I would appreciate it.
Officially ZigBee 3.0 Certified listed so far (all in the current Aqara product form-factor):
Mains-powered wall switches with/without Neutral
In-wall outlet
Smart Plug
Wireless Mini-Switch (button)
Door-Window contact sensor
Occupancy (PIR) Sensor
My expectation is that all of these will finally be directly targeted at all non-Chinese markets, so everything will be priced accordingly. It will be interesting to see if they release a new ZigBee 3.0 gateway product (or a firmware upgrade for the current ones). Their whole IoT brand is essentially set up as a closed platform ecosystem, and the new certified ZigBee 3.0 product variants will open them up for use on other platforms.
If Hubitat / SmartThings continues to not want to touch them in terms of official support, I stand ready to put together new DTHs / device drivers as soon as I can get my hands on any devices that work in my region (the US.)
Also, we should be talking about Lumi United Corp products, not Xiaomi, or Aqara. Those are sub-brands as I understand it. Lumi is the entity who got the ZigBee 3.0 certification.
Sure, but why should Lumi United care, anyhow? All of their documentation / marketing states that a Lumi (Xiaomi/Aqara) Gateway is required for use of all of their ZigBee-based products. Since it's an essentially a closed platform ecosystem as I said above, they can operate with their own bastardized flavor of the ZigBee spec / ZHA 1.2, and not have to answer to anyone in terms of interoperability with other platforms.
With billions of people in China, I don't think they have to worry much about market size. But people in other countries are willing to pay a whole heck of a lot more per device, I'd guess that's the attraction to finally falling in step with the published ZigBee spec and getting the Certification. So the new devices will work, but again my guess is that we'll be paying for it, and they will just be another (in my opinion) overpriced line of HA products.
Section 2.4.3.3.5 Table 2.84 of the Zigbee Specification.
Other information from the document:
1.4.1.1
Conformance Levels
The conformance level definitions shall follow those in clause 13, section 1 of the
IEEE Style Manual [B13].
Shall: A key word indicating mandatory requirements to be strictly followed in
order to conform to the standard; deviations from shall are prohibited (shall
equals is required to).
And from my post above:
Upon receipt, the remote device shall issue the NLME-LEAVE.request primitive
using the parameters supplied with the Mgmt_Leave_req command. The results
of the leave attempt shall be reported back to the local device via the
Mgmt_Leave_rsp command.
If the remote device does not support this optional management request, it shall
return a status of NOT_SUPPORTED.
I absolutely agree. Its the same with the iris v1 equipment. It is not supported, they used a variation of the zigbee specification and it doesn't work with other hubs. My whole argument here is that these devices will not be officially supported by us because they do not implement the zigbee specification properly.
You are confusing me now. You said that perform the leave request and never rejoin.
On this highlighted sectioned you just reposted there is nothing regarding rejoining solely about the leave request component what is my understanding that they do perform as they leave the network.
“thousands” would be a bit much, what I was trying to say is that they already invested a ton of money (amount is only relevant to the persons budget and taste).
But to answer your question, I started with the hub and two devices, less than $200. I personally researched all the hubs out there. Picked one (obviously HE), researched known good devices (posts and compatibility wiki), bought a few. Continued to expand devices based on the above and my needs/wants.
Only once did I knowingly step out of this norm, it cost me a non-working $30 device. I also got one for Mike Maxwell, maybe he’ll get it working hopefully. I don’t like possibly losing that money completely, but it was a risk I took, hopefully it works out and it’s another device for users in the future.
The above loss I am “ok” with, but personally I am not ok with replacing tons of plugs, outlets, switches, etc to start using devices that won’t play well with others.
I like the $15 temp/humidity sensor, but if it means I have also get rid of things I have now (plugs, outlets, switches) and replace them with Xiaomi conforming things .... then I’d rather buy the $32 Zooz 4-1.
I would think most people would do the same. I also don’t think most people will simply plan or buy around Xiaomi due to price, size, look. If they have issues under most hubs, they will avoid them, and stick to what works rather than redo their whole setup.
Are you reading the spec document? You keep saying that the bit is optional, but you won't tell me why you believe that. I can post the entire section from the document, but I assumed we were looking at the same one.
Here is the specification for the Mgmt_Leave_req command, There is further text after this. Please tell me where it says you can implement only parts of this command. that you can ignore the last bit (Rejoin) if you want?
Do you find it odd that Xiaomi is the only one who correctly interpreted the spec and made the Rejoin bit optional? That the devices have difficultly on every hub except the one that Xiaomi makes?
Not that anyone asked, but I also think the rejoin is a shall, not should, the way the standard is written.
That is part of the reason I think pairing devices with their native Hub, and then integrating that Hub with HE, is the most technically compliant solution.
Not so sure about this.
Imagine the following scenario:
2 doors, 8 windows, 4 rooms temp. 1 smoke sensor, 4 move senaors and 1 leak sensor.
If you use Xiaomi prices you can get all of those sensors for under 250$. With any other brand you are certainly over 600$.
That was my earlier point. For someone that is planning out a path forward and has a large number of sensors, it may very well be worth their trouble to replace incompatible devices.
in my scenario I had to replace three SmartThings outlets, but the money I saved with the cheaper sensors vastly outweigh that cost.
I really love the Xiaomi device form factor and have been tempted numerous times to risk buying them. But at the end of the day I remind myself that I value the stability of my system and I value my time. Saving a couple of hundred bucks buying something I know might not completely work always has a way i biting me in the ■■■ and costing me significantly more than I saved in the long run.
Of course I also don't think most people would buy a fledgling hub with the extra work it takes either.
For the xiaomi devices to be successful in other markets they need to have Hub compatibility. If all they care about is the Chinese market, then they can do whatever they want without worry. Maybe hubs outside of the Chinese market will support them, maybe they won't. Hard to tell for sure.
Those using them outside of the Chinese market are the edge case right now. Just like everyone who uses hubitat.
The fact I have a degree in law probably hinders my view and I'm more picky related terminology and what is or it is not include in regulations and norms. In law unless something clearly stated is the same as not being stated.
The fact is that neither it says it's optional and neither it says that is forcibly mandatory. It's not clear and that's the main point. It's open to interpretation.
The flow of the protocol suggests (based on interpretation) that it should be mandatory but does not clear state it. As such of it does not clearly state it Xiaomi or any brand has now forcible need to implement it.
Just to be clear Chuck I don't disagree with your interpretation what I disagree is that we blame Xiaomi by not implementing xyz when is not clear (without interpretation) that they should implement it in first place.
Does Xiaomi opted for a poor implementation? By a mile YES.
I do agree with Vee and Jason hopefully all of this go away with Zigbee 3.0 certification and hopefully they will still be priced affordably.
But I'm also cautions regarding 3.0 devices of any brand due to what Mike hinted a while back that there isn't any plans to implement 3.0 on HE at the moment.
).
