Predbat overwriting FoxESS Modbus sensor

[david00yates]

Describe the bug
When in Control Charge mode, predbat overwrites the battery charge sensor with a state value of 2600 and blanks the state attributes
This is with the FoxEss Modbus integration

Expected behaviour
From what I can work out predbat should be reading this sensor value, not writing to it

Predbat version

v8.13.0

Environment details

• FoxEss H1-5.0-E-G2 inverter, 2x EP5 batteries
• HAOS running predbat as an add-on
• FoxEss Modbus integration

Log file

predbat.log

Predbat debug yaml file

predbat_debug_16_45_00.yaml.txt

[WyndStryke]

My guess is that predbat was expecting to be given the modbus force charge power (number.force_charge_power) entity, which controls the charge rate. Although note that it is kW rather than W.

[david00yates]

It would be good to understand what the purpose of charge_rate and discharge_rate are. It's not clear from the documentation but it does look like these should be to control the charge rate, in which case I have configured my instance incorrectly.

I'll change the config and update on the results

[gcoan]

the charge rate and discharge rate in apps.yaml should point to entities that:

• tell Predbat what the current inverter charge and discharge rate is
• enable Predbat to change the inverter charge and discharge rate

I can add something more to the documentation if its not clear?

[WyndStryke]

This is what I have from the integration (Nathan's FoxESS modbus, since there may be others)

• sensor.bms_charge_rate (Amps, maximum possible charge rate from the BMS - this may further be limited by the inverter, purely a sensor and should not be written to. The temperature vs charge rate curve, and the SoC vs charge rate curve, will both be reflected here, using the max_charge_rate as the reference, so when the temp is very low, or the SoC is very close to maximum, this will drop)
• sensor.bms_discharge_rate (Amps, maximum possible discharge rate from the BMS - this may further be limited by the inverter, purely a sensor and should not be written to)
• number.force_charge_power (kW, how to control the charge rate when force-charging, this is the one that predbat should be writing to)
• number.force_discharge_power (kW, how to control the discharge rate when force-discharging, this is the one that predbat should be writing to)
• number.max_charge_current (Amps, theoretical maximum from the battery stack, will be further limited by the BMS and inverter)
• number.max_discharge_current (Amps, theoretical maximum from the battery stack, will be further limited by the BMS and inverter)
• sensor.battery_charge (kW, instantaneous measurement of what the battery is charging right now, purely a sensor, should not be written to)
• sensor.battery_discharge (kW, instantaneous measurement of what the battery is discharging right now, purely a sensor, should not be written to)
• sensor.inverter_battery_power (kW, instantaneous measurement of what the inverter is drawing or sending to the battery, can be positive or negative, purely a sensor, should not be written to)
• sensor.inverter_power (kW, instantaneous measurement of what the inverter is converting, can be positive or negative, purely a sensor, should not be written to)

Internally everything is based around amps. So when the battery voltage drops, everything else will drop alongside it.

So for example, I have a 7kW inverter, my bms charge rate is 35A (currently limited by temperature), and my bms discharge rate is 50A, the max charge current is 50A, the max discharge current is also 50A, but in reality my upper limit is 7kW which is 28A because of the inverter. So despite the max charge rate being 50A, I'll never be able to charge the battery that quick with a mere 7kW inverter.

There are lots more modbus registers, I have only illustrated the ones directly related to the charge/discharge speed. There are also plenty of registers which the integration does not expose (most likely because people haven't asked for them), but can be queried directly if needed, I think the ones relating to the inverter's own maximum charge/discharge limits are an example of these. If there's a sensor you need, that currently isn't exposed, ask on their github, and if they can read it, they'll publish it. The registers can be different from one model to another, and one firmware to another, so it's not necessarily straightforward (i.e., it may take a while).

[david00yates]

For clarity it is Nathan's Modbus integration I am using.

[springfall2008]

Do we need support for the charge/discharge rate to be in kW too? Could we use the amps version of it also?

[WyndStryke]

Easy to convert between kW and W in a helper, it might already be doing that? (You mentioned that the kW pv_power sensor which I complained about a couple of weeks ago #1870 is converted to W in history, so I'm guessing the others are likely to do the same).

I'm using predbat in read-only mode, and it seems to be fine as far as that is concerned. I can pick up predbat's outputs and use that in my own automations. Perhaps @david00yates can feed back on wh hether the Fox Modbus integrations force_charge_power and force_discharge_power inputs are working as expected, or if they are getting confused about kW vs W.

I have some doubts about the fox.yaml template, in particular it doesn't let predbat put the inverter into Fox's "feed-in first" mode to allow PV to be directly exported rather than being stored in the battery, and I don't think it sets up all the available sensors. I was going to experiment with that but haven't had time. It works at a MVP level at least.

Internally the inverter usually runs on timed charge slots, although the integration doesn't really support that yet and just sets the workmode as needed. I might take a look at your recent work on that and write it up as a feature request for the integration. From your viewpoint is it preferable to run that way, or just set the workmode?

One complication is that it seems to be write-only on many of the charge slot registers exposed via modbus. We can see that a charge slot is running on the inverter, figure out the start time and end time, can initiate our own charge time charge slots, but can't see the workmode or charge/discharge rates or SoC limits associated with that slot if it had been created from outside the integration (e.g., if the schedule was running via the cloud or the app). So to some extent we're working blind.

We actually have the same issue with the workmode. The integration can't read it, and therefore keeps track of the commanded workmodes instead. This works fine as long as the integration is the only thing controlling the inverter.

number.max_charge_current (Amps, theoretical maximum from the battery stack, will be further limited by the BMS and inverter)
number.max_discharge_current (Amps, theoretical maximum from the battery stack, will be further limited by the BMS and inverter)

Regarding amps, I can see these have been set up as a 'number' rather than as a sensor, but as far as I know I don't think we need to write to them. So I don't know why they are configured that way, maybe I'm wrong about them being read-only.

[bfayers]

The number entities for max charge/discharge current are write-only. You would need to be looking at sensor.invbatcurrent (negative when charging) or sensor.bat_current (negative when discharging) or sensor.invbatpower (negative when charging, value in kW) to get the values for instantaneous charge/discharge

As for @gcoan 's comment about these:

the charge rate and discharge rate in apps.yaml should point to entities that:

• tell Predbat what the current inverter charge and discharge rate is
• enable Predbat to change the inverter charge and discharge rate

I'm really not sure how you could configure those on a fox setup? Personally at the moment I have these settings:

  charge_start_service:
    service: select.select_option
    entity_id: select.work_mode
    option: "Force Charge"
  # charge_stop_service:
  #   service: select.select_option
  #   entity_id: select.work_mode
  #   option: "Self Use"
  charge_stop_service:
    service: script.inverter_self_use_40a_charge_discharge #Script to set work mode to Self Use and number.max_charge_current / number.max_discharge_current to 40A.
  charge_freeze_service:
    service: number.set_value
    entity_id: number.max_charge_current
    value: 0
  discharge_freeze_service:
    service: number.set_value
    entity_id: number.max_discharge_current
    value: 0
  discharge_start_service:
    service: select.select_option
    entity_id: select.work_mode
    option: "Force Discharge"

  charge_rate:
    - input_number.force_charge_power_watts
  discharge_rate:
    - input_number.force_discharge_power_watts
  battery_power:
    - sensor.invbatpower
  pv_power:
    - sensor.pv_power
  load_power:
    - sensor.load_power
  soc_kw:
   - sensor.bms_kwh_remaining
  soc_percent:
     - sensor.battery_soc

Those input_numbers are helper entities and then I have an automation to sync the watts value from those into the force charge/discharge kW number entities provided by the integration (see here: https://gist.github.com/bfayers/82f5a45155281d187f2758c66872c162)

Editing to add another point -- I'm using an automation in HASS to inform predbat with the manual_api of the current inverter charge limit as defined by the BMS charge rate sensor (which shows the limit in amps, not a current value). This is mostly useful when it's very cold out and the BMS is gating the maximum charge speed. See here: https://gist.github.com/bfayers/3684ad464b9d85944fbc52381e3f7d8a

[WyndStryke]

One thing I've noticed (today) about using the Fox force discharge power settings, is that if you are being delicate with them (for example, using the low charge rate functionality), and your household load is high, it'll draw from the grid to cover the difference, instead of increasing the discharge rate dynamically. So might be necessary to add an automation to watch the house load and override the discharge power rate.

[gcoan]

One thing I've noticed (today) about using the Fox force discharge power settings, is that if you are being delicate with them (for example, using the low charge rate functionality), and your household load is high, it'll draw from the grid to cover the difference

that is the same behaviour on the givenergy inverters. If you lock the discharge rate to a low value and house load exceeds that rate then the extra has to come from grid import