Solar sometimes shows correctly in plan, other times stays at fixed number

springfall2008 / batpred

Home battery prediction and charging automation for Home Assistant, supporting many inverter types

https://springfall2008.github.io/batpred/

114 stars 39 forks source link

Solar sometimes shows correctly in plan, other times stays at fixed number #530

Closed Boffinboy closed 8 months ago

Boffinboy commented 8 months ago

Happy Christmas! thank you for your work and making predbat available to us!

Describe the bug In the plan, the PV kWh column sometimes shows a fixed value, after reaching a certain point - this continues from then onwards even through the night. I am not sure if this is being used for planning or just a display error. Usually appears to correct itself after I notice.

Expected behavior Should show forecast values

Predbat version v7.14.24 - oops realised I was on v7.14.22, will check if new PV fix has worked!

Environment details

Givenergy AC3 and 9.5 battery
HAOS running in VM on Synology NAS

Screenshots “Stuck” at 0.53

“Stuck” at 0.49

Log file Not been able to capture a log when I’ve noticed it yet - what period should I capture?

Boffinboy commented 8 months ago

Looking at plan it does seem to be influencing it, see below where SoC looks to be increasing

springfall2008 commented 8 months ago

Hopefully fixed now: https://github.com/springfall2008/batpred/releases/tag/v7.14.25

Boffinboy commented 8 months ago

Thank you. I think it may have been fixed and I’d not updated to 14.24. Have updated to 25 and will let you know!

Boffinboy commented 8 months ago

Looks like the issue isn’t occurring anymore! However, I am a bit puzzled by the current plan. It seems to only be doing a very small charge before the peak, despite many slots being nearly half the price of others. Even with round trip losses I would have thought it makes sense to charge? I have conservative settings for the solar because Solcast tends to significantly err on the positive for my array vs reality, and I have set a high bar for force discharge as I don’t want the extra cycles, but I am surprised there is no charging happening.

springfall2008 commented 8 months ago

Try setting metric soc keep to 0.5 and maybe reduce metric battery cycle back to 2?

Boffinboy commented 8 months ago

Setting keep to 0.4 (roughly equivalent to 4% reserve) totally transformed it back to something more like I’d expect. I’m still not entirely sure how the soc keep influences the plan - I would have thought allowing it to run to empty with would be optimal?

springfall2008 commented 8 months ago

Was the empty plan cheaper or more expensive for the next 24 hours?

Boffinboy commented 8 months ago

I have to confess I didn’t check… very silly of me!

Boffinboy commented 8 months ago

On a somewhat related note - does metric_min_improvement_discharge relate solely to forced discharge (including export)? Or does it related to discharging to house load? I wasn’t quite sure from reading the notes. I am trying to figure out the right setting to reduce forced export, unless definitely very profitable, whilst allowing standard discharging to house load. Is this the right setting for that?

Sorry for edit - I was also curious over what time period the metric refers to eg if it’s set at 1 does that mean a 1p gain in the slot is the minimum required to set to discharge? Or 1p over the whole optimisation? Or something else?

springfall2008 commented 8 months ago

On a somewhat related note - does metric_min_improvement_discharge relate solely to forced discharge (including export)?

It relates to forced export, and the time period is one export slot which can be normally up to 1 hour maximum bit is sized in 5 minute chunks.

Boffinboy commented 8 months ago

Thank you very much for the explanation. Have sent you a couple of beers. Really appreciate your work and responsiveness!