Charging still bouncing around the 100% mark

[Sycamore967]

Describe the bug Won't hold 100% throughout the charging window

Expected behavior Charge to 100% and stay there without dropping or switching to discharge.

Predbat version

7.16.8

Environment details

• GEN3 Inverter
• Using REST
• HAOS

Screenshots

Log file Hopefully the screenshot says enough, but if you need to log file I'll have to send it later.

[gcoan]

Have you tried setting inverter_reserve_max in apps.yaml to 98

There is a known bug in Gen 3 inverters that causes the inverter to not be able to set to 100 https://springfall2008.github.io/batpred/apps-yaml/#workarounds

[Sycamore967]

I could certainly set that, but it is capable of getting to 100% and staying there if I turn off BatPred and just go with the GivEnergy schedule and BatPred was been better at staying at 100% in earlier versions. I didn't see the discharge spikes for instance.

[gcoan]

If you think its predbat that is letting the battery discharge and then recharge (not just the inverter not holding charge) then it will definitely help if you can share the logfile and maybe some screen shots of entities changing over time in Home Assistant - things like target soc, battery power, charge & discharge rate over that time period will help show what predbat is instructing the inverter to do.

I don't see that behaviour with my Gen 1 inverters, there is a small cross-charging problem when one inverter soc is above target Soc #829 (which is the small bouncing you see early on), but otherwise the batteries smoothly charge to 100% and stay there for me.

Which is why I think it may be inverter caused rather than predbat letting the inverter discharge then recharge

[RobinCu]

I have a Gen3, and the inverter_reserve_max: 98 fixed the issue of bouncing from 98 - 100%. To be fair, Sycamore967's looks less frequent than my own and others I've seen (mine was bouncing after each recalculation and could be seen in the Predbat status log).

My take (which may be wrong) on why the issue occurs with Predbat and not GE settings is that Predbat relies on setting a reserve, as it recalculates every 5 minutes and may reach the target SOC earlier than planned if the house load exceeds forecast. GE settings may get around the bug by reading SOC more frequently locally. It's certainly worth implementing and seeing if it occurs overnight.

@gcoan With more Gen3 users onboarding, do you think inverter_reserve_max: 98 should be the default? Would there be any unintended consequences for Gen1 installs? Maybe it just needs a bit more prominence in the docs. I've told three people in the GivTCP Facebook group about reserve_max this week, so it seems to be cropping up more frequently.

[gcoan]

@gcoan With more Gen3 users onboarding, do you think inverter_reserve_max: 98 should be the default? Would there be any unintended consequences for Gen1 installs? Maybe it just needs a bit more prominence in the docs. I've told three people in the GivTCP Facebook group about reserve_max this week, so it seems to be cropping up more frequently.

Trefor has changed the default for this to 98 in the template apps.yaml https://github.com/springfall2008/batpred/blob/main/apps/predbat/config/apps.yaml although obviously this won't help people with existing installs

  # Workaround to limit the maximum reserve setting, some inverters won't allow 100% to be set
  # Comment out if your inverter allows 100%
  inverter_reserve_max : 98

At some point I was thinking of pulling together some of these 'inverter specific recommended settings' into a more prominent place in the documentation as there are one or two of them that are buried in amongst what is now a lot of documentation. I'll put that on the longer term improvement list, am still working through the customisation doc at the moment.

@Sycamore967 I think its worth setting this in apps.yaml and see how it behaves overnight

[Sycamore967]

Hi there, just a quick update. I'm still monitoring after setting inverter_reserve_max : 98

It does seem to have smoothed out the charge and I've not noticed any discharge spikes. Tonight will be the first night I charge the car at the same time as the house batteries. That's when I noticed the problem in the first place, so I'll report back tomorrow.

[slopemad]

Wouldn't a solution be to set the discharge rate to 0 to prevent unwanted battery discharge?

[Sycamore967]

Well......woke up to this yesterday

As you can see, something happened at 03:55 and things went downhill from there. Now I'm not saying it's Predbat. Far from it, if I'm reading the attached log correctly PB is still trying to set a charge window, but it seems my inverter and my slave battery BMS fell out with each other!

Joking aside, I said I'd report back after setting inverter_reserve_max : 98 For the one day of data I have when I was charging both the house and the car, prior to yesterdays fun, the bouncing seems to have been flattened out,

If you are interested in yesterday fun, I've attached the log. (appdaemon.log.3)

Things went wrong in it here: 2024-03-28 04:00:44.950358 INFO pred_bat: Inverter 0 with soc_max 19.05 kWh nominal_capacity 9.52 kWh battery rate raw 3600 w charge rate 3.6 kW discharge rate 3.6 kW battery_rate_min 0.0 w ac limit 3.6 kW export limit 3.6 kW reserve 5.0 % current_reserve 5.0 %

You can see the BMS fail on the second battery and my nominal capacity half. As the car was charging at the time and the inverter switched to discharging, it significantly drained the one remaining battery, despite what I think I can see and PB still trying to set a charge window. (I don't know if PB could have reset anything. I'm including all this just in case it's of any use at all).

The resulting rapidly increasing voltage difference between each battery (the slave was still reporting 100% SOC when I woke up) meant that it never came back online as BMS can't cope with such a large voltage difference.

GivEnergy initially wanted Octopus to come out and disconnected the BMS board from the DC supply inside the battery to reset the board, but then later in the day suggested charging the master battery might get the voltages back in line. It did. I'm ok this morning and running on 2 batteries again. I've attached todays log for completeness. You should be able to see me switch to read only mode @3:30 this morning just to check things out.

appdaemon.log.zip