Może ktoś ma wiedzę lub dokumentację techniczna dotyczącą inwertera ESB 6kw-24v.
Do tej pory miałem do czynienia z rs485 i odczytem na arduino liczników energetycznych ORNO OR-WE-517 oraz wersji jednofazowej oraz regulatora ładowania mppt esmart - (jak by ktoś potrzebował mogę udostępnić kod w Arduino - działa cały czas) ale teraz utknąłem z problemem - Kupiłem inwerter ESB - 6kw 24v a tam okazuje sie jest modbus ale po rs232 - i dodatkowo brak jest jakiejkolwiek dokumentacji żeby napisać sobie własny program do odczytu na arduino. Może ktoś coś ma lub pomoże mi go podłaczyć chociażby do arduino - domyślam sie że potrzebny będzie max232 na ttl prędkość transmisji znam jest podana w instrukcji ale nic więcej.
Witaj.
Także mam falownik ESB 6kW-24V.
Sprawa jest generalnie prosta, tylko trzeba rozpracować poszczególne polecenia, a i to niekoniecznie, by pobrać dane z falownika o statusie i bieżącej konfiguracji.
Ot wystarczy wysłać sekwencję bajtów i potem obrabiać odpowiedź. Na potrzeby pobierania statystyk - to wystarczy na dowolnej platformie (AVR/STM32/ARM/Android/PC - no każda powinna potrafić wysyłać gołe bajty po RS232 bez wielkich kombinacji w dowolnym języku programowania).
Akurat przymierzam się do napisania czegoś pod OrangePi, także zmotywował mnie Kolega do wyłuskania transmisji
Wygląda też na to że komunikacja powinna być kompatybilna z falownikiem Voltronic Axpert VMIII 3000VA - tak się ten falownik przedstawia na porcie com.
Konfiguracja portu: 2400 8N1 bez kontroli przepływu lub Xon/Xoff - to i to mi działa.
Warstwa sprzętowa to standardowy port com, zgodny ze standardem. Także MAX232 i podobne rozwiązania są tu na miejscu. Ja akurat używam bramki LAN <-> RS232/485.
Tu lista poleceń, które działają z moim falownikiem - wydobyte z żywego organizmu.
Prawdę mówiąc, nie wiem, dlaczego są takie różnice między komunikacją z aplikacji, a komunikacją z palca. Obie wersje działają jak przepiszę w konsolę. Jednak proponuję używać dłuższych wersji poleceń (fabryczna aplikacja takich używa).
Kolejna rzecz, ten falownik może pracować on-gridowo (mimo iż sprzedawca tego nie podał, a producent przemilczał). W trybie SUB - Energia z niego potrafi cofać się do licznika przy niedociążeniu (jest to niewielki upływ w moim egzemplarzu - na poziomie kilkunastu Wh na godzinę) - kwestia korekty parametrów by to zlikwidować, ale zjawisko jak najbardziej do praktycznego wykorzystania na ongrida (o ile opanuję dostęp do ciekawszych parametrów, bo z siecią to on synchronicznie pracuje w SUB już z fabryki [SUB mnie najbardziej interesuje, ale praca synchroniczna działa jak ogólnie jest włączony "bypass"]).
@update: Znalazłem listę poleceń pod Axperta i wygląda przynajmniej częściowo na zgodną z listingami:
Spoiler:
#Axpert Commands and examples
#Q1 # Undocumented command: 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
#QPI # Device protocol ID inquiry
#QID # The device serial number inquiry
#QVFW # Main CPU Firmware version inquiry
#QVFW2 # Another CPU Firmware version inquiry
#QFLAG # Device flag status inquiry
#QPIGS # Device general status parameters inquiry
# GridVoltage, GridFrequency, OutputVoltage, OutputFrequency, OutputApparentPower, OutputActivePower, OutputLoadPercent, BusVoltage, BatteryVoltage, BatteryChargingCurrent, BatteryCapacity, InverterHeatSinkTemperature, PV-InputCurrentForBattery, PV-InputVoltage, BatteryVoltageFromSCC, BatteryDischargeCurrent, DeviceStatus,
#QMOD # Device mode inquiry P: PowerOnMode, S: StandbyMode, L: LineMode, B: BatteryMode, F: FaultMode, H: PowerSavingMode
#QPIWS # Device warning status inquiry: Reserved, InverterFault, BusOver, BusUnder, BusSoftFail, LineFail, OPVShort, InverterVoltageTooLow, InverterVoltageTooHIGH, OverTemperature, FanLocked, BatteryVoltageHigh, BatteryLowAlarm, Reserved, ButteryUnderShutdown, Reserved, OverLoad, EEPROMFault, InverterSoftFail, SelfTestFail, OPDCVoltageOver, BatOpen, CurrentSensorFail, BatteryShort, PowerLimit, PVVoltageHigh, MPPTOverloadFault, MPPTOverloadWarning, BatteryTooLowToCharge, Reserved, Reserved
#QDI # The default setting value information
#QMCHGCR # Enquiry selectable value about max charging current
#QMUCHGCR # Enquiry selectable value about max utility charging current
#QBOOT # Enquiry DSP has bootstrap or not
#QOPM # Enquiry output mode
#QPIRI # Device rating information inquiry - nefunguje
#QPGS0 # Parallel information inquiry
# TheParallelNumber, SerialNumber, WorkMode, FaultCode, GridVoltage, GridFrequency, OutputVoltage, OutputFrequency, OutputAparentPower, OutputActivePower, LoadPercentage, BatteryVoltage, BatteryChargingCurrent, BatteryCapacity, PV-InputVoltage, TotalChargingCurrent, Total-AC-OutputApparentPower, Total-AC-OutputActivePower, Total-AC-OutputPercentage, InverterStatus, OutputMode, ChargerSourcePriority, MaxChargeCurrent, MaxChargerRange, Max-AC-ChargerCurrent, PV-InputCurrentForBattery, BatteryDischargeCurrent
#QBV # Compensated Voltage, SoC
#PEXXX # Setting some status enable
#PDXXX # Setting some status disable
#PF # Setting control parameter to default value
#FXX # Setting device output rating frequency
#POP02 # set to SBU
#POP01 # set to Solar First
#POP00 # Set to UTILITY
#PBCVXX_X # Set battery re-charge voltage
#PBDVXX_X # Set battery re-discharge voltage
#PCP00 # Setting device charger priority: Utility First
#PCP01 # Setting device charger priority: Solar First
#PCP02 # Setting device charger priority: Solar and Utility
#PGRXX # Setting device grid working range
#PBTXX # Setting battery type
#PSDVXX_X # Setting battery cut-off voltage
#PCVVXX_X # Setting battery C.V. charging voltage
#PBFTXX_X # Setting battery float charging voltage
#PPVOCKCX # Setting PV OK condition
#PSPBX # Setting solar power balance
#MCHGC0XX # Setting max charging Current M XX
#MUCHGC002 # Setting utility max charging current 0 02
#MUCHGC010 # Setting utility max charging current 0 10
#MUCHGC020 # Setting utility max charging current 0 20
#MUCHGC030 # Setting utility max charging current 0 30
#POPMMX # Set output mode M 0:single, 1: parrallel, 2: PH1, 3: PH2, 4: PH3
Trafiłem na ten wątek poszukując możliwości spięcia tych chińskich inwerterów hybrydowych (dostępnych pod wieloma różnymi markami) z jakimś systemem monitorowania.
Bardzo interesująco wygląda udostępniony przez Victrona system Venus, kto nie widział tych victronowych kafelków
Co ciekawe, można go postawić na Rasbperry PI, potrafi samodzielnie wykryć trochę urządzeń (np. moje falowniki Froniusa)
Ale tez jest otwarty na samodzielne budowanie własnych modułów. np ktoś dopisał support świetnego licznika SDM630
Jest do tego cała dokumentacja jak takie moduły podłączyć do VictronVenus
https://community.victronenergy.com/questions/105383/dbus-service-example.html
Gdyby, korzystając z danych które udało Ci się skompletować - dopisać taki moduł do Victron Venus to to naprawdę było by coś!!!
Tych chińskich falowników jest dużo (sam zamierzam sobie taki zamontować) a taka współpraca różnych klocków w ramach jednego systemu była by super. Niestety jest jeden problem - nie potrafię programować w Phytonie
@jurek.parus Ja używam EmonCMS (CMS oparty jest o jQuerry, dane trzyma w MySQL/MariaDB), warstwy pośredniej w postaci MQTT (mosquitto) i Vcom na socat'cie w cronie (do bramki LAN, takie akurat specyficzne dla mnie) - też fajna sprawa bo akwizycja danych oraz wysyłanie poleceń może się odbywać nawet głupim skryptem sh.
A MQTT jest o tyle prostym protokołem, że można spinać wszelkie wynalazki na uC i mieć małe centrum kontroli.
Całość postawiona na Orange Pi R1 i wygląda to tak. Dashboardy są konfigurowalne.
Jedno co jeszcze mam w planach, to dopisanie do DemandShapera wystawiania stanów na GPIO względem parametrów na falowniku i 15min historii.
Obecnie się z tym nie śpieszę, gdyż obecnie wystawiam CMS w świat i niefortunnym by było, jak by mi jakiś szkodnik mógł przestawiać parametry. Więc cały system nie ma obecnie wbitych komend sterujących.
Zależało mi głównie na podglądzie parametrów na np. telefonie po wi-fi, czy tablecie jako stała konsola wisząca na ścianie.
Victron Venus można podpiąć pod Victron VRM Portal - a tam są gromadzone dane.
Oczywiście im bardziej złożony system tym wykresy ciekawsze - tu akurat drukarnia z kanału Mikrogeneracje
https://vrm.victronenergy.com/installation/77168/dashboard
właśnie zakupiłem i zamontowałem podobny falownik tyle że 3kW. Dzięki za podesłanie pełnych komend, te z monitora portu miały na końcu jakieś krzaki i po wysłaniu z konsoli falownik nic nie zwracał. Sprawdzę jutro jak z tymi poniżej.
Wracając do rzeczy. Napisałem prosty kod na układ ESP 8266, który ma za zadanie odebrać ramkę z wartościami napiec itp po uart i wysłać ją po MQTT dalej czyli taki UART to MQTT gateway. Jak było napisane powyżej do ESP/arduino itp. oczywiście musi być konwerter MAX232.
Witam
Mam uruchomioną komunikację z przetwornicą (jak w temacie), po mqtt via wifi. Większość tematów mqtt ogarnąłem za pomocą Arduino (esp32s). Całość działa pod kontrolą Homeassistant'a i wrzucona na tablet zamocowany w przedpokoju pozdrawiam
Aby nie być gołosłownym, podrzucam kolegom plik nagłówkowy z główną strukturą zapytań. może to pomoże. Testowałem, także napisany przeze mnie program na RPI, jednakże nie dawało długofalowych stabilnych odczytów z ESB
Bardzo ładnie to wygląda. Napisałem bardzo prosty kod na samo ESP32, ma za zadanie przechwytywać dane z serial monitora i wysyłąć dalej po mqtt. Jak doszlifuję załączę w tym wątku.
Sekwencja komend. Soft producenta najpierw odpytuje z czym ma do czynienia.
Druga rzecz, że prawdopodobnie wysyłasz bez znaku 0Dh na końcu, albowiem nawet na śmieci powinien odpowiedzieć (NAKss.
Może być to jeszcze związane z kontrolą przepływu danych.
P.S Do tematu:
Też miałem problemy ze stabilnością mojego OrangePi. Wygląda na to, że te płytki malinopochodne są średnie do takich zadań. Ponadto zauważyłem silny związek z jakością użytego zasilacza. Im porządniejszy, tym dłużej to pracuje bez zawieszki.
Ponadto doświadczyłem nieprzyjemnych problemów z zegarem - te płytki nie mają RTC w pakiecie i przez w przypadku braku netu, zdarzało się, że wartości pobrane z falownika były źle umieszczane na osi czasu.
Wielki plus, że to oparte o bazę danych i łatwo to było prostować kwerendami.
Witam
Proponuję wstępnie zapoznać się ze specyfikacją struktury zapytań oraz zwracanych wiadomości.
Pomoże to w zrozumieniu protokołu komunikacyjnego. Wpisz w przeglądarkę "QPI Device protocol ID Inquiry"
a otrzymasz informacje skąd ściągnąć rs232-communication-protocol.pdf. Jeśli go już masz to otrzymasz
odpowiedzi na większość pytań. Co do kodowania to sprawa wygląda dość prosto. Całość jest/może być pisana
pod Arduino z wstawkami C++ (*.h, *.cpp) bardzo upraszczającymi proces bibliotekami komunikacyjnymi.
Funkcje i kilka procedur tworzą całość programu. Ograniczyłem komunikację do niezbędnych elementów aby, nie
obciążać komunikacji ESB<->ESP32. Przetwornice ESB mam w piwnicy a terminal piętro wyżej, więc zrezygnowałem
z możliwości dłubania przez sieć w jej ustawieniach. Jest to poprostu bezpieczne
Jak działa program?
1. ustanowienia portu : Serial.begin(115200); //debug arduino
Serial4.begin(2400); //port ESP32<->ESB
2. aktywacja wifi WiFi.begin(ssid, password)
aktywacja klienta mqqt client.setServer(mqttServer, mqttPort);
podłączenie klienta client.connect("Solar Client", mqttUser, mqttPassword
3. Zdefiniowanie buffora danych
4. Zdefiniowanie zmiennych typu String "question"
5. Procedury kontrolne potrzebne przy wysyłaniu i odbiorze message crc 16
6. Procedura kontrolna tzw pierwszego znaku lub jak kto woli nagłówek
7. Procedura parsująca ciągi otrzymanych wg kolejności danych
8. Procedury parsujące otrzymane wiadomości
9 Procedury parsujące zmienne typu float
5. Procedury obliczające długość wysyłanej wiadomośći mqtt
11. Procedura publikująca message "client.beginPublish(grid_topic, msgLen, false);"
to tak na szybko, musiałem zaglądnąć do notatek i komentarzy w programie bo to już trzeci rok
jak to hula.
pozdrawiam
Druga rzecz, że prawdopodobnie wysyłasz bez znaku 0Dh na końcu, albowiem nawet na śmieci powinien odpowiedzieć (NAKss.
NAK pojawia się w wiadomościach zwracanych z przetwornicy ale w przypadku próby ich modyfikacji...
jest tylko coś takiego "(NAK<cr>"
Co masz na myśli pisząc o kontroli przepływu danych? skąd i dokąd, programowo, sprzętowo ? nie ma w tym protokole takich rozwiązań
Bardzo dziękuję za odpowiedź, namierzyłem już dokumentację i będę to analizował.
Prośba jeszcze tylko o rzut okiem na schemat połączeń. Chciałem się upewnić czy to jest na pewno prawidłowo podłączone. W moim falowniku jest wejście RJ45 zakończonej żeńskim wtykiem db9. Dalej wiadomo musi być konwerter na usb albo rs232 na urat o ile dobrze rozumiem.
Witam
W swoim rozwiązaniu przetestowałem klika konwerterów najlepszym okazał się
(pozostałość po testach z rpi0 - ESB) "Serial Pi Zero MAX3232 - interfejs RS232 dla Raspberry Pi", polecam każdy który zawiera sprawdzony Max3232, ale jeśli ten, który używasz nie grzeje się itp. to OK. Nie widzę co to jest za układ między płytką WEMOS a wtykiem rs232, jeśli jest to tylko konwerter poziomów logicznych, to nie jest to dobre rozwiązanie. Użyj do testów oryginalną przejściówkę RJ->RS232 dołączoną do przetwornic ESB i konwerter na Max3232 złącze db9(male). Komunikacja sprzętowa oparta jest na liniach różnicowych co wymusza stosowanie dedykowanych konwerterów. Do testów i debugowania ("Serial.println")z użyciem edytora Arduino wystarczy konwerter rs232<->usb
Pozdrawiam
Ten układ w środku to gotowy konwerter oparty właśnie na układzie max3232. Robiąc ten rysunek uświadomiłem sobie że chyba w moim wykonaniu mam pomylone rx z tx, będę to testował. Jak skończę pochwalę się finalnym rozwiązaniem.
komunikacja z przetwornicą jak w poprzednich postach
zapytanie : QEY<YYYYnnn><cr> (query year, checksum, carriage return)
<YYYY> Y zmienna typu int is an Integer, checksum for QEYYYYY, odpowiedz 8 cyfr wartość w kilowatach
pytanie:QEY2011179<cr>
odpowiedz: (03012300<cr>
miesiąc, dzień podobnie
Pozdrawiam
Trafiłem na ten wątek próbując skomunikować się z ESB 10kW-48 a informacje jakie zostały tu umieszczone są szalenie przydatne Mam jednak identyczny problem jak kolega uncle__saddam, mianowicie na jakiekolwiek zapytanie inwerter odpowiada pustą linią.
Walczę na malinie i napisałem prosty skrypt, taki jak ponizej:
--------------------------------------------
import time
import serial
ser = serial.Serial('/dev/ttyUSB0', 2400, timeout=1)
Konwerter USB na RS232 to CH340, działa z WatchPowerem
Przewód RJ45 na RS232 oryginalny z inwertera
Nie wiem gdzie szukać, może mam jakiś banalny błąd w kodzie, którego nie widzę....
Ostatecznie pewno skończy się na Arduino, ale jakoś wrodzony upór ciągnie mnie do tego aby chociaż raz pobrać dane z inwertera za pomocą pythona....
@matcheyrc1 Próbowałeś wpisywać te komendy w terminalu np PuTTY?
Zauważyłem, że inwerter zwraca poprawne odpowiedzi na komendy np qpigs, qey, qem itd, wtedy gdy tuż przed nimi wysłane są odpowiednio 3 komendy qpi, qmn i qid. Nie wiem, czy to jest wymagane, ale u mnie to tak działa.
Co do python'a to ja akurat nie mam doświadczenia w tym języku, natomiast napisałem prosty program w c# który zwraca poprawne odpowiedzi, może komuś się przyda:
Code: csharp
Log in, to see the code
Stworzyłem sobie też "bramkę"/sterownik na esp8266 którego zadaniem jest komunikacja z inwerterem i udostępnianie "dalej" wyników
Źródła tego projekciku sa na GH: ESBDriver
Brakuje tam oczywiście pliku pwd.h, który powinien wyglądać tak:
witam
zacytuję to co napisałem w swoim poście
"Proponuję wstępnie zapoznać się ze specyfikacją struktury zapytań oraz zwracanych wiadomości.
Pomoże to w zrozumieniu protokołu komunikacyjnego. Wpisz w przeglądarkę "QPI Device protocol ID Inquiry"
a otrzymasz informacje skąd ściągnąć rs232-communication-protocol.pdf."
Co do "maliny" to odpuściłem sobie to rozwiązanie na rzecz esp32s aczkolwiek nie pozbawione wad (odpowiednie zatasowanie watchdog'a)
Wykorzystuję kilka struktur do wyłuskania odpowiednich informacji:
"
struct QpiMessage
{
byte protocolId;
};
struct QpigsMessage
{
unsigned long rxTimeSec;
float gridV;
float gridHz;
float acOutV;
float acOutHz;
short acOutVa;
short acOutW;
byte acOutPercent;
short busV;
float battV;
float battChargeA;
float battPercent;
float heatSinkDegC;
float solarA;
float solarV;
float sccBattV;
float battDischargeA;
bool addSbuPriorityVersion;
bool isConfigChanged;
bool isSccFirmwareUpdated;
bool isLoadOn;
bool battVoltageToSteadyWhileCharging;
byte chargingStatus;
byte reservedY;
byte reservedZ;
long reservedAA;
short reservedBB;
};
struct QmodMessage
{
char mode;
};
"
Dodano po 11 [minuty]:
Ciekawostką jest to, że nowe ESB, dość dobrze współpracują z bramkami wifi, które mają zaimplementowany protokół Modbus TCP i tu sprawa odczytu danych robi się trywialnie prosta.
pozdrawiam
