MQTT Entities Unavailable After Home Assistant Restart

Direct answer: When MQTT entities become unavailable after Home Assistant restarts, the most common problem is not the entity itself. Home Assistant has reconnected to the broker, but it has not yet received the discovery or availability messages required to rebuild the entity and mark the device online. The safest fix is to verify the broker connection, confirm the device republishes discovery after Home Assistant’s birth message, and check whether the availability message is retained. Do not delete the MQTT integration or recreate every entity until you know which message is missing.

What this problem looks like

MQTT entities worked normally before a Home Assistant restart but return as unavailable.
The device is powered and still publishes data, yet its entities do not recover.
Reloading MQTT temporarily restores some or all entities.
Entities appear only after the physical device restarts.
Manually republishing a discovery payload makes the entity return.
The broker log shows Home Assistant reconnecting, but the expected discovery or online message is absent.

This guide applies to MQTT discovery and manually configured MQTT entities. It is especially relevant to devices or bridges that generate Home Assistant discovery payloads, including custom firmware, gateways, scripts, and home-built sensors.

Why MQTT entities can stay unavailable

MQTT is message based. Home Assistant cannot infer a device’s current state merely because the broker is reachable. Depending on the entity configuration, it may need several different messages:

A discovery configuration message describing the entity.
A state message containing the current value.
An availability message such as online.
A new message before an expire_after timer runs out.

Home Assistant’s MQTT documentation explains that, during startup, existing discovered devices and entities can remain unavailable until their discovery messages are received and processed. It recommends that devices subscribe to Home Assistant’s birth message and use it as a trigger to resend discovery. This matters when the original discovery configuration was not retained or when the publishing device started before Home Assistant.

Availability is separate from state. A sensor may continue publishing a number while its availability topic still says offline. Conversely, an entity can be marked online but have an old or unknown state. Diagnose these message paths separately.

Before changing anything

Record one affected entity ID and its device name.
Open the MQTT integration and download diagnostics if available.
Copy the entity’s discovery topic, state topic, and availability topic.
Note whether the failure happens after every restart or only intermittently.
Back up configuration files before editing YAML, templates, automations, or broker settings.

Avoid clearing retained topics broadly. Retained MQTT messages may be controlling discovery and availability for many devices. Deleting them without an exact topic list can remove working entities or revive stale configurations in confusing ways.

Step 1: Confirm Home Assistant is connected to the correct broker

Open Settings → Devices & services → MQTT. Confirm the integration is loaded and does not show an authentication or connection error. If you recently moved the broker, changed credentials, or restored a backup, verify the host, port, TLS setting, username, and broker instance.

Use the MQTT listening tool in Home Assistant to subscribe temporarily to the affected device’s topic tree, such as device-name/#. Use the narrowest safe filter you know; avoid subscribing to # on a busy system for long periods. Restart or wake the affected device and observe whether messages arrive.

If no messages arrive, the problem is upstream of the entity: device connectivity, broker permissions, an incorrect topic, or the publisher itself. If messages do arrive, continue and distinguish discovery, state, and availability.

Step 2: Verify the discovery configuration is replayed

MQTT discovery topics normally begin with the configured discovery prefix, commonly homeassistant/. Listen for the exact configuration topic used by the affected entity. A valid discovery message should contain the entity configuration and should be published again when needed.

If the configuration is retained, a newly connected Home Assistant client should receive it from the broker. If it is not retained, the device or bridge must republish it after Home Assistant comes online. Many reliable publishers do both: retain the discovery configuration and also respond to the Home Assistant birth message.

Check the publisher documentation before changing retain behavior. Retaining a discovery configuration is normal; retaining every kind of state or command message is not automatically correct.

Step 3: Test the Home Assistant birth-message path

Home Assistant publishes a birth message when MQTT becomes available. A discovery publisher can subscribe to that status topic and resend its configurations when it sees the online payload. If entities appear only after restarting the device, this replay path is probably missing or broken.

Identify the birth topic and payload configured for Home Assistant.
Confirm the publishing device or bridge subscribes to that exact topic.
Check capitalization and spacing in the expected payload.
Restart only the MQTT integration or Home Assistant once while listening.
Verify that the publisher responds by sending its discovery configurations again.

Do not create an automation that repeatedly floods discovery messages. One response to the relevant birth event is enough.

Step 4: Inspect the availability topic and retained flag

For an entity with an availability topic, Home Assistant uses the configured available and unavailable payloads. The defaults are often online and offline, but publishers can use other values. The payload must match exactly.

The official MQTT binary-sensor documentation notes that when the availability message is not retained, a sensor may display unavailable after Home Assistant starts because no current availability message has arrived. Retaining the latest availability status allows a subscriber to receive it immediately. A device should normally publish a retained offline message through its Last Will and Testament and replace it with a retained online message after a successful connection.

Check for these failure patterns:

The online message uses a different topic than the entity configuration.
The device publishes Online while Home Assistant expects online.
A retained offline message remains after the device reconnects.
Multiple availability topics require all topics to be online when any was intended.
The publisher reconnects without sending its current online state.

Step 5: Separate state retention from availability retention

Do not assume the state message should be retained because availability should be retained. The correct choice depends on the entity. A retained temperature reading can provide an immediate value after restart, but it may also present a stale reading as current. Home Assistant’s MQTT sensor documentation cautions against retaining state when expire_after is used because replaying an old retained value can make an expired sensor appear available again.

For event-like data—button presses, motion events, one-shot commands—retaining the state is usually wrong. For a slowly changing measurement, retaining may be useful if the age and availability logic are handled correctly. Follow the device integration’s documentation.

Step 6: Check `expire_after` and message frequency

If the entity works briefly and then becomes unavailable, inspect expire_after. The publisher must send a valid update before the timer expires. A sensor configured to expire after 60 seconds cannot remain available if it reports every five minutes.

Compare the configured expiry with the real publish interval, including battery-saving sleep. Allow enough margin for Wi-Fi reconnection, broker delays, and normal jitter. Do not reduce battery life by forcing excessive updates merely to satisfy an unnecessarily short expiry.

Step 7: Look for stale or duplicate discovery configurations

If the same physical device has multiple entities or old names, search the broker’s retained discovery topics for obsolete configurations. A changed unique_id, discovery topic, or device identifier can create a second entity instead of updating the first.

Remove only a configuration you have positively identified. The standard discovery removal method is to publish an empty retained payload to the exact obsolete configuration topic. Before doing so, save the topic and payload so you can restore it. Never bulk-delete retained messages as a first troubleshooting step.

How to verify the fix

Restart Home Assistant once; do not restart the MQTT device at the same time.
Confirm the broker connection returns normally.
Watch for the Home Assistant birth message.
Confirm discovery is replayed or delivered from retained storage.
Confirm the current availability message is received.
Confirm a fresh state arrives and the entity becomes available.
Wait longer than the previous failure interval to ensure it stays available.

Rollback and recovery

If a configuration change makes the problem worse, restore the saved discovery payload, return the previous retain settings, and restart only the affected publisher. If you edited YAML, restore the backup and validate configuration before restarting Home Assistant. If many devices fail simultaneously, investigate the broker, credentials, DNS, firewall, storage, or MQTT integration rather than resetting every endpoint.

When to escalate

Collect the Home Assistant version, installation type, MQTT integration diagnostics, broker version, exact affected topics with secrets removed, timestamps, and a short sequence that reproduces the failure. Report firmware-specific behavior to the device or bridge project. Never post broker passwords, access tokens, private certificates, or complete diagnostics without reviewing them for sensitive information.

Prevention

Make discovery publishers respond to the Home Assistant birth message.
Retain discovery configurations and availability status where the publisher supports it correctly.
Use stable unique IDs and topic names.
Document state, availability, and expiry behavior separately.
Back up broker configuration and custom publisher code.
Test one controlled Home Assistant restart after firmware or broker changes.

Use a controlled message trace to prove which stage fails

When several MQTT entities behave differently, capture a short, time-bounded trace for one affected device. Begin listening before restarting Home Assistant, note the timestamp of the birth message, and then record the order in which discovery, availability, and state messages arrive. Remove credentials and sensitive payload fields before saving or sharing the trace.

The sequence matters. If discovery arrives but availability never follows, investigate the publisher’s connection and Last Will configuration. If availability arrives but state does not, examine the device’s publish interval, sleeping behavior, and state topic. If no discovery arrives until the device restarts, the birth-message subscription or retained discovery configuration is the likely gap. A trace converts a vague “unavailable” symptom into a specific missing message.

Special considerations for sleeping and battery-powered devices

A sleeping sensor may not respond immediately to a Home Assistant restart. Its state and availability design should reflect the expected wake interval. Do not force a battery device to remain awake or publish excessively simply to make the interface update sooner. Compare the configured expiration period with the longest normal sleep interval, including weak-signal retries and seasonal reporting behavior.

Some publishers intentionally omit an availability topic and rely on the age of the last state. Others use a bridge-level availability topic shared by many child devices. Identify the model actually implemented before changing retain flags. Applying a generic online/offline pattern to a sleeping product can mark a healthy device unavailable between reports.

Broker-session and permission checks

After credentials, TLS settings, or access-control lists change, a publisher may connect but lose permission to publish discovery or availability topics. Review broker logs for denied subscriptions or publishes, using the exact client ID and topic. Also check for duplicate client IDs: MQTT brokers normally disconnect the earlier session when another client connects with the same identifier, which can create a repeating online/offline pattern.

Make one reversible change at a time. Correct the topic permission or client ID, reconnect the publisher, and repeat the controlled trace. Avoid broad wildcard permissions as a shortcut; grant only the topic access the device or bridge requires.

What to include when escalating

Provide the broker version, Home Assistant version and installation type, publisher firmware, discovery prefix, redacted topic names, QoS and retain settings, availability mode, expiry configuration, and a timestamped message sequence. State whether reloading MQTT, restarting Home Assistant, or restarting the publisher changes the outcome. Keep broker passwords, certificates, access tokens, unique device identifiers, and complete unredacted payloads private.

Evidence and testing disclosure

Applies to: current Home Assistant MQTT discovery and manually configured MQTT entities, including publishers that use birth messages, availability topics, retained configuration, or expire_after. Expected result: after Home Assistant restarts, the broker reconnects, discovery is replayed or retained, the current availability arrives, and a fresh state restores the entity without restarting the physical device. Verification: capture one time-bounded trace in the order birth → discovery → availability → state. Rollback: restore saved topic payloads and previous retain or expiry settings if a change fails. Testing status: this guide follows official Home Assistant MQTT behavior; Troubliq did not test every third-party publisher. Last reviewed September 30, 2026.

Sources

Last reviewed: September 8, 2026.

Related Troubliq guides: Start with the safe diagnostic method and browse all troubleshooting guides.

Decision guide: what should be retained?

Retain the discovery configuration when the device should be reconstructed automatically after Home Assistant reconnects. Retain the latest availability status when subscribers need to know immediately whether the device is online, and configure Last Will and Testament so an unexpected disconnect leaves an accurate offline status. Treat state retention as a separate design choice.

For a temperature, energy total, or other slowly changing measurement, a retained state can be reasonable when users understand its timestamp and no conflicting expiry logic exists. For motion, button presses, doorbell events, and commands, a retained state can replay an old event as though it just happened and is usually unsafe. For sensors using expire_after, follow the official warning about retained state and test restart behavior carefully.

If you do not control the publisher, do not compensate with broad broker cleanup. Document the exact topics, capture a short message trace, and report the missing discovery replay or availability behavior to the device project. A precise report is more useful than repeatedly reloading the integration.

Find your next troubleshooting path

Use the related guide that matches the next confirmed layer of the failure. Avoid changing unrelated systems at the same time.

MQTT entities unavailable after Home Assistant restart