Fronius per inoffizieller API auf MQTT auslesen

[AlexAn]

Das ganze ist keine offizielle API und kann sich jederzeit ändern!

Per Loxberry XL
LoxBerry XL - Beispiele - LoxBerry - LoxWiki (atlassian.net)

#!/usr/bin/env php

<?php
require_once "loxberry_XL.php";
$mqtt->publish( "Fronius", file_get_contents( "http://IPvomWR/components/readable" ) );

oder noch einfacher regelmäßig per MQTT senden

UDP Transformer - http2mqtt (shipped) - LoxBerry - LoxWiki (atlassian.net)

publish http2mqtt Fronius http://IPvomWR/components/readable


Auszug der Ausgabe:





Falls es nicht gleich klappt dann einfach dem Loxberry etwas Zeit lassen!

[Christian Fenzl]

Sehr cool!

[Tico]

AlexAn - Danke für den Beitrag. Ich wusste nicht, dass es den Aufruf "components/readable" gibt.

Ich möchte mein Verständnis der relativen Vorteile dieser Methode gegenüber der aktuellen Methode (Fronius Push via FTP zu NodeRed, NodeRed zu MQTT) klären -

1. Wegfall von zwei Push-Diensten (Aktuelle Daten - Speicher, Aktuelle Daten - Powerflow),
2. Aufhebung der Begrenzung des Fronius Push Service Intervalls auf 10 Sekunden.
3. Sonst noch etwas?

Gibt es einen Unterschied in der Ressourcennutzung auf dem Loxberry zwischen Loxberry XL und UDP Transformer?

[AlexAn]

Der Loxbery wird da ziemlich geflutet also Filtern!
Geht um die 4 Lastmanagement Relais da anscheinend der Gen24 keinen Push Service hat.
Alternative wäre den zukünftige Shelly i4DC oder 2xUni direkt an die Relais des WR zu hängen.

Keine Ahnung ob der kleine "Hack" dauerhaft eine Lösung sein wird.
Zu den Ressourcen müsste Christian Fenzl was sagen können.

Die Befehlserkennung kann man natürlich auch bauen aber wie unten in der Ausgabe steht kann sich der Seitenaufbau bei jedem Update ändern.

[Tico]

Ich wollte schon seit einiger Zeit den Gesundheitszustand meiner Fronius-Batterie ermitteln. Ich sehe, dass es im Aufruf /components/readable zwei Werte gibt -

a. "Estimated_Capacity_Maximum"
b. "Estimated_Capacity_Remaining"

Ich habe drei Fronius-Solarbatterien, auf die ich mich beziehen kann, und "Estimated_Capacity_Maximum" unterscheidet sich je nach Alter.

Die Werte von geschätzte Kapazität beziehen sich auf Watt-Stunden. "Estimated_Capacity_Remaining" als Anteil von "Estimated_Capacity_Maximum" ergibt einen Prozentwert. Dieser stimmt immer mit dem Ladezustand (State of Charge, SoC) überein.

Es kann angenommen werden, dass "Estimated_Capacity_Maximum" als Anteil der ursprünglichen Kapazität einen Gesundheitszustand der Batterie (SoH) ergeben sollte. Ich gehe davon aus, dass 9600 Wattstunden der ursprüngliche Wert ist, weil die Fronius-Spezifikationen die Kapazität der Batterie im Neuzustand mit 1200 Wattstunden pro Modul angeben, d. h. 8 x 1200 = 9600.

Bei den drei Fronius-Batterien, die ich mir angeschaut habe, habe ich drei SoH-Werte berechnet.

Batterie 1 (259 Zyklen) - SoH = 98,2%
Batterie 2 (674 Zyklen) - SoH = 96,1%
Batterie 3 (681 Zyklen) - SoH = 96,0%

Ich weiß nicht, ob es sich bei "Estimated_Capacity_Maximum" einfach um eine Nachschlagetabelle handelt, die die geschätzte Kapazität auf der Grundlage von Zyklen festlegt. Es gibt eine weitere Metrik im Aufruf /components/readable, die "RelativeBatteryAge_Cycles" enthält.

Es wäre interessant zu sehen, ob andere Leute konsistente SoH im Vergleich zu "RelativeBatteryAge_Cycles" haben.

[Klartext]

Habe mich gewundert warum viele Daten wie die Wattzahlen der einzelnen Strings nicht mehr ankommen, der Grund war das ich eine bestehende Modbus Verbindung zum Fronius die ich eigentlich nicht nutze gelöscht habe, dadurch sind einige Werte aus der API rausgefallen die sie anscheinend nur für die Modbusverbindung verarbeitet

Nur zur Info