ha-debuglisted

Work systematically and evidence-first. Do NOT propose a fix before you have logs + state in hand. Order every investigation: **evidence → inspect → reproduce → hypothesis → fix → verify.** Set a shorthand for the Supervisor-proxied Core API (the token is always present): ```bash API=http://supervisor/core/api AUTH="Authorization: Bearer $SUPERVISOR_TOKEN" ``` ## 1. Pull recent errors first ```bash curl -sS -H "$AUTH" "$API/error_log" | tail -n 80 ``` Grep it for the entity, domain, or integration in question: ```bash curl -sS -H "$AUTH" "$API/error_log" | grep -iE 'error|warning|traceback|<domain>' ``` Then read the log at the correct layer: ```bash ha core logs # HA Core: integrations, automations, templates ha addons logs <slug> # a specific add-on (use `ha addons` to list slugs) ``` ## 2. Inspect the entity — state + attributes ```bash curl -sS -H "$AUTH" "$API/states/<entity_id>" | jq . ``` Read the signals: - `state` = `unavailable` → the integration/device isn't providing it (offline, auth failure, network, IP change). - `state` = `unknown` → set up but no value yet. - attribute `restored: true` → HA restored it from its DB; the integration did NOT re-create it this boot, i.e. it failed to load (go to steps 1 and 4). - Missing/wrong attributes → bad platform config or a template error (check the log). ## 3. Check for staleness ```bash curl -sS -H "$AUTH" "$API/states/<entity_id>" | jq '{state, last_changed, last_updated}' ``` Compare `last_up