Troubliq

Smart-home fixes, step by step.

Category: Sensors & Thermostats

Troubleshooting for sensors and thermostats, including stale values, missing energy entities, calibration, availability, batteries, reporting intervals, statistics, units, and climate-control problems. Protect HVAC and freeze-safety settings, and verify a safe fallback before changing heating or cooling controls. Start with Energy dashboard sensor missing.

  • Ecobee integration unavailable in Home Assistant after 2026.3: authentication recovery

    Ecobee integration unavailable in Home Assistant after 2026.3: authentication recovery

    Direct answer: For Home Assistant 2026.3 and later, new Ecobee setup no longer requires obtaining a developer API key. Existing keys can continue working, but official documentation warns that revoking an existing key breaks that integration and requires removing the service from Home Assistant and setting it up again. Diagnose authentication before changing thermostat wiring, schedules, or HVAC settings.

    Last reviewed: September 12, 2026. Applies to current Home Assistant installations using the official integration named below; menus can vary slightly by release and installation type.

    Symptoms and scope

    The Ecobee device may appear unavailable, stop updating temperature and occupancy, reject setpoint changes, or request reauthentication after an upgrade or account change. If the physical thermostat still controls heating and cooling normally, treat this first as an integration or cloud-authentication problem, not an HVAC hardware failure.

    Prerequisites and evidence to preserve

    Confirm the Home Assistant version is 2026.3 or later, the thermostat works locally, and the Ecobee account can see the device. Record entity IDs, dashboards, automations, helpers, and any legacy API-key history before removal. Do not expose tokens, cookies, passwords, or developer keys in logs or support posts.

    Likely causes

    1. A legacy Ecobee developer key was revoked or its authorization changed.

    2. The Ecobee account session requires reauthentication.

    3. The integration is temporarily unable to reach the cloud service.

    4. An entity ID or device mapping changed after re-setup.

    5. The thermostat itself is offline, which is distinct from a Home Assistant-only integration failure.

    Least-destructive diagnostic sequence

    Step 1: Check the physical thermostat first. Confirm it has power, shows the expected equipment state, and can safely control the system. If the thermostat itself is blank or reports an HVAC fault, stop software troubleshooting and follow Ecobee or qualified HVAC guidance.

    Step 2: Open the Ecobee integration entry and record its exact status and repair message. A reauthentication prompt is more specific than a generic unavailable entity and should be handled through the provided flow. With username-and-password setup, Home Assistant supports authenticator-app TOTP codes; push, SMS, and email MFA are not currently supported. A password change can invalidate the refresh token and trigger reauthentication.

    Step 3: Review Home Assistant logs around the first failure for authentication, authorization, rate-limit, timeout, or connection messages. Redact account identifiers and secrets before sharing anything.

    Step 4: If you knowingly revoked the old developer key, plan a controlled remove-and-add operation because the official documentation says the existing integration will fail. First inventory every automation and dashboard reference so they can be checked after setup.

    Step 5: Before removal, export or capture important Home Assistant configuration references. Removing an integration should not erase thermostat schedules stored by Ecobee, but Home Assistant entity identifiers may be recreated differently.

    Step 6: Use the current Ecobee add-integration flow rather than following old tutorials that require creating a developer key. Complete account authorization only in the legitimate account window.

    Step 7: After setup, compare the new entity IDs with the saved inventory. Repair references deliberately instead of renaming multiple entities blindly. Test read-only sensor updates before sending setpoint or mode changes.

    Step 8: Observe at least two normal polling cycles, then make a small safe temperature adjustment and reverse it. Confirm both Home Assistant and the thermostat show the same state.

    Diagnostic asset: choose the next branch

    Version decision: before 2026.3, older setup instructions may discuss developer keys; on 2026.3 and later, use the current account-linking flow. Existing legacy keys may continue, but a revoked key cannot be repaired by repeatedly reloading; inventory references, remove the failed service, and add it again.

    Deeper checks when the first sequence does not solve it

    Begin with observation rather than removal. In Settings, Devices & services, open the integration entry and compare the integration status with individual entity states. Write down exactly what is unavailable, what remains responsive, and when the change began. This boundary prevents a narrow entity problem from being treated as a complete integration failure.

    Check Settings, System, Repairs before changing configuration. A repair notice can describe a migration, deprecated behavior, reauthentication requirement, or duplicate-device correction more accurately than a generic entity state. Read the notice fully and record its wording before dismissing or applying it.

    Use the device’s own local controls or official app as a comparison, but interpret that test carefully. A working vendor app may use a cloud path while Home Assistant uses the local network; conversely, a local device may work while its cloud account is unavailable. The comparison narrows the path but does not by itself identify the fault.

    Build a short timeline from router events, Home Assistant updates, integration reloads, firmware changes, power interruptions, account changes, and the first failed automation. Correlation is not proof, but a reliable timeline tells you which evidence to inspect and which unrelated changes to leave alone.

    Inspect diagnostics without publishing secrets. Useful evidence includes exact timestamps, sanitized error classes, addresses within your private network when appropriate, firmware versions, integration versions, and whether failures are continuous or intermittent. Remove tokens, cookies, serial numbers, email addresses, coordinates, and encryption material.

    Change one variable at a time. After each change, repeat the same test and record the result. Simultaneously restarting the router, Home Assistant, bridges, and devices destroys the evidence needed to learn which action mattered and makes recurrence harder to prevent.

    Prefer reload over restart when the integration supports it. Prefer reconfigure over delete-and-add when the host or account changed. Prefer a DHCP reservation over hard-coding addresses independently in several places. These choices preserve registry relationships and provide a simpler rollback.

    Treat factory reset as recovery, not diagnosis. Before any reset, document pairings, automations, scenes, dashboards, entity IDs, network assignments, encryption keys, and manufacturer-specific recovery requirements. If those cannot be preserved, escalate before resetting.

    When service returns, verify both directions: Home Assistant should read fresh state from the device, and a safe command from Home Assistant should be reflected by the device. Also confirm that a physical or vendor-app change is reported back to Home Assistant.

    Test the real workflow, not only the device page. Trigger a representative automation in a controlled way, inspect its trace, confirm conditions and targets, and restore the previous state. A device can be healthy while an automation still points to an old entity.

    Check recurrence across a normal operating period. Include at least one integration refresh, a DHCP lease check, or the next expected sensor update. For battery equipment, allow for its documented reporting interval instead of assuming silence means failure.

    Create a rollback note containing the former value, new value, change time, and verification result. If the change worsens availability or creates duplicate entities, restore the known-good value before trying the next hypothesis.

    Escalate with a compact evidence bundle when the problem survives safe local checks: model, firmware, Home Assistant version, integration name, sanitized first error, network topology relevant to the path, steps already attempted, and the smallest reliable reproduction. This gives maintainers actionable information without exposing the household.

    Prevent recurrence by documenting address reservations, account ownership, update practices, backup location, integration-specific dependencies, and recovery contacts. Review these notes after router, firmware, or Home Assistant changes rather than waiting for the next outage.

    Avoid unsupported certainty. An unavailable state describes a communication result, not necessarily a failed device. Power, privacy controls, address changes, authentication, sleeping behavior, rate limits, firmware, and network policy can create similar symptoms, so evidence must select the branch.

    If the problem began immediately after an update, read the official integration documentation and current release notes before downgrading. A migration or renamed entity may be expected. Downgrades can introduce database incompatibility and should never be the first response to a single unavailable entity.

    If several unrelated integrations fail together, stop device-specific troubleshooting. Check Home Assistant host health, DNS, time synchronization, network interfaces, Bluetooth or radio adapters, and upstream internet only where the affected integrations require it. Shared failures usually have a shared dependency.

    If only one entity fails while sibling entities from the same device remain current, inspect whether it is disabled, unsupported, conditionally exposed, asleep, or dependent on a specific feature. Re-pairing the entire device is disproportionate until those possibilities are excluded.

    Verification checklist

    Confirm the integration reports loaded, the affected entities have current timestamps, state changes travel in both directions, and the original automation or dashboard works with the expected entity. Repeat the test after a normal reload. Do not declare success from a single momentary update.

    Check that no duplicate device or replacement entity appeared. If a new entity ID was created, compare it with automations, scripts, scenes, dashboards, voice-assistant exposure, and history before removing or renaming anything.

    Rollback and recovery

    If the latest change made the system worse, restore the recorded prior address, option, entity reference, or integration configuration. Reload once and retest. If rollback cannot restore the known-good state, stop making changes, preserve logs, and use the evidence bundle described above.

    Safety and privacy warning

    Heating and cooling equipment can be damaged by inappropriate rapid cycling or extreme setpoints. Do not alter wiring, compressor protection, installer settings, or equipment thresholds to solve an authentication error. Keep a manual way to control the thermostat while integration work is underway.

    Prevention

    Keep Home Assistant, the official integration, and device firmware within supported versions, but avoid changing all layers on the same day. Maintain a current backup, reserve stable network addresses where appropriate, label devices by MAC address, and review logs after planned maintenance.

    Related Troubliq guides

    Start with the Smart-Home Diagnostic Decision Tree, visit the category hub, and compare these related guides: home assistant automation not triggering, alexa devices integration unavailable home assistant, duplicate devices home assistant 2026 8 repair.

    Sources

    Primary source: Home Assistant Ecobee integration documentation. This guide synthesizes the official behavior into a conservative diagnostic order; it does not claim hands-on testing of every model or network.

    Frequently asked diagnostic questions

    Do I still need an Ecobee developer key?

    For Home Assistant 2026.3 and later, the official integration documentation says a new developer API key is no longer required. Avoid obsolete setup guides that instruct you to create one.

    What happens if I revoked the old key?

    The existing integration fails and must be removed and set up again, according to the official documentation. Inventory entity references first so dashboards and automations can be repaired predictably.

    Can reloading restore a revoked credential?

    No. Reloading can retry a temporary connection, but it cannot make a revoked authorization valid. Use the current reauthentication or setup flow.

    Why does the thermostat work while Home Assistant is unavailable?

    The thermostat can continue local HVAC control and communicate through paths separate from Home Assistant’s session. That pattern points toward integration or account connectivity rather than wiring.

    Should I change HVAC settings during setup?

    No. Authentication recovery does not require installer settings, compressor delays, wiring, or extreme setpoints. Keep safe manual control available and test only modest reversible commands.

    What should I verify after adding it again?

    Compare entity IDs, temperature and occupancy updates, HVAC mode, setpoints, dashboards, automations, voice exposure, and history. Reverse any small test change and observe multiple refresh cycles.

    Final verification record

    Record the date, Home Assistant version, device firmware, integration status, entity IDs checked, commands tested, state-update interval observed, and any network or account change that solved the failure. This record turns today’s repair into a faster and safer response if the symptom returns.

    What not to do

    Do not respond to an unavailable state by deleting every related device, clearing registries, changing several network rules, or restoring an old backup without first proving the scope. Those actions can create duplicate entities, break historical continuity, invalidate automation targets, and erase the best evidence. Do not follow screenshots from older releases when the current official integration flow differs.

    Avoid disabling firewalls, privacy controls, encryption, account protections, or electrical safety features as a test. A safer test is narrow, timed, documented, and reversible. If a proposed action cannot be rolled back or its effect is unclear, collect diagnostics and escalate instead of experimenting on a live household system.

    Maintenance check after recovery

    One day after recovery, review entity history for another unavailable period, confirm the router or account still shows the expected relationship, and inspect the automation trace from a normal run. Remove temporary diagnostic logging so secrets and storage use do not accumulate, but keep a sanitized summary of the cause and verified fix.

  • Home Assistant Energy dashboard sensor is missing from the selection list

    Home Assistant Energy dashboard sensor is missing from the selection list

    Direct answer: The Energy dashboard only offers compatible sensor entities. Check the entity domain, device class, state class, unit, and long-term statistics errors before changing the dashboard.

    Symptoms

    • A working power or energy entity is absent from the Energy dashboard selector.
    • The entity appears elsewhere but cannot be chosen for grid, solar, battery, gas, or water.

    Prerequisites

    Record the entity ID and current attributes. Do not edit recorder data or entity registries as a first step.

    Diagnostic steps

    1. Open Settings → Developer tools → States and find the entity.
    2. Confirm it belongs to the sensor domain.
    3. Check device_class: electricity normally requires energy or power; gas and water require their matching classes.
    4. Check state_class. Power measurements normally use measurement; accumulated energy normally uses total or total_increasing.
    5. Confirm the unit is supported and correctly written.
    6. Open Settings → Developer tools → Statistics and resolve any issue shown for the entity.
    7. If an integration supplies incorrect attributes, update it and report the problem to that integration rather than masking it blindly.

    Verify the fix

    After valid statistics are generated, reopen Energy configuration and confirm the sensor appears. Add it, then verify new readings and totals rather than relying on the selector alone.

    Recovery and rollback

    If you created a template sensor, keep the original entity unchanged until the replacement has accumulated valid data. Remove the template only after reverting the dashboard selection.

    Prevention

    Prefer integration-provided energy entities, document templates, and check Statistics after unit or firmware changes.

    Sources

    Last reviewed: September 4, 2026.

    Related Troubliq guides

    Find your next troubleshooting path

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

    Detailed evidence checklist for Home Assistant Energy dashboard sensor is missing from the selection list

    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.

    For checkpoint 1, inspect measurement unit rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 1: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    Checkpoint 2 — device class: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 2: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    Verification checkpoint 3 focuses on state class. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 3: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    For checkpoint 4, inspect numeric state rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 4: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    Checkpoint 5 — statistics ID: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 5: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    Verification checkpoint 6 focuses on statistics repair. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 6: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    For checkpoint 7, inspect power integration helper rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 7: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    Checkpoint 8 — utility-meter source: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 8: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    Verification checkpoint 9 focuses on metric prefix. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 9: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    For checkpoint 10, inspect dashboard refresh rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 10: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    Checkpoint 11 — controlled-load comparison: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 11: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

    Confirm that the entity qualifies for the Energy dashboard

    The Energy dashboard does not list every sensor that displays watts or kilowatt-hours. A consumption source normally needs a supported device class, an appropriate state class and a cumulative energy unit such as Wh or kWh. Open Developer Tools, inspect the entity and record its unit, device_class, state_class and current state. A power sensor measured in W describes a rate; it must be integrated over time before it can represent energy.

    For a cumulative meter, determine whether it increases continuously, resets periodically or can decrease. Use the state class that matches the sensor’s real behavior rather than forcing metadata solely to make the entity appear. Incorrect statistics metadata can produce misleading totals and long-term-statistics warnings.

    Check statistics before editing helpers

    Open Developer Tools and the statistics repair interface. Look for unit changes, unsupported units, non-numeric states, duplicate statistic IDs or a discontinuity caused by replacing an entity. Correct the upstream sensor when possible. A template or utility meter can be appropriate, but it should have a clearly documented source and should not duplicate an already valid cumulative reading.

    If the source is instantaneous power, create an integration helper using the correct time unit and metric prefix, then allow it to accumulate before selecting it. If a daily or monthly view is needed, create a Utility Meter from a valid cumulative energy sensor. Do not chain helpers without checking the resulting unit and statistics behavior.

    Verify the dashboard data path

    • The entity exposes a numeric state in Wh or kWh.
    • Its device and state classes match the measurement behavior.
    • Long-term statistics appear without repair warnings.
    • The Energy configuration accepts the entity after statistics refresh.
    • Totals increase plausibly when a known load operates.

    Allow enough time for the statistics cycle; the dashboard is not an instantaneous display. Compare a controlled appliance run with the change in the cumulative sensor and the dashboard total. If the value is off by a factor of 1,000, inspect unit conversion and metric-prefix settings instead of compensating with an arbitrary dashboard adjustment.