fix(dashboards): repoint power-flow + pv-system-roi to open3e entities #273

Merged
k.renner merged 1 commits from claude-bot/pv-powerflow-open3e into master 2026-07-16 20:24:23 +00:00
Member

Follow-up to #271. The same ViCare → open3e/MQTT migration (2026-07) that broke heatpump-roi also broke the two other dashboards that query the Vitocharge PV/battery entities. This repoints both to the new vitocharge_vx3_vx3_* entities.

power-flow.json (Prometheus, real-time)

Straight entity swaps on homeassistant_sensor_* metrics (device classes unchanged, so metric names are identical):

  • solar_power → pv_power
  • battery SoC …_battery → …_battery_soc
  • The two absolute battery-power sensors (battery_power_in/out_absolute) are gone — open3e exposes a single signed battery_power (positive = discharge, negative = charge, per the open3e package docs). So: discharge = the sensor as-is, charge = × -1, and the history panel's net-battery series = the signed sensor directly.

pv-system-roi.json (InfluxDB)

Repoints all 52 queries, with the unit changes the migration introduced:

  • PV production + battery energy are now Wh (were kWh) → ÷1000
  • Grid import/export energy are now kWh (were Wh) → drop the old ÷1000
  • Grid power sign unchanged (negative = export)
  • History preserved: every timeseries panel (range goes back to the 2023 install) union()s the pre-migration e3_vitocharge_03_* series with the post-migration vitocharge_vx3_vx3_* series, unit-normalized, so the lines stay unbroken across July 2026.
  • Reserved Energy had no direct open3e replacement → recomputed as battery_installed_capacity × backup_discharge_limit / 100.
  • strompreis (EUR/kWh) and the two input_number config entities (…_battery_installed_capacity, …_solar_power_installed) survived the migration and are kept as-is.

Validation

Reuses the exact Flux patterns proven in #271 (pivot/map, union+unit-normalize, findRecord, array.from). The one new construct — deriving charge/discharge from the signed battery_power inside a union branch — was run live in Grafana Explore and returns a continuous series across the migration boundary. JSON validated (power-flow 3 panels, pv-system-roi 26 panels; power-flow has zero retired-entity refs, pv-system-roi retains them only inside the intended history-union branches).

Note

Please eyeball the numbers after deploy, especially the battery charge/discharge split and the PV/grid unit scaling.

🤖 Generated with Claude Code

Follow-up to #271. The same ViCare → open3e/MQTT migration (2026-07) that broke `heatpump-roi` also broke the two other dashboards that query the **Vitocharge** PV/battery entities. This repoints both to the new `vitocharge_vx3_vx3_*` entities. ## `power-flow.json` (Prometheus, real-time) Straight entity swaps on `homeassistant_sensor_*` metrics (device classes unchanged, so metric names are identical): - `solar_power` → `pv_power` - battery SoC `…_battery` → `…_battery_soc` - The two absolute battery-power sensors (`battery_power_in/out_absolute`) are gone — open3e exposes a **single signed** `battery_power` (**positive = discharge, negative = charge**, per the open3e package docs). So: discharge = the sensor as-is, charge = `× -1`, and the history panel's net-battery series = the signed sensor directly. ## `pv-system-roi.json` (InfluxDB) Repoints all 52 queries, with the unit changes the migration introduced: - PV production + battery energy are now **Wh** (were kWh) → `÷1000` - Grid import/export energy are now **kWh** (were Wh) → drop the old `÷1000` - Grid power sign unchanged (negative = export) - **History preserved:** every timeseries panel (range goes back to the 2023 install) `union()`s the pre-migration `e3_vitocharge_03_*` series with the post-migration `vitocharge_vx3_vx3_*` series, unit-normalized, so the lines stay unbroken across July 2026. - **Reserved Energy** had no direct open3e replacement → recomputed as `battery_installed_capacity × backup_discharge_limit / 100`. - `strompreis` (EUR/kWh) and the two `input_number` config entities (`…_battery_installed_capacity`, `…_solar_power_installed`) survived the migration and are kept as-is. ## Validation Reuses the exact Flux patterns proven in #271 (pivot/map, union+unit-normalize, `findRecord`, `array.from`). The one new construct — deriving charge/discharge from the signed `battery_power` inside a union branch — was run live in Grafana Explore and returns a continuous series across the migration boundary. JSON validated (power-flow 3 panels, pv-system-roi 26 panels; `power-flow` has zero retired-entity refs, `pv-system-roi` retains them only inside the intended history-union branches). ## Note Please eyeball the numbers after deploy, especially the battery charge/discharge split and the PV/grid unit scaling. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude-bot added 1 commit 2026-07-16 20:23:14 +00:00
The 2026-07 ViCare->open3e/MQTT migration renamed the Vitocharge PV/battery entities (e3_vitocharge_03_* -> vitocharge_vx3_vx3_*) and changed some units. Both dashboards still queried the retired entities and showed No data.

power-flow (Prometheus, real-time): solar_power->pv_power, battery SoC->battery_soc; the two absolute battery-power sensors are replaced by a single signed battery_power (open3e: positive=discharge, negative=charge), so charge/discharge derive from its sign.

pv-system-roi (InfluxDB): repoint every query; fix units (PV/battery energy now Wh not kWh -> /1000; grid energy now kWh not Wh); grid power sign unchanged (negative=export). Timeseries panels UNION pre-migration e3_* with post-migration series (unit-normalized) so history back to 2023 stays unbroken. Reserved Energy recomputed as capacity x backup_discharge_limit. strompreis + the two input_number config entities survived and are kept.

Validated live via Grafana Explore: signed-battery charge/discharge union, unit normalization, pivot/value patterns (reused from merged heatpump-roi fix #271).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QiLCinB7NLp7YdCjGYzvfh
k.renner merged commit 592fef04fc into master 2026-07-16 20:24:22 +00:00
Sign in to join this conversation.