Letitý regulátor Tristar MPPT 60 odchází do křemíkového nebe – tedy stále funguje na pevně nastaveném MPP bodě, nicméně čím dál častěji zadrhává i při vyčítání dat, takže je zřejmé, že už mu moc času nezbývá. Začala jsem tedy připravovat přechod na Victron MPPT 150/100.

Nejdříve jsem si pořídila chytrou krabičku Victron Cerbo S-GX, kterou jsem spojila skrze VE.Direct port s regulátorem mobilního FVE zdroje, abych si mohla dopsat modul do valcLoggeru.

Cerbo je tak malé zařízení, že se v přístrojové skříni mé elektrárny úplně ztratí. Bohužel ale potřebuje vlastní napájení, mírná komplikace.

V administraci Cerba jsem povolila Modbus protokol, zjistila si Modbus ID připojeného regulátoru (dostal číslo podle použitého Ve.Direct portu) a stáhla si od Victronu Excel s popisem Modbus registrů. A pak jsem se vrhla na rozšíření valcLoggeru, šlo to jednoduše, zde příklad vyčtení jednoho z registrů:

uint16_t a ;

float Vbattery;

modbus_read_input_registers (ctx, 771, 1, &a);

Vbattery = a /100.0;

V proměnné Vbattery mám například napětí baterie, jak jej měří regulátor. Podobně se pak stačí dotázat na ostatní hodnoty a uložit to do databáze.

Bohužel Victron neposkytuje přes standardní registry data jako Voc, Vmp, denní Ah, ani čas ve floatu či absorpci, a dokonce nevrací ani celkovou výrobu (vrací jen výrobu od posledního resetu počítadla). Podobně o sobě neprozradí teplotu na chladiči, to je už horší, protože teplotu regulátoru vzhledem k tomu, že je zavřený v přístrojové ve skříni, hlídám.

Některé z těchto dat se dají odvodit, některé už nikoliv, a proto mě čekají ještě práce na valcMonitoru.

ValcMonitor mi už hrozně zastaral, hrabat se v 10 let starém kódu je práce nezáživná, proto jsem to spojila s mírnou refaktorizací. Hodně logiky mám v uložených procedurách databáze valcMonitoru, pokusím se to provést tak, abych pokud možno nemusela sahat na php klienta, u kterého se to prostou refaktorizací modernizovat už nenechá, bude jednodušší to přepsat znovu.

I databáze valcMonitoru má ale kostlivce ve skříni. Patří mezi ně například optimalizační udělátka, jako třeba tabulky, které jsem měla v memory engine, které se denně flushovaly do archivních tabulek, a měly za účel šetřit SD kartu RPI před vycyklováním neustálými zápisy. Asi to i fungovalo – pamatuju si na jednu instanci valcMonitoru, kde SD karta vydržela asi 3 roky. Dřív nebo později ale časem odešla každá. Tohle je dnes už zcela bezúčelné, komplikuje to spoustu dalších procedur, musím to odstranit. A jsou tam i další, dnes už neužitečné výkonové optimalizace výkonu, které byly zapotřebí na slabších strojích, aby se ty agregace nad hromadou dat rozumně upočítaly. Nejsou špatné, ale příliš komplikují kód, takže je těžké je odignorovat.

Mimochodem 12-jádrový 9 5900x v mém serveru s velkou pamětí přidělenou databázi se dnes už 6 milióny záznamů (při základním joinu se spojuje stejný počet záznamů z Valcu a obou Tristarů s hlavičkovými záznamy) prokousává impozantně rychle.

Dobrá, odstranit bufferování mi zabralo jedno odpoledne, bohužel to ale nestačilo. Některé dotazy jsou nyní neoptimalizované, hlavně ty agregační, které se spouští cronem, ty, které počítaly s tím, že poběží nad maličkou dočasnou tabulkou a nyní mají co do činění s obřími daty. Bohužel ne vše jsem našla hned, takže jsem si připravila krušné chvilky, když jsem jednoho dne před odchodem do práce zběžně nahlédla do Zabbixu a se zděšením uviděla takřka 100% využití CPU VM, na kterém běží databáze. Fve monitoring mi přestal běžet zcela. Nahlédnutím do logů jsem zjistila, že Mysql vyčerpal celý prostor temp na systémovém disku mezivýsledky dotazů, navíc nestíhal vyřídit transakce, které se mu štosovaly tak, že dovedly téměř celý db server vyřadit. Restart pomohl, ale i tak se mi tam občas spouští purge démon, který pěkně kvedlá s daty. Našla jsem další dotazy a uložené procedury, na které jsem pozapomněla, a provizorně je odstavila se značkou TODO.

No jo, už to dlouho nepočká, ten monitoring musím předělat pořádně. Ale kde brát čas…

Jsou tam bohužel i problémy logické, které mi tehdy nepřišly tak důležité, ale po letech provozu už komplikují užití: elektrárna prodělává rozšiřování, a teď tedy i nově už i výměnu některých komponent. Čeká ji i přechod na 24V systém. Typickým ukazatelem, které mi valcMonitor už neposkytuje, je počet cyklů baterie, protože dnes už provozuju třetí sadu paralelně a aktuálně vyrábím sadu čtvrtou (později to přepojím do dvou paralelních sérií). U každé komponenty eviduju datum spuštění a ukončení, logika tahle data ale zatím neuvažuje, takže třeba onen počet cyklů už dnes nic neříká.

Podobně je na tom i poměrně zajímavý ukazatel utilizace (Wh na instalovaný Wp). Data by byla, ale po různých rozšířeních a modernizacích se už jednoduchými agregacemi míchají hrušky s jablkama. Upravit to nebude to pracné ani nijak zvlášť složité, ale nějaký čas mi to zabere.

A jsou tam i další mrtvolky, které nemohu při úpravách přejít, takže pár dní mi to zabere. Jedním z nich je třeba technologie – všechny velké tabulky tam mám ještě v MyIsam – tento engine se před deseti lety doporučoval jako efektivnější, což na slabém Raspberry dávalo smysl. Přepla jsem tabulky na InnoDb, to nějakou dobu trvalo. Pracnější bylo vyrobit relace referenční integrity, bez kterých je použití InnoDb poloviční. Musela jsem nejdřív v tabulkách najít osiřelé záznamy, které se tam skutečně vyskytovaly, ty odstranit, a pak teprve zavést relace. CPU to přepočítal během několika minut, teď už mám tabulky pěkně hlídané a data drží pohromadě.

 

 

Další díly seriálu

<< FVE 11: TS MPPT-60 umíráFVE 13: Upgrade mé FVE na 24V zahájen >>