Fix consumption-entity resolution: registry lookup instead of guessed entity_id

Verifying the hourly-profile data path surfaced the reason the profile-aware
overnight reserve might not take effect: _resolve_consumption_entity GUESSED
the inverter load sensor's entity_id as `sensor.{title}_{key}`. But HA derives
the entity_id from the slugified friendly NAME, e.g. "Homeload Day Cost Energy
（0.1KWh）" → `sensor.<title>_homeload_day_cost_energy_0_1kwh` — so the guess
never matched, hass.states.get() returned None, resolution failed, and the
hourly profile silently fell back to a FLAT daily/24 distribution. A flat
profile makes the profile-aware reserve identical to the old flat reserve, so
the daytime-EV phantom-deficit fix would have had no effect on real installs.

Now resolves the entity via the entity registry using the exact unique_id the
integration assigned (`{entry_id}_{key}`) — exact and rename-proof. Keeps the
override entity as first choice and the old title-guess as a last-resort
fallback.

Rest of the path verified sound: recorder statistics_during_period for hourly
buckets, 7-day averaging, persisted + recomputed on startup (no cold-start
gap), exposed as consumption_hourly_profile for inspection.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P9LAQ5ET6SU9dLWULxv2uF

Author: claude

CLAUDE.md

@@ -1313,7 +1313,34 @@ extrapolation from today's actual production) so the algorithm doesn't
 default to PV=0 and over-aggressively grid-charge.
 
 #### C. Consumption Profile Awareness — IMPLEMENTED
-Hourly consumption profiles from 7-day HA recorder history. `EMSState.consumption_hourly_kwh` provides per-hour averages used in `_project_soc_trajectory()` and `_validate_schedule_soc()`. Coordinator records hourly breakdown at midnight. Frontend card also uses profiles.
+Hourly consumption profiles from 7-day HA recorder history. `EMSState.consumption_hourly_kwh` provides per-hour averages used in `_project_soc_trajectory()`, `_validate_schedule_soc()`, and (July 2026) the overnight reserve. Coordinator records hourly breakdown at midnight. Frontend card also uses profiles.
+
+**Data path** (`coordinator`):
+1. `_resolve_consumption_entity` — picks the source: the user's
+   `consumption_override_entity` if set, else an inverter load-energy sensor
+   (`homeload_day_cost_energy` / `load_day_cost_energy` / …) resolved via the
+   **entity registry** by the exact `unique_id` (`{entry_id}_{key}`).
+2. `_query_hourly_from_history` — HA recorder `statistics_during_period`
+   ("change" per hour) → 24 hourly buckets.  Falls back to a FLAT daily/24
+   distribution when no statistics exist.
+3. `_record_hourly_consumption` (midnight) appends to a 7-day
+   `_hourly_consumption_history`; `_calculate_hourly_profile` averages it into
+   `_hourly_consumption_profile`.  Persisted in the consumption Store and
+   **recomputed on startup** from the loaded history (no cold-start gap).
+4. Exposed as `consumption_hourly_profile` in `schedule_status` attributes —
+   inspect it to confirm the shape (low-night/high-day for EV loads).  A FLAT
+   profile (all hours equal) means the history query fell back (no stats or,
+   pre-fix, an unresolved entity).
+
+**Registry-lookup fix (July 2026)**: `_resolve_consumption_entity` previously
+GUESSED the entity_id as `sensor.{title}_{key}`.  HA derives the entity_id
+from the slugified friendly NAME (e.g. "Homeload Day Cost Energy （0.1KWh）" →
+`..._homeload_day_cost_energy_0_1kwh`), so the guess never matched → the hourly
+profile silently fell back to FLAT → the profile-aware overnight reserve had no
+effect (daytime-heavy / EV loads looked flat overnight again).  Now resolved
+via `entity_registry.async_get_entity_id("sensor", DOMAIN, unique_id)` — exact
+and rename-proof.  Best accuracy still comes from setting a
+`consumption_override_entity` (a real P1/energy meter).
 
 #### C2. SOC History Display — IMPLEMENTED
 Coordinator records battery SOC at each slot boundary in `_soc_history`. Frontend draws solid line for actual past SOC, dotted line for projected future.

custom_components/ha_felicity/coordinator.py

@@ -1734,15 +1734,43 @@ async def _record_hourly_consumption(self, date_str: str) -> None:
         self._calculate_hourly_profile()
 
     def _resolve_consumption_entity(self) -> str | None:
-        """Return the best entity_id to query for hourly consumption history."""
+        """Return the best entity_id to query for hourly consumption history.
+
+        Resolution order:
+          1. The user's consumption_override_entity (a real energy meter / P1).
+          2. An inverter load-energy sensor this integration created — looked
+             up via the ENTITY REGISTRY by the exact unique_id the sensor was
+             registered with (`{entry_id}_{key}`).  The old code GUESSED the
+             entity_id as `sensor.{title}_{key}`, but HA derives the entity_id
+             from the slugified friendly NAME (e.g. "Homeload Day Cost Energy
+             （0.1KWh）" → `..._homeload_day_cost_energy_0_1kwh`), so the guess
+             never matched → resolution failed → the hourly profile silently
+             fell back to a FLAT distribution.  That flat profile defeats the
+             profile-aware overnight reserve (daytime-heavy / EV loads look
+             like flat overnight consumption again).  The registry lookup is
+             exact and rename-proof.
+        """
         if self.consumption_override_entity:
             return self.consumption_override_entity
-        # Try to find the sensor entity created by this integration for load energy
+
+        from homeassistant.helpers import entity_registry as er
+        ent_reg = er.async_get(self.hass)
+        entry_id = self.config_entry.entry_id
         for key in ["daily_energy_consumed", "daily_load_energy",
                      "total_load_consumption_energy_day",
                      "load_consumption_energy_day",
                      "homeload_day_cost_energy",
                      "load_day_cost_energy"]:
+            eid = ent_reg.async_get_entity_id("sensor", DOMAIN, f"{entry_id}_{key}")
+            if not eid:
+                continue
+            state = self.hass.states.get(eid)
+            if state and state.state not in ("unknown", "unavailable"):
+                return eid
+
+        # Legacy fallback: the old title-based guess (kept in case a future
+        # entity isn't in the registry under the expected unique_id).
+        for key in ["homeload_day_cost_energy", "load_day_cost_energy"]:
             eid = f"sensor.{self.config_entry.title.lower().replace(' ', '_')}_{key}"
             state = self.hass.states.get(eid)
             if state and state.state not in ("unknown", "unavailable"):