modbus tcp register und ID problem

[MiRoGa-NV]

Hallo,

wir haben heute versucht mit meinem Speicherhertseller herauszufinden auf welchem Register die PV-Leistung Total für meine 4 WR von Hoymiles (HM-1500 4T) abgeholt wird. Es scheint Adresse 40192 zu sein. Meine beiden Speicher sind von Sax Heimspeicher. Ich möchte die PV_Leistung gesamt auf der Web-App, sowie auf dem E-Paper Display sehen.

Folgendes haben wir heute eingestellt:

Versucht haben wir:
Erhöhung des Scale Faktors auf 100, kein Erfolg, aber 0W Anzeige auf dem Display
alte Gateway Software SAX mit 2Byte Länge, kein Erfolg, aber 0W Anzeige auf dem Display
Gateway Update SAX, 2 Byte Länge statt 4 Byte, gar keine W Anzeige mehr auf dem Display
Versucht über Stammregister SM Power und Einbindung aller P Inverter, kein Erfolg, aber 0W Anzeige auf dem Display

Das alles über TCP Protokoll!

Punkte die noch offen sind:
DTU evtl. auf eigene Scale-Faktor Registeradresse prüfen und evtl. eintragen und versuchen
evtl. vergibt die eigene DTU eine eigene Unit ID anstelle von 125.

OpenDTU wird von einem Modbus-Server erweitert. #1893
Der Modbus-Server bedient TCP an Port 502.
Bei Modbus ID 1 ahmt der Server die Modbus-Register im ursprünglichen DTUPro nach.
Bei Modbus ID 125 bedient der Server einen SunSpec-kompatiblen "Total Inverter", der
stellt die aggregierten OpenDTU-Daten aller registrierten Wechselrichter zur Verfügung.
Bei Modbus ID 243 bedient der Server ein SunSpec-Messgerät, das Wechselstrom und Wechselstromausbeute liefert, als würde er alle registrierten Wechselrichter messen. Derselbe Ansatz wie beim "Gesamtwechselrichter", aber jetzt als Zähler verkleidet.

Kann hier jemand helfen, das Problem zu lösen?

[b0661]

Hallo @MiRoGa-NV ,

das Image aus dem pull request #1893 liefert an Adresse 40192 einen float32 Wert (SunSpec Model 113 - Inverter (Three Phase) FLOAT Model).

Ich könnte mir diese Probleme vorstellen:

1. Die Heimspeicher-SW erwartet einen int32 Wert. Sieht von den Einstellungen her so aus.
2. Keine Verbindung der Heimspeicher-SW zum OpenDTU Modbus Port - Modbus ist nicht aktiviert. Darauf könnte die 0W Anzeige hindeuten.
3. Keine Verbindung der Heimspeicher-SW zum OpenDTU Modbus Port - die OpenDTU ist mit dem "Standard"-Image geflashed. Darauf könnte die 0W Anzeige hindeuten.
4. Keine Verbindung der Heimspeicher-SW zur OpenDTU - Netzwerkprobleme. Darauf könnte die 0W Anzeige auch hindeuten.

Lösungen:

1. In der Heimspeicher-SW die Abfrage des Wertes auf float32 setzen. Falls dies nicht möglich ist müsste ich die Modbus-SW um das entsprechende SunSpec INT Model erweitern. Sollte relativ einfach möglich sein.
2. Modbus unter Einstellungen aktivieren
3. Das Image aus dem pull request Add Modbus #1893 bauen und flashen.
4. Evtl. Heimspeicher-Fehlermeldungen prüfen.

Bobby

[MiRoGa-NV]

Welche der x.bin muss ich flashen, es stehen mehrere zur Verfügung. Und was ist der Unterschied.

und kann ich dann zur meiner alten Version zurückspringen, wenn es nicht funktioniert?

Michael

[b0661]

firmware.bin

[MiRoGa-NV]

wie kann ich jetzt prüfen ob ich die richtigen Einstellungen habe.
DTU ist ist mit neuer Firmware geflasht.

[b0661]

Unter Einstellungen Modbus aktivieren. Unter Info kannst Du die Einstellungen prüfen. Nach dem Aktivieren sollten die Daten per Modbus verfügbar sein

[MiRoGa-NV]

Ich habe keine sichtbaren Einstellungen zur Modbus Aktivierung.

jedoch beim nochmaligen Kompilieren folgenden Fehler/Warnung: Ist mir gestern nicht aufgefallen, erst heute Morgen.

[b0661]

Hallo Michael,

Du hast anscheinend nicht das Image zum Pull request erzeugt.

Das sollte sichtbar sein:

Hier ist ein Image für generic_esp32:
firmware.bin.gz

Vor dem flashen musst Du das Image noch entpacken:

  gunzip firmware.bin.gz

Falls Dir die Verwendung des Images zu risikoreich ist musst Du den Pull Request von github abholen (siehe https://docs.github.com/de/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally).

  cd .../OpenDTU
  git fetch origin pull/1893/head:pr_modbus
  git switch pr_modbus

Anschließend wie gehabt bauen und flashen.

VG Bobby

[b0661]

Addressfehler werden nur als Warnungen betrachtet und die sind momentan im Image nicht aktiviert. Ich schau dass ich ein entsprechendes Image baue.

[b0661]

Hier ist ein generic_esp32 Image in dem das Logging für Modbus Warnungen und Fehler eingeschalten ist. Vielleicht gib es da ja mehr informationen.
firmware.debug.bin.gz

[b0661]

Edit:
Die Adresse 40192 wie sie hier #1893 angegeben wird ist eine Adresse für die Home Assistant Modbus Integration. Sie ist absolut zu lesen - enthält also nicht den oft in der Dokumentation verwendeten Holding Register Offset von 40001.

Die Anfrage sollte so aussehen:

Erzeugt mit https://npulse.net/en/online-modbus.

[MiRoGa-NV]

das wird angefragt: 7D 03 00 BF 00 02

und das erhalte ich zurück 7D 83 02

wenn ich das richtig sehe, wird bei dir ein CRC Wert (FE:13) übermittelt, dieser fehlt bei mir.

[b0661]

Hallo,

mir war die Adressangabe für Home Assistant Modbus selbst nicht mehr ganz klar. In #2134 (reply in thread) habe ich das jetzt korrigiert.

Du solltest also einfach die Adresse 40192 verwenden (und nicht 40001 abziehen).

VG Bobby

[astrakaro]

Hallo, ich komme mit dem Pull Request auch nicht klar und benötige die Firmware für die Freischaltung der Modbus Funktionalität.
Könnte mir hier jemand weiterhelfen?

Vielen Dank :)

[b0661]

In #1893 ist beschrieben wie man sich die Firmware selber bauen kann. Hier #2134 (comment) ist ein Firmware-Image für generic_esp32.

[astrakaro]

Danke für die schnelle Antwort. Doch leider funktioniert es bei nur mit der generic firmware ohne esp32
So sieht es nach dem Firmwareupdate in der Übersicht aus :

Hier ist auch alles unkonfiguriert:

[b0661]

Die Konfiguration der Funk-Chips hat Nichts mit Modbus zu tun. Vorgehen hier entsprechend OpenDTU Dokumentation.

Hier ein Image für generic:
firmware.bin.gz

[astrakaro]

Vielen Dank!