That's great, thanks! I already run Espurna on everything, so that's fine, I just wanted to confirm that all Zigbee devices are interoperable. It's unlikely that I'll get a device that will only want to talk to its specific vendor's gateway, then?
> I just wanted to confirm that all Zigbee devices are interoperable.
At the RF protocol level, yes they should be. Speaking as someone who works at a company with a few Zigbee-certified products, I can say that there are a LOT of "optional" features in the Zigbee specification, and even implementations of mandatory features can have differences that lead to incompatibility.
Manufacturer-specific profiles are also a big thing. So just be aware that manufacturer A's Zigbee "hub"/coordinator may or may not be inherently compatible with manufacturer B's sensors. But I would imagine that open-source systems like HomeAssistant deal with that.
How can HA deal with it? Is the incompatibility not at the protocol level? Does HA even see the messages at all? Or are the messages compatible, and then HA has to decode them somehow?
Messaging in Zigbee (i.e. sending data back and forth) is all about two things: addressing (endpoint, profile and cluster... kind of like port + URI for HTTP, where endpoint=port and profile+cluster=URI), and the payload itself. The Zigbee specification defines a variety of standard profiles that devices may choose to implement. Things like device temperature, on/off switch, metering, time, lighting, etc.
But nothing says that any given device, say a Zigbee light controller (on/off) from manufacturer X, MUST implement the standard on/off cluster for that. They could have their own manufacturer-specific profile+cluster for controlling the light, where a payload of 0x11 turns it on, 0x22 turns it off, and 0xF7 toggles the light. Or maybe you send the ASCII string "on".
Suppose that HA has implemented the functionality needed to interact with the standard on/off cluster. That functionality would work with devices that implement the standard cluster, but not with manufacturer X's device that needs the string "on". But then, HA could be updated to recognize such devices and implement the required functionality.
Assuming you're familiar with HTTP: just because two services both consume and produce JSON, doesn't mean the message bodies are interchangeable.
That clarifies things perfectly, thanks. As long as the wire format is compatible (which it is, from your description), then compatibility is only a matter of software updates, which is great.
