Why Zigbee Sensors Disappear After Restarting Home Assistant

Zigbee sensors are usually not removed from the network after Home Assistant restarts. More often, Home Assistant temporarily loses access to the coordinator, opens a different serial port, starts the Zigbee integration before a dependent service is ready, or loads the wrong network database. Troubleshooting should begin not with pairing the sensors again, but with checking the coordinator, startup logs, and Zigbee network state files.

What to Check Before Making Any Changes

Do not remove devices from ZHA or Zigbee2MQTT, and do not reset the sensors. Pairing them again may hide the original cause, create duplicate entities, and make network recovery more difficult.

First, identify which stack you are using:

ZHA — the Zigbee Home Automation integration runs inside Home Assistant.
Zigbee2MQTT — a separate service manages the coordinator and sends data through MQTT.

Open the Home Assistant integrations page and check the status of ZHA or MQTT. Then review the log immediately after a restart. Look for messages about opening the serial port, an unavailable coordinator, database errors, conflicting access to the USB device, and lost MQTT connections.

Do not run ZHA and Zigbee2MQTT with the same coordinator at the same time. A serial port can be opened by only one process, and competing access causes unreliable startup or makes the entire Zigbee network unavailable.

Step 1. Determine Whether the Entire Network Is Affected

After a restart, compare the status of several devices:

Check a mains-powered Zigbee router, such as a smart plug, relay, or permanently powered light.
Check several battery-powered sensors of different types.
Check whether the coordinator management page is available.

If all devices are unavailable, the cause is almost certainly related to the coordinator, serial port, ZHA, Zigbee2MQTT, or MQTT. If only some battery-powered sensors are missing, the coordinator is probably working, but those devices have not yet communicated since the restart.

Battery-powered Zigbee sensors sleep most of the time. Home Assistant cannot immediately request their status after startup. Wake the sensor using its normal action: open the door, trigger motion, or press the service button as described by the manufacturer. Do not hold the reset button.

Step 2. Check the Stable Path to the USB Coordinator

On Linux, the coordinator may receive a different name such as /dev/ttyUSB0 or /dev/ttyACM0 after a restart. If the integration is configured with such a name, it may open the wrong device or fail to find the adapter.

It is preferable to use a persistent path from the /dev/serial/by-id/ directory. On a Linux host, you can list the available paths with:

ls -l /dev/serial/by-id/

The output should contain a link to the coordinator's actual device. Copy the full path and compare it with the ZHA or Zigbee2MQTT configuration.

If the directory is missing or empty, check the adapter's physical connection, USB port, cable, host power supply, and device passthrough to the virtual machine or container. In Home Assistant OS, information about detected hardware is available through the system interface; the exact menu location depends on the interface version.

For Docker and Virtual Machines

The container must receive the same physical coordinator every time it starts. Mapping only /dev/ttyUSB0 is unreliable. In the container configuration, use the persistent device path from the host or a stable mapping to an internal container path.

In a virtual machine, the USB adapter must reconnect automatically to the guest system after the hypervisor restarts. If the coordinator remains attached to the host, Home Assistant cannot open the radio module even when its configuration is correct.

Step 3. Find the ZHA Startup Error

When using ZHA, open the Home Assistant log immediately after startup. Check not only messages from individual sensors, but also entries from the ZHA integration and the radio library it uses.

Common error categories include:

the serial port does not exist;
access to the port is denied;
the port is already in use by another process;
the coordinator is not responding;
the wrong radio type is selected;
the Zigbee network database cannot be read or opened.

If ZHA is shown as an integration that failed to load, fix the coordinator error first. Reloading the integration without correcting the port will not solve the problem.

Do not select radio types by trial and error. The type must match the coordinator and its firmware. An incorrect selection may prevent startup, but it does not mean the sensors need to be paired again.

Step 4. Check Zigbee2MQTT and MQTT Startup

When using Zigbee2MQTT, the network depends on at least three components: the coordinator, the Zigbee2MQTT process, and the MQTT broker. Home Assistant may already be running while one of them is still unavailable.

Make sure the MQTT broker is running and accepting connections.
Check the Zigbee2MQTT log while it attempts to open the adapter.
Make sure Zigbee2MQTT connects to MQTT without continuously retrying.
Check whether the devices appear in the Zigbee2MQTT interface.

If the devices are visible in Zigbee2MQTT but unavailable only in Home Assistant, the radio network is working. Check the MQTT integration and device discovery mechanism instead of pairing the devices again.

If Zigbee2MQTT cannot find the coordinator, check the serial port setting in its configuration. Example structure without reference to a specific model:

serial:
  port: /dev/serial/by-id/ВАШ_ПОСТОЯННЫЙ_ПУТЬ

Do not copy this value from someone else's instructions: the identifier depends on the specific USB adapter and system.

Step 5. Check Whether the Zigbee Network Database Is Persistent

The coordinator stores some network parameters, but ZHA and Zigbee2MQTT also use local state files. If a container is recreated without a persistent volume, the configuration directory is replaced with an empty one, or an incomplete backup is restored, the interface may lose its device records.

For ZHA, make sure the Home Assistant configuration directory persists across restarts and is not stored in temporary storage. For Zigbee2MQTT, verify that its data directory uses persistent storage. Exact filenames and database formats depend on the software stack; do not edit them manually without a backup.

Signs of a storage problem include:

the initial setup starts after every container recreation;
the device list is empty even though the coordinator opens without errors;
the log reports that a new database is being created;
configuration changes disappear after a restart.

Before restoring data, stop the component that writes to the database. Use a backup created before the devices disappeared, and restore both the Zigbee component configuration and the associated coordinator parameters if the selected stack backs them up separately.

Step 6. Rule Out Changes to Network Parameters

Sensors will not connect to an automatically created new network even when the same coordinator is used. The Zigbee network identifiers, security key, and radio channel all matter. After a failure, do not create a new network, reset the coordinator, or replace the network key unless necessary.

If the problem appeared after migrating to another coordinator, restoring a backup, or moving between ZHA and Zigbee2MQTT, follow the official migration procedure for the selected project. Copying only the device list is not sufficient.

Without logs, a backup, and information about the previous configuration, it is impossible to determine reliably whether the original network parameters were preserved. In that situation, pairing the devices again may be the only option, but it should be attempted only after checking the port and state files.

Step 7. Check Power and USB Interference

The coordinator may be detected by the system but operate unreliably because of its power supply, a faulty cable, a USB hub, or radio interference. For troubleshooting:

Connect the coordinator through a short, high-quality USB extension cable.
Do not place it directly next to the computer case, storage devices, or USB 3.x devices.
Remove any unpowered USB hub from the connection.
Check whether the device disappears from the system after several restarts.

These steps do not replace log analysis. They are relevant when the port disappears intermittently, the coordinator resets, or communication returns after physically reconnecting the adapter.

Step 8. Allow the Network to Rebuild Its Routes

After the coordinator has been offline for an extended period, network devices may not restore their routes simultaneously. First, make sure the permanently powered Zigbee routers are available. Then wake the battery-powered sensors.

Do not restart Home Assistant repeatedly in quick succession. Each restart interrupts the coordinator connection again and makes it harder to distinguish a startup problem from temporary route recovery.

When Pairing Is Required Again

Pair the sensors again only when one of the following conditions has been confirmed:

a new Zigbee network was created and the old configuration is unavailable;
the device was reset to factory settings;
the sensor was removed from the network and does not return after being woken normally;
the coordinator migration was completed without transferring the network data.

In many cases, a device can be added again without deleting its existing entities first: Home Assistant or Zigbee2MQTT recognizes the previous IEEE address and links it to the existing record. The behavior depends on the stack and database state, so create a backup before starting the procedure.

Final Checklist

The active stack has been identified: ZHA or Zigbee2MQTT.
The log from the first startup after the restart has been checked.
The coordinator is available through a persistent /dev/serial/by-id/ path.
Only one Zigbee process is using the coordinator.
The USB device is correctly passed through to the container or virtual machine.
For Zigbee2MQTT, the MQTT broker and the connection to it have been checked separately.
The configuration and database directories use persistent storage.
No new network was created, and its key, channel, and identifiers were not changed.
Permanently powered Zigbee routers have been checked.
Battery-powered sensors have been woken without a factory reset.
A backup was created before migration or restoration.

Sources

The names of individual interface options and the supported migration methods may change. This guide intentionally does not specify version numbers; check the official documentation for the installed component to confirm current limitations.