Fórum | MyPower.CZ

Konecne som rozbehal emulaciu XCom232i takze sa mozem venovat klientovi co bude citat udaje cez XCom232i a posielat vybrane udaje aj cez MQQT (ala sensor).
Kedze s nasadenim MQQT nemam skusenosti (pouzivam skor wcf, webservices) zatial to vyzera tak ze MQQT sensor odosiela informacie bud vo fixnom intervali, alebo len ak nastane zmena. Zatial som nenarazil na riesenie kedy by zaslal udaje ako odpoved na poziadavku.
Vychadza mi to skor na fixny interval, detekcia zmien u float hodnot by vyzadovala definovat oblast necitlivosti.
Ideu mam taku, ze v configuracnom subore sa nastavia (oznacia) parametre, ktorych hodnoty sa maju posielat (len Informacii - Id 3000 je 168) a interval.
Parametre sa citaju po jednom, cize aj cas behu slucky - vycitanie vsetkych pozadovanych parametrov bude obmedzeny ich poctom. Pravdepodobne by bolo dobre aj nejak definovat parametre ktore staci citat v kazdom druhom, tretom kole (pomaly sa meniace) a podobne.
Dalsia vec, kde sa treba rozhodnut je, ci posielat udaje po jednom, t.j. hned ako sa vycitaju, alebo ako skupinu udajov (ulozit napr. do json vety) a posielat po vetach (tak to robi napriklad Axpert/PIP ako odozva pigs).
V niektorych parametroch nemam jasno, napriklad SOC je aj v Info pod 3007 aj v BSP info pod 7002.
Zaujimave je to aj s timeoutom, v dokumentacii sa pise o 2 sekundach.

MQTT taky moc neznám, ale aktualizaci hodnot na MQTT brokeru jsem si vykládal přesně jak píšeš. Tím ale neříkám, že je to správně.
Každopádně výborný počin, moc se těším na další výsledky.

Držím palce. Lebo origo portál nie je nič extra...

Publikovat data na MQTT brokera můžeš podle libosti, nemusí to být ve fixních intervalech.
Posílat hodnotu jako odpověď na požadavek jde taky, i když takový způsob komunikace je typický pro služby a ne pro komunikaci typu PUB-SUB. Dělá se to tak, že klient co publikuje data navíc ještě poslouchá nějaký topic, kde si konzumenti dat mohou publikováním zprávy vyžádat data a publisher jim je pošle do jiného topicu tam kde běžně publikuje (něco jako publikace pro všechny na žádost kohokoli).
Pokud jde o strukturu dat, přijde mi lepší posílat každou hodnotu do samostatného topicu, pokud ta data nemají těsnou časovou souvislost. Takže topicy ve stylu /studer/data/3007, /studer/data/7002 atd. Samozřejmě nic nebrání tomu poslat pak ještě celý balíček dat třeba v json třeba na /studer/data/all. A k tomu pak může být topic /studer/refresh, který publisher poslouchá, a do kterého když někdo zapíše hodnotu 7002 tak publisher publikuje čerstvou hodnotu do /studer/data/7002.
S MQTT mám trochu pracovních zkušeností tak se kdyžtak ptej.

Dalsi krok - vyzera to tak ze vycitanie udajov cez XCom232i bezi.

co sa ma citat som dal configu

Vycitavane bolo aktualne napatie baterie na XTM1 {3000}, actualny prud do/z baterie BSP {7001} a SOC na BSP {7002}.
XTM odpoveda aj ked je vypnute.

to začíná vypadat hodně nadějně. Ať se daří v dalším pokračování.

>>> DanoP: Ahoj, pokracujes pekne ... Rad bych se zeptal na par veci ...
1. Vycitani dat:
S jakou periodou vycitas data / jak rychle to XCOM max. zvlada?
S jakou peridou "Studer sytem" aktualizuje data v jednotlivych "registrech" (napr. proud, SOC u BSP ),?
2. Nikde jsem nenasel k BSP info o "Zero current calibration" a synchronizaci SOC na 100% ...mozna jsem to prehlidl ... Jak to ma Studer vymyslene? Zkousel jsi presnost mereni proudu?

1. Zaviedol som si nieco ako priority, priorita 0 znamena ze sa dany udaj vycita v kazdom "kolecku", priorita 1 cca kazdych 10 sekund a priorita 2 kazdu minutu.
Dlzka trvania kolecka zavisi od poctu vycitanych parametrov. Pokial su zo skupiny Info (jedno ci XTM, BSP) tak je odozva rychla, zatial pouzivam cas medzi vycitaniami 300ms, obcas (naozaj zriedka) nastane timeout (vacsinou XTM) a vtedy sa to pozdrzi - mam nastavene 2s, ale asi to zmensim, pokial do 1s nepride odozva tak uz nepride.
Prave SOC mam jednu z nizsich priorit, ale co vycitavam prudy z BSP, tak to vyzera ze hodnota sa zmeni pri kazdom kole, ale ked budem robit este testy tak sa na to pozriem. Svoju rolu hra aj 4 bytovy float, ktory je dost "hruby".
2. Zero current - neviem, ale zosiluju to dvojitym operakom a v obvodoch operakov (TS912 ?) je dost tranzistorov, takze mam podozrenie na prepinanie zisku, mozno aj polarity na minimalizovanie ofsetu?
Presnost merania - vacsie prudy sa s kliestovym zhoduju ale to je len orientacne, nepriamo meranim napatia na bocniku je trochu problem lebo nemam na meraku skalibrovany rozsah 1mV a uV udaje uz su na hranici stability meraku.
1.5A bolo na mV rozsahu 1,5mV ale na uV rozsahu nieco okolo 1442uV ale uz nestabilne (limity mojho meraku).
Momentalne si posielam 10s priemery v json cez web api.
Rozmyslal som nad mqtt a asi najefektivnejsie by bolo cez mqtt posielat udaj len ked sa zmeni (ak by sa posielali jednotlivo). Nie je to zlozite, len sa mi nechce definovat presnost, ktora bude urcovat kedy sa parameter zmenil. To je dolezite ak sa ma udaj pouzit na nejake riadenie, aby informacia o zmene presla co najrychlejsie.
Ak by som posielal skupiny udajov (tak to robim teraz - poslem si vsetky naraz), tak je tam oneskorenie dane nacitanim skupiny udajov.
Este neviem ako studer pocita minutove priemerovane hodnoty, ci pouziva nejaky druh rolling average alebo natvrdo robi priemer v minutovych intervaloch. V tomto je bezna dokumentacia riadne skupa.

OK Diky DanoP
Srovnavam BSP s BMV 7xx od Victronu a tak nejak uvazuji, kterym smerem jit ...

Ked porovnavas BMV s BSP, tak BMV bezi samostatne, co nie som si isty o BSP. BSP ma sice pripojenie na plus pol baterie a berie z neho aj napajanie, ale neviem ci napaja aj studer zbernicu a bez toho nejde XCom. K udajom/nastaveniu sa da dostat len cez XCom (pre externe zariadenia) alebo cez RCC, inak nema BSP ziadne ine rozhrania typu releovy vystup a pod. BSP v mode LiFe/Lion je len jednoduchy citac Ah, s resetom SOC na 100% po dosiahnuti nastaveneho napatia + vydrz/poklesu nabijacieho prudu. Nic viac.

Presne ako pise DanoP, Battery monitor od Studeru je SBM-02.

Nie, BSP nenapájal zbernicu určite. Can Bus u Studera funguje normálne aj bez BSP.
Samostatne je určite lepší BMV700 od victrona. Ma aj rele.

Frenky sa pytal ako generujem "dotazy" co sa posielaju cez XCom.
Hlavna finta tkvie v tom, ze hlavicka a data maju vlastne kontrolne sucty, cize mam object header, ktory ma metodu na vypocet crc hlavicky, potom mam object frame ktory ma property header, data a ma metodu pre vypocet crc dat. Dalej ma object frame metodu, ktora vrati cely frame ako pole bytov vratane kontrolnych suctov, a toto sa posiela cez seriovy port.
Pozadovane prikazy su nadefinovane configuracnom subore

Cely jeden cyklus poziadavka -> odpoved je potom takyto:
1. z pola prikazov (config subor) sa nacita poziadavka () a vytvori sa frame object (ten si vytvori aj header object).

Nastavia sa property a metoda GetBytes() vrati pole bytov. Toto pole obsahuje header s crc a data s crc - cize komplet ramec, ktory sa odosle na seriovy port.
2. Caka sa na prijem (max cas definovany v time out). a proces sa opakuje.
Co sa tyka prijmu, ten bezi vo vlastnom vlakne (skusobne backgroundworker v StuderComunicator.cs) a len informuje ci je k dispoziici platny frame.
Pre zjednodusenie sa prijate znaky citaju po jednom a vyhodnocuje sa priebezne ci je to platna hlavicka (14 bytov) - frunkcia FrameFnc.IsCorrectCheckSum(header.Skip(1).ToArray())) - pozor do crc hlavicky sa nepocita prvy - start byte hlavicky. Ak je crc hlavicky ok, v hlavicke je aj info o dlzke dat a pokracuje sa v prijme udajov podla dlzky v hlavicke + 2 znaky pre crc data casti.
Ked toto nastane, skontroluje sa aj crc dat a pole bytov sa posunie ako odozva na poslany prikaz, kde sa z neho obnovi object prijateho frame (OnFrameReceived r. 224 v StuderComunicator.cs) a ten sa potom dalej spracuje/transformuje a posle dalej (cez ReportProgress) - ja si ich zoskupujem a serializovane posielam na web server.
Zdrojaky (C#) su tu je to este pred optimalizaciou.
V zdrojakoch su aj funkcie (FrameFnc.cs) pre konverziu floatu, int z bytov platformovo nezavisle - cize vzdy ako little endian a vypocty kontrolnych suctov.
Z bezpecnostnych dovodov je flag ServiceId = ServiceIdEnum.READ_PROPERTY headeru nastaveny natvrdo na citanie, samozrejme je mozne ho nastavit aj pre zapis, treba vsak nastavit vo frame aj spravne datovu cast s pozadovanou hodnotou. Predpokladam ze to ale bude pouzivat len niekto kto vie co robi.
Cez XCom je mozne poslat zapisove prikazy akejkolvek bezpecnostenj urovne !!!