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

• Home Assistant: Energy dashboard FAQ and missing entities
• Home Assistant developer documentation: sensor properties

Last reviewed: September 4, 2026.

Related Troubliq guides

• Start Here
• General troubleshooting

Find your next troubleshooting path

• Sensors and thermostats hub
• Home Assistant automations hub
• Smart-home diagnostic decision tree

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.