Zigbee protocol
Zigbee and HoumeOS: the radio is at the gateway, the logic is on the server
One gateway carries dozens of devices. The screen sees devices, not protocols.
Why the radio sits outside the platform, what the path of one message looks like, and which practical advice we give about the network.
In short
Zigbee is a 2.4 GHz radio mesh: cheap devices, batteries that last for years, a network where a device passes on to its neighbour. HoumeOS has no radio of its own and does not plan one. Zigbee devices enter through a coordinator or a gateway that translates them into MQTT over the home/v1 contract. The choice of coordinator is still to be made.
What Zigbee is and where the border is
Zigbee runs on 802.15.4 and lives in a network led by a coordinator. That is its strength: small, cheap devices, batteries for years, signals that pass from device to device. That is also its border: the coordinator is a separate device with its own radio part, while the HoumeOS server is an ordinary machine in the LAN. We do not put both into one box.
- The coordinator carries the radio, not the server
- A translated device enters the same model as every other one
- There is no point in keeping the same history in two places
The path of one message
The sensor sends the change to the coordinator. The gateway translates it into an MQTT message on the device topic. The server records it as state, checks the rules and pushes it to the kiosk over the SSE stream. The command travels the same road backwards. None of these steps leaves the network of the house.
What is ready today
The catalog describes Zigbee as radio devices arriving through a gateway into MQTT, and shows whether the required dependency is present. The data model is ready for it: the protocol field of a device is a free string, and the demonstration records already describe devices with zigbee and a zigbee2mqtt style integration. The home/v1 contract, the rules, the rights, the journal and the history are ready as well.
What is still to come
Two things are missing and they are roadmap work, not promises: the choice of a coordinator and the integration module that fills the home/v1 topics from a real gateway. The MQTT package also has to enter the dependencies — today the broker code exists, but it has not been tested with a real broker because the package is not installed. Until that is done we do not say "we read your Zigbee devices".
Practical things about the network
If you already own Zigbee devices, half of the work is radio housekeeping. Keep the Zigbee channel away from the Wi-Fi channel (for example 15, 20 or 25 against 1, 6, 11) and the coordinator antenna away from USB 3.0 noise. Client isolation in the router blocks the kiosk to server path and must be off, and the server address has to be static — there is no automatic discovery in the LAN.
What works today and what is coming
We do not present upcoming work as available. This list matches the roadmap.
Works today
- Zigbee is described in the catalog as radio devices arriving through a gateway into MQTT
- The device model is ready: the protocol of every device is a free field
- The home/v1 contract and the simulation that speaks over the same path
- Rules, modes, rights, journal and history — regardless of which radio is used
Coming soon
- A coordinator choice and an integration module that fills home/v1 from the gateway
- The MQTT package in the dependencies and a test with a real broker in the LAN
Later
- A radio stack of our own in the platform — not planned
- Ready profiles for specific device brands — confirmed during a site survey
Frequently asked questions
Does HoumeOS support Zigbee today?
Not as a finished connection. The platform describes Zigbee as radio devices through a gateway and the data model is ready, but the choice of coordinator and the module that fills the home/v1 topics from a real gateway are still missing. We do not present an upcoming integration as available. If you already run a gateway into MQTT, that is precisely the link we document as the next step.
Which coordinator should I buy?
We do not recommend one blindly. The choice depends on how many devices you have, where the server sits and whether you also need Bluetooth for initial pairing. It is decided together with a survey of the site, because a coordinator is a radio device and noise, channel and distance are judged on the spot.
Zigbee or Matter — which should I choose?
Matter is further along with us: pairing really works through the controller, commands are local, and devices with metering also give their measured energy. Zigbee, in turn, is a huge park of cheap sensors that arrive only through a gateway. For a new house the sensible order is Matter first; for an existing investment in Zigbee sensors the answer is the gateway into MQTT.
Will my devices still work when the internet goes down?
Yes — that is the point of a local architecture. The server is in your network, the rules run on it, and the kiosk talks to the server rather than to a cloud. The coordinator and the gateway are local as well. Which is also why we are not in a hurry to add a foreign cloud bridge for Zigbee: it would put the dependency on a foreign server and an account right back in.
Do you already have Zigbee devices in the system?
In the demonstration data, yes — those records describe devices with the zigbee protocol and a zigbee2mqtt style integration, so you can see how a translated device looks on screen. That is not a finished path for your coordinator. The difference is visible in the status columns too: the model is ready, the real gateway is still to come.
We show the system on a live screen
The demo starts from your question: which devices, which protocols, which scenarios.