2 Car Charging Question

[hnb2907]

Hi,

I'm trying to work out if this is possible with predbat, and after some experimentation I've got a bit confused.

Quick overview...
I've been successfully using predbat with octopus agile and fixed export. Equipment is a foxess inverter+solar+battery using modbus/RS485. It's been working really well since everything was installed in April this year.

What I'm now trying to achieve...
Set up 2x physical car chargers, but each with slightly different requirements. They can charge concurrently. I don't want either to drain the battery. I am trying to configure charging as "predbat led"

Been using the predbat car charging documentation. Also #3001, for inspiration for %/kWh conversion, 2 car setup etc.

Car 1

• Must charge in a single block of cheapest rates 30min periods, multiple charger output on/off's are not acceptable
• Charger has entities for power kW, energy kWh (does not reset to 0kWh at start of each charging session)
• Entities for initial SOC%, maximum/target SOC%, will be set at 20:45 each night for the following charge window
• Charging must be completed by 16:00 the next day

Car 2

• Can charge using any lowest rates periods, multiple charger output on/off's are acceptable
• Charger has entities for power kW, energy kWh (resets to 0kWh at start of each charging session)
• Entity for initial SOC%, will be set manually in HA roughly at the time I plug the car in (or later)
• Maximum/target SOC% will always be 100% (27.7kw)
• Charging must be completed by the time set in a date/time entity, this will be set manually in HA roughly at the time I plug the car in (or later)
• If the average temperature is <10c (from the metoffice integration) for 3 hours before desired end time, force the charger on for 2hours immediately before the desired end time, and shift the charging window to end 2 hours earlier (this is probably best done in another automation outside predbat?)

This is what I've got so far...

 num_cars: 2
  
 car_charging_energy: 
    - sensor.car1_energy
    - sensor.vec01_energy_session

  car_charging_planned:
    - switch.car1_charger_on
    - sensor.vec01_status_connector
    
  # switch.car1_charger_on returns "on"
  # sensor.vec01_status_connector returns "Preparing", and "Finishing" to allow restart charging from multiple periods
  car_charging_planned_response:
    - 'on'
    - 'Preparing'
    - 'Finishing'
   
# car_charging_now:
   
  car_charging_battery_size:
    - 11.3
    - 27.7
   
  car_charging_limit:
    - input_number.car1_charger_max_charge
    - 27.7
  
  car_charging_soc:
    - input_number.car1_initial_charge
    - input_number.car2_initial_charge
  
  car_charging_exclusive:
    - False
    - False

  watch_list:
    - input_number.car1_initial_charge
    - input_number.car2_initial_charge
    - input_number.car1_charger_max_charge
    - input_datetime.car2_ready_time
    - sensor.vec01_status_connector

All of the entities should be the correct type, and predbat doesn't throw any errors regarding the configuration.

For now, the main items I'm having trouble understanding are:

• How to configure car 1 to charge in a single contiguous block of cheapest rates rather than multiple cheaper periods, -and- car 2 charging with the cheapest available periods
• How to configure car 1 and car 2 to finish at different times, as I've only found a single select.predbat_car_charging_plan_time for 1 car?

Alternatively, I have been considering if it's possible to mimic the octopus entities for 2 cars, and configure predbat for octopus-led charging for both? This is currently beyond my knowledge of HA, predbat, and bottlecapdave's octopus integration!

Any thoughts please? :)

Cheers,
Chris.

[gcoan]

If the average temperature is <10c (from the metoffice integration) for 3 hours before desired end time, force the charger on for 2hours immediately before the desired end time, and shift the charging window to end 2 hours earlier (this is probably best done in another automation outside predbat?)

This bit definitely is beyond Predbat, you'd be better to try this in an automation

How to configure car 1 to charge in a single contiguous block of cheapest rates rather than multiple cheaper periods, -and- car 2 charging with the cheapest available periods

There isn't this kind of fine control in predbat led charging for a single car let alone two with different requirements, sorry. Predbat will select the cheapest blocks to charge your car to reach the target SoC(s) by the finish time, holding or charging your battery to stop it discharging into the car.

How to configure car 1 and car 2 to finish at different times, as I've only found a single select.predbat_car_charging_plan_time for 1 car?

As you've found, there is only a single car charging plan time. It could well be possible to extend this in predbat for multiple car finish times as the other key Predbat car charging entities have multiples for multiple cars.

Trying to emulate the Octopus led charging when you are not on IOG is going to be a real challenge to format the sensors correctly I'd think. Am not sure it handles multiple cars either.

[hnb2907]

HI gcoan,

Thanks for the fast reply, that confirms what I thought I'd found. Hopefully you could help me understand if there's another method of implementing something with predbat and some automations.

So, let me describe my current working config.

Actually car 1 is a storage heater, with the "economy 7" supply controlled by a contactor via an esphome device. I've modelled it in predbat as a car, so it does not form part of the house load, and also to trigger predbat from discharging the battery into the heater. Predbat is monitoring an output from the esphome device, showing if the contactor is on/off, and a kWh energy sensor.

I have a HA octopus "target rate" sensor. At 20:45 daily, an automation populates the "hours required", using a formula based on metoffice 24h hour average temperature forecast, and previous 24h average room temperature. This then controls the esphome contactor to charge up the storage heater on the cheapest block found by the target rate sensor. The target rate sensor has a start and end times of 21:00 and 16:00 respectively.
The target rate sensor leads for "car" charging, by controlling the esphome device, and predbat reacts to it.

This has been working with predbat very well, with 2 small downsides that I can live with:

1. predbat doesn't know the forecast of when the target rate sensor will enable the contactor.
2. for the first few minutes after the contactor is enabled, the battery might be discharged into the heater while predbat recalculates the plan and controls the inverter away from "Demand" mode.

  num_cars: 1

  car_charging_energy: 
    - sensor.sonoff_dualr3_garage_heater_heater_offpeak_runtime_kwh

  #car_charging_planned:
  #  - binary_sensor.sonoff_dualr3_garage_heater_heater_offpeak_contactor_enabled
  
  car_charging_now:
    - binary_sensor.sonoff_dualr3_garage_heater_heater_offpeak_contactor_enabled
   
  car_charging_battery_size:
    # 7.5hours at 1.5kw
    - 11.3

  watch_list:
    - binary_sensor.sonoff_dualr3_garage_heater_heater_offpeak_contactor_enabled

In the example in my first post, I was trying to remove the target rate sensor for the heater, and instead have predbat lead charging of both the heater and EV. I'm happy to keep the target rate sensor for the heater and have predbat react to it.

I've now had an EV charger installed. This needs to be led by predbat. I always want it to charge to 100%. I was hoping to use #3001 as the starting point.

I did have a look at predheat, but couldn't work out exactly how to configure it for the heater, and whether it could enable the contactor in a single block of cheap rates.

I've also tried to create a new target rate sensor for the EV charger, put some automations around it, and have predbat react to the charging state of the charger. However, the target rate sensor cannot set an end time for "tomorrow", before the agile rates are published "today", whereas predbat has more future plan prediction.

As I see it there's possibly 2 options...?

1. Is it possible for predbat config to keep the existing car 1 config (target rate sensor led), and adding in car 2 (EV charger led by predbat)?
2. Or is there some other method where I can get predbat to ignore the kWh load history from the heater, and trigger the inverter away from "Demand" when the heater contactor is enabled? Then I could just config predbat car 1 to lead controlling the EV charger.

Cheers,
Chris.

[gcoan]

thanks for the fuller explanation of what you are trying to do, I understand now better the requirement and why you have two "cars" with different charging profiles.

I'll have a ponder about the best way to solve this for you, when I've not had several glasses of wine ...

But to answer a few of your other questions:

• predheat isn't the answer I don't think. It is designed to model electric (or gas) heat demand based upon outside temperature forecast and historic heat loss and then feed that in as extra home demand into the predbat model so predbat can plan the battery charging to meet that demand.

• you mentioned Octopus target rate sensors, are you using them in the Octopus integration or have you moved over to Bottlecapdave's Target Timescales integration which is where he is intending to maintain this functionality going forward. I use these myself for forecasting when to put the dishwasher, washing machine on.

• excluding heater load from the historical forecast is easy, you can either create a custom template sensor that subtracts heater load from house load, or you can add the heater load in as a car charging energy entry in apps.yaml (as well as your real car charging energy) and Predbat will exclude that from the historical forecast.
  I do the former so I can see house load separate from heat pump load in my dashboards, but I use the total load figure for predbat so it has the fuller view of historical demand

Cheers Geoffrey

[hnb2907]

Hi again,

Been pondering further myself.

I'm using the old-fashioned target rate sensors in bottlecapdave's octopus integration. TBH the sensor for the heater was setup a couple of years ago, and as it's working I've not checked the documentation recently to find out about the newer target timescales.

I'm thinking along the lines of suggestion 2, to have predbat lead control of the EV charger, and bodge the heater elsewhere.

I haven't tried this yet, would this possibly work?

  ## from https://github.com/springfall2008/batpred/issues/2267
  charge_start_service:
    - service: select.select_option
      entity_id: select.work_mode
      option: "Force Charge"
    - service: number.set_value
      entity_id: number.max_discharge_current
      value: "40"
  charge_stop_service:
    - service: select.select_option
      entity_id: select.work_mode
      option: {{"Self Use" if ((states('sensor.garage_heater_power')|int)<400) else "Back-up"}}
    - service: number.set_value
      entity_id: number.max_discharge_current
      value: "40"
  discharge_start_service:
    - service: select.select_option
      entity_id: select.work_mode
      option: "Force Discharge"
    - service: number.set_value
      entity_id: number.max_discharge_current
      value: "40"
  discharge_stop_service:
    - service: select.select_option
      entity_id: select.work_mode
      option: {{"Self Use" if ((states('sensor.garage_heater_power')|int)<400) else "Back-up"}}
    - service: number.set_value
      entity_id: number.max_discharge_current
      value: "40"
  discharge_freeze_service:
    - service: select.select_option
      entity_id: select.work_mode
      option: "Feed-in First"
    - service: number.set_value
      entity_id: number.max_discharge_current
      value: "40"      
  charge_freeze_service:
    - service: select.select_option
      entity_id: select.work_mode
      option: "Back-up"
      ##set the discharge current to 0A in backup mode, to prevent discharging the battery when PV<load, use grid instead (e.g. overnight)
      ##think this is because backup mode isn't working as described in the inverter f/w v1.49/1.23/1.02
    - service: number.set_value
      entity_id: number.max_discharge_current
      value: "0"     


 num_cars: 1
  
 car_charging_energy: 
    - sensor.garage_heater_energy
    - sensor.vec01_energy_session

  car_charging_planned:
    - sensor.vec01_status_connector
    
  # sensor.vec01_status_connector returns "Preparing" for first charge, and "Finishing" or "SuspendedEV" to allow restart charging for multiple periods
  car_charging_planned_response:
    - 'Preparing'
    - 'Finishing'
    - 'SuspendedEV'
   
# car_charging_now:
   
  car_charging_battery_size:
    - 27.7
   
  car_charging_limit:
    - 100
  
  car_charging_soc:
    - input_number.car_initial_charge
  
  car_charging_exclusive:
    - False

  watch_list:
    - input_number.car_initial_charge
    - input_datetime.car_ready_time
    - sensor.vec01_status_connector
    - binary_sensor.sonoff_dualr3_garage_heater_heater_offpeak_contactor_enabled
    - {{(states('sensor.garage_heater_power')|int)>400}}    

I think it should do this:

• Predbat lead charging of the EV only, and indirectly reacts to the heater
• Subtract the 2x energy entities for heater and EV, from the house load
• Trigger a plan recalculation on any entity changing regarding the EV parameters, and charger status, or if the heater contactor switches on/off
• Trigger a plan recalculation if the heater watts >400 is this allowed in app.yaml "{{(states('sensor.garage_heater_power')|int)>400}}" ?
• For "charge_stop_service" and "discharge_stop_service", if the heater power watts is >400 set the inverter to "Back-up" mode, otherwise "Self-Use". Would the "{{"Self Use" if ((states('sensor.garage_heater_power')|int)<400) else "Back-up"}}" work in apps.yaml?

Does this sound like a potential solution?

Enjoy your wine! :)

Cheers,
Chris.

[hnb2907]

Nice one, thanks for your guidance.
I'm not a yaml or ninja expert, so I'm not always sure when you can('t) inline it.

Give me a day or 2, and I should have some time to have a go at the scripting. If I get it working, I'll try to do a write up for the "show & tell".

Cheers,
Chris.

[gcoan]

One other thing I thought about overnight,

There is a gap in the current solution that Predbat will set the inverter mode depending on whether the heater is on or not when it goes through stop charging or stop discharging, but I think your 'start heating' command also needs to set the inverter mode as well otherwise (a) Predbat will always be in catchup and you'll get some battery discharge into the heater until Predbat does catch up, and (b) if Predbat doesn't identify it needs to stop charging/discharging then the inverter mode won't be set.

What I suggest you need to do is have the heating start in an automation script and that script can set the inverter mode to stop discharging the battery before the heater gets turned on.

And you could have the inverse in a stop heating script

[hnb2907]

Good thinking.

If I'm following you correctly, I already see this behaviour for a few minutes in the current implementation where predbat reacts to the heater contactor status in the watch_list. It takes the duration of a re-plan to set the inverter, which I mentioned in an earlier post. This only takes a few minutes for the correct inverter mode to be set, and I can live with it.

Currently part way through implementing the foxess inverter mode script, so I'll see what happens... :)

Ta,
C.

[gcoan]

Do share the script if you want a second viewing

Cheers

[hnb2907]

You're correct, I do need an automation triggered by the contactor changing on/off. I have the automation checking if predbat is in demand mode, and checking the heater power watts >400, then calling the script to set the inverter to "Self Use" or "Back up" work mode as required. (Probably because predbat doesn't run the script again if it is already in demand mode).

The same script is being called to control the inverter in apps.yaml.

Everything seems to be working, with some quick testing. It's actually faster than my original implementation, as it doesn't need to wait for a predbat plan recalculation to set the inverter.

I suspect this method of using "Back Up" mode (i.e. grid use) when the heater is charging and predbat thinks it's in Demand ("Self Use" battery mode), will cause some errors in the plan cost forecast, I can live with that.

Next, adding the EV charger stuff, similarly to #3001

Thanks again,
C.