Hacker News Reader

Comment by StavrosK | Hacker News Reader

What do they talk to? Do you need to get a Xiaomi hub? Are they hackable? I really don't want my devices talking to the internet, I even jailbroke my vacuum so I could control it locally (what a brave new world).

View on HN

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.phoscon.de/en/conbee2/software

BLE: RPi or ESP32 running https://esphome.io

433MHz: https://sonoff.tech/product/accessories/433-rf-bridge running https://esphome.io or 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.

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.

They display temperature and humidity on the LCD display, but also transmit the temp + humidity every 10 minutes or so via Bluetooth Low Energy.

Battery lasts around a year (on paper) so they make for cheap alternatives to the Zigbee temperature + humidity sensor in the OP article (although that one is pretty cheap as well!)

No internet needed if you set up a Raspberry Pi or ESP32 and run some software which can e.g decode the BLE messages and publish them to MQTT. ESPHome has a component for this which can get you up and running in a few minutes if you have an ESP32 lying around (needs to be ESP32 as ESP8266 doesn't have Bluetooth).

That's pretty cool, though my WiFi is already pretty crowded, so rather than have an ESP32 in every room and on WiFi, I think I'll get an ITEAD ZigBee hub and go that route instead, thanks!

Yeah fair enough the Zigbee ones will last longer with one battery anyway.

I only have one ESP32 for the 4 BLE sensors, it handles them all fine across different corners of my flat (the furthest one is around 10m through 2 walls). The same ESP32 is also in my utility cupboard with a photoresistor attached taped to my electric meter which counts the LED pulses so I can see how much electricity I’ve used in Home Assistant as well. Esphome makes it easy to configure multiple use cases for one device like that

Hmm, that's interesting. I've never tried ESPhome, but I should. I rolled my own five years ago and it's been working fine so far, but ESPhome + Home Assistant might be easier to configure and update than Espurna.

Yeah I was using Espurna on my lightbulbs that I replaced the firmware with (they were Tuya-based bulbs so I swapped them for Espurna). It was rock solid but I decided to move to Esphome as I liked the YAML based config, makes for a more "infra-as-code" style for IoT devices :)

Since then I'm using it on all kinds now, my own ESP32 dev board like I mentioned for the BLE sensors, and a variety of Shelly 1 devices and random brands of WiFi smart plugs from Amazon.

That sounds great, I like Espurna for the web interface and general quality but I really hate the C-style header file configuration, it's very hard to update your code.

With YAML, I at least know that the file I have will continue to work across updates. Seems much more usable.

Reply on news.ycombinator.com