springfall2008
Predbat costing not saving money
- I have a Fox ESS Inverter,
- Fox EP5 x3 batteries = 15kW
- 4.4 kW solar array
- Solcast fairly accurate
- Predbat in "control charge" mode
See attached plan + yaml. Octopus cosy so 3 tariffs. I need a little help - or is this a bug?
You can see in the yaml that predbat wants to charge the battery between Tues 9am and 4PM at both the cheapest and middle rate tariff. During every 30 minute slot there's enough PV to cover the load plus spare to fully charge the battery by the expensive period starting at 4PM.
I don't understand why in control charge mode it's importing energy from the grid when there's plenty of PV to cover load + charge. I think it's because it's treating the cheapest slot as an opportunity to import cheap with the intention of exporting higher later but (from what I understand) control charge mode should prioritise filling the battery from PV + import if it needs to ignoring potential offset value.
Secondly, I'm baffled as to why predbat seems obsessed with keeping the charge level at 100% which is also costing money.
Help/wisdom appreciated, I'm sure I'm missing something.
Predbat in "control charge" mode
Any reason that you aren't letting it also discharge?
I would suggest experimenting with some of these changes. Try them one at a time to see if they help.
has_reserve_soc: False
reserve:
- 2
Try changing to has_reserve_soc: true with
reserve:
- number.min_soc_on_grid
battery_min_soc:
- sensor.min_soc
Reserve is needed to pause charging/discharging. If you don't have it, then I found that the system can't constrain the charging, and the battery will go to 100%. Predbat will set the minimum soc so that the charge or discharge can stop at a configurable level. If it is hardwired to a number then it cannot do that. It is min_soc_on_grid because that is what the backup-mode (charge_freeze_service) uses.
battery_min_soc would be 10% since the Fox batteries are 90% DoD. Predbat will not change this (but it will change min_soc_on_grid as it pauses charging/discharging)
support_discharge_freeze: False
discharge_freeze_service:
service: select.select_option
entity_id: select.h1_g2_work_mode
option: "Feed-in First"
I would suggest that support_discharge_freeze should be true here, since the discharge_freeze_service is configured.
The battery temp won't affect things at the moment, hence won't be relevant to your current issue, but might be more relevant in midsummer and midwinter. Note that relatively recent firmware might be required to read these. If you have older firmware, leave them commented out.
# Battery temperature sensor per inverter, used outside REST mode to get current temperature
#
#battery_temperature:
# - sensor.givtcp_battery_stack_1_bms_temperature
# - sensor.givtcp2_battery_stack_1_bms_temperature
battery_temperature:
- sensor.bms_cell_temp_low
battery_temperature_history:
- sensor.bms_cell_temp_low
Try commenting inverter_battery_rate_min out, I don't think it is needed for the Fox batteries. But is unlikely to be relevant to your current issue.
# 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
Similarly I don't think this will affect your current issue, but I see no harm in allowing threads. Might depend on your hardware.
# 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
Also unrelated, but depending on firmware version, there is a sensor which will supply the nominal capacity (this is the larger figure including the min_soc, the usable capacity is less) as modified by state-of-health. So as the years go by, the sensor will start reporting slightly lower numbers as the battery SoH drops. This is only on recent firmware.
On older firmware, sensor.bms_kwh_remaining holds the current state-of-charge in kWh, which is completely different., in which case leave the soc_max as the battery's nominal capacity (before the 90% DoD calculation).
soc_max:
- 15.54
soc_max:
- sensor.bms_kwh_remaining
And therefore needs a helper template sensor to provide the SoC in kWh.
soc_kw:
- sensor.tonyhoyle_bms_actual_kwh_remaining
sensor.tonyhoyle_bms_actual_kwh_remaining
{{ ((states('sensor.bms_kwh_remaining')|float) * (states('sensor.foxess_battery_soc_exact')|float / 100)) | round(3) }}
If you have the older firmware, if you ever get a firmware update you might need to revisit this.
Not sure if you might need these (perhaps they are defaulted if not supplied). I think it is also possible to use an input_number here, in case you want to adjust them on the fly with an automation.
# Maximum speed of the inverter for charging and discharging the battery, for Fox this will be the same as the inverter_limit.
inverter_limit_charge:
- 3600
inverter_limit_discharge:
- 3600
You can see in the yaml that predbat wants to charge the battery between Tues 9am and 4PM at both the cheapest and middle rate tariff. During every 30 minute slot there's enough PV to cover the load plus spare to fully charge the battery by the expensive period starting at 4PM.
Predbat is letting the battery charge (SoC is increasing), but its not charging the battery from grid, its charging from solar - you can see that there is no cost incurred and the total cost is not increasing. The only bit of import is 4p of import in the 13:00 slot, at the lowest Cosy rate, and then once the battery is full the excess solar is exported, you can see negative costs and the total cost is decreasing.
You can see in the yaml that predbat wants to charge the battery between Tues 9am and 4PM at both the cheapest and middle rate tariff. During every 30 minute slot there's enough PV to cover the load plus spare to fully charge the battery by the expensive period starting at 4PM.
Predbat is letting the battery charge (SoC is increasing), but its not charging the battery from grid, its charging from solar - you can see that there is no cost incurred and the total cost is not increasing. The only bit of import is 4p of import in the 13:00 slot, at the lowest Cosy rate, and then once the battery is full the excess solar is exported, you can see negative costs and the total cost is decreasing.
thank you, that makes the plan look more sensible (that's confusing for a gormless newbie). I'll try out the suggestions in the first reply and report back.
Can you attached the debug yaml for your **plan?
**
Attached.