battery charge curve not being created by predbat

[gcoan]

Describe the bug Upgraded to 7.15.4 (after the crashes of 7.15.3 - thanks for the quick bugfix)

But the power curve is not created by predbat

getting the error pred_bat: Note: Can not find battery charge curve, one of the required settings for soc_kw, battery_power and charge_rate are missing from apps.yaml

Looking at apps.yaml, none of these are set because I am using givtcp_rest and so all the inverter controls are commented out, vis:

  # When set use the REST API rather than HA entity for control, should be more reliable/faster to control
  # Set one per inverter
  # If using Docker then change homeassistant.local to the Docker IP address
  givtcp_rest:
  # - 'http://homeassistant.local:6345'
   - 'http://homeassistant.local:6346'

  # If not using REST then instead set the Control here (one for each inverter)
  # - you can delete this section if using REST
  #charge_rate:
  #  - number.givtcp_{geserial}_battery_charge_rate
  #  - number.givtcp2_{geserial2}_battery_charge_rate
  #discharge_rate:
  #  - number.givtcp_{geserial}_battery_discharge_rate
  #  - number.givtcp2_{geserial2}_battery_discharge_rate
  #battery_power:
  #  - number.givtcp_{geserial}_battery_power
  #  - number.givtcp2_{geserial2}_battery_power
  #pv_power:
  #  - number.givtcp_{geserial}_pv_power
  #  - number.givtcp2_{geserial2}_pv_power
  #load_power:
  #  - number.givtcp_{geserial}_load_power
  #  - number.givtcp2_{geserial2}_load_power
  #soc_kw:
  #  - sensor.givtcp_{geserial}_soc_kwh
  #  - sensor.givtcp2_{geserial2}_soc_kwh

Expected behavior Battery curve created per new feature in 7.15.3/4

Predbat version 7.15.4

Environment details HAOS Gen 1 hybrid

[gcoan]

Here's the logfile appdaemon (22).log

Its still showing it as 2.4

but the sensor is changed:

so maybe the history is stored with the uom, which would be logical

[springfall2008]

I’ll have a go at pulling the units when I get time

[gcoan]

It’s not a top priority for me right now. Just as long as it doesn’t crash.Could always put in the charge curve as 100% then could go back to the main code stream if you don’t get to thisThanks On 31 Jan 2024, at 21:43, Trefor Southwell @.***> wrote: I’ll have a go at pulling the units when I get time

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[mpartington]

Just a query as keen to give a go now I've done a few full power charges. However, Not all charges are equal, I has a soc drop, so it spent ages faffing around to recalibrate the top limit next charge, which would throw the charge curve off. Since then I've done a few more typical charges, but what will predbat base the calculations on. Is it most recent data, or does it try and do some averaging across multiple runs?

[springfall2008]

There's a new version on MAIN that averages the data points across all charges, also accounts for units. Finally you can set the charge curve in apps.yaml to 'auto' and it will just use the computed one.

[gcoan]

I tried the new version @springfall2008 and it seems to work:

2024-02-01 11:22:59.488771 INFO pred_bat: Charge curve before adjustment is: {97: 25.350000000000005, 98: 0.98, 99: 0.98, 100: 0.98, 96: 29.140000000000008, 94: 31.000000000000007, 95: 31.000000000000007, 93: 0.98, 92: 29.40000000000001, 91: 31.36000000000001, 90: 30.38000000000001, 88: 29.66000000000001, 89: 29.66000000000001, 86: 29.40000000000001, 87: 0.98}
2024-02-01 11:22:59.490987 INFO pred_bat: Charge curve can be entered into apps.yaml or set to auto:
  battery_charge_power_curve:
    97 : 0.89
    96 : 0.93
    95 : 0.99
    94 : 0.99
    89 : 0.98
    88 : 0.98

This was with predbat configured to use all the direct givtcp controls.

I then changed apps.yaml to put it back into REST mode, but just left the battery_charge_rate, battery_power and soc_kwh set to the givtcp sensors (for the history) to see if this 'minimal config' worked, and it did, but it gave a different curve without the 88 or 89% datapoints:

2024-02-01 11:47:36.752957 INFO pred_bat: Charge curve before adjustment is: {97: 25.770000000000007, 98: 0.98, 99: 0.98, 100: 0.98, 96: 29.28000000000001, 94: 31.33000000000001, 95: 31.33000000000001, 93: 0.98, 92: 29.40000000000001, 91: 31.36000000000001, 90: 31.36000000000001, 88: 30.38000000000001, 89: 30.38000000000001, 86: 29.40000000000001, 87: 0.98}
2024-02-01 11:47:36.758043 INFO pred_bat: Charge curve can be entered into apps.yaml or set to auto:
  battery_charge_power_curve:
    97 : 0.91
    96 : 0.93
    95 : 0.97
    94 : 0.97

And I notice that neither have the full range of %'s that I see on my soc graph, including 100%!

I've just looked at a couple of my SoC graphs and on two charges to 100% today they went 90, 91, 92, 93, 95, 96, 97, 98, 98, 100

[springfall2008]

This is mostly as the values that are 1.0 aren't output, it seems your 98->100 is quicker than 97-98!

[mpartington]

Finally managed to try this. I've set to auto and it looks to be working well (hope this is correct battery_charge_power_curve: auto)

Generated curve: battery_charge_power_curve: 100 : 0.15 99 : 0.15 98 : 0.2 97 : 0.24 96 : 0.43 95 : 0.46 94 : 0.37 93 : 0.41 92 : 0.72 91 : 0.91 90 : 0.91

Only question is around the scaling: "Consider setting in HA: input_number.battery_max_rate_scaling: 0.91 - currently 1.0"

I understand for charging, but it you apply same logic for discharge then it will be >1. Won't setting this this mess the discharge estimations up?

[springfall2008]

Looks good

yeh the scaling is for both, I maybe should split out discharge scaling, I don’t know if both are the same or not

[mpartington]

I'm fairly sure they are not the same, so would need splitting. The Giv guys have confirmed a few times that the battery power is displayed in DC. So my 3kW Inverter only displays 2880W ish on charge, but say 3150 W on discharge

I've just forced it now

On Thu, 1 Feb 2024, 20:36 Trefor Southwell, @.***> wrote:

Looks good

yeh the scaling is for both, I maybe should split out discharge scaling, I don’t know if both are the same or not

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/666#issuecomment-1922201249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZQHXHICFZQJBHAYKVKXJXTYRP4EFAVCNFSM6AAAAABCQHWEISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRSGIYDCMRUHE . You are receiving this because you commented.Message ID: @.***>

[mpartington]

Mis sed screenshot

[springfall2008]

Ill try to split them out soon :)

[mpartington]

Thanks, these new features are amazing btw.

[gcoan]

This is mostly as the values that are 1.0 aren't output, it seems your 98->100 is quicker than 97-98!

I've just updated to the 7.15.10 release and it's produced a different curve, this time with 99 and 100

battery_charge_power_curve: 100 : 0.46 99 : 0.46 98 : 0.46 97 : 0.88 96 : 0.93 95 : 0.97 94 : 0.97 89 : 0.98 88 : 0.98

[springfall2008]

Maybe more sensible, now it’s averaging all data points

[dochtie]

Great features here. I changed to auto successfully but got a wildly different curve from the previous version.

Version 7.15.9 seems a lot more realistic.

91 : 1.0 92 : 0.95 93 : 0.82 94 : 0.7 95 : 0.57 96 : 0.44 97 : 0.32 98 : 0.19 99 : 0.19 100 : 0.19

Version 7.15.10

INFO pred_bat: Find charge curve has 22.0 days of data, max days 22 Charge automatically computed as: battery_charge_power_curve: 100 : 0.22 99 : 0.22 98 : 0.25 97 : 0.35 96 : 0.54 95 : 0.6 94 : 0.68 93 : 0.75 92 : 0.76 91 : 0.78 90 : 0.78 89 : 0.78 87 : 0.92 86 : 0.97 85 : 0.68

Q: if I leave on auto will it tweak as time goes on?

[mpartington]

An additional question to above... It you switch back to slow charge, will that artificially reduce the higher power (lower soc) points in auto,? As the charge rate is likely set below the point the BMS would limit

[springfall2008]

Auto isn’t going to work in low power mode as eventually there will be no data for charging at full rate

[gcoan]

If you set auto creation of the power curve does it cache it between runs as its quite resource intensive to create it from the history On 1 Feb 2024 at 22:20 +0000, Trefor Southwell @.***>, wrote:

Auto isn’t going to work in low power mode as eventually there will be no data for charging at full rate — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[dochtie]

How often will the auto curve calculation run? Would it just run on every initial load or it saving it somewhere and reading it? I’m thinking my battery is cold and performing poorly now but will behave differently as we head into warmer weather. So leaving on auto would be nice.

[springfall2008]

The curve is only computed once at startup, so it will update when you restart HA, restart appdaemon or update Predbat

[springfall2008]

There's an updated version on MAIN which has:

• Better charge curve calculation
• Support discharge curve calculation
• Separate max rate discharge control
• Fix input_number units in HA

If anyone fancies testing....

[mpartington]

I love how easy it is to update. Not found discharge curve for me. Will try to restart and try again

2024-02-02 19:25:17.070893 INFO pred_bat: Curve automatically computed as: battery_charge_power_curve: 100 : 0.15 99 : 0.15 98 : 0.2 97 : 0.29 96 : 0.43 95 : 0.43 94 : 0.42 93 : 0.52 92 : 0.77 91 : 0.86 90 : 0.91 89 : 0.91

2024-02-02 19:25:17.073758 INFO pred_bat: Saved computed battery charge power curve 2024-02-02 19:25:17.077204 INFO pred_bat: Find discharge curve with sensors sensor.givtcp_ce2146g269_soc_kwh and number.givtcp_ce2146g269_battery_discharge_rate and predbat.status and sensor.givtcp_ce2146g269_battery_power 2024-02-02 19:25:29.350933 INFO pred_bat: Find discharge curve has 15.0 days of data, max days 15 2024-02-02 19:25:29.493858 INFO pred_bat: Note: Can not find battery charge curve (no final curve), one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml

Is it because I don't have 15 days of 'Predbat status'? Still trying to build that back up

Edit... Have checked apps.yaml and all the necessary parameters appear to be there. A restart made no difference (same error)

Edit2... Guess this should be dis...charge curve in debug

2024-02-02 19:25:29.493858 INFO pred_bat: Note: Can not find battery charge curve (no final curve)

Edit 3 (lol)... No longer displaying the recommended battery charge scaling factor

Edit 4... Battery rate max scaling discharge will not take a number greater than 1 (Calculate mine to be 1.04)

[gcoan]

@springfall2008 I had just been making some documentation updates to explain the specific entities needed for history for the charge curve, and a new FAQ to explain the 'can't find' message

Since you're adding more features to this and probably need to update the docs for the changes. I'll create a PR so you can merge it in

[gcoan]

The version on main worked for me, created both charge and discharge curves:

2024-02-02 21:00:17.354896 INFO pred_bat: Find charge curve has 9.0 days of data, max days 9
2024-02-02 21:00:17.399087 INFO pred_bat: Curve before adjustment is: {97: 0.9190000000000003, 96: 0.916666666666667, 94: 0.963823529411765, 95: 0.963823529411765, 93: 0.98, 92: 0.9800000000000003, 91: 0.9800000000000003, 90: 0.9800000000000003, 88: 0.9800000000000003, 89: 0.9800000000000003, 86: 0.9800000000000003}
2024-02-02 21:00:17.403382 INFO pred_bat: Curve curve can be entered into apps.yaml or set to auto:
  battery_charge_power_curve:
    100 : 0.94
    99 : 0.94
    98 : 0.94
    97 : 0.94
    96 : 0.94
    95 : 0.98
    94 : 0.98

2024-02-02 21:00:17.406463 INFO pred_bat: Consider setting in HA: input_number.battery_rate_max_scaling: 0.98 - currently 1.0
2024-02-02 21:00:17.408427 INFO pred_bat: Find discharge curve with sensors sensor.h_sd2237g395_soc_kwh and number.h_sd2237g395_battery_discharge_rate and predbat.status and sensor.h_sd2237g395_battery_power
2024-02-02 21:00:30.655643 INFO pred_bat: Find discharge curve has 9.0 days of data, max days 9
2024-02-02 21:00:30.695122 INFO pred_bat: Curve before adjustment is: {7: 1.0, 8: 1.0, 10: 0.99875, 9: 0.99875, 11: 1.0, 13: 0.9937037037037036, 12: 1.0, 14: 1.0, 16: 1.0, 15: 1.0, 18: 1.0, 19: 1.0}
2024-02-02 21:00:30.697627 INFO pred_bat: Curve curve can be entered into apps.yaml or set to auto:
  battery_charge_power_curve_discharge:
    20 : 1.0
    13 : 0.99

(although the discharge curve is a bit weird)

@mpartington I uncommented: discharge_rate:

• number.givtcp_{geserial}_battery_discharge_rate

As I'm using REST mode otherwise. Had the same issue on charge curve not working so guessed I needed this (and soc_kw and battery_power) uncommented

[springfall2008]

Interesting it’s saying your max charge rate is 0.98 when mine is 0.95. Discharge seems to be full power ok the GE systems so no curve

[mpartington]

I've just left all of mine uncommented, it doesn't seem to affect REST mode anyway. I wonder if my issue is I only have about 8 days of predbat.status and 15 days of the others as I was purging predbat history more frequently

[gcoan]

This is with a gen 1 hybrid with a 5.2 battery, you have a 9.5 don't you @springfall2008 ?

I have noticed it tends to charge at 2.4 and discharge at 2.6

@mpartington ah maybe. I've not put any effort into pruning the HA history in any intelligent way

[springfall2008]

I keep a full 30 days of evening with no issues, but then again my setup is a quad processor amd desktop pc with a large SSD drive and 16gb of ram

[gcoan]

think of the power being burnt !

I increased my history slightly but not that much, was wary of doing so as I think the size of the history might have been a cause of the corruption I had in HA last year. Every time I tried applying a HA update or the overnight db housekeeping ran, HA would decide the db was corrupt and in the end I had to abandon it and start again.

I think I might need to start purging more or increase the virtual disk size as I just checked and its 83% full.

[springfall2008]

It’s way more efficient to have a HAOS native install, all these VMs add overhead

[gcoan]

It’s way more efficient to have a HAOS native install, all these VMs add overhead

Yeah maybe, but it works, and I quite like being able to use the rest of the PC to have windows open on github, HA, etc. Means I don't have to have another PC open. Although re-remembering how to use Microsoft Windows after a number of Mac years has been a pain.

[mpartington]

From tonights data

AC3 = 3Kw (AC) Nominal Charging = 2865W (DC - post losses) = 0.95 Max Discharge = 3145W (DC - needs higher discharge power to achieve 3kW AC) = 1.05 Max

[springfall2008]

@mpartington for AC coupled this seems correct, and now you can tune the charge and discharge rate max with their own settings to calibrate

[mpartington]

Latest version is giving me a very different charge curve. Is it now auto applying the battery scaling, as seeing 0.99, which seems impossible. It is very consistent between runs. I have selected auto mode in apps.yaml

2024-02-04 06:32:42.955983 INFO pred_bat: Find charge curve has 15.0 days of data, max days 15 2024-02-04 06:32:43.092702 INFO pred_bat: Curve before adjustment is: {99: 0.15, 98: 0.195, 97: 0.29000000000000004, 96: 0.43, 95: 0.505, 94: 0.4566666666666667, 93: 0.48666666666666675, 92: 0.72, 91: 0.82, 89: 1.0, 90: 1.0, 87: 1.0, 86: 0.99} 2024-02-04 06:32:43.097241 INFO pred_bat: Curve automatically computed as: battery_charge_power_curve: 100 : 0.15 99 : 0.15 98 : 0.2 97 : 0.29 96 : 0.43 95 : 0.51 94 : 0.46 93 : 0.49 92 : 0.72 91 : 0.82 86 : 0.99 85 : 0.99

2024-02-04 06:32:43.101528 INFO pred_bat: Consider setting in HA: input_number.battery_rate_max_scaling: 1.0 - currently 0.91