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
V
#2Vestas
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.
A
#3Al E.Gator
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.
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:
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.
#6GrahamShaul
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?
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.)
#8Maxwell
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.
#10hoggy
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.
#11PianSom
hoggy
Well, blow me down, so it does. Must be a v3 thing I hadn’t spotted. Thanks.
Is it % of original capacity remaining?
#12hoggy
[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?
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?
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.
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 ...
#19hoggy
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.
A
#20Al E.Gator
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!
#21hoggy
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
#22PianSom
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).
#23hoggy
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.
#24PianSom
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
