photron

Danke fürs Testen. @OpiFS Die Änderung wird dann Teil der nächsten Firmware-Version, bis dahin kannst du bei der Test-Version bleiben.

Okay, Problem gefunden. Fronius hat zwei leicht verschiedene Registersätze. Bei @pene8 und @Steff49 ist es der eine und bei @OpiFS der andere. Die angehängte Firmware erkennt jetzt automatisch welcher von beiden es ist. Könntet ihr drei das bitte testen? warp3_firmware_2_6_6_6762a913_4b6d1d017fe4b8b_merged.bin

Ich habe das Problem gefunden. Du hattest vorher eine Test-Firmware für die Fronius GEN24 Plus Batterie-Unterstützung laufen. Dort war der virtuelle Zähler für die Batterie die ID 1. In 2.6.6 ist es jetzt aber die 3. ID 1 ist gerade unbenutzt und für zukünftige Verwendung reserviert. Dadurch hast du jetzt eine ungültige Config. Das ist erstmal kein Problem. Dafür bekommst du die Meldung "Invalid Fronius GEN24 Plus Hybrid Inverter Virtual Meter: 1". Damit sollte alles gut sein. Aber durch einen Bug führt diese ungültige Config jetzt zu einem Crash. Lösung: Der Crash tritt auf sobald sich die Wallbox zu deinem Wechselrichter verbindet. Am einfachsten ziehst du das Netzwerkkabel von der Wallbox ab, dadurch unterbindet du die Verbindung der Wallbox zum Wechselrichter. Jetzt sollte die Wallbox durchlaufen und stellt dann fest, dass keine Netzwerkverbidung besteht und aktiviert den Access Point. Über den Access Point löscht du den Fronius GEN24 Plus Zähler und richtest diesen neu ein, dadurch wird dieser dann mit der richtigen ID angelegt. Danach kannst du das Netzwerkkabel wieder einstecken und das Problem sollte behoben sein.

Wenn das Webinterface nicht funkitoniert, wie lädst du dann den Debug Report runter? Die Wallbox scheint immer nach "Network connected (Ethernet)" zu crashen. Leider fehlt im Debug Report der Coredump, der zeigen würde wo der Crash ist. Kannst du versuchen nur den Coredump von der Wallbox herunterzuladen: http://192.168.178.163/coredump/coredump.elf

Das sieht so aus, als wäre die Skalierung der Werte falsch. Spiel bitte mal diese Firmware ein. Diese gibt mehr Details im Log aus. Das ganze einen Moment laufen lassen, dann unter System -> Ereignis-Log einen Debug Report speichern und hier anhängen. warp3_firmware_2_6_6_67603904_d59739d4655f7bc_merged.bin

Das Problem ist mit Firmware 2.6.5 behoben.

Der Source Code von Github heruntergeladen ist nicht direkt lauffähig. Du musst zuerst build_src.py ausführen. Siehe: https://github.com/Tinkerforge/brickv?tab=readme-ov-file#running-the-source-code-instead-of-using-prebuild-installerpackage

Die 4 kW Schwelle hat nichts damit zu tun woher der Strom kommt. Unter 4 kW kann deine Wallbox keine Ladung beginnen. Angedacht ist schon, dass die Wallbox da zukünfig mehr kann. In der nächsten Firmware wird enthalten sein, dass wir mit einbeziehen wieviel der Speicher gerade lädt und du einstellen kannst, ob das Auto oder der Speicher bevorzugt landen sollen. Weitere Dinge werden kommen, eine genau Roadmap kann ich dir allerdings nicht geben. Momentan musst du solche komplexeren leider Regeln noch von Hand umsetzen. Wenn du in der Lage bist da selbst eine kleine Steuerung zu progammieren, dann steht dir über die API der Wallbox alles bereit was du dafür brauchst. Alternativ kannst du dir auch evcc.io anschauen, das kann mit unseren Wallboxen zusammenarbeiten.

Du hast die Wallbox fest dreiphasig ansgeschlossen. Dadurch liegt die minimale Leistung, die als Überschuss vorhanden sein muss, bevor eine Ladung beginnt, bei 4140 W (= 230 V * 6 A * 3 Phasen). Der Standard sieht das Minimum von 6 A vor und manche Autos (z.B. Renault Zoe) laden auch erst ordentlich ab ca. 9 A. Mit 2581 W bist du einfach nicht über der 4140 W Schwelle. Da hilft dann eine Phasenumschaltung, die du bei WARP2 mit einem WARP Energy Manager nachrüsten kannst und die bei WARP3 mit eingebaut ist. Dadurch kann die Wallbox dann bei Bedarf auf einphasig runterschalten und die minimal benötigte Überschussleistung sinkt auf 1380 W (= 230 V * 6 A * 1 Phase).

@Steff49 Wenn ich mich richtig erinner, hatten wie bei dir, das Problem, dass der Fernzugriff noch nie richtig funktioniert hat und wir noch nciht rausbekommen haben warum. Wende dich bitte mal an @ffreddow, der entwickelt den Fernzugriff.

Hast du im Header die SetOnLCD128x64 Funktion in einem "public slots:" Anschnitt stehen?

Sporadisch Timeouts sind kein generells Problem. Du siehst da so ein bis zwei Timeouts die Stunde. Dass du das mit mbpoll nicht siehts mag daran liegen, das du mit mbpoll anders liest als die Wallbox. Da du zwei Zähler eingerichtet hast laufen in der Wallbox zwei unabhängie Abfrageprozesse. Es kann jetzt passieren, dass der eine Prozess eine Anfrage schickt während eine andere Anfrage noch in Bearbeitung ist. Das kann (muss aber nicht) zu einem Timeout der zweiten Anfrage führen. In der Firmware, die dir rtrbt zum Testen gegeben hat wird noch die alte Modbus/TCP Bibliothek verwendet. Wir sind inzwischen auf eine neue Modbus/TCP Bibliothek gewechselt, die die Anfragen nacheinander schickt, um genau dieses Problem zu vermeiden. Die Timeout-Zeit haben wir auch generell von einer auf zwei Sekunden angehoben. Viel länger würde ich nicht erlauben wollen, da sonst die Reaktionszeit der Regelung leidet, wenn die Daten zu langsam kommen. Auch werden speziell Timeout-Fehler nicht mehr geloggt, da diese zu den erwarteten Fehler gehören und ansonsten, wie bei dir, das Log füllen, auch wenn sie nicht wirklich ein Problem darstellen. Stattdessen gibt es jetzt einen Fehlerzähler für Timeouts. Dieser wird demnächst auch im Webinterface einsehbar sein. Aktuell kannst du den Wert nur im Debug Report unter "meters/?/errors" sehen. Teste bitte die angehängte Firmware. Vom Log her hat der Netzanschlusszähler Messwerte. Ich denke nicht, dass dein Problem durch feghlende Messwerte verursacht wird. Aber da bin ich nicht der Experte. Da können dir MatzeTF und rtrbt weiterhelfen. warp3_firmware_2_6_1_672894bb_86cc8abf9083b19_merged.bin

@pene8 und @Steff49 kleine Frage. Welche Modus Geräteadesse habt ihr für den Fronius GEN24 Plus eingestellt in der Wallbox? 1 oder 200?

@Steff49 und @pene8 das sieht gut aus, danke!

@Steff49 und @pene8 seht ihr, dass die Speicherwerte folgende Kriterien erfüllen? Wenn der Speicher läde sollten Gleich­strom und Leistung positiv sein. Wenn der Speicher entlädt sollten Gleich­strom und Leistung negativ sein. Die geladene Energie sollte größer sein als die entladene Energie.

Das ist leider so erstmal absolut erwartetes Verhalten. Eine TCP/IP Verbindung wird nicht passive getrennt. Die Verbindung besteht so lange bis eine der beiden Seiten aktive die Verbinfung schließt. Trennen des Netzwerkkabels oder Abschalten einer Seite führt nicht dazu, dass die andere Seite die Verbindung für geschlossen hält. Dieser Fall lässt sich nur durch einen aktiven Heartbeat-Mechanismus lösen, den keines unserer API Bindings bisher untersützt, sorry. Die TCP/IP Verbindung kann erst als unterbrochen durch die API Bindings erkannt werden, wenn du nach dem Trennen der Stromversorgung die Stromversorgung wieder anschließt. Denn dann ist die Verbindung auf der Gegenseite geschlossen und die Gegenseite antwortet mit einem TCP/IP Reset auf eingehende Pakete. Vorher laufen die Pakete einfach ins Leere, was erlaubt ist in TCP/IP. Ich kann allerdings nicht nachstellen, dass Connected-Listener oder Autoreconnect notwendig wären. Folgendes Beispiel funktioniert, mit den beschriebenen Einschränkungen. import com.tinkerforge.IPConnection; public class DisconnectTest { private static final String HOST = "192.168.1.112"; private static final int PORT = 4223; public static void main(String args[]) throws Exception { IPConnection ipcon = new IPConnection(); ipcon.setTimeout(250); ipcon.setAutoReconnect(false); /*ipcon.addConnectedListener(new IPConnection.ConnectedListener() { public void connected(short connectReason) { System.out.println("" + System.currentTimeMillis() + " Connected " + connectReason); } });*/ ipcon.addDisconnectedListener(new IPConnection.DisconnectedListener() { public void disconnected(short disconnectReason) { System.out.println("" + System.currentTimeMillis() + " Disconnected " + disconnectReason); } }); ipcon.connect(HOST, PORT); System.out.println("" + System.currentTimeMillis() + " Press key to exit"); System.in.read(); ipcon.disconnect(); } }

Sehr gut, dann wird die Fronius Speicherunterstützung Teil des nächsten Firmware Release sein. Auto SOC auslesen benötigt ISO 15118, das benötigt einen größeren Schwung extra Hardware, die die Wallbox leider nicht hat. Du kannst den Umweg über die Cloud des Autoherstellers gehen um an den Auto SOC zu kommen. Das hat aber auch so seine Tücken. Das kannst du mit EVCC bewerkstelligen.

Bitte die angehängte Firmware testen. Ich bin zuversichtlich dass es jetzt funktioniert. Edit: Angehängte Firmware gelöscht. Diese Funktion ist schon Teil der offiziellen Firmware.

Okay, danke. Ich glaube ich habe die Verwirrung gelöst. Ich habe in Gen24_Primo_Symo_Inverter_Register_Map_Float_storage.xlsx geguckt. Dort sind die Register die uns interesieren um +10 verschoben, bedingt dadurch das einige Werte vorher in zwei statt in einem Register abgebildet werden. Dann kommt hinzu, dass im Dokument Registernummern (1-basiert) und nicht Registeraddressen (0-basiert) angegeben sind. Ich bestätige, ich komme jetzt auch auf Registeradresse 40351 für State of Charge ist.

Die Werte sind ja mal völlig daneben. Ich denke die Dokumentation über die Registermap die ich verwendet habe passt nicht. @pene8 Woher hast du dass Register 40351 State of Charge ist? Das ist laut Dokumentation die ich habe etwas völlig anderes.

Interessant. Das ChaState_SF darf wohl nicht gelsen werden. Dort steht der Skalierfaktor für den ChaState Wert (State of Charge) des Speichers drin. Die Dokumentation sagt, dass der fest -2 (also 0,01) ist. Ich habe aber versucht den Wert trotzdem zu lesen. Das habe ich jetzt geändert und nehme fest -2 an. Bitte die angehängte Firmware testen. Die Einstellungen können so belassen werden. Nur die Firmware fachen und schauen, ob es dann geht. EDIT: Fehlerhafte Firmware gelöscht, neue Firmware in meinem nächsten Post.

Fronius meldet die Speicherwerte nicht direkt über SunSpec, sondern missbraucht dafür MPP Tracker 3 und 4 im SunSpec Modell 160. Für den Moment hier erstmal eine Firmware mit Support für den Fronius GEN24 Plus Speicher. Das ist absolut ungetestet. Im schlimmsten Fall funktioniert es einfach nicht. Vor dem Update die Batteriespeicher-Option auf "Kein Batteriespeicher" stellen und speichern, soll ich von MatzeTF ausrichten. Danach dann den neuen Zähler einrichten und auswählen. Für den neuen Zähler als Klasse Modbus/TCP wählen, Anzeigename und Host eintragen, Port auf 502 belassen, als Registertabelle Fronius GEN24 Plus Hybrid-Wechselrichter wählen, als Vir­tu­eller Zähler Speicher wählen und Geräte­adresse auf 1 belassen. Dann Hinzufügen, Speichern und Neustarten klicken. Im besten Fall funktioniert das einfach so und die Messwerte für den Speicher werden angezeigt. EDIT: Fehlerhafte Firmware gelöscht, neue Firmware in meinem nächsten Post.

@TobiSt Teste bitte die angehängte Version. dbus-warp-charger.py

Schau bitte mal, ob du die neuste Firmware Version 2.0.4 auf dem HAT Brick hast, und ob du die neuste brickd Version 2.4.7 laufen hast.

Laut Datenblatt ist der E38S6G5-600B-G24N ein Quadraturencoder, der mit bis zu 24V arbeiten kann. Dafür ist unser Industrial Counter Bricklet bestens geeignet: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Industrial_Counter.html#quadraturencoder-inkrementalgeber