Modelling plug-in solar that's invisible to the load CT

[mitulgovind]

Modelling plug-in solar that sits downstream of the load CT — is pv_today + load_today the right approach?

System overview

Software

• Predbat v9.0.1 (auto-update enabled)
• Home Assistant 2026.9.1
• Running as an HA add-on on Home Assistant Green (4GB RAM), 1TB USB SSD attached
• Recorder purge_keep_days: 30

Inverter / battery

• LuxPower LXP 3600ACS, AC-coupled, ~3,600W charge/discharge (real ceiling ~3,420W)
• 5 × 3.2kWh Hanchu ESS modules = 16kWh, LiFePO4
• Native battery balance + 7-day Battery Calibration enabled
• has_reserve_soc: false — no writable reserve register on this model
• support_discharge_freeze: false — charge freeze only, handled by a custom automation

Solar PV (existing)

• SolarEdge SE4000-16A inverter, 20 × 200Wp ET Solar panels (4.0kWp array, 4,000VA AC cap)
• Separate inverter — PV does not pass through the LuxPower; Predbat reads it via a CT clamp
• Observed real-world export peaks ~2,800–3,000W
• Legacy FiT on generation, so solar is effectively "paid for" regardless of how it's used

Solar PV (being added)

• EcoFlow STREAM Microinverter (EF-PS-800), 800W, plug-in via a 13A socket
• 2 × CSI Solar CS6R-440T (440Wp) panels
• Sits downstream of the LuxPower CT, so its output appears only as reduced house consumption

Forecasting

• Solcast, free hobbyist tier, 2 rooftop sites (garage 3.2kW + house 1.0kW), solcast_poll_hours: 6.0
• PV10 and PV90 scenarios both live
• Predbat ML load forecasting enabled (load_ml_enable/load_ml_source), 28-day training window, 90-day on-disk history, temperature_enable: true
• Cloud model, load divergence and PV calibration all enabled

Tariffs / grid

• Octopus Agile import, Octopus Outgoing fixed export at 12p
• DNO region A, UKPN, G98 connection (both inverters notified)
• Octoplus Saving/Power Down sessions and Weekend Happy Hours in use
• No EV (num_cars: 0)

Load accounting (relevant to the question below)

• load_today is sensor.lux_new_home_consumption_daily, which is no longer a raw LuxPower daily register. Those froze mid-day for hours while still reporting fresh polls, which Predbat's gap-fill logic flagged as ~24 zero-load periods a day. It's now an integration platform sensor (trapezoidal, max_sub_interval: 5min) over the live power formula, feeding a daily-cycle utility_meter, mirrored back to the original entity_id so apps.yaml needed no change.
• Immersion heater is a Shelly Plus 1PM, driven by its own HA automation rather than by Predbat. iboost_enable: false, but iboost_energy_today is mapped to sensor.plus1pm_immersion_energy with iboost_energy_subtract: true, so Predbat subtracts real measured diverter energy from historical load for ML accuracy. That subtraction works independently of iboost_enable.
• So there's already one behind-the-meter flow being reconciled into the load model — the plug-in solar is the same problem with the opposite sign.

Other custom sensors

• sensor.lux_battery_soc_corrected and sensor.lux_soc_max_kwh are template sensors per the LuxPower inverter setup docs
• Charge freeze is handled by a custom automation (automation.luxpower_freeze_charge) wired to charge_freeze_service, since the hardware has no discharge freeze

Predbat mode

• "Control charge & discharge"
• best_soc_min 0.0kWh, best_soc_keep 0.8kWh
• metric_battery_cycle 0.0p, forecast_plan_hours 32, rate_low_threshold 0.8 (fixed)

Question

I'm adding an 800W plug-in solar microinverter that plugs into a 13A socket, so it's downstream of the CT clamp Predbat reads PV from. Its output is invisible as generation and instead shows up as a drop in measured house consumption.

My plan is to add its daily generation sensor to both pv_today and load_today, so that load is grossed back up to its true value and total PV is correct, keeping the energy balance intact. The Solcast side is handled by raising the house site's capacity from 1.0kW to 1.6kW rather than adding a third site.

The EcoFlow integration gives power rather than a cumulative counter, so I'd build the daily kWh sensor the same way as the load sensor above — integration platform into a utility_meter — rather than trusting a cloud-side daily total.

Is that the right approach? The one thing I'm unsure about is that Predbat will model this PV as available to charge the battery, which is only indirectly true — surplus at the meter just exports rather than reaching the LuxPower directly. Is that worth worrying about, or does it wash out in practice?

Sanitised apps.yaml below — API keys, account/meter IDs, Solcast site IDs, postcode and the inverter serial have all been removed, so entity IDs read sensor.lux_* where they'd normally carry the serial.

apps.yaml

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

  # Weather / grid alert feed for Predbat
  alerts:
    url: "https://feeds.meteoalarm.org/feeds/meteoalarm-legacy-atom-united-kingdom"
    event:
      "(Yellow|Orange|Red).*(Wind|Snow|Fog|Rain|Thunderstorm|Flood|Ice|Storm|Heat|Low
      temperature|Coastal event|Wildfire)"
    severity: "Severe|Extreme"
    certainty: "Likely|Expected"
    keep: 25 # target battery SoC (%) during an active alert
    # latitude: 51.00      # optional – override HA location
    # longitude: -0.00     # (leave commented to use your HA location)

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

  # When True predbat records to a local database
  db_enable: true
  db_days: 90
  db_mirror_ha: true
  db_primary: false

  # 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

  enable_coarse_fine_levels: true

  load_power_fill_enable: true

  prediction_kernel_enable: 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'

  # 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.lux_new_home_consumption_daily

  import_today:
    - sensor.lux_power_from_grid_daily_um

  export_today:
    - sensor.lux_power_to_grid_daily_um

  pv_today:
    - sensor.lux_solar_output_daily_um

  # Enable ML load prediction
  load_ml_enable: true
  # Use the output data in Predbat
  load_ml_source: true
  # Recommended: improves accuracy (esp. heating season)
  temperature_enable: true
  # Maximum days of historical data to use for training (default: 28)
  load_ml_max_days_history: 28
  # Optional: Number of days of history to accumulate in the on-disk database (default: 90)
  load_ml_database_days: 90

  # Controls/status - must by 1 per inverter
  #
  num_inverters: 1
  inverter_type: Lux
  inverter:
    name: "LXP ACS 3600"
    has_rest_api: false
    has_mqtt_api: false
    has_service_api: true
    output_charge_control: "current"
    current_dp: 0
    has_charge_enable_time: true
    has_discharge_enable_time: true
    has_target_soc: true
    has_reserve_soc: false
    has_timed_pause: false
    charge_time_format: "HH:MM:SS"
    charge_time_entity_is_option: false
    soc_units: "%"
    num_load_entities: 1
    has_ge_inverter_mode: false
    time_button_press: false
    clock_time_format: "%Y-%m-%d %H:%M:%S"
    write_and_poll_sleep: 10
    has_time_window: false
    support_charge_freeze: true
    support_discharge_freeze: false

  charge_start_service:
    service: switch.turn_on
    entity_id: switch.lux_ac_charge_enable
  charge_stop_service:
    service: switch.turn_off
    entity_id: switch.lux_ac_charge_enable
  discharge_start_service:
    service: switch.turn_on
    entity_id: switch.lux_force_discharge_enable
  discharge_stop_service:
    service: switch.turn_off
    entity_id: switch.lux_force_discharge_enable
  #discharge_freeze_service:
  #service: switch.turn_on
  #entity_id: switch.lux_charge_last
  #discharge_unfreeze_service:
  #service: switch.turn_off
  #entity_id: switch.lux_charge_last
  charge_freeze_service:
    service: automation.turn_on
    entity_id: automation.luxpower_freeze_charge
  charge_unfreeze_service:
    service: automation.turn_off
    entity_id: automation.luxpower_freeze_charge

  # Run balance inverters every N seconds (0=disabled) - only for multi-inverter
  # balance_inverters_seconds: 60

  timed_charge_current:
    - number.lux_charge_current_limit
  timed_discharge_current:
    - number.lux_discharge_current_limit
  grid_power:
    - sensor.lux_grid_flow_live
  grid_power_invert:
    - false
  battery_power:
    - sensor.lux_battery_flow_live
  battery_power_invert:
    - true
  pv_power:
    - sensor.lux_solar_output_live
  load_power:
    - sensor.lux_new_home_consumption_live
  soc_percent:
    - sensor.lux_battery_soc_corrected # This is a custom template sensor - see LuxPower section of 'Inverter Setup' documentation for how to create
  soc_max:
    - sensor.lux_soc_max_kwh # Custom template sensor - see LuxPower inverter setup for details
  battery_rate_max:
    - 3600 # Set to the maximum rate your inverter can charge your battery at (in Watts)
  battery_min_soc:
    - number.lux_on_grid_discharge_cut_off_soc
  battery_voltage:
    - sensor.lux_battery_voltage_live
  scheduled_charge_enable:
    - switch.lux_ac_charge_enable
  charge_start_time:
    - time.lux_ac_charge_start1
  charge_end_time:
    - time.lux_ac_charge_end1
  charge_limit:
    - number.lux_ac_battery_charge_level
  scheduled_discharge_enable:
    - switch.lux_force_discharge_enable
  discharge_start_time:
    - time.lux_force_discharge_start1
  discharge_end_time:
    - time.lux_force_discharge_end1
  discharge_target_soc:
    - number.lux_forced_discharge_battery_level

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

  # Optional battery charge/discharge caps
  inverter_limit_charge:
    - 3600

  inverter_limit_discharge:
    - 3600

  # Optional forced-export-only battery cap
  # Leave commented unless you want to slow battery export
  # inverter_limit_export:
  #   - 2000

  # PV AC output limit for AC-coupled / non-hybrid PV modelling only
  # This helps Predbat model clipping/realistic max PV AC output
  pv_ac_limit: 4000

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

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

  # 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)
  #
  # Predbat can compute this curve automatically if you have enough data, restart the add-on and look in the logfile for the data
  # once set here Predbat will no longer re-compute the curve.
  # Can also be set to 'auto' to just use the calculation curve, not recommended if you are using low power charging mode.
  #
  # uncomment the following charge_rate and discharge_rate lines if you want Predbat to create the charge curves for you
  # charge_rate:
  #   - number.lux_target_charge_current_w
  # discharge_rate:
  #   - number.lux_target_discharge_current_w
  #
  # Example curves from Hanchu batteries with Luxpower inverter:
  # battery_charge_power_curve:
  #97: 0.93
  #98: 0.52
  #99: 0.30
  #100: 0.30

  #battery_discharge_power_curve:
  #10: 1.00
  #5: 0.50
  #0: 0.0

  battery_charge_power_curve: auto
  battery_discharge_power_curve: auto

  # 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
  inverter_can_charge_during_export: false

  # Clock skew adjusts the Predbat computer reported 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 Predbat computer 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_sites:
    - "xxxx-xxxx-xxxx-xxxx"
    - "xxxx-xxxx-xxxx-xxxx"
  solcast_poll_hours: 6.0

  # Open-Meteo backup PV forecast
  # Use this only if Solcast has API/rate-limit issues
  # To enable, uncomment this block and disable/comment out the Solcast cloud section above
  #
  # open_meteo_forecast:
  #   - postcode: XX99 9XX
  #     kwp: 3.2
  #     declination: 10
  #     azimuth: -140
  #     efficiency: 0.77
  #
  #   - postcode: XX99 9XX
  #     kwp: 0.8
  #     declination: 30
  #     azimuth: 128
  #     efficiency: 0.77
  #
  # open_meteo_forecast_max_age: 4.0

  # forecast_solar: false
  # forecast_solar_max_age: 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: sensor.solcast_pv_forecast_forecast_today
  # pv_forecast_tomorrow: sensor.solcast_pv_forecast_forecast_tomorrow
  # pv_forecast_d3: sensor.solcast_pv_forecast_forecast_day_3
  # pv_forecast_d4: sensor.solcast_pv_forecast_forecast_day_4
  # pv_forecast_d5: sensor.solcast_pv_forecast_forecast_day_5
  # pv_forecast_d6: sensor.solcast_pv_forecast_forecast_day_6
  # pv_forecast_d7: sensor.solcast_pv_forecast_forecast_day_7

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

  # One per car, when true only one car can charge at once, when False multiple cars can charge at once
  #car_charging_exclusive:
  #  - True

  # 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_target_time)'
  #octopus_charge_limit: 're:(number.octopus_energy([0-9a-z_]+|)_intelligent_charge_limit)'
  # 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'

  # Carbon Intensity data from National grid
  # carbon_intensity:
  #   sensor.national_grid_current_carbon_intensity_2
  carbon_postcode: "XX99 9XX"
  carbon_automatic: true

  # 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_<MPAN>_<SERIAL>_previous_day_rates
  #event.octopus_energy_electricity_<MPAN>_<SERIAL>_current_day_rates
  #event.octopus_energy_electricity_<MPAN>_<SERIAL>_next_day_rates
  #and if you have export enable:
  #event.octopus_energy_electricity_<MPAN>_<EXPORT_SERIAL>_export_previous_day_rates
  #event.octopus_energy_electricity_<MPAN>_<EXPORT_SERIAL>_export_current_day_rates
  #event.octopus_energy_electricity_<MPAN>_<EXPORT_SERIAL>_export_next_day_rates
  #Predbat will automatically find the event. entities from the link below to the sensors
  #metric_octopus_import: sensor.octopus_energy_electricity_<MPAN>_<SERIAL>_current_rate
  #metric_octopus_export: sensor.octopus_energy_electricity_<MPAN>_<EXPORT_SERIAL>_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: sensor.octopus_energy_electricity_<MPAN>_<SERIAL>_current_standing_charge

  # --- Octopus Energy Direct (optional, currently NOT in use) ---
  # If you ever want Predbat to connect directly to your Octopus account
  # instead of using the HA Octopus integration above, you would set:
  #
  octopus_api_account: "A-XXXXXXXX"
  octopus_api_key: "xxxx"
  octopus_automatic: true

  # Saving Sessions -> Power Down (from Octopus Energy HA integration)
  # octopus_saving_session: event.octopus_energy_a_xxxxxxxx_octoplus_power_down_events
  # octopus_saving_session_octopoints_per_penny: 8

  # Free Electricity -> Power Up (from Octopus Energy HA integration)
  # octopus_free_session: event.octopus_energy_a_xxxxxxxx_octoplus_power_up_events

  # Backup method for Free Electricity (scrape Octopus webpage)
  octopus_free_url: "https://octopus.energy/free-electricity/"

  # --- Future Agile energy rates (tomorrow estimate before Octopus publishes) ---
  futurerate_url: "https://dataportal-api.nordpoolgroup.com/api/DayAheadPrices?date=DATE&market=N2EX_DayAhead&deliveryArea=UK&currency=GBP"
  futurerate_adjust_auto: true
  # futurerate_adjust_import: true
  # futurerate_adjust_export: false
  futurerate_peak_start: "16:00:00"
  futurerate_peak_end: "19:00:00"

  # When using Octopus Direct, you can ignore metric_octopus_import /
  # metric_octopus_export above because Predbat will pull rates itself.
  # ----------------------------------------------------
  #
  #rates_export:
  #  -  rate: 12.0

  # 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-G/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-23-02-14/electricity-tariffs/E-1R-FLUX-EXPORT-23-02-14-G/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/"

  # 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: 112
  #    load_scaling: 0.8

  # 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

  # 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:
    - 7
    - 14
    - 21
    - 28

  # 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.00
  # - 0.75
  # - 0.50
  # - 0.25

  days_previous_auto: True

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

  # Limit the number of charge slots used in the baseline savings comparison (v8.27.6+)
  # calculate_savings_max_charge_slots: 1

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

  # 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
  # One per inverter
  battery_scaling:
    - 1.0

  battery_scaling_auto: true

  # 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.plus1pm_immersion_energy
  iboost_energy_scaling: 1.0

  # Gas rates for comparison
  # metric_octopus_gas: 're:(sensor.(octopus_energy_|)gas_[0-9a-z]+_[0-9a-z]+_current_rate)'
  # Tariff comparison feature
  # Adjust this list to the tariffs you want to compare (include your current tariff too)
  # Octopus region code (https://energy-stats.uk/dno-region-codes-explained/)
  #dno_region: "A"

  #compare_list:
  #- id: 'current'
  #name: 'Current Tariff (Agile import / Outgoing fixed export)'

  #- id: 'cap_seg'
  #name: 'Price cap import / SEG export'
  #rates_import:
  #- rate: 24.86
  #rates_export:
  #- rate: 4.1

  #- id: 'agile_agile'
  #name: 'Agile import / Agile export'
  #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/'
  #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/'

  #- id: 'flux'
  #name: 'Flux import / export'
  #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_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'

  # Watch list, a list of sensors to watch for changes and then update the plan if they change
  # This is useful for things like the Octopus Intelligent Slot sensor so that the plan update as soon as you plugin in
  # Only uncomment the items you actually have set up above in apps.yaml, of course you can add your own as well
  # Note those using +[] are lists that are appended to this list, whereas {} items are single items only
  #watch_list:
  #--- Battery (charge/discharge + health) ---
  # - 'sensor.lux_battery_soc_corrected'

  #--- House / Load ---
  #  - 'sensor.lux_home_consumption_live'

  #--- Solar (generation detail) ---
  #  - 'sensor.lux_solar_output_live'
  #--- Grid ---
  #- 'sensor.lux_grid_flow_live'

[gcoan]

My plan is to add its daily generation sensor to both pv_today and load_today, so that load is grossed back up to its true value and total PV is correct, keeping the energy balance intact. The Solcast side is handled by raising the house site's capacity from 1.0kW to 1.6kW rather than adding a third site.

The EcoFlow integration gives power rather than a cumulative counter, so I'd build the daily kWh sensor the same way as the load sensor above — integration platform into a utility_meter — rather than trusting a cloud-side daily total.

Is that the right approach?

A good question, thanks. We'll probably get a few more people adopting a similar setup as plug in solar gets more affordable.

Are you planning on creating new template PV and Load sensors or are you planning on just adding the additional sensor to the pv_today and load_today lines in apps.yaml.
I suspect (not checked the code or tested it) but if you add a second line and still have num_inverters set to 1, then Predbat's validation of apps.yaml will complain about this. You could circumvent this by adding a second dummy inverter to the apps.yaml and adding dummy control entities alongside the existing Luxpower sensors, but would be a bit of a faff and a lot of dummy sensors to create (could reduce the number by having your dummy inverter have far fewer capabilities than your Luxpower.

Creating new template sensors would avoid this.

In terms of logic it makes sense.

The one thing I'm unsure about is that Predbat will model this PV as available to charge the battery, which is only indirectly true — surplus at the meter just exports rather than reaching the LuxPower directly. Is that worth worrying about, or does it wash out in practice?

Yes predbat will model this PV as available to charge the battery, but what will happen in practice is that the extra PV will satisfy house load first and you'll only get a small amount exported. It's only going to be on peak solar generation that this will noticeably happen. Predbat re-calculates the plan every 10 minutes, there's quite a lot of variation of solar generation vs forecast so this will just wash out as part of the general 'forecasts are never 100% accurate'

[mitulgovind]

Thanks, that's really helpful on both counts.

Going the template sensor route. As you say it avoids the num_inverters question entirely, and I need to build sensors regardless — the EcoFlow reports power rather than a cumulative counter, so there's an integration platform sensor into a utility_meter in the chain either way. So it's two more template sensors rather than a different approach.

The other reason I'd rather do it that way: summing inside a template makes the combined values visible entities I can chart. If the plug-in solar contribution ever looks wrong I can see it directly instead of inferring it from Predbat's behaviour. That's the same reasoning behind mirroring the utility_meter back to the original entity_id when I rebuilt the load sensor in August — it kept the diagnostics where I could see them.

So it'll be something like sensor.total_pv_daily (LuxPower solar + EcoFlow) and sensor.total_home_consumption_daily (existing load + EcoFlow), with apps.yaml pointing at those single entries.

Worth flagging on the validation point — the comment block above pv_today in the templates currently reads "for pv_today if you have multiple solar inverter inputs then you should include one entry for each inverter", which reads as though summing is independent of num_inverters. Might be worth a doc tweak either way once someone confirms which behaviour is actual.

On the battery modelling — that makes sense, and the bit that resolves it for me is that the error is bounded rather than just small. The 800W only fails to reach the battery when PV exceeds house load, and my baseline rarely sits under 800W, so what's left is well inside forecast noise I already live with. Combined with the 10-minute replan it self-corrects rather than accumulating. Happy to stop worrying about it.

Will report back once it's running with a few weeks of data, in case it's useful to anyone else doing the same thing.