Fronius Wechselrichterdaten über Modbus TCP/IP in Loxone einlesen

[romildo]

das ist mir schon klar, nur hat "DC Power" die Startadresse 40285 und ist "uint16". In Loxone somit die Adresse 40284.
Wenn jetzt "LifeTimeEn1" auch 40284 bekommt, beisst sich das nicht


Korrektur:
Registeradresse Loxone = Registeradresse Registerverzeichnis -1
Type > 16 Bit = Häkchen bei Loxone Registerreihenfolge
Somit hat "DC Power" die Loxone IO Adresse 40284 und "LifeTimeEn1" die Loxone IO Adresse 40285

[romildo]

Ich habe es jetzt ohne es zu verstehen, trotzdem mal bei mir so eingebunden.
Mal sehen, welche Ergebnisse bei mir rauskommen.
Werde in ein paar Tagen berichten.

[Bogenhaus]

super, bin gespannt

eventuell ist diese „Überlappung“ ja auch das Problem
Ich wüsste nur nicht wie man sonst addressiert - wenn man nicht -2 rechnet stimmts ja gar nicht

[romildo]

Bei "AC Energy" Register 40102 float32 (Loxone Register 40100) gibt es ja auch Unstimmigkeiten, obwohl es hier keine Registerkonflikte gibt.
Kann gut sein, dass es da mehrere Probleme gibt.

[SPS-Guru]

Hallo zusammen

Ich bekomme meinen SymoGEN24 leider erst in ein paar Wochen aber das Thema interessiert mich natürlich.
Wahrscheinlich stehe ich einfach auf dem Schlauch aber die Registeradresse beim Modbus-Protokoll setzt sich
doch eigentlich aus Funktionscode und Registeradresse zusammen. Der Unterschied zwischen RTU und TCP besteht
eigentlich nur aus einem speziellen Header für TCP. Die Registeradressierung steht in der "PDU" und sollte für beide Varianten die selbe sein.

Also hier für "Lifetime Energy" Funktionscode(03) = Offset 40000, Adresse des ersten Registers 40286 - 40001 = 285, Offset 40000 vorgegeben durch Funktionscode

Dann gibt es auch keine Adressüberlappung weil immer nur -1.
Hat das schon mal jemand so ausprobiert?

[Bogenhaus]

Ich verwende Modbus TCP zum Fronius SymoGen und Modbus über die ModBus Extension über RS485 zu meiner Wärmepumpe.
Bei der Wärmepumpe ist es tatsächlich so dass die Offsets nicht mitgerechnet werden.

Beim Modbus TCP zum Fronius gehts aber nur so dass man die gesamte Nummer angibt und 1 oder 2 abzieht je nach 16bit/32bit - ich hab das mehr/weniger auch experimentel ermittelt - anders bekommt man keine Werte
Ich könnte mir eventuell auch vorstellen dass das an der Implementierung von Loxne liegt - soweit bin ich dabei aber einfach nicht im Thema.
Ich hab glaube ich auch schon im Kontext iOBrocker gelesen dass dort die kompletten register und -1 angegeben werden.

[romildo]

Beim "Shelly Pro 3EM" muss über Modbus TCP bei Funktionscode "4-Reading input register(3x)" der Offset auch nicht mitgerechnet werden.
Es muss aber auch nichts abgezogen werden.
Beispiel:
Shelly Register: 31020 float Phase A voltage, V
Loxone IO Adresse: 1020

[SPS-Guru]

Das mit dem "-1" kommt daher weil die Daten eines Moduls in 4 Tabellen gespeichert werden.
Jede Tabelle hat jeweils ihren eigenen Offset --> 1,10001,30001,40001.
Ein Holding Register mit der Nummer 40001 hat aber die Adresse 0000 also -1.

Deshalb verstehe ich eben auch die -2 bei den 32bit Werten bei Fronius nicht.
Da müsste mir dann auch einer erklären welche Adresse das Register 40001 "SID" (32bit) dann bekommen soll.
39999 kann es ja nicht sein weil kein Holding-Register mehr.

[romildo]

Hallo SPS-Guru

[SPS-Guru]

Ja dann hält sich da wohl einer von den Herstellern nicht an das offizielle Modbus-Protokoll.
Wie gesagt ich warte noch auf den Fronius und habe aktuell kein ModbusTCP Gerät hier.
Wenn ich meinen MS mit einem ModbusTCP-Simulator verbinde funktioniert das mit 285 für Register 40286.

[romildo]

SPS-Guru bezugnehmend auf Post 17.3
Tja, so wie du schreibst steht es ja auch in der Doku von Fronius

Ähnliche Werte kommen auch mit -1, wenn man die Registerreihenfolge setzt, so dass zuerst das LowWord und dann das HighWord gelesen wird.
Das ist vermutlich auch die einzig richtige Einstellung.
Bei mir war es nur so, dass so die Werte in Loxone täglich etwas höher ausgefallen sind wie die von der API, was bei -2 nicht der Fall war.

Mir ist aber schon auch klar, dass nur eine Variante die Richtige sein kann.

Vielleicht habe ich bei meinen vielen Versuchen auch einfach sonst noch was falsch gemacht.
Ich werde das jetzt nochmals mit -1 und Häkchen bei Registerreihenfolge testen und mit den API Werten vergleichen.

[SPS-Guru]

Ja schauen wir mal.
In KW28 sollte ich meinen WR bekommen 😎

[Bogenhaus]

Hallo romildo und SPS-Guru

ihr seit nun meine beiden Helden

das war es, bei 32 oder 64 Bit Werten - Adresse -1 und die Registerreihenfolge anhaken - damit sind die Werte plausibel, schwanken auch nicht mehr
Und damit ist erstmalig auch ein Wert im acc64 Format lesbar

Das alleine bestätigt schon das es so richtig sein muss.

Irgendwie ja erstaunlich dass es anders auch "irgendwie" ging was mich leider auf die falsche Spur führte.
Danke euch !!


LifeTimeEn1 - alte Variante register -2
LifeTimeEn1-2 - neu Variante -1, und Refgisterreihenfolge
PV-API-PV_ENERGYACTIVE_ACTIVE_SUM_01_U64 kommt über die API

[Bogenhaus]

Noch ein Nachtrag - schneller als im 10s Raster werden die Werte über Modus TCP bei mir auch nicht abgefragt - trotz Einstellung 5s (minimaler Wert laut Config)

[romildo]

Kann ich so nicht bestätigen, bei mir kommen die im 5s Takt.
Miniserver Gen2
Config Version 14.1.5.9

[Bogenhaus]

spannend

hab gleiche HW, gleiche SW,alle 5 derzeit verwendeten Sensoren auf 5s gestellt.
Miniserver nun gerade mit Power aus/ein gestartet -immer noch 10s

Langsamer kann ich einstellen - aber unter 10 wird nicht gesendet

[Tico]

Jeder Modbus-TCP-Sensor benötigt eine endliche Zeit, um interagiert zu werden. Ein hypothetisches Beispiel: Wenn romildo 10 Sensoren hat, könnte dies gerade noch innerhalb der Grenze für 5-Sekunden-Aktualisierungen liegen. Wenn Bogenhaus 20 Sensoren hat, fragt der Miniserver nacheinander jeden Sensor mit der gleichen Rate ab, aber es dauert doppelt so lange, bis er fertig ist.

Die Einstellung "Timeout" hat einen erheblichen Einfluss auf die Aktualisierungsrate der Sensoren. Hier ist ein Link, wenn Sie die Modbus-TCP-Rate optimal einstellen möchten - Optimising Modbus Polling

https://loxwiki.atlassian.net/wiki/spaces/LOXEN/pages/1316061809/Fronius+Hybrid+with+Modbus+TCP#FroniusHybridwithModbusTCP-g.OptimisingModbusPolling

[Bogenhaus]

Danke Tico, es lag tatsächlich am Timeout - auch wenn ich das Verhalten nciht nachvollziehen kann.

Ich habe derzeit 5 Sensoren - bei allen ist 5s Abtastrate eingestellt.
Timeout ursprünglich 1000ms
Sensoren wurden alle 10s abgefragt

Ich hab Tineout auf 500ms geändert - tatsächlich wurden Sensoren in 5s abgefragt.
Dann das timeout im 100ms Ratser erhöht bis zu den ursprünglichen 1000ms - immer noch Abfrage im 5s Raster

Egal - ich werde dies solle ich die ModBus Schnittstelle erweitern jedenfalls in Erinnerung behalten ;-)

Danke nochmals

[romildo]

Ich habe zurzeit ca. 30 Sensoren mit 5s Abtastrate mit einem Timeout von 300ms
Der ModbusMonitor zeigt schon, dass da reger Verkehr herrscht.
Dies nur zur Info.
Auch einen Dank an @Tico
"Liken" kann man Kommentare ja leider nicht

[Tico]

romildo - Das ist interessant mit 30 Sensoren bei 5 Sekunden Aktualisierungsrate.Ich hatte das Wiki mit der Erfahrung des Miniserver Gen 1 geschrieben, der wäre bei so vielen Sensoren im Eimer gewesen.
Damals habe ich die Fronius-Kommunikation auf den "Push"-Dienst innerhalb des Wechselrichters übertragen (Fronius FTP to Node-Red to MQTT to Loxberry to Miniserver Virtual Input).
Vielleicht werde ich Modbus jetzt mit einem Miniserver Gen2 als Gateway wieder aufgreifen.

[romildo]

...ja da geht schon was ab



Hier noch der Vergleich wie in Post 19 geschrieben.
Die Kurven laufen absolut parallel, Für die unterschiedlichen Werte zwischen API und ModBus habe ich jedoch keine Erklärung

[Tico]

Ich sehe einen ungewöhnlichen Unterschied zwischen E_Total, wenn ich den folgenden Endpunkt aktualisiere (ich verwende ein anderes System im Fronius Symo Hybrid) -

http://Inverter_IP/solar_api/v1/GetPowerFlowRealtimeData.fcgi

Die E_Total (Inverters) hinkt der E_Total (Site) hinterher. Wenn der Endpunkt mehrfach aktualisiert wird, holt die E_Total (Inverters) manchmal auf und stimmt mit der E_Total (Site) überein.

E_Total (Site) hat eine höhere Granularität als E_Total (Inverters), manchmal mit mehreren Dezimalstellen.

Ich frage mich, welche E_Total Sie von der API verwenden? Ich würde mich auf den Modbus-Stream als maßgeblichen Wert verlassen. AlexAn schrieb auch etwas über eine Verschiebung in diesem Beitrag -

https://www.loxforum.com/forum/german/software-konfiguration-programm-und-visualisierung/393714-fronius-wechselrichterdaten-%C3%BCber-modbus-tcp-ip-in-loxone-einlesen?p=393852#post393852

[romildo]

Danke für die Info.
Mein API-Wert "TOTAL_ENERGY" kam von "GetInverterRealtimeData.cgi".
Die Info von AlexAn habe ich anders verstanden. Wenn der Scale-Faktor falsch wäre, müssten die Werte um Potenzen verschieden sein.
Aber egal, ich verwende eh die Modbuswerte

[Bogenhaus]

Tico
weißt du über welches ModBus Register man die Fronius Fehlercodes auslesen kann ?

Bin gerade dabei den Baustein EnergieMonitor zu eliminieren (gibt irgendwie keinen Sinn mehr wenn man den Energieflussmonitor auch nutzt).

Ich hab alle Werte nun per Modus wie z.B. StVnd als Status statt Ausgang Sci.
Nun suche ich was ich statt dem Ausgang Eci verwenden kann.

Derzeit so ausgewertet


Dank schon mal

[Tico]

Soviel ich weiß, gibt es kein Modbus-Register für Fehlercodes. Das nächstgelegene, das ich habe, ist der StVnd-Eintrag. Diese Liste für den Symo Hybrid ist möglicherweise nicht auf den Gen24 anwendbar.

[Bogenhaus]

Danke dir,
mindestens die Werte bis 8 passen - hab ich in Doku gefunden.
Bei Status Fault wird auf Register Evt verwiesen , die gibt es ja - mal nachsehen was da ankommt
letztlich ja auch nicht so wichtig das Loxone den Fehler genau anzeigt

[Bogenhaus]

Hallo

noch ergänzend die Rückmeldung von Fronius zu Status und Fehlercodes am SymoGen24 über Modbus

Fragestellung an Fronius
:

Antwort von Fronius

[Bogenhaus]

Hi Tico

funktioniert das mit den Werten über Modus wirklich fehlerfrei bei dir ?

Ich denke ich habe grundsätzlich das System verstanden - auch dein Wiki dazu studiert und ähnlich umgesetzt.

Allerdings habe ich bei den Leistungswerten sporadisch für einen Lesezyklus einfach Fehler
Ich schreibe die gelesenen Rohwerte direkt per HTTP Ausgang in eine Influx DB . dazu der Screenshot der 3 aktiven DC Leistungswerte und dem Scale Faktor.
Aktuell lese ich mit 10s Abfrage Intervall

Wie du sehen kannst ist für einen Abfragezyklus der Wert DCW2 (Fronius Register 40305) um Faktor 10 größer - der Skale Factor unverändert - auch die anderen Werte fast unverändert.


Ich lese in Summe 24 Werte vom Modus, eine Lesezyklus der 24 Wert dauert aktuell ca. 4.8s , Timeout steht auf 1000ms
Nachtrag : hab grad den Miniserver neu geladen, jetzt ist der Zyklus in 200ms durch ?! (so flott hatte ich es zuletzt eigentlich auch beobachtet)

Ich gehe davon aus dass ich alle Werte auch empfange - sonst würde der HTTP Ausgang nicht getriggert werden

um solche Fälle auszufiltern fehlt mir auch die Idee - bei den Leitungen wäre es mir ja noch irgendwie egal - aber wenn das bei den Zählerständen passiert sind die Loxone Energiezähler ja beleidigt was ich echt nicht brauchen kann


Aktuell von heute morgen - um 06:16:43 machte DCW2 einen Sprung von 609 auf 5712. DCW1 blieb unverändert,
erst um 6:16:53 (nächster Abfragezyklus) änderte sich auch DCW1 von 6530 auf 65019 und DCW_SF von -1 auf -2


als das ganze wieder retour ging hat es gepasst


Anmerkung - Grafana zeigt beim SF immer nur einen Punkt weil in dieser Auflösung kein anderer Datenpunkt vorkommt



Danke für deine / eure Tips

[Bogenhaus]

Noch ergänzend
aus dem Monitor ein aktuelles Screenshot (werden diesen heute dauernd laufen lassen um hoffentlich auch einen Fehlerfall im Monitor zu haben
auffällig - das Timing hat sich wieder verändert von gestern 21 Uhr auf Heute ist eine Afragedurchlauf deutlich langsamer geworden -ohne jegliche Änderungen in der Config




Timeouts finde ich im Debug Monitor keine aber dennoch eigenartiges - kommt unregelmäßig immer wieder mal SEQ_ERROR