CC2652R: how to make zigbee system inter-operable with off-the shelf zigbee s

Which Z-Stack version do you run on CC2530 as coordinator and what kind of profile do off-the shelf zigbee devices support?

For cc2538, we use the z-stack 3.0.2.   Off the shelf means,  I mean, any zigbee device already in the market , ex:

:www.safewise.com/zigbee-devices

If we want to make our product more interoperable. What needed to be done  in both ZC and ZED?

This is my experience and analyses:

- Any vendor will "guarantee" that their solution is compatible with other vendors;
- Zigbee Certification is only a partial guarantee of interroperability.
- Interoperability depends both on the stack from the silicon vendor, and on the way it was used by the product developer;.

It seems to me that Zigbee is lacking the equivalent of the Unplugfests for Bluetooth. During unplugfests bluetooth produccts are tested against each other, not only in a test house.

Un practice, I encountered several difficulties in interoperability, but I did noto identify all causes yet.

One main cause in my setup is that the ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1 still needs to be "tuned";
I tested a third party product that supposes a fixed endpoint number for attribute reporting (when reporting is configured for another endpoint, it will report to a fixed endpoint);
Recently a third party based ZED required a firmware upgrade because it was unable to associate with another third party coordinator (neither involved a TI based solution).

For now, in pratical situations, several third party products associate variably with the CC2530ZSTACK3.0/ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1 based solution. As said, this seems mostly due to the gateway.

I am only starting to analyse in detail what the expected Zigbee behavior is when the setup does not work as expected. But for now, I have not pin pointed an issue with the ZSTACK3.0.2 itself when it comes to interoperability.
In some "invalid" situations, the ZSTACK3.0.2 does not respond as one might expect (e.g., TableFull response from the API instead of InvalidParameter), but that does not impact the interoperability once the API request is corrected.

So IHMO interroperability has to be tested between real products and for the moment this is not done at the same level as we can see for Bluetooth (Unplugfests).

So to make things more interoperable it is left up to the engineers using the different solutions to test, anlayze, correct and report when needed in order to have the different products and potentially ZStack libraries corrected.  For the moment, the market is more oriented to "closed" solutions where inter-operability is guaranteed by the manufacturer with other products that it tested and validated - generally with "partners" or "in-house".  You will find that most solutions do not accept third party products "unknown" to the coordinator, which is a way to limit End User After Sales Support with regards to inter-operability issues.

Specifications themselves have gaps and let the interpretation to the reader.

Within a team the specification may be interpreted in a specific way and differently in another team.

I was responsible for verifying ASICs in the past and we made sure that the development engineer and the verification engineer were not the same person in order to help ensure that differences in the interpretation of the specification could be catched.

In an ideal world, specifications are perfect, implementations are perfect (and verification would not even be needed), but we are "only" human so subject to subjectivity, mistakes and incompleteness.

The specification itself has a few errors that are obvious adn certainly also a few that are not so obvious.

Agee with you and that is real world.

Hi YK,

I tried to pair our zed switch sample original or zed light sample original with launchpad only to unniversal gateway conbee ii but we cannot join at the moment...

Any ideas?

Regards,

WAlter

Walter Macamos Do you use sniffer to check what happens over the air?

SIMPLELINK-CC13X2-26X2-SDK nodes are regularly tested to verify interoperability with Amazon Echo and Samsung SmartThings hubs, please make sure you are communicating on the same channel and confirm that the gateway does not contain any specific join requirements (install code for example).

Regards,
Ryan