Software pro Axpert (USB)

[cz7jfm]

Zdravím.
Protože jsem nenašel na internetu software, který by uměl vyčítat data z Axpertu msxe z USB portu do RPi, napsal jsem si vlastní. Snad poslouží i někomu jinému. Pokud máte někdo také vlastní aplikaci, sem s ní
Nebo se prosím alespoň podělte o své zkušenosti.
Předem díky.

[cz7jfm]

Zdravím.
Protože jsem nenašel na internetu software, který by uměl vyčítat data z Axpertu msxe z USB portu do RPi, napsal jsem si vlastní. Snad poslouží i někomu jinému. Pokud máte někdo také vlastní aplikaci, sem s ní
Nebo se prosím alespoň podělte o své zkušenosti.
Předem díky.

Ještě dodávám že to spouštím php scriptem v nekonečné smyčce. Jednorázové spouštění nefunguje spolehlivě.
Data v /tmp zpracuji ve stejném PHP scriptu a odešlu do grafu, nebo zobrazím na webu.
např. http://cz0njf.dreamsys.cz/axpert.html

Omlouvám se všem komu to nebude fungovat správně, mi to jede spolehlivě více, než 14 dnů.

[josse]

Zdravím,

Já jsem měl stejný problém, také jsem nenašel žádný SW co by mi vyhovoval.
Nevím jestli víte o chybě výpočtu CRC pro příkaz POP02 všechny příkazy jsou správně kromě tohoto jednoho.
více zde:
http://forums.aeva.asn.au/forums/forum_ ... rter#53712

Když jsem psal vlastní ovládání měniče, vyčítání údajů a odesílání do EmonCMS, jako příklad jsem měl:
https://www.raspberrypi.org/forums/view ... 1&p=985570
https://github.com/scottwday

Moje aktuální verze napsaná v pythonu:
https://github.com/JosefKrieglstein/Axp ... /axpert.py

Vzhledem k malé kapacitě akumulátorů (4x12 V 180 Ah) a malému svitu říjen-únor jsem doplnil přepínání mezi SBU a Utility automaticky během dne v závislosti na nízkém/vysokém tarifu. Řídím nabíjecí proud v závislosti na tarifu, denní době a hlavně aktuálnímu příkonu. Aby mi to neshazovalo jistič. Když přes měnič jde maximální proud omezuji nabíjení/udržování nabitých akumulátorů.

Ještě nevím jak doplnit ruční ovládání, které by se mohlo občas hodit, asi využiji MQTT. Využívám RS232 místo USB. Radši než vlastním zobrazením jsem šel cestou právě EmonCMS ve kterém jsou vyřešeny i pomocné výpočty, podmínky, grafy, prostě skoro vše co je potřeba. (http://emoncms.trenet.org/dashboard/view?id=3)

MQTT i EmonCMS je použitelné na více než jen měniče a baterky.

[cz7jfm]

Zdravím,

Já jsem měl stejný problém, také jsem nenašel žádný SW co by mi vyhovoval.
Nevím jestli víte o chybě výpočtu CRC pro příkaz POP02 všechny příkazy jsou správně kromě tohoto jednoho.
více zde:
http://forums.aeva.asn.au/forums/forum_ ... rter#53712

Když jsem psal vlastní ovládání měniče, vyčítání údajů a odesílání do EmonCMS, jako příklad jsem měl:
https://www.raspberrypi.org/forums/view ... 1&p=985570
https://github.com/scottwday

Moje aktuální verze napsaná v pythonu:
https://github.com/JosefKrieglstein/Axp ... /axpert.py

Vzhledem k malé kapacitě akumulátorů (4x12 V 180 Ah) a malému svitu říjen-únor jsem doplnil přepínání mezi SBU a Utility automaticky během dne v závislosti na nízkém/vysokém tarifu. Řídím nabíjecí proud v závislosti na tarifu, denní době a hlavně aktuálnímu příkonu. Aby mi to neshazovalo jistič. Když přes měnič jde maximální proud omezuji nabíjení/udržování nabitých akumulátorů.

Ještě nevím jak doplnit ruční ovládání, které by se mohlo občas hodit, asi využiji MQTT. Využívám RS232 místo USB. Radši než vlastním zobrazením jsem šel cestou právě EmonCMS ve kterém jsou vyřešeny i pomocné výpočty, podmínky, grafy, prostě skoro vše co je potřeba. (http://emoncms.trenet.org/dashboard/view?id=3)

MQTT i EmonCMS je použitelné na více než jen měniče a baterky.

Díky za odpověď, jsem rád, že je tu někdo kdo se tím také zabývá.

K tomu CRC, nevím jestli je to chyba, ale v každém případě se to odchyluje od standardu výpočtu pro CRC-CCITT (XModem). Ve skutečnosti je to tak, že podle tohoto výpočtu pokud v horním nebo spodním bajtu výpočtu CRC vyjde hodnota 0x28, nebo 0x0d, nebo 0x0a, je potřeba v vypočtené hodnotě přičíst 0x01. Já na to také narazil při POP02.

Co se týče automatického přepínaní stavů, nebo dálkové ovládání (battery, bypass) tak to mám již také vyřešeno.
Postupoval jsem úplně stejně. QPIGS a QMOD se vyčítá ve skriptu neustále dokola (co 5s) programem který jsem zde zveřejnil a ostatní příkazy PCP00, POP02, QPIRI atd. (napsané v C), spouštím řízené dalším skriptem, který čeká až ten první provede zápis do souboru v /tmp a teprve potom pošle další instrukce na Axperta.
Dálkově to řeším přes mobilní aplikaci https://play.google.com/store/apps/deta ... spberryssh
a navíc ovládám ještě různá relé přes GPIO.

EmonCMS, dobrý, také tam mám účet, ale kousek vedle máš prý Luboše "lzahradil" a myslím, že ve spolupráci s ním jsou ty možnosti ještě vyšší, nehledě k tomu že ty data lze posílat na několik serverů (jen je mít )

Pokud by byl zájem o ty zdrojáky přepínání stavů, tak je také poskytnu.
Bohužel celé je to postaveno alespoň na částečné znalosti PHP (je to takové dodělej si sám na míru).

[josse]

Chápu to správně, že máš dva scripty, oba umí komunikovat s měničem, jeden jen vyčítá a odesílá, druhý spouští ten první a když první není spuštěny, tak odesílá povely? K sériovému portu nemůžou být připojené dva najednou ve stejnou chvíli, jak je to s USB nevím. Komunikaci bych chtěl mít na jednom místě, ale ještě nevím jak.

Netuší někdo jak je v Axpertech řešeno ukládání nastavení, kolik změn je to schopno ustát. Obávám se aby to nebylo do EEPROM a za rok už to nešlo přepsat.

[cz7jfm]

Chápu to správně, že máš dva scripty, oba umí komunikovat s měničem, jeden jen vyčítá a odesílá, druhý spouští ten první a když první není spuštěny, tak odesílá povely? K sériovému portu nemůžou být připojené dva najednou ve stejnou chvíli, jak je to s USB nevím. Komunikaci bych chtěl mít na jednom místě, ale ještě nevím jak.

Netuší někdo jak je v Axpertech řešeno ukládání nastavení, kolik změn je to schopno ustát. Obávám se aby to nebylo do EEPROM a za rok už to nešlo přepsat.

Jeden script spouští tu binárku na vyčítání dat (co 4s odsadí port USB a ihned uvolní). Druhý script po spuštění čeká do uvolnění USB portu a potom spouští jinou binárku pro nastavení parametrů (obsadí USB port a po dokončení příkazu opět uvolní, aby byl k dispozici zase tomu prvnímu scriptu).

S tou EEPROM netuším, ale teď jsi mi ale nasadil brouka do hlavy.

[lzahradil]

Netuší někdo jak je v Axpertech řešeno ukládání nastavení, kolik změn je to schopno ustát. Obávám se aby to nebylo do EEPROM a za rok už to nešlo přepsat.

Te EEPROM bych se uplne nebal. Pokud tam teda nebudes zapisovat v nejake caste periode.
Obsazena je 24C04 ktera by mela mit kolem milionu zapisu

[DanoP]

Pozeral som komunikaciu medzi WatchPower a PIP4048 a nasiel som v nej prikaz "QPIGS0", vratene udaje su mierne odlisne od odpovede na QPIGS:
QPIGS
(243.9 50.0 230.0 50.0 0138 0138 003 422 52.80 000 036 0050 0000 000.0 00.00 00002 00010000 00 00 00000 010

QPGS0
(1 92931609100044 B 00 244.0 50.01 230.0 49.99 0138 0133 003 52.8 000 036 000.0 000 00138 00133 003 00000010 0 3 040 120 30 00 002

Nema niekto aktualizovany popis seriovej komunikacie s popisom QPGS0 ? Ozaj ako pocitate vybijaci prud baterie?

[josse]

Existuje kompletní popis příkazů, někde jsem ho našel.
Moje kopie jsou zde:
https://josseowncloud.trenet.org/public ... 1981ca8170
https://josseowncloud.trenet.org/public ... 9eaae28c8e

[josse]

QPIGS: Device general status parameters inquiry
QPGSn: Parallel Information inquiry, n je pořadí měničů začínající 0

Je pravda, že je potřeba oba příkazy kombinovat, protože jeden nestačí. Já beru Battery Dischcharging Current a Battery Charging Current z QPIGS, 9-té a 15-té číslo. z QPGS0 beru momentálně pouze Line/Battery mode, ostatní beru z QPIGS.

V tvém případě je nabíjecí proud 0A, vybíjecí proud je podle mě u tebe 2A. Můj axpert při malých proudech trošku kecá zaokrouhlovací chybou. 0,8A je u něj stále 0A, takže si nemyslím, že to je zaokrouhlení, ale useknutí. Kdyby to opravdu usekávalo, pak to sedí na jednotky A přesně.

Mě se nepodařilo sprovoznit následující příkazy: PPCPnXX, QPIRI, vzdal jsem zjišťování proč jim měnič nerozumí.

[DanoP]

Vdaka za popis prikazov, v tom co mam neboli pre QPIGS popisane hodnoty pre stlpce P az W. Status (bat/line ..)beriem z QMOD. QPIRI mi funguje. V asci+hex to vyzera takto (s crc + CR) Q51 P50 I49 R52 I49 F8 T54 0D

[DanoP]

Este som si vsimol ze charge led-ka pri floate trvale svieti, pri nabijani blika, dokonca sa mi zda ze je rozdiel ci nabija v rezime bulk alebo float, ale zatial som nenasiel prikaz co by vratil tuto info.

[cz7jfm]

Este som si vsimol ze charge led-ka pri floate trvale svieti, pri nabijani blika, dokonca sa mi zda ze je rozdiel ci nabija v rezime bulk alebo float, ale zatial som nenasiel prikaz co by vratil tuto info.

No nejsem si úplně jistej, všiml jsem si toho v popisu instrukci teprve nedávno, zatím nesvítí slunko a nemohu ověřit (plně nabít baterii).
V device status (b104b105b106) by se měla v prvním bajtu (104) objevit 1 při float (snad). B104: Flag for charging to
floating mode.

Brzy zjistíme na http://cz0njf.dreamsys.cz/axpert.html

[josse]

Dopsal jsem do skriptu v Pythonu podporu USB. Pokud by někdo chtěl, napište. Subjektivně mi přijde, že po USB to je rychlejší než RS232. Ale moje implementace v Pythonu není z nejčistějších... Zatím odlaďuju, pak to nahraju na github, kde je ten můj starší skript.

[josse]

Kdyby chtěl někdo přesnější měření vstupního výkonu na Axpertu:
Nedokumentovaný příkaz: Q1, 14-té číslo, SCCChargePowerWatts

LocalInverterStatus (seconds from absorb), ParaExistInfo (seconds from end of Float), SccOkFlag, AllowSccOnFlag, ChargeAverageCurrent, SCC PWM Temperature, Inverter Temperature, Battery Temperature, Transformer Temperature, GPDAT, FanLockStatus, FanPWMDuty, FanPWM, SCCChargePowerWatts, ParaWarning, SYNFreq, InverterChargeStatus

více viz: http://forums.aeva.asn.au/viewtopic.php ... 332#p60229

Rozdíl:

Kostrbaté je původní oficiální měření, hladké je přes příkaz Q1
Chyba je cca 6,6 %. V mém dnešním zisku to dle LCD a normálních příkazů byla energie 4308 Wh, na vstup Axperta ale doputovalo ve skutečnosti 4613 Wh.

Tohle zjištění mi poněkud kazí tu relativně dobrou účinnost celku, kterou jsem kdysi změřil a to o docela dost, znamená to, že mnou zjištěná hodnota 93,5 % je ve skutečnosti 88,4 %.

[josse]

Aktualizace SW v python přes USB, už umí usínat druhého axperta při nečinosti, odběr uspaného klesne na 0,2-0,3 A z původních 1 A. Tvrdí 15 W, já bych s tím i souhlasil.

Nově tedy přepsat statistiky klidové spotřeby 2x AXPERT -> 8 kW měnič s klidovou spotřebou 55+15= 70 W.

Celý den se tu babrám v poslání více než 8bajtů přes USB bez "newline". Musel jsem změnit knihovny pro přístup na /dev/hidrawX, z původních open()/read()/write() na os.open()/os.write()/os.read(), ty jsou výrazně rychlejší, ale měnič to nedává, tak tam mám strašně time.sleep() aby to nedělalo chyby v komunikaci.

Zvolil jsem si treshold 1800 W, pod běží jeden, nad běží oba. Interval je momentálně 11 sekund, za tuto dobu se dostane v pomalé komuniakci na nové čísla TotalOutputActivPower.

QPGS0 : (1 92931707102911 B 00 000.0 00.00 229.9 50.00 0321 0265 006 54.5 000 077 082.6 000 00321 00265 003 10100110 1 2 060 140 02 04 002
QPIGS : (000.0 00.0 230.0 50.0 0322 0259 006 436 54.50 000 077 0041 0004 079.3 54.58 00002 00110110 00 00 00251 010
Q1 : (00000 00000 01 01 00 032 025 032 041 00 00 000 0030 0256 0000 50.00 11G
QBV : (54.5 077
QPGS1 : (1 92931712100540 S 00 000.0 00.00 000.6 50.00 0000 0000 000 54.5 000 077 000.0 000 00321 00259 003 00000100 1 3 060 140 02 00 001
Load: 265 MODE: 1|2
Second inverter already sleeping
no command

Toto se musí periodicky vyčíst, postupně zpracovat a odeslat na EmonCMS. Příkazy delší než 6 znaků (delší než 8 včetně CRC a <newline> je třeba rozdělit a odeslat dvakrát. Než jsem přišel na to kde je chyba, ani na to nechci myslet.

Implementovány příkazy MNCHGC1497, 1498 dostupné v modifikovaném FW 73.00E. Pokud do toho napojím i BMS, budu ještě řešit MNCHGC499-640.

[youda]

Tak to je super počin! Ty jsi z těch Axpertů prostě udělal Studery

Ohledně toho automatického vypínání druhého měniče v tandemu, je vhodné ošetřit tam pár stavů. Napadá mne například toto:
1) Přidat hysterezi, aby ON/OFF zbytečně necyklovalo
2) Nevypínat druhý měnič, pokud v posledních 30ti minutách bylo potřeba více než X výkonových špiček (toto by mělo řešit termostaty v troubách, žehličkách apod. Tam by prosté hlídání pevného limitu mohlo způsobovat cyklování.
3) Alternativně lze bod dvě řešit tak, že pokud bylo ON/OFF provedeno v posledních 5ti minutách vícekrát, tak následující ON/OFF bude provedeno nejdříve za dalších 5 minut
4) Je-li to technicky možné, je vhodné vypínaný měnič střídat. V liché dny vypínat jeden. V sudé dny vypínat druhý. Reset CPU totiž jednou za čas prospěje.

[josse]

Tak to je super počin! Ty jsi z těch Axpertů prostě udělal Studery

Ohledně toho automatického vypínání druhého měniče v tandemu, je vhodné ošetřit tam pár stavů. Napadá mne například toto:
1) Přidat hysterezi, aby ON/OFF zbytečně necyklovalo
2) Nevypínat druhý měnič, pokud v posledních 30ti minutách bylo potřeba více než X výkonových špiček (toto by mělo řešit termostaty v troubách, žehličkách apod. Tam by prosté hlídání pevného limitu mohlo způsobovat cyklování.
3) Alternativně lze bod dvě řešit tak, že pokud bylo ON/OFF provedeno v posledních 5ti minutách vícekrát, tak následující ON/OFF bude provedeno nejdříve za dalších 5 minut
4) Je-li to technicky možné, je vhodné vypínaný měnič střídat. V liché dny vypínat jeden. V sudé dny vypínat druhý. Reset CPU totiž jednou za čas prospěje.

1. No už jsem na to přišel mikrovlnnou troubou, já trouba 1800 nahoru i dolů, co mě to napadlo! Asi jsem to psal když jsem neměl HW, nanečisto. Ohřívám si jídlo a vidím to... Ono to chvilku trvá, takže kratší čas než minutu si to vyřídí vlastně samo. Trouba, žehlička, bude třeba to chvilku sledovat. Ještě že máme ty grafy.
2. Vím, ale asi to nechci, maximálně na řádově minuty... Budu o tom přemýšlet. Časovače jsem v Pythonu ještě nepsal.
3. To se mi líbí víc. Ale jestli to na mé programátorské schopnosti už nebude příliš složité...
4. No jak na co... Blbý je že jeden musí být master a vypnout master znamená, že master začne být ten druhý. Takže vlastně vždy vypnu master, to se mi vůbec nelíbí. Například synchronizaci se sítí řídí právě master (to už jsem vyzkoušel) a mohlo by to dělat neplechu, kdyby se to přeplo na síť a uspalo v jeden moment. Další blbosti to bude dělat ráno a večer se sluncem. Reset se nestane, takže výhody nejsou... Když budu vypínat jen jeden, mám velkou šanci, že měniče neodejdou na opotřebení současně, ale napřed jeden a budu mít prostor s tím něco dělat.

[cerm]

Našel jsem logger SolPipLog a celkem snadno rozběhl na RPI , data odesílá na emoncms.
Pro Voltronic Axpert, Mppsolar PIP, Voltacon, Effekta a další klony.
https://github.com/njfaria/SolPipLog

[ferdinand]

Úspěšně používám nejméně dva roky.Je to super aplikace,jednoduchá a docela spolehlivá , zcela zdarma a autor jí neustále vylepšuje. Odesílá i na pvoutput .