Goodwe fhempy Sems Portal

[eLoP]

Hallo,

ich habe einen Goodwe 25k ET und möchte die daten ins fhem oder iobroker implementieren. ich habe mir auch das LAN Interface extra gekauft für eine stabile Verbindung.
Ich habe es über fhempy realisiert und bekomme auch alle daten rein. Allerdings unterbricht es dann die aufzeichnung in der Handy app Semsportal, somit geht dann die Statistik flöten.

ich habe es auch über iobroker versucht nur da leider genau das gleiche.

Gibt es irgendeine möglichkeit beides zu haben ?
Über fhem 7 iobroker möchte ich dann natürlich bei überschuss einige dinge steuern.

[Aurel_B]

Ich habe rasch gegoogelt, eventuell geht bei deinem Wechselrichter Modbus über TCP. Schau mal, ob du mit Google weiterkommst und Modbus bei deinem WR aktivieren kannst (braucht eventuell ein Firmware Update) und gib uns dann wieder Bescheid.

[eLoP]

Leider ist Modbus eine neue Welt für mich und ich finde keine vernünftiges How To etc.
Einer Anleitung schaffe ich meist noch zu folgen aber selber etwas herauszufinden ist dann sehr schwer für mich.
Vielleicht hat das schon jemand realisiert und kann berichten ?

[Tobias]

Im einfachsten Fall funktioniert dein GoodWe schon mit meinem Projekt über Modbus.
Einfach mal zusammenstecken und testen

https://github.com/tobiasfaust/SolaxModbusGateway
Dort im Wiki gibt es auch ne Menge zu lesen

[Rampler]

Ich kann gar nicht glauben, dass noch keiner den GoodWe via ModBusAttr ausliest.
Falls doch wäre es super, wenn der oder die jenige die Definitionen hier posten würde..
Die einzige Vorraussetzung ist der kombinierte WLAN/LAN Adapter.
Siehe auch hier
Ist zwar ein Forum von iobroker, zeigt aber zumindest, das der Goodwe via MODBUS ansprechbar ist.

[Klaus.A]

Ich habe einen GoodWe WR, der mit dem WLAN/LAN Modul ausgestattet ist. Es ist die Software von GoodWe im Einsatz. Ziel ist die Anbindung an FHEM um bestimmte Funktionen zu realisieren.

Wichtig: Man muss beachten wie man mit dem GoodWe WR kommunizieren will: RS485 oder Modbus/TCP. Ich bin für Modbus/TCP, da erfordert nur eine normale LAN-Verbindung und keine zusätzlichen Basteleien. Das ist auch die Lösung, die der ioBroker-Adapter verwendet.

Die grundsätzliche Verbindung ist mit FHEM ModBusAttr sehr einfach zu definieren. Man braucht dazu nur ModBusAttr wie im FHEM Wiki beschrieben. Syntax:

Code Auswählen Erweitern

define <name> ModbusAttr <Id> <Interval> <Address:Port> <RTU|ASCII|TCP>

Beispiel (IP Adresse muss natürlich angepasst werden!):

Code Auswählen Erweitern

define myWR ModbusAttr 247 60 192.168.1.198:502 TCP

Als ID wird hier 247 verwendet (Standard lt. GoodWe), Abfrage im 60 Sekunden-Intervall, Standard-Modbus-Port 502.
Für die TCP Verbindung ist die Option "TCP" zu verwenden.

Etwas komplexer - und da bin ich noch in der Forschung - sind die Registerdefinitionen für ModbusAttr um Daten zu erhalten. Von GoodWe gibt es eine Dokumentation der Register. Soweit bin ich noch nicht, das wird auch noch etwas dauern (es gibt zur Zeit andere Prioritäten).

Gruß, Klaus

[Klaus.A]

Ergebnis weiterer Nachforschungen: So einfach ist die Sache nicht, aber es gibt neue Erkenntnisse, auch aus anderen Foren.

Modbus/TCP funktioniert definitiv NICHT per WiFi und auch NICHT mit dem WiFi/WLAN-Kit Version 1.0! Als wäre das nicht genug, ist immer noch nicht ganz klar ob/wann die größeren Wechselrichter (so auch 25KET) unterstützt werden. Da könnte ein Firmware-Update notwendig sein.

Was ich definitiv weiß:

Mit WiFi wird es niemals gehen.
Also nur per LAN.
Das WiFi/LAN-Kit 1.0 kann es nicht, wird es auch nie können.
Es ist das WiFi/LAN-Kit 2.0 erforderlich. Das habe ich nicht, höre aber dass es mit einer fehlerhaften Firmware ausgeliefert wird, die vom Support erst einen Update braucht.

In der SolarGo-App (von GoodWe) war eine Option, Modbus/TCP zu aktivieren. Das sollte dann Port 502 freischalten. Hat es aber nicht für TCP, sondern nur über eine Verbindung per UDP. Auch die SolarGo-App hat nur per UDP verbunden.
Jetzt gibt es eine neue Version der SolarGo-App (5.5.1 - 341) und da ist die Option zur Aktivierung von Modbus/TCP nicht mehr vorhanden, zumindest wenn das WiFi/LAN-Kit 1.0 installiert ist. Das ist verständlich, denn per TCP hat es nie funktioniert, nur per UDP.

Wie das FHEM-Modul verbindet ist mir noch nicht bekannt.

Es gibt auch Unklarheiten wie die Situation mit den größeren Wechselrichtern ist - ob da Modbus/TCP mit WiFi/LAN-Kit 2.0 schon möglich ist oder ob man noch auf einen Firmware-Update warten muss. (Ich habe nur einen kleinen WR, kann das daher nicht direkt beurteilen.)

Als Alternative bleibt nur die Verbindung über RS485. Dann braucht man für eine LAN-Verbindung einen zusätzlichen Adapter/Konverter, z.B. von "Waveshare". Da gibt es eine spezielle Version, die von RS485 auf TCP wandelt, mit "Modbus-TCP" Implementierung. Aufpassen, nur "TCP" genügt nicht, der Adapter mur "Modbus/TCP" können!

Das Problem der Alternative ist allerdings, dass man ein dediziertes LAN-Kabel zum Router (oder Switch) braucht. Wenn der Wechselrichter bereits per LAN angeschlossen ist, dann wäre das ein zweites LAN-Kabel. Da bin ich raus, ein weiteres Kabel verlege ich nicht. Das muss alles über eine einzige LAN-Kabelverbindung gehen - also WiFi-LAN-Kit 2.0, das kann Bluetooth, WiFi und LAN inklusive Modbus/TCP, alles in einem Adapter.

Soviel zu den aktuellen Erkenntnissen. Ob bzw. wann ich bei mir umbaue weiß ich noch nicht. Zur Zeit habe ich keine direkte Anwendung, das Auslesen der Daten wäre ein "nicht-to-have", aber keine essentielle Funktion. Das wird anders wenn ich eine intelligente Steuerung benötigt, die eine "Überschussnutzung" realisieren muss. Damit meine ich eine Situation, in der eine Steuerung den echten Überschuss - normalerweise ins Netz eingespeist - erkennt und diesen (und wirklich nur diesen) für andere Komponenten nutzt. So etwas gibt es als teuren Zusatz - im Internet zu finden unter der Bezeichnung "Thor". Da stellt sich schnell die Frage nach der Wirtschaftlichkeit: Kann die Anlage so viel Überschuss erzeugen und ist dieser nutzbar dass die Investitionskosten über die Nutzungsdauer sich rechnen?

Gruß, Klaus

[Parallix]

Hallo,

ich habe einen Goodwe 25k ET und möchte die daten ins fhem oder iobroker implementieren. ich habe mir auch das LAN Interface extra gekauft für eine stabile Verbindung.
Ich habe es über fhempy realisiert und bekomme auch alle daten rein. Allerdings unterbricht es dann die aufzeichnung in der Handy app Semsportal, somit geht dann die Statistik flöten.

ich habe es auch über iobroker versucht nur da leider genau das gleiche.

Gibt es irgendeine möglichkeit beides zu haben ?
Über fhem 7 iobroker möchte ich dann natürlich bei überschuss einige dinge steuern.

Hatte anfangs das gleiche Problem, wenn ich in FHEM das Inverter-Attribut "interval", (Zeit zwischen zwei Abfragen) permanent auf einem zu kleinen Wert (<< 300s) belasse. Da ich aber vom WR häufiger und deutlich weniger verzögert Daten bekommen möchte, als dies mit SEMS möglich ist, ist dies natürlich wenig sinnvoll.

Lösung:
Setze das Attribut z.B. alle 12h für eine kurze Dauer auf einen SEMS-freundlichen Wert (bei mir klappt's mit 180s), um dem WR in diesem Zeitraum ein Export seiner gespeicherten Daten nach SEMS zu ermöglichen. In der restlichen Zeit belasse den Wert auf 10s.

PS: Lieber würde ich anstelle fhempy lieber ModbusAttr nutzen. Letzteres bekomme ich unter Nutzung einer Bridge (z.B. einer reinen Software-Lösung mittels https://github.com/thgau/goodwe_modbus) auch hin. Da (ohne Patches) mittels der o.g. Software-Bridge und auch via fhempy derzeit nur ein lesender Zugriff auf (ausgewählte) Readings möglich ist, gefallen mir beide Lösungen nicht wirklich. Hinzu kommt, dass beide Lösungen zu viele externe Komponenten (außerhalb von FHEM) verwenden. Vielleicht kommt ja irgendwann mal ein schönes FHEM-Modul zur Anbindung von Modbus via UDP oder gar eine Erweiterung von ModbusAttr das auch eine Nutzung von UDP ermöglicht.

[Prof. Dr. Peter Henning]

Da bin ich raus, ein weiteres Kabel verlege ich nicht. Das muss alles über eine einzige LAN-Kabelverbindung gehen - also WiFi-LAN-Kit 2.0, das kann Bluetooth, WiFi und LAN inklusive Modbus/TCP, alles in einem Adapter.

Kleiner Tipp: Für eine Verbindung mit 100 MBit/s (und da liegt kein WR drüber) reichen 4 Adern aus. Das bedeutet, dass man ein bereits verlegtes Kabel aufsplitten und damit 2 Geräte versorgen kann. Adapter gibt es für wenig Geld, z.B. https://www.ebay.de/itm/354564160824

Ein Bekannter hat sich auch gerade für einen der billigen GoodWe-Wechselrichter entschieden (das war in einem Paketpreis mit drin). Insofern werde ich hier mal mitlesen, denn früher oder später kommt er und will die Daten haben.

LG

pah

[Parallix]

Um den ETT-Hybridwechselrichten, z.B. dem ET25K-ET, über das alte LAN/Wifi-Interface Daten zu entlocken, muss derzeit noch auf UDP zurückgeriffen werden. Das geht inzwischen auch via fhempy, zumindest dann, wenn man beim Connect neben der IP-Adresse auch noch den UDP-Port (hier: goodwe.const.GOODWE_UDP_PORT) angibt. Trotz eines mit 10s relativ  geringen zeitlicher Abstands zwischen zwei Connects, kommt es bei mir relativ selten zu Problemen. Ein zeitlich relativ gut aufgelöste Darstellung diverser Wechselrichtergrößen ist somit möglich!

Leider führt eine nicht optimale Fehlerbehandlung im fhempy-Code gelegentlich dazu, dass die fhempy-Prozesse in einen Zustand verfallen, aus denen diese kurzfristig nur per manuellem Restart wieder herausgeholt werden können. Nun interessiert mich, ob andere ähnliches beobachtet haben und bitte um ein entsprechendes Feedback.

Hier auch noch ein Auszug aus dem Log:

Code Auswählen Erweitern

Activating virtual environment...OK
2024-09-30 10:01:20,465 - INFO     - fhempy.lib.fhem_pythonbinding: Starting fhempy 0.1.742...
2024-09-30 10:01:20,469 - INFO     - fhempy.lib.fhem_pythonbinding: Waiting for FHEM connection
2024-09-30 10:01:20,618 - INFO     - websockets.server: server listening on 0.0.0.0:15733
2024-09-30 10:01:22,077 - INFO     - websockets.server: connection open
2024-09-30 10:01:22,079 - INFO     - fhempy.lib.fhem_pythonbinding: Incoming FHEM connection: 127.0.0.1
2024-09-30 10:22:33,872 - ERROR    - asyncio: Exception in callback _SelectorDatagramTransport._read_ready()
handle: <Handle _SelectorDatagramTransport._read_ready()>
Traceback (most recent call last):
  File "/usr/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/lib/python3.12/asyncio/selector_events.py", line 1248, in _read_ready
    self._protocol.datagram_received(data, addr)
  File "/opt/fhem/.fhempy/fhempy_venv/lib/python3.12/site-packages/goodwe/protocol.py", line 113, in datagram_received
    self.response_future.set_result(data)
asyncio.exceptions.InvalidStateError: invalid state