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.