Blog

Quick answer: If Home Assistant Core becomes unresponsive and the Supervisor watchdog restarts it several minutes later, collect one complete failure cycle before changing anything. Check memory, CPU, disk I/O, database activity, blocked integrations, recorder growth, and the first error preceding the watchdog action. A watchdog restart is the recovery event, not necessarily the root cause.

Public reports describe Core 2026.9 systems becoming unresponsive without an obvious out-of-memory event. Because many unrelated failures produce the same visible symptom, this guide uses a measurement-first process and avoids claiming a universal fix.

Preserve evidence before restarting

• Note the exact time the interface stopped responding.
• Save Core, Supervisor, host, and add-on logs covering several minutes before the event.
• Record Core, OS, Supervisor, and database versions.
• Record CPU, memory, disk utilization, free space, and database size.
• List integrations or add-ons changed immediately before the first incident.

Confirm what is actually unresponsive

Test the local IP address from a second device. If the interface fails but SSH, the observer, or host metrics remain available, the host may be healthy while Core is blocked. If the entire machine disappears from the network, investigate power, storage, hardware, virtualization, and host networking instead.

Build a simple timeline

1. Last successful automation or state update
2. First delayed or failed request
3. First warning or exception in the log
4. Time the watchdog detected failure
5. Time restart began
6. Time Core became available again

The first abnormal event is more useful than the final watchdog message.

Check memory without assuming an OOM

Look for steadily increasing memory, sudden spikes, swap pressure, and the host kernel’s out-of-memory messages. If memory remains normal, do not label the incident a memory leak. A blocked event loop, slow storage, database lock, integration timeout, or network filesystem can make Core appear dead without exhausting memory.

Check the Recorder database

A large or unhealthy database can create long writes, migrations, purges, and startup delays. Record the database engine and size. Look for locked, malformed, disk-full, and unusually slow query messages. Do not delete the database as a diagnostic shortcut.

Reduce unnecessary high-frequency entities only after identifying them. Broad exclusions can remove history you need and may hide the actual source.

Check integrations and add-ons

Look immediately before the freeze for an integration generating repeated exceptions, reconnect loops, or blocking calls. If one component is consistently named, investigate its current release notes and issue tracker. Disable only the suspected nonessential component with a backup and a reversible plan.

Add-ons are separate processes but can still saturate storage, CPU, memory, or network resources. Compare their resource graphs with the incident time.

Check storage and host health

• Confirm adequate free disk space.
• Check for filesystem or I/O errors.
• On SD-card installations, treat repeated I/O errors as a possible storage failure.
• On virtual machines, inspect host contention and storage latency.
• Confirm system time and network connectivity remain stable.

Controlled isolation

1. Back up the current system.
2. Choose the strongest single suspect from the logs.
3. Change only that component.
4. Observe long enough to cover the normal failure interval.
5. If the freeze returns, restore the previous state and test the next evidence-backed suspect.

Changing several integrations, database settings, and network components together makes the result impossible to interpret.

Rollback or update forward?

If incidents began only after 2026.9 and no environmental change occurred, check later patch notes and the active issue report. Update forward when a patch explicitly addresses the condition. Roll back only with a verified pre-update backup and an understanding that database and configuration state will also move backward.

Do not do these things first

• Do not schedule automatic restarts to hide the problem.
• Do not disable the watchdog.
• Do not delete the Recorder database without diagnostic evidence.
• Do not remove every custom integration at once.
• Do not publish raw diagnostics containing secrets or personal data.

Decision tree

1. Did the whole host disappear? Investigate hardware, storage, power, virtualization, and host networking.
2. Only Core stopped responding? Inspect the first Core error and resource timeline.
3. Memory climbed continuously? Identify the component correlated with the growth.
4. Storage latency or database errors appeared? Protect the backup and diagnose storage or Recorder.
5. One integration loops before every freeze? Isolate that integration reversibly.
6. No local cause is visible and failure began with 2026.9? Compare the active issue and newer patch releases.

Incident reference

See Home Assistant Core issue #181318 for a current report of Core becoming unresponsive followed by a Supervisor watchdog restart. The report is a useful signal, but it does not establish one cause for every installation.

Last reviewed: September 23, 2026.

Additional evidence-based diagnostics

Measure event-loop symptoms

A blocked event loop can stop API and frontend responses while the host still answers. Look for warnings about blocking calls, integrations taking excessive setup time, executor saturation and long event-loop delays before the watchdog restart. Do not assume high CPU is required for Core to become unresponsive.

Correlate resource history

Compare CPU, resident memory, swap, disk latency, database writes and network errors across the minutes before the freeze. A value that rises after Core is already stuck may be a consequence. Prefer repeated correlations across two incidents before changing configuration.

Check Recorder workload

Recorder purges, repacks, migrations and high-frequency entities can create intensive storage activity. Record the database engine, size, purge schedule and relevant errors. Do not delete the database or broadly exclude entities until logs and timing make Recorder a credible suspect.

Inspect network-mounted dependencies

Integrations or backups that depend on an unavailable network share, DNS server or remote database can stall or retry. Compare network and resolver events with the freeze. Restore connectivity or disable only the proven nonessential dependency using a reversible change.

Review custom integration behavior

Repeated exceptions, rapid reconnect loops and synchronous calls from one custom integration can degrade Core. Confirm the component version and upstream compatibility. Disable only the strongest suspect after a backup, then observe for at least the normal interval between failures.

Separate add-on load from Core faults

Add-ons run separately but share host CPU, memory, disk and networking. A camera processor, database, backup job or log flood can starve Core. Compare add-on resource graphs and schedules with the timeline instead of removing add-ons indiscriminately.

Use the watchdog correctly

The watchdog restores availability when Core stops responding; it does not diagnose the cause. Keep it enabled. Automatic scheduled restarts can erase evidence and create the appearance of stability while the underlying lockup remains.

Build a controlled comparison

Change one variable, document it, and observe through the expected failure window. If the incident returns, reverse that change before testing the next hypothesis. Several simultaneous changes cannot produce reliable evidence and complicate rollback.

Validate durable recovery

Confirm Core remains responsive past the prior failure interval, entity timestamps remain current, automations execute, database writes continue, resource levels stabilize and one controlled Core restart completes without a new freeze.

Escalation package

Provide the complete version set, installation type, database engine, sanitized log window beginning before the freeze, resource timeline, watchdog time and changes already tested. Remove tokens, addresses, coordinates, camera URLs and personal entity names.

Testing disclosure

Troubliq has not reproduced every watchdog restart scenario. The article uses the cited upstream incident as a demand signal while keeping the diagnostic branches applicable to other measured causes; it does not assert that Home Assistant 2026.9 universally causes freezes.

Related Troubliq resources

Use the Home Assistant Error Decoder to match the exact message, then review the current Home Assistant problems hub for related verified guides.

Advanced interpretation and recovery

CPU interpretation

Sustained CPU saturation before each freeze suggests a workload or loop, but a brief spike during restart is expected. Break usage down by Core, add-ons and host services. If one integration floods logs or state updates at the same time, isolate it rather than increasing hardware blindly.

Memory interpretation

Track resident memory and swap over hours, not only the value after restart. A monotonic increase associated with one integration supports a leak hypothesis. Stable memory during a freeze shifts attention toward blocking I/O, event-loop stalls, database locks or network waits.

Disk-latency interpretation

High I/O wait, filesystem errors or long database commits can make Core unresponsive without high CPU. Check the storage device and host logs. On flash media, repeated read/write errors justify immediate backup and storage replacement planning.

Database-engine branch

SQLite problems are diagnosed through Core logs, database integrity and host storage. External MariaDB or PostgreSQL adds network, server, connection-pool and authentication layers. Confirm which engine is active before applying repair commands. Preserve statistics and backups before database work.

Automation-load branch

A looping automation can generate rapid service calls and state changes. Inspect traces and logbook activity near the incident. Disable only the confirmed automation and verify whether the event rate and responsiveness normalize; do not disable all automations as a long-term workaround.

Template and sensor branch

Templates that update excessively or reference many entities can create work across the state machine. Compare recently changed templates and high-frequency sensors with the timeline. Optimize only measured hot paths so useful state history is not lost.

Network timeout branch

Cloud integrations, DNS failures and unreachable local devices can generate reconnect loops. Well-behaved integrations should not block Core, but custom components may. Correlate the first timeout and component logger with the freeze before disabling anything.

Backup-job branch

Backup creation, compression, upload and retention can stress storage and CPU. If incidents align with scheduled backups, test the job separately, inspect destination availability and reduce overlap with database maintenance. Never stop a backup by cutting host power.

Thermal and power branch

Throttling, undervoltage and unstable power can cause broad slowness or host resets. Check platform health indicators and hardware logs. Replace suspect power supplies or cooling using manufacturer guidance; software changes cannot repair failing hardware.

Virtual-machine branch

Inspect host contention, ballooning, storage latency, snapshots and CPU scheduling. A responsive hypervisor with a stalled guest suggests a guest resource or device problem; simultaneous issues across guests point to the host.

Expected-result interpretation

If disabling one proven custom component prevents recurrence past the normal interval, investigate that component upstream. If database repair removes I/O errors and writes remain stable, monitor Recorder. If the whole host still stalls, leave Core configuration intact and escalate to hardware or virtualization diagnostics.

Recovery documentation

Record the last incident time, root-cause evidence, exact change, observation period and final versions. Preserve the pre-repair backup until the system operates normally through several expected cycles.

Prevention

Keep storage healthy, control high-frequency entities, review custom components before Core upgrades, stagger intensive backup and database tasks, monitor free space and resources, and retain logs long enough to capture the minutes before a watchdog event.

Log-rate diagnosis

A component writing thousands of repetitive messages can consume CPU, storage and I/O while hiding the first useful exception. Measure the logger and message that dominates the interval. Correct the component or temporarily raise only that logger’s threshold after preserving evidence. Do not disable all logging, because the next freeze would become harder to diagnose.

State-change diagnosis

Review the busiest entities and whether their update rate changed before the problem. A noisy power sensor, malformed MQTT publisher or template feedback loop can create excessive state and database activity. Correct the measured source, then confirm state-change and Recorder write rates return to normal without losing necessary monitoring.

Health-check interpretation

If the Supervisor watchdog restarts Core, record how long the health check failed and whether API, frontend and automation processing stopped together. A proxy-only outage should not normally require a Core restart. Matching the watchdog time to Core logs helps distinguish a real Core stall from an external access problem.

Post-fix observation window

Observe the installation beyond the longest previous interval between incidents. Include at least one scheduled backup, Recorder purge or other recurring workload that previously overlapped a freeze. A short period of responsiveness immediately after restart is not enough to establish a durable repair.

Safe temporary mitigation

If a nonessential integration is strongly implicated but no fix exists, keeping only that integration disabled can be a reasonable temporary mitigation. Document the lost functions, monitor the upstream issue and retest after a supported update. Do not normalize scheduled whole-system restarts as the permanent solution.

Direct answer: On Android, reliable zone tracking requires the Home Assistant Companion app to have location permission set to Allow all the time, the appropriate location sensors and Zone Based Tracking enabled, and a working connection to the Home Assistant server while away from Wi-Fi. Begin with the app’s Location History troubleshooting screen: it shows whether Android produced an update, why the app accepted or skipped it, and whether the update reached the server.

This guide addresses Home Assistant Android location or zone tracking that is not updating. It is designed to preserve working configuration and evidence before any reset, deletion, or re-pairing. Work in order and stop when the first confirmed cause is corrected. Screens and menu labels can vary by Home Assistant release and installation method.

Symptoms and scope

Use the following signs to decide whether this guide matches your problem. Similar-looking failures can come from different layers, so record what still works as carefully as what fails.

• The person or device_tracker entity remains home after the phone leaves.
• Zone enter or exit automations arrive late or not at all.
• Location updates work only while the app is open.
• Tracking works on home Wi-Fi but stops on cellular data.
• The app records a location but the entity in Home Assistant does not change.

Most likely causes, ranked

Start with the causes that fit the evidence. Do not apply every fix at once: simultaneous changes make it impossible to know what solved the problem and can create a second failure.

• 1. Android location permission is set to While using the app, approximate only, or otherwise restricted.
• 2. Zone Based Tracking or required location sensors are disabled in Companion App settings.
• 3. Battery optimization, sleeping apps, background-data limits, Data Saver, or manufacturer power management suspends the app.
• 4. The external Home Assistant URL, certificate, VPN, DNS, or mobile network cannot reach the server away from home.
• 5. Google Play services, device location, Wi-Fi/Bluetooth scanning, or GPS accuracy is impaired.
• 6. The app deliberately rejects stale, inaccurate, or duplicate readings; the location history explains the reason.

Safe diagnostic procedure

Before beginning, make a current backup when the procedure could affect configuration or stored data. Record the Home Assistant version, installation type, device or app version, the first failure time, and the last known working change. Redact secrets from every screenshot and log excerpt.

Step 1: Capture the exact failure

Open the Home Assistant Companion app → Settings → Companion app → Troubleshooting → Location tracking and enable Location History. Reproduce one departure or movement. Read the event details rather than guessing: determine whether Android generated an update, whether the app skipped it, and whether server delivery succeeded.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 2: Protect the current state

In Android Settings → Apps → Home Assistant → Permissions, set Location to Allow all the time and enable precise location where available. Menu names differ by manufacturer. Also confirm the phone’s main Location switch is on. Do not grant permissions to unrelated apps.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 3: Verify the affected layer

In Companion App settings, enable Location Zone and Zone Based Tracking as documented for Android. Review the device’s enabled sensors in Home Assistant. Avoid enabling every high-frequency sensor merely for troubleshooting; start with the minimum location features required for presence.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 4: Test the least-destructive cause

Remove Home Assistant from battery optimization or sleeping-app lists using the device maker’s supported settings. Allow background activity and unrestricted battery use when necessary. Samsung, Xiaomi, OnePlus, and other vendors add controls beyond stock Android, so verify after system updates.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 5: Inspect configuration and identity

Allow background data and cellular data for Home Assistant. If Data Saver is active, grant the app unrestricted data as appropriate. Turn off Wi-Fi and open the configured external Home Assistant URL in the app; a server connection failure is not a GPS failure.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 6: Check network, power, or permissions

Check the Companion app connection settings, internal URL, external URL, SSID rules, VPN, and certificate trust. Do not weaken TLS validation or expose Home Assistant directly merely to make tracking work. Repair the certificate, proxy, tunnel, or secure remote-access path.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 7: Apply the narrow repair

Review zone geometry and the Home zone radius. Overlapping zones, a huge Home radius, GPS drift, and short trips can make a correct location appear wrong. Compare the raw coordinates privately and never publish home coordinates or a screenshot showing your address.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 8: Observe through a full cycle

Send a one-time request-location notification only as a diagnostic if the device supports it. It can prompt an update, but it is not a substitute for background permission and may fail when the operating system cannot obtain a timely fix. Avoid frequent forced requests that drain the battery.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Installation and environment branches

Home Assistant OS or appliance-style installs

No events in Location History: focus on Android permission, sensors, battery management, and device location services.

Container, network, or account variation

Events exist but show skipped readings: inspect accuracy, age, duplicate suppression, and the reason recorded by the app.

Partial failure versus complete failure

Events are sent but server rejects or never receives them: focus on authentication, external connectivity, certificates, and server logs.

Multi-device or multi-hop environments

Entity changes but person does not: inspect the Person configuration and every tracker attached to that person; another tracker may still report home.

What not to do

• Do not delete the integration, device, database, app registration, or proxy configuration merely because it is the fastest visible button. Deletion can remove evidence and create new entity identities.
• Do not paste passwords, tokens, encryption keys, exact home coordinates, public URLs with credentials, or unredacted logs into a forum or support ticket.
• Do not disable firewalls, TLS verification, authentication, or other security controls as a permanent workaround. A useful test must be narrow, timed, and reversed.
• Do not make several network, software, and device changes together. Change one variable, observe the result, and keep the working rollback path.
• Do not assume a restart is a diagnosis. A restart can temporarily hide timing, memory, radio, storage, or connectivity faults without correcting them.

Verification checklist

Perform a controlled test that protects privacy: note the time, leave the Home zone by a safe margin, wait for a normal update, and check Location History. Confirm the device_tracker changes first, then the Person entity and finally the automation trace. Repeat on cellular data with the app closed and screen off. Return home and verify the reverse transition. One manual refresh while the app is open does not prove background tracking is fixed.

• The original symptom is gone under the same conditions that previously reproduced it.
• The relevant log has no new matching error after a normal update or restart cycle.
• Related entities, history, automations, or remote access still work.
• The repair survives one controlled restart of the affected component.
• Temporary troubleshooting exceptions have been removed or documented.

Rollback and recovery

Before clearing app data or deleting the mobile_app integration, record the device name, notification service name, enabled sensors, Person assignment, automations, widgets, and server connection settings. Re-registration can create new entity IDs and break notifications. Try permission, connectivity, and battery fixes first. If re-registration is necessary, repair each dependency deliberately and remove duplicates only after verification.

If the evidence points to failing hardware, a vendor outage, an upstream regression, or corrupted data that matters, stop improvising. Preserve the backup and diagnostic record, then escalate with the exact version, timestamp, error, minimal reproduction, and steps already tested. That produces a safer and faster answer than repeated resets.

Prevention

• Recheck background permissions after Android and vendor updates.
• Keep a secure external connection tested on cellular data.
• Use realistic non-overlapping zone radii.
• Review Location History when delays begin.
• Avoid aggressive battery-saving profiles for the Companion app.
• Document which tracker drives each Person entity.

Schedule a brief review after the next Home Assistant update or device firmware change. Confirm that the repaired path still works, remove obsolete workarounds, and update your private documentation. Prevention is most effective when it records why a setting exists, not just its value.

Diagnostic worksheet

For Home Assistant Android location or zone tracking that is not updating, write down five facts before asking for help: the exact error, the first failure time, the last working time, the smallest action that reproduces it, and the layer that still works. Add the Home Assistant Core version, installation type, relevant device or app firmware, network path, and whether the issue survives a restart. This worksheet separates a repeatable defect from a transient outage.

If you observe: The person or device_tracker entity remains home after the phone leaves

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: Zone enter or exit automations arrive late or not at all

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: Location updates work only while the app is open

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: Tracking works on home Wi-Fi but stops on cellular data

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: The app records a location but the entity in Home Assistant does not change

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

Frequently asked questions

Should I delete and add everything again?

Usually not. Re-adding can change entity IDs, erase evidence, and hide the original cause. Use it only after backup, documentation, and the narrower checks in this guide.

Can I ignore the error if it starts working again?

A single brief interruption may be harmless, but a recurring error deserves timestamps and logs. Repetition after the same event often reveals a network, storage, power, permission, or token lifecycle problem.

Is updating Home Assistant always the fix?

No. Updates can contain fixes, but they also change dependencies and behavior. Read release notes, back up first, and match the error to a known fix before treating an update as diagnosis.

How much log information should I share?

Share the smallest relevant window around the failure, with secrets and personal data removed. Include versions and the exact action that caused the event. Avoid uploading complete logs publicly.

When should I escalate?

Escalate when safety, important data, repeated corruption, an upstream regression, or an account-side failure is involved, or when the least-destructive checks produce a clear error you cannot resolve.

Sources and review notes

Photo: Henry Perks on Unsplash. Last reviewed: September 22, 2026. Official documentation is the authority for supported configuration. Community and issue reports are useful for identifying recurring symptoms but do not prove that every installation has the same cause.

• https://companion.home-assistant.io/docs/core/location/
• https://companion.home-assistant.io/docs/troubleshooting/faqs/
• https://companion.home-assistant.io/docs/getting_started/connection-security-level/

Continue with the Device Unavailable Diagnostic, the Smart-Home Diagnostic Decision Tree, or the Home Assistant Error Decoder when the symptom crosses more than one integration.

Direct answer: Do not keep restarting or copying a live SQLite file. First create a full Home Assistant backup and confirm at least 2.5 times the database size is available as free storage, then stop Home Assistant before touching the database. Home Assistant can move an unrecoverable SQLite database aside and create a new one, which restores operation but may leave history in the old file. Preserve every displaced database before attempting recovery. If long-term statistics matter, treat recovery as a data-preservation job rather than a quick delete-and-reboot fix.

This guide addresses a malformed or corrupt Home Assistant Recorder database. It is designed to preserve working configuration and evidence before any reset, deletion, or re-pairing. Work in order and stop when the first confirmed cause is corrected. Screens and menu labels can vary by Home Assistant release and installation method.

Symptoms and scope

Use the following signs to decide whether this guide matches your problem. Similar-looking failures can come from different layers, so record what still works as carefully as what fails.

• The log contains “database disk image is malformed,” “unrecoverable sqlite3 database corruption detected,” “database is locked,” or repeated Recorder write failures.
• History, Logbook, Energy, or statistics stop updating while automations and device control continue to work.
• A file with a name such as home-assistant_v2.db.corrupt appears and a fresh database starts growing.
• Startup or shutdown becomes unusually slow, purge or repack repeatedly fails, or the host runs low on storage.
• The problem returns after replacing the database, suggesting an underlying disk, power, memory, filesystem, or shutdown issue.

Most likely causes, ranked

Start with the causes that fit the evidence. Do not apply every fix at once: simultaneous changes make it impossible to know what solved the problem and can create a second failure.

• 1. An interrupted write caused by sudden power loss, forced VM termination, storage disconnect, or a host crash.
• 2. A failing SD card, SSD, USB bridge, filesystem, or hypervisor storage layer is returning incomplete or inconsistent writes.
• 3. The disk is full or nearly full, leaving too little room for SQLite journaling, purge, repack, backups, or host updates.
• 4. The live SQLite file was copied, opened, repaired, or manipulated while Home Assistant still had it open.
• 5. Very heavy state recording, noisy sensors, short-retention experimentation, or an oversized database increased I/O pressure; size alone does not prove corruption.
• 6. A network filesystem or unsupported storage arrangement introduced locking behavior that SQLite was not designed to tolerate.

Safe diagnostic procedure

Before beginning, make a current backup when the procedure could affect configuration or stored data. Record the Home Assistant version, installation type, device or app version, the first failure time, and the last known working change. Redact secrets from every screenshot and log excerpt.

Step 1: Capture the exact failure

Open Settings → System → Repairs and Settings → System → Logs. Save the exact Recorder and SQLite messages with timestamps. Redact tokens, passwords, public URLs, GPS coordinates, and device identifiers before sharing anything. Distinguish a one-time recovery notice from an error that repeats every few minutes.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 2: Protect the current state

Create a full Home Assistant backup before changing Recorder settings. Download or copy the backup to storage outside the same failing device. A backup that exists only on the questionable disk is not a complete safety net. Record the Core version, installation type, database engine, and approximate database size.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 3: Verify the affected layer

Check free space and host health. Home Assistant OS users can inspect System → Storage and hardware information; container and supervised users should also inspect the host filesystem and container volume. Leave meaningful headroom for the database, journal, backup, and updates. Remove only known expendable files through supported interfaces.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 4: Test the least-destructive cause

Stop Home Assistant cleanly before copying or inspecting SQLite. Do not use Samba, an editor, a database browser, or a repair command against the live file. If the installation cannot stop cleanly, preserve a backup and investigate storage and host logs before forcing power off.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 5: Inspect configuration and identity

Preserve the original database and any .corrupt copies with their timestamps. Never overwrite the only damaged copy with a repaired experiment. Work on a duplicate. If Home Assistant already created a fresh database, confirm that current history is writing before deciding whether old data needs recovery.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 6: Check network, power, or permissions

For the fastest safe service restoration, allow Home Assistant to use a new database. This sacrifices ordinary short-term history from the damaged file but should not require deleting configuration, devices, entities, or automations. Long-term statistics may require separate recovery and careful validation.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 7: Apply the narrow repair

If historical or energy data is important, use SQLite’s documented recovery process only on an offline duplicate and preferably with an experienced administrator. Validate recovered tables and statistics before any import. A file that opens is not automatically internally consistent.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 8: Observe through a full cycle

Reduce recurrence risk only after the service is stable. Exclude high-frequency entities from Recorder when their history provides no value, correct sensors that update excessively, maintain backups, and address storage or power faults. Moving to MariaDB can change operational characteristics but does not cure failing hardware or unsafe shutdowns.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Installation and environment branches

Home Assistant OS or appliance-style installs

Home Assistant OS: favor built-in backups, Repairs, storage information, and supported add-ons; avoid unsupported host-level file changes.

Container, network, or account variation

Container: verify the /config volume, filesystem ownership, available inodes, Docker shutdown behavior, and whether the database lives on reliable local storage.

Partial failure versus complete failure

Virtual machine: check the hypervisor for snapshots, thin-provisioned disk exhaustion, datastore latency, forced resets, and host power events.

Multi-device or multi-hop environments

External SQL database: a connection or credential failure is not the same as SQLite corruption. Inspect the database server, network path, permissions, capacity, and server logs before changing Recorder URLs.

What not to do

• Do not delete the integration, device, database, app registration, or proxy configuration merely because it is the fastest visible button. Deletion can remove evidence and create new entity identities.
• Do not paste passwords, tokens, encryption keys, exact home coordinates, public URLs with credentials, or unredacted logs into a forum or support ticket.
• Do not disable firewalls, TLS verification, authentication, or other security controls as a permanent workaround. A useful test must be narrow, timed, and reversed.
• Do not make several network, software, and device changes together. Change one variable, observe the result, and keep the working rollback path.
• Do not assume a restart is a diagnosis. A restart can temporarily hide timing, memory, radio, storage, or connectivity faults without correcting them.

Verification checklist

After recovery, restart once and watch Recorder logs for at least one normal write cycle. Open History and Logbook, change a harmless test entity, and confirm a new state appears with the correct time. Check Statistics in Developer Tools for repair notices and verify the Energy dashboard on the next statistics cycle. Recheck free storage and confirm no new .corrupt file appears. A clean dashboard alone is not proof; the log and fresh database writes must agree.

• The original symptom is gone under the same conditions that previously reproduced it.
• The relevant log has no new matching error after a normal update or restart cycle.
• Related entities, history, automations, or remote access still work.
• The repair survives one controlled restart of the affected component.
• Temporary troubleshooting exceptions have been removed or documented.

Rollback and recovery

If a recovery attempt makes matters worse, stop and return to the untouched copy or full backup. Restore into a test instance when possible, not directly over the only working production system. If statistics are business-critical, preserve both the old and new databases and seek database-specific help. Never merge rows by guesswork: entity and metadata identifiers can differ across databases.

If the evidence points to failing hardware, a vendor outage, an upstream regression, or corrupted data that matters, stop improvising. Preserve the backup and diagnostic record, then escalate with the exact version, timestamp, error, minimal reproduction, and steps already tested. That produces a safer and faster answer than repeated resets.

Prevention

• Use reliable storage and a UPS where outages are common.
• Keep tested backups outside the Home Assistant host.
• Shut down the host cleanly before power or storage work.
• Review Recorder exclusions for noisy, low-value entities.
• Watch storage capacity and database growth monthly.
• Investigate repeat corruption as a hardware or platform fault, not normal maintenance.

Schedule a brief review after the next Home Assistant update or device firmware change. Confirm that the repaired path still works, remove obsolete workarounds, and update your private documentation. Prevention is most effective when it records why a setting exists, not just its value.

Diagnostic worksheet

For a malformed or corrupt Home Assistant Recorder database, write down five facts before asking for help: the exact error, the first failure time, the last working time, the smallest action that reproduces it, and the layer that still works. Add the Home Assistant Core version, installation type, relevant device or app firmware, network path, and whether the issue survives a restart. This worksheet separates a repeatable defect from a transient outage.

If you observe: The log contains “database disk image is malformed,” “unrecoverable sqlite3 database corruption detected,” “database is locked,” or repeated Recorder write failures

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: History, Logbook, Energy, or statistics stop updating while automations and device control continue to work

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: A file with a name such as home-assistant_v2

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: Startup or shutdown becomes unusually slow, purge or repack repeatedly fails, or the host runs low on storage

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: The problem returns after replacing the database, suggesting an underlying disk, power, memory, filesystem, or shutdown issue

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

Frequently asked questions

Should I delete and add everything again?

Usually not. Re-adding can change entity IDs, erase evidence, and hide the original cause. Use it only after backup, documentation, and the narrower checks in this guide.

Can I ignore the error if it starts working again?

A single brief interruption may be harmless, but a recurring error deserves timestamps and logs. Repetition after the same event often reveals a network, storage, power, permission, or token lifecycle problem.

Is updating Home Assistant always the fix?

No. Updates can contain fixes, but they also change dependencies and behavior. Read release notes, back up first, and match the error to a known fix before treating an update as diagnosis.

How much log information should I share?

Share the smallest relevant window around the failure, with secrets and personal data removed. Include versions and the exact action that caused the event. Avoid uploading complete logs publicly.

When should I escalate?

Escalate when safety, important data, repeated corruption, an upstream regression, or an account-side failure is involved, or when the least-destructive checks produce a clear error you cannot resolve.

Sources and review notes

Photo: Taylor Vick on Unsplash. Last reviewed: September 24, 2026. Official documentation is the authority for supported configuration. Community and issue reports are useful for identifying recurring symptoms but do not prove that every installation has the same cause.

• https://www.home-assistant.io/integrations/recorder/
• https://www.home-assistant.io/common-tasks/general/#backups
• https://www.sqlite.org/recovery.html

Continue with the Device Unavailable Diagnostic, the Smart-Home Diagnostic Decision Tree, or the Home Assistant Error Decoder when the symptom crosses more than one integration.

Direct answer: If Node-RED reports that it cannot connect to Home Assistant, check the configured Home Assistant URL, long-lived access token or add-on authentication, WebSocket path, DNS, and TLS trust before reinstalling anything. Test whether the failure affects the Node-RED add-on, an external Node-RED server, or only one flow.

Safety first: Preserve a current Home Assistant backup and record entity IDs, device names, IP addresses, integration settings, and the exact error before changing anything. Never expose tokens, passwords, encryption keys, webhook URLs, or unredacted diagnostics. Do not factory-reset equipment, delete an integration, or open mains-powered hardware as a first troubleshooting step.

Confirm the failure boundary

Open the Home Assistant server configuration node in Node-RED and identify whether it is disconnected globally, repeatedly reconnecting, authenticated but missing entities, or failing only when a flow calls a service. Connection failures and flow-logic failures require different fixes.

Determine whether the problem affects one device, one integration, or every device using the same network path. A single-device failure usually points to power, addressing, credentials, firmware, or device-specific settings. Several failures beginning together point toward Home Assistant, DNS, routing, firewall policy, an upstream service, or a recent update.

Quick diagnostic table

Step 1: preserve evidence

Write down when the failure began, the last known working version, recent updates, router or VLAN changes, and the full error text. Open Settings → System → Logs and the integration entry under Settings → Devices & services. Download diagnostics when available. Evidence collected before a restart is often more valuable than evidence collected afterward.

Step 2: verify the basic path

Determine where Node-RED runs. The supervised add-on may use internal connectivity and add-on authentication, while an external container or computer must resolve and reach the configured Home Assistant URL. Test from the Node-RED host or container, not only from your phone.

Use the least invasive test that separates network reachability from application authentication. A successful ping proves only that an address responds; it does not prove that the required port, protocol, credentials, certificate, or API is working. Likewise, a vendor app working through the cloud does not prove that local communication from Home Assistant is allowed.

Step 3: check configuration and credentials

For an external installation, verify the base URL and a valid long-lived access token belonging to an appropriately limited user. For the official add-on, verify the documented add-on authentication settings. Never paste a token into screenshots or public flow exports.

Prefer the integration’s Reconfigure or Reauthenticate flow over deleting it. Deletion can remove entity-registry relationships and break dashboards or automations. If credentials changed, update only the affected entry and verify one harmless entity before touching anything else.

Step 4: inspect networking without weakening security

Reverse proxies must pass WebSocket upgrades and present a certificate trusted by Node-RED. Split DNS can cause an internal client to resolve a public address that hairpin routing cannot reach. Prefer a valid internal route and trusted TLS rather than disabling certificate verification.

If Home Assistant and the device are on different VLANs, test temporarily on the same trusted network. If that works, restore the intended layout and create the narrowest required rule. Do not expose local APIs to the public internet, disable the firewall globally, or create an unrestricted route from an untrusted IoT network to the main LAN.

Step 5: read logs and reproduce once

Compare Node-RED logs with Home Assistant authentication and HTTP logs. Unauthorized errors indicate credentials; name-resolution errors indicate DNS; certificate errors indicate trust or hostname mismatch; repeated WebSocket closes point toward proxy, timeout, or network behavior.

Enable debug logging only long enough to reproduce the failure once. Then disable it and download the log. Look for the first meaningful error, not every secondary warning that follows. Match timestamps between Home Assistant, the add-on or bridge, the router, and the vendor service when applicable.

Step 6: make one reversible change

Correct the server node’s URL or authentication, deploy once, and watch the connection state. If a reverse proxy is involved, repair WebSocket forwarding and certificate trust. Do not regenerate multiple tokens without revoking and documenting obsolete ones.

After each change, wait through several normal update intervals. Changing DNS, credentials, firmware, firewall rules, and device configuration at the same time may produce a temporary success without revealing the cause. Record the old value and the test result so you can roll back cleanly.

How to verify the repair

• The Home Assistant server node remains connected.
• Entity autocomplete and state events refresh normally.
• One harmless flow receives an event and calls a low-risk service.
• The connection returns automatically after a controlled Node-RED restart.

A repair is not verified by a green icon alone. Confirm fresh state updates, send one low-risk command, verify the physical response, and make sure the returned state matches. Watch long enough to cover normal polling, sleep, or reconnect behavior.

Rollback and escalation

Before editing, export the affected flow and record server-node settings without secrets. If a new URL or proxy rule fails, restore the prior value. Revoke tokens that were exposed or created only for testing.

If escalation is necessary, provide the exact model, firmware, Home Assistant version, integration version, network layout, redacted diagnostics, timestamps, and the checks already completed. A concise evidence package gets better help than a broad statement that the integration is broken.

Prevent recurrence

• Use a dedicated Home Assistant user and token for external Node-RED.
• Document internal DNS and reverse-proxy WebSocket settings.
• Back up flows before node or add-on updates.
• Monitor repeated reconnects before they become a total outage.

Related Troubliq guides

• Smart-Home Diagnostic Decision Tree
• Why Is My Smart-Home Device Unavailable?
• Browse all troubleshooting guides

Sources and review record

• Home Assistant: Node-RED add-on repository
• Home Assistant: REST API authentication
• Node-RED documentation

Last reviewed: September 21, 2026. Testing disclosure: This guide follows current official documentation and established diagnostic practice; exact menus can vary by release, installation type, and device firmware.

Advanced isolation checklist

When the basic checks do not identify the cause, build a controlled comparison. Test one known-good device, account, or client through the same path, and test the affected device through a simpler path when safe. Compare timestamps, addresses, authentication method, firmware, and permissions. The purpose is to change one boundary at a time, not to keep trying random fixes.

Review release notes for Home Assistant, the integration, add-on, device firmware, and any reverse proxy or network service updated near the failure. Confirm a reported workaround applies to the same product and version before using it. Prefer an official repair or documented reconfiguration over unsupported downgrades.

What not to do

• Do not factory-reset multiple devices together.
• Do not delete a working integration merely to clear a warning.
• Do not expose local services or dashboards directly to the internet.
• Do not post secrets or unredacted diagnostic files.
• Do not assume a successful mobile-app test proves the Home Assistant path works.

Detailed evidence checklist for Node-RED cannot connect to Home Assistant

Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.

Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.

Network tests that prove the failing layer

Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.

For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.

Configuration comparison procedure

Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.

Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.

Power, radio, and timing checks

Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.

Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.

Log-reading workflow

Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.

Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.

Safe change order

1. Correct time, power, cabling, or an obviously stale address.
2. Reload only the affected integration when documentation supports it.
3. Use Reconfigure or Reauthenticate without deleting the entry.
4. Restart only the affected device or add-on during a safe window.
5. Restart Home Assistant when several components share the symptom or a change requires it.
6. Update software after reading release notes and preserving rollback.
7. Delete, exclude, reset, or rebuild only after safer checks prove it necessary.

Post-repair validation

Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.

Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.

When to stop and escalate

Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.

A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.

Direct answer: When an ESPHome Bluetooth proxy becomes unavailable, confirm the proxy itself is online through the ESPHome native API before troubleshooting Bluetooth devices. Then inspect Wi-Fi stability, API encryption, proxy mode, coverage, and connection-slot limits. A working proxy and a discoverable Bluetooth device are two different checkpoints.

Safety first: Preserve a current Home Assistant backup and record entity IDs, device names, IP addresses, integration settings, and the exact error before changing anything. Never expose tokens, passwords, encryption keys, webhook URLs, or unredacted diagnostics. Do not factory-reset equipment, delete an integration, or open mains-powered hardware as a first troubleshooting step.

Confirm the failure boundary

Separate proxy availability in Home Assistant from Bluetooth discovery and from active connections. If the proxy device is unavailable, fix its ESPHome API path first. If the proxy is online but a sensor is missing, investigate advertisements, distance, interference, and integration support.

Determine whether the problem affects one device, one integration, or every device using the same network path. A single-device failure usually points to power, addressing, credentials, firmware, or device-specific settings. Several failures beginning together point toward Home Assistant, DNS, routing, firewall policy, an upstream service, or a recent update.

Quick diagnostic table

Step 1: preserve evidence

Write down when the failure began, the last known working version, recent updates, router or VLAN changes, and the full error text. Open Settings → System → Logs and the integration entry under Settings → Devices & services. Download diagnostics when available. Evidence collected before a restart is often more valuable than evidence collected afterward.

Step 2: verify the basic path

Check the proxy in ESPHome Device Builder, its DHCP lease, signal level, uptime, and logs. Confirm Home Assistant can reach the native API address and that the encryption key matches. Unstable power can create repeated short connections that resemble weak Bluetooth coverage.

Use the least invasive test that separates network reachability from application authentication. A successful ping proves only that an address responds; it does not prove that the required port, protocol, credentials, certificate, or API is working. Likewise, a vendor app working through the cloud does not prove that local communication from Home Assistant is allowed.

Step 3: check configuration and credentials

Confirm the ESPHome configuration includes the current Bluetooth proxy component and native API. Passive observation and active connections have different requirements. Validate the configuration with the current ESPHome release before compiling, and preserve the working YAML and encryption key.

Prefer the integration’s Reconfigure or Reauthenticate flow over deleting it. Deletion can remove entity-registry relationships and break dashboards or automations. If credentials changed, update only the affected entry and verify one harmless entity before touching anything else.

Step 4: inspect networking without weakening security

The proxy transports Bluetooth data to Home Assistant over IP. Wi-Fi client isolation, VLAN rules, DNS, mDNS, or a changed DHCP address can break that transport. Fix the precise Home Assistant-to-proxy path; do not expose port 6053 publicly.

If Home Assistant and the device are on different VLANs, test temporarily on the same trusted network. If that works, restore the intended layout and create the narrowest required rule. Do not expose local APIs to the public internet, disable the firewall globally, or create an unrestricted route from an untrusted IoT network to the main LAN.

Step 5: read logs and reproduce once

Correlate ESPHome boot messages, Wi-Fi reconnects, API client connections, Bluetooth scan messages, and memory or watchdog warnings. Repeated boots point toward power or firmware. A stable API connection with no advertisements points toward RF range, device advertising, or hardware.

Enable debug logging only long enough to reproduce the failure once. Then disable it and download the log. Look for the first meaningful error, not every secondary warning that follows. Match timestamps between Home Assistant, the add-on or bridge, the router, and the vendor service when applicable.

Step 6: make one reversible change

Reconfigure the correct address or encryption key, stabilize power, or perform a short same-room range test. Add another proxy only after proving coverage is the problem. Update firmware one proxy at a time so a bad build does not remove all Bluetooth coverage.

After each change, wait through several normal update intervals. Changing DNS, credentials, firmware, firewall rules, and device configuration at the same time may produce a temporary success without revealing the cause. Record the old value and the test result so you can roll back cleanly.

How to verify the repair

• The proxy remains available through several Wi-Fi and API intervals.
• Expected advertisements appear with stable signal strength.
• A supported active-connection device accepts one harmless command.
• Home Assistant reconnects to the proxy after a controlled restart.

A repair is not verified by a green icon alone. Confirm fresh state updates, send one low-risk command, verify the physical response, and make sure the returned state matches. Watch long enough to cover normal polling, sleep, or reconnect behavior.

Rollback and escalation

Keep the previous ESPHome YAML and firmware available. If a new build causes instability, restore the known-good configuration using a supported local or USB recovery method rather than repeatedly attempting over-the-air updates.

If escalation is necessary, provide the exact model, firmware, Home Assistant version, integration version, network layout, redacted diagnostics, timestamps, and the checks already completed. A concise evidence package gets better help than a broad statement that the integration is broken.

Prevent recurrence

• Use reliable power supplies and cables for proxies.
• Create DHCP reservations or dependable local name resolution.
• Place multiple proxies with overlapping—but not excessive—coverage.
• Update and test one proxy before rolling changes to the rest.

Related Troubliq guides

• Smart-Home Diagnostic Decision Tree
• Why Is My Smart-Home Device Unavailable?
• Browse all troubleshooting guides

Sources and review record

• Home Assistant: Bluetooth integration
• ESPHome: Bluetooth Proxy
• ESPHome: Native API

Last reviewed: September 21, 2026. Testing disclosure: This guide follows current official documentation and established diagnostic practice; exact menus can vary by release, installation type, and device firmware.

Advanced isolation checklist

When the basic checks do not identify the cause, build a controlled comparison. Test one known-good device, account, or client through the same path, and test the affected device through a simpler path when safe. Compare timestamps, addresses, authentication method, firmware, and permissions. The purpose is to change one boundary at a time, not to keep trying random fixes.

Review release notes for Home Assistant, the integration, add-on, device firmware, and any reverse proxy or network service updated near the failure. Confirm a reported workaround applies to the same product and version before using it. Prefer an official repair or documented reconfiguration over unsupported downgrades.

What not to do

• Do not factory-reset multiple devices together.
• Do not delete a working integration merely to clear a warning.
• Do not expose local services or dashboards directly to the internet.
• Do not post secrets or unredacted diagnostic files.
• Do not assume a successful mobile-app test proves the Home Assistant path works.

Detailed evidence checklist for Home Assistant Bluetooth proxy unavailable

Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.

Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.

Network tests that prove the failing layer

Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.

For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.

Configuration comparison procedure

Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.

Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.

Power, radio, and timing checks

Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.

Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.

Log-reading workflow

Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.

Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.

Safe change order

1. Correct time, power, cabling, or an obviously stale address.
2. Reload only the affected integration when documentation supports it.
3. Use Reconfigure or Reauthenticate without deleting the entry.
4. Restart only the affected device or add-on during a safe window.
5. Restart Home Assistant when several components share the symptom or a change requires it.
6. Update software after reading release notes and preserving rollback.
7. Delete, exclude, reset, or rebuild only after safer checks prove it necessary.

Post-repair validation

Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.

Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.

When to stop and escalate

Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.

A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.

Direct answer: If Tuya or Smart Life devices are unavailable in Home Assistant, verify they still work in the correct vendor account, reauthenticate the existing Tuya integration, and check account region and device sharing before resetting hardware. A cloud-account mismatch can make every device disappear even though Wi-Fi is healthy.

Safety first: Preserve a current Home Assistant backup and record entity IDs, device names, IP addresses, integration settings, and the exact error before changing anything. Never expose tokens, passwords, encryption keys, webhook URLs, or unredacted diagnostics. Do not factory-reset equipment, delete an integration, or open mains-powered hardware as a first troubleshooting step.

Confirm the failure boundary

Determine whether the integration cannot load, every device vanished, only newly added devices are missing, or a device exists but exposes fewer entities than expected. Account linkage, region, product support, and entity capability are separate issues.

Determine whether the problem affects one device, one integration, or every device using the same network path. A single-device failure usually points to power, addressing, credentials, firmware, or device-specific settings. Several failures beginning together point toward Home Assistant, DNS, routing, firewall policy, an upstream service, or a recent update.

Quick diagnostic table

Step 1: preserve evidence

Write down when the failure began, the last known working version, recent updates, router or VLAN changes, and the full error text. Open Settings → System → Logs and the integration entry under Settings → Devices & services. Download diagnostics when available. Evidence collected before a restart is often more valuable than evidence collected afterward.

Step 2: verify the basic path

Confirm the devices work in the Tuya Smart or Smart Life app while signed into the account linked to Home Assistant. Note the app name, account country or region, and selected home. A device shared from another account may behave differently from one owned by the linked account.

Use the least invasive test that separates network reachability from application authentication. A successful ping proves only that an address responds; it does not prove that the required port, protocol, credentials, certificate, or API is working. Likewise, a vendor app working through the cloud does not prove that local communication from Home Assistant is allowed.

Step 3: check configuration and credentials

Start the official integration’s reauthentication flow and use the exact linked account. Scan or confirm authorization only through the official app and Home Assistant interface. If the account region changed, document it before relinking because region selection affects which cloud endpoint sees the devices.

Prefer the integration’s Reconfigure or Reauthenticate flow over deleting it. Deletion can remove entity-registry relationships and break dashboards or automations. If credentials changed, update only the affected entry and verify one harmless entity before touching anything else.

Step 4: inspect networking without weakening security

The official Tuya integration depends on Tuya cloud access. Verify outbound HTTPS, DNS, system time, and the absence of filtering that blocks Tuya endpoints. Local ping tests do not validate cloud authorization, and port-forwarding will not repair the integration.

If Home Assistant and the device are on different VLANs, test temporarily on the same trusted network. If that works, restore the intended layout and create the narrowest required rule. Do not expose local APIs to the public internet, disable the firewall globally, or create an unrestricted route from an untrusted IoT network to the main LAN.

Step 5: read logs and reproduce once

Distinguish authorization failures, rate limits, device-not-found responses, and unsupported data points. Do not repeatedly reload the integration during a cloud outage; repeated authentication attempts can complicate diagnosis or trigger temporary limits.

Enable debug logging only long enough to reproduce the failure once. Then disable it and download the log. Look for the first meaningful error, not every secondary warning that follows. Match timestamps between Home Assistant, the add-on or bridge, the router, and the vendor service when applicable.

Step 6: make one reversible change

Reauthenticate once, then reload the entry and allow a full refresh. If only new devices are absent, confirm they are assigned to the same app home and account before removing anything. Avoid switching between Tuya Smart and Smart Life accounts during the same test.

After each change, wait through several normal update intervals. Changing DNS, credentials, firmware, firewall rules, and device configuration at the same time may produce a temporary success without revealing the cause. Record the old value and the test result so you can roll back cleanly.

How to verify the repair

• The integration loads without an authentication repair notice.
• Owned and intentionally shared devices appear in the expected home.
• Entity states change after a normal cloud refresh.
• One low-risk command works and its new state returns to Home Assistant.

A repair is not verified by a green icon alone. Confirm fresh state updates, send one low-risk command, verify the physical response, and make sure the returned state matches. Watch long enough to cover normal polling, sleep, or reconnect behavior.

Rollback and escalation

If relinking creates duplicates, disable the newer entry and preserve the original entity IDs until you can compare both. Restore the prior account or region selection rather than resetting every device.

If escalation is necessary, provide the exact model, firmware, Home Assistant version, integration version, network layout, redacted diagnostics, timestamps, and the checks already completed. A concise evidence package gets better help than a broad statement that the integration is broken.

Prevent recurrence

• Document which Tuya app, account, region, and home Home Assistant uses.
• Keep account recovery methods current.
• Avoid moving devices between homes without recording entity dependencies.
• Check cloud status before making local network changes.

Related Troubliq guides

• Smart-Home Diagnostic Decision Tree
• Why Is My Smart-Home Device Unavailable?
• Browse all troubleshooting guides

Sources and review record

• Home Assistant: Tuya integration
• Home Assistant: integration troubleshooting

Last reviewed: September 21, 2026. Testing disclosure: This guide follows current official documentation and established diagnostic practice; exact menus can vary by release, installation type, and device firmware.

Advanced isolation checklist

When the basic checks do not identify the cause, build a controlled comparison. Test one known-good device, account, or client through the same path, and test the affected device through a simpler path when safe. Compare timestamps, addresses, authentication method, firmware, and permissions. The purpose is to change one boundary at a time, not to keep trying random fixes.

Review release notes for Home Assistant, the integration, add-on, device firmware, and any reverse proxy or network service updated near the failure. Confirm a reported workaround applies to the same product and version before using it. Prefer an official repair or documented reconfiguration over unsupported downgrades.

What not to do

• Do not factory-reset multiple devices together.
• Do not delete a working integration merely to clear a warning.
• Do not expose local services or dashboards directly to the internet.
• Do not post secrets or unredacted diagnostic files.
• Do not assume a successful mobile-app test proves the Home Assistant path works.

Detailed evidence checklist for Tuya devices unavailable in Home Assistant

Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.

Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.

Network tests that prove the failing layer

Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.

For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.

Configuration comparison procedure

Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.

Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.

Power, radio, and timing checks

Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.

Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.

Log-reading workflow

Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.

Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.

Safe change order

1. Correct time, power, cabling, or an obviously stale address.
2. Reload only the affected integration when documentation supports it.
3. Use Reconfigure or Reauthenticate without deleting the entry.
4. Restart only the affected device or add-on during a safe window.
5. Restart Home Assistant when several components share the symptom or a change requires it.
6. Update software after reading release notes and preserving rollback.
7. Delete, exclude, reset, or rebuild only after safer checks prove it necessary.

Post-repair validation

Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.

Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.

When to stop and escalate

Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.

A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.

Direct answer: When Google Nest devices become unavailable in Home Assistant, first separate an expired Google authorization from a Device Access project, Pub/Sub, network, or camera-event problem. Reauthorize the existing integration, confirm the Google project and Device Access subscription are still active, and verify event delivery before recreating anything.

Safety first: Preserve a current Home Assistant backup and record entity IDs, device names, IP addresses, integration settings, and the exact error before changing anything. Never expose tokens, passwords, encryption keys, webhook URLs, or unredacted diagnostics. Do not factory-reset equipment, delete an integration, or open mains-powered hardware as a first troubleshooting step.

Confirm the failure boundary

Open the Google Nest integration and identify whether the whole integration failed to load, only one structure or device is missing, live video alone fails, or state works but events do not. These symptoms use different paths and should not be treated as one generic outage.

Determine whether the problem affects one device, one integration, or every device using the same network path. A single-device failure usually points to power, addressing, credentials, firmware, or device-specific settings. Several failures beginning together point toward Home Assistant, DNS, routing, firewall policy, an upstream service, or a recent update.

Quick diagnostic table

Step 1: preserve evidence

Write down when the failure began, the last known working version, recent updates, router or VLAN changes, and the full error text. Open Settings → System → Logs and the integration entry under Settings → Devices & services. Download diagnostics when available. Evidence collected before a restart is often more valuable than evidence collected afterward.

Step 2: verify the basic path

Confirm Home Assistant has working outbound HTTPS and correct system time. Verify the Nest device works in Google Home and belongs to the same Google account and home that were authorized. If Google Home also fails, resolve the device or Google service problem first.

Use the least invasive test that separates network reachability from application authentication. A successful ping proves only that an address responds; it does not prove that the required port, protocol, credentials, certificate, or API is working. Likewise, a vendor app working through the cloud does not prove that local communication from Home Assistant is allowed.

Step 3: check configuration and credentials

Use Reconfigure or Reauthenticate. Confirm the OAuth client, Device Access project, project ID, redirect URI, and account match the original setup. Consent-screen or credential changes can invalidate access. Do not create multiple replacement projects until the existing configuration has been examined.

Prefer the integration’s Reconfigure or Reauthenticate flow over deleting it. Deletion can remove entity-registry relationships and break dashboards or automations. If credentials changed, update only the affected entry and verify one harmless entity before touching anything else.

Step 4: inspect networking without weakening security

Nest uses cloud APIs and event delivery, so outbound DNS, HTTPS, and accurate time matter. Local discovery rules will not repair an OAuth or Pub/Sub failure. Check filtered DNS, proxy inspection, and outbound firewall changes without opening inbound router ports.

If Home Assistant and the device are on different VLANs, test temporarily on the same trusted network. If that works, restore the intended layout and create the narrowest required rule. Do not expose local APIs to the public internet, disable the firewall globally, or create an unrestricted route from an untrusted IoT network to the main LAN.

Step 5: read logs and reproduce once

Look for invalid_grant, access_denied, project or subscription errors, event timeouts, and unsupported device traits. An OAuth error requires account attention; a Pub/Sub error requires event-delivery attention; a missing trait may simply mean the device does not expose that feature.

Enable debug logging only long enough to reproduce the failure once. Then disable it and download the log. Look for the first meaningful error, not every secondary warning that follows. Match timestamps between Home Assistant, the add-on or bridge, the router, and the vendor service when applicable.

Step 6: make one reversible change

Reauthorize the existing entry first. If state works but events fail, repair the documented Pub/Sub subscription and permissions. Change one project setting at a time and allow event delivery to resume before judging the result.

After each change, wait through several normal update intervals. Changing DNS, credentials, firmware, firewall rules, and device configuration at the same time may produce a temporary success without revealing the cause. Record the old value and the test result so you can roll back cleanly.

How to verify the repair

• All expected structures and devices appear once, without duplicates.
• A fresh temperature, mode, or camera state reaches Home Assistant.
• A supported event arrives and creates a new logbook entry.
• The integration reloads after a Home Assistant restart without requesting authentication again.

A repair is not verified by a green icon alone. Confirm fresh state updates, send one low-risk command, verify the physical response, and make sure the returned state matches. Watch long enough to cover normal polling, sleep, or reconnect behavior.

Rollback and escalation

If a project edit worsens the problem, restore the recorded identifier, redirect URI, permission, or subscription setting. Do not delete the Device Access project while it may still own the authorization used by Home Assistant.

If escalation is necessary, provide the exact model, firmware, Home Assistant version, integration version, network layout, redacted diagnostics, timestamps, and the checks already completed. A concise evidence package gets better help than a broad statement that the integration is broken.

Prevent recurrence

• Keep a secure record of the Google project and Device Access project IDs.
• Review Google account-security changes before they expire active authorizations.
• Use a dedicated, documented cloud project for Home Assistant.
• Test events after major Home Assistant or Google account changes.

Related Troubliq guides

• Smart-Home Diagnostic Decision Tree
• Why Is My Smart-Home Device Unavailable?
• Browse all troubleshooting guides

Sources and review record

• Home Assistant: Google Nest integration
• Google Device Access documentation

Last reviewed: September 21, 2026. Testing disclosure: This guide follows current official documentation and established diagnostic practice; exact menus can vary by release, installation type, and device firmware.

Advanced isolation checklist

When the basic checks do not identify the cause, build a controlled comparison. Test one known-good device, account, or client through the same path, and test the affected device through a simpler path when safe. Compare timestamps, addresses, authentication method, firmware, and permissions. The purpose is to change one boundary at a time, not to keep trying random fixes.

Review release notes for Home Assistant, the integration, add-on, device firmware, and any reverse proxy or network service updated near the failure. Confirm a reported workaround applies to the same product and version before using it. Prefer an official repair or documented reconfiguration over unsupported downgrades.

What not to do

• Do not factory-reset multiple devices together.
• Do not delete a working integration merely to clear a warning.
• Do not expose local services or dashboards directly to the internet.
• Do not post secrets or unredacted diagnostic files.
• Do not assume a successful mobile-app test proves the Home Assistant path works.

Detailed evidence checklist for Google Nest unavailable in Home Assistant

Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.

Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.

Network tests that prove the failing layer

Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.

For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.

Configuration comparison procedure

Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.

Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.

Power, radio, and timing checks

Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.

Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.

Log-reading workflow

Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.

Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.

Safe change order

1. Correct time, power, cabling, or an obviously stale address.
2. Reload only the affected integration when documentation supports it.
3. Use Reconfigure or Reauthenticate without deleting the entry.
4. Restart only the affected device or add-on during a safe window.
5. Restart Home Assistant when several components share the symptom or a change requires it.
6. Update software after reading release notes and preserving rollback.
7. Delete, exclude, reset, or rebuild only after safer checks prove it necessary.

Post-repair validation

Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.

Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.

When to stop and escalate

Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.

A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.