HASS Homeassistant Umrechnung Modbus mit Scale-Factor

[tsb2001]

Hallo zusammen,
ich lese seit geraumer Zeit den Fronius Wechselrichter über Modbus TCP mittels Homeassistant aus und schreibe die in Teilen auf den KNX (hauptsächlich der Füllstand vom Akku und der momentane Ertrag), damit man abschätzen kann, ob die Waschmaschine mit Überschuss geladen werden kann und der Akku trotzdem nicht entladen wird, da noch genug Sonneneinstrahlung vorhanden ist.

Funktioniert seit 3 Jahren eigentlich gut. Eigentlich weil...
...die Werte springen:
Ich hole mir vom Wechselrichter die Werte nach folgendem Schema:

Hier verbirgt sich die Leistung vom DC-Strang 1 als Rohwert ohne den Skalierungsfaktor (String 2 funktioniert genauso)

    - name: PV_GEN24_W_DC_1_RAW
      slave: 1
      # count: 1
      data_type: uint16
      address: 40284
      scan_interval: 10​

Um den Wert richtig zu berechnen, skaliert sich der Wert je nach Leistung vom Dach mit einem Scalefactor und versetzt das Komma.
Den lese ich im vorher aus:

    - name: PV_GEN24_DCW_SF
      slave: 1
      # count: 1
      data_type: int16
      address: 40267
      scan_interval: 10

Um nun das ganze als richtigen Wert zu bekommen, Multipliziere ich den Messwert mit dem Scaltefactor:

  # Generatorfeld 1
  - name: "PV_GEN24_W_DC_1"
    unique_id: f63974e7-2db6-4af4-926b-b13627f9e74b
    unit_of_measurement: W
    device_class: power
    state: "{{ max(0, (((states('sensor.PV_GEN24_W_DC_1_RAW') | int) * (10 ** (states('sensor.PV_GEN24_DCW_SF')) | int))) | round(0) ) }}"​

Jetzt passiert folgendes (einfache Beispielwerte):

• der Wert PV_GEN24_W_DC_1 beträgt 900 Watt
• der Scalefactor PV_GEN24_DCW_SF ist 1
• ergibt in der Ausgabe 900W

soweit richtig:

• die Sonne wird intensiver (kommt grade hinter einer Wolke hervor) und der Messwert PV_GEN24_W_DC_1 beträgt 580 Watt
• der Scalefactor PV_GEN24_DCW_SF wechselt auf 10
• sollte unmittelbar einen Wert von 5800W geben

Genau dann springt die Anzeige.
Der Messewert wird auf 580W gesetzt, dann wird der Scalefactor neu eingelesen und dann der korrigierte Wert mit 5800 Watt ausgegeben.

Je nach Sprunghaftigkeit der Sonneneinstrahlung liefert meine PV mit maximal 12kW plötzlich 60.000 Watt, bis der Scalefactor den wert auf 6.000 Watt oder gar 600 Watt korrigiert.

Nun meine Frage:
Wie kann ich sicherstellen, dass der Wert immer erst berechnet wird, wenn BEIDE Werte eingelesen sind und erst DANN folgt die Berechnung?

[SvenB]

Da bin ich noch nicht. Aber wieso nimmst du nicht das Fronius-Integration von HASS?

[sewi]

Naja, selbst wenn ich das programmieren würde, müsstest du da wahrscheinlich irgendwie von einer zeitlichen Nähe der Werte ausgehen?

Weil die beiden Werte sind ja immer definiert, nur möglicherweise halt vom letzten Senden. In NR (was eben nicht HASS ist) würd ich einfach jeweils den Wert mit Zeitstempel speichern, dann gleich prüfen, ob beide Werte da sind, und wenn ja, umrechnen und weiterleiten.

Klar, ist NR, aber vielleicht geht's in HASS ähnlich?

[d0m]

Hallo zusammen,

ein typisches Problem bei variablen Skalierungsfaktoren. Das richtige Werkzeug heißt multiread mit direkter / synchronisierter Auswertung, damit keine alten Werte verrechnet werden.

Ein Feature was unser neues Modbus RTU Gateway (SCN-MBGRTU.01) unterstützt. Dafür muss die kanalübergreifende Arithmetik mit multiread Leseanfrage verwendet werden. Die TCP Variante wird für Funktion ebenfalls haben.

Beste Grüße
Dominik

[tsb2001]

Da bin ich noch nicht. Aber wieso nimmst du nicht das Fronius-Integration von HASS?

Weil du über Modbus wesentlich mehr Werte zur Verfügung gestellt bekommst und auch schreibend drauf zugreifen kannst.

Das richtige Werkzeug heißt multiread mit direkter / synchronisierter Auswertung, damit keine alten Werte verrechnet werden.

Eigentlich braucht s das gar nicht. Bei einer SPS werden zum Beispiel erst alle Werte eingelesen, dann erfolgt die Verarbeitung und dann die Ausgabe.
Da würde dann beispielsweise die Modbus-Register 40284 und 40267 hintereinander gelesen, dann gerechnet und danach ausgegeben.

Hier triggert jedoch jede Änderung bei beiden Modbus-Registern die Rechnung erneut an. Dadurch kommen dieses unsinnige Ergebnis heraus.

Und da wäre nun die Frage: wie lese ich erst die Modbus-Register aus und rechne dann einmalig alles durch; und das zyklisch?

Ablauf:

• Lese Register 40284
• Lese Register 40267
• Rechne Inhalt vom Register 40284 mit dem Zehner-Exponent vom Register 40267

Dann wäre nur die Unschärfe, wenn sich exakt in dem Augenblick der ScaleFactor ändert, wenn der Abgefragt wird und sich auf einem ganz knapp älteren Wert der Leistung bezieht, der sich ebenfalls verändert.
Das lässt sich aber bei einer seriellen Datenabfrage nie ganz ausschließen; ist aber zu verkraften.
Zumal über TCP die Abfrage so schnell ist, dass das kaum ins Gewicht fallen würde.

[gbglace]

Sequenzielles Lesen und dann wirklich erst auswerten hilft bei den Fronius Dingern auch nicht immer. Denn selbst in den ms zwischen den Einzelnen Leseanfragen springen da immer mal die Werte zueinander.

[sewi]

d0m von eurem Modbus Gateway fehlen aber noch die Downloads, hätte ich mir gerne angeschaut (auch wenn ich keinen unmittelbaren Bedarf habe, weil derzeit ich derzeit ein Weinzerl Gateway einsetze ... aber für's nächste Mal)

[meti]

Aber wieso nimmst du nicht das Fronius-Integration von HASS?




Weil du über Modbus wesentlich mehr Werte zur Verfügung gestellt bekommst und auch schreibend drauf zugreifen kannst.

Benutz halt beides - jeweils das geeignetere für den Zweck.

Oder halt die Float Register statt Int+Sf - da hast das Problem nicht.

[tsb2001]

Oder halt die Float Register statt Int+Sf - da hast das Problem nicht.

Mache ich ja.
Aber leider spielt Fronius nicht alle Daten als Float aus.
Die AC-Werte kannst du alle über Float auslesen, den DC-Bereich gibts nur als Int+Sf.

Gibt ja 2 unterschiedliche Tabellen. Einmal reines Int+Sf und einmal Float und Int+Sf.
Was die sich dabei gedacht haben - keine Ahnung. Komplett mit Float wäre es wesentlich einfacher.

[SvenB]

Es hilft hier nur wenn man 250 Register am Stück liest und auswertet. Dann sind (eigentlich) Sprünge beim lesen selber ausgeschlossen. Das die Auswertung selber am Stück erfolgt muss man im Plugin sicherstellen. Ich hab das im Kostal KSEM Plugin gemacht. Beim WR verbietet Kostal das Lesen von nicht benutzten Registern.

Ist der Code vom Fronius Plugin bei HASS nicht verfügbar? Einer erweitern, PR stellen und sich selber ne Version bauen.

@MDT: Hilft hier ein RTU Gerät bei der Auswertung von Modbus TCP?

[tsb2001]

Ein Feature was unser neues Modbus RTU Gateway (SCN-MBGRTU.01) unterstützt.

Nice try, aber...
...ich brauche drei Daten auf dem Bus, hole aber 30 Daten zu Statistikzwecken über Modbus TCP vom Wechselrichter ab, um die dann in die Influx-DB zu schreiben und mittels Grafana auszuwerten.

Bei einer Abfrage von 30 Daten über euer Gateway würde ich dann bei 10-Sekunden-Intervallen 6 mal pro Minuten den Bus mit Telegrammen fluten, die mir ohnehin über IP bereitgestellt werden, die dann über den Flaschenhals KNX mit lahmen 9600 Bits übertragen werden, um dann wiederum im IP-Interface auf IP umgewandelt werden, um zuletzt an den Homeassistant weitergeleitet zu werden.

Wäre irgendwie so, als würde man bei einer 5-spurige Autobahn einen einspurigen Tunnel bauen...

Ist der Code vom Fronius Plugin bei HASS nicht verfügbar?

Nee - direkt gibt's da leider nichts. Es gibt da aber im HACS das Plugin SunSpec.
Da SunSpec grundsätzlich mit Int+Sf agiert; werde ich mal gucken, wie da die Werte umgesetzt werden...

[tsb2001]

Einer erweitern, PR stellen und sich selber ne Version bauen.

Geht viel einfacher:
SunSpec als HACS hinzugefügt, der erkennt automatisch alle Werte, unabhängig ob Float oder Int+Sf.
doppelt konfiguriert:

• einmal auf die IP mit dem Slave auf ID 1 (Wechselrichter)
• zweite auf die IP mit dem Slave auf ID 200 (Smartmeter (das überträgt nur Float-Werte, ist dem Plugin aber egal - das kann das auch))

Sieht so aus:
...daher erledigt...
image.png

Jetzt muss ich nur noch die ganzen Entitäten anpassen, damit ich die Werte auch wieder sehe / mitschreibe...

[SvenB]

Sehr schön. Der Sunspec Standard ist leider sehr komplex dokumentiert. Hatte es mal versucht aber abgebrochen. Toll das es jemand (oder Sunspec selber) gemacht hat.

[tsb2001]

SvenB und meti

Was mich halt an der Lösung mit der API gestört hat:
Der Wechselrichter hat intern Zähler für alle DC-Strings (der GEN24 von Fronius hat 2 für die Strings, 1 zum Entladen und 1 zum Laden des Akkus) und für den AC-Output. Also alles wird hardwareseitig gezählt

Über die API bekomme ich davon überhaupt keine Werte; die werden schlichtweg nicht zur Verfügung gestellt.
Daher wäre ich genötigt, für das Energiedashboard mittels dem Riemann-Summenintegralsensor die Leistung in die Zeit zu integrieren, um vom Wechselrichter überhaupt eine Wirkarbeit zu bekommen.
Die kommen aber nur alle 10 bis 15 Sekunden. Das bedeutet: der Wert den ich jetzt grade habe bleibt für diese Zeit konstant, egal was die Sonneneinstrahlung, der Eigenverbrauch oder sonst was die Wirkleistung ändert.

Das habe ich am Anfang so gebaut - der Drift nach einigen Monaten waren nicht nur ein paar Kilowattstunden; sondern das ging völlig am Ziel vorbei.
Insbesondere wenn ich meinem NAS ne neue Firmware aufgespielt habe und das Ding daher über eine Stunden offline war. Keine Riemann-Rechnerei, da keine Werte vorhanden waren, obwohl die Hardware des Wechselrichters diese "richtigen" Zähler mitbringt.

Mit Modbus bisher kein Problem; bis auf die Ausreißer durch den Scalefaktor.
Das ist nun Geschichte; der zählt richtig (wie vorher) und die Sprünge sind weg. Sieht man grade gut an solchen wechselhaften tagen wie heute, wo sich die Leistung sprunghaft ändert.

Denn selbst in den ms zwischen den Einzelnen Leseanfragen springen da immer mal die Werte zueinander.

Bei mir jetzt nicht mehr...

[gbglace]

Gut zu wissen. Einen Fronius werde ich auch noch installieren der wird aber als reiner AC WR agieren und die Victrons können wohl auch nativ deren Modbus entschlüsseln. Muss ich dann nur sehen wer mir da am besten die Werte liefert, ob ich das noch irgendwie separat aus dem Fronius hole oder es per MQTT aus dem Victron rausbekommen.