You restart Home Assistant — or the MQTT broker, or the whole host — and every Zigbee2MQTT entity flips to “unavailable” at once: lights, sensors, switches, all of it. Nothing was unplugged. Nothing paired badly. Open the Zigbee2MQTT frontend and every device is right there, responding to toggles and reporting battery and link quality like nothing happened. The break is entirely on the Home Assistant side.
This is a Zigbee2MQTT plus Home Assistant plus self-hosted MQTT broker setup — Mosquitto is the common case — and the fix has nothing to do with re-pairing devices or rebuilding the mesh. It’s a single MQTT topic that doesn’t get refreshed the way you’d assume.
This is a different failure from Zigbee2MQTT’s per-device availability settings — the availability block and its active and passive timeouts — which mark an individual device unavailable when it stops reporting. This is a bridge-level gap that marks everything unavailable at once, whatever those timeouts say.
The symptom: everything’s unavailable, but Zigbee2MQTT disagrees
The tell is the mismatch. If devices were genuinely offline — dead batteries, a mesh hole, a dropped coordinator — Zigbee2MQTT’s frontend would agree with Home Assistant: stale last_seen, no response to commands, degraded link quality. Here its view is clean, every device answers immediately, and the entities all fail together rather than one at a time. Simultaneous failure across unrelated devices points upstream, at the bridge or the MQTT layer.
What’s actually happening: bridge/state never gets refreshed
Zigbee2MQTT publishes its own connectivity status to a dedicated topic, zigbee2mqtt/bridge/state, separate from the per-device topics each entity reads. Home Assistant ties the availability of every Zigbee2MQTT entity to that topic: if it doesn’t say online, those entities go unavailable regardless of what the device topics report.
When Home Assistant restarts, its MQTT integration announces itself with a birth message — by default online on homeassistant/status. Zigbee2MQTT listens for it and responds by republishing discovery and cached device states, so entities pick up fresh values immediately rather than waiting for each device to report on its own schedule. According to the reporter’s code-level analysis in GitHub issue #32067, the handler that runs that republish explicitly excludes the bridge/coordinator entity — so bridge/state is simply never part of the pass. That’s the reporter’s own reading of the code, not a maintainer confirmation; the issue was closed without either a rebuttal or an acknowledgment.
Retain is the second half of the picture, and it works the opposite way round from how it usually gets described. Zigbee2MQTT publishes bridge/state as a retained message, so under normal conditions the broker hands the last value straight to any client that subscribes — which is exactly why most Home Assistant restarts recover fine in spite of the republish gap. The retained copy is what covers for it. Lose that copy and nothing backfills it: a broker restart discards retained messages unless the broker is configured to persist them to disk, and Zigbee2MQTT’s force_disable_retain option strips the retain flag from everything it publishes if someone has switched it on.
zigbee2mqtt/bridge/state <- never republished on HA's birth message zigbee2mqtt/aqara_switch_01 <- republished normally, entity data is fine zigbee2mqtt/living_room_plug <- republished normally, entity data is fine
So there are two routes to the same symptom, and they compound: the retained copy is stale or gone, and the birth-message republish that would refresh it skips the bridge entity. Home Assistant reads an empty or offline bridge state, and every entity keyed to it goes unavailable while the device topics stay current and correct.
Is this new? No — this has never been fixed
This isn’t a regression from a recent Home Assistant release. The same gap — bridge/state stuck offline and never republished on reconnect — was reported for a plain Mosquitto broker restart back in November 2020, in GitHub issue #4854. What #32067 adds is the Home Assistant birth-message variant, which became more visible after a behavior change in a Home Assistant 2026.5 beta. Same long-standing design gap, not a new bug.
#32067 was closed as not planned, so there’s no upstream fix queued for this behavior. Treat the workarounds below as the permanent answer rather than a stopgap — and check the issue itself if you want its current status.
Fix 1: restart Zigbee2MQTT (fast, manual)
The quickest fix is restarting Zigbee2MQTT itself, rather than Home Assistant or the broker. On its own startup Zigbee2MQTT runs its full initial-connection sequence, which does publish bridge/state: online, and that clears the stuck entities immediately — the workaround described in #32067. It works every time this gap is the cause, but it’s manual: you have to notice and restart the add-on or container each time it recurs.
Fix 2: make the birth-message handshake actually fire
The durable fix is making sure the birth message reaches Zigbee2MQTT in the first place. The handshake depends on both sides agreeing on one topic, and a mismatch fails quietly — Zigbee2MQTT simply never hears anything, and nothing on either side logs an error about it.
Check Home Assistant’s side first. Birth and will messages are no longer set in configuration.yaml: the MQTT broker’s YAML configuration block was removed in Home Assistant 2023.4, and these options now live in the integration’s own settings, under Settings → Devices & services → MQTT → Configure → Re-configure MQTT, with advanced mode enabled on your user profile. The default birth message is online on homeassistant/status.
Then check Zigbee2MQTT’s side, which is where carried-over configurations usually break. Zigbee2MQTT listens on whatever homeassistant.status_topic is set to. Since Zigbee2MQTT 2.0.0 that defaults to homeassistant/status; before that the default was hass/status, and a config still pinning the old value never sees the birth message at all (GitHub issue #27458).
homeassistant: status_topic: homeassistant/status
If both sides already match and entities still stick on unavailable, an automation that re-fires the birth message a short delay after Home Assistant finishes starting has worked for people on the Home Assistant community thread on this exact symptom — giving Zigbee2MQTT a second chance to run its republish pass once the rest of the startup sequence has settled.
- alias: "Re-publish MQTT birth message after HA start"
triggers:
- trigger: homeassistant
event: start
actions:
- delay: "00:00:30"
- action: mqtt.publish
data:
topic: homeassistant/status
payload: online
Reports on that thread vary enough that this belongs in the “worked for others” column rather than the guaranteed one — test it against your own setup rather than assuming it behaves identically. My own read: fix the topic match first and only add the automation if the symptom survives it. The automation papers over a timing problem, while a mismatched status topic is a real misconfiguration that will keep costing you every other MQTT integration that depends on the same handshake.
Fix 3: keep the retained copy across a broker restart
If the symptom follows a broker restart rather than a Home Assistant one, the missing piece is the retained bridge/state message the broker threw away. Mosquitto’s own defaults leave persistence off, though packaged builds — distribution packages and the Home Assistant add-on among them — commonly enable it, so check yours rather than assuming either way.
persistence true persistence_location /var/lib/mosquitto/
With persistence on, the retained online message survives the broker restart and a reconnecting Home Assistant reads it straight back. That doesn’t touch the birth-message gap in Fix 2 — it’s a separate hole in the same path, and a setup can have both.
What this isn’t: three restart problems that look similar
Three other “something broke after a restart” symptoms in this cluster look alike and have different causes. Be precise about which one you have before changing settings.
| Symptom | Real cause | Covered here? |
|---|---|---|
| All entities unavailable after HA restart, Z2M frontend looks fine | bridge/state stale and not republished on the birth message |
Yes — this article |
| Device state/values revert or don’t persist across a restart | retain and Zigbee2MQTT’s state cache behave differently depending on which of the three things restarted |
No — see the retain vs state.json guide |
last_seen looks stuck or stale |
Timestamp semantics — what last_seen actually tracks, not a connectivity failure |
No — see the last_seen explainer |
| Devices missing entirely after a restart, not just unavailable | database.db corrupted or wiped |
No — see the database.db recovery guide |
If your devices are still listed in both Home Assistant and Zigbee2MQTT but simply flagged unavailable, this article’s fix applies. If they’ve vanished from Zigbee2MQTT itself, that’s the database case, not this one. For background on how Zigbee2MQTT lays out its MQTT topics — including where bridge/state sits relative to the per-device ones — see our MQTT topics explainer.
FAQ
Why does Zigbee2MQTT show all devices unavailable after a restart?
Home Assistant ties Zigbee2MQTT entity availability to the zigbee2mqtt/bridge/state topic. When Home Assistant restarts and sends its birth message, Zigbee2MQTT republishes individual device states but — per the code-level analysis in GitHub issue #32067 — excludes the bridge/coordinator entity from that pass, so bridge/state never gets refreshed. If the retained copy on the broker is also stale or gone, every dependent entity goes unavailable.
Does restarting Zigbee2MQTT fix devices stuck unavailable in Home Assistant?
Yes, in this specific case. Zigbee2MQTT runs its full connection sequence on its own startup, which does publish bridge/state: online, clearing the stuck state immediately. It’s a manual fix you repeat each time the symptom recurs, not a permanent setting.
What is zigbee2mqtt/bridge/state and why does it matter?
It’s the MQTT topic Zigbee2MQTT uses to report whether the bridge itself is connected, separate from the per-device topics. Home Assistant ties entity availability to it, so a stale or empty value takes every entity down even when the devices are responding normally.
Do I need to set retain on my MQTT broker to fix this?
Retain isn’t something you switch on at the broker — it’s a flag the publisher sets, and Zigbee2MQTT already publishes bridge/state retained. What’s worth checking broker-side is persistence: without it, a broker restart discards every retained message, that one included (Fix 3). After a Home Assistant restart, retain isn’t the gap at all — the missing republish is, so Fixes 1 and 2 are what apply.
Is this a Zigbee2MQTT bug or a Home Assistant bug?
It sits on the boundary between the two, and #32067 was closed as not planned, so there’s no official fix coming from either side. The mechanism — the birth-message handler skipping the bridge/coordinator entity — is the reporter’s own code analysis in the closed issue, neither confirmed nor denied by the Zigbee2MQTT team.
What this article verified
This is research-synthesis, consistent with this cluster’s sourcing-only voice: no hardware was involved and no bench testing was performed for this piece.
Two GitHub issues carry the behavior. #32067 is the current Home Assistant-restart report, closed as not planned; its root-cause explanation is attributed throughout to the reporter’s own code analysis rather than a maintainer statement, because the issue was closed without either. #4854 is the 2020 report of the same gap after a plain Mosquitto restart, and #27458 covers the birth-topic mismatch. The two workarounds come from a long-running Home Assistant Community thread and are corroborated by multiple independent reports rather than a single one.
Two claims were corrected against primary sources while editing. Retain is a flag the publishing client sets, not a broker default that Mosquitto leaves switched off — Zigbee2MQTT publishes bridge/state retained, and what brokers commonly lack by default is on-disk persistence of retained messages across a restart. And birth and will messages are no longer configured in Home Assistant’s configuration.yaml; that block was removed in Home Assistant 2023.4 and the settings moved into the MQTT integration itself.
Zigbee2MQTT’s official Device Availability documentation covers per-device availability timeouts and backoff but has no section on this bridge-level republish gap — that absence is stated here rather than implied to be covered. Everything above stays local: no cloud, no app, no vendor account.