Výpočet kapacity akumulátora

[007ToMMaS]

Ahojte, chcel by som sa poradiť s skúsenejšími ako prosím vás riešite výpočet kapacity? Chcel by som si do systému dorobiť výpočet kapacity a neviem ako správne na to aby to bolo účinné a funkčné. Máte v programe vytvorenú nejakú hodnotu ktorá je "referenčná" a od nej sa pri spotrebe odpočíta a pri výrobe pripočítajú vyrobené Ah? Ďakujem za informáciu.

[vata]

Já to řeším tak, že výchozí kapacita a aktuální SOC je "nějaké" - podle uživatele. Pak musím poznat stav plného nabití, při tom nastavím SOC na 100%, a plného vybití, tam SOC nastavím na nulu a poznačím si dosaženou kapacitu.
Problém u systému s automatizací je takový, že máte-li to dobře naštelované a vyloženě si nehrajete, pak ke stavu plného vybití nedojde, od toho SOC měřím, abych odpojovala ještě s nějakou rezervní kapacitou pro UPS. Takže spodní hranice se v běžném provozu nedosáhne a kapacita baterky zůstává v systému ta papírová. Což u lithia není problém, tam to sedí, u olova by to chtělo občas úplně vybít, aby se zjistil reálný stav kapacity.
Větší problém je ale přesnost měření. Pokud dlouho nedojde k plnému nabití, SOC se prostě rozjede, protože nepřesnosti se kumulují.

[007ToMMaS]

tiež som nad tým probližne tak nejak rozmýšľal. V podstate rozmýšľam nad tým že plne nabitá batéria je maximálna kapacita a spotrebu prepočítam na Ah a tá sa od tej maximálnej hodnoty odčíta, následne keď sa spustí nabíjanie tak sa hodnota vyrobená pripočíta k zostávajúcej hodnote a takto stále dookola. Mohlo by to fungovať po teoretickej stránke?

[mixman]

Pocitat Ah je to najmenej, pokial je merianie prudu pomerne presne, horsie je to s ucinnostou nabijacieho a vybijacieho cyklu akkumulatorov. U olova to moze byt spolu niekde okolo 70-75% co je pre meranie SOC uplne na nic. No existuju rozne metody, ktore beru do uvahy aktualne napatie pri aktualne odoberanom prude spolu s pocitanim Ah, no taktiez do toho zasahuje stav akku, pocet cyklov ...

[kybos]

Nevím, jak je to u jiných systémů, ale u systému Emus, který pro LIFEPO používám, program pravděpodobně jen stupidně přičítá a odečítá naměřené ampérhodiny a při dosažení krajních mezí jen srovná stav SOC, což lze dokumentovat skokovými změnami udávaného SOC. Takový postup ovšem dává chybné výsledky (přilepšuje SOC) v období, kdy se dlouhodobě nedosáhne žádné z krajních mezí. Kdyby byl jen trochu chytřejší a sčítal ampérhodiny v každém směru samostatně, mohl by v intervalech mezi dosažením jednotlivých mezí určit i skutečnou kapacitu baterie a také vyčíslit její ztráty a napříště při sumaci naměřené proudy o vypočtené ztráty korigovat (a to dokonce nelineárně dle velikosti proudu) ještě před sumací a vyčíslením aktuálního SOC a tím jej dynamicky výrazně zpřesnit.

[rottenkiwi]

Netreba zabúdať aj na to, že počítame SOC, ale treba to robiť osobitne pre Pb a LiFE,
lebo každý string reaguje ináč na nabíjanie/vybíjanie pri roznom prúde a roznej teplote.

A ak sa teplota zvýši, tak sa nám zvýši aj SOC, bez toho, že by sme do baterky niečo dodali.

Akceptovanie náboja je iné pri malých prúdoch a iné pri veľkých.
Akceptovanie je výrazne lepšie, ak sa veľký prúd nedodáva kontinuálne, ale v nárazoch.

[petrs]

http://zpravy.e15.cz/burzy-a-trhy/komod ... te-1263907

[kybos]

Tak to vypadá, že snížení cen LIFEPO se asi nedočkáme, spíš naopak...

[rva]

Obnovím velmi staré téma. Pomocí esp, ina226 a bočníku se dá u lifepo sestavit za cca 400,-Kč "smart shunt", který použitelným způsobem počítá SOC:

Vlastní výpočet pak může probíhat v samotném esp a není k tomu potřeba ani HomeAssistant:

Kód: Vybrat vše

substitutions:
  name: esp8266-lolin-d1-mini-3
  friendly_name: esp8266-lolin-d1-mini-3
  device_description: "Měření proudu do/z baterií pomocí bočníku 75mV/300A a snímače proudu INA226"
  
esphome:
  name: ${name}
  friendly_name: ${friendly_name}
  comment: ${device_description}
  name_add_mac_suffix: false
  project:
    name: esphome.web
    version: '1.0'

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "xxxxxxxxxxOib/AwmzmCKkO5Dgry4169cInF/U30="

ota:
  - platform: esphome
    password: "xxxxxxxxxxxx8e843ab709dd0efa526"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  min_auth_mode: WPA2
# Optional manual IP
#  manual_ip:
 #   static_ip: 192.168.0.72
  #  gateway: 192.168.0.1
   # subnet: 255.255.255.0
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "esp8266-lolin-d1-mini-3"
    password: "xxxxxxx"

# V HA se pak k položkám "edit" a "logs" objeví položka "visit", kde se po kliknutí otevře stránka esphome daného zařízení
web_server:
  port: 80

captive_portal:

# Aktivuje bezpečné ukládání stavů do paměti ESP aby se počítaná hodnota Ah po restartu nenulovala
preferences:
  flash_write_interval: 1min # Uloží hodnotu do paměti každou minutu
  
#i2c
#Configuration variables:
#    sda (Optional, Pin): The pin for the data line of the I²C bus. Defaults to the default of your board (usually GPIO21 for ESP32 and GPIO4 for ESP8266).
#    scl (Optional, Pin): The pin for the clock line of the I²C bus. Defaults to the default of your board (usually GPIO22 for ESP32 and GPIO5 for ESP8266).
#    scan (Optional, boolean): If ESPHome should do a search of the I²C address space on startup. Defaults to true.
#    frequency (Optional, float): Set the frequency the I²C bus should operate on. Defaults to 50kHz. Values are 10kHz, 50kHz, 100kHz, 200kHz, … 800kHz
#    timeout (Optional, Time): Set the I²C bus timeout. Defaults to the framework defaults (100us on esp32 with esp-idf, 50ms on esp32 with Arduino, 1s on esp8266 and 1s on rp2040). Maximum on esp-idf is 13ms.
#    id (Optional, ID): Manually specify the ID for this I²C bus if you need multiple I²C buses.
i2c:
   - id: bus_a
     sda: GPIO4
     scl: GPIO5
     scan: true
 #  - id: bus_b
 #    sda: GPIOXX
 #    scl: GPIOXX
 #    scan: true

#ina226
#Configuration variables:
#    address (Optional, integer): Manually specify the I²C address of the sensor. Defaults to 0x40.
#    shunt_resistance (Optional, float): The value of the shunt resistor on the board for current calculation. Defaults to 0.1 ohm.
#    max_current (Optional, float): The maximum current you are expecting. ESPHome will use this to configure the sensor optimally. Defaults to 3.2A.
#    adc_time (Optional, Time or both of the following nested options): The time in microseconds to perform a single ADC conversion. Defaults to 1100us. Valid values are 140us, 204us, 332us, 588us, 1100us, 2116us, 4156us, 8244us.
#        voltage (Required, Time) ADC conversion time for Bus Voltage
#        current (Required, Time) ADC conversion time for Shunt Voltage (Current measurement)
#    adc_averaging (Optional, integer): Selects ADC sample averaging count. Defaults to 4. Valid values are 1, 4, 16, 64, 128, 256, 512, 1024.
#    update_interval (Optional, Time): The interval to check the sensor. Defaults to 60s.
#
#Sensors
#The component offers four sensors. You can configure all or any subset of them. Each configured sensor is reported separately on each update_interval. The name option is required for each sensor configured. All other options from Sensor.
#    current (Optional): Calculated current output, Amperes.
#    power (Optional): Calculated power output, Watts.
#    bus_voltage (Optional): Bus voltage output (voltage of the high side contact), Volts.
#    shunt_voltage (Optional): Shunt voltage (voltage across the shunt resistor) value of the sensor, Volts.
sensor:
  - platform: ina226
    address: 0x40
    shunt_resistance: 0.00025 ohm
    max_current: 300A
    # Nastavení do 2026-08-15
    # adc time used for both, Bus Voltage and Shunt Voltage
    #adc_time: 8244us
    #adc_averaging: 64
    #update_interval: 10s
    # AI doporučila toto nastavení - od 2026-08-15
    adc_time: 1100us       # Rychlejší vzorkování
    adc_averaging: 1024    # Maximální hardwarové průměrování čipu
    update_interval: 2s    # Častější vyčítání do ESPHome

    current:
      name: "INA226 Current"
      id: ina226_current
#    power:
#      name: "INA226 Power"
#    bus_voltage:
#      name: "INA226 Bus Voltage"
#    shunt_voltage:
#      name: "INA226 Shunt Voltage"
  
  - platform: integration
    name: "Baterie - Ah stav podle esphome"
    id: baterie_ah_stav_podle_esphome
    sensor: ina226_current
    time_unit: h               # Výsledkem budou Ampérhodiny (Ah)
    integration_method: left   # Metoda integrace (stejná jako máte v HA)
    restore: true # <--- DŮLEŽITÉ: Po restartu začne tam, kde skončil
        # Filtry kontrolují hodnotu při každé změně:
 #   filters:
 #     - lambda: |-
 #         if (x > 1590.0) {
 #           return 1590.0; // Pokud je hodnota vyšší než 1590, vrátí 1590
 #         } else if (x < 0.0) {
 #           return 0.0;    // Pojistka: Pokud klesne pod 0, vrátí 0
 #         } else {
 #           return x;      // Jinak vrátí skutečně naměřenou hodnotu
 #         }

# Baterie mají 1590 Ah. Tímto tlačítkem se ručně údaj stavu baterie nastaví na tuto hodnotu 
button:
  - platform: template
    name: "Baterie - Ah v esphome - reset na 100%"
    id: baterie_ah_v_esphome_reset
    icon: "mdi:battery-refresh"
    on_press:
      then:
        - sensor.integration.set_value:
            id: baterie_ah_stav_podle_esphome
            value: 1590.0
    

Když už jsou taková data k dispozici, není problém zavést si zvlášt integraci pro dobíjecí proud a zvlášť pro odebíraný a zjistit tak, jaká kapacita nebo energie protekla baterií:

[Franta2776]

Hodně se to za 10let posunulo a mě bych řekl, to funguje přesně. Se starou Daly se to nedá srovnat:
JK BMS verze 19 měří ampérhodiny (Ah) přímým měřením proudu (Coulomb counting), nikoliv pouhým odhadem podle napětí. Napětí slouží pouze jako referenční bod pro kalibraci a nulování/plnou kapacitu.
Jak výpočet stavu nabití (SoC / Ah) v JK BMS funguje:
* Integrovaný Bočník (Shunt): BMS obsahuje interní bočník, přes který neustále v reálném čase měří protékající proud (v ampérech) i směr (nabíjení vs. vybíjení). Tyto hodnoty v čase integruje, čímž přesně přičítá nebo odečítá odebrané/dodané Ah.
* Role napětí (Kalibrace na hranicích): Protože drift měření u Coulomb countingu v čase narůstá, BMS využívá napětí k auto-kalibraci při dosažení mezních hodnot:
* 100 % SoC: Jakmile jakýkoliv článek dosáhne nastaveného napětí Cell OVP (resp. Volts for 100% SoC), BMS zresetuje počítadlo na plnou kapacitu (Ah).
* 0 % SoC: Při dosažení napětí Cell UVP vynutí přenastavení na 0 Ah.
* Pásmo mezi hranicemi: Uprostřed vybíjecí křivky (zejména u LiFePO4, kde je křivka napětí mezi 20 % a 80 % téměř plochá) je odhadování kapacity čistě podle napětí zcela neúplné a nepřesné. Proto v tomto rozsahu BMS spoléhá výhradně na naměřený proud protékající bočníkem.
Pokud pozorujete odchylku v načtených Ah, bývá to zpravidla způsobeno buď chybou v nastavení jmenovité kapacity akumulátoru v aplikaci, neproběhnutým plným nabitím do resetu na 100 %, nebo potřebou manuální kalibrace nuly proudu (Current Calibration / Zero Current) v prostředí JK BMS.

[Valdano]

Níže jsou videa od Andyho (Off-Grid Garage z Austrálie) popisující nepřesnosti ve výpočtech SOC u JK-BMS a porovnání mezi verzemi 14, 15 a 19. Je tam zmíněno, že pokud se poměrně často (příklad cca každé 2 dny) nabijí až k resetu SOC tak je měření poměrně přesné. Nicméně v zimě je u řady provozovatelů situace taková, že se nabíjí výrazně méně a k resetu SOC nedochází po mnohem delší dobu, a to vede postupem času k akumulování nepřesností a vykazovaná SOC pak může být i výrazně mimo oproti realitě.



Andy před testem všechny baterie plně nabil, aby se resetovalo SOC na 100% a poté všechny BMS zkalibroval. Následně po dobu 5 týdnů schválně nenabíjel až k resetu SOC, aby porovnal jak budou JK-BMS s různými verzemi firmware nepřesné a jak moc u nich bude SOC po té době cyklování bez resetu ujeté. Stav SOC v jednotlivých BMS porovnával Andy vůči Victron Smart Shuntu. Baterie se v průběhu testování nabíjely z FVE a vybíjely jen pro účel dobíjení BEV. Na konci testu viz druhé video Andy odečetl stav BMS vykazovaného zbytkového SOC a všechny baterie schválně vybil až na doraz kdy článek v baterii s nejnižším napětím při vybíjení dosáhl 2,5V. Pak spočítal rozdíly o kolik se jednotlivé BMS odchýlily.



Všechny JK-BMS v testu ukazovaly na konci menší zbytkovou hodnotu SOC než v nich skutečně byla.

baterie LiFePO4 48V/280Ah, JK-BMS verze 19.06 o 18% méně
baterie LiFePO4 48V/314Ah, JK-BMS verze 14.25 o 10% méně
baterie LiFePO4 48V/280Ah, JK-BMS verze 15.41 o 28% méně
baterie LiFePO4 48V/304Ah, JK-BMS verze 15.41 o 18% méně

V tom druhém videu ke konci pak Andy vysvětluje, že při nízkých proudech vykazují jednotlivé JK-BMS vyšší odchylky při měření proudů než Victron Smart Shunt což se také podílí na nepřesnostech.

[Franta2776]

Podobně chybné SOC mi ukazuje i přimo bmw I5.Nejdéle se nabijí z 99 do 100%.Samovybíjení a ztráty v bateriich zatím nikdo přesně neodhadne.Mění se i teplotou a stářím baterii.

[Valdano]

Chcel by som si do systému dorobiť výpočet kapacity a neviem ako správne na to aby to bolo účinné a funkčné...

Doporučuji k přečtení popis nastavitelných parametrů pro Victrn Smart Shunt, který je obecně považován za celkem přesný. Z toho popisu je patrné jaké různé eventuality bere Victron Smart Shunt při výpočtu SOC v potaz.

Jen pro zajímavost viz třeba:
- Peukert exponent (u LifePo4 obvykle 1.05)
- Charge efficiency factor (u LifePo4 obvykle 99%)
- Current threshold
- Time-to-go averaging period
- Zero current calibration
- Temperature coefficient (u LifePo4 0.5% kapacity / °C)

Podle toho se můžete inspirovat při tvorbě vlastního měřiče.

[Franta2776]

Jj vím mám ho doma. Mám lifepo z olovem. Jak to olovo odchází ani prase to nedá dohromady. Parametry bych musel neustále měnit.
Každá baterie má mít svoje měření bms, potom jsou použitelné vysledky.

[Valdano]

Jj vím mám ho doma.

Nepsal jsem to pro ty co to používají a znají, ale primárně pro tazatele/zakladatele tohoto tématu, aby se podle toho mohl inspirovat při tvorbě vlastního měřiče a software k němu.

[rva]

To u mě jedno JK-BMS na baterii 100 Ah počítá SOC velmi špatně. Stačí 6 dní a je ze 100% na nule i když vše ostatní ukazuje, že jsou baterie nabité.

JK-BMS - Velmi chybně počítáno SOC.png (39.64 KiB) Zobrazeno 24 x

Přičítám to tomu, když proud velmi rychle mění i směr, tak JK-BMS tady dělá velkou chybu.

[glottis]

Podobně chybné SOC mi ukazuje i přimo bmw I5.Nejdéle se nabijí z 99 do 100%.Samovybíjení a ztráty v bateriich zatím nikdo přesně neodhadne.Mění se i teplotou a stářím baterii.

To že to trvá nejdéle je spíš tím že v tu dobu balancuje. Tesla to dělá taky

[TomHC]

INA22x je definitívne riešenie. Len teda INA226 má a) limit 36V a na 48V je treba INA228. Dá sa samozrejme použiť INA226 a odporový delič, ale b) pri INA226 sa musí použiť výpočet energie pomocou integrálu, lebo NEMÁ HW počítanie náboja/energie. A to je oproti HW metóde ďalšia chyba merania a nevýhoda INA226.

Áno, INA226 je na Ali za pár drobných, ale oproti 228 je menej presný. A hlavne toto by bola vec ktorú by som kúpil výhradne u normálneho distribútora (mouser, digikey...)

Ja mám doma tri kusy diybms-Currentshunt, k plnej spokojnosti.

https://github.com/stuartpittaway/diyBMS-CurrentShunt

[Kajap]

Celkem logicky to funguje pesimistickým odhadem, protože to bude asi lepší než kdyby to ukazovalo 80 a za 10% by to chcíplo:))

Neboli je stále lepší ukazovat SOC 30 i když tam je 80%. Nebo ne?

Zo by muselo umět AI ML, aby se to nějak samokalibrovalo.