Dual inverters charge/discharge block: config advice please

[sandyman44]

TLDR: What is the correct configuration structure for the charge/discharge/start/stop block when you have two inverters that are different ?

In my case I want inverter 0 to be controlled by predbat using this config block. Inverter 1 is controlled by HA, responding to the value of predbat.status. However, the SOC, energy and power of inverter 1 is tracked by predbat, so as to get the maths right.
So this config block for inverter 1 needs to be , logically speaking, a do-nothing block.

I've been through chatgpt and claude, neither could help me figure this out other than both being certain (basedon them reviewng my logs) that my config is causing predbat to send commands to inverter 0 when its really trying to talk to inverter 1.

the behaviour I am seeing is that the charge/discharge/start/stop block that I have coded to make changes for inverter 0 (and it works, if only inverter 0 is in the system), is also called when predbat wants to make a change to inverter 1. which breaks things, inverter 0 (which is a cloud controlled powerwall, which makes life harder as well) gets confused as its export allowed state flip flops around and ends up wrong.

If I run it without inverter 1 its basically clean behaviour.

inverter 0 is a powerwall, inverter 1 is a victron, although I think that isn't a relevant issue. I am not trying to balance inverters or any of that.

I've set has_service_api: False in inverter 1, but that doesn't appear to make any difference.

help!

pred_bat:
  module: predbat
  class: PredBat
  prefix: predbat
  timezone: Europe/London
 
  # --- AUTODISCOVERY SETTINGS ---
 
    # --- OCTOPUS HA INTEGRATION AUTODISCOVERY ---
  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_standing_charge: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_standing_charge)'

  # solar 
  pv_forecast_today: sensor.solcast_pv_forecast_forecast_today
  pv_forecast_tomorrow: sensor.solcast_pv_forecast_forecast_tomorrow

  # --- CONFIGURATION ADJUSTMENTS ---
  days_to_log: 7
  forecast_hours: 48
 
 
  rate_high_threshold: true

num_inverters: 2

 inverter_type: 
 - Custom
 - Custom2
 
 inverter:
 - name: "Tesla Powerwall"
   has_rest_api: False
   has_mqtt_api: False
   output_charge_control: "none"
   has_charge_enable_time: False
   has_discharge_enable_time: False
   has_target_soc: False
   has_ge_inverter_mode: False
   charge_time_format: "S"
   charge_time_entity_is_option: False
   soc_units: "%"
   num_load_entities: 1
   time_button_press: False
   clock_time_format: "%Y-%m-%d %H:%M:%S"
   write_and_poll_sleep: 2
   has_time_window: False
   support_charge_freeze: True
   support_discharge_freeze: False
   has_idle_time: False
   has_reserve_soc: False
   has_service_api: True



 - name: "Victron"
   has_rest_api: False
   has_mqtt_api: False
   output_charge_control: "none"
   has_charge_enable_time: False
   has_discharge_enable_time: False
   has_target_soc: False
   has_ge_inverter_mode: False
   charge_time_format: "S"
   charge_time_entity_is_option: False
   soc_units: "%"
   num_load_entities: 1
   time_button_press: False
   clock_time_format: "%Y-%m-%d %H:%M:%S"
   write_and_poll_sleep: 2
   has_time_window: False
   support_charge_freeze: False
   support_discharge_freeze: False
   has_idle_time: False
   has_reserve_soc: False
   has_service_api: False


 battery_rate_max : 
 - 15000
 - 3600
 export_limit: 
 - 11900
 - 4000
 inverter_limit_charge: 
 - 15000
 - 3600
 inverter_limit_discharge: 
 - 11900
 - 4000
 
# from powerwall local integration
 battery_power:
   - sensor.powerwall_battery_now
   - sensor.xxxxxxxxxx_multiplus_ii_48_5000_70_50_id_276_input_power_l1
 battery_power_invert:
   - False
   - True

 pv_power:
   - sensor.powerwall_solar_now
   - sensor.xxxxxxxxsolar_pv_yield_power
 load_power:
   - sensor.true_net_load_really
   # subtracts victron export
   # - sensor.powerwall_load_now
   - 0.0

 grid_power:
   - sensor.powerwall_site_now
   - 0.0
 grid_power_invert: 
   - true
   - true

 soc_percent:
   - sensor.xxxxxxxxxx_battery
   - sensor.victron_mqtt_c0619ab6fb80_battery_277_battery_soc
 soc_max:
   - 41  # ensure this matches your usable kWh
   - 12

# calls to cloud integration
 charge_start_service:
 
   - service: select.select_option
     entity_id: select.xxxxxxxxx_operation_mode
     option: "Time-Based Control"
     repeat: True
   - service: select.select_option
     entity_id: select.xxxxxxxxxx_grid_charging
     option: "Yes"
   - service: number.set_value
     entity_id: number.xxxxxxx_backup_reserve
     value: "100"
     repeat: True
 


 charge_freeze_service:
 
   - service: select.select_option
     entity_id: select.xxxxxxxxx_operation_mode
     option: "Self-Powered"
     repeat: True
   - service: script.turn_on
     entity_id: script.freeze_powerwall_soc
 
 charge_stop_service:
 
   - service: number.set_value
     entity_id: number.xxxxxxxxxx_backup_reserve
     value: "0"  # Set to your lowest preferred reserve limit (e.g. 10 or 20)
     repeat: True
   - service: select.select_option
     entity_id: select.xxxxxxxx_operation_mode
     option: "Self-Powered"
     repeat: True 
   - service: select.select_option
     entity_id: select.xxxxxxxx_grid_charging
     option: "No"
     repeat: True



 discharge_start_service:

 
   - service: select.select_option
     entity_id: select.xxxxxxxx_energy_exports
     option: "Everything"
     repeat: True
   - service: select.select_option
     entity_id: select.xxxxxxxxx_operation_mode
     option: "Time-Based Control"
     repeat: True
 


 discharge_stop_service:
 

   - service: select.select_option
     entity_id: select.xxxxxx_energy_exports
     option: "Nothing"
     repeat: True


   
  # ---- Daily energy (kWh, cumulative today) ----
 load_today:
  # - sensor.house_energy_today
  # powerwall only 
   - sensor.true_net_energy_today
  # allows for victron energy movement
 import_today:
   - sensor.grid_import_today
 export_today:
   - sensor.safe_grid_export_today 
   - 0.0
    # Replace this with the total PV energy generated today from your inverter
 pv_today: sensor.solar_energy_today
   

   
   
   
   # car stuff
   
 num_cars: 1
 myenergi_automatic_zappi: false
 car_charging_energy: 
   - sensor.myenergi_house_charge_added_session
#    - sensor.victron_import_energy
 car_charging_power: 
   - sensor.myenergi_house_internal_load_ct1
#    - sensor.victron_import_power
   
 car_charging_planned: 
  - sensor.myenergi_house_plug_status
#   - input_boolean.dummy_boolean

# Define what statuses mean the car is connected/charging
 car_charging_planned_response:
   - 'Charging'
   - 'EV Connected'
 car_charging_now:  
  - sensor.myenergi_house_internal_load_ct1
#   - input_boolean.dummy_boolean

 
 octopus_intelligent_dynamic : true
 octopus_intelligent_charging: true


 octopus_intelligent_slot: 'binary_sensor.octopus_energy_00000000_0009_4000_8020_00000007fa7d_intelligent_dispatching'
 octopus_ready_time: 'select.octopus_energy_00000000_0009_4000_8020_00000007fa7d_intelligent_target_time'
 octopus_charge_limit: 'number.octopus_energy_00000000_0009_4000_8020_00000007fa7d_intelligent_charge_target'
 
 
 
 # load ML
 temperature_enable: true
   # Enable ML load prediction
 load_ml_enable: true
 # Use the output data in Predbat (can be false to explore the use without using the data)
 load_ml_source: true

 # Optional: Maximum days of historical data to fetch from HA on each poll (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

`

[gcoan]

Predbat has no concept of control block for inverter 0 and inverter 1, it only has a single common set of controls to start charge, stop charge, start discharge, etc, and my guess (not verified) is that these will get executed twice, once for each inverter if there are multiple inverters configured in predbat.

You could either change the numbers, create composite entities for the two inverters, or configure both inverters as you have, listing their SoC, charge/discharge rates, etc, then when Predbat controls the inverters it'll execute the (eg) start charge service controls and your automation then picks up the predbat.status and reflects that in the non-controlled inverter.

For the second (non controlled) inverter, set the inverter definition to as much config items as possible to False to stop predbat trying too hard to use that inverter's data. Just keep to the minimum, SoC. The battery/grid/solar power are nice to have to get the diagram in the web console right but don't affect the plan (well load power can be used if there are load_today gaps). You'll need just a single import energy, export energy, load today (example template in the docs), and PV can either be a custom template or just include both PV energy sensors

Bear in mind Predbat doesn't control the inverters to stop cross charging by default. There are ways around that, switch.predbat_set_freeze_export_during_demand is one, see the customisation doc

[sandyman44]

thanks. your guess is correct, its executing them twice, which you would think would be ok, however there's a couple of issues - it calls charge_stop and discharge_start every time it wants to export; in powerwall case those unset and reset the same object; if the 2nd unwanted inverter call does the same thing a few seconds later the powerwall gets very confused. second I think it sometimes calls discharge_stop on what it thinks is inverter2 before inverter1 - which is reasonable, as inverter2's batt can go low much more quickly... but I will deal with that in HA. I don't want it to stop inverter 1 by bad logic (which is exactly what its doing!).
the import/export energy/load after a bit of templating in HA, I have working well enough for the plan to be measuring calculating the right energy transfer numbers, which is why I wanted to configure a second genuine inverter rather than a fake car as I had before.
cross charging control is a non-requirement for me, I am dealing with that in my HA automations that control the 2nd inverter.
I have set as many things to False as I can including "has_service_api" which I thought would be the one to do it, but it doesn't.

The issue is there is no way to stop it sending using the same config block to send commands to both inverters.
Even if I did want it to control both inverters, the commands would be different, as they are different types. So it does seem as though there needs to be way to have the control block in sections, separated by inverter.....

Is there a way to pass inverter ID or name as a variable into the control block? Then rather then executing the inverter commands from predbat. I would execute them from a HA script called by the control block, which would in turn read the inverter ID and therefore be able to fork to a "do nothing" branch if called with inverter 2 ID.

[gcoan]

have set as many things to False as I can including "has_service_api" which I thought would be the one to do it, but it doesn't.

The issue is there is no way to stop it sending using the same config block to send commands to both inverters.
Even if I did want it to control both inverters, the commands would be different, as they are different types. So it does seem as though there needs to be way to have the control block in sections, separated by inverter.....

Is there a way to pass inverter ID or name as a variable into the control block? Then rather then executing the inverter commands from predbat. I would execute them from a HA script called by the control block, which would in turn read the inverter ID and therefore be able to fork to a "do nothing" branch if called with inverter 2 ID.

has_service_api is actually a no-op in the Predbat code, Predbat determines whether to call the service operations based on the presence of the service call settings in apps.yaml. Its only there for backwards compatibility.

Yes a better solution would be some form of inverter id passed through, but that's a future enhancemnt request.

Bear in mind that Predbat is not controlling the inverters individually, it aggregates the fleet and then sends the same instructions to the fleet, so at the moment there isn't really the need for this as all inverters are set to charge, to discharge, etc. Improving multi inverter support is on the to-do list.

Predbat always cycles round the inverters in sequence 0, 1, etc so your thought that inverter 1 was processed before 0 isn't correct,

What you might be best doing is to just have a single control script that predbat executes and then in that execute the commands you need for all inverters. Probably dropping down to just a single inverter config and aggregating the settings (soc, charge rate, etc) as you have done for load, import, etc would then remove the stop before charge controls that confuse the powerwall.

[sandyman44]

thanks for confirming its a no-op. I'll work on moving the control tasks into HA script(s) and have predbat call those, hopefully I can get that to behave better. I'll update if/when I have progress.

[sandyman44]

going to answer my own question here: I now run

  charge_start_service:
    - service: script.turn_on
      entity_id: script.chargestart
      repeat: True
  charge_stop_service:
    - service: script.turn_on
      entity_id: script.chargestop
      repeat: True
  discharge_start_service:
    - service: script.turn_on
      entity_id: script.dischargestart
      repeat: True 
  discharge_stop_service:
    - service: script.turn_on
      entity_id: script.dischargestop
      repeat: True

and the HA scripts deal with what to do with each inverter, deal with flip-flopping / arguing, etc. This is now working reasonably well.