Battery charging despite "HoldChrg" target

[AberDino]

This might or might not be related to issue #2035, but my symptoms and screenshots as follows...

I have a single GivEnergy AIO and gateway, with solar PV, running GivTCP v3.0.4 and Predbat v8.16.17 on HA. The tariff I'm on, has a 'mid-rate' window between 9:30 and 11:30, which is ideal for topping up the battery if needed.

While I was behind my computer this morning, I decided to have a look at the Predbat plan and see what was happening. Interestingly, despite a "HoldChrg" target of 89%, the AIO was charging and was already at 95%! To cut a long story short, on the remote control page on the GivEnergy portal, I noticed the "Enable AC Charge Upper % Limit" was not enabled. As soon as I enabled it, the charging stopped, respecting the 89% "AC Charge Upper % Limit".

Should this option be enabled at all times in the GivEnergy portal regardless, i.e. it's not something Predbat or GivTCP control, or should Predbat / GivTCP control this option? If the former, are there any other options which should be set within the GivEnergy portal?

Predbat:

GivTCP:

HA Battery card:

GivEnergy portal:

[gcoan]

good spot, it could well be the cause of #2035 at least on GivEnergy inverters.

Enable AC charge target isn't turned on on my inverter either, and isn't a HA control switch that is mapped in apps.yaml. Potentially Predbat could be trying to set it via REST; would need to look at the code to confirm. In fact probably need to look at the code for hold charge and freeze charge to see what it tries to set. In the screenshot I had for 2035 it was setting target SoC to current SoC, and target SoC in HA is AC charge limit in the portal.

So not having enable charge target switch on would indicate why its not holding

[springfall2008]

This should be on all the time, not sure why not. I'm not sure if I count it as a GivTCP bug or not....

[springfall2008]

Documentation updated for now

[mpartington]

This should be on all the time, not sure why not. I'm not sure if I count it as a GivTCP bug or not....

Please don't enable this if the charge target is 100% - it can cause very different behaviour in the post 3017 BMS. Essentially on 3018 onwards it will by design charge for longer (to calibrate the top end). If Enable AC charge target is on, for some reason it doesn't do this correctly (for 100%). Raised as a firmware/portal bug, but not clear if it will get fixed

I confirmed via the beta group it should be set to off if SOC target is 100%.

Edit - this does appear to be a safe register using RTC, so could be freely toggled on/off , although Predbat setting PauseCharge via GivTCP seems to work fine for me to hold a charge target

[gcoan]

Please don't enable this if the charge target is 100% - it can cause very different behaviour in the post 3017 BMS. Essentially on 3018 onwards it will by design charge for longer (to calibrate the top end). If Enable AC charge target is on, for some reason it doesn't do this correctly (for 100%). Raised as a firmware/portal bug, but not clear if it will get fixed

@mpartington The workaround for this BMS 3017+ issue would be to set inverter_reserve_max as is advised for Gen 2+'s and AIO's that refuse to be set to 100?

https://springfall2008.github.io/batpred/apps-yaml/#inverter-reserve-maximum

[AberDino]

Thanks for all the feedback. I've got "inverter_reserve_max" set to 98% in my apps.yaml file, so I will keep the "Enable AC Charge Upper % Limit" option enabled for now, and monitor the system behaviour more closely over the next few days.

[mpartington]

Please don't enable this if the charge target is 100% - it can cause very different behaviour in the post 3017 BMS. Essentially on 3018 onwards it will by design charge for longer (to calibrate the top end). If Enable AC charge target is on, for some reason it doesn't do this correctly (for 100%). Raised as a firmware/portal bug, but not clear if it will get fixed

@mpartington The workaround for this BMS 3017+ issue would be to set inverter_reserve_max as is advised for Gen 2+'s and AIO's that refuse to be set to 100?

https://springfall2008.github.io/batpred/apps-yaml/#inverter-reserve-maximum

No, this is a different issue completely. It's not the reserve, but the fact BMS3018,.3019.and now 3020 exhibits different behaviour depending if "Enable AC Charge Upper % Limit" is on or off when a 100% charge is requested. Forcing it to 'on' stuffs up the regular upper calibration. The new BMS is a completely new methodology.

[AberDino]

Hi @mpartington, that's an interesting one, and leaves me with a bit of a dilemma. As you can see above, in my case, where Predbat's intention is to hold the charge at a certain percentage, if I don't enable the "Enable AC Charge Upper % Limit", the AIO just keeps charging. I interpret the 'hold charge' option as "grid AC charge to the target level if the SoC drops below the target level, but don't do anything if it is higher than the target level". With excess solar PV, charging the battery above the target level would be ok (assuming that makes more economic sense than exporting excess solar), just don't use grid power (which comes at a cost). I guess the 'hold charge' option could also be interpreted as a "minimum reserve" option, in which case the AIO would be bypassed as soon as the SoC drops to that level, and I guess the AIO would charge to that "minimum reserve" target if required. Would that be better you think?

With regards to the "Enable AC Charge Upper % Limit" option in the GivEnergy portal, to me it would make sense for the AIO to automatically ignore this setting when a 100% charge is requested, as effectively there is no upper % limit at that point. The option would then still be useful for charge targets less than 100%.

Last but not least, my AIO is on inverter firmware "D0.616-A0.616" and battery firmware "12". How does that translate to "BMS 3017+", or is that something completely different?

[gcoan]

No, this is a different issue completely. It's not the reserve,

Ok thanks, thought it might be a fix.

So we'd need a max target parameter then? It seems that we need to set ac charge limit on for hold/freeze charge to work and at the same time we need to respect the newer BMS firmwares

[mpartington]

With regards to the "Enable AC Charge Upper % Limit" option in the GivEnergy portal, to me it would make sense for the AIO to automatically ignore this setting when a 100% charge is requested, as effectively there is no upper % limit at that point. The option would then still be useful for charge targets less than 100%.

Exactly this, the portal should set the correct combination depending on if the soc target is 100% or not, but it doesn't.

The option is available in GivTCP, so Predbat could change it depending on the SOC AC target, I was just worried Trefor would force it permanently on. You could also do this as a temporary measure via an automation that runs every time soc target changes.

I'm on BMS3020, but that is for low voltage batteries. I think this is equivalent to BMS 12 on AIO

Real time control is an option on 616, recommendation is to switch on if using predbat

So it's actually quite easy to achieve what you want (assuming AIO exposes the same options in GivTCP), but setting the charge target to either on or off permanently probably isn't the best solution.

[mpartington]

@gcoan , so long as GivTCP 2 &3 both expose 'Enable charge target' and (big question) all the Giv battery types use this, then all the tools to work around should be already available. Really it should be managed via GivTCP (where it sets multiple registers depending on command, e.g. pause modes). However , I'm sure Trefor could also add this extra write as a condition.

Slight caveat, I have an AC3, me and another tester both repeated this . However I don't know if other battery types behave the same. For me it would hit the 100% on grid and stop immediately, whereas if it hit 100% on solar, it would continue charging to make sure the batteries were full. When I turned off the AC limit, both behaved the same. I only charge to 100% on grid at the moment.

[AberDino]

@mpartington and @gcoan, the "Enable charge target" option is available for me with GivTCP v3.0.4 (AIO control), and I can confirm that when I toggle it, the "Enable AC Charge Upper % Limit" in the GivEnergy portal changes as well:

So it sounds like this would be the solution, i.e. if charge target <100% then enable this option, and if charge target is 100% then disable this option.

@gcoan, do you know when Predbat would opt to use "freeze charge" vs "hold charge"?

[gcoan]

@mpartington as far as I know all the givenergy inverters have 'enable AC charge upper limit %' as a switch option and 'AC charge upper limit %' as a % charge-to limit.

Predbat already uses AC charge upper limit % as the target % for charging (number.givtcp_xxx_target_soc, mapped to charge_limit in apps.yaml).

There is also a soc_max in apps.yaml which defines the maximum charge level of the battery in kWh. I suspect for GivEnergy inverters this is ignored.

@springfall2008 Potential solutions:

1. add guidance to not turn on AC charge upper limit if you are on BMS 3018+, but this just fudges the issue and charge hold/freeze won't work
2. extend Predbat to use soc_max in apps.yaml for GivEnergy inverters and add guidance that this needs to be set to the watts value of 99% of battery capacity if on BMS 3018+
3. as 2 but introduce optional soc_max_percent that can be set as an alternative to soc_max in kwh (which maybe should be renamed to soc_max_kwh but that would be a breaking change). Guidance that soc_max_percent should be set to 99 for BMS 3018+

Personally I favour option 3 as this follows the pattern of other similar flexibility introduced in Predbat configuration and facilitates other inverter types.

I am on BMS3015 at present but was planning on trialling BMS3020 sometime soon.

@gcoan, do you know when Predbat would opt to use "freeze charge" vs "hold charge"?

I don't know. The description of the two is in my view confusing https://springfall2008.github.io/batpred/what-does-predbat-do/#predbat-status with hold charge being described as 'freeze charge without being explicitly selected'. Personally I think we should do away with Hold Charge and just have Freeze Charge, I don't see the distinction or the need for two almost the same things

[mpartington]

Wouldn't option 4 be simpler?

Predbat enables AC charge upper limit% if SOC target <100%

Predbat disables AC charge upper limit% if SOC target =100%

That was what I had in my mind, should work for all scenarios / BMS revisions.

[gcoan]

Wouldn't option 4 be simpler?

Predbat enables AC charge upper limit% if SOC target <100%

Predbat disables AC charge upper limit% if SOC target =100%

That was what I had in my mind, should work for all scenarios / BMS revisions.

that is another option, and requires different apps.yaml changes as switch.givtcp_xxx_enable_charge_target isn't something that is currently used/controlled by predbat

some advantages to that in that its automatic and doesn't require user configuration of the limit, disadvantage is its more GivEnergy specific

[AberDino]

enable AC charge upper limit% if SOC target <100% disable AC charge upper limit% if SOC target =100%

FYI, for the moment, I've implemented the above logic using HA automation, and it seems to be working well.

[CJDumbleton]

@AberDino Are you using predbat.best_charge_limit and switch.givtcp_{geserial}_enable_charge_target in your HA automation to enable AC charge upper limit% if SOC target <100%? Something like this:

alias: Toggle Enable Charge Target
description: ""
triggers:
  - trigger: state
    entity_id:
      - predbat.best_charge_limit
conditions: []
actions:
  - if:
      - condition: numeric_state
        entity_id: predbat.best_charge_limit
        below: 100
    then:
      - action: switch.turn_on
        metadata: {}
        data: {}
        target:
          entity_id: switch.givtcp_{geserial}_enable_charge_target
    else:
      - action: switch.turn_off
        metadata: {}
        data: {}
        target:
          entity_id: switch.givtcp_{geserial}_enable_charge_target
mode: single

[AberDino]

Hi @CJDumbleton,

Yes, similar to that, but I set mine up through the GUI, so the "charge_target" entity is different (picked it from the drop-down, which has "turn on" and "turn off" as different entities) and I use the GivTCP target SOC rather than a Predbat entity. YAML script as follows:

alias: Manage AIO AC Charge Upper-% Limit
description: ""
triggers:
  - trigger: state
    entity_id:
      - number.aio_1_chxxxxgyyy_target_soc
conditions:
  - condition: state
    entity_id: binary_sensor.givtcp_running
    state: "on"
    for:
      hours: 0
      minutes: 2
      seconds: 0
actions:
  - if:
      - condition: numeric_state
        entity_id: number.aio_1_chxxxxgyyy_target_soc
        below: 100
    then:
      - type: turn_on
        device_id: 9604f6891774c1b67c90272e3e7a42be
        entity_id: 3707d256dea6a6bf4d1c35f1e79e4f59
        domain: switch
    else:
      - type: turn_off
        device_id: 9604f6891774c1b67c90272e3e7a42be
        entity_id: 3707d256dea6a6bf4d1c35f1e79e4f59
        domain: switch
mode: single

Ideally, I would like to include a check-in every so often as a secondary trigger, just in case a change in the SOC target is missed. However, I don't want this secondary trigger to action anything if it is not needed, and I'm not sure how to do that.

[gcoan]

Ideally, I would like to include a check-in every so often as a secondary trigger, just in case a change in the SOC target is missed.

The way to do this is to add an id to each trigger, then in the actions section you use a choose statement with options for each trigger id

End up with something like this automation which executes every 10 minutes and has a separate end-of-day trigger. The appropriate code to run is determined by the trigger ids:

alias: PVOutput for GivTCP - Update pvoutput.org with PV system performance
description: ""
triggers:
  - trigger: time_pattern
    minutes: /10
    id: 10min-poll
  - trigger: time
    at: "23:55:00"
    id: end-of-day
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - 10min-poll
          - condition: time
            before: "23:54:00"
        sequence:
          - alias: Wait 20 seconds for total sensors to be updated
            delay:
              seconds: 20
          - action: rest_command.update_pvoutput
            data: {}
      - conditions:
          - condition: trigger
            id:
              - end-of-day
        sequence:
          - action: rest_command.update_pvoutput_endofday
            data: {}
mode: single

And can I also suggest you don't ever use device id's in your automations, it makes them very hard to read. In every case you should just be able to specify the entity id of the switch you want to change