Zigbee Home Automation

The coordinator and Home Assistant

Home Assistant runs on my Raspberry Pi. My ZHA configuration uses a USB-connected Zigbee coordinator with an Ember-compatible radio connection. ZHA works with the coordinator through the Zigbee software stack and exposes the supported controls, events and measurements in Home Assistant.

Zigbee device ↔ coordinator ↔ ZHA ↔ Home Assistant entity or automation

This path does not require an MQTT broker or a separate Z-Wave JS server. Those are other connection paths in my build, described in the MQTT and Z-Wave JS articles.

My Hue bridge has its own connection to Home Assistant. Zigbee devices joined to that bridge are not automatically part of the ZHA network. A device joins one Zigbee network at a time; Home Assistant can still combine devices from those separate networks in an automation.

What I connect through ZHA

These roles come from my configured devices, dashboard references and automation definitions. The table separates what a connection reports from what I use that information to do.

Scroll the table horizontally to compare all four columns.

My ZHA dashboards include alarm controls, switched outputs, occupancy and opening states, and measurements such as power, energy, battery and temperature. The functions available vary by device; pairing successfully does not mean every manufacturer-specific feature is exposed.

The CentraLite keypad and Alarmo

Commands in, alarm state back

My keypad automation receives ZHA events and maps the relevant commands to Alarmo arm or disarm actions. A separate automation responds to Alarmo state changes and updates the keypad's ZHA alarm-control entity for the corresponding mode.

Keypad command → ZHA event → Home Assistant automation → Alarmo
Alarmo state change → Home Assistant automation → keypad panel state

These are two directions of communication. Receiving a keypad request is different from Alarmo accepting it, and updating a keypad entity is different from verifying the physical keypad's response. When checking the workflow, both directions matter.

What my custom quirk changes

My local CentraLite 3400 quirk adapts several device-specific reports. It derives a battery percentage from reported voltage, adds an indication of keypad interaction and creates a timed tamper indication from the device's zone notifications.

• Battery is an estimate. The quirk converts voltage into a percentage rather than receiving a native percentage from this keypad.
• Interaction is not room occupancy. The quirk exposes keypad interaction as an occupancy entity and clears it after a timeout. It does not detect someone approaching the keypad or establish that a room is occupied.
• Tamper is a timed indication. The local implementation interprets the relevant notification as a tamper signal and clears it on a timer. That clearance is not confirmation that the cover has been physically restored.

The quirk includes a startup grace period to suppress enrollment-related notifications. Its behavior is specific to the device handling implemented here; it is not a general claim about every CentraLite firmware version.

The ZHA Device Handlers project explains the quirk mechanism and upstream device support. That link points to the upstream project, not a published repository for my local keypad changes.

Irrigation outputs and equipment monitoring

Rachio state into Zigbee output control

My irrigation configuration combines Rachio switch states with outputs on a Tuya TS0004 Zigbee relay. Home Assistant automations use Rachio state to select actions that turn the relevant ZHA outputs on or off. Related logic also checks those states at startup and periodically.

Some relay outputs appear as light entities in Home Assistant, so the automations use light actions to operate them. The entity type describes how the control is exposed in software; in this setup, those outputs participate in irrigation rather than room lighting.

Other configured paths use output-state changes for notifications, or combine relay and Rachio state with equipment information for counters. Those are software observations. A relay state alone does not prove that water is flowing, a valve moved or a watering cycle completed.

Metering alongside other equipment data

ZHA power readings are included in a configured notification alongside power information from other equipment integrations. My metering devices also expose supported electrical measurements such as energy, current and voltage for inspection in Home Assistant.

Power and energy answer different questions: power describes a reported rate of consumption, while energy represents accumulated consumption. Having those entities available does not establish that every reading is used in the Energy dashboard, or that every measurement has been calibrated.

My configuration also uses a ZHA switch-state input in an automation with a helper condition and a switching action. This is the same wider pattern: Home Assistant evaluates the logic, and each integration handles its own devices.

Reports, radio coverage and device support

Local Zigbee is one part of the workflow

ZHA provides a local connection to the joined devices. A wider routine still depends on Home Assistant and any other integration it calls. A working Zigbee relay connection does not establish that the Rachio side is available, just as a received keypad command does not establish that Alarmo changed state.

Network coverage and quirks solve different problems

I use the GLEDOPTO device as a Zigbee repeater. Router devices can help carry traffic through the mesh, but the existence of a router does not prove that a particular device is using it or has a healthy route. Coordinator placement, interference and powered routers remain part of connection troubleshooting.

A quirk adapts how a device's messages are interpreted. It cannot repair an unreachable radio device. Conversely, improving radio coverage will not correct a manufacturer-specific report that needs different handling.

Fresh reports matter

A saved battery value, a displayed contact state or an available control can outlast the last useful device report. Check for a fresh update when diagnosing a missing action. Battery-operated devices may also need waking for pairing or configuration work, following their own instructions.

Before changing coordinators, preserve the network backup and follow the supported migration process. Keep custom quirk code with the configuration needed to restore it. Network recovery and the continued behavior of a local customization are separate checks.

Checking the full path from device to result

The useful checks depend on where the information stops:

1. Check ZHA and the coordinator. Confirm the integration can communicate with its radio before investigating an individual automation.
2. Check a fresh device report. Look for the relevant keypad event, sensor update or output-state report. Avoid treating an old value as proof of a new interaction.
3. Check the interpretation. For the keypad, distinguish device reports from the quirk's estimates and timed indications. For the relay, check the entity actually used by the automation.
4. Check the automation trace. Inspect the trigger, conditions and selected action, then the state reported by Alarmo, Rachio or another participating integration.
5. Verify the intended result. A command request, a reported output state and a physical outcome are different observations. For the keypad workflow, check the return path as well.

The official ZHA documentation covers pairing, interference, device support and coordinator migration. In my build, ZHA supplies the direct Zigbee connection; Home Assistant makes those controls and measurements useful alongside the rest of the home.