photron

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. Edit: Veraltete Firmware entfernt.

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". Edit: Veraltete Firmware entfernt.

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

Im Rahmen der Integration des Victron GX als Zählerwertquelle, sind wir auch daran vorbeigekommen, dass man einen WARP Charger in die andere Richtung als Wallbox an Victron GX anbinden könnte. Dazu müsste man den Registersatz einer Victron Wallbox im WARP Charger implementieren. Ich habe das mal als Ticket hinterlegt, damit der Gedanke nicht verloren geht: https://github.com/Tinkerforge/esp32-firmware/issues/353

Issue zu 1.) https://github.com/Tinkerforge/esp32-firmware/issues/340

Füg mal bitte nach dem lcd_128x64_create Aufruf dies ein lcd_128x64_set_response_expected_all(&lcd, true); und lass das lcd_128x64_destroy weg, oder ruf es nach dem lcd_128x64_write_line auf.

Mich wundert eher, dass das nicht crashed mit lcd_128x64_destroy vor lcd_128x64_write_line. Das das so herum funktioniert ist eher Zufall. Dreh das mal bitte wieder um. lcd_128x64_write_line gibt einen int zurück. Gibt dir denn Wert mal bitte aus.

Es scheint das Unraid Server Docker Container ausführen kann. Getestet habe ich das aber nicht. Brick Daemon kann in einem Docker Container gebaut werden: https://github.com/Tinkerforge/brickd/tree/master/src/build_data/docker Das müsstest du dir aktuell selber bauen, das ist nicht auf Docker Hub verfügbar.

When you run brickd as user then it cannot access the GPIO pins with an EACCESS error. That is somewhat expected. There was a bug in the cleanup code for that case that resulted in a crash. This is fixed on Github now. You need to run brickd as root, but then it still cannot access the GPIO pins this time with an EBUSY error. This is unexpected. I can repoduce this problem with Ubuntu on an Raspberry Pi 5. But this is working fine with Raspberry Pi OS. So this must be an Ubuntu specific problem. I don't have the time right now to look into this Ubuntu specific problem. Maybe we could look at this next week. Sorry!

I cannot reproduce the "sudo apt --fix-broken install" here. Where did you find that you should install the dependencies (sudo apt-get install libusb-1.0-0 libudev1 procps) by hand? This is not neccessary. Also libudev1 is not required anymore. There where a few places left that still mentioned libudev1, I updated them now. Please try this brickd version, this should fix the GPIO problem. Edit: Attachment deleted. Brick Daemon 2.4.6 has been released. Please install the official release instead.

Nicht alle Autos können das. Zum Beispiel der Renault Zoe nicht.

Sehr gut! Das steht auf der TODO Liste.

Das "x5" soll dir sagen, dass du fünf uint32 (also 10 Register) von Adresse 4000 bis 4009 auslesen musst, um an die maximal 20 Byte zu kommen, die eine Tag ID lang sein kann. Die Dokumentation ist da verwirrend. Ich verbessere das gleich.

Ich hatte einen Dreher in den Device Type Konstanten. Jetzt sollte es funktionieren. Edit: Veraltete Firmware entfernt.