photron

Brick Daemon 2.4.5 Add Raspberry Pi 5 support for HAT (Zero) Brick Fix rare crash in initial USB device scan Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Brick Daemon 2.4.5 Unterstützung für HAT (Zero) Brick auf Raspberry Pi 5 hinzugefügt Seltenen Absturz bei der ersten USB Geräte-Suche behoben Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Firmware: HAT 2.0.4, HAT Zero 2.0.2 Support for Raspberry Pi 5 added Download: HAT, HAT Zero

Firmware: HAT 2.0.4, HAT Zero 2.0.2 Support für Raspberry Pi 5 hinzugefügt Download: HAT, HAT Zero

Deine Erkenntnisse sind soweit korrekt. Es werden abhängig vom Bricklet verscheidene Mikrocontroller aus der XMC 1100/1300/1400er Serie verwendet. Diese Details sind aber nicht relevant in deinem Fall. Ein Master Brick ab Hardware Version 3.0 kann unseren Bootloader auf einen leeren XMC flashen. Das kann allerdings dann nicht Brick Viewer, sondern du braucht das write_bootloader_and_firmware_to_comcu_bricklet.sh Script von hier https://github.com/Tinkerforge/flash-test Du brauchst dazu einen PC mit Linux und brickd (z.B. Ubuntu). Du schließt dein Bricklet an Port D einens Master Bricks 3.x an, schließt diesen Master Brick an den PC an und führst das write_bootloader_and_firmware_to_comcu_bricklet.sh Script aus. Dem gibts du als einziges Parameter den Pfad zur *.zbin Datei der Firmware für dein Bricklet mit. Diese kannst du unter https://www.tinkerforge.com/de/doc/Downloads.html herunterladen. ./write_bootloader_and_firmware_to_comcu_bricklet.sh bricklet_io16_v2_firmware_2_0_2.zbin Ich habe das jetzt recht knapp beschrieben. Falls das zu knapp war kann ich das auch in mehr Details beschreiben. Aber wenn du dich mit Linux auskennst, sollte das eigentlich reichen. Ansonsten frag bitte einfach.

This is not a common problem. It's the first time I hear about it. But I might have a hunch, about what might cause this. When the problem occurs, do you see a change in the CAN error counters of the Bricklet (function get_error_log)? By default the Bricklet uses 8 hardware write buffers. Does it make a difference if you reduce the number of write buffers to 1 (function set_queue_configuration, parameter write_buffer_size = 1)? Does your script reset the Bricklet on start?

SMA (steht auch in deren Dokumentation) erlaubt es nicht Werte partiell zu lesen. Genau das ist bei der Gerätesuche des Energy Managers passiert und daher kam der Invalid Address Fehler. Ist mit Beta 2 und in Git behoben. Das Script hat das Lesen da etwas anders gemacht, dadurch war das okay.

git pull und teste bitte nochmal. Der Fehler dort ist ein anderer. An der Stelle wird Modell 160 gelesen, das 128 Register lang ist. Modbus erlaubt es aber nur 125 Register an einem Stück zu lesen. Das habe ich jetzt repariert. Mit -s wird der Block von Modell 160 nicht geladen, sondern übersprungen, daher tritt dieser Problem mit -s nicht auf. Das hat aber leider alles nichts mit dem originalen Problem zu tun. Das Script kann die Daten lesen, der Energy Manager nicht. Ich such mal weiter nach dem Unterschied.

@poohnet Wir kommen näher. Das discover.py Script liest alle Werte einzeln. Der Energy Manager liest die Werte blockweise. Ich habe das discover.py Script jetzt umgestellt auf blockweises Lesen. Aktualisier mal bitte deinen git Clone und lass das Script nochmal laufen. Ich vermute, dass SMA es nicht erlaubt die Daten blockweise zu lesen. Das discover.py Script hat jetzt eine -s/--single-value-read Option, um das vorherige Verhalten wieder zu bekommen. Ich erwarte, dass das aktuelle discover.py Script ohne -s bei dir nicht funktiioniert, aber mit -s funktioniert. Kannst du das bestätigen?

@poohnet Komisch! Kannst du bitte diese Script ausführen: https://github.com/Tinkerforge/esp32-firmware/blob/feature-meters-7/software/src/modules/meters_sun_spec/discover.py Du brauchst dazu pymodbus >= 3.5.x, am einfachsten über pip installieren. python3 discover.py -H <sunny-boy-addresse> -d 126 Das Script liest jeden Wert einzeln, anstatt den ganzen Common Model Block in einem Rutsch zu lesen.

@poohnet Dann teste mal bitte den aktuelle Stand des features-meters-7 Branch (Commit: meters-sun-spec: Avoid reading common model block padding). Vielleichthilft das. Der Common Model Block kann laut Spec 65 oder 66 Register lang sein. Alles was wir hier zum Testen haben hat de 65er Variante. SMA hat aber die 66 Variante. Der Code geht damit richtig um, denke ich, aber vielleicht mag SMA nicht, dass ich das eine Padding Register mit lese. Das habe ich gerade geändert.

Ich gehe davon aus das SunSpec aktiv ist, da die SunSpec ID gefunden wird bei Geräteadresse 126 (SMA Standardwert laut Dokumentation). Der Common Model Header wird auch gelesen, aber das Lesen des Common Model Blocks gibt dann einen ILLEGAL_ADDRESS Fehler. Es gibt gleich eine neue Firmware zum Testen.

Da scheint sich was in Python geändert zu haben. Dieser Code hat in älteren Python Versionen funktioniert. Ich habe das korrigiert. Teste bitte mal Beta2. tinkerforge_shell_bindings_2_1_33_beta2.zip

Sorry, there was a bug in this call. Please try the attached version. tinkerforge_shell_bindings_2_1_33_beta1.zip

Firmware 1.1.2 ist über 1,5 Jahre alt. Wo hast du die als aktuelle Firmware gefunden? Oder hast du die Firmware aktualisiert als die Wallbox installiert wurde? Die aktuelle Firmware findest du immer hier: https://www.warp-charger.com/warp2.html#firmware

EVCC spricht mit der Wallbox über MQTT. Dafür müssen sich die Wallbox und EVCC zum MQTT Broker verbinden. EVCC verbindet sich nicht direkt mit der Wallbox, daher muss du in EVCC die Adresse des MQTT Brokers (dem Raspberry Pi in deinem Fall) angeben und nicht die Adresse der Wallbox.

Das Weitergeben geht weiterhin (dann offiziel), nur die API wird sich ändern. Die Umstellung wird in den nächsten Wiochen kommen. Die ganze Umstellung der Zähler API hat das Ziel meherer Zähler gleichzeitg zu unterstützen und es besser zu ermöglichen bereits vorhandene Zähler einfacher anbinden zu können.

https://tff-forum.de/t/charging-cable-release-tesla-taste/33270 Wenn der Schaltplan da stimmt, dann läuft die Entriegelung über den PP/PE Widerstand. PP ist aber die einzige Leitung die nicht durch das Kabel zur Wallbox geht. Sondern PP ist lokal mit PE im Stecker über einen Widerstand verbunden, der die Stromfestigkeit des Kabels codiert.

Firmware: WARP Energy Manager 1.0.7 Fehlende Messung der Phasenspannungen resultieren nicht mehr in zu niedrigen Ladeströmen im Lastmanagement 64k-Spitze in der Energiebilanz beim Neustart einer kontrollierten Wallbox beseitigt Y-Achsen Beschreibung zum Energiebilanz- und Stromzähler-Graphen hinzugefügt Identische Legendeneinträge im Energiebilanz-Graphen zusammengefasst Größenberechnung des Energiebilanz-Graphen repariert Laden der RTC-Zeit an Sonntagen repariert Erstellungszeit der Firmware besser lesbar gemacht Subnetzmaske zum WLAN- und Netzwerk-Zustand hinzugefügt Auswahl der vollen Subnetzmaske (/0 bis /32) für WireGuard erlaubt Abweichung in der Serialisierung zwischen current_charge und last_charges beseitigt Lastmanagement auf tabellarische Darstellung umgestellt Verwendung von Platzhaltern in Auswahlfeldern verbessert Payloads für Recovery-API-Aufruf repariert Fehleranzeige bei fehlender Auswahl einer Subnetzmaske repariert Potentiellen Deadlock beim Aufruf von API-Befehlen beseitigt Aktualisierung des last_value_change Wertes im API-Meter repariert Download: WARP Energy Manager 1.0.7

Firmware: WARP2 2.1.4 Fehlende Messung der Phasenspannungen resultieren nicht mehr in zu niedrigen Ladeströmen im Lastmanagement Potentiellen Deadlock beim Aufruf von API-Befehlen beseitigt Y-Achsen Beschreibung zum Stromzähler-Graphen hinzugefügt Laden der RTC-Zeit an Sonntagen repariert Erstellungszeit der Firmware besser lesbar gemacht Subnetzmaske zum WLAN- und Netzwerk-Zustand hinzugefügt Auswahl der vollen Subnetzmaske (/0 bis /32) für WireGuard erlaubt Abweichung in der Serialisierung zwischen current_charge und last_charges beseitigt NFC-Tag-Injection-API repariert im Falle, dass ein bereits bekannter Tag injectet wurde Überflüssigen Freigabe-Knopf für den globalen Ladestromslot entfernt Verwendung von Platzhaltern in Auswahlfeldern verbessert LED blinkt nicht mehr fälschlicherweise bei deaktivierter Benutzerfreigabe Verhalten bei zu schnellem OCPP-Verbindungsverlust verbessert Lastmanagement, NFC und Benutzerverwaltung auf tabellarische Darstellung umgestellt Payloads für Recovery-API-Aufruf repariert Fehleranzeige bei fehlender Auswahl einer Subnetzmaske repariert Inkonsistenzen zwischen SDM630 und SDM72 V2 im OCPP Modul behoben Aktualisierung des last_value_change Wertes im API-Meter repariert DC-Fehlerstromprüfung wird nur noch bei geschlossenem Schütz durchgeführt (durch Update auf Ladecontroller-Firmware 2.1.6) Boost-Modus nach Start repariert (durch Update auf Ladecontroller-Firmware 2.1.14) Schütz bleibt mindestens 30 Sekunden lang nach Verlassen von Zustand D ausgeschaltet (durch Update auf Ladecontroller-Firmware 2.1.14) Schütz bleibt mindestens 5 Sekunden lang nach Ende des Ladevorgangs ausgeschaltet (durch Update auf Ladecontroller-Firmware 2.1.14) Download: WARP2 2.1.4

Firmware: WARP 2.1.4 Fehlende Messung der Phasenspannungen resultieren nicht mehr in zu niedrigen Ladeströmen im Lastmanagement Potentiellen Deadlock beim Aufruf von API-Befehlen beseitigt Y-Achsen Beschreibung zum Stromzähler-Graphen hinzugefügt Laden der RTC-Zeit an Sonntagen repariert Erstellungszeit der Firmware besser lesbar gemacht Behoben, dass Zeit- und Energielimits weitere Ladevorgänge blockieren konnten Subnetzmaske zum WLAN- und Netzwerk-Zustand hinzugefügt Auswahl der vollen Subnetzmaske (/0 bis /32) für WireGuard erlaubt Abweichung in der Serialisierung zwischen current_charge und last_charges beseitigt NFC-Tag-Injection-API repariert im Falle, dass ein bereits bekannter Tag injectet wurde Überflüssigen Freigabe-Knopf für den globalen Ladestromslot entfernt Verwendung von Platzhaltern in Auswahlfeldern verbessert LED blinkt nicht mehr fälschlicherweise bei deaktivierter Benutzerfreigabe Lastmanagement, NFC und Benutzerverwaltung auf tabellarische Darstellung umgestellt Payloads für Recovery-API-Aufruf repariert Fehleranzeige bei fehlender Auswahl einer Subnetzmaske repariert Aktualisierung des last_value_change Wertes im API-Meter repariert Boost-Modus nach Start repariert (durch Update auf Ladecontroller-Firmware 2.1.6) ID.3-Modus auf Zustandsübergang von C nach A ausgeweitet (durch Update auf Ladecontroller-Firmware 2.1.6) Schütz bleibt mindestens 30 Sekunden lang nach Verlassen von Zustand D ausgeschaltet (durch Update auf Ladecontroller-Firmware 2.1.6) Schütz bleibt mindestens 5 Sekunden lang nach Ende des Ladevorgangs ausgeschaltet (durch Update auf Ladecontroller-Firmware 2.1.6) Download: WARP 2.1.4

Diesen Peak siehst du nur auf der Energiebilanzseite des Energy Managers? Aber nicht auf der Stromzählerseite der Wallbox? Welche Softwareversioen (WEM und WARP1) laufen da?

Hallo, EVCC kommuniziert dafür mit der Cloud des Autoherstellers. Das hat also so erstmal nichts direkt mit dem WARP Charger zu tun. Ich vermute man wird dir im EVCC Forum besser mit diesem Problem weiterhelfen können: https://github.com/evcc-io/evcc/discussions

Das USB CAN Gerät hat ja keinen Masse/GND-Kemme, das kanst du also nicht anschließen. Mir ist unklar die wie 120Ohm-Klemme zu verstehen ist. Leider schweigt sich die Anleitung aus. Muss da ein 120Ohm Widerstand angeschlossen werden, oder ist dort ein 120Ohm Widerstand innen drin? Hast du CANL an CANL angeschlossen und CANH an CANH? Oder hast du das vertauscht? Entferne mal die beiden kurzen Kabel, die du zwischen CANL/H und 120Ohm R+/- geschraubt hast. Falls das nicht hilft, stelle mal die Terminurung auf dem CAN Bricklet 2.0 auf Off. Man kann auch zu viel terminieren.

Please try the attched brickv version. brickv_macos_2_4_25_snapshot_150aa4c.dmg