Fronius Wechselrichterdaten über Modbus TCP/IP in Loxone einlesen

[Bogenhaus]

ein Update
das mit dem SEQ_ERROR wird sich Loxone kommende Woche ansehen

Neue Inkonsistent wieder aufgetreten - diesmal lief auch der Modus Monitor

um z.B. 11:27:10 haben sich DCW 1 und DCW 2 um Faktor 10 geändert - der DCW_SF erst einen Zyklus später um 11:27:20

gleiches sieht man im Monitor



Ich werde das mal an Fronius senden was die dazu sagen - sieht man recht gut 3 Werte höher beim 1DCW, aber nur 2 mal bei DCW_SF

[Tico]

Zunächst müssen Sie verstehen, dass die Architektur von Fronius Modbus schlecht konzipiert ist. Die Aufteilung eines Wertes auf zwei Register (Skalierungsfaktor und Basiswert), die zwei getrennte Abfrageanforderungen erfordert, ist wirklich schlecht konzipiert.

Bei SMA-Wechselrichtern sind der Wert und der Skalierungsfaktor in aufeinanderfolgenden 16-Bit-Registern viel besser aufgehoben. In Loxone können Sie beide Werte in einer einzigen Abfrage mit einer 32-Bit-Registeradresse abrufen. Kein zeitlicher Unterschied.

Meiner Erfahrung nach ist die Zeitüberschreitung mit 1000 ms etwas zu lang. Wenn das Netzwerk von einer kurzen Störung betroffen ist, wartet der Miniserver die vollen 1000 ms auf eine Sensorantwort.
Nehmen wir an, Sie haben 24 Sensoren, und sagen wir, 8 sind von einer kurzen Netzwerkstörung betroffen. Das sind dann 8 Sekunden Wartezeit. Die restlichen Sensoren werden abgefragt, aber der Zeitrahmen für alle Sensoren geht über 10 Sekunden hinaus.
Der Miniserver fragt nun einen Wert ab, der möglicherweise nicht mit dem Skalierungsfaktor übereinstimmt, an den er angepasst werden sollte.
Haben Sie die Speicherflags für DCW, DCW1, DCW2, DCW3 und den Skalenfaktor berücksichtigt? So sollte es aussehen -




Sie sollten die vorhandenen 5 zeitkritischen Sensoren löschen und neu beginnen. Erstellen Sie die neuen Sensoren in dieser Reihenfolge -

DCW
DCW_SF
DCW1
DCW2
DCW3

Während Sie die Aktualisierung in LiveView beobachten, sollten Sie einen Fluss nach unten auf der Seite sehen. Der Analogspeicher-Trigger sollte in einem sicheren Abstand zur letzten Aktualisierung in jedem 10-Sekunden-Zyklus erfolgen.

P.S. Haben Sie eine Ethernet- oder WiFi-Verbindung zum Gen24?

[Bogenhaus]

Hallo

sehe dass auch so dass die Aufteilung schlecht ist - ist angeblich laut der SunSpec Spezifikation so üblich.
Ich habe Ethernet - 1GB - Miniserver und Wechselrichter im gleichen VLAN, am gleichen Switch

Netzwerkstörungen in dem Zusammenhang konnte ich keine feststellen.
Die Reihenfolge habe ich im Grunde so - nur den DCW habe ich danach - mit dem mache ich eigentlich auch nur die Erkennung auf Änderung. Meiner Meinung nach auch kein Nachteil.


Ich hatte das mal so wie du - die Problematik war die selbe.
Aktuell speichere ich nicht die Werte einzeln sondern das Ergebnis des Formelbausteins - um auch diesem Zeit zu geben wirklich durchzulaufen mit den beiden Werten

Aktuell ist es so umgesetzt, die VQ schreiben in die Influx
DCW kommt als letztes vom Bus, eine Änderung wird 1s verzögert - danach werden die Ergebnisse der Formelbausteine gespeichert
Meiner Meinung klappt das sehr gut - x-fach pro Tag, bis auf einige Ausnahmen




Letztlich liegt es aber meiner Meinung nach daran dass der Datemempfang nicht passt - siehe Export aus dem Modus Monitor
Egal was wir für eine Logik machen wird es in dieser Konstellation schief gehen müssen

Oder interpretierst du es anders ?



Hab das mal an Fronius geschickt - mal sehen was von dort kommt, sind eigentlich recht bemüht

Worst Case belieb ich dabei die Werte aus der inoffiziellen API zu holen

lg

[Tico]

Der Screenshot ist insofern informativ, als der Fehler bei einem "Gangwechsel" auftritt. Entschuldigen Sie die Analogie zum Fahrrad, aber die dargestellte Sequenz entspricht einem kurzen Wechsel vom hohen in den niedrigen und dann in den hohen Gang.



Um 11:27:02 Uhr befinden wir uns im hohen Gang. Um 11:27:12 Uhr schalten wir einen Gang zurück. Leider wurde der Wechsel des Skalierungsfaktors knapp verpasst. Er hätte -1 sein müssen, aber diese Änderung ist wahrscheinlich im Wechselrichter in den nächsten 200 Millisekunden erfolgt (kurz bevor der 1DCW Wert um 11:27:13 abgelesen wurde).

Die Werte im niedrigen Gang liegen sehr nahe an dem maximal möglichen Wert für einen 16-Bit-Wert (65535).

Um 11:27:43 Uhr schalten wir wieder in den hohen Gang mit 6588 und Skalierungsfaktor 0 (weil es unmöglich ist, 65880 darzustellen, weil es größer ist als die 16-Bit-Grenze).

Leider können weder Fronius noch Loxone dieses Problem lösen. Fronius könnte es wohl beheben, indem es die Modbus-Registertabelle komplett umgestaltet und den Skalierungsfaktor neben dem Register für den Wert einfügt. Das wird aber nicht passieren, weil es alle Altsysteme zerstören würde.

Es gibt eine Möglichkeit, die fremden Werte zu filtern, die noch nicht erforscht wurde. Der Skalierungsfaktor 0 steht für eine hohe Solarproduktion. Skalenfaktor -1 und -2 stehen für eine geringere Solarproduktion. Der "höchste Gang" für mein System ist der Skalierungsfaktor 0. Bei Skalierungsfaktor 0 ist der ausgegebene 1_DCW Wert 1:1 mit den Watts.

Ich habe eine physikalische Grenze von Solarmodulen, die besagt, dass ich nicht mehr als 8500 Watt auf 1_DCW haben kann. Wenn der Skalierungsfaktor 0 ist und Werte über 8500 Watt auftreten, kann ein Statusblock den fremden Wert auf die Erwartungen abändern (indem er erkennt, dass der Skalierungsfaktor um eine Größenordnung daneben liegt).




Der Wert 9000 muss so geändert werden, dass er knapp über dem erwarteten Höchstwert für jeden der DCW1, 2, 3 und 4 liegt, wenn der Skalierungsfaktor 0 ist.

Dies kann die niedrigeren Gangwechsel nicht korrigieren, z. B. 650 Watt/65 Watt. Aber der Fehler wird erheblich reduziert.

Außerdem behebt es nur den Downshift-Fehler (das Beispiel in Ihrem Screenshot), bei dem die Werte um den Faktor 10 aufgebläht werden. Es behebt nicht den Upshift-Fehler, bei dem die Werte kurzzeitig um den Faktor 10 verringert werden.

Ich hoffe, das macht etwas Sinn...

[Bogenhaus]

Hi, du hast mit deinen Ausführungen vermutlich recht. Sehe auch dass du dich damit wirklich sehr intensiv auseinandergesetzt hast und ein hohes Wissen dazu hast.

Ich habe mittlerweile auch eine Logik implementiert um "den Fehlerfall" auszublenden - einen einfache Sache wird langsam immer komplexer :-(

Die Idee - die beiden Rohwerte vom Modbus laufen direkt in den Formelbaustein.
das aktuelle Ergebnis wird mit dem zuletzt getrillerten Ergebnis verglichen ob es innerhalb von +-80% liegt (Multipliziere und Dividieren mit 8). Wäre also der Unterschied in der Gegend Faktor 10 würde die Logik kein True ausgeben. Die Triggerung erfolgt dann wie gehabt mit damverzögerten Impuls auf die Änderung beim Modbus Empfang.


Scheint im Moment zu klappen - schlimmsten Fall wird mal eine Änderung ausgelassen.
unten der Scale Faktor oben blau der verrechnet Wert nach der Formel - die orange Linie der getriggerte -man sieht (etwas schlecht) dass die Fehlerwerte nicht durchgehen)

[Bogenhaus]

Habe übrigens eine zusätzliche Erkenntnis gehabt welche ich bei Loxone hinterfragen werde

im Post #30 habe ich geschrieben dass sich das Timing verändert hat - langsamer wurde.
Ich dachte ich hab das heute wieder - habe aber festgestellt dass das nur am Modbus Monitor selbst liegt. Im Debugmonitor läuft alles sehr flott, im Debug Monitor wird es gemütlich angezeigt.

Scheint dass der Monitor eine eigene Task ist welche "in Bedrängnis" kommt.

[Witte]

Hi zusammen,

ich steh im Moment irgendwie am Schlauch (oder auf mehreren?) und bräuchte eure Hilfe:
An meinem Fronius Symo sind ZWEI SmartMeter Fronius TS 65A-3 angeschlossen und konfiguriert, einer an der Zählerposition "Einspeisepunkt" (Registeradresse 1)
und einer an der Zählerposition (so wird die Spalte unter http://<fronius_ip>/#/settings/meter genannt) "Verbraucherzähler" (Registeradresse 2).
Unter http://<fronius_ip>/solar_api/v1/GetMeterRealtimeData.cgi?Scope=System kann ich unter
Body -> Data -> 0: Den SmartMeter am Einspeisepunkt
Body -> Data -> 1: Den SmartMeter am Verbraucherzähler

sehen.

Jetzt gibt es mehrere Möglichkeiten, diese Informationen in Loxone einzubinden oder? (https://loxwiki.atlassian.net/wiki/s...Wechselrichter)
Nach allem was ich gelesen habe würde ich die Daten vom Fronius Wechselrichter selber über den Energiemonitor Baustein eingelesen.
Jetzt möchte ich die Werte vom Verbraucherzähler und vom Einspeisepunkt noch auslesen. Dafür gibt es ja mehrere Möglichkeiten: über die API oder über Modbus.
Ich würde mich für Modbus entscheiden, da es wohl ausfallsicherer ist (hab ich aus dem Forum gelesen).

Also hab ich einen Modbus Server erstellt und folgende Vorlage gezogen: https://library.loxone.com/detail/fr...r-978/overview
Die Vorlage für den Smart Meter hab ich nicht genommen, das ist keine Modbus Vorlage, sondern die macht Virtuelle Eingänge auf: https://library.loxone.com/detail/fr...a-556/overview

Für Modbus hab ich also die genommen, die für Laien verlinkt ist:https://loxwiki.atlassian.net/wiki/s...mittels+Modbus

Nach der Anleitung hab ich auch die SmartMeter als Modbus Geräte eingebunden:


Leider kommen keine Werte an bei TotWhExp, W usw...
Muss ich beim Datentyp usw.. was beachten oder wo könnte ich mich einlesen?

[Witte]

Habs aufgegeben. Nehm jetzt die solar_api, auch wenn sie nur alle 10 Sekunden abgerufen wird. Deutlich komfortablere API.

[Bogenhaus]

Ich kann dich da gut verstehen und denke da recht ähnlich.

Da ich im früher alles über die API gelesen habe , teilweise aus der undokumentierten (somit jederzeit möglich dass es das nicht mehr gibt) dachte ich auch mit ModBus besser dran zu sein und habe mir damit eine Menge an Arbeit gemacht.

Dein Problem mit dem Smartmeter konnte ich nicht bewerten da ich das nie versucht habe.

Meine Erkenntnis - die API läuft bei mir komplett sorgenfrei und stabil. Kommunikationstechnisch ist es eine Anfrage und in Loxone entsprechende Auswertungen einer Antwort. Bei ModBus wird von Loxone jedes Register eigens geschickt , auf Antwort gewartet …
Daraus resultierend auch Inkonsistenzen bei Werten welche Skalierungsfaktoren haben - was mir der Fronius Support bestätigt hat - die empfehlen die API zu nutzen in Loxone.

Dazu kommt, dass ich gar nicht alle Werte aus der API am Modbus gefunden haben - z.B. SOH (Health) der Batterie oder Zeit im Backup Mode.
Also habe ich jetzt eine umfangreiche Lösung um die Werte über ModBus zu plausibilisieren , brauche aber die API immer noch weil über Modbus nicht alles verfügbar ist.
Und ob die Wert in 10 oder 5s verfügbar sind ist wohl nicht so entscheidend - für mich jedenfalls nicht.

Ich werde demnach vermutlich bei der API Lösung belieben und ModBus nur für die Steuerungsaufgaben wie Batterie Lade/Entladeleistung Begrenzung verwenden.

Übrigens - auch den Energiemonitor habe ich eliminiert.
Der Baustein ist nicht mehr nötig, greift auch nur die Werte über die API ab, ist optisch „alt“ (gruselig Statistiken wie früher). Der Energieflußmonitor stellt das gleiche und mehr dar in aktueller Optik. Hab defakto den Energiemonitor nie mehr angesehen.
Somit weg, Statistikdatenaufzeichnung sparen und gut ist.

Weiterhin viel Erfolg

[Witte]

Ich hab mir wunder was von Modus erwartet, um dann festzustellen, dass das Zeug sooo Oldschool ist... Alter Schwede.
Ist man in Zeiten von GRPC, MQTT usw.. nicht mehr gewohnt🙃

Ah, du hast den Energiemonitor für den WR einfach durch nen stinknormalen Zählerbaustein ersetzt?
Welche URL der API verwendest du um die Daten vom Wechselrichter selber abzurufen?
Also nicht die von den angeschlossenen SmartMetern....

[Bogenhaus]

ja, da hast du recht, Modbus ist halt aus den 1980er Jahren.
Alleine der Ansatz der SunSpec Spezifikation welche Fronius verwendet mit Interneren und Skalierungsfaktor zeigt schon dass das einfach alt ist, da musste man sich noch anders helfen

genau - ich hab zum Energieflußmonitor kompatible Zähler
- Zähler für Speicher - alles rund um die Batterie
- Zähler - AC Leistung
- Zähler - je String für die DC Leistung
- Zähler bidirektional - für Netz Ein/Rückspeisung

Soweit ich mich erinner gibts beim Energiemonitor die Funktion des Konvertieren (rechts click auf Baustein oder so ähnlich)

Im Energieflußmonitor verwende ich die DC Zähler der Strings was mir besser gefällt und den echten Fluß darstellt. Der AC Zähler arbeitet ja nicht wenn die Batterie geladen wird.

Ich nutze folgende URLs
http://Fronius-IP/components/readable (da wäre alles drinnen, ist nur so dass Fronius nicht dafür garantiert alles zu ändern)
http://Fronius-IP/solar_api/v1/GetStorageRealtimeData.cgi
http://Fronius-IP/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId= 1&DataCollection=CommonInverterData

[DrS332]

Hallo.

Ich habe einen Gen24 und einen Symo mit je 2 Felder. In Summe also 4 Felder. Ich frage per Modbus/TCP die Leistung von jedem String ab.
Dafür habe ich zwei Modbus Server in der LoxConfig angelegt.

Gen24 - IPvomWR:502 // Wartezeit: 0 // Timeout: 500ms // Fragmentierte Pakete ON

• 40284 - AC Power 1
• 40304 - AC Power 2
• 40267 - Power Scale Factor

Symo - IPvomWR:502 // Wartezeit: 0 // Timeout: 500ms // Fragmentierte Pakete ON

• 40284 - AC Power 1
• 40304 - AC Power 2
• 40267 - Power Scale Factor

Wenn nachts die Sonne untergeht, springt beim Symo AC Power 1 (40284) der Wert ständig zwischen 0 und 65.535. Die anderen 3 Strings zweigen immer korrekt an.
Tagsüber ist diese Phänomen nicht zu beobachten.
Auch die Werte für Current und Voltage springen bei dem einen Feld zwischen "plausibel" und 65.535.

Die Einstellungen sind Befehl, Datentyp, 16-Bit Register sind bei allen v4 Strings gleich.

Mit UINT/INT, 0x03/0x04, 16-Bit Register ON/OFF, Fragmentierte Pakete ON/OFF habe ich mich schon gespielt. Ohne Erfolg.

Kann sich jemand einen Reim darauf machen?

P.S: Aktuell habe ich die Validierung auf min:0 / max:65.534 eingestellt. Aber das kann ja nicht die Lösung sein ;-)

[Schneider1983]

Hallo Loxis,

ich habe einen Fronius Symo Wechselrichter den ich über die Netzwerkperipherie/Modbusserver/Fronius Symo/Sensoren einwandfrei auslesen kann. Hab mir aus der Libary die Vorlage dazu geholt.
Jetzt meine Frage. Ich habe ein Fronius Smartmeter 63A mit dem Wechselrichter verbunden, das ich auch über das Fronius Portal sehe, Werte kommen an.
Kann ich die Werte direkt über den Modbusserver auslesen? Mich würde der Wert "Power SUM (Pv)" interessieren, damit ich mein Elektrofahrzeug mit Überschuss laden kann. Gibt es eine IO-Adresse mit der ich die Modbusabfrage erweitern kann? Prinzipiell ist der Wert im Wechselrichter ja vorhanden.

Alternativ habe ich es über die virtuellen Eingänge versucht, aber leider nicht zum Laufen gebracht. Dazu gibt es auch eine Vorlage in der libary, welche ich verwende.
Welche Infos muss man in der URL ergänzen "http://192.168.x.x/solar_api/v1/GetMeterRealtimeData.cgi?Scope=System". Leider bin ich nicht so tief im Thema. IP Adresse ist klar, aber muss die Datenlogger ID oder etwas anderes auch noch irgendwo in den Pfad eingeben?

Schon mal danke für eure Hilfe.
Gruß
Christoph

[romildo]

Schneider1983
Hallo, ich kenne kein Register "Power SUM(Pv)". Könnte sein, dass du "Total Real Power" meinst.
Man hat schon Zugriff auf einige Daten vom "Fronius Smart Meter" darüber wurde auch schon viel im Forum geschrieben.

Das Smartmeter ist üblicherweise über die Geräteadresse 200 zu erreichen.
Dann muss man noch wissen ob die Einstellung im Fronius auf "Float" oder "Int&SF" steht.
Je nachdem gibt es dann die Dokumentationen dazu.
Bei Float wäre es die Datei "Smart_Meter_Register_Map_Float.xlsx"
In dieser Tabelle findet man auch die Registerwerte.
Beispielsweise 40098-40099 für "Total Real Power".
In Loxone müsste dann Register 40097 als IO-Adresse eingetragen werden.
Befehl: 3-Read Holding Register
Datentyp: 32-bit floating pont
Häkchen bei 16-Bit Register und Registerreihenfolge

Abfrage über API ist eigentlich recht einfach.
Du legst einen Virtuellen HTTP Eingang mit der URL "http://192.168.x.x/solar_api/v1/GetMeterRealtimeData.cgi" an.
Dann noch einen Virtuellen HTTP Eingangsbefehl dazu. Dort bei der Eigenschaft Befehlserkennung ganz rechts auf die 3 Punkte klicken, dann sollte sich ein Fenster öffnen. In diesem Fenster kannst du dann sehen, was alles abgefragt werden kann und zudem auch gleich die Befehlserkennung getestet werden.
Beispiel Befehlserkennung: "Current_AC_Phase_2" : \v

[He.Slar]

Hallo,

das Thema Solar API wird parallel in einem anderen Tread auch gerade behandelt:

https://www.loxforum.com/forum/german/software-konfiguration-programm-und-visualisierung/438586-energieflussmonitor

Gruß
Andreas