photron

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

Where do you get this message? Could you please show the full output of the command "systemctl status brickd", the command "uname -a", the command "gpioinfo" and attach the /var/log/brickd.log file from your Raspberry Pi?

Euler angles are problematic, as you already found out. The IMU Bricklet also provides the oriantation in form of a quaternion and Wikipedia explains how to convert a quaternion into a rotation matrix: https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Quaternion-derived_rotation_matrix

Wir haben das bei @COW getestet und es gab bis einschlieslich WARP2 Firmware 2.4.1 einen Fehler in der Prüfung, der dazu geführt hat, dass die Prüfung als okay betrachtet wurde und dann die Firmware eingespielt wurde, obwohl es nicht erlaubt gewesen wäre. Diese Problem ist mit den aktuellen Firmware-Version (u.a. WARP2 Firmware 2.5.0) behoben und Firmware-Updates werden im Falle eines angeschlossenen Fahrzeugs zuverlässig verweigert.

Mit welchem Browser hast du das hinbeommen? Ja, das ist kein Problem.

Ich habe das gerade getestet und es funktoniert wie es soll in Chrome 128 und Firefox 129 auf Linux. Auf der Firmware-Aktuali­sierung-Seite wird die manuelle Aktualisierung verweigert, wenn ein Auto angeschlossen ist. Ich kann das klicken was ich will. Auf der Recovery-Seite darf man flashen auch wenn Auto angeschlossen ist. Über die Recovery-Seite reden wir hier aber nicht, richtig? @COW und @wuesten_fuchs: Könnt ihr mir bitte einmal genauer erklären was ihr tut, um die Prüfung zu umgehen?

Sorry, das soll so nicht funktionieren, das ist ein Bug. Von welcher Firmware-Version aus hast du das Update gemacht? Also welche Fmware-Version hat dieses Verhalten zugelassen?

Ohne Vorzeichen muss du "Bezug plus Einspeisung" wählen. Darauf kann das dynamische Lastmanagement abr nicht regeln. Wir brauchen den gerichteten Phasenstrom. Kann der Zähler andere Werte liefern an denen ersichtlich ist, ob gerade bezogen oder eingespeist wird?

Im Moment gibt es da noch nichts für. Das ist ein offenes TODO: https://github.com/Tinkerforge/esp32-firmware/issues/47

Die Sortierung in beiden Screenshots ist richtig. Du hast im ersten Screenshot die Sortigung auf "nach Position absteigend" gestellt und im zweiten auf "nach Position aufsteigend". Falls das nicht absi chtlich ist, dann hast du aus Versehen auf den "Position" Eintrag geklickt und dadurch die Sortierung umgestellt. Bleibt die Frage, warum der 3.2er Master Brick oben auf dem Stack seine Bricklets nicht meldet. Kannst du einmal zeigen wie der funktionierende Fall mit Master Brick 3.2 alleine oder unten im Stack in Brick Viewer aussieht?

brickd 2.4.7 is now available from our APT server.

brickd 2.4.7 is now available from our APT server.

Brick Daemon 2.4.7 Fix Raspberry Pi 1-4 SPI backend detection, this makes a HAT (Zero) Brick work with a Raspberry Pi 1-4 again Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Brick Daemon 2.4.7 Raspberry Pi 1-4 SPI Backend-Erkennung repariert, damit funktioniert jetzt der HAT (Zero) Brick mit einem Raspberry Pi 1-4 wieder Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Dafür mustest du im Brick Viewer localhost zum Hostnamen oder der IP-Adresse des ESP32 Ethernet Brick ändern. Das musst du auch beim Aufruf von tinkerforge_mqtt machen. Du hast dort --ipcon-host localhost stehen, dort musst du localhost auch zum Hostnamen oder der IP-Adresse des ESP32 Ethernet Brick ändern.

Please try the attached brickd version: sudo dpkg -i brickd_2.4.7_armhf.deb brickd_2.4.7_armhf.deb brickd_2.4.7_arm64.deb

Bis zum nächsten Update haben wir eine dauerhafte Lösung. Bis dahin kannst du diese Firmware installiert lassen. Das mit dem höheren Datenrate beim Laden ist jetzt eine Idee warum das nur beim Laden passiert. Du hast im Log auch Fälle wie diesen. Da ist vermutlich die CONNACK-Antwort von Mosquitto für den Verbindungsversuch der Wallbox nicht schnell genug bei der Wallbox angekommen. Darauf hin hat die Wallbox die Verbindung geschlossen, ohne das irgendetwas anderes gesendet würde. 2024-07-09T20:48:38: New client connected from 192.168.178.95:51682 as warp2-292u (p2, c1, k120). 2024-07-09T20:48:38: Sending CONNACK to warp2-292u (0, 0) 2024-07-09T20:48:38: Client warp2-292u closed its connection. Dann hast du Meldungen wie diese: 2024-07-10 15:06:23,309 | wifi | Disconnected from SBCH: Reception too poor (200). Was connected for 9335 seconds. Wobei im Log aber auch steht, dass der RSSI Wert -64 wäre, was nicht super ist, aber ach nicht absolute schlecht. Es scheint mir du hast da irgendwie WLAN Problem, bzw die Wallbox hat WLAN Probleme. Wie lange hast du die Wallbox schon? Hat die da ohne Probleme zuvor Monate gelaufen und plötzlich treten diese Probleme auf? Wie ist die Wallbox angebracht? Hängt die draußen im Wetter? Ist der Deckel ordentlich dicht verschraubt? Kannst vielleicht du Fotos machen, damit wir uns eine Bild von der Lange machen können? Worauf ich hinaus will, wenn das vorher Monate lange ohne Probleme gelaufen hat und dein WLAN sonst gut funktioniert, auch an der Stelle an der die Wallbox hängt, dann könnte das vielleicht auch ein Hardware-Schaden sein.

Ein längerer Timeout bedeutet langsamere Reaktion in Fehlerfall. Wenn du kein Auto lädst ändern sich die Zählerwerte kaum und die Messwerte werden seltener über MQTT geschickt, da diese nur bei Änderung gesendet werden. Vermutlich schafft dein WLAN gerade so den Durchsatz, dass die Daten im Ruhezustand schnell genug ankommen. Wenn jetzt aber mehr Daten gesendet werden müssen, dann reicht der Durchsatz deines WLANs nicht mehr, um alle Daten schnell genug rauszubekommen und unser MQTT Client läuft in den Timeout. Das würde auch dazu passen, dass du Probleme beim Laden des Webinterfaces der Wallbox hast. Ich vermute, dass diese Probleme auch jetzt noch da sind, während die MQTT Verbindung der Wallbox bei längerem Timeout jetzt stabil ist. Ich vermute weiterhin ein Problem mit deinem WLAN, dass dazu führte, dass sich MQTT bei uns nicht gut verhalten hat.

Sendeinterval und der Timeout haben nichts mit einander zu tun. Bitte das Sendeintervall auf 1 Sekunde lassen.