Closed muexxl closed 1 hour ago
Ich habe FW 1.34.2-1 am laufen und da funkt es einwandfrei, ich kann daher nicht testen.
Was bekommst du von deinem WR zurück?
Hab es gerade mit der anderen von dir in https://github.com/muexxl/batcontrol/pull/29#issuecomment-2453554448 erwähnten URI probiert, hier bekomme ich den Error:
RuntimeError: [Inverter] Request failed with 400-Bad Request. url:http://192.168.1.18/config/setup/powerunit,
Nehme mal an da haben sie etwas im Sprung von der 1.2x auf die 1.3x verändert.
@muexxl gibt's die Firmware version von ner URI?
@muexxl mach einen try block, wahrscheinlich die beste option
in GET /status/version gibt es swrevisions.GEN24 oder und ein Array apiversions ..
da es -bisher- nur der eine call ist könnte man ganz pragmatisch auch config/powerunit callen und falls es einen 400er response code gibt die legacy uri config/setup/powerunit probieren.
hab jetzt auch den WR geupdated und es funktioniert wieder. Wir sollten das aber auf jeden Fall fixen, damit auch die 1.2.xer Versionen noch unterstützt werden. Das ist halt der sh** wenn man undokumentierte APIs reengineert ..
da es -bisher- nur der eine call ist könnte man ganz pragmatisch auch config/powerunit callen und falls es einen 400er response code gibt die legacy uri config/setup/powerunit probieren.
Genau das meinte ich mit dem try block. Funken beide nicht, kann man als exception einfach min_soc nehmen, dann läuft es wenigstens nicht schlechter als vorher.
Zu den Welser IT-Künsten sag ich jetzt mal nix 😝
Die Solar-API scheint zumindest dokumentiert. https://www.fronius.com/~/downloads/Solar%20Energy/Operating%20Instructions/42,0410,2012.pdf
Aber es scheint wir nutzen eine andere.
Wollte es nur mal teilen.
"Wir nutzen eine andere" -> kann man so sagen :D.
Ich habe mir halt die Kommunikation vom WebUI mit dem Backend angeschaut und dann re-engineered. Die SolarAPI von Fronius kann man nur nutzen um Parameter auszulesen, aber nicht um Werte zu setzen. Von daher ist es für mich ok, wenn Fronius die nach gusto ändert. Ist ja nichts offiziell unterstütztes.
Später habe ich dann erfahren, dass es wohl auch eine elegantere Möglichkeit via Modbus TCP gibt.
Wobei Modbus TCP eigene Probleme hat...
Auch wenn es nicht direkt hier reingehört: Wir sollten uns angewöhnen solche grundlegenden Changes mit einem Featuer-Flag erst zu versehen, dass die Applikation wenigstens lauffähig bleibt.
Man sollte die get und push requests inkl. exception handler bauen. Besonders bei "undokumentierten" APIs, dann wäre es wenigstens etwas stabiler.
Die breaking changes können ja vonseiten der FW bzw. dieser repo sein. Das kann man idR. vorher nicht wissen und man hat meist nur eine FW Version um das im lokalen Netzwerk zu testen.
Schwierig. Du kannst mit der gefangenen Exception unter Umständen auch nichts anfangen. Gerade wenn du bei der Initialisierung bist, dann ist Ende, weil du keine Daten bekommst.
"Unterwegs" kann man das machen. Da könnte man zurückfallen in die Verarbeitungsschleife und nach 2 Minuten es erneut versuchen (z.B. WR Restart). Da wäre sogar das Beenden vom batcontrol kontraproduktiv, weil das Einspielen der alten Konfiguration fehlschlagen würde.
Man müsste das mal durchdenken. Nicht nur bei WR Neustart sondern auch beim Wechsel in den Backup Modus.
@johannesghd Kannst du dir die version auf dem Branch issue-32 bitte anschauen? Damit sollte es ja tun.
Merged into Release-0.2.11 branch for testing
Linked to PR29 https://github.com/muexxl/batcontrol/pull/29
Der Wechselrichter antwortet mit "Bad Request" offenbar stimmt etwas mit der API Abfrage nicht.
EDIT: FW 1.28.7-1