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


[Ckaytwo]

Hi,
Ich suche auch schon länger ohne eine für mich verständliche Lösung.

Mein Ansatz war nun für 30€ einen fertigen ir-Lesekopf auf den stromzähler zu setzen.
Zwar habe ich dann die erzeugte PV Leistung nicht in Fhem, aber die tatsächliche Last/Einspeisemenge vom Zähler. Damit kann ich jetzt wunderbar schalten und walten.

Von Shelly gibt's auch für 70€ ein 3Phasigen Energiezähler, mit dem man die PV Leistung noch abgreifen könnte.


Viel Erfolg weiterhin.

Grüße
Christian

[maci]

Hallo,

Habe auch einen Goodwe Hybrid Wechselrichter.
Die Verbindung per ModbusAttr über TCP klappt.
Aber dann weiß ich nicht mehr weiter. Da ich nicht weiß welches Attribut ich wählen muss, damit ich Werte auslesen kann.
Die Beschreibung Goodwe-Register versuche ich zu verstehen, kann aber keine Verbindung zu den fhem Registern herstellen.
Vielleicht kann mir jemand auf die Sprünge helfen, wie und was ich da nehmen muss.
Evtl. hat es schon jemand gemacht.

[Parallix]

Hallo,

Habe auch einen Goodwe Hybrid Wechselrichter.
Die Verbindung per ModbusAttr über TCP klappt.
...

Wenn Du (z.B. durch Angabe in Deiner Signatur) verrätst, welchen Goodwe Du genau hast, dann sind viele weitere Dinge wahrscheinlich einfacher zu beantworten.

[maci]

Es ist ein GW8KN-ET HybridWechselrichter

[Parallix]

Es ist ein GW8KN-ET HybridWechselrichter

Die Modbus-Daten-Objekte, auf die Du lesend zugreifen kannst, sind in FHEM wie folgt bezeichnet:

Code Auswählen Erweitern

obj-[cdih][0-9]+-reading
Willst Du beispielsweise auf das Register 35105, in dem die gegenwärtige Leistung Deines MPPT1-Strings abgelegt ist, nutzen, so verwendest Du obj-h35105-reading.

Zum Auslesen musst Du es vorher via

Code Auswählen Erweitern

attr <inverter> <object> <reading>als FHEM-Reading verfügbar machen, was Du z.B. via

Code Auswählen Erweitern

attr GW8K obj-h35105-reading pv-p-mppt1erledigen kannst

[Prof. Dr. Peter Henning]

z.B. durch Angabe in Deiner Signatur

Pardon, aber solche Aufforderungen sollten wir bitte vermeiden.

LG

pah

[maci]

Habe mal versucht ein Fhem Reading anzulegen.
Wenn ich es versuche mit

Code Auswählen Erweitern

attr obj-[cdih][0-9]+-reading h35105 bekomme ich eine Fehlermeldung mit unerlaubten Zeichen
Das gleich beim Versuch

Code Auswählen Erweitern

obj-h35105-reading.

Habe es nun mal direkt eingegeben:

Code Auswählen Erweitern

attr Goodwe obj-h35105-reading pv-p-mppt1
Reading bekomme ich keines.

Habe für Logausgaben verbose 5 eingeben.

Im Log steht:

Code Auswählen Erweitern

2024.11.09 10:07:07.253 3: 10.0.0.209:502 disconnected, waiting to reappear (Goodwe)
2024.11.09 10:07:07.274 5: HttpUtils url=http://10.0.0.209:502/ NonBlocking via http
2024.11.09 10:07:07.275 4: IP: 10.0.0.209 -> 10.0.0.209
2024.11.09 10:07:07.281 3: 10.0.0.209:502 reappeared (Goodwe)
2024.11.09 10:07:07.290 4: Goodwe: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 8.4 sec at 10:07:15.680, interval 60
2024.11.09 10:07:15.681 4: Goodwe: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.11.09 10:07:15.682 4: Goodwe: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 60.0 sec at 10:08:15.681, interval 60
2024.11.09 10:07:15.683 5: Goodwe: CreateUpdateHash full object list: h35105
2024.11.09 10:07:15.684 4: Goodwe: CombineUpdateHash objHash keys before combine:
2024.11.09 10:07:15.684 5: Goodwe: CombineUpdateHash tries to combine read commands
2024.11.09 10:07:15.684 5: Goodwe: CombineUpdateHash keys are now
2024.11.09 10:07:15.684 4: Goodwe: GetUpdate will now create requests for
2024.11.09 10:07:20.221 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 251362516) line 1.

[maci]

Habe mich etwas durch die fhem-Referenz zum Thema ModbusAttr gelesen.
Habe daher meine 2 Strings mal wie folgt angelegt

Code Auswählen Erweitern

attr Goodwe obj-h35105-format %.2f
attr Goodwe obj-h35105-len 2
attr Goodwe obj-h35105-poll 1
attr Goodwe obj-h35105-reading PV1-Power
attr Goodwe obj-h35105-unpack n
attr Goodwe obj-h35109-format %.2f
attr Goodwe obj-h35109-len 2
attr Goodwe obj-h35109-poll 1
attr Goodwe obj-h35109-reading PV2-Power
attr Goodwe obj-h35109-unpack n
Ich bekomme jetzt regelmäßig Readings, aber die Ausgaben sind 0.00.
In der Weboberfläche habe ich aber Werte.

Also muss irgendetwas noch nicht passen.

Hier noch die Log Ausgabe mit verbose 5

Code Auswählen Erweitern

2024.11.09 10:51:28.730 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 251431548) line 1.
2024.11.09 10:52:16.731 4: Goodwe: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.11.09 10:52:16.732 4: Goodwe: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 60.0 sec at 10:53:16.732, interval 60
2024.11.09 10:52:16.735 5: Goodwe: CreateUpdateHash full object list: h35105 h35109
2024.11.09 10:52:16.736 5: Goodwe: CreateUpdateHash will request h35105 len 2 PV1-Power
2024.11.09 10:52:16.736 5: Goodwe: CreateUpdateHash will request h35109 len 2 PV2-Power
2024.11.09 10:52:16.737 4: Goodwe: CombineUpdateHash objHash keys before combine: h35109,h35105
2024.11.09 10:52:16.737 5: Goodwe: CombineUpdateHash tries to combine read commands
2024.11.09 10:52:16.737 5: Goodwe: CombineUpdateHash keys are now h35109,h35105
2024.11.09 10:52:16.738 4: Goodwe: GetUpdate will now create requests for h35105 len 2 (PV1-Power), h35109 len 2 (PV2-Power)
2024.11.09 10:52:16.740 4: Goodwe: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 247, read fc 3 h35105, len 2, tid 200, master device Goodwe, reading PV1-Power (getUpdate for PV1-Power len 2)
2024.11.09 10:52:16.740 5: Goodwe: QueueRequest called from DoRequest with h35105, qlen 0 from master Goodwe through io device Goodwe
2024.11.09 10:52:16.740 5: Goodwe: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2024.11.09 10:52:16.742 4: Goodwe: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 247, read fc 3 h35109, len 2, tid 157, master device Goodwe, reading PV2-Power (getUpdate for PV2-Power len 2)
2024.11.09 10:52:16.742 5: Goodwe: QueueRequest called from DoRequest with h35109, qlen 1 from master Goodwe through io device Goodwe
2024.11.09 10:52:16.743 5: Goodwe: ProcessRequestQueue called from Fhem internal timer as queue:Goodwe, qlen 2, request: request: id 247, read fc 3 h35105, len 2, tid 200, master device Goodwe, reading PV1-Power (getUpdate for PV1-Power len 2), queued 0.00 secs ago
2024.11.09 10:52:16.744 5: Goodwe: checkDelays commDelay, last communication with same device was 59.755 secs ago, required delay is 0.1
2024.11.09 10:52:16.744 5: Goodwe: checkDelays sendDelay, last send to same device was 59.815 secs ago, required delay is 0.1
2024.11.09 10:52:16.744 5: Goodwe: checkDelays busDelayRead is not required
2024.11.09 10:52:16.744 5: Goodwe: checkDelays clientSwitchDelay is not relevant
2024.11.09 10:52:16.745 4: Goodwe: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 2, sending 00c800000006f70389210002 via 10.0.0.209:502, read buffer empty,
request: id 247, read fc 3 h35105, len 2, tid 200, master device Goodwe, reading PV1-Power (getUpdate for PV1-Power len 2), queued 0.01 secs ago
2024.11.09 10:52:16.745 5: Goodwe: Send called from ProcessRequestQueue
2024.11.09 10:52:16.746 5: DevIo_SimpleWrite Goodwe: 00c800000006f70389210002
2024.11.09 10:52:16.747 5: Goodwe: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2024.11.09 10:52:16.836 5: Goodwe: readFn buffer: 00c800000007f703040000003a mode master, expect response
2024.11.09 10:52:16.837 5: Goodwe: ParseFrameStart called from ReadFn protocol TCP expecting id 247
2024.11.09 10:52:16.837 4: Goodwe: ParseFrameStart (TCP, master) extracted id 247, fCode 3, tid 200, dlen 7 and potential data 040000003a
2024.11.09 10:52:16.837 5: Goodwe: HandleResponse called from ReadFn
2024.11.09 10:52:16.837 5: Goodwe: HandleResponse is now creating response hash, masterHash is HASH(0x55b8dfe92770)
2024.11.09 10:52:16.837 5: Goodwe: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55b8dfe92770)
2024.11.09 10:52:16.838 5: Goodwe: ParseResponse called from HandleResponse, fc 3
2024.11.09 10:52:16.838 5: Goodwe: now parsing response data objects, master is Goodwe relay is undefined
2024.11.09 10:52:16.838 5: Goodwe: ParseDataString called from HandleResponse with data hex 0000003a, type h, adr 35105, op read
2024.11.09 10:52:16.838 5: Goodwe: SplitDataString called from ParseDataString with data hex 0000003a, type h, adr 35105, valuesLen 2, op read
2024.11.09 10:52:16.838 5: Goodwe: CreateDataObjects called from ParseDataString with objList h35105
2024.11.09 10:52:16.839 5: Goodwe: CreateDataObjects sortedList h35105
2024.11.09 10:52:16.839 5: Goodwe: CreateParseInfoCache called
2024.11.09 10:52:16.839 5: Goodwe: CreateDataObjects unpacked 0000003a with n to 0
2024.11.09 10:52:16.840 5: Goodwe: FormatVal for CreateDataObjects formats 0 with format %.2f, result is 0.00
2024.11.09 10:52:16.840 4: Goodwe: CreateDataObjects assigns value 0.00 to PV1-Power
2024.11.09 10:52:16.847 5: Goodwe: ParseDataString created 1 readings, errcode undef
2024.11.09 10:52:16.848 4: Goodwe: HandleResponse done, current frame / read buffer: 00c800000007f703040000003a, id 247, fCode 3, tid 200,
request: id 247, read fc 3 h35105, len 2, tid 200, master device Goodwe, reading PV1-Power (getUpdate for PV1-Power len 2), queued 0.11 secs ago, sent 0.10 secs ago,
response: id 247, fc 3, h35105, len 2, values 0000003a
2024.11.09 10:52:16.848 5: Goodwe: ResetExpect for HandleResponse from response to idle
2024.11.09 10:52:16.849 5: Goodwe: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2024.11.09 10:52:16.850 5: Goodwe: DropFrame called from ReadFn - drop 00c800000007f703040000003a
2024.11.09 10:52:16.850 5: Goodwe: readFn end buffer:  mode master, expect idle
2024.11.09 10:52:16.851 5: Goodwe: ProcessRequestQueue called from Fhem internal timer as queue:Goodwe, qlen 1, request: request: id 247, read fc 3 h35109, len 2, tid 157, master device Goodwe, reading PV2-Power (getUpdate for PV2-Power len 2), queued 0.11 secs ago
2024.11.09 10:52:16.851 5: Goodwe: checkDelays busDelayRead is not required
2024.11.09 10:52:16.851 5: Goodwe: checkDelays commDelay, last communication with same device was 0.014 secs ago, required delay is 0.1
2024.11.09 10:52:16.851 5: Goodwe: checkDelays sendDelay, last send to same device was 0.104 secs ago, required delay is 0.1
2024.11.09 10:52:16.851 5: Goodwe: checkDelays clientSwitchDelay is not relevant
2024.11.09 10:52:16.851 4: Goodwe: checkDelays found commDelay not over, set timer to try again in 0.086
2024.11.09 10:52:16.940 5: Goodwe: ProcessRequestQueue called from Fhem internal timer as queue:Goodwe, qlen 1, request: request: id 247, read fc 3 h35109, len 2, tid 157, master device Goodwe, reading PV2-Power (getUpdate for PV2-Power len 2), queued 0.20 secs ago
2024.11.09 10:52:16.941 5: Goodwe: checkDelays clientSwitchDelay is not relevant
2024.11.09 10:52:16.941 5: Goodwe: checkDelays sendDelay, last send to same device was 0.194 secs ago, required delay is 0.1
2024.11.09 10:52:16.941 5: Goodwe: checkDelays commDelay, last communication with same device was 0.103 secs ago, required delay is 0.1
2024.11.09 10:52:16.942 5: Goodwe: checkDelays busDelayRead is not required
2024.11.09 10:52:16.943 4: Goodwe: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 009d00000006f70389250002 via 10.0.0.209:502, read buffer empty,
request: id 247, read fc 3 h35109, len 2, tid 157, master device Goodwe, reading PV2-Power (getUpdate for PV2-Power len 2), queued 0.20 secs ago
2024.11.09 10:52:16.943 5: Goodwe: Send called from ProcessRequestQueue
2024.11.09 10:52:16.944 5: DevIo_SimpleWrite Goodwe: 009d00000006f70389250002
2024.11.09 10:52:17.009 5: Goodwe: readFn buffer: 009d00000007f70304000001bd mode master, expect response
2024.11.09 10:52:17.009 5: Goodwe: ParseFrameStart called from ReadFn protocol TCP expecting id 247
2024.11.09 10:52:17.010 4: Goodwe: ParseFrameStart (TCP, master) extracted id 247, fCode 3, tid 157, dlen 7 and potential data 04000001bd
2024.11.09 10:52:17.010 5: Goodwe: HandleResponse called from ReadFn
2024.11.09 10:52:17.010 5: Goodwe: HandleResponse is now creating response hash, masterHash is HASH(0x55b8dfe92770)
2024.11.09 10:52:17.010 5: Goodwe: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55b8dfe92770)
2024.11.09 10:52:17.011 5: Goodwe: ParseResponse called from HandleResponse, fc 3
2024.11.09 10:52:17.011 5: Goodwe: now parsing response data objects, master is Goodwe relay is undefined
2024.11.09 10:52:17.011 5: Goodwe: ParseDataString called from HandleResponse with data hex 000001bd, type h, adr 35109, op read
2024.11.09 10:52:17.011 5: Goodwe: SplitDataString called from ParseDataString with data hex 000001bd, type h, adr 35109, valuesLen 2, op read
2024.11.09 10:52:17.012 5: Goodwe: CreateDataObjects called from ParseDataString with objList h35109
2024.11.09 10:52:17.012 5: Goodwe: CreateDataObjects sortedList h35109
2024.11.09 10:52:17.012 5: Goodwe: CreateParseInfoCache called
2024.11.09 10:52:17.013 5: Goodwe: CreateDataObjects unpacked 000001bd with n to 0
2024.11.09 10:52:17.013 5: Goodwe: FormatVal for CreateDataObjects formats 0 with format %.2f, result is 0.00
2024.11.09 10:52:17.013 4: Goodwe: CreateDataObjects assigns value 0.00 to PV2-Power
2024.11.09 10:52:17.024 5: Goodwe: ParseDataString created 1 readings, errcode undef
2024.11.09 10:52:17.024 4: Goodwe: HandleResponse done, current frame / read buffer: 009d00000007f70304000001bd, id 247, fCode 3, tid 157,
request: id 247, read fc 3 h35109, len 2, tid 157, master device Goodwe, reading PV2-Power (getUpdate for PV2-Power len 2), queued 0.28 secs ago, sent 0.08 secs ago,
response: id 247, fc 3, h35109, len 2, values 000001bd
2024.11.09 10:52:17.025 5: Goodwe: ResetExpect for HandleResponse from response to idle
2024.11.09 10:52:17.026 5: Goodwe: DropFrame called from ReadFn - drop 009d00000007f70304000001bd
2024.11.09 10:52:17.026 5: Goodwe: readFn end buffer:  mode master, expect idle

[Parallix]

z.B. durch Angabe in Deiner Signatur

Pardon, aber solche Aufforderungen sollten wir bitte vermeiden.

LG

pah

Wo liegt das Problem?

[maci]

Habe es nun geschafft Werte zu bekommen wenn unpack auf f ändere.

Allerdings sind das irgendwelche Fantasiewerte, denn ein Wert -8657043456.00 ist sicherlich nicht echt.

Habe es dann versucht damit dass ich die Volt und Ampere Werte je String abfrage, jedoch sind diese fast immer auf 0.00 oder -0.00
oder auch 1.07619722060146e-42
Also nicht relevant.

Derzeit ist das alles noch unbrauchbar?

Ich lese auch immer von Master und Slave Modus. Wie stelle ich diesen ein?
Hat es evtl. damit zu tun?

Gruß
Georg

[maci]

Geschafft, denke ich zumindest
Mit unpack l> bekomme ich Werte die zumindest mal plausibel sind.
Sie passen allerdings immer noch nicht ganz mit den Anzeigen im SEMS Portal zusammen.

[maci]

Hallo,

Habe nun einige Attribute definiert, die plausible Werte liefern. Mit diesen kann auch etwas anfangen

Code Auswählen Erweitern

attr Goodwe obj-h35105-reading PV1-Power
attr Goodwe obj-h35105-poll 1
attr Goodwe obj-h35105-len 2
attr Goodwe obj-h35105-format %.2f
attr Goodwe obj-h35105-unpack l>
attr Goodwe obj-h35109-reading PV2-Power
attr Goodwe obj-h35109-poll 1
attr Goodwe obj-h35109-len 2
attr Goodwe obj-h35109-format %.2f
attr Goodwe obj-h35109-unpack l>
attr Goodwe obj-h35191-reading Stromproduktion-Gesamt
attr Goodwe obj-h35191-poll 1
attr Goodwe obj-h35191-len 2
attr Goodwe obj-h35191-unpack l>
attr Goodwe obj-h35191-expr $val/10
attr Goodwe obj-h35193-reading Stromproduktion-Heute
attr Goodwe obj-h35193-poll 1
attr Goodwe obj-h35193-len 2
attr Goodwe obj-h35193-unpack l>
attr Goodwe obj-h35193-expr $val/10
attr Goodwe obj-h35206-reading BatterieLadeStromGesamt
attr Goodwe obj-h35206-poll 1
attr Goodwe obj-h35206-len 2
attr Goodwe obj-h35206-unpack l>
attr Goodwe obj-h35206-expr $val/10
attr Goodwe obj-h35209-reading EntladeEnergie
attr Goodwe obj-h35209-poll 1
attr Goodwe obj-h35209-len 2
attr Goodwe obj-h35209-unpack l>
attr Goodwe obj-h35209-expr $val/10
Den Rest wie Summieren auf Jahresenergie und Gesamtenergie mache ich über userReadings

Ich kann mit diesen Werten wieder etwas anfangen, dass ich auch meine Wallbox steuern kann

[Prof. Dr. Peter Henning]

OK, allerdings hast Du nicht Attribute definiert, sondern Readings definiert und Attribute gesetzt.

Und noch ein Tipp: Es geht bei Deinen Readingnamen ziemlich durcheinander mit Power, Strom und Energie. Das mag zwar im Moment brauchbar aussehen, aber in 2 Jahren sicher nicht mehr. Also
1. Überlegen, ob man lieber englische Readings hat: power, energy, current, voltage. Oder deutsche: Leistung, Energie, Strom, Spannung. Für die englischen spricht -> siehe unten Punkt 3.
2. Vermeiden von Fehlbenennungen. Es gibt keine "Stromproduktion-heute", Strom ist immer ein Momentanwert. Produziert als Tagessumme wird Energie.
3. Die Aufintegration von power zu energy kann man mit der userReadings-Option integral machen. Ich habe die Genauigkeit davon überprüft, ist sehr gut brauchbar. Die Aufschlüsselung auf Tages- und Monatswert idealerweise mit dem statistics-Modul. Und damit sind wir bei der Frage ob Englisch oder Deutsch. Das statistics-Modul hat nämlich Readingsnamen vordefiniert, die es entsprechend auswertet - energy, power, voltage gehören dazu.

Und noch ein Tipp: Man kann auch bei einem ModBus-Device eine komplexe Statusanzeige realisieren (siehe Bild). Dazu einfach das Attribut stateFormat mit einem Perl-Funktionsausfruf belegen, und darin die ganzen Werte aufsammeln. Und dann als HTML-Tabelle zurückgeben.

LG

pah

[maci]

Danke für die Rückmeldung.

Werde mir das nochmals etwas zu Gemüte führen

Gruß
Georg

[Parallix]

In fhempy sind, z.B. in goodwe.py, die in set_config abgelegten Defaults statisch. Nun frage ich mich, wie sich diese Defaults möglichst elegant ändern lassen, sodass sie jeweils auf dem aktuell eingestellten Wert stehen. Kann mir da jemand weiterhelfen?

[maci]

Habe meine Reading jetzt umbenannt.
Hier meine Readings, die auch entsprechend richtige Werte liefern.

Code Auswählen Erweitern

attr Goodwe obj-h35105-len 2
attr Goodwe obj-h35105-poll 1
attr Goodwe obj-h35105-reading PV1-Power
attr Goodwe obj-h35105-unpack l>
attr Goodwe obj-h35109-len 2
attr Goodwe obj-h35109-poll 1
attr Goodwe obj-h35109-reading PV2-Power
attr Goodwe obj-h35109-unpack l>
attr Goodwe obj-h35191-expr $val/10
attr Goodwe obj-h35191-len 2
attr Goodwe obj-h35191-poll 1
attr Goodwe obj-h35191-reading PV-Energy_Gesamt
attr Goodwe obj-h35191-unpack l>
attr Goodwe obj-h35193-expr $val/10
attr Goodwe obj-h35193-len 2
attr Goodwe obj-h35193-poll 1
attr Goodwe obj-h35193-reading PV-Energy_heute
attr Goodwe obj-h35193-unpack l>
attr Goodwe obj-h35206-expr $val/10
attr Goodwe obj-h35206-len 2
attr Goodwe obj-h35206-poll 1
attr Goodwe obj-h35206-reading Charge-Energy
attr Goodwe obj-h35206-unpack l>
attr Goodwe obj-h35209-expr $val/10
attr Goodwe obj-h35209-len 2
attr Goodwe obj-h35209-poll 1
attr Goodwe obj-h35209-reading Discharge-Energy
attr Goodwe obj-h35209-unpack l>
Ich wollte weiters gerne noch den Batterieladestand lesen.
Aber ich finde keine Adrr. in der Modbus Beschreibung dafür.
Das müsste der SOC Wert sein. Im Sems Portal wird er angezeigt. Aber in Modbus finde ich dazu nichts.

[Parallix]

...
Ich wollte weiters gerne noch den Batterieladestand lesen.
Aber ich finde keine Adrr. in der Modbus Beschreibung dafür.
Das müsste der SOC Wert sein. Im Sems Portal wird er angezeigt. Aber in Modbus finde ich dazu nichts.

Wenn Du den SOC nicht direkt am Speicher abholen willst, sondern am Wechselrichter, dann kommen hierfür folgende Register in Frage:

• 37007: BMS1 SOC
• 39005: BMS2 SOC

[maci]

Wenn Du den SOC nicht direkt am Speicher abholen willst, sondern am Wechselrichter, dann kommen hierfür folgende Register in Frage:

• 37007: BMS1 SOC

[/list]

Im Modbus Dokument steht bei 37007 zwar SOC als Name, bei remark: First group battery capacity

Wenn ich diesen Wert abhole kommt ein Wert von 655460.
Sollte zwar ein % Wert sein, das ist aber ganz sicher keiner.
39005 gibt es in der Doku nicht.

[maci]

Es hat mir keine Ruhe gelassen, darum habe ich heute nochmals einen Versuch gemacht, den BYD Batterie Ladestatus auszulesen.
Von der Batterie selbst kann ich es nicht lesen, da diese nicht im Netz hängt. Mein Installateur hat gesagt, die Chinesen müssen nicht alles wissen.

habe es mal mit 37007 versucht (bei 37007 steht im Goodwe Modbus Dokument "SOC  First Group battery capacity")

habe mal folgende Readings angelegt:

Code Auswählen Erweitern

attr Goodwe obj-h37007-reading Batt-SOC
attr Goodwe obj-h37007-poll 1
attr Goodwe obj-h37007-len 2
attr Goodwe obj-h37007-unpack f>
Auf die unpack f> Angabe bin ich durch Zufall gekommen, denn bei den anderen Readings habe ich unpack l>.
Wenn ich hier auch unpack l> setze bekomme ich eine Wert 655460. Das ist absolut etwas anders.

Mit unpack f> bekomme auch einen Wert der halbwegs plausibel ist, denn mein Batteriestatus beträgt derzeit ca. 10%
Im Reading steht: 9.18495091426345e-40
Ich frage mich nur was das für eine Zahl ist?
Wie soll ich diese ausgeben, wenn es ein tatsächlicher Wert ist?

[Prof. Dr. Peter Henning]

9.18495091426345e-40

= 0,000000000000000000000000000000000000000918495091426345

Also im Rahmen physikalisch erzielbarer Genauigkeit NULL.

Damit scheidet die direkte Interpretation des Registers als Gleitkommazahl aus.

Ich habe nicht die Zeit, da in der Spezifikation herumzugraben. Vlt. kannst Du das mal posten:
1. Was wird als Registerlänge angegeben? Wirklich 2?
2. Welchen Wert erhält man, wenn der Ladezustand auf einen anderen Wert erhöht wird?

LG

pah

[Parallix]

...
Von der Batterie selbst kann ich es nicht lesen, da diese nicht im Netz hängt. Mein Installateur hat gesagt, die Chinesen müssen nicht alles wissen.
...

WR und Batterien nicht zu erlauben, Daten ohne eigene Kenntnis nach Außen zu versenden, insb. aber Daten von Außen eingespielt zu bekommen, ist auch meine Devise. Gleichwohl halte ich eine Überwachung der Betriebsstati von Speicher und WR für sehr sinnvoll.

Wenn Du am BYD-Speicher kurz den runden Ein-/Aus-Taster drückst, dann hast Du 5h lang die Möglichkeit per WLAN mit deinem Speichersystem zu verbinden und zwar ohne dem Speicher damit das Tor zum Internet eröffnen zu müssen. Diese 5h sollte ausreichen, um die Daten, die Du via Modbus von Deinem WR bekommst, mit denen vom Batteriesystem zu vergleichen.

PS: Selber habe ich eine kabelgebundene und rein lokale Anbindung meines FHEM-Knotens mit Speicher und WR konfiguriert . Über die kann somit keine Verbindung Internet <-> Speicher oder Internet <-> WR aufgebaut werden.

[maci]

Ich habe nicht die Zeit, da in der Spezifikation herumzugraben. Vlt. kannst Du das mal posten:
1. Was wird als Registerlänge angegeben? Wirklich 2?
2. Welchen Wert erhält man, wenn der Ladezustand auf einen anderen Wert erhöht wird?

Hier ein Bild aus den Spezifikationen.

Du darfst diesen Dateianhang nicht ansehen.

Wenn der Wert größer wird, kommen hier Readings mit 1,0123.... e-38

Also auch gleich 0


Spiele derzeit mit dem Gedanken, den Speicher trotzdem in Netz zu hängen, aber den Zugang zum Internet in meinem Gateway zu verbieten.

Gruß Georg

[Prof. Dr. Peter Henning]

Zunächst einmal ist klar, dass für den Datentyp U16 = unsigned 16 Bit sowohl die Längenangabe 2, als auch der Unpack-Code f> falsch sind. Das führt zur fehlerhaften Darstellung als Gleitkommazahl.

Bitte mal probieren mit

Code Auswählen Erweitern

attr Goodwe obj-h37007-reading Batt-SOC
attr Goodwe obj-h37007-poll 1
attr Goodwe obj-h37007-type unsigned short big
Und wenn das keinen sinnvollen Wert im Bereich 0-100 liefert

Code Auswählen Erweitern

attr Goodwe obj-h37007-reading Batt-SOC
attr Goodwe obj-h37007-poll 1
attr Goodwe obj-h37007-type unsigned short little

LG

pah

[maci]

Danke Peter!

Danke für die Antwort.
Die erste Anregung hat bereits gepasst und jetzt steht als Ergebnis tatsächlich 10 drinnen.
Das ist genau der Wert, denn der Speicher auch lt. Weboberfläche hat.

Hier sieht man, dass ich bei ModbusAttr noch nicht wirklich durchblicke.
Einfach auch deshalb, weil ich zwischen den Beschreibungen im Wiki oder CommandRef zu den Angaben die der Gerätehersteller macht keinen Bezug herstellen kann.

Alles bisher war eher probieren und schauen was kommt.

Gruß
Georg

[Prof. Dr. Peter Henning]

Na, das ist doch ganz einfach.

In der Doku steht RO=Read-Only, sowie U16 = unsigned 16, also EIN Register a 16 Bit

Es muss also Perl nur gesagt werden, dass es sich um eine Ganzzahl in einem Register handelt.

LG

pah

[Parallix]

Kann es sein, dass im Code goodwe.py in der update_loop() in

Code Auswählen Erweitern

await fhem.readingsSingleUpdate(self.hash, "operation_mode", self.get_enum_name(operation_mode))das letzte Argument (do_trigger) fehlt und daher "state" immer auf "error" gesetzt wird? Nach meiner Ansicht ist das letzte Argument - anders, als beim BulkUpdate - nicht optional, oder?

[Rampler]

Hallo zusammen,
habe nun mal meinen GoodWe GW8KN-ET via Modbus (WLAN) angebunden.
Hier mal die Definition:

Code Auswählen Erweitern

efmod GoodWe ModbusAttr 247 60 192.168.1.20:502 TCP
attr GoodWe comment Inbetriebname: 10.12.2024\
attr GoodWe dev-timing-sendDelay 0.1
attr GoodWe dev-timing-timeout 4
attr GoodWe enableControlSet 1
attr GoodWe event-min-interval PV_[1-2]_Power:900,E_.*:1800,SOC:1800,Power_.*:1800,PV_Total_Power:1800,AC_ActivePower:900,Inverter_Temperature:3600,BMS_Pack_Temperature:3600
attr GoodWe event-on-change-reading Power_.*:2,.*
attr GoodWe event-on-update-reading ARM_SVN_Version,ARM_Software_Version,BMS_Software_Version,DSP_SVN_Version,DSP_Software_Version,SOH
attr GoodWe icon measure_power_meter
attr GoodWe obj-h35016-poll once
attr GoodWe obj-h35016-reading DSP_Software_Version
attr GoodWe obj-h35016-showGet 1
attr GoodWe obj-h35018-poll once
attr GoodWe obj-h35018-reading DSP_SVN_Version
attr GoodWe obj-h35018-showGet 1
attr GoodWe obj-h35019-poll once
attr GoodWe obj-h35019-reading ARM_Software_Version
attr GoodWe obj-h35019-showGet 1
attr GoodWe obj-h35020-poll once
attr GoodWe obj-h35020-reading ARM_SVN_Version
attr GoodWe obj-h35020-showGet 1
attr GoodWe obj-h35103-expr $val/10
attr GoodWe obj-h35103-format %.1f
attr GoodWe obj-h35103-poll 1
attr GoodWe obj-h35103-polldelay x10
attr GoodWe obj-h35103-reading PV_1_Voltage
attr GoodWe obj-h35105-group 1-1
attr GoodWe obj-h35105-len 2
attr GoodWe obj-h35105-poll 1
attr GoodWe obj-h35105-polldelay x2
attr GoodWe obj-h35105-reading PV_1_Power
attr GoodWe obj-h35105-unpack L>
attr GoodWe obj-h35107-expr $val/10
attr GoodWe obj-h35107-format %.1f
attr GoodWe obj-h35107-poll 1
attr GoodWe obj-h35107-polldelay x10
attr GoodWe obj-h35107-reading PV_2_Voltage
attr GoodWe obj-h35109-expr ReadingsVal($name, 'PV_1_Power', 0) + $val
attr GoodWe obj-h35109-group 1-2
attr GoodWe obj-h35109-len 2
attr GoodWe obj-h35109-name Eigentlich PV_2_Power
attr GoodWe obj-h35109-poll 1
attr GoodWe obj-h35109-polldelay x2
attr GoodWe obj-h35109-reading PV_Total_Power
attr GoodWe obj-h35109-showGet 1
attr GoodWe obj-h35109-unpack L>
attr GoodWe obj-h35140-group 1-4
attr GoodWe obj-h35140-poll 1
attr GoodWe obj-h35140-polldelay x2
attr GoodWe obj-h35140-reading AC_ActivePower
attr GoodWe obj-h35140-showGet 1
attr GoodWe obj-h35140-unpack s>
attr GoodWe obj-h35174-expr $val/10
attr GoodWe obj-h35174-format %.0f
attr GoodWe obj-h35174-poll 1
attr GoodWe obj-h35174-polldelay x15
attr GoodWe obj-h35174-reading Inverter_Temperature
attr GoodWe obj-h35183-group 1-3
attr GoodWe obj-h35183-poll 1
attr GoodWe obj-h35183-polldelay x2
attr GoodWe obj-h35183-reading Power_Battery
attr GoodWe obj-h35183-showGet 1
attr GoodWe obj-h35183-unpack s>
attr GoodWe obj-h35184-map 0:Akku disconnected, 1:Standby, 2:Discharging, 3:Charging, 4: Waiting for charge, 5: Waiting for discharge
attr GoodWe obj-h35184-poll 1
attr GoodWe obj-h35184-polldelay x1
attr GoodWe obj-h35184-reading Akku_Mode
attr GoodWe obj-h35184-showGet 1
attr GoodWe obj-h35191-expr $val/10
attr GoodWe obj-h35191-len 2
attr GoodWe obj-h35191-poll 1
attr GoodWe obj-h35191-polldelay x90
attr GoodWe obj-h35191-reading E_PV_Total
attr GoodWe obj-h35191-unpack L>
attr GoodWe obj-h35193-expr $val/10
attr GoodWe obj-h35193-len 2
attr GoodWe obj-h35193-poll 1
attr GoodWe obj-h35193-polldelay x10
attr GoodWe obj-h35193-reading E_PV_Day
attr GoodWe obj-h35193-unpack L>
attr GoodWe obj-h35203-expr $val/10
attr GoodWe obj-h35203-len 2
attr GoodWe obj-h35203-poll 1
attr GoodWe obj-h35203-polldelay x60
attr GoodWe obj-h35203-reading E_Load_Total
attr GoodWe obj-h35203-unpack L>
attr GoodWe obj-h35205-expr $val/10
attr GoodWe obj-h35205-poll 1
attr GoodWe obj-h35205-polldelay x10
attr GoodWe obj-h35205-reading E_Load_Day
attr GoodWe obj-h35208-expr $val/10
attr GoodWe obj-h35208-format %.1f
attr GoodWe obj-h35208-poll 1
attr GoodWe obj-h35208-polldelay x10
attr GoodWe obj-h35208-reading E_Battery_Charge_Day
attr GoodWe obj-h35211-expr $val/10
attr GoodWe obj-h35211-format %.1f
attr GoodWe obj-h35211-poll 1
attr GoodWe obj-h35211-polldelay x10
attr GoodWe obj-h35211-reading E_Battery_Discharge_Day
attr GoodWe obj-h37003-expr $val/10
attr GoodWe obj-h37003-format %.0f
attr GoodWe obj-h37003-poll 1
attr GoodWe obj-h37003-polldelay x10
attr GoodWe obj-h37003-reading BMS_Pack_Temperature
attr GoodWe obj-h37006-reading BMS_Error_Code_L
attr GoodWe obj-h37006-showGet 1
attr GoodWe obj-h37007-poll 1
attr GoodWe obj-h37007-polldelay x5
attr GoodWe obj-h37007-reading SOC
attr GoodWe obj-h37007-showGet 1
attr GoodWe obj-h37008-poll 1
attr GoodWe obj-h37008-polldelay x60
attr GoodWe obj-h37008-reading SOH
attr GoodWe obj-h37008-showGet 1
attr GoodWe obj-h37010-reading BMS_Warning_Code_L
attr GoodWe obj-h37010-showGet 1
attr GoodWe obj-h37012-reading BMS_Error_Code_H
attr GoodWe obj-h37012-showGet 1
attr GoodWe obj-h37013-reading BMS_Warning_Code_H
attr GoodWe obj-h37013-showGet 1
attr GoodWe obj-h37014-poll once
attr GoodWe obj-h37014-reading BMS_Software_Version
attr GoodWe obj-h37014-showGet 1
attr GoodWe openTimeout 5
attr GoodWe room PV
attr GoodWe stateFormat <div style="color:white ;; text-align:left"><b>Leistung Zaehler: &nbsp &nbsp &nbsp &nbsp AC_ActivePower Watt </b>&nbsp &nbsp( - => Bezug  + => Einspeisung )</div>\
<div style="color:white ;; text-align:left"><b>Leistung Haus: &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp  Power_House Watt </b></div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="color:yellow ;; text-align:left"><b>Tägliche Werte:</b></div>\
<div style="color:yellow ;; text-align:left">==============================</div>\
<div style="color:white ;; text-align:left">Energie Verbrauch: &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp E_Load_Day kw/h</div>\
<div style="color:white ;; text-align:left">Energie Verbrauch gestern: &nbsp statE_Load_TotalDayLast kw/h</div>\
<div style="color:white ;; text-align:left">Energie Battery Entladung: &nbsp &nbsp E_Battery_Discharge_Day kw/h</div>\
<div style="color:white ;; text-align:left">Energie Battery Ladung: &nbsp &nbsp &nbsp &nbsp E_Battery_Charge_Day kw/h</div>\
<div style="color:white ;; text-align:left">Energie PV Ertrag: &nbsp &nbsp &nbsp &nbsp &nbsp  &nbsp &nbsp &nbsp &nbsp E_PV_Day kw/h</div>\
<div style="color:white ;; text-align:left">Energie PV Ertrag gestern: &nbsp &nbsp  statE_PV_TotalDayLast kw/h</div>\
<div style="color:yellow ;; text-align:left">==============================</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="text-align:left">PV Strang 1: &nbsp &nbsp  PV_1_Power Watt</div>\
<div style="text-align:left">PV Strang 1: &nbsp &nbsp  PV_1_Voltage Volt</div>\
<div style="text-align:left">PV Strang 2: &nbsp &nbsp PV_2_Power Watt</div>\
<div style="text-align:left">PV Strang 2: &nbsp &nbsp PV_2_Voltage Volt</div>\
<div style="text-align:left">PV Total DC: &nbsp  &nbsp PV_Total_Power Watt</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="text-align:left">Akku-Power: &nbsp &nbsp  Power_Battery Watt&nbsp &nbsp( - => Laden  + => Entladen)</div>\
<div style="text-align:left">Akku-Level: &nbsp &nbsp &nbsp  SOC %</div>\
<div style="text-align:left">Akku-Health: &nbsp &nbsp  SOH %</div>\
<div style="text-align:left">Akku-Status: &nbsp &nbsp Akku_Mode</div>\
<div style="text-align:left">Akku-Temp: &nbsp &nbsp &nbsp BMS_Pack_Temperature °C</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="text-align:left">BMS Version: &nbsp &nbsp BMS_Software_Version</div>\
<div style="text-align:left">DSP Version: &nbsp &nbsp DSP_Software_Version. DSP_SVN_Version</div>\
<div style="text-align:left">ARM Version: &nbsp &nbsp ARM_Software_Version. ARM_SVN_Version</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="text-align:left">WR Temp: &nbsp &nbsp &nbsp &nbsp Inverter_Temperature °C</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="color:green ;; text-align:left">Status: state</div>\

attr GoodWe userReadings PV_2_Power:PV_Total_Power.*\
{ReadingsVal("GoodWe","PV_Total_Power",0) - ReadingsVal("GoodWe","PV_1_Power",0)} ,\
Power_House:(PV_Total_Power|AC_ActivePower|Power_Battery|Akku_Mode).*\
{\
# Discharge\
if (ReadingsVal("GoodWe","Akku_Mode","") eq "Discharging" ) \
{ReadingsVal("GoodWe","AC_ActivePower",0)*-1 + ReadingsVal("GoodWe","PV_Total_Power",0) + ReadingsVal("GoodWe","Power_Battery",0) }\
# Charge via App/PV (Strombezug)\
elsif (ReadingsVal("GoodWe","Akku_Mode","") eq "Charging" && ReadingsVal("GoodWe","AC_ActivePower",0) < 0)\
{abs(ReadingsVal("GoodWe","AC_ActivePower",0)) + ReadingsVal("GoodWe","PV_Total_Power",0) - abs(ReadingsVal("GoodWe","Power_Battery",0)) }\
# Charge via PV (ohne Strombezug)\
elsif (ReadingsVal("GoodWe","Akku_Mode","") eq "Charging") \
{ReadingsVal("GoodWe","PV_Total_Power",0) - abs(ReadingsVal("GoodWe","Power_Battery",0)) }\
# Battery empty\
elsif (ReadingsVal("GoodWe","Akku_Mode","") eq "Standby") \
{ReadingsVal("GoodWe","AC_ActivePower",0)*-1 + ReadingsVal("GoodWe","PV_Total_Power",0) }\
}
attr GoodWe verbose 0

setstate GoodWe <div style="color:white ;; text-align:left"><b>Leistung Zaehler: &nbsp &nbsp &nbsp &nbsp 7 Watt </b>&nbsp &nbsp( - => Bezug  + => Einspeisung )</div>\
<div style="color:white ;; text-align:left"><b>Leistung Haus: &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp  310 Watt </b></div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="color:yellow ;; text-align:left"><b>Tägliche Werte:</b></div>\
<div style="color:yellow ;; text-align:left">==============================</div>\
<div style="color:white ;; text-align:left">Energie Verbrauch: &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp 6 kw/h</div>\
<div style="color:white ;; text-align:left">Energie Verbrauch gestern: &nbsp 7.5 kw/h</div>\
<div style="color:white ;; text-align:left">Energie Battery Entladung: &nbsp &nbsp 0.0 kw/h</div>\
<div style="color:white ;; text-align:left">Energie Battery Ladung: &nbsp &nbsp &nbsp &nbsp 0.6 kw/h</div>\
<div style="color:white ;; text-align:left">Energie PV Ertrag: &nbsp &nbsp &nbsp &nbsp &nbsp  &nbsp &nbsp &nbsp &nbsp 1.2 kw/h</div>\
<div style="color:white ;; text-align:left">Energie PV Ertrag gestern: &nbsp &nbsp  4.3 kw/h</div>\
<div style="color:yellow ;; text-align:left">==============================</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="text-align:left">PV Strang 1: &nbsp &nbsp  662 Watt</div>\
<div style="text-align:left">PV Strang 1: &nbsp &nbsp  640.1 Volt</div>\
<div style="text-align:left">PV Strang 2: &nbsp &nbsp 442 Watt</div>\
<div style="text-align:left">PV Strang 2: &nbsp &nbsp 369.1 Volt</div>\
<div style="text-align:left">PV Total DC: &nbsp  &nbsp 1104 Watt</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="text-align:left">Akku-Power: &nbsp &nbsp  -794 Watt&nbsp &nbsp( - => Laden  + => Entladen)</div>\
<div style="text-align:left">Akku-Level: &nbsp &nbsp &nbsp  16 %</div>\
<div style="text-align:left">Akku-Health: &nbsp &nbsp  100 %</div>\
<div style="text-align:left">Akku-Status: &nbsp &nbsp Charging</div>\
<div style="text-align:left">Akku-Temp: &nbsp &nbsp &nbsp 17 °C</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="text-align:left">BMS Version: &nbsp &nbsp 7</div>\
<div style="text-align:left">DSP Version: &nbsp &nbsp 12. 197</div>\
<div style="text-align:left">ARM Version: &nbsp &nbsp 29. 290</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="text-align:left">WR Temp: &nbsp &nbsp &nbsp &nbsp 36 °C</div>\
<div style="text-align:left"> &nbsp </div>\
\
<div style="color:green ;; text-align:left">Status: opened</div>\

setstate GoodWe 2024-12-26 11:50:47 AC_ActivePower 7
setstate GoodWe 2024-12-24 17:58:36 ARM_SVN_Version 290
setstate GoodWe 2024-12-24 17:58:36 ARM_Software_Version 29
setstate GoodWe 2024-12-26 11:52:46 Akku_Mode Charging
setstate GoodWe 2024-12-14 20:58:19 BMS_Error_Code_H 0
setstate GoodWe 2024-12-25 17:25:40 BMS_Error_Code_L 0
setstate GoodWe 2024-12-26 11:52:47 BMS_Pack_Temperature 17
setstate GoodWe 2024-12-24 17:58:41 BMS_Software_Version 7
setstate GoodWe 2024-12-15 10:47:27 BMS_Warning_Code_H 0
setstate GoodWe 2024-12-15 10:47:21 BMS_Warning_Code_L 0
setstate GoodWe 2024-12-24 17:58:35 DSP_SVN_Version 197
setstate GoodWe 2024-12-24 17:58:34 DSP_Software_Version 12
setstate GoodWe 2024-12-26 11:52:47 E_Battery_Charge_Day 0.6
setstate GoodWe 2024-12-26 11:42:47 E_Battery_Discharge_Day 0.0
setstate GoodWe 2024-12-26 11:42:47 E_Load_Day 6
setstate GoodWe 2024-12-26 11:11:47 E_Load_Total 156
setstate GoodWe 2024-12-26 11:42:47 E_PV_Day 1.2
setstate GoodWe 2024-12-26 10:51:46 E_PV_Total 28.6
setstate GoodWe 2024-12-26 11:50:47 Inverter_Temperature 36
setstate GoodWe 2024-12-26 11:50:47 PV_1_Power 662
setstate GoodWe 2024-12-26 11:42:46 PV_1_Voltage 640.1
setstate GoodWe 2024-12-26 11:50:47 PV_2_Power 442
setstate GoodWe 2024-12-26 11:50:47 PV_2_Voltage 369.1
setstate GoodWe 2024-12-26 11:50:47 PV_Total_Power 1104
setstate GoodWe 2024-12-26 11:50:47 Power_Battery -794
setstate GoodWe 2024-12-26 11:50:47 Power_House 310
setstate GoodWe 2024-12-26 11:47:47 SOC 16
setstate GoodWe 2024-12-26 11:48:47 SOH 100
setstate GoodWe 2024-12-26 11:52:47 statE_Load_Total Hour: 0.2 Day: 6.2 Month: 66.2 Year: 66.2 (since: 2024-12-20 )
setstate GoodWe 2024-12-26 11:52:47 statE_Load_TotalDay 6.2
setstate GoodWe 2024-12-25 23:59:55 statE_Load_TotalDayLast 7.5
setstate GoodWe 2024-12-26 10:59:55 statE_Load_TotalLast Hour: 1.8 Day: 7.5 Month: - Year: -
setstate GoodWe 2024-12-26 11:52:47 statE_PV_Total Hour: 0.0 Day: 0.4 Month: 21.7 Year: 21.7 (since: 2024-12-18 )
setstate GoodWe 2024-12-26 11:52:47 statE_PV_TotalDay 0.4
setstate GoodWe 2024-12-25 23:59:55 statE_PV_TotalDayLast 4.3
setstate GoodWe 2024-12-26 10:59:55 statE_PV_TotalLast Hour: 0.3 Day: 4.3 Month: - Year: -
setstate GoodWe 2024-12-26 11:52:32 state opened

Was nicht funktioniert ist das auslesen von:
E-Day-Sell h35199  (keine sinnvollen Werte)
E-Day-Buy h35202 (ist immer null)

Aktuelle bezogene Leistung des Hauses, sowie PanelLeistung musste ich via Userreading erstellen.
Läuft erst 2 Wochen, die Anbindung scheint stabil zu sein.

Evtl. hilft es ja den einem oder anderen ...

VG Klaus

EDIT: 26.12.2024 Definitionen aktualisiert

[Parallix]

Zwischen den Tagen hat man ja zumeist etwas mehr Zeit zum Stöbern. Dabei ist mir aufgefallen, dass es auf den Download-Seiten von Goodwe seit Mitte November 2024 eine von Goodwe bereits am 24.4.2024 aktualisierte technische Information "GoodWe Modbus Prtocol Hybrid" (Version 1.2) gibt. Das entsprechende PDF ist hier zu finden.

[Rampler]

Zwischen den Tagen hat man ja zumeist etwas mehr Zeit zum Stöbern. Dabei ist mir aufgefallen, dass es auf den Download-Seiten von Goodwe seit Mitte November 2024 eine von Goodwe bereits am 24.4.2024 aktualisierte technische Information "GoodWe Modbus Prtocol Hybrid" (Version 1.2) gibt. Das entsprechende PDF ist hier zu finden.

Zumindest für den GW8KN-ET passt die Doku nicht.
Beispiel Register 35182 (Battery1 Power) liefert beim GW8KN-ET keine Antwort.
Stattdessen liefert das Register 35183 die Info, welche aber in der Doku fehlt, scheint für andere Wechselrichter zu sein.
Schade, eine aktualisierte Doku wäre schön gewesen.
Anbei die Doku, welche zu meinem Beispiel/GW8KN-ET passt.. (halbwegs)