Reduce Battery Charge Current when above 93% charge

[Dave Foster]

Code: Select all

alias: Charge Reduction
description: ""
trigger:
  - platform: time_pattern
    minutes: /1
condition:
  - condition: or
    conditions:
      - condition: numeric_state
        entity_id: sensor.battery_soc
        below: 90
      - condition: numeric_state
        entity_id: sensor.battery_soc
        above: 93
action:
  - if:
      - condition: numeric_state
        entity_id: sensor.battery_soc
        above: 92
    then:
      - if:
          - condition: numeric_state
            entity_id: sensor.max_charge_current
            above: 10
        then:
          - service: number.set_value
            data:
              value: 4
            target:
              entity_id: number.max_charge_current
          - service: logbook.log
            data:
              message: Setting Max Charge to 4A
              name: Max Charge
    else:
      - if:
          - condition: numeric_state
            entity_id: sensor.battery_soc
            below: 90
        then:
          - if:
              - condition: numeric_state
                entity_id: sensor.max_charge_current
                below: 10
            then:
              - service: number.set_value
                data:
                  value: "35"
                target:
                  entity_id: number.max_charge_current
              - service: logbook.log
                data:
                  message: Setting Max Charge to 35A
                  name: Max Charge
mode: single

This is a simple automation that sets the charge current to 4A above 93% SoC and then increases it backs to 35A (the default max setting) when the battery drops below 90%.

Whilst this will slow down the final 6% of charging the battery it helps to maintain the battery balance by giving the batteries more time to top balance.

In home assistant go to Settings, Automations & Scenes and click the blue button in the bottom corner that says 'CREATE AUTOMATION' , select 'Create new automation', then click the three dots in the top right corner of the window and choose 'Edit in Yaml'

Copy the code above into the new automation overwriting what is there, then click 'Save'

This automation will be called 'Charge Reduction' and once saved will start to work the next time your battery SoC goes over 93%

[Simacsee]

Really nice - thanks for sharing - as couple of questions:

1) I agree with the approach to changing the charging current limit from a 'scientific' point of view - but does the BMS no do this somewhat automatically (basing this on playing with settings for charging a Nissan leaf, whereby the 90-100% charge is very slow and you can see using Leaf Spy the cells being balanced). Just wondering if there was any direct steer from FoxESS (or someone there), as I could imagine a scenario whereby the BMS is expecting more power, and suddenly can't draw it due to this limitation (i.e. causing a conflict).

2) Any specific reason why 93% SoC (as opposed to 85%-95%) - seems a pretty reasonable 'rule of thumb' approach - but just wondering.

3) I'm not programming expert - especially in respect of HA - but would it not be better to use a trigger on 'change of state' of SoC, rather than checking every minute? I don't know what the overhead of running this (and unless you have lots and lots of automations running, probably makes no difference).

Any thoughts from anyone welcome - but again - love the approach and thanks for sharing.

[Dave Foster]

Really nice - thanks for sharing - as couple of questions:

1) I agree with the approach to changing the charging current limit from a 'scientific' point of view - but does the BMS no do this somewhat automatically (basing this on playing with settings for charging a Nissan leaf, whereby the 90-100% charge is very slow and you can see using Leaf Spy the cells being balanced). Just wondering if there was any direct steer from FoxESS (or someone there), as I could imagine a scenario whereby the BMS is expecting more power, and suddenly can't draw it due to this limitation (i.e. causing a conflict).

2) Any specific reason why 93% SoC (as opposed to 85%-95%) - seems a pretty reasonable 'rule of thumb' approach - but just wondering.

3) I'm not programming expert - especially in respect of HA - but would it not be better to use a trigger on 'change of state' of SoC, rather than checking every minute? I don't know what the overhead of running this (and unless you have lots and lots of automations running, probably makes no difference).

Any thoughts from anyone welcome - but again - love the approach and thanks for sharing.

Hi,
Yes the BMS does do quite a bit itself and the management has improved considerably since this was originally written, but it doesn't throttle the charge until 96% and if the batteries are not in perfect sync, as the active balance circuits are only small there isn't enough time to re-balance.
I've found that after a particularly heavy discharge (as you might do for example in an Octopus Saver Session), this is earlier throttle is needed but for normal operation the latest versions of BMS master are good at managing.

The reason for 93% was simply that the Fox BMS starts throttling and balancing, re-calibrating at 96% - 93% was chosen from testing on a system that was used a lot to heavy discharge - and it works really well.

I myself actually take a much finer control of the BMS charging and start throttling earlier and have different profile curves depending on time of year (solar generation, temperature etc...) - but again that was mostly written because earlier iterations of BMS master was very mono-lithic and did not do such a great job for all conditions - it has improved massively the last 12 months.

On the overhead, yes arguably you could test on the state change but you'd have to check for unavailable, none etc... in the state change test and the test every minute approach has a tiny processing overhead and recovers well from a restart - I keep my automation activations disabled in 'recorder', that would be the bigger overhead as it stores the automation activation in the database every minute.
From a purity point of view if I was writing this now I would probably use numeric entity templates and use the triggerid to determine the higher / lower test later in the code - that would remove the overhead of the automation logging and only trigger when it needs to - but it’s only marginal at best.

[WyndStryke]

I've been throttling charging via the number.force_charge_power (which is in kW rather than amps, and obviously affects the system only when it is in force charge mode).

Is it better to do it via number.max_charge_current instead?

Are these two throttles independent (i.e., will it be the lower of the two which controls the force charge speed)?


Somewhat unrelated, but when the predbat software tries to adjust the force charging or force discharging rate, it needs an entity which can be both written and read, and expects it in be in W rather than kW or A.

Charge/Discharge rate
charge_rate - Battery charge rate entity in watts
discharge_rate - Battery discharge max rate entity in watts
or

charge_rate_percent - Battery charge rate entity in percent of maximum rate (0-100)
discharge_rate_percent - Battery discharge max rate entity in percent of maximum rate (0-100)

https://github.com/springfall2008/batpr ... 2638205124

It isn't clear from the documentation what charge_rate is supposed to be - it just says 'Battery charge rate entity in watts'.
That could be interpreted the current charging current or the available charge rate

The sensor that is configured in apps.yaml is expected to be an inverter sensor that (a) gives the current charge rate and (b) is something that Predbat can set to control the charge rate.

By using a template sensor for the entity, part b isn't going to work ....

Trefor has recently introduced the ability to control charge and discharge rate by % instead of watts value. Is this something the Fox inverter supports?

I can certainly expand the documentation to make this clearer, and if the Fox template needs changes, I can make those.

Currently in their example configuration for Fox, it is wired up to sensor.bms_charge_rate and sensor.bms_charge_rate which I don't think is right (I presume that writes to these sensors will be ignored).

* https://github.com/springfall2008/batpred/issues/1928
* https://github.com/springfall2008/batpred/issues/1964

The leading suggestion so far seems to be to have a pair of input_numbers in W, and an automation to translate back and forth into number.force_charge_power & number.force_discharge_power like so: https://github.com/TonyHoyle/foxess_predbat

Also, would it be correct to say that force_charge_power is working at the inverter level (affecting AC/DC conversions), and max_charge_rate would be working at the BMS level?

[Dave Foster]

I've been throttling charging via the number.force_charge_power (which is in kW rather than amps, and obviously affects the system only when it is in force charge mode).

Is it better to do it via number.max_charge_current instead?

Are these two throttles independent (i.e., will it be the lower of the two which controls the force charge speed)?

It's better to do it using number.force_charge_power as that is used to set the active power used by the inverter, however you can set number.max_charge_current and that will also throttle the charge - they are independent of each other in so far as whichever is the lowest will always take priority.

I'm afraid i've no experience of predbat, but using the bms_charge_rate or bms_discharge_rate sensors is wrong - they are read only and set by the BMS to the maximum rate that it will allow to be used - and irrespective of what rate you set in either number.force_charge_power or number.max_charge_current if the bms charge rate is lower that will win every time.

Also, would it be correct to say that force_charge_power is working at the inverter level (affecting AC/DC conversions), and max_charge_rate would be working at the BMS level?

force_charge_power is setting the inverters active power register and that is the maximum power output it will throttle at.
max_charge rate is setting the dc input current used to charge to the batteries

[WyndStryke]

Many thanks