Huawei SUN2000 Modbus RTU oder TCP

[Dütt]

crusherv9 die emma kannst du nicht per Modbus TCP abfragen, weil die die ID 0 hat und laut loxone ist die 0 für Broadcast und kann nicht abgefragt werden. Habe aktuell auch die Emma verbaut und frage die daten über Iobroker ab.

https://forum.iobroker.net/topic/71768/test-adapter-sun2000-v0-1-x-huawei-wechselrichter/690

Mit dem plugin funktioniert das sehr gut.
im dem Pluginist ein Proxy server integriert,
damit kannst du dann die Daten per Modbus TCP
vom IO Broker abfragen.

Allerdings aktuell nur alle 5 Sekunden

[Rar9]

Leider Stimmt das mit der EMMA nicht. Sie baut zwar die Modbus Verbindung auf, jedoch muss man die Modbus Adresse vom Inverter eingeben damit die Kommunikationfunktioniert.

[Bernhard373]

Hallo crusherv9,

Ich habe die gleichen Wechselrichter wie Du - allerdings mehrere wegen größerer Anlage.

Das mit den RS485 Anschlüssen ist ein bisschen verwirrend:

An einen RS485 Port kann man grundsätzlich mehrere Geräte anschließen. Es ist ein "Bus" und keine Punkt-zu-Punkt Verbindung.

Der Wechselrichter, Batterie und Emma sprechen aber das Protokoll "Modbus" über RS485. Hier kann man zwar auch mehrere Geräte anschließen. Allerdings darf es nur einen Master pro Port geben. Der Master schickt dabei Kommandos und die "Slaves" antworten darauf.

Der SUN2000-12K-MB0 hat zwei RS485 Ports:

• Der erste Port hat den A-Anschluss an den Pin 1 und Pin 2. Diese zwei Pins sind elektrisch einfach miteinander verbunden und dienen dazu, mehrere Geräte an einem Bus anzuschließen. Der B-Anschluss ist an den Pins 3 und 4.
  Bei diesem Port ist der Huawei wohl immer "Slave" und hört auf Kommandos vom SmartDongle oder Emma.
• Der zweite Port hat den A-Anschluss an Pin 7. Der B-Anschluss ist an Pin 9.
  Bei diesem Port ist der Huawei wohl Master und schickt Kommandos an die Batterie und an den Strommesser.

Bei Dir sind wohl beide Ports belegt. Einer ist an die Emma angeschlossen und einer an die Batterie.

Du kannst also nicht einfach irgendwas an Pin 2 und 4 anschließen und dann Kommandos schicken - das kollidiert dann mit den Kommandos, die die Emma schickt.

Was Du aber machen kannst, ist an den RS485 Ports zu "lauschen". Also nicht selber Kommandos schicken, sondern einfach mithören, was geschickt wird und diese Daten auswerten.

Bei mir ist das ausreichend, da der SmartDongle oft genug nachfragen muss, um die Anlage zu steuern. Ist bei der Emma sicherlich ähnlich.

Ich habe also zwei Waveshare RS485 -> Ethernet Adapter benutzt. Jeder hängt an einem Port und schickt den Traffic per UDP an Loxone.

In Loxone gibt es kleine C-Skripte (für jeden Port eines), die die Daten bekommen und die Werte auslesen, die ich für meine Steuerung brauche.


Zum Einrichten würde ich so vorgehen:

1. Waveshare an RS485 und Ethernet Anschließen. Folgende Parameter:
   1. Work Mode: UDP
   2. Destination IP/DNS: IP-Adresse des Miniservers
   3. Port: muss mit dem C-Skript übereinstimmen
   4. Baudrate 9600, Databits 8, Parity none, Stopbits 1, Flow control none
   5. Protocol none
2. Im Miniserver einen "Virtuellen Eingang" vom Typ "UDP" erstellen. Diesen auf die richtige Portnummer konfigurieren. Nun kannst Du mit dem Monitor in Loxone sehen, ob irgendwelche Daten kommen.
3. Das gleiche für den zweiten Port machen
4. Die C-Skripte anpassen, so dass sie die für Dich interessanten Werte rausfiltern.

Ich hänge die C-Skripte mal mit an.

[sLindi]

Hallo Dütt,

Ich habe nun auch ein Waveshare Modul an Pin 1+3 anschlossen, leider schaffe ich es nicht, eine Verbindung herstellen zu können.

Nutzt du Modbus RTU parallel zu Modbus TCP, oder ausschließlich Modbus RTU?
Könntest du bitte noch ein paar Details zu deiner Konfiguration anführen?

• Einstellungen im Waveshare Modul (Baudrate,...)
• Einstellungen in der Config (Timeout,...)

Vielen Dank,
sLindi

Nochmal kurzer Statusupdate: (zum ursprünglichen Thema, also nicht der Diskussion mit EMMA)

Seit dem Update des Dongles wie hier https://www.loxforum.com/forum/germa...awei-pv-update beschrieben funktioniert die Kommunikation mittels Modbus TCP einwandfrei.
Einige Werte frage ich nun sogar problemlos alle 1s ab.
Ich habe die Versuche mittels Modbus RTU daher nicht weiterverfolgt => sehe da aktuell auch keinen Grund mehr dafür!

[marksa]

Hallo Bernhard373

Ich habe zwei WR, 1x 10ktl m1 (master), 1x 4ktl m1, DTSU666H + LUNA 10KWH. Aktuell noch mit dem sdongle verbunden.

Bisher frage ich meine Daten via Modbus TCP vom SDongle ab. Möchte die Cloud aber los werden. Ohne Internet bootet der dongle jedoch alle 1-2Minuten und zerhaut mir meine Modbus TCP Abfragen.

Nun bin ich auf deinen Ansatz gestoßen.
einen Waveshares Modbus -> ETH Converter habe ich bereits, war bisher als TCP Server jedoch erfolglos, da die ModBus RTU Abfragen mit angeschlossenem Dongle nicht funktionieren und ohne Dongle meine WR Kaskade + LUNA nicht mehr sauber funktionieren will. (slave WR bleibt stur in Status "Netzanschluss Stromlimit" und will nicht einspeisen).

Der Waveshares hängt am Master an Pin 2+4, an Pin 1+3 hängt der 4ktl WR.

Nun zu deiner Lösung:
- Der Download von ModbusSnifferBatteryPowerMeter_c.txt funktioniert leider nicht (kannst Du das nochmal hochladen?!)
- Ich habe den Waveshares Converter auf UDP Port 4195 wie in deinem Script angegeben abgeändert
- Virtual UDP Eingang angelegt, Ich erhalte laut UDP Monitor Daten mit denen ich im Rohzustand nichts anfangen kann.
- einen Baustein namens "Programm" angelegt und dein Script ModbusSnifferInverter_c eingefügt.
- im Ergebnis sehe ich aber nirgendwo was.... ?!

Ich denke hier fehlt mir noch irgendwas.... (neben programmierverständnis ;-)

Kannst Du mir hier nochmal auf die Sprünge helfen?
Vielen Dank !

[Jan W.]

Ich denke hier fehlt mir noch irgendwas..

Ich hatte die Lösung von Bernhard373 so verstanden, dass der Waveshare Modbus Adapter die Modbus RTU Kommunikation zwischen EMMA (oder SDONGLE) nur mitsnifft, d.h. keine eigenen Modbus Befehle für eine Abfrage sendet, sondern diese nur mitliest und per UDP an den MS sendet. Über diese Methode kann man aber keine eigenen Abfragen zum WR senden oder Konfigurationen anpassen. Letzteres benötige ich z.B. zur Steuerung des Ladevorgangs beim E-Auto, damit dieses beim "Normalladen" in der sonnenarmen Jahreszeit nicht aus dem Speicher läd.

Wenn Du dein SDongle wg. der Kommunikation zur Huawei Cloud entfernen möchtest und keine EMMA hast, welche Kommunikation möchtest Du dann mitlesen? Wenn Du den Waveshare Modbus Adapter alternativ zum SDONGLE (bzw. EMMA) verwenden möchtest, dann muss der Waveshare Adapter eine Modbus TCP Abfrage vom MS in Modbus RTU umwandeln. Die Register sind die gleichen, die Huawei für den Inverter veröffentlicht hat und die Geschwindigkeit muss wahrscheinlich auf 9600 Baud begrenzt sein, wenn ein DTSU0066 verwendet wird, der nur diese Geschwindigkeit kann.

Bisher frage ich meine Daten via Modbus TCP vom SDongle ab. Möchte die Cloud aber los werden. Ohne Internet bootet der dongle jedoch alle 1-2Minuten und zerhaut mir meine Modbus TCP Abfragen.

Vielleicht gibt es noch andere Wege, die Kommunikation mit der Huawei Cloud zu unterbinden? Z.B. Umbiegen der DNS Namen, Konfiguration im Inverter über Installer App oder Webinterface ändern? Ich habe diese Methoden allerdings nie getestet.

Ich hatte einen Waveshare Modbus Adapter als Alternative zum SDongle kurz getestet, aber am Ende wieder alles zurückgebaut, weil ich die zusätzliche Anbindung an die Huawei Cloud für den Vergleich mit der Loxone App, als auch Software-Updates behalten wollte.

[Bernhard373]

Hallo marksa,

Wenn ich das richtig sehe, bekommst Du über den Waveshare schon Daten. Elektrisch scheint es also zu passen. Zumindest für einen der zwei RS485 Busse.

Damit das Sniffer-Programm funktioniert, musst Du den Virtuellen Eingang deaktivieren. Sonst bekommt das Sniffer-Programm keinen Zugriff auf den Port.

Jan W. liegt richtig. Über diese Lösung kann man keine Befehle an die Wechselrichter schicken. Das ist m.E. auch nicht nötig. Du bekommst eigentlich alle Werte, die man z.B. für eine Lastregelung braucht. Die Werte werden auch oft genug aktualisiert.

Ich habe damit eine Laderegelung für die Loxone Wallbox implementiert. Fürs Überschussladen brauchst Du dazu nur die aktuelle Einspeisung, die Leistung zu / von der Batterie und den aktuellen Wert der Wallbox. Dann kann man die Wallbox immer so nachjustieren, dass sie immer den überschüssigen Strom benutzt.

Ich habe bei meiner Regelung auch noch den SOC der Hausbatterie mit einbezogen, damit sie zu den Abendstunden voll ist, auch wenn das Auto lädt. Da kann man sich ganz schön spielen...

[Bernhard373]

Hier nochmal die aktuellen C-Files

[marksa]

Ich habe den virtuellen UDP nun gelöscht und nur den Programmbaustein wechselweise mit deinen Skripten getestet (natürlich vorher den Port jeweils angepasst).

Im PicoC Skript selber verstehe ich das die Werte nun auf Txt1-3, bzw O1-6 anliegen sollten.
Bei mir bleibt aber leider alles leer, keinerlei Ergebniss :-(

Hast Du eine Idee an was das liegen könnte, bzw wie ich da analytisch tätig werden kann?
Auch der outputtext "Unable to open the UDP stream." kommt nicht.



Zum restlichen Thema: Ich benötige tatsache nur wenige Werte (SoC, DC Power, Smartmeter Active Power, All time accumulated energy yield....) lesend. Ich muss nichts zurücksenden. Ich habe eine Keba Wallbox, welcher ich mittels ModbusTCP das Überschussladen in perfektion in 3 verschiedenen Betriebsmodis (Priorisierung Akku...) beigebracht habe ;-)

[Jan W.]

Hast Du eine Idee an was das liegen könnte, bzw wie ich da analytisch tätig werden kann?

Das Troubleshooting für Pico-C ist sehr dürftig. Man kann bestimmte Werte in ein Log via "printf" schreiben. Da dies die SD-Karte belastet, sollte man dafür ein "Define" verwenden, so dass man die ganzen Log-Einträge schnell abschalten kann, wenn es läuft. Ich hatte zusätzlich noch ein Maximalwert definiert. Ein Beispiel für so ein Logging findest Du hier.

Zusätzlich solltest Du noch den Ausgang "Etxt" (Error Text) mit einem Statusbaustein verbinden. Wenn dort etwas anderes als "Running" ausgegeben wird, hast Du einen Syntaxfehler in Deinem Programm. Die "while" Schleife muss endlos laufen, aber das sollte ja der Fall sein.

Funktioniert Dein Setup denn jetzt ohne den SDongle?

[Bernhard373]

Hallo marksa,

Zum Testen würde ich den "Live view" von Loxone einschalten und im Skript Aufrufe zum Debuggen verteilen. Z.B. den output text setzen oder einfach noch einen zusätzlichen Output mit einer Nummer setzen. Damit siehst Du sehr einfach, ob das Skript überhaupt läuft und was es tut - bzw. nicht tut.

Für welchen Bus (den zwischen den Invertern oder den für die Batterie) testest Du gerade?

Welche Modbus-Adressen haben denn Deine Inverter? Von dem was Du gepostet hast, gehe ich on 0x01 und 0x02 aus. Das Skript geht von drei Invertern aus: Master hat Adresse 0x01, Slave 1 0x10 (16) und Slave 2 0x11 (17). Wenn es nur zwei Inverter gibt, sollte das Skript genauso laufen - natürlich ohne die Werte für den dritten Inverter auszugeben. Die Modbus Adressen musst Du im Skript anpassen.

Gleiches gilt für das Skript für die Batterie und den Strommesser. Welche Adresse haben die? Wenn ich mich nicht täusche, geht das Skript von 0x05 für die Batterie und 0x0b für den DTSU666 aus.

Wie schon erwähnt benutzt Huawei leider keine Standard Modbus Befehle. Und ich konnte auch keine Doku finden, was sie machen. Das Skript sucht nach dem Pattern der für meine Anlage passt. Es kann natürlich sein, dass Deine Pattern etwas anders sind - weil Du 2 anstelle von 3 Inverter hast und weil die Adressen nicht identisch sind.

[Bernhard373]

Hier noch ein bisschen mehr zur Kommunikation:

Der Dongle schickt einen Befehl an den jeweiligen Inverter, um mehrere Register auf einmal auszulesen. Das macht er vielleicht aus Effizenzgründen. Wie gesagt, ist das leider undokumentiert. Ich habe solange gesucht, bis ich den Befehl, der die richtigen Register enthält gefunden hatte.

Das Sniffer-Programm horcht am Bus. Und wenn es den Befehl erkennt zum Lesen dieser Register, wertet es die Antwort dazu aus.

Soweit ich den Traffic verstanden habe, ist das folgende der Behehl zum Auslesen mehrerer Register auf einmal:

0x01 <address of device>
0x41 0x033 <function code: read multiple registers>
0x23 number of bytes to follow (including check sum)
next two bytes are unknown
2 bytes: first register
1 byte: number of register values to read
2 bytes: second register
1 byte: number of register values to read
...
checksum

Die Antwort ist ähnlich aufgebaut - da müsste ich aber nochmal genau schauen.

(
Für wens interessiert: Wenn man den Waveshare auf TCP-Server umstellt kann man den Traffic mit dem Befehl
"c:\Program Files (x86)\Nmap\ncat.exe" 192.168.1.202 4196 > data.txt
In Windows in eine Datei umleiten und dann in Ruhe analysieren. Z.B. auch das Pico-C Skript unter Windows laufen lassen und anpassen.
Natürlich ncat.exe installieren und IP-Adressen / port anpassen.
)