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 signedbattery_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.
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)
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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Follow-up to #271. The same ViCare → open3e/MQTT migration (2026-07) that broke
heatpump-roialso broke the two other dashboards that query the Vitocharge PV/battery entities. This repoints both to the newvitocharge_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→…_battery_socbattery_power_in/out_absolute) are gone — open3e exposes a single signedbattery_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:
÷1000÷1000union()s the pre-migratione3_vitocharge_03_*series with the post-migrationvitocharge_vx3_vx3_*series, unit-normalized, so the lines stay unbroken across July 2026.battery_installed_capacity × backup_discharge_limit / 100.strompreis(EUR/kWh) and the twoinput_numberconfig 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 signedbattery_powerinside 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-flowhas zero retired-entity refs,pv-system-roiretains 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