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

[springfall2008]

Unfortunately REST doesn’t provide any history so the fix is just to comment these back in. I probably need to change the documentation to say that

[gcoan]

OK, I didn't appreciate that, yes to update the documentation to make it clearer

[PianSom]

I moved my apps.yaml from REST back to non-REST.

Got the following logs, which seem odd:

2024-01-30 10:16:09.841222 INFO pred_bat: Find charge curve with sensors sensor.givtcp_ch2316g275_soc_kwh and number.givtcp_ch2316g275_battery_charge_rate and predbat.status and sensor.givtcp_ch2316g275_battery_power
2024-01-30 10:16:29.982225 INFO pred_bat: Find charge curve has 15.0 days of data, max days 15
2024-01-30 10:16:30.009718 INFO pred_bat: Note: Found incomplete battery charging curve, maybe try again when you have more data.

How much history is needed?

Also, I have an AIO and the soc_kwh returned by GivTCP is 15.96kWh, but the useable power is (as I understand it) 13.58kWh - will this cause issues?

[gcoan]

Its not working for me either.

I uncommented out the three non-rest lines the charge curve needs:

charge_rate:
    - number.h_{geserial}_battery_charge_rate
  battery_power:
    - number.h_{geserial}_battery_power
  soc_kw:
    - sensor.h_{geserial}_soc_kwh

2024-01-30 10:28:40.623482 INFO pred_bat: Find charge curve with sensors sensor.h_sd2237g395_soc_kwh and number.h_sd2237g395_battery_charge_rate and predbat.status and sensor.h_sd2237g395_battery_power
2024-01-30 10:28:55.283062 INFO pred_bat: Find charge curve has 9.0 days of data, max days 9
2024-01-30 10:28:55.300701 INFO pred_bat: Note: Can not find battery charge curve, one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml

This is a slightly different error message from when I didn't have the sensors uncommented

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

And I have a 5.2 battery with 80% DoD that reports as 5.22. I have battery_scaling set to 0.8, assume that will be taken account of?

[springfall2008]

It's probably a bug related to the battery scaling, I'll try to make a fix

[springfall2008]

Please can you re-test on MAIN?

[PianSom]

Looks good, Trefor.

I commented the REST setting s and uncommented the others. For my AIO I got the following -
2024-01-30 18:26:24.122216 INFO pred_bat: Charge curve can be entered into apps.yaml:
battery_charge_power_curve:
100 : 0.19
99 : 0.19
98 : 0.19
97 : 0.45
96 : 0.57
95 : 0.57
94 : 0.7
93 : 0.82
92 : 0.95

So I will now go and do exactly that.

[PianSom]

Also, the next line was

 INFO pred_bat: Consider setting in HA: input_number.battery_max_rate_scaling: 1.0

Given that you suggested here that I put it at 0.85, should I ignore this suggestion?

[springfall2008]

I’d comment that REST back in, you don’t need to disable it you just needed the sensors to be set.

battery rate max scaling is the charge rate scaling

I think you are confusing this with battery scaling ?

[PianSom]

Yes, I reverted when I put the charge curve in, thanks.

And yes, about battery scaling. What should I be having as 0.85? Should it be the UI element called "Metric Battery Value Scaling" (which I think is input_number.predbat_battery_value_scaling?

(Someone who was stupid could get confused around here! :) )

[gcoan]

I tried the version on main, it looks as if it tried but still didn't work, sorry

2024-01-30 19:22:29.911807 INFO pred_bat: Find charge curve with sensors sensor.h_sd2237g395_soc_kwh and number.h_sd2237g395_battery_charge_rate and predbat.status and sensor.h_sd2237g395_battery_power
2024-01-30 19:22:57.583016 INFO pred_bat: Find charge curve has 9.0 days of data, max days 9
2024-01-30 19:22:57.591039 INFO pred_bat: Note: Can not find battery charge curve, one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml
2024-01-30 19:22:57.595890 INFO pred_bat: Found 1 inverters totals: min reserve 0.17 current reserve 0.21 soc_max 4.18 soc 0.17 charge rate 2.6 kW discharge rate 2.6 kW battery_rate_min 0.0 w ac limit 5.0 export limit 5.0 kW loss charge 5 % loss discharge 5 % inverter loss 3 %
2024-01-30 19:22:57.687054 INFO pred_bat: Base charge    window [  ]

appdaemon (16).log

my apps.yaml:

pred_bat:
  module: predbat
  class: PredBat

  # Import rates can be overridden with rate_import_override
  # Export rates can be overridden with rate_export_override
  # Use the same format as above, but a date can be included if it just applies for a set day (e.g. Octopus power ups)
  # This will override even the Octopus plugin rates if enabled
  #
  rates_import_override:
    -  date: '2024-01-25'
       start: '21:00:00'
       end: '23:30:00'
       rate: 0
    -  date: '2024-01-28'
       start: '10:00:00'
       end: '13:00:00'
       rate: 0
       
  # Days previous is the number of days back to find historical load data
  # Recommended is 7 to capture day of the week but 1 can also be used
  # if you have more history you could use 7 and 14 (in a list) but the standard data in HA only lasts 10 days
  days_previous:
    - 2
    - 3
    - 4
    - 5
    - 6
    - 7
    - 8

  # Days previous weight can be used to control the weighting of the previous load points, the values are multiplied by their
  # weights and then divided through by the total weight. E.g. if you used 1 and 0.5 then the first value would have 2/3rd of the weight and the second 1/3rd
  # Include one value for each days_previous value, each weighting on a separate line.
  # If any days_previous's that are not given a weighting they will assume a default weighting of 1.
  days_previous_weight:
    - 1
  
    # Sets the prefix for all created entities in HA - only change if you want to run more than once instance
  prefix: predbat

  # Timezone to work in
  timezone: Europe/London

  # XXX: This is a configuration template, delete this line once you edit your configuration
  # template: True

  # Set to auto-match with a GivEnergy serial number, but you can override the serial or the sensor names
  # if it doesn't work or if you have more than one inverter you will need to list both
  geserial: 're:sensor.h_(.+)_soc_kwh'
  # geserial2: 're:sensor.givtcp2_(.+)_soc_kwh'

  # Sets the maximum period of zero load before the gap is filled, default 30 minutes
  # To disable set it to 1440
  load_filter_threshold: 30
  
  #
  # Sensors, more than one can be specified and they will be summed up automatically
  #
  # For two inverters the load today would normally be the master load sensor only (to cover the entire house)
  # If you have three phase and one inverter per phase then you would need three load sensors
  #
  # For pv_today if you have multiple solar inverter inputs then you should include one entry for each inverter
  #  
  load_today:
    - sensor.calc_house_load_today_5_mins
  #  - sensor.h_{geserial}_load_energy_today_kwh
  import_today:
    - sensor.h_{geserial}_import_energy_today_kwh
  export_today:
    - sensor.h_{geserial}_export_energy_today_kwh
  pv_today:
    - sensor.h_{geserial}_pv_energy_today_kwh

  # Load forecast can be used to add to the historical load data (heat-pump)
  # To link to Predheat
  # Data must be in the format of 'last_updated' timestamp and 'energy' for incrementing kWh
  #load_forecast:
  #  - predheat.heat_energy$external
  #
  # If you enable ge_cloud_data then the load/import and export data will be fetches from the GE cloud instead of from GivTCP sensors
  # this is usually less efficient and of course prone to internet downtime, but could be useful if you lost your GivTCP data
  # Set the serial to the inverter serial to pull the data from and the key to your API key
  # When this is set load_today, import_today and export_today are not used
  #
  ge_cloud_data: False
  # ge_cloud_serial: '{geserial}'
  # ge_cloud_key: 'xxxx'
  #
  # Controls/status - must by 1 per inverter
  #
  num_inverters: 1
  #
  # Run balance inverters every N seconds (0=disabled) - only for multi-inverter
  balance_inverters_seconds: 60
  #
  # 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.h_{geserial}_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.h_{geserial}_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.h_{geserial}_soc_kwh
  #soc_max:
  #  - sensor.givtcp_{geserial}_battery_capacity_kwh
  #  - sensor.givtcp2_{geserial2}_battery_capacity_kwh
  #reserve:
  #  - number.givtcp_{geserial}_battery_power_reserve
  #  - number.givtcp2_{geserial2}_battery_power_reserve
  #inverter_mode:
  # - select.givtcp_{geserial}_mode
  # - select.givtcp2_{geserial2}_mode
  #inverter_time:
  # - sensor.givtcp_{geserial}_invertor_time
  # - sensor.givtcp2_{geserial2}_invertor_time
  #charge_start_time:
  # - select.givtcp_{geserial}_charge_start_time_slot_1
  # - select.givtcp2_{geserial2}_charge_start_time_slot_1
  #charge_end_time:
  # - select.givtcp_{geserial}_charge_end_time_slot_1
  # - select.givtcp2_{geserial2}_charge_end_time_slot_1
  #charge_limit:
  # - number.givtcp_{geserial}_target_soc
  # - number.givtcp2_{geserial2}_target_soc
  #scheduled_charge_enable:
  # - switch.givtcp_{geserial}_enable_charge_schedule
  # - switch.givtcp2_{geserial2}_enable_charge_schedule
  #scheduled_discharge_enable:
  # - switch.givtcp_{geserial}_enable_discharge_schedule
  # - switch.givtcp2_{geserial2}_enable_discharge_schedule
  #discharge_start_time:
  # - select.givtcp_{geserial}_discharge_start_time_slot_1
  # - select.givtcp2_{geserial2}_discharge_start_time_slot_1
  #discharge_end_time:
  # - select.givtcp_{geserial}_discharge_end_time_slot_1
  # - select.givtcp2_{geserial2}_discharge_end_time_slot_1

  # Inverter max AC limit (one per inverter). E.g for a 3.6kw inverter set to 3600
  # If you have a second inverter for PV only please add the two values together
  inverter_limit:
   - 5000
  # - 5000

  # Export limit is a software limit set on your inverter that prevents exporting above a given level
  # When enabled Predbat will model this limit
  #export_limit:
  # - 3600
  # - 3600

  # Some inverters don't turn off when the rate is set to 0, still charge or discharge at around 200w
  # The value can be set here in watts to model this (doesn't change operation)
  #inverter_battery_rate_min:
  #  - 200

  # Workaround to limit the maximum reserve setting, some inverters won't allow 100% to be set
  # inverter_reserve_max : 99

  # Some batteries tail off their charge rate at high soc%
  # enter the charging curve here as a % of the max charge rate for each soc percentage.
  # the default is 1.0 (full power)
  # The example below is from GE 9.5kwh battery with latest firmware and gen1 inverter
  #battery_charge_power_curve:
  #  91 : 0.91
  #  92 : 0.81
  #  93 : 0.71
  #  94 : 0.62
  #  95 : 0.52
  #  96 : 0.43
  #  97 : 0.33
  #  98 : 0.24
  #  99 : 0.24
  #  100 : 0.24

  # Inverter clock skew in minutes, e.g. 1 means it's 1 minute fast and -1 is 1 minute slow
  # Separate start and end options are applied to the start and end time windows, mostly as you want to start late (not early) and finish early (not late)
  # Separate discharge skew for discharge windows only
  inverter_clock_skew_start: 0
  inverter_clock_skew_end: 0
  inverter_clock_skew_discharge_start: 0
  inverter_clock_skew_discharge_end: 0

  # Clock skew adjusts the Appdaemon time
  # This is the time that Predbat takes actions like starting discharge/charging
  # Only use this for workarounds if your inverter time is correct but Predbat is somehow wrong (AppDaemon issue)
  # 1 means add 1 minute to AppDaemon time, -1 takes it away
  clock_skew: 0

  # Set these to match solcast sensor names
  # The regular expression (re:) makes the solcast bit optional
  # If these don't match find your own names in Home Assistant
  pv_forecast_today: re:(sensor.(solcast_|)(pv_forecast_|)today)
  pv_forecast_tomorrow: re:(sensor.(solcast_|)(pv_forecast_|)tomorrow)
  pv_forecast_d3: re:(sensor.(solcast_|)(pv_forecast_|)(day_3|d3))
  pv_forecast_d4: re:(sensor.(solcast_|)(pv_forecast_|)(day_4|d4))

  # car_charging_energy defines an incrementing sensor which measures the charge added to your car
  # is used for car_charging_hold feature to filter out car charging from the previous load data
  # Automatically set to detect Wallbox and Zappi, if it doesn't match manually enter your sensor name
  # Also adjust car_charging_energy_scale if it's not in kwH to fix the units
  #car_charging_energy: 're:(sensor.myenergi_zappi_[0-9a-z]+_charge_added_session|sensor.wallbox_portal_added_energy)'

  # Defines the number of cars modelled by the system, set to 0 for no car
  num_cars: 0

  # car_charging_planned is set to a sensor which when positive indicates the car will charged in the upcoming low rate slots
  # This should not be needed if you use Intelligent Octopus slots which will take priority if enabled
  # The list of possible values is in car_charging_planned_response
  # Auto matches Zappi and Wallbox, or change it for your own
  # One entry per car
  #car_charging_planned:
  #  - 're:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)'

  #car_charging_planned_response:
  #  - 'yes'
  #  - 'on'
  #  - 'true'
  #  - 'connected'
  #  - 'ev connected'
  #  - 'charging'
  #  - 'paused'
  #  - 'waiting for car demand'
  #  - 'waiting for ev'
  #  - 'scheduled'
  #  - 'enabled'
  #  - 'latched'
  #  - 'locked'
  #  - 'plugged in'

  # In some cases car planning is difficult (e.g. Ohme with Intelligent doesn't report slots)
  # The car charging now can be set to a sensor to indicate the car is charging and to plan
  # for it to charge during this 30 minute slot
  #car_charging_now:
  #  - off

  # Positive responses for car_charging_now
  #car_charging_now_response:
  #  - 'yes'
  #  - 'on'
  #  - 'true'

  # To make planned car charging more accurate, either using car_charging_planned or the Octopus Energy plugin,
  # specify your battery size in kwh, charge limit % and current car battery soc % sensors/values.
  # If you have Intelligent Octopus the battery size and limit will be extracted from the Octopus Energy plugin directly.
  # Set the car SOC% if you have it to give an accurate forecast of the cars battery levels.
  # One entry per car if you have multiple cars.
  #car_charging_battery_size:
  #  - 75
  #car_charging_limit:
  #  - 're:number.tsunami_charge_limit'
  #car_charging_soc:
  #  - 're:sensor.tsunami_battery'

  # If you have Octopus intelligent, enable the intelligent slot information to add to pricing
  # Will automatically disable if not found, or comment out to disable fully
  # When enabled it overrides the 'car_charging_planned' feature and predict the car charging based on the intelligent plan (unless octopus intelligent charging is False)
  # This matches either the intelligent slot from the Octopus Plugin or from the Intelligent plugin
  #octopus_intelligent_slot: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)'
  #octopus_ready_time: 're:(time.octopus_energy([0-9a-z_]+|)_intelligent_ready_time)'
  #octopus_charge_limit: 're:(number.octopus_energy([0-9a-z_]+|)_intelligent_charge_limit)'
  
  # Octopus saving session points to the saving session Sensor in the Octopus plugin, when enabled saving sessions will be at the assumed
  # Rate is read automatically from the add-in and converted to pence using the conversion rate below (default is 8)
  octopus_saving_session: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_saving_session(s|))'
  octopus_saving_session_octopoints_per_penny: 8
  
  # Energy rates
  # Please set one of these three, if multiple are set then Octopus is used first, second rates_import/rates_export and latest basic metric

  # Set import and export entity to point to the Octopus Energy plugin import and export sensors
  # automatically matches your meter number assuming you have only one (no need to edit the below)
  # Will be ignored if you don't have the sensor but will error if you do have one and it's incorrect
  # NOTE: To get detailed energy rates you need to go in and manually enable the following events in HA
  #       event.octopus_energy_electricity_xxxxxxxx_previous_day_rates
  #       event.octopus_energy_electricity_xxxxxxxx_current_day_rates
  #       event.octopus_energy_electricity_xxxxxxxx_next_day_rates
  # and if you have export enable:
  #       event.octopus_energy_electricity_xxxxxxxx_export_previous_day_rates
  #       event.octopus_energy_electricity_xxxxxxxx_export_current_day_rates
  #       event.octopus_energy_electricity_xxxxxxxx_export_next_day_rates
  # Predbat will automatically find the event. entities from the link below to the sensors
  metric_octopus_import: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_rate)'
  metric_octopus_export: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_export_current_rate)'

  # Standing charge in pounds, can be set to a sensor or manually entered (e.g. 0.50 is 50p)
  # The default below will pick up the standing charge from the Octopus Plugin
  # The standing charge only impacts the cost graphs and doesn't change the way Predbat plans
  # If you don't want to show the standing charge then just delete this line or set to zero
  # metric_standing_charge: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_standing_charge)'
  metric_standing_charge: 0

  # Or set your actual rates across time for import and export
  # If start/end is missing it's assumed to be a fixed rate
  # Gaps are filled with zero rate
  #rates_import:
  #  -  start: "00:30:00"
  #     end: "04:30:00"
  #     rate: 7.5
  #  -  start: "04:30:00"
  #     end: "00:30:00"
  #     rate: 40.0
  #
  #rates_export:
  #  -  rate: 4.2

  # Can be used instead of the plugin to get import rates directly online
  # Overrides metric_octopus_import and rates_import
  # rates_import_octopus_url : "https://api.octopus.energy/v1/products/FLUX-IMPORT-23-02-14/electricity-tariffs/E-1R-FLUX-IMPORT-23-02-14-A/standard-unit-rates"
  # rates_import_octopus_url : "https://api.octopus.energy/v1/products/AGILE-FLEX-BB-23-02-08/electricity-tariffs/E-1R-AGILE-FLEX-BB-23-02-08-A/standard-unit-rates"

  # Overrides metric_octopus_export and rates_export
  # rates_export_octopus_url: "https://api.octopus.energy/v1/products/FLUX-EXPORT-BB-23-02-14/electricity-tariffs/E-1R-FLUX-EXPORT-BB-23-02-14-A/standard-unit-rates"
  # rates_export_octopus_url: "https://api.octopus.energy/v1/products/AGILE-OUTGOING-BB-23-02-28/electricity-tariffs/E-1R-AGILE-OUTGOING-BB-23-02-28-A/standard-unit-rates/"
  # rates_export_octopus_url: "https://api.octopus.energy/v1/products/OUTGOING-FIX-12M-BB-23-02-09/electricity-tariffs/E-1R-OUTGOING-FIX-12M-BB-23-02-09-A/standard-unit-rates/"



  # For pv estimate, leave blank for central estimate, or add 10 for 10% curve (worst case) or 90 or 90% curve (best case)
  # If you use 10 then disable pv_metric10_weight below
  # pv_estimate: 10

  # Number of hours forward to forecast, best left as-is unless you have specific reason
  forecast_hours: 48

  # Specify the devices that notifies are sent to, the default is 'notify' which goes to all
  #notify_devices:
  #  - mobile_app_treforsiphone12_2

  # Battery scaling makes the battery smaller (e.g. 0.9) or bigger than its reported
  # If you have an 80% DoD battery that falsely reports it's kwh then set it to 0.8 to report the real figures
  battery_scaling: 0.8

  # Can be used to scale import and export data, used for workarounds
  import_export_scaling: 1.0

  # Export triggers:
  # For each trigger give a name, the minutes of export needed and the energy required in that time
  # Multiple triggers can be set at once so in total you could use too much energy if all run
  # Creates an entity called 'binary_sensor.predbat_export_trigger_<name>' which will be turned On when the condition is valid
  # connect this to your automation to start whatever you want to trigger
  #export_triggers:
  #   - name: 'large'
  #     minutes: 60
  #     energy: 1.0
  #   - name: 'small'
  #     minutes: 15
  #     energy: 0.25

  # If you have a sensor that gives the energy consumed by your solar diverter then add it here
  # this will make the predictions more accurate. It should be an incrementing sensor, it can reset at midnight or not
  # It's assumed to be in Kwh but scaling can be applied if need be
  #iboost_energy_today: 'sensor.xxxxx'
  #iboost_energy_scaling: 1.0

  # Nordpool market energy rates
  futurerate_url: 'https://www.nordpoolgroup.com/api/marketdata/page/325?currency=GBP'
  futurerate_adjust_import: True
  futurerate_adjust_export: False
  futurerate_peak_start: "16:00:00"
  futurerate_peak_end: "19:00:00"
  futurerate_peak_premium_import: 14
  futurerate_peak_premium_export: 6.5

[PianSom]

Geoffrey - I commented out my equivalent of your

  givtcp_rest:
  # - 'http://homeassistant.local:6345'
   - 'http://homeassistant.local:6346'

and then uncommented ALL of the sensors in section below. That seemed to do the trick.

(I then reverted to the original versions.)

[gcoan]

Thanks @PianSom
Its strange that the log file shows that the settings I made to uncomment out the specific non-rest sensors that the charge curve needs are being picked up, and it looks to try to get the curve data.
As much as anything else would like to get to the minimum set of instructions we have to give to Predbat users to get the charge curve created. So hence why I only uncommented the 3 specific lines (and I had to change them to match my givtcp setup, so trying to avoid doing this x lots!)

[springfall2008]

Yes, I reverted when I put the charge curve in, thanks.

And yes, about battery scaling. What should I be having as 0.85? Should it be the UI element called "Metric Battery Value Scaling" (which I think is input_number.predbat_battery_value_scaling?

(Someone who was stupid could get confused around here! :) )

No battery_scaling is in apps.yaml and that controls the reported battery size, e.g. 0.85 would scale your battery size down by 15%

[springfall2008]

@gcoan I don't really understand your setup, but can you charge the four entities it mentions in the logfile in the charge curve section and show a period where the battery goes from 90% to 100%?

[gcoan]

@springfall2008 the apps.yaml is a bit of a mess because I have two inverters but at the moment only 1 has a working battery, so I commented out inverter 1 leaving inverter 2 now as the only inverter that predbat knows about and manages

my givtcp prefixes for the inverters are g_ and h_ (rather than givtcp and givtcp2_)

I believe I have apps.yaml set correctly, but happy to be corrected !

The first message appears to show that predbat has at least found all the required entities for the charge curve:
2024-01-30 19:22:29.911807 INFO pred_bat: Find charge curve with sensors sensor.h_sd2237g395_soc_kwh and number.h_sd2237g395_battery_charge_rate and predbat.status and sensor.h_sd2237g395_battery_power

The error message is:
2024-01-30 19:22:57.591039 INFO pred_bat: Note: Can not find battery charge curve, one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml

In apps.yaml, skipping all the commented out lines for inverter 1 which isn't configured at the moment in predbat:

  charge_rate:
    - number.h_{geserial}_battery_charge_rate
  battery_power:
    - number.h_{geserial}_battery_power
  soc_kw:
    - sensor.h_{geserial}_soc_kwh

and predbat.status is of course already defined in HA

Here's the 4 sensors from 12:50 to 13:15 today when the battery was being charged to 100%

[springfall2008]

Interesting, I think I know what the issue might be - I suspect not all %'s are represented in your battery size? Maybe I could allow some gaps and fill them...

[springfall2008]

That said you don't seem to have a curve anyhow!

[springfall2008]

@gcoan please try the updated version on MAIN which might fix it or at least give more debug info if not

[gcoan]

@springfall2008 I upgraded to main but the error looked the same

2024-01-30 21:22:18.230267 INFO pred_bat: Find charge curve with sensors sensor.h_sd2237g395_soc_kwh and number.h_sd2237g395_battery_charge_rate and predbat.status and sensor.h_sd2237g395_battery_power
2024-01-30 21:22:36.250591 INFO pred_bat: Find charge curve has 9.0 days of data, max days 9
2024-01-30 21:22:36.324883 INFO pred_bat: Note: Can not find battery charge curve, one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml

so turned debug on and then restarted appdaemon

TBH the log looks the same to me?
appdaemon (17).log

[gcoan]

That said you don't seem to have a curve anyhow!

yea that's weird, because if I look at these sensors for a time period 2 days ago and re-do the screen shots that I put on #650 there is a charge curve!

[springfall2008]

@gcoan can you re-run with an extra debug line:

            data_point = 99
            for minute in range(0, min_len):
                if (minute % 60) == 0:
                    self.log("Minute {} soc {}% soc_kwh {} soc_max {} status {} charge_rate {} battery_power {}".format(minute, soc_percent.get(minute, 0), soc_kwh.get(minute, 0),self.soc_max, predbat_status[minute], charge_rate[minute], battery_power[minute]))
                if soc_percent.get(minute, 0) == data_point and predbat_status[minute] == "Charging" and charge_rate[minute] == max_power and battery_power[minute] <= 0:

The if and the self.log line between the for start and the if soc_percent

[gcoan]

Done, took a while to do as I've got a stinking cold, courtesy of Mrs C

Log starts from 5965
appdaemon (18).log

[gcoan]

Just in case it was a factor, configured apps.yaml to comment out REST and set all the givtcp controller entities.
Charge curve still didn't work
appdaemon (19).log

[PianSom]

Another user (The Black Cat) just said the exact same thing over on the forum. Very strange! I wonder why it worked for me.

[gcoan]

Strange as you say

[springfall2008]

Just taken a look, I wonder if you never get 99% charge level?

[gcoan]

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

[PianSom]

FWIW I hit 100% pretty much every day. Only missed out once (98%) in the 10+ days I looked at the charts for

[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