Hallo
Es handelt sich hier bei um einen Fenecon Hybridweschselrichter.
Ich habe folgendes Probelem, dass ich das Register 303 als float 32 bit mit littleendian convertierung auslese und es falsche Daten liefert:
Der SOC steigt an und das Register liefert fast keine Daten.
Wenn allerdings der SOC bei 100% bleibt und aufeinmal -10kW bezogen werden aber der SOC sinkt nicht.
Hat jemand von euch ein ähnliches Problem?
Die Register daten habe ich von hier, aus dem Abschnitt 3.3: FEMS App Modbus/TCP schreibend :: FENECON Dokumente
@s_h Dann sind es Werte im Megawatt bereich.
Wenn die Konvertierung falsch wäre würde die Daten extremer hin und her springen zwischen Minus und Plus, ihr könnt auf dem Bild sehen, dass die Werte teils einer Rampe folgen.
@s_h Das freut mich sehr für dich. @stefan.feilmeier Vielen Dank für den Wilkommensgruss, ich kann dir garantieren die Kodierung stimmt (Vielleicht verwechseln wir die Namen). Denn Fall mit der Kodierung, hatte ich bereits getestet.
Kann ich über ein Register die Versionsnummer auslesen (ich habe nichts im Dokument, oben erwähnt, gesehen) ?
Oder gibt es einen anderen Testcase?
Oder hättest du mir noch einen anderen Lösungsansatz?
Die Schnittstellenbeschreibung aus dem Link ist nicht aktuell.
Ich muss mich korrigieren.
Falls beim ModbusTCP Read/Write nur die Komponente “_sum” eingetragen ist, stimmt die Beschreibung mit der von “nur lesend” überein.
Ist auch “ess0” konfiguriert, können die Register anders sein, je nachdem, in welcher Reihenfolge die Komponenten eingestellt sind.
Am besten lädt man sich aus dem FEMS im Anlagenprofil bei “Externe Schnittstellen” die jeweilige Protokollbeschreibung herunter. Die ist aktuell.
@s_h Vielen Dank das könnte es sein, ich frage die Systeme mittels ModbusTCP ab.
Kann ich das mittels Versionen Nummer erkennen?
Habe bereits Register 304 getestet mit float 32, gibt mir eine illegale Daten Adressen Exception zurück.
Bei Register 583, erhalte ich nan zurück da, sehr wahrscheinlich wegen der Schreiblizenz die nicht vorhanden ist.
Theoretisch ja; praktisch ist die Reihenfolge aber in den allermeisten Fällen gleich.
Theoretisch deshalb, weil OpenEMS sehr modular ist und jede Komponente ihre eigene Modbus-Tabelle definieren kann. Je nachdem, welche Komponenten dann im Protokoll freigegeen sind und wie diese sortiert sind, kann sich die Reihenfolge theoretisch ändern. Der Aufbau des Protokolls orientiert sich deshalb an SunSpec und könnte auch dynamisch eingelesen werden (unsere OpenEMS Edge-to-Edge-Implementierung macht das: openems/io.openems.edge.edge2edge at develop · OpenEMS/openems · GitHub).
In der Praxis werden bei einem FEMS mit Schreibzugriff die Reihenfolge der Komponenten und damit die relevanten Modbus-Register immer gleich sein. Erst _sum für allgemeine Daten, dann ess0 für die Ansteuerung des Speichers oder Speicher-Clusters. Dahinter kommen dann häufig weitere Leseregister, falls gewünscht (z. B. für Details zu den einzelnen technischen Einheiten aus Batterien und Wechselrichtern, Ladesäulen, etc.)
Diese Reihenfolge kann im Anlagenprofil, im App-Center und im Excel-Protokoll überprüft werden. Wenn du mir die FEMS-Nummer schickst (per PN), kann ich auch mal einen Blick darauf werfen.
@PvSolar: die FEMS-Nummer steht auch in der Excel-Tabelle des Protokolls (Modbus-TCP-femsXXXXX.xlsx) oder kann am Register 85: Manufacturer EMS Serial Number als string16 ausgelesen werden.
→ Register 303: _sum/EssActivePower = 8024 W
(Übrigens wäre in bei einem Hybrid-System wie dem FENECON Home das Register 415: _sum/EssDischargePower meistens aussagekräftiger)
QModMaster führt hier intern schon die Konvertierung von IEEE-754 Floating Point durch. Manuell sieht das so aus:
Zu beachten ist noch: sollten einmal keine Daten verfügbar sein, z. B. weil der Speicher ausgeschaltet ist, bei Kommunikationsfehler, etc. werden folgende Daten zurückgegeben: (dokumentiert im Excel-Export in der Tabelle Undefined values:
In case a modbus value is ‘undefined’, the following value will be read:
