Category: General Troubleshooting

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.