photron

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.

Danke für die Logs. Wir setzen den Timeout für unseren MQTT Client auf eine Sekunde. Wir vermuten, dass das deinem Setup zu gering ist. Teste mal bitte die angehängte Firmware mit 10 Sekunden MQTT Timeout. warp2_firmware_2_4_0_668e5d3f_4c292c70ca8e3ef_merged.bin

Das ist eher kein EVCC-Problem, sondern eher ein WLAN-Empfangsproblem. Hast du auch Probleme mit der Erreichbarkeit des Webinterfaces der Wallbox? Teste bitte mal, ob es hilft die WLAN-Empfangs­opti­mierung auf der Wallbox zu aktivieren unter: Netzwerk > WLAN-Verbindung > Empfangs­opti­mierung Leider geht aus dem Log nicht hervor warum die MQTT-Verbindung verloren geht. Du kannst für Mosquitto das Logging auf Maximum stellen, dann sollte im Mosquitto Log etwas dazu stehen. Dazu am Ende von /etc/mosquitto/mosquitto.conf diese beiden Zeilen anfügen und Mosquitto neustarten: log_type all log_dest syslog

Allgemein Wenn du Probleme mit deinem WARP Charger oder deinem WARP Energy Manager hast und hier meldet möchtet, dann ist es für uns sehr hilfreich, wenn du (sofern möglich) einen Debug-Report über das Webinterface des WARP Charger oder des WARP Energy Manager speicherst und an deinen Forumpost anhängst. Den Debug-Report kannst du unter "System > Ereignis-Log > Debug-Report + Ereignis-Log (ohne Passwörter)" speichern. Wallbox-Ladeprobleme Wenn du speziell Probleme beim Laden deines E-Autos hast, dann kannst du über das Webinterface des WARP Chargers unter "Wallbox > Ladestatus > Ladeprotokoll > Start" die Aufzeichnung eines Ladeprotokolls starten. Dabei werden sehr detalliert Daten über die Kommunikation mit dem E-Auto aufgezeichnet. Dazu in der Regel zuerst das Ladeprotokoll starten, dann den Ladevorgang starten, damit der Start des Ladevorgangs mit aufgezeichnet werden kann. Das Webinterface muss während der Aufzeichnung offen bleiben, da das Ladeprotokoll im Browser gesammelt wird. Die Aufzeichnung über "Stop + Download" beenden und das Ladeprotokoll herunterladen, sobald das Problem aufgetreten ist. Da das Ladeprotokoll sehr detalliert ist wird es recht schnell recht groß, daher sollte die Aufzeichnung des Ladeprotokolls nicht über Stunden laufen gelassen werden. Energy Manager-Probleme Bei Problemen mit der Energieverteilung durch den WARP Energy Manager kann ein Energy Manager-Protokoll für uns hilfreich sein. Die Aufzeichnung kannst du im Webinterface des WARP Energy Managers unter "Energy Manager > Debug > Start" starten und über "Stop + Download" beenden und das Protokoll herunterladen. Entsprechend dem Ladeprotokoll der Wallbox wird auch das Energy Manager-Protokoll im Browser gesammelt, so dass das Webinterface während der Aufzeichnung offen bleiben muss.

Teste bitte mal diese Firmware. Dort kannst du als Registertabelle für den Zähler jetzt "Shelly Pro 3EM" auswählen, anstelle von "Benutzerdefiniert". warp_firmware_2_4_0_6688316c_ba658cef15de2d0_merged.bin

The original problem has been resolved. Please update to brickd 2.4.6 and HAT Brick firmware 2.0.4.

The original problem has been resolved. Please update to brickd 2.4.6 and HAT Brick firmware 2.0.4.

Brick Daemon 2.4.6 Adapt to Raspberry Pi 5 GPIO pin numbering changes, this makes a HAT (Zero) Brick work with a Raspberry Pi 5 now Use libgpiod for GPIO pin access on Linux Change runstatedir default from /var/run to /run on Linux Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Brick Daemon 2.4.6 An Änderugen bei der Raspberry Pi 5 GPIO Pin-Nummerierung angepasst, damit funktioniert jetzt der HAT (Zero) Brick mit einem Raspberry Pi 5 Auf Linux wird libgpiod für GPIO Pin-Zugriff verwendet Auf Linux runstatedir Standardwert von /var/run zu /run aktualisiert Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Currently there is a problem with Raspberry Pi 5 and more recent Linux kernel versions. Please try the attached brickd version. There will be a new release shortly. Sorry, for the long time it takes us to fix this problem. Edit: Attachment deleted. Brick Daemon 2.4.6 has been released. Please install the official release instead.

Das scheint daran zu liegen, dass die nicht direkt Modbus/TCP sprechen, sondern Modbus/TCP noch mal in einem Deye eigenen Protokoll verpackt ist: https://github.com/kbialek/deye-inverter-mqtt https://github.com/kbialek/deye-inverter-mqtt/blob/ef72887383e3a2e0bc7a3e4a55b5574ebcf65bb5/src/deye_modbus_tcp.py#L39 Dabei muss man dann die Seriennummer des Wechselrichters mitgeben. Mir ist nicht klar, ob das der Addressierung oder Security-by-Obscurity dient.

Die Dateien hal_arduino_esp32_brick.[hc] liegen im source/hal_arduino_esp32_brick Verzeichnis im ZIP.

The Industrial Counter Bricklet has a mode to read quadrature encoders like yours: https://www.tinkerforge.com/en/doc/Hardware/Bricklets/Industrial_Counter.html But it requires a higher voltage range that your encoder can provide. You could us a transistor at the outputs of your encoder to match the voltage level required by the Industrial Counter Bricklet.

Die ZIP Datei war unvollständig, das Problem ist behoben. Sorry und Danke für den Hinweis. Für die Ausgabe der Namen der Bricklets schau dir mal das angehängt Beispiel an. example_inventory.c