Predbat causing cross-charging in multi-inverter setup

[gcoan]

I have two 5kW hybrid inverters. One (G182) with a 9.5kW battery and one (G395) with a 5.2kW battery.

Predbat controls both of them with no issues but I have noticed for the last two nights it appears that overnight there is cross-charging occurring when predbat sets the battery reserve levels to hold the battery charge through the flux cheap overnight period. As the battery capacities are so different the batteries naturally discharge at different rates so have different SoC's. In the overnight period I can see the 5.2 battery (purple line) discharging and the 9.5 (blue line) charging, but the corresponding overall kWh SoC (calculated by predbat) doesn't change (blue line bottom graph) and there's no import occurring (bottom graph purple line)

The appdaemon.log file for last night has wrapped round so I'll have to capture another one from tonight.

How do I stop this happening? Will the new predbat_balance_inverters switches help?

[springfall2008]

Can you try turning on inverter balancing ? I suspect there maybe a better way to handle this but this feature should patch it.

[gcoan]

Sure, balance inverters for charging, discharging and cross-charging were all turned on (by default) but balance_inverters_enable was set to off. I've turned this on.

Batteries are currently on slightly different SoC's, so I'll see what turning this on does

[gcoan]

first run:

2023-10-04 23:31:20.246622 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, True] can_power_house [True, True] power_enough_discharge [True, True] power_enough_charge [False, False] soc_low [True, False] soc_high [False, True]
2023-10-04 23:31:20.247692 INFO pred_bat: BALANCE: Inverter 0 is out of balance low - during discharge, attempting to balance it using inverter 1
2023-10-04 23:31:20.248652 INFO pred_bat: Inverter 0 current discharge rate is 2600 and new target is 0
2023-10-04 23:31:36.362214 INFO pred_bat: Inverter 0 set discharge rate 0 via REST succesfull on retry 0
2023-10-04 23:31:36.459356 INFO pred_bat: BALANCE: Completed this run

I can see that inverter 1 which has the lower SoC the discharge rate has been changed to zero.

There's something not quite right with the rebalance logic because a minute later it determined that the batteries are in balance (when they weren't), set discharge rate to 2600, then a minute later set to zero, then back to 2600:

2023-10-04 23:32:19.283716 INFO pred_bat: BALANCE: socs [27, 33] reserves [0.38, 0.21] battery_powers [8.0, 818.0] total 826.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] total 5200.0 discharge_rates [0.0, 2600.0] total 2600.0
2023-10-04 23:32:19.284644 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, True] can_power_house [True, False] power_enough_discharge [False, True] power_enough_charge [False, False] soc_low [True, False] soc_high [False, True]
2023-10-04 23:32:19.285652 INFO pred_bat: BALANCE: Inverter 0 reset discharge rate to 2600.0 now balanced
2023-10-04 23:32:19.286841 INFO pred_bat: Inverter 0 current discharge rate is 0 and new target is 2600
2023-10-04 23:32:35.124417 INFO pred_bat: Inverter 0 set discharge rate 2600 via REST succesfull on retry 0
2023-10-04 23:32:35.191759 INFO pred_bat: BALANCE: Completed this run
2023-10-04 23:33:15.011359 INFO pred_bat: BALANCE: Enabled balance charge True discharge True crosscharge True
2023-10-04 23:33:15.012300 INFO pred_bat: Inverter 0 using Rest API http://homeassistant.local:6345
2023-10-04 23:33:16.038705 INFO pred_bat: Invertor time 2023-10-04 23:33:11+01:00 AppDeamon time 2023-10-04 23:33:15.011498+01:00 difference -0.08 minutes
2023-10-04 23:33:16.040394 INFO pred_bat: New Inverter 0 with soc_max 9.52 kWh nominal_capacity 9.52 kWh battery rate raw 2600.0 w charge rate 2.6 kw discharge rate 2.6 kw ac limit 5.0 kw export limit 5.0 kw reserve 4.0 % current_reserve 4.0 %
2023-10-04 23:33:17.087937 INFO pred_bat: Inverter 0 SOC: 2.57 kw 27 % Current charge rate 2600.0 w Current discharge rate 2600.0 wcurrent power 226.0 w
2023-10-04 23:33:17.088894 INFO pred_bat: Inverter 0 scheduled charge enable is False
2023-10-04 23:33:17.090455 INFO pred_bat: Inverter 0 charge windows currently []
2023-10-04 23:33:17.091577 INFO pred_bat: Inverter 0 Charge settings: timed charged is disabled, power 2.6 kw
2023-10-04 23:33:17.093091 INFO pred_bat: Inverter 0 scheduled discharge enable is False
2023-10-04 23:33:17.094365 INFO pred_bat: Inverter 0 discharge windows currently [{'start': 1095, 'end': 1140, 'average': 0}, {'start': 2535, 'end': 2580, 'average': 0}]
2023-10-04 23:33:17.095275 INFO pred_bat: Inverter 1 using Rest API http://homeassistant.local:6346
2023-10-04 23:33:18.132151 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_charge value 2600
2023-10-04 23:33:18.133233 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_discharge value 2600
2023-10-04 23:33:18.134300 INFO pred_bat: Invertor time 2023-10-04 23:33:32+01:00 AppDeamon time 2023-10-04 23:33:15.011498+01:00 difference 0.27 minutes
2023-10-04 23:33:18.135458 INFO pred_bat: New Inverter 1 with soc_max 5.22 kWh nominal_capacity 5.22 kWh battery rate raw 2600.0 w charge rate 2.6 kw discharge rate 2.6 kw ac limit 5.0 kw export limit 5.0 kw reserve 4.0 % current_reserve 4.0 %
2023-10-04 23:33:19.374981 INFO pred_bat: Inverter 1 SOC: 1.72 kw 33 % Current charge rate 2600.0 w Current discharge rate 2600.0 wcurrent power 563.0 w
2023-10-04 23:33:19.376082 INFO pred_bat: Inverter 1 scheduled charge enable is False
2023-10-04 23:33:19.377025 INFO pred_bat: Inverter 1 charge windows currently []
2023-10-04 23:33:19.378043 INFO pred_bat: Inverter 1 Charge settings: timed charged is disabled, power 2.6 kw
2023-10-04 23:33:19.379120 INFO pred_bat: Inverter 1 scheduled discharge enable is False
2023-10-04 23:33:19.381184 INFO pred_bat: Inverter 1 discharge windows currently [{'start': 1095, 'end': 1140, 'average': 0}, {'start': 2535, 'end': 2580, 'average': 0}]
2023-10-04 23:33:19.381953 INFO pred_bat: BALANCE: socs [27, 33] reserves [0.38, 0.21] battery_powers [226.0, 563.0] total 789.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] total 5200.0 discharge_rates [2600.0, 2600.0] total 5200.0
2023-10-04 23:33:19.382745 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, True] can_power_house [True, True] power_enough_discharge [True, True] power_enough_charge [False, False] soc_low [True, False] soc_high [False, True]
2023-10-04 23:33:19.383519 INFO pred_bat: BALANCE: Inverter 0 is out of balance low - during discharge, attempting to balance it using inverter 1
2023-10-04 23:33:19.384378 INFO pred_bat: Inverter 0 current discharge rate is 2600 and new target is 0
2023-10-04 23:33:35.243358 INFO pred_bat: Inverter 0 set discharge rate 0 via REST succesfull on retry 0
2023-10-04 23:33:35.285841 INFO pred_bat: BALANCE: Completed this run
2023-10-04 23:34:15.012958 INFO pred_bat: BALANCE: Enabled balance charge True discharge True crosscharge True
2023-10-04 23:34:15.014230 INFO pred_bat: Inverter 0 using Rest API http://homeassistant.local:6345
2023-10-04 23:34:16.060257 INFO pred_bat: Invertor time 2023-10-04 23:33:47+01:00 AppDeamon time 2023-10-04 23:34:15.013148+01:00 difference -0.48 minutes
2023-10-04 23:34:16.061653 INFO pred_bat: New Inverter 0 with soc_max 9.52 kWh nominal_capacity 9.52 kWh battery rate raw 2600.0 w charge rate 2.6 kw discharge rate 2.6 kw ac limit 5.0 kw export limit 5.0 kw reserve 4.0 % current_reserve 4.0 %
2023-10-04 23:34:17.124988 INFO pred_bat: Inverter 0 SOC: 2.57 kw 27 % Current charge rate 2600.0 w Current discharge rate 0.0 wcurrent power 8.0 w
2023-10-04 23:34:17.125951 INFO pred_bat: Inverter 0 scheduled charge enable is False
2023-10-04 23:34:17.126776 INFO pred_bat: Inverter 0 charge windows currently []
2023-10-04 23:34:17.127766 INFO pred_bat: Inverter 0 Charge settings: timed charged is disabled, power 2.6 kw
2023-10-04 23:34:17.128859 INFO pred_bat: Inverter 0 scheduled discharge enable is False
2023-10-04 23:34:17.129941 INFO pred_bat: Inverter 0 discharge windows currently [{'start': 1095, 'end': 1140, 'average': 0}, {'start': 2535, 'end': 2580, 'average': 0}]
2023-10-04 23:34:17.130765 INFO pred_bat: Inverter 1 using Rest API http://homeassistant.local:6346
2023-10-04 23:34:18.158726 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_charge value 2600
2023-10-04 23:34:18.159937 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_discharge value 2600
2023-10-04 23:34:18.161118 INFO pred_bat: Invertor time 2023-10-04 23:34:08+01:00 AppDeamon time 2023-10-04 23:34:15.013148+01:00 difference -0.13 minutes
2023-10-04 23:34:18.162277 INFO pred_bat: New Inverter 1 with soc_max 5.22 kWh nominal_capacity 5.22 kWh battery rate raw 2600.0 w charge rate 2.6 kw discharge rate 2.6 kw ac limit 5.0 kw export limit 5.0 kw reserve 4.0 % current_reserve 4.0 %
2023-10-04 23:34:19.403572 INFO pred_bat: Inverter 1 SOC: 1.72 kw 33 % Current charge rate 2600.0 w Current discharge rate 2600.0 wcurrent power 775.0 w
2023-10-04 23:34:19.404673 INFO pred_bat: Inverter 1 scheduled charge enable is False
2023-10-04 23:34:19.405823 INFO pred_bat: Inverter 1 charge windows currently []
2023-10-04 23:34:19.406891 INFO pred_bat: Inverter 1 Charge settings: timed charged is disabled, power 2.6 kw
2023-10-04 23:34:19.408221 INFO pred_bat: Inverter 1 scheduled discharge enable is False
2023-10-04 23:34:19.409682 INFO pred_bat: Inverter 1 discharge windows currently [{'start': 1095, 'end': 1140, 'average': 0}, {'start': 2535, 'end': 2580, 'average': 0}]
2023-10-04 23:34:19.410555 INFO pred_bat: BALANCE: socs [27, 33] reserves [0.38, 0.21] battery_powers [8.0, 775.0] total 783.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] total 5200.0 discharge_rates [0.0, 2600.0] total 2600.0
2023-10-04 23:34:19.411519 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, True] can_power_house [True, False] power_enough_discharge [False, True] power_enough_charge [False, False] soc_low [True, False] soc_high [False, True]
2023-10-04 23:34:19.412820 INFO pred_bat: BALANCE: Inverter 0 reset discharge rate to 2600.0 now balanced
2023-10-04 23:34:19.413808 INFO pred_bat: Inverter 0 current discharge rate is 0 and new target is 2600
2023-10-04 23:34:35.302963 INFO pred_bat: Inverter 0 set discharge rate 2600 via REST succesfull on retry 0
2023-10-04 23:34:35.333340 INFO pred_bat: BALANCE: Completed this run

[springfall2008]

Ah okay, I think I see the problem. It actually should work okay but it will take long to return back - I'll try to put in a fix

[springfall2008]

Are you able to try a fix on 'main' out please? If you go to HACS and redownload and select 'main', you may then need to restart appDeamon

[gcoan]

The good news, it did appear that the balance inverters worked, the two inverter SoC lines came together after I turned on the balancing at about 11pm (the current SoC flatline is due to predbat crashing because I put the multiple days_previous_weight in wrongly as a set of values on a single line)

That's the good news. A some side effect of the balance inverters is that the discharge rate got set to zero by predbat. Got up this morning to find the prediction showing that the battery would discharge down to empty and then never charge. Both battery charge rates were set to zero.

I turned off the balancing. predbat didn't reset the charge rates so I manually changed them both and the batteries are now charging again.

Here's the logfile from around 5am when predbat left charge rate at zero after the cheaprate period: appdaemon.1.log

and the logfile from this morning when I disabled balancing, charge rate didn't change and then I manually changed it back. Only after I changed the charge rate did the prediction jump back to what I'd expect of the battery charging through the day and supporting the house overnight: appdaemon.log

[gcoan]

Here (for the above) is the status history

I have redownloaded predbat. I only had the option to download 7.5 or 7.6 (I was on 7.5). Downloaded 7.6 and restarted appdaemon. There wasn't an option for 'main' - turning on show beta versions didn't look any different versions to download.

Turned the balancing back on. Looks like its making changes to charge rates again, but more fine grained? here's the logfile appdaemon (2).log

[springfall2008]

Okay thanks for the log, I found the issue with the zero charge rate and re-released v.7.6.1 - please try that one.

FYI - Main is on the list here:

[gcoan]

Thanks for a quick turnaround. I have installed 7.6.1 and will leave it running for a bit then see what its doing.
Ah yes, I see main, at the bottom of the list !

[gcoan]

Have left it running for a while, 7.6.1 with all the balance settings turned on

On the positive front, predbat does seem to be successful in balancing the inverters, but its chopping the charge rates up and down every minute to get there and I'm not sure I like that or the side effect of charge throughput. Inverter 1 is entirely East facing on the front of the house, Inverter 2 is half East on the garage front and half West in the gaps between the FIT panels. So morning is my peak charging period and by frequently chopping the charge rate off to keep the batteries in balance I'm throwing quite a lot of solar out as grid export.

This seems a very big hammer to crack a nut of an overnight cross charging issue with battery hold. I'm going to turn off switch.predbat_balance_inverters_charge. Still leaving balance for discharge and cross-charging on and see what this does. .... Its cut down the notifications dramatically for one thing!

[gcoan]

Since turning balance_inverters_charge off at about 10:30, I can't see a visible change in the rate at which the SoC's are increasing, but can see as I expected it to that the SoCs have diverged slightly but more importantly the export power has dropped noticeably. Export was peaking up to 3-4kW, now its all under 1kW

[springfall2008]

I was thinking of adding a balance threshold for charge and one for discharge, e.g. only balance charge if they are more than say 10% apart, but the problem is it's not going to solve it as once it gets that far apart it would be back to up and down around 9-10%.

Another idea is to reduce the charge rate based on the % difference between the two, but then again if your PV is imbalanced you will still end up losing charge in the end. Maybe see what its like with discharge only?

[gcoan]

Turning balance_inverters_charge off, things worked as I'd normally expect, the batteries charged up fine, one slightly ahead of the other, with minimal export until first one then the other one filled up.

I think its inevitable that the batteries will charge at different rates, the array sizes are different and as I said they are aligned differently. Having different SoC's has never been an issue for me and I have never had any issues at all with the batteries cross charging each other until now overnight with predbat. I have gen 1 hybrid inverters and from what I read on the givenergy community forum, the other person with a gen 1 hybrid pair (Tim) also doesn't have cross charging issues, but gen 2 and gen 3 do. There was a suggested reason given for this, can't remember what it was, something to do with the gen 1 not taking account of the CT clamps the same as the gen 2 and 3 do.

I'll see how it operates during discharging for tonight and overnight. I am slightly concerned that if predbat keeps shutting the discharge rate off to get the batteries into alignment then I'm going to lose the ability to ramp discharging up to 2.6x2=5.2kW, e.g. when you put the oven or kettle on.

What does switch.predbat_balance_inverters_crosscharge do? I didn't really understand the readme entry "Is used to toggle on/off balancing when the batteries are cross charging" because there isn't a "cross charging mode", how would predbat know? Maybe if I do find that the balance_inverters_discharge does limit my discharge capability (causing more grid imports) I should only leave this switch on? Another option, is it possible to rework how predbat holds the current battery level during the offpeak period, e.g. setting different charge-to and battery reserve figures specific to each inverter as the common reserve/charge across the two inverters is what's causing the cross-charge

[springfall2008]

Balancing is usually for two matched batteries, I'm not sure if it makes a huge amount of sense in your case for the reasons you mentioned.

Cross charging is where one battery is discharging while the other is charging, and so one battery charges the other. This is known as the battery charge/discharge rate is reported via GivTCP.

What is the actual issue with the reserve setting, are you saying you don't want the same % on both - what should it be?

[gcoan]

The problem is, if you look at this screenshot, at 2am the 5.2 was at 38% SoC and the 9.5 at 25%. Then at 2am the reserve for both inverters is set to the same level and you can see that the 5.2 then discharges into the 9.5.

The 3rd October the batteries had run out so they both had to charge up to the reserve level, so not an issue that night

But the 2nd October very much the same behaviour as the 4th, the same reserve is being set on the two inverters which causes a cross charge

What I'm asking is whether the reserves could be set independently in some way to prevent the cross charge?

[springfall2008]

Ah yes, got it - so the quick workaround is to turn off 'set reserve'.

But yes, I can re-compute the reserves individually

[gcoan]

As I suspected might happen, as the sun is dropping this afternoon, the oven is on for the evening meal, as predbat tries to keep the two inverter SoC's balanced its chopping the G395 discharge rate down to zero and I'm getting spikes of 2kW imports occurring

I'll turn predbat_balance_inverters_discharge off

[springfall2008]

Yes, balance can be run say every 30 seconds but if you use more than one inverters power in the meantime it will take some time to re-enable it.

[gcoan]

After yesterday's testing to try to stop the overnight inverter cross charging issue I concluded (above) that balance inverters for charging and discharging both had side effects in terms of normal day-to-day inverter throughput that I didn't like so I left these both turned off. However balance inverters for cross charging was left turned on to see what happened overnight and see if this cured the problem.

I'd say it was a partially positive result. At 2am the 5.2 battery (inverter H) was exhausted but there was still 14% in the 9.5 (inverter G). Reserve soc was set to 17% by predbat:

I'd expect G to need to charge a little but not discharge (so G discharge rate to be set to zero), H to charge a lot (so H charge rate to remain on 2600).

G is set to charge throughout the period 2:00 to 2:30; apart from a brief 1 minute? period at 2:06 when the charging is stopped

H is charging from 2:00 and then starts getting chopped back at 2:11, which corresponds to the soc's coming closer together, which is probably right:

The one that doesn't look right is G's discharge rate. Even though we're in a cheap rate charging period (so grid import is OK) and G has a higher soc than H, G's discharge rate is never changed from 2600 which I would have thought it would need to do to prevent cross charging?

Despite this, I think it might be doing the right thing. If I look between G discharging, H charging and grid import, apart from a 'blip' at about 2:05, I see plenty of import from 2:00 to 2:10, I don't see G discharging and I see H charging throughout. Gets more complex from 2:10 to 2:15, lots of things changing on and off.

I tried to download the logfile but the earliest appdaemon.log.3 only starts at 3:45 so misses out this period. Have added log_generations: 6 to my logfile in appdaemon.yaml to try to capture things tomorrow morning

[springfall2008]

That's good to see it did something.

You could try changing the appdeamon log size (see below). It's worth making sure Predbat debug is turned off or it gets very big.

logs: main_log: filename: /config/appdaemon.log log_size: 10000000

[gcoan]

Had a look at what happened last night, this is with predbat 7.7 the updated main you suggested I try. I'll download the latest public version and leave that running tonight to see if its any different.

Unfortunately keeping 6 logfiles wasn't enough and when I look now at 5pm, the earliest log I have is 4am. I'll increase the logfile size as well.

In short I think its still cross charging. balance inverters is on, balance inverters for cross-charging is on, the other two balance (for charging and discharging) are both off because of the side effects noted above.

You can see that at just before the 2am cheap charging period, G soc is 24%, H is 5% and the target is bring the batteries to 20. We don't really want to discharge G, but we do want to charge H

Overall kwh soc drops over this period. I would have expected it to rise as H is being charged so this in itself is indicating cross charging

G discharge rate is set to 2600 throughout. Would have expected this to be dropped to prevent cross charging

The colours chosen by HA dont make this easy to see, but the lower blue line is import power, the upper bluey purple line is H charge power and the line green is G discharge power

So although there are pulses of import going on, they only reach 1kW, and all throughout G is discharging at much the same rate as H is charging from which I conclude that G is discharging into H - cross chrging

Final graph, same as above with H charge rate overlaid on top in Orange. This is curious because it shows that H's charge rate is being pulsed down and up every minute or so, which correspond to the import and H charging dropping of.

To bring the two batteries into balance and not cross charge I'd have expected G's discharge rate to be dropped to zero and H allowed to charge to the reserve soc set. Instead H's charge rate is being varied which looks to be the wrong inverter action

[springfall2008]

Good spot, there was a typo and your analysis was exactly correct

Can you please try the fix I made on main for this issue?

https://github.com/springfall2008/batpred/commit/405815c5922f02a4153aae8c746a771b44be7a26

[springfall2008]

Oh wait, I missed something, hold off

[springfall2008]

Okay, I've done one more pull request, I realised I forget to change the flag to reset discharge.

The other thing is I changed the charge balancing to account for PV generation, so that it doesn't turn off charge if the PV can't be stored with the other inverter/battery fully. This is to mirror the same thing as discharge does, the problem with discharge is that load can be spiky.

Let me know if it's any better.

[gcoan]

I've installed the latest main update and am just restarting my PC now (windows update to apply, so might as well do that). Will take a look tomorrow and see how it looks.

The other thing is I changed the charge balancing to account for PV generation, so that it doesn't turn off charge if the PV can't be stored with the other inverter/battery fully. This is to mirror the same thing as discharge does, the problem with discharge is that load can be spiky.

My particular issue is with inverter cross charging when a reserve SoC is set overnight in the cheap rate period and the inverters are out of balance. So in my case there won't be any solar PV generation to worry about. I'm assuming the change you made applies when charging balancing is turned on (which I don't have)? PV charging should in theory (if there's enough solar) balance the inverters out at 100% anyway

[gcoan]

I am BTW seeing some extra warning messages in the logfile

2023-10-08 20:07:15.006574 INFO pred_bat: BALANCE: Enabled balance charge False discharge False crosscharge True threshold charge 1.0 discharge 1.0
2023-10-08 20:07:18.295479 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_charge value 2600
2023-10-08 20:07:18.297117 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_discharge value 2600
2023-10-08 20:07:18.298960 INFO pred_bat: WARN: Out of range index 1 within item inverter_battery_rate_min value 0
2023-10-08 20:07:19.539726 INFO pred_bat: BALANCE: socs [61, 26] reserves [0.38, 0.21] battery_powers [887.0, 116.0] total 1003.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] pv_power [0.0, 0.0] total 5200.0 discharge_rates [2600.0, 2600.0] total 5200.0
2023-10-08 20:07:19.540813 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, True] below_full [True, True] can_power_house [True, True] can_store_pv [True, True] power_enough_discharge [True, True] power_enough_charge [False, False] soc_low [False, True] soc_high [True, False]
2023-10-08 20:07:19.542260 INFO pred_bat: BALANCE: Completed this run

[springfall2008]

I wouldn’t worry about the warning provided your battery rate is 2.6kw. I really must fix the warning…

[gcoan]

Yes it is 2.6kW.  Gen 1 hybrid inverters On 8 Oct 2023 at 20:46 +0100, Trefor Southwell @.***>, wrote:

I wouldn’t worry about the warning provided your battery rate is 2.6kw. I really must fix the warning… — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[gcoan]

Here's the logfile from this morning's activity at 2am. G's soc was 9% and H at 4% at the start, so both were below the reserve soc set at 32%. So slightly out of balance but both needed charging to reach reserve soc appdaemon.log

From 1:55 to 2:25 there was no change to the charge or discharge rates of either inverter, all were set to 2600 from 1:55 to 2:25

Inverter H has the smaller battery so it charges quickest, and its soc rises above G's (larger battery) at around 2:14.

The charging was as expected, G was discharging up to 2am (lime green) then from 2am nearly 6kw of import power (top blue line) and both inverters were charging at 2425w (not 2600w weirdly, but not really of consequence) - lower red and purple lines overlaid on each other

Looking at the next 30 minute slot, from 2:35 to 2:45 H's soc drops whilst G's continues to rise, which looks to me like a cross charge might be happening

G's discharge rate from 2:25 to 2:55 remains constant at 2600

The import power drops right off from 2:35 to 2:45

There's a brief dip in H's discharge rate, but only for 1 minute, but I'd have expected H's discharge rate to be set down to zero to stop H (higher soc) discharging into G (lower soc) when battery reserve is set to a value > current soc (meaning both batteries need to charge)

Overlaying G charge power (red line) with H discharge power (brown line) I can see there are corresponding peaks where G is charging when H is discharging and vice versa

Looks like G's charge rate is being throttled back in this period which is what we see in the prior graph when the charge and discharges go up and down. But since G's soc is lower than H's and both are < reserve soc, this doesn't seem quite right; both batteries need to charge but we don't want H (higher soc) to discharge into G during the process.

Another thought, as the soc's reach towards the reserve soc the charging will I believe naturally slow down. Looking at the soc's and power reserve over the full 3 hour flux period, the soc's never actually reach the reserve figure, its as if they decide that 'within a couple of % is close enough!'

[gcoan]

Another observation, may be unrelated or may be something else in this latest version, at the moment predbat hasn't selected to do a peak rate flux discharge this afternoon. The next planned discharge is tomorrow afternoon. This is leaving quite a lot of charge in the batteries overnight, which is just unusual. Today's PV forecast is 18kW, tomorrow's is 22kW, so tomorrow there will be more spare PV to fully recharge the batteries.

Will wait to see if it changes its mind later on

[springfall2008]

Thanks, did you manage to capture a log for the period where you had the cross charging?

For tonights discharge one cycle of the log (no need for debug) would be useful

[gcoan]

Yes the log file covering that period is at the top of that message. About a third of the way in. I’ve since dropped the log file size back down as they’re 7mb each now. If you can’t access it I can cut it down to just the 2-5am period

On 9 Oct 2023, at 11:58, Trefor Southwell @.***> wrote:

 Thanks, did you manage to capture a log for the period where you had the cross charging?

For tonights discharge one cycle of the log (no need for debug) would be useful

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[springfall2008]

Okay thanks, the log is pretty clear - the issue is when cross charging the overall balance seems to be discharging (not suprising due to AC loses) and so Predbat balances the wrong way around.

I think I can fix this by detecting if charging is enabled or not - I'll try to do a new version tonight.

2023-10-09 02:37:19.335748 INFO pred_bat: BALANCE: socs [23, 30] reserves [3.05, 1.67] battery_powers [-2424.0, 2602.0] total 178.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] pv_power [0.0, 0.0] total 5200.0 discharge_rates [2600.0, 2600.0] total 5200.0 2023-10-09 02:37:19.336594 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, True] below_full [True, True] can_power_house [True, True] can_store_pv [True, True] power_enough_discharge [False, True] power_enough_charge [True, False] soc_low [True, False] soc_high [False, True] 2023-10-09 02:37:19.338024 INFO pred_bat: BALANCE: Inverter 0 is cross charging during discharge, attempting to balance it 2023-10-09 02:37:19.339046 INFO pred_bat: Inverter 0 current charge rate is 2600 and new target is 0 2023-10-09 02:37:35.290206 INFO pred_bat: Inverter 0 set charge rate 0 via REST succesfull on retry 0 2023-10-09 02:37:35.293191 INFO pred_bat: BALANCE: Completed this run 2023-10-09 02:38:15.008463 INFO pred_bat: BALANCE: Enabled balance charge False discharge False crosscharge True threshold charge 1.0 discharge 1.0

Although one idea I did have is to just set the discharge rate to 0 during charge slots, that might fix it?

[gcoan]

I think I understand what you are saying, from

battery_powers [-2424.0, 2602.0] total 178.0

G (inverter 0) is charging and H (inverter 1) is discharging, but overall if you add the two together the overall power is positive, so discharging overall. But as you say there's energy losses on charging and discharging occurring that this simple power summation doesn't take account of.

The issue is presumably not the detection of the cross charging, which is done by the two inverters having different power rates? (And that on its own may not be 100% bulletproof, may need to consider PV power as well as I have seen before in the afternoons, one inverter charging off PV (west facing panels) and the other (east facing panels) discharging to meet house load)

The issue is deciding what to do about it once detected.

Might need to work through some different scenarios, eg:

• charging period, both below target soc (as happened last night)
• charging period, one above and one below target soc (happened the night before)
• not in a charging period but mis-aligned soc's and no solar PV
• not in a charging period, misaligned socs, solar pv on both
• not in a charging period, misaligned socs, solar pv on one

The third one probably the easiest, if the inverters are not trying to do a charge either because of a forced charge activity or the reserve soc being raised above current soc, then the inverters will sit there with misaligned socs and will just discharge to meet house load.

4th similarly simple, both will charge from solar pv and meet house load from the solar pv

In a charging period and freeze discharge is on (which it is for me), I'd expect to either be charging to reach target soc or holding the charge level and I wouldn't expect any discharging to be occurring. In the case of scenario 2, I would have expected the higher soc to remain high and the lower one charged to reserve. If discharging is enabled for the soc that's above reserve then it'll cross charge that one into the lower soc (as we have seen happen)

5th scenario just need to think about, it is legitimate for the inverter that has pv power to be charging from solar and the other one discharging to meet house load

[springfall2008]

I made a tweak on the last release that tries to go for turning off discharge to try to prevent cross charging during discharge (which we know is actually charge in this case). It maybe worth trying it out before looking at more detailed scenarios.

There maybe a better way to fix this at source with the charge % between the inverters or disabling discharge during the charge slots - I haven't had time to consider that yet.

[gcoan]

OK so I'll install the latest published release 7.7.4 and see what happens tonight.

I mentioned that predbat hadn't planned to do an octopus peak rate discharge for yesterday afternoon which surprised me as it has been doing one every day before. Well later on yesterday it did decide to do a peak rate discharge. I've also noticed that its doing peak rate freezes before the discharge, setting the battery charge rate to zero during the peak rate period to let any solar get exported rather than charging the battery and then having to discharge it later. In fact its just done that now at 4pm. Makes sense.

Are you aware there are some breaking deprecations to the Octopus integration that affect octopus_energy_electricity_XXX_current_rate that predbat uses? https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/discussions/444 Not sure if this impacts predbat so haven't installed it yet.

[springfall2008]

Thanks for the heads up about the Octopus plug, it's not that hard to change but will require another 2 apps.yaml entries which is annoying. I'm still wondering about bypassing it and going to the cloud service directly as an option...

[gcoan]

If you go directly to the cloud service you'll have to then include the octopus API key in predbat. One less integration for predbat to be dependent upon, balanced by the extra effort for you to have to understand and keep up with the octopus API as opposed to dealing with the changing Octopus integration. If you've got to make changes to adopt the new version then maybe its just as easy to move away from it. Swings and roundabouts

[springfall2008]

The changes aren't too complex, I'll add them of course. Longer term I wanted to try to make a cloud version of Predbat that can be run on a normal PC without Home Assistant, but that's probably next year...

[gcoan]

Here's the logfile covering the 2am-5am offpeak charging period thjis morning: appdaemon.log.1.txt

Looking at the SoC's and overall battery kwh, for the first half hour looks OK. At 2am H (inverter 1)'s soc was 4% and G was 18%, but both socs were below the reserve soc so both soc's rose as did the overall kwh soc - indicating both batteries were charging and G wasn't discharging into H.

Looking at the charge/discharge power, pretty much as expected. Up to 2am, G is discharging to support house load (lime green), then G (brown) and H (blue) start charging

Curiously at 2:01, G's discharge rate was set down to zero, and then back to 2600 Can see that in the charge power as well, tiny little blip of H discharging (red) and then that discharging stopping.

Something a bit weird in the logfiles, showing inverter 1 was detected as cross discharging during charge, then a minute later declared that inverter 1 is now balanced?

2023-10-11 02:00:44.065710 INFO pred_bat: BALANCE: Enabled balance charge False discharge False crosscharge True threshold charge 1.0 discharge 1.0
2023-10-11 02:00:47.199926 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_charge value 2600
2023-10-11 02:00:47.200921 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_discharge value 2600
2023-10-11 02:00:47.201851 INFO pred_bat: WARN: Out of range index 1 within item inverter_battery_rate_min value 0
2023-10-11 02:00:48.284780 INFO pred_bat: BALANCE: socs [18, 4] reserves [4.48, 2.45] battery_powers [-2190.0, 75.0] total -2115.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] pv_power [0.0, 0.0] load_power [991.0, 3410.0] total 5200.0 discharge_rates [2600.0, 2600.0] total 5200.0
2023-10-11 02:00:48.285573 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, False] below_full [True, True] can_power_house [True, True] can_store_pv [True, True] power_enough_discharge [False, True] power_enough_charge [True, False] soc_low [False, True] soc_high [True, False]
2023-10-11 02:00:48.286338 INFO pred_bat: BALANCE: Inverter 1 is cross discharging during charge, attempting to balance it
2023-10-11 02:00:48.287145 INFO pred_bat: Inverter 1 current discharge rate is 2600 and new target is 0
2023-10-11 02:01:07.362590 INFO pred_bat: Inverter 1 set discharge rate 0 via REST succesfull on retry 0
2023-10-11 02:01:07.368215 INFO pred_bat: BALANCE: Completed this run
2023-10-11 02:01:15.004269 INFO pred_bat: BALANCE: Enabled balance charge False discharge False crosscharge True threshold charge 1.0 discharge 1.0
2023-10-11 02:01:18.325528 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_charge value 2600
2023-10-11 02:01:18.326460 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_discharge value 2600
2023-10-11 02:01:18.327354 INFO pred_bat: WARN: Out of range index 1 within item inverter_battery_rate_min value 0
2023-10-11 02:01:19.369618 INFO pred_bat: BALANCE: socs [18, 4] reserves [4.48, 2.45] battery_powers [-2424.0, 0.0] total -2424.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] pv_power [0.0, 0.0] load_power [787.0, 3429.0] total 5200.0 discharge_rates [2600.0, 0.0] total 2600.0
2023-10-11 02:01:19.370416 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, False] below_full [True, True] can_power_house [True, True] can_store_pv [True, True] power_enough_discharge [False, False] power_enough_charge [True, False] soc_low [False, True] soc_high [True, False]
2023-10-11 02:01:19.371278 INFO pred_bat: BALANCE: Inverter 1 reset discharge rate to 2600.0 now balanced
2023-10-11 02:01:19.372177 INFO pred_bat: Inverter 1 current discharge rate is 0 and new target is 2600
2023-10-11 02:01:35.408349 INFO pred_bat: Inverter 1 set discharge rate 2600 via REST succesfull on retry 0
2023-10-11 02:01:35.427532 INFO pred_bat: BALANCE: Completed this run
2023-10-11 02:02:15.008474 INFO pred_bat: BALANCE: Enabled balance charge False discharge False crosscharge True threshold charge 1.0 discharge 1.0
2023-10-11 02:02:18.131649 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_charge value 2600
2023-10-11 02:02:18.136093 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_discharge value 2600
2023-10-11 02:02:18.137019 INFO pred_bat: WARN: Out of range index 1 within item inverter_battery_rate_min value 0
2023-10-11 02:02:19.207378 INFO pred_bat: BALANCE: socs [18, 5] reserves [4.48, 2.45] battery_powers [-2424.0, -2424.0] total -4848.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] pv_power [0.0, 0.0] load_power [3455.0, 3489.0] total 5200.0 discharge_rates [2600.0, 2600.0] total 5200.0
2023-10-11 02:02:19.208189 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, False] below_full [True, True] can_power_house [True, True] can_store_pv [True, True] power_enough_discharge [False, False] power_enough_charge [True, True] soc_low [False, True] soc_high [True, False]
2023-10-11 02:02:19.209025 INFO pred_bat: BALANCE: Completed this run
2023-10-11 02:03:15.003644 INFO pred_bat: BALANCE: Enabled balance charge False discharge False crosscharge True threshold charge 1.0 discharge 1.0
2023-10-11 02:03:18.122989 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_charge value 2600
2023-10-11 02:03:18.124325 INFO pred_bat: WARN: Out of range index 1 within item inverter_limit_discharge value 2600
2023-10-11 02:03:18.125227 INFO pred_bat: WARN: Out of range index 1 within item inverter_battery_rate_min value 0
2023-10-11 02:03:19.171445 INFO pred_bat: BALANCE: socs [19, 5] reserves [4.48, 2.45] battery_powers [-2424.0, -2424.0] total -4848.0 battery_max_rates [2600.0, 2600.0] charge_rates [2600.0, 2600.0] pv_power [0.0, 0.0] load_power [3465.0, 3497.0] total 5200.0 discharge_rates [2600.0, 2600.0] total 5200.0
2023-10-11 02:03:19.172245 INFO pred_bat: BALANCE: out_of_balance True above_reserve [True, False] below_full [True, True] can_power_house [True, True] can_store_pv [True, True] power_enough_discharge [False, False] power_enough_charge [True, True] soc_low [False, True] soc_high [True, False]
2023-10-11 02:03:19.173619 INFO pred_bat: BALANCE: Completed this run

The next half an hour follows the same, both soc's rising towards the reserve soc. But then from 2:56 to 3:06, H's soc dips as G's continues to rise and the overall soc kwh dips slightly as well

Through this period H's discharge rate remains on 2600 but at 2:57 and 2:59, G's discharge rate drops to zero for a minute and back again. Not sure this makes sense as both batteries should be charging (soc below reserve) and neither discharging at all

H's charge rate (the higher of the two socs) remains constant on 2600 but G's charge rate is dropped to zero (light blue) just after its discharge rate is dropped to zero (dark blue). Again not sure about this

Looking at G's charge power and H's discharge power, from 2:56 to 3:01, G is charging (gold brown) as H is discharging (red)

And overlaying import power can see a dip in import power (dark brown) at the same time

So net net I don't think the latest change in 7.7.4 is preventing the cross charging correctly.

[springfall2008]

I guess it kind of worked, but the problem is each time you stop the discharge then the cross charging goes away and then it puts discharge back and it resumes.

I think just turning off discharge during charging would be the best idea, I'll try to work something up for you to test on that soon?

[gcoan]

I don't know how well this will appear if I attach a photo to a github email response, but I've been looking at the battery soc alongside the target soc and inverter reported soc.  The battery soc is reported as just going over the reserve soc (whereas inverter soc always remains below). This appears to correspond to the inverter stopping charging of H and as G is still charging and the H battery is above target, it starts discharging of H.

I agree I can't think of any benefit of the batteries discharging during a charging period. Should turn off the discharge, I think it's the major cause of cross charging, either if one soc is above reserve at the beginning or it rises above reserve during the charging.  Home demand can be met from grid draw until such a point that predbat determines the batteries are sufficiently charged to see through to the next pv period and then presumably the charging period will stop. Yes happy to test the next iteration On 11 Oct 2023 at 09:48 +0100, Trefor Southwell @.***>, wrote:

I guess it kind of worked, but the problem is each time you stop the discharge then the cross charging goes away and then it puts discharge back and it resumes. I think just turning off discharge during charging would be the best idea, I'll try to work something up for you to test on that soon? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[springfall2008]

On 'main' I've added a new toggle 'switch.predbat_set_discharge_during_charge' if you turn this off then discharge will be disabled when charging is enabled. I'd be interested to see if this works.

The reason to allow discharge during charge slots is when the charge % is higher than the current battery level it will act as if the charge slot isn't present, this is normally useful for those with one nightly charge slot were the % is based on the minimum charge required but they don't always need the charge.

[gcoan]

Looks like the attachment I added to the emailed github reply didn't make it through. Oh well, wasn't significant.

I've downloaded main, restarted appdaemon, added the new switch to the dashboard and turned it off. Predbat is predicting to do a small overnight charge tonight (its another octopus power-up event tomorrow) so I'll have a look how this behaves in the morning. H's soc is currently 40% and G's 60% so its likely that H with the smaller battery will be lower than G come the night-time charge-up. I guess as I have dissimilar battery sizes I am more likely to get these kind of issues than people with more balanced battery sizes across their inverters. I would ideally have got 2x9kW but my installer wanted silly money for the batteries so I got a 5.2kW from them and then the 9.5 from ITS technologies (which the installer did fit, albeit wrongly with both batteries on one inverter and none on the second).

[gcoan]

The reason to allow discharge during charge slots is when the charge % is higher than the current battery level it will act as if the charge slot isn't present, this is normally useful for those with one nightly charge slot were the % is based on the minimum charge required but they don't always need the charge.

Yes I understand. Maybe a further optimisation to allow inverters to skip the charge (or at least carry on discharging to meet house load) would be to set the discharge off depending on soc vs target soc (but as noted earlier there is a question of which soc to check: battery or inverter soc). But thinking further, if the battery is already above target soc to remain "best" then wouldn't predbat just not set a charge period because it doesn't need one? i.e. is the charge period always just a function of rate or is it a function of rate and whether there is need for it or not?

[springfall2008]

When the charge slot is for a complete period eg Go night rate then the limit might be hit part the way through the slot. Right now Predbat notices this and instead sets the reserve to hold that level. In your case it’s more an issue when actually charging.

[gcoan]

Last night's run wasn't really conclusive. Although the socs were diverged quite a bit in the evening, by 1:40 they had both converged on 20%. Also the Octopus power-up event for today was causing predbat to not want to do much of a charge last night. In the later part of the evening it had (based on historical load) decided that the batteries would be exhausted by 2am so it wasn't even planning on doing a charge, but in the end it looked like the batteries didn't drop that much and instead the soc's were held at the reserve through the 2-5am period.

Interesting the reserve figure pulsed on and off with the soc being pretty much constant at the same value

The charge rates remained fixed at 2600 from 1 to 3:15 but at 2:25 the discharge rates were both dropped to zero

And the same 2:25, discharging both batteries ceased and it started importing from the grid to meet house demand

Same pattern for all of the 2-5am slot, soc's remaining flat, battery reserve's pulsing on and off, overall kwh soc bouncing around by 0.15kW

A few spikes of charging of one battery but import taking the load through the period, preserving the batteries.

Grey day today and the batteries almost exhausted at 5% by 10am before solar started charging them up again - so pretty accurate predbat prediction!

Here's the two logfiles that cover the overnight period. appdaemon.log.3.txt appdaemon.log.2.txt

Think will have to wait and see what happens tonight as both soc's were too close to the reserve this morning to see anything meaningful

[springfall2008]

Thanks for the update, sounds positive but lets see how it goes :)

[gcoan]

Sorry for no response yesterday, but I've got covid and didn't feel like anything. This morning (14th) something weird happened, one of the inverters didn't charge at all despite both batteries being flat. Can't see any reason for that so maybe it was just an inverter glitch. Its charging OK on solar.

Looking at the morning before, the 13th, H's soc was above target and G's soc was below so should have been a good test. Some pulsing up and down of the target soc on both inverters between 17% and 4% that I don't really understand:

Both inverter charge rates stayed at 2600 throughout.

And the discharge rates (purple and orange on the bottom graph) are pulsing up and down at the same time that the target soc (light blue on top graph) is changing:

This doesn't look right. Its as if its detecting there is cross charging, stopping it (e.g. 2:00 dropping the discharge rate and target soc for H and G), but then soon after setting it back again (e.g. 2:11 the discharge rates go back to 2600). This continues through the offpeak period

And if you look at the charge and discharge power, most of the time G (soc below target) is discharging with only occasional peaks (light brown) charging. There are spikes of H discharging a lot (red) but most of the time its just discharging a little, corresponding to the soc dropping over the period

I've got two other screen shots on my ipad to upload so will add those to a separate comment response as its a query on when the charge period is calculated.

Here's the logfiles from the evening of the 12th and morning of the 13th: appdaemon.log.8.txt 834/appdaemon.log.6.txt) appdaemon.log.7.txt [appdaemon.log.6.txt](https://github.com/springfall2008/batpred/files/12905

The above was all running on the main fork you asked me to test. Last night I installed the latest public version as I could see you'd made further enhancements. Around lunchtime some odd behaviour occurred. Both inverters were charging from solar PV, its nowhere near a charging or discharging period:

And just before and after 12, predbat drops H's discharge rate up and down several times. I looked at the logfile and can see that it thinks cross charging is going on

G and H were both charging OK. G (higher soc at this time) doesn't discharge at all (dark blue), but H (red) discharges a bit when the H's discharge rate is altered. It just did this around 12:00, before and after there was no inverventions

Logfile from this period appdaemon.log

[gcoan]

Ignore this part, I think I’ve figured out what the issue is with why I wasn’t getting nighttime charge predictions until last minute, and I’ll post a new issue to explain it once I’ve finished figuring out the solution…

Here’s the other two screenshots from my iPad.

The 12th was an overcast day and the batteries didn’t charge much and were predicting to run out overnight. At 21:40 predbat’s plan appeared not to be to do any charge in the cheap overnight period. The batteries would be allowed to drain, it would grid import all the way through to starting to get some reasonable solar generation at 10am. I was expecting for there to be a small cheap overnight charge sufficient to see the battery through to solar generation but the evening before it hadn’t planned this

Just after midnight I looked again and (no predbat settings changed) it had now decided to do the overnight charge that earlier it hadn’t. I thought it predicted 36 hours or so ahead?

logfile for this period in prior comment above