funguje to tak, že když je v dané hodině predikce výroby větší, než spotřeby, tak je tento hack aktivní (pokud jsou ty predikce obráceně, tak se tento hack neaktivuje).
Jakmile detekujeme ESS#1 (běhěm pár vteřin) tak snížíme mSoC o 4% pod aktuální SoC a jakmile ESS#1 zmizí, tak mSoC nastavíme na SoC - 1, tzn. o jedno procento níže, než bylo původní mSoC.
Takto s ním “couváme” tak dlouho, dokud je potřeba, ale maximálně o 5% a nikdy ne pod 10% nabití baterie.
Se začátkem nové hodiny se vše vždy vrátí na původní (uživatelské) mSoC.
TLDR: Pokud dle predikcí věříme, že výroba by měla být pokrýt spotřebu, tak jakmile se narazí na mSoC a aktivuje ESS#1, cíleně ho podlezeme o 4% abychom z něj vyskočili (3 a méně nestačí, aby to z něj vyskočilo) a následně to ihned vrátíme o jedno procento pod aktuální nabití (to už ESS#1 nespustí) a toto celé se pořád opakuje tak dlouho, dokud se buď baterka nenabije zpět nad uživatelské mSoC a nebo nevybije 5% pod uživatelské mSoC kde už dále nepokračujeme a ESS#1 necháme aktivní a nebo jsme se tímto postupem nedostali na 10% nabití baterie (tzn. uživatelské mSoC bylo 15% a méně) a tam též dále nepokračujeme.
ten náš hack neznamená, že to nikdy není v ESS#1 - do něj to spadne stejně, ale co se děje je, že jakmile Proteus detekuje aktivní ESS#1 (trvá mu to pár vteřin) tak “uhne” s mSoC dolů natolik, aby vynutil ukončení ESS#1 a tím zastavil to nabíjení baterky o 3%.
Na obrázku je krásně vidět, že se mu to povedlo - uhnul s mSoC (žlutá) a zelená (SoC) zůstala tam kde byla - pak se SoC začalo zvedat o cca hodinu později už s FVE - takže žádné umělé nabíjení ze sítě.
Kde byl problém - máme všude tzv. rate limitery - tedy jakmile dochází k přenastavování nějaké hodnoty na dané FVE moc často, začneme to omezovat. Je to kvůli tomu, aby se z důvodu nějaké chyby nestalo, že někde něco měníme sem tam moc často a tím způsobíme třeba nějaký problém se zápisy od EEPROM (solax) ale obecně i jakékoliv nežádoucí chování.
Mno a bohužel zde je potřeba relativně rychle za sebou několikrát přenastavit mSoC a do toho nám vlezl právě ten rate limiter, který to nenechal měnit tak často. Už by mělo být opraveno, dejte vědět, pokud stále ne (nezapomínat ale na to, že se to děje jen když je predikce výroby větší než predikce spotřeby, což s ohledem na to, že jdeme do podzimu a zimy, už bude nastávat méně a méně)
tak už snad konečně odchyceny všechny edge casy a mělo by to šlapat
Problém následujících dní je, že je zataženo a často nemusí být predikce výroby vyšší než spotřeby - takže se to složitě otestuje, ale kdyby cokoliv, dejte vědět
.
.
