I haven’t read all the above in detail, but here are my two cents.
I would split up Zigbee compatibility in two main groups: “zigbee management” (“low level”) and Zigbee clusters (+profiles, etc).
Low Level
- Devices that pass certification are not necessarily compliant because the certification is limited to certain types of tests;
- The Zigbee stacks from the manufacturers are not tested a lot for interoperability. Some stacks seem to be more permissive than others or cope better with deviations. (To compare with bluetooth: theu have “UnPlugFests” aimed at testing interoperability.
- Low Level interoperability tends to improve - IMHO because zigbee is actually used.
- Low Level interoperability is determined essentially by the stack from the IC manufacturer, and in part by how good it is configured by the developer.
Zigbee Clusters
- Interoperability may be limited because the manufacturer wishes a closed system, but in my experience it is more that they are more than happy when it works with their system and do not want to spend more on making sure it works elsewhere.
Another reason is that developers do not understand the zigbee specification, are resistant to changing an existing implementation (admitting they are wrong, spend more time than planned, …). I remember though discussions with pairs.- One was about a timestamp. The zigbee specification “clearly” says the reference (epoch) is 1/1/2000 but the implementation uses the more classic 1/1/1970. So all dates are by about 30 year wrong. It is still so in the end product for the following reasons forwarded by the subcontractor: this feature was not requested by the customer and they do not agree with my interpretation of the specification.
- Too many developers tend to implement features in custom clusters or attributes even though the equivalent feature exists in the standard Zigbee Cluster Library specification.
- Testing is mainly done against the internal coordinator or a single selected coordinator (cost reasons related to time) and improved only when there is a market need (a customer using another coordinator wants to integrate your end device).
- The market is driven by (B2B agreements of) selling systems, not by B2C sales of end devices.
- Some companies will deviate from the specification improving the user experience with their coordinator by fixing certain values in the end devices. In one instance I found that an end device can only report to endpoint 1. And I still believe this is more a choice of the developer than a choice of the company.