Fox ESS AC1+ECS4100 h7 - Known working configuration example (UK Octopus Cosy)

[PeterHaban]

After spending over a year to install solar panels, inverter and battery I have taken the plunge and moved to Octopus Cosy. I found Predbat shortly after, some of the Fox ESS examples were a bit out of date so I've taken a bit of time to build my own and wanted to share it in case anybody else might find it useful. It runs off the work modes and charge_rate/discharge_rate, I've had it running for over two weeks now and works perfectly including free electricity sessions, I don't export.
I'm sure there is more room for improvement e.g. I can't get the battery curve to work yet but this should be a good starting point to easily get the basics up and running, all feedback welcome :)

foxess ac1.txt

[Wiggy93]

Going to use this as a starter for my apps.yaml - is there any reason you used the min soc on grid, rather than min soc entity?

[PeterHaban]

Hope it gets you up and running :) The section below came from the original Fox template, not played with it yet.

reserve:
- number.min_soc_on_grid
battery_min_soc:
- number.min_soc

[gcoan]

I'm happy to merge this into the Predbat documentation, and sorry @PeterHaban that it got overlooked before

Looking at the reserve definitions in the apps.yaml, it's not right.

In the inverter definition, the 'reserve' line will be ignored as its not part of the expected inverter definition:

inverter_type: FoxESS
  inverter:
    name: "FoxESS"
    has_rest_api: False
    has_mqtt_api: False
    has_service_api: True
    output_charge_control: "power"
    has_charge_enable_time: False
    has_discharge_enable_time: False

    # Theoretically Target SoC should be configured with number.max_soc but this causes issues because
    # target_soc is not automatically reset to 100% after use by switch.predbat_inverter_soc_reset, and
    # this blocks all charging.
    has_target_soc: False

    # Reserve SoC will be configured with number.min_soc_on_grid
    has_reserve_soc: True
    reserve: number.foxess_min_soc_on_grid

Then later on down, when the reserve is defined in the predbat section:

  # I'm setting reserve manually via a number helper
  reserve:
    - input_number.reserve

This isn't going to do anything either !

Predbat is expecting reserve to be configured to point to an inverter control that predbat can use to set the battery reserve level so it should be configured to an entity on the inverter.

If the inverter doesn't have a reserve then this can be omitted and 'has_reserve_soc' in the inverter definition is set to False.

If you don't export then probably you won't have noticed that this isn't working right.

be useful if you can give some more detail of the input_numbers and templates you used to get this working and what values you set them to

[Wiggy93]

The sensor.foxess_bms_kwh_remaining is output by the FoxEss modbus integration - essentially its the max soc in kWh taking the battery SOH (state of health) into effect from the nomincal capicity when new. I think from memory its something calculated by the BMS and the integration reads it from one of the modbus registers. An example (with unrealistic numbers for simplicity):

• Nominal capacity of 100 kWh
• SOH of 91.5%
• sensor.foxess_bms_kwh_remaining would be 91.5 kWh which would be the max energy able to be held by the battery.

FoxESS as an inverter type is already coded into Predbat so doesn't need to be repeated in the apps.yaml. I checked and your definition was the same as the predbat one

To clarify, the following doesn't need to be included? As its essentially duplicating the natively held inverter within predbat?

inverter: name: "FoxESS" has_rest_api: False has_mqtt_api: False has_service_api: True output_charge_control: "power" has_charge_enable_time: False has_discharge_enable_time: False has_target_soc: False has_reserve_soc: true charge_time_format: "S" 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: 2 has_time_window: False support_charge_freeze: true support_discharge_freeze: true

With regards to the note on the template apps.yaml, the kW --> W helper converters aren't required anymore, a predbat update enabled either W or kW to be used. The predbat docs already have this distinction listed.

[gcoan]

The sensor.foxess_bms_kwh_remaining is output by the FoxEss modbus integration - essentially its the max soc in kWh taking the battery SOH (state of health) into effect from the nomincal capicity when new.

Thanks for the explanation and worked example, I thought it might have been battery available capacity which varied based on SoC.

So this sounds fine to be used for soc_max, I'll update the template and take the bit about kW->W conversion not being needed any more. Predbat is more relaxed about the entities it is given in more recent releases.

FoxESS as an inverter type is already coded into Predbat so doesn't need to be repeated in the apps.yaml. I checked and your definition was the same as the predbat one
To clarify, the following doesn't need to be included? As its essentially duplicating the natively held inverter within predbat?

Correct. In config.py is the definitions of the inverter types Predbat knows about, simply defining inverter_type as FoxESS is all you need to do and I suspect that configuring it in apps.yaml, it gets ignored anyway.

I'm personally probably leaning to not configuring more inverter types in the Predbat code. Having the configuration options exposed means people can expand their inverter config (things like freeze charge) with newer inverter firmware, or by writing automations to handle the inverter states better. We've done this with other new inverters added to Predbat. But since FoxESS is already coded in, might as well use it.

soc_kwh_remaining template?

[PeterHaban]

If we're after a static number that is the battery capacity then sensor.foxess_bms_kwh_remaining feels like a good choice, it shows how many kwh the battery can hold at 100% and will get adjusted down by the BMS as the battery ages. I've set up the following template for sensor.foxess_soc_kwh_remaining:
{{ ((float(states.sensor.foxess_battery_soc.state)/100) *float(states.sensor.foxess_bms_kwh_remaining.state)) }}

I'm running without the W/kW conversion addon, all working ok so don't think that's needed anymore.

I've also looked at the sensors for my charge curve, I get history ok for all four sensors (screenshot below) and charge up to 100% every night:

• sensor.foxess_battery_soc
• number.foxess_force_charge_power
• predbat.status
• sensor.foxess_invbatpower

[gcoan]

thanks I have added sensor.foxess_bms_kwh_remaining for soc_max in the template, removed the input number helper and the W/kW conversion YAML note, and added the template sensor helper to the inverter setup.

After more looking at the code I think I have found why you are not getting charge curves generated. Its because you have battery_rate_max set to 14112W in apps.yaml and Predbat is trying to find the curves from where your charging rate reaches 95% of this max, which from the graphs it never does. Is this a config error?

You won't get a discharge curve generated as the battery needs to be discharged down to between 5 and 20%.

[Wiggy93]

I guess if you have enough batteries and the voltage is high enough, the battery theoretically could charge at 14kW. However unless you have a beast of a solar array and inverter to match, doubt you'd ever get to 95% of that. I'm guessing Peter's inverter, like mine, will be the limiting factor of charging power of 5000W from the grid at this time of the year if you're in the northern hemisphere.

Have another few days of getting the predbat status history before I'm hoping my charge cure gets auto calculated

[PeterHaban]

I've changed my battery_rate_max to 5000W and turned off switch.predbat_set_charge_low_power so fingers crossed that will get me a charge curve, any hints on how many days of data it will need? I assume once I get my charge curve I can put it into the battery_charge_power_curve section and turn the low power charging back on?

[Wiggy93]

2025-12-19 10:13:56.136186: charge curve can be entered into apps.yaml or set to auto: battery_charge_power_curve: 100 : 0.01 99 : 0.01 98 : 0.37 97 : 0.46 96 : 0.52 95 : 0.48 94 : 0.53 93 : 0.67 92 : 0.68 91 : 0.68 90 : 0.68 89 : 0.68 87 : 0.96

Thanks so much for your help, finally got there. My discharge curve is more or less a straight line down, so leaving that alone for now.

Regarding the docs the apps.yaml description is really clear now, very helpful.

Only changes I would make are in the fox.yaml, line 161, I think PeterHaban is using a custom sensor there. The standard fox inverter home assistant integration people use (and now seen you've referenced in the commit) has a sensor.foxess_pv_power that outputs the solar power in kW.

[PeterHaban]

I think I've managed to get there as well over night, seems to just need a very simplistic little adjustment over 86%:
charge curve can be entered into apps.yaml or set to auto:
charge curve before adjustment is: {86: 0.98}
Find charge curve has 11.0 days of data, max
I'm tempted to let it run a few nights to see if it consistently comes up with the same.

As for the PV incoming sensor I'm indeed not using the one from the integration, I've got the AC inverter so my panels are not connected to it. I've got enphase microinverters behind each panel, then all coming into the consumer unit on one aggregated feed and I'm monitoring that with an ESPHome flashed EmporiaVue2.
Glad to see it's all working well and should give a very good starting point to anyone else with a Fox inverter setting this up🙂

[gcoan]

Regarding the docs the apps.yaml description is really clear now, very helpful.

thanks, I have just updated the apps.yaml again to expand the max_battery_rate description to highlight the interlink to charging curves - which is the specific issue you both had. Glad that this is sorted now.

Only changes I would make are in the fox.yaml, line 161, I think PeterHaban is using a custom sensor there. The standard fox inverter home assistant integration people use (and now seen you've referenced in the commit) has a sensor.foxess_pv_power that outputs the solar power in kW.

done. I have put the foxess sensor in, and added a note for AC coupled Fox's that a separate solar monitor will be needed.
Is there a foxess sensor for pv_today energy, and also grid_power that I can put in the template and denote where to be changed for AC-coupled?

[Wiggy93]

• sensor.foxess_solar_energy_today (daily PV total)

Fox inverters separate the grid import/export into the below, I've ended up using my zappi charger ct clamps to give a single postive or negative number to indicate import/export power in predbat. An alternative would be to make a template sensor I guess looking at something like
if import > 0 {{ sensor.foxess_grid_consumption | float }} elif export > 0 {{ sensor.foxess_feed_in | float}}
(aware pseudo code is pants syntax, sorry).

• sensor.foxess_grid_consumption (Grid import Power in kW)
• sensor.foxess_feed_in (Grid export power in kW)

[gcoan]

Thanks both, have updated the template and setup instructions with the grid power template sensor