Car charging plan and history with Sigenergy

[tdbegley28]

Hi all.

I have predbat setup to control and discharge along with taking control of car charging.

When I plug my EV in Predbat correctly adds 3.6kw to the Car kWh column in the upcoming plan from 11PM (as this is when my cheap EDF electric kicks in)

The following morning if I check the history tab the load for the car charging in history is now in load kWh instead of car kWh, is this correct?

Also I notice some ghost load car kWh in history at a time where no car was charging.

Last night's history below

[gcoan]

Without further details of your EV charger and sensor setup, I can only make some guesses:

The following morning if I check the history tab the load for the car charging in history is now in load kWh instead of car kWh, is this correct?

Also I notice some ghost load car kWh in history at a time where no car was charging.

this could well be a consequence of how your sensors and car/house wiring are setup.

What do you see in the history of your house and car load sensors? Is car load recorded when you expect it to, and not showing any ghost values; does house load include car charging?

I am guessing it could be a problem with your car load sensor, and so predbat assigns all the load to your house not the car?

If the car load sensor correctly is reporting car charging then there sounds like a bug with the plan history in which case please raise a bug with your debug.yaml, apps.yaml, logfile and sensor history

[tdbegley28]

Thanks for the reply

The below of the relevent car info from my app fils

I have the Sig DC and Sig AC charger at home. My BYD only uses the DC and my Ioniq, that was charging last night only uses the AC. I have created a utility meter helper that resets daily to monitor the AC total energy consumed sensor, image attached of this (sensor.sigen_ac_charger_ac_predbat_charger)

  # PREDBAT CAR CHARGING CONFIGURATION
  # ============================================================================
  # Updated for: 2x Sigenergy chargers (12kW DC + 7kW AC), EDF cheap rate 23:00-06:00
  # Cars: BYD ATTO 3 (60.5 kWh) + Hyundai Ioniq 5 (77.4 kWh)
  # ============================================================================

  num_cars: 2

  # Only one charger, so both cars can't charge simultaneously
  car_charging_exclusive:
    - false
    - false

  switch.predbat_car_energy_reported_load: true   # Inverter SEES car charging
  switch.predbat_car_charging_hold: true          # Filter it from historical load

  # ============================================================================
  # PLANNED CAR CHARGING - PREDBAT LED
  # ============================================================================
  # Car charging energy sensors (daily incrementing kWh)
  car_charging_energy:
    - 'sensor.sigen_inverter_dc_charger_dc_charger_predbat'  # Car 1: BYD ATTO 3 (DC)
    - 'sensor.sigen_ac_charger_ac_predbat_charger'           # Car 2: Ioniq 5 (AC)

  # Sensors that indicate when car is plugged in / ready to charge
  car_charging_planned:
    - 'sensor.sigen_inverter_dc_charger_running_state'       # Car 1: DC charger state
    - 'sensor.sigen_ac_charger_system_state'                 # Car 2: AC charger state

  # States that mean "plugged in and can charge"
  car_charging_planned_response:
    - 'on'
    - 'Charging'
    - 'Preparing'
    - 'Scheduled'
    - 'Occupied'
    - 'Reserving'
    - 'Preparing Insulation'
    - 'Preparing Comm'

  # COMMENTED OUT: car_charging_now can cause false low-rate assumptions
  # Only uncomment if Predbat-led charging doesn't work after testing automation
  #car_charging_now:
  #  - 'sensor.sigen_inverter_dc_charger_running_state'
  #  - 'sensor.sigen_ac_charger_system_state'
  #car_charging_now_response:
  #  - 'Charging'

  # ============================================================================
  # CAR SPECIFICATIONS
  # ============================================================================
  # Battery capacities (must be decimal format)
  car_charging_battery_size:
    - 60.5   # Car 1: BYD ATTO 3
    - 80.0   # Car 2: Hyundai Ioniq 5

  # Current State of Charge % sensors
  car_charging_soc:
    - 'sensor.byd_atto_3_battery_level'      # Car 1
    - 'sensor.ioniq_5_ev_battery_level'      # Car 2

  # Charge limit % (manual if charger doesn't expose it)
  car_charging_limit: [100, 100]

  # ============================================================================
  # PREDBAT-LED CHARGING CONTROL
  # ============================================================================
  # These must be set in Home Assistant (not in apps.yaml):
  #
  # input_number.predbat_car_charging_rate:
  #   - 12.0  # Car 1: DC charger 12kW
  #   - 7.0   # Car 2: AC charger 7kW
  #
  # input_number.predbat_car_charging_rate_1: 7.0
  #
  # select.predbat_car_charging_plan_time:
  #   - '06:00'  # Both cars charged by 6am (before cheap rate ends)
  #
  # select.predbat_car_charging_plan_time_1: '06:00'
  #
  # switch.predbat_car_charging_plan_smart: ON (use cheapest slots only)
  # switch.predbat_octopus_intelligent_charging: OFF (Predbat-led, not Octopus)
  #
  # If your chargers don't expose SoC sensors, enable manual mode:
  # switch.predbat_car_charging_manual_soc: ON (for car 1)
  # switch.predbat_car_charging_manual_soc_1: ON (for car 2)
  #   Then manually set input_number.predbat_car_charging_manual_soc_kwh before charging

  # ============================================================================
  # EXPERT/OPTIONAL SETTINGS
  # ============================================================================
  # Allow battery to discharge into car during planned charging slots
  switch.predbat_car_charging_from_battery: false

  # Loss factor during charging (8% typical)
  input_number.predbat_car_charging_loss: 0.08

  # Don't export during car charging windows
  switch.predbat_metric_dynamic_load_adjust: false```

[gcoan]

I can see one possible source of your issue

switch.predbat_car_energy_reported_load: true # Inverter SEES car charging
switch.predbat_car_charging_hold: true # Filter it from historical load

you have used AI to "help" you write your predbat apps.yaml config

entries like this, switches, input_number's and selects in apps.yaml are clear evidence that you've used AI, and AI hallucinates

you need to set the appropriate Home Assistant controls not set these entries in apps.yaml as they will be ignored

car charging hold is probably the one that's causing the plan to be wrong

see Car charging documentation https://springfall2008.github.io/batpred/car-charging/

and please don't use AI. There is comprehensive documentation !

[tdbegley28]

I tried using the Sig template here: https://raw.githubusercontent.com/springfall2008/batpred/main/templates/sigenergy_sigenstor.yaml

And then tried to get some understanding from AI, my bad.

I've reused the template, and replaced the sensors to match mine, along with checking the config and apps in Predbat (attached).

Will do some more reading after work tonight and see what happens. Thank you for your help.

  pred_bat:
  module: predbat
  class: PredBat

  # 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: Template configuration, delete this line once you have set up for your system
#  template: True

  # If you are using Predbat outside of HA then set the HA URL and Key (long lived access token here)
  #ha_url: 'http://homeassistant.local:8123'
  #ha_key: 'xxx'

  # Currency, symbol for main currency second symbol for 1/100s e.g. $ c or £ p or e c
  currency_symbols:
    - '£'
    - 'p'

  # Number of threads to use in plan calculation
  # Can be auto for automatic, 0 for off or values 1-N for a fixed number
  threads: auto

  #
  # Sensors, currently more than one can be specified and they will be summed up automatically
  # however if you have two inverters only set one of them as they will both read the same.
  #
  inverter_type: "SIG"
  num_inverters: 1
  #
  # Controls/status - must by 1 per inverter
  #
  load_today:
    - sensor.sigen_plant_daily_load_consumption
  import_today:
    - sensor.sigen_plant_daily_grid_import_energy
  export_today:
    - sensor.sigen_plant_daily_grid_export_energy
  pv_today:
    - sensor.sigen_plant_daily_pv_energy

  charge_rate:
    - input_number.charge_rate
  discharge_rate:
    - input_number.discharge_rate
  battery_power:
    - sensor.sigen_plant_battery_power
  pv_power:
    - sensor.sigen_plant_pv_power
  load_power:
    - sensor.sigen_plant_consumed_power
  grid_power:
    - sensor.sigen_plant_grid_active_power

  # change the positive/negative sense of power sensors to match what Predbat expects
  battery_power_invert: true
  grid_power_invert: true

  soc_percent:
    - sensor.sigen_plant_battery_state_of_charge
  soc_kw:
    - sensor.sigen_plant_available_max_discharging_capacity
  soc_max:
    - sensor.sigen_plant_rated_energy_capacity
  battery_temperature:
    - sensor.sigen_inverter_battery_average_cell_temperature
  battery_min_soc:
    - 0
  reserve:
    - number.sigen_plant_ess_discharge_cut_off_state_of_charge
  charge_limit:
    - number.sigen_plant_ess_charge_cut_off_state_of_charge

  # Services to control the inverter
  charge_start_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Charging"
  charge_stop_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Demand"
  discharge_start_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Discharging"
  charge_freeze_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Freeze Charging"
  discharge_freeze_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Freeze Discharging"

  # Inverter max AC limit (one per inverter)
  # If you have a second inverter for PV only please add the two values together
  inverter_limit:
    - sensor.sigen_plant_available_max_active_power

  # Set the maximum charge/discharge rate of the battery
  battery_rate_max:
    - sensor.sigen_plant_ess_rated_discharging_power

  # 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
  #
  # The maximum rate the inverter can charge and discharge the battery can be overwritten, this will change
  # the register programming and thus cap the max rates. The default is to use the maximum supported rates (recommended)
  #
  #inverter_limit_charge:
  #  - 4000
  #inverter_limit_discharge:
  #  - 4000

  # 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:
  #  - 100

  # 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)
  #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

  # Solcast cloud interface, set this or the local interface below
  #solcast_host: 'https://api.solcast.com.au/'
  #solcast_api_key: 'xxxx'
  #solcast_poll_hours: 8

  # Set these to match solcast sensor names if not using the cloud interface
  # 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_|)forecast_today)
  pv_forecast_tomorrow: re:(sensor.(solcast_|)(pv_forecast_|)forecast_tomorrow)
  pv_forecast_d3: re:(sensor.(solcast_|)(pv_forecast_|)forecast_(day_3|d3))
  pv_forecast_d4: re:(sensor.(solcast_|)(pv_forecast_|)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:
    - 'sensor.sigen_inverter_dc_charger_dc_charger_predbat'
    - 'sensor.sigen_ac_charger_ac_predbat_charger'

  num_cars: 2

  # 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 Octopus Intelligent 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
  car_charging_planned:
    - 'sensor.sigen_inverter_dc_charger_running_state'
    - 'sensor.sigen_ac_charger_system_state'

  car_charging_planned_response:
    - 'on'
    - 'Charging'
    - 'Preparing'
    - 'Scheduled'
    - 'Occupied'
    - 'Reserving'
    - 'Preparing Insulation'
    - 'Preparing Comm'

  # To make planned car charging more accurate, either using car_charging_planned or Octopus Intelligent
  # specify your battery size in kwh, charge limit % and current car battery soc % sensors/values
  # If you have intelligent the battery size and limit will be extracted from Intelligent 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:
    - 60.5
    - 80.0
  car_charging_limit: [100, 100]
  car_charging_soc:
    - 'sensor.byd_atto_3_battery_level'
    - 'sensor.ioniq_5_ev_battery_level'

  # If you have Octopus Intelligent Go and are not using the Octopus Direct connection method, 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 the intelligent slot from the Octopus Energy integration
  # octopus_intelligent_slot: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)'
  # octopus_ready_time: 're:((select|time).octopus_energy_([0-9a-z_]+|)_intelligent_target_time)'
  # octopus_charge_limit: 're:(number.octopus_energy([0-9a-z_]+|)_intelligent_charge_target)'

  # Carbon Intensity data from National grid
  # carbon_postcode: 'SW1 5NA'
  # carbon_automatic: True

  # Example alternative configuration for Ohme integration release >=v0.6.1
  #octopus_intelligent_slot: 'binary_sensor.ohme_slot_active'
  #octopus_ready_time: 'time.ohme_target_time'
  #octopus_charge_limit: 'number.ohme_target_percent'

  # Set this to False if you use Octopus Intelligent slot for car planning but when on another tariff e.g. Agile
  #octopus_slot_low_rate: False

  # 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:(event.octopus_energy([0-9a-z_]+|)_saving_session_event(s|))'
  # octopus_saving_session_octopoints_per_penny: 8

  # Enter your Axle VPP API key if you have signed up to the Axle service in the UK
  # axle_api_key: "xxxxxxx"

  # 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
  # automatically matches your meter number assuming you have only one
  # Will be ignored if you don't have the sensor
  # Or manually set it to the correct sensor names e.g:
  # sensor.octopus_energy_electricity_xxxxxxxxxx_xxxxxxxxxxxxx_current_rate
  # sensor.octopus_energy_electricity_xxxxxxxxxx_xxxxxxxxxxxxx_export_current_rate
  # 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)'
  # metric_octopus_import: 'sensor.edf_energy_electricity_25j0036423_2600001092501_current_rate'
  # octopus_intelligent_slot: 'binary_sensor.edf_energy_electricity_25j0036423_2600001092501_off_peak'


  # Standing charge can be set to a sensor (e.g. Octopus) or manually entered in pounds here (e.g. 0.50 is 50p)
  # metric_standing_charge: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_standing_charge)'
  metric_standing_charge: 'sensor.edf_energy_electricity_25j0036423_2600001092501_current_standing_charge'

  # 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 0
  # rates_import:
  #   - start: "23:30:00"
  #     end: "05:30:00"
  #     rate: 7.5
  #   - start: "05:30:00"
  #     end: "23:30:00"
  #     rate: 30.0

  rates_import:
    - start: "23:00:00"
      end: "06:00:00"
      rate: number.edf_off_peak_rate
    - start: "06:00:00"
      end: "23:00:00"
      rate: number.edf_peak_rate

  # rates_export:
  #   - rate: 15.0
  rates_export:
    - rate: 0.00
  # Can be used instead of the plugin to get import rates directly online
  # Overrides metric_octopus_import and rates_import
  # See the 'energy rates' part of the documentation for instructions on how to find the correct URL for your tariff and DNO region
  #
  # 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-24-10-01/electricity-tariffs/E-1R-AGILE-24-10-01-A/standard-unit-rates"

  # Overrides metric_octopus_export and rates_export
  # rates_export_octopus_url: "https://api.octopus.energy/v1/products/FLUX-EXPORT-23-02-14/electricity-tariffs/E-1R-FLUX-EXPORT-23-02-14-A/standard-unit-rates"
  # rates_export_octopus_url: "https://api.octopus.energy/v1/products/AGILE-OUTGOING-19-05-13/electricity-tariffs/E-1R-AGILE-OUTGOING-19-05-13-A/standard-unit-rates/"

  # 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: '2023-09-10'
  #    start: '14:00:00'
  #    end: '14:30:00'
  #    rate: 5

  # Days previous sets how many days of load history Predbat searches when forecasting your future house load.
  # By default this uses a weighted-bucket forecast that automatically accounts for day-of-week, holiday mode
  # and recency (days_previous_auto) - see the documentation for other options, such as picking specific
  # days/weights instead, or using Load ML.
  days_previous:
    - 7

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

  # The number of hours ahead to count in charge planning (for cost estimates)
  # It's best to set this on your charge window repeat cycle (24) but you may want to set it higher for more variable
  # tariffs like Agile
  forecast_plan_hours: 30

  # 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: 1.0

  # 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

  # Nordpool market energy rates
  #futurerate_url: 'https://dataportal-api.nordpoolgroup.com/api/DayAheadPrices?date=DATE&market=N2EX_DayAhead&deliveryArea=UK&currency=GBP'
  #futurerate_adjust_import: False
  #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

  # 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

[tdbegley28]

Hi. Thank you. I have since provided the debug file below following a night of charge. If the full log file is needed I will look to charge tonight and provide all files.

[gcoan]

I'll see what the AI BOT can spot. It may need to be moved to an issue, but lets give it a go

[tdbegley28]

Thank you

[tdbegley28]

I'll see what the AI BOT can spot. It may need to be moved to an issue, but lets give it a go

Hi. I don't think the bot fired here in the discussion?

Would you like me to create an issue instead?

[gcoan]

I'll see what the AI BOT can spot. It may need to be moved to an issue, but lets give it a go

Hi. I don't think the bot fired here in the discussion?

Would you like me to create an issue instead?

yes please, do include the config and log files and the screenshots as you have in this discussion.

You've given great information but I don't have an EV so can't really advise on the config.

Cheers

[tdbegley28]

Just to update here as the historic data still seems a bit odd on stripping the car load data accurately. Is this the expected behaviour? Plan and then history attached with debug file

Plan

History

Debug
predbat_debug_20260905-053000.yaml

[Javert1969]

Just to add here - I am having a very similar issue with Zappi charger and Alpha ESS inverter (manually configured using Modbus controls) and using Octopus IOG.
Real future car charging is correctly picked up in the plan. In the plan history, it shows wrong until midnight the next day, after which it seems to show correct.
However I am also getting spurious threshold amounts being classified as car charging - e.g. last night it classified cooking the dinner as car charging. I have changed the threshold detection to 20Kw but from the documentation, I understood that this should only be needed if I have not provided a specific car charge daily load figure (which I have done). This is the part which has a detrimental effect on the next day plan because the cooking of dinner is not taken into account in load planning the next day.

[gcoan]

However I am also getting spurious threshold amounts being classified as car charging - e.g. last night it classified cooking the dinner as car charging. I have changed the threshold detection to 20Kw but from the documentation, I understood that this should only be needed if I have not provided a specific car charge daily load figure (which I have done).

is the problem in the display of the plan history that you are getting miscategorisations or in the forward load projection?

The OP has raised a github issue (see below) on the plan history display problem and its been confirmed to be a display problem that is being fixed - basically dates were being mis-counted for non-IOG car charging. So might be worth waiting for that fix

[tdbegley28]

Issue raised here: #5004 @Javert1969

[gcoan]

Issue raised here: #5004 @Javert1969

great, thanks

From the bot triage it looks to be a bug with the history plan display, and a fix is coming.

Thanks for raising

[tdbegley28]

Thank you!

Can you please advise on the following raised by the BOT

Reporter's config checked (from the attached debug yaml): car_charging_hold=true, car_energy_reported_load=true, two Sigenergy charger sensors as car_charging_energy — so both the load-subtraction and car-band effects apply. Note also that only car 0 gets reconstructed slots (output.py:3039 appends only to car_charging_slots[0]), so with num_cars: 2 both chargers fold into car 1's graph.

Is this a code side issue that needs to be fixed for multiple cars?

[gcoan]

Is this a code side issue that needs to be fixed for multiple cars?

yes I believe so