Method for determining battery capacity

As I have a battery that is now three years old I am aware that it no longer has the capacity as stated when it was new. As I can't find anything explicitly in the app or portal that says what its capacity is does anyone have a method of knowing or is there something hidden which I have missed? Recently I have set the timed charge time to 00:00 to 05:30 and then in 'Energy Graph', 'Grid in' I use the value there 'Grid to Battery' when I know that the battery was at a 4% SOC/Inverter Idle the evening before. There could be something better or not dependent on the battery being emptied the day before.
Thanks

GrahamShaul You'll need to run a calibration to get the current capacity & use a third-party app (GivTCP or the inverter app) to read the "Battery Capacity" figure.

GrahamShaul If you have home assistant and GivTCP I can give you a custom sensor that you can just copy paste that will show you day by day what % of your original capacity the battery is charging up to pretty accurately. As Vestas said, the only 100% sure way of doing it is running a calibration.

Al E.Gator
I’d like to see that -please post!

PianSom `
sensor:

• platform: template
  sensors:
  total_battery_capacity_percentage:
  unique_id: total_battery_capacity_percentage
  friendly_name: "Total Battery Capacity Percentage"
  unit_of_measurement: "%"
  value_template: >-
  {% set cap1 = states('sensor.INVERTER/BATTERY_battery_remaining_capacity') | float(0) %}
  {% set total_capacity = cap1 %}
  {{ (total_capacity / 186 * 100) | round(2) }}`

So you'll need to find the sensor for your battery/inverter for that entity and paste it into here sensor.INVERTER/BATTERY_battery_remaining_capacity, then where it says 186 after total_capacity, this is the factory specification of the battery so it can calculate how much is left as a percentage. Mine is a 9.5kWh battery so it is 186Ah. If you have multiple batteries you want to add up so you have a total capacity you can do something like the following:
`sensor:

• platform: template
  sensors:
  total_battery_capacity_percentage:
  unique_id: total_battery_capacity_percentage
  friendly_name: "Total Battery Capacity Percentage"
  unit_of_measurement: "%"
  value_template: >-
  {% set cap1 = states('sensor.BATTERY 1_battery_remaining_capacity') | float(0) %}
  {% set cap2 = states('sensor.BATTERY 2_battery_remaining_capacity') | float(0) %}
  {% set cap3 = states('sensor.BATTERY 3_battery_remaining_capacity') | float(0) %}
  {% set cap4 = states('sensor.BATTERY 4_battery_remaining_capacity') | float(0) %}
  {% set total_capacity = cap1 + cap2 + cap3 + cap4 %}
  {{ ((total_capacity / 744 * 100) - 3) | round(2) }}`

Again just add or delete however many lines for batteries you have and their sensors, and then make sure you add or delete the 'cap1, cap2' etc after set total_capacity. Then where it says 744 you'll put the total capacity of all your batteries, in my case I have 4 9.5kWh batteries so the total capacity is 186*4 =744.

If you'd prefer you can just copy and paste the first code if you'd rather see each battery separately rather than as a total. But you'd need to give each one a name, friendly_name, and unique_id. Up to you!

Let me know if you have any issues.

Al E.Gator Thank you for your suggestion. Unfortunately I have neither of those. However I am interested regarding knowing as a result of a calibration, can you explain how that works?

Al E.Gator
Thank you

I actually am an AIO user, and don't seem to have any sensor.BATTERY 1_battery_remaining_capacity-type entities 🙁

(BTW for future reference, if you use three back ticks ``` before and after pasting code then it will format it properly, and make it easier to cut/paste and read.)

Or upload the code/script in a txt file and include that in the post. Surely that battery parameter is something that GE include in the portal dashboard views.

PianSom I thought the AIO bms actually had the SOH value already in it?
The HV stuff seems to have the "STACK" prefix rather than battery.

hoggy
Well, blow me down, so it does. Must be a v3 thing I hadn’t spotted. Thanks.

Is it % of original capacity remaining?

[unknown] on the LV stuff its (Capacity Actual / Capacity Design) * 100.
Note that Capacity Actual only changes after a calibration, I'm unsure if there is a "capacity remain" without trawling through every register....
The LV bms does log it's SOH but as yet doesn't seem to be available over modbus?

PianSom

PianSom I mean, if it’s got that that then I’m quite surprised it doesn’t display the Ah remaining of the battery

hoggy easiest way to do it on a daily basis is with my example at the top measuring what the maximum Ah the battery charges up to each day

[unknown] I don't have an AIO but looking at GivTCP it seems to take the AH value and then manipulate it, so not sure how that impacts the accuracy:

Raw Values

GivTCP Interpretation

hoggy
Very interesting.

The 12y warranty warrants (provided usage is not excessive) 70% of "usable capacity" at 12y. Assuming that usable capacity is 13.5kWh for an AIO, that means they warrant 9.45kWh.

Let's assume that the definition is the same for HV kit as it is for LV kit. Capacity Design is - I assume - what GivTCP reports as being the capacity of the batteries - 16.48kWh. Capacity Actual will decline over time, so if it gets to 9.45kWh at y12 that is a SOH of 57.3% (=9.45/16.48), so a decline each year of 3.55%. (Assuming that capacity decline is linear over time - no idea.)

So if you are running at over that (which I am!) then a warranty claim is on the cards for 2035. Provided that GE still exist then.

I didn't think calibration was a thing now that BMS12 is with us? I thought it was done on the fly. So I wonder when Capacity Actual gets updated?

hoggy stupid forum editing thing.

Anyway, givTCP turns the raw AH value into an soc_kwh value. You will need to work that back to an AH value using the reverse of what GivTCP does, as I can't see anywhere where the raw AH value gets displayed to the user.

hoggy
Sorry - we crossed over.

I had a second AIO installed just over a week ago, so I can compare values from an 18m old battery to a new one.

I am heading out now, but will do some digging around later on ...

PianSom as Giv over provision most of the battery range, I'm unsure quite what starting value the warranty retention 70% thing is based on. One would assume the SOH value is the one that is used but if you have a 100% DOD pack then Actual Cap started well above design cap, so SOH is >100% and therefore you have more of a window for loss than it first appears.

At one point (as you may have seen on my long running post over 4 years) I've tracked mine and its down to "83% SOH" but that only changes when a calibration is run, and let's face it, if you go in for a warranty claim then the first thing support will do is run a calibration to check.

The HV BMS if I'm honest is a bit of a mystery, I've not had one to play around with.

hoggy Hmm did't know that GivTCP manipulated the Ah value, I thought I'd found a smart way of seeing what it charges up to each day in Ah!

Al E.Gator only on AIO it looks like though. If you have the "normal" LV stuff the "remain AH" value is just yanked out the BMS direct.
I don't have an AIO but feel free to rummage through that list I linked to see if anything else stands out as unusual (only caught my eye as i scrolled past it as it had a comment against it:

bcudata['Stack_SOC_kWh']=round((stack[0].remaining_battery_capacitystack[0].number_of_module)0.9,2) # Usable kWh is 10% less than actual

hoggy
Turns out there's lots of stuff published to raw by GivTCP3 that I hadn't spotted. Here's the stats from my new AIO -

So SOH starts at 100.

Comparing to by 18mo AIO is slightly edifying. I have been pretty much thrashing the battery, and it shows in SOH reduction. But I am not really any wiser about (a) what the code comment about "Usable kWh" means, nor (b) whether I am on track to require a warranty claim before 12y. (I'm obviously eating capacity, but I'm pretty certain I won't hit the 10MWh/1kWh churning limit though. What the warranty actually means is far from clear to me.)

The big question is - is it worth continuing to thrash the batteries? ie Do the savings pay enough for a decent return on capital invested, assuming a reducing capacity and writing off the AIOs after 12y. At the moment the answer is probably yes by my rough calculations, but YMMV. A successful warranty claim to replace the batteries (or a partially usable system after 12y) would make for a MUCH more solid case for thrashing.

Impossible to know, of course, since we don't have a crystal ball telling us what is going to happen over the next decade to import/export pricing (which matters a lot to the calcs), nor how quickly the batteries will degrade in use (which matters rather less).

PianSom yes the Raw output should mostly pull the registers directly without too much processing / massaging via GivTCP. Before we get too far though, there's a few that look like they might be mis labelled in there looking at the values returned:

min_charge_current - probably should be max_charge_current
min_charge_voltage - likely max_charge_voltage
min_discharge_current - likely max_discharge current.
number_of_cycles - is that likely to be 1.5 (how "new" is it?) or is that out by a decimal point and should be 15? Doesn't square well with total energy in/out values so something off between those two things.
cluster_cell_voltage - weird that it is 96, can't square that one but potentially mixed up with cells_per_module (24cells in each tray x4 = 96?) unless the value moves around.

in better news, remaining_battery_capacity_ah AND battery_nominal_capacity_ah are showing values - just need to pester Mark to add them into HA side of things.

hoggy
New, as in installed 9 days ago. Could easily be an order of magnitude out, as I have been doing about 1.5 charge cycles per day.

BTW did you notice my Github request citing you for the battery in/out flows?

EDIT cluster_cell_voltage is currently 96 on both AIOs