Smart-Home Diagnostic Decision Tree

Start with the failure boundary

This decision tree helps identify which layer is failing before you reset devices or rebuild integrations. Choose one affected device and one expected behavior. Record what changed, the exact error, relevant versions, and what still works. Change only one thing at a time.

Decision 1: Is there a safety risk?

If there is smoke, heat, arcing, damaged mains wiring, water near electricity, gas, battery swelling, an insecure lock, or a failed life-safety device, stop. Disconnect power only when it is safe to do so and contact the appropriate qualified professional, manufacturer, utility, or emergency service.

Decision 2: One device or the whole system?

Observed scope	Most useful next check	Avoid first
One device	Power, battery, native app, signal, device log	Restarting the entire home
One protocol	Coordinator, bridge, border router, broker, interference	Resetting every endpoint
One integration	Integration card, authentication, coordinator update, logs	Deleting the integration immediately
One automation	Trace, trigger, conditions, action, entity availability	Re-pairing hardware
Whole system	Host power, storage, network, DNS, time, Core and Supervisor	Changing unrelated device settings

Decision 3: Does the device work in its native interface?

If the manufacturer’s local interface or app cannot control the device, investigate device power, connectivity, account or service status, and firmware before changing Home Assistant. If native control works, the failure is more likely in discovery, network reachability, authentication, the integration, entity mapping, or an automation.

Decision 4: Is the device locally reachable?

Check the device or bridge’s current address, Wi-Fi association, Ethernet link, VLAN, firewall path, DNS, multicast discovery, and time. Do not assume a device is healthy merely because it appears in a router’s client list. Test the protocol Home Assistant actually uses.

For Zigbee or Z-Wave, local reachability means radio-network membership and routing rather than an IP response. For Matter over Thread, check the Matter fabric, Thread credentials, border router, IPv6, and multicast path separately.

Decision 5: Is the integration healthy?

Open Settings, Devices & services. Look for setup failures, reauthentication requests, repairs, or unavailable configuration entries. Save diagnostics and relevant logs before reloading. Reload one integration once as a controlled test. If it recovers and fails again, preserve the timing rather than creating a blind reload loop.

Decision 6: Integration works, but is the entity current?

Compare the entity’s last update, availability, attributes, unit, and device association. A working integration can contain one stale or disabled entity. Check whether the entity ID changed, whether the device now has multiple representations, and whether an expiry or availability rule is operating as designed.

Decision 7: Entity works, but does the automation fail?

Open the automation trace. Verify the trigger occurred, conditions passed, templates rendered, the selected branch ran, and the action targeted the intended entity. Check automation mode, concurrency, delays, time zones, and unavailable dependencies. Test a non-critical action manually before changing the trigger.

Recovery ladder

Observe and save evidence.
Verify power, battery, cables, service status, and reachability.
Test the native interface.
Reload only the affected integration or service once.
Correct one reversible setting and retest.
Restart the smallest affected component.
Back up before removing, re-pairing, updating firmware, or restoring.
Reset only when ownership or network state requires it and recovery information is available.

Verification matrix

Change	Proof it worked	Observation period
Network correction	Stable protocol connection and fresh entity updates	Longer than the previous failure interval
Integration reload	No recurring coordinator or authentication error	At least one normal update cycle
Automation correction	Trace shows intended trigger, conditions, and action	Several safe test events
Radio recovery	Interview completes and routes remain stable	Include sleeping-device wake cycles
Restore	Integrations, radios, dashboards, users, and automations verified	Before declaring the old system replaceable

What to record for escalation

Provide device model, platform, connection type, Home Assistant version and installation type, integration version, exact redacted error, first failure time, relevant logs, what still works, what changed, and the results of controlled tests. Never share passwords, tokens, private certificates, pairing codes, backup keys, precise addresses, or unreviewed diagnostic archives.

Choose the relevant Troubliq path

Last reviewed: September 8, 2026.