It’s easy to get confused about this and many people explain it in a way that can make it sound more confusing, although it isn’t really.
In part because it is a group, the zigbee alliance allows for a lot of customization within the standard. Different manufacturers can add their own encoding. This can in fact improve the security of zigbee, which is one reason it has been popular for security systems.
Zigbee historically handled interoperability through “profiles.” A device could be certified as using the vanilla “zigbee home automation” profile or the “zigbee medical” profile or the “zigbee green energy profile,” and if it is one of those profiles, it meant it would be broadcasting standard messages with the standard addressing scheme. So far so good, right? In theory, any coordinator using a specific profile (like smartthings uses the zigbee home automation profile) should be able to talk to any device using the same profile.
But then there is one more twist. Every zigbee device has its own “fingerprint” which lists the device class, The manufacturer, the model, and the specific command clusters that it can process.
In order for a coordinator to be able to talk to a device, it has to know which clusters it uses. Many Coordinators, including SmartThings, use a common library for this. If they recognize the device’s fingerprint at the time that it joins the network, then they know which device handler to use to talk to it.
The problem arises because the fingerprints can be slightly different just because they include the manufacturer information. The brand and model.
So there are two ways for a Coordinator to handle the situation when it doesn’t recognize the specific fingerprint. It might just use the supported command cluster information, which is also available from the device.
But most home automation systems don’t do that. Again, this can be considered a security measure. Instead, they look up the fingerprint, and if they don’t already have that on file, they just list the device as a generic thing and you can’t really do anything with it.
This is what will happen if you try to join, for example, a SmartThings branded zigbee sensor to wink or Iris. Even though these all use the same zigbee profile, the coordinator says “I don’t know who you are” and sort of stops there.
Smartthings is very unusual in that it allows the customer to assign the device to a specific device type handler (DTH) after joining or even write their own DTH for the system to use.
This is why ST customers can use so many different zigbee devices from different manufacturers. As long as the device is using the zigbee home automation profile, you can capture its fingerprint at the time that it pairs to the smartthings hub, and then create a device handler for it.
Since it’s ZHA certified, it’s going to use the standard command clusters. It’s just a matter of properly introducing it to the SmartThings hub.
The fingerprint issue doesn’t matter to systems which are sold in kits of preselected devices. This is how most DIY security systems are sold, for example. In those cases the Coordinator will be preloaded with the fingerprints for those devices. And again, some people consider it a security advantage if the coordinator cannot be joining to any devices not on the preapproved list.
But for home automation systems, where people tend to occasionally add entirely new devices of a device class they’ve never had before, being able to buy from multiple manufacturers gives you a lot more flexibility. And that’s what SmartThings delivers.
The next generation of zigbee, 3.0, is going to combine many of the profiles into one, but it isn’t backwards compatible in that way you might expect, and it still doesn’t address the fingerprint issue. So it will improve inter-operability, but not open it up completely.