3 ms·

This is the great part about Zigbee/BLE/433MHz devices, they do _not_ go on your wifi (and the internet), but instead talk to a dedicated gateway. As long as yo

by tga 6y ago

This is the great part about Zigbee/BLE/433MHz devices, they do _not_ go on your wifi (and the internet), but instead talk to a dedicated gateway. As long as you find a way to talk to them, you can mix and match sensors from the shadiest of vendors. You can ignore the gateways offered by each manufacturer and instead go with something (more) open like zigbee2mqtt or deConz. Zigbee: https://www.zigbee2mqtt.io https://www.zigbee2mqtt.io https://www.phoscon.de/en/conbee2/software https://www.phoscon.de/en/conbee2/software BLE: RPi or ESP32 running https://esphome.io https://esphome.io 433MHz: https://sonoff.tech/product/accessories/433-rf-bridge https://sonoff.tech/product/accessories/433-rf-bridge running https://esphome.io https://esphome.io or https://tasmota.github.io https://tasmota.github.io Of course, this way you lose the (more or less) polished apps that come with each system and need to set up something like Home Assistant or openHAB for control and automation.

StavrosK 6y ago
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?
- comfydragon 6y ago
  > 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.
  - StavrosK 6y ago
    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?
    - comfydragon 6y ago
      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.
      - StavrosK 6y ago
        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.

by tga 6y ago

StavrosK 6y ago

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?

comfydragon 6y ago
> 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.
- StavrosK 6y ago
  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?
  - comfydragon 6y ago
    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.
    - StavrosK 6y ago
      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.