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.