Which entity gives a reliable day-ahead PV forecast total? (predbat_pv_forecast_raw scaling inconsistent)

[duncvfr1]

Trying to build a Home Assistant automation that snapshots Predbat's day-ahead PV forecast total (kWh) each evening, so I can chart it against actual generation over time — similar to the GivEnergy portal's "Estimated Actual PV (Solcast) vs Actual PV" comparison chart, but using Predbat's own forecast instead of Solcast.

I tried reading sensor.predbat_pv_forecast_raw's forecast attribute (a dict of {minutes_offset: value} pairs relative to relative_time, which appears to be anchored to midnight today). The idea was to sum the values for the 1440–2880 minute window (tomorrow) × the interval between entries to get a kWh total.

The problem: when I cross-check individual values from this raw dict against other Predbat PV sensors (sensor.predbat_pv_forecast_h0's now attribute, and the Plan table's own displayed PV column), the ratio between them isn't consistent — I'm seeing roughly 30x, 70x, and 87x differences depending on which point in time I check, not a fixed scale factor. So I don't think the raw dict's values are in the same units (or same context) as the other forecast entities, and I can't find a documented explanation.

Questions:

What unit/scale are the values in sensor.predbat_pv_forecast_raw's forecast attribute actually in, and how do they relate to predbat_pv_forecast_h0's values?
Is there a better/intended entity or method for getting tomorrow's (or day+2, day+3's) full-day PV forecast total programmatically, for logging/charting purposes, rather than reading the Plan table by eye each day?

Running GivTCP + Predbat via HACS/AppDaemon on Home Assistant, PV forecast source recently switched from Solcast to Open-Meteo if that's relevant.

This version works as-is for the Predbat GitHub/Discord community (technical, entity-focused). For the Facebook GivTCP group, you might trim the entity-specific jargon slightly since that group leans more GivEnergy-hardware-focused than Predbat-internals-focused — but the core question stands either way, and it's worth posting in both since the sensor in question is Predbat's, not GivTCP's, even though your setup combines both.

[gcoan]

sensor.predbat_pv_forecast_raw isn't included in the documentation, it must have been added at some point

why don't you use sensor.predbat_pv_tomorrow and the totalCL attributes?

one issue you could well be experiencing with using sensor.predbat_pv_forecast_h0 is that power now is an interpolation of the half hour forecast

[duncvfr1]

Yes I think that’s a better option Thanks

…

On 18 Aug 2026, at 11:36, Geoffrey Coan ***@***.***> wrote: sensor.predbat_pv_forecast_raw isn't included in the documentation, it must have been added at some point why don't you use sensor.predbat_pv_tomorrow and the totalCL attributes? one issue you could well be experiencing with using sensor.predbat_pv_forecast_h0 is that power now is an interpolation of the half hour forecast