Zigbee
A two-level gateway/end-device integration talking EZSP - direct serial to a bare Silicon Labs coordinator, no separate software required. A configured gateway has its own end devices joined to its network underneath it, added by hand rather than auto-discovered.
deCONZ/ConBee coordinators are a separate integration - see deCONZ - since the two talk completely different local protocols even though both are "Zigbee coordinators" conceptually.
Passing the USB stick through to Athena
Unlike deCONZ/Z-Wave/Matter above, this one needs no separate container - the coordinator's
serial port just needs to be visible inside Athena's own container. Both
docker-compose.yml and docker-compose-with-esphome.yml ship a
commented-out devices: mapping on the athena service for exactly this;
uncomment it and point it at your stick before adding a gateway:
# docker-compose.yml - uncomment on the athena service
devices:
- /dev/serial/by-id/<your-stick-here>:/dev/ttyUSB0
Use ls /dev/serial/by-id/ to find a stable name rather than a bare
/dev/ttyUSB0, which can shift across reboots if more than one USB-serial adapter is
plugged into the host. This pins one specific stick though - Docker resolves it to one fixed
device node at container start, so unplugging it (or swapping it for a different one) isn't
guaranteed to keep working without running docker compose up -d again.
Both compose files also document a second option right below that mapping, for real hot-plug
support instead: replace the devices: block with - /dev:/dev and add a
device_cgroup_rules: entry granting the whole USB-serial device class rather than
one pinned path. See either file's own comment on that Zigbee EZSP mount for the exact lines -
worth it if you expect to unplug/replug the stick, or swap it for a different one, without
restarting the container.
Adding a gateway
Devices & Services > Zigbee > "Add gateway" takes a serial device path (e.g.
/dev/ttyUSB0) talking directly to the coordinator over ASH framing and legacy EZSP
commands. End devices are added by hand under a connected gateway - IEEE address, endpoint, and
device type - rather than discovered automatically.
This integration is unverified against real coordinator hardware - built from ZCL cluster definitions used by production libraries, not smoke-tested against a live radio. deCONZ is the better-tested option if a new gateway fails to connect.
What's supported
- Switches - on/off, from the ZCL On/Off cluster.
- Dimmable lights - on/off plus brightness (ZCL Level Control), kept in Zigbee's own native 0-254 range rather than converted to a percentage.
- Color lights - adds hue/saturation color and color temperature (ZCL Color Control) on top of dimming.
- Temperature & occupancy sensors - read-only.
Every device type works with Dashboard cards and Automations exactly like any other integration. Zigbee entities aren't wired into the History page's own multi-entity graph picker yet.