photron

Teste mal bitte die angehängte Firmware. Diese behebt in unseren Tests beide Probleme. Die Ursache lag in der Art und Weise, wie dein Smart Meter reagiert, wenn eine Modbus Deviceaddrese angefragt wird, die das Smart Meter nicht kennt. Damit ging die Firmware nicht richtig um und dann blieb der Scan hängen und konnte auch nicht mehr abgebrochen werden. Edit: Veraltete Firmware entfernt.

@Smoki Kurze Einführung in SunSpec. Die Daten werden als eine Kette von Blöcken dargestellt. Die Kette beginnt mit zwei Registern die die 32bit SunSpec ID 0x53756E53 enthalten. Daran erkennen wir, dass SunSpec unterstüzt wird. Wir laufen alle Modbus-Geräteadressen (1 - 247) durch und versuchen die SunSpec ID zu finden. Wenn die ID vorhanden ist, dann lesen wird die Kette der Blöck aus. Jeder Block beginnt mit der Model ID (ein Register) und der Blocklänge (ein Register). Dadurch können wir uns an der Kette der Blöcke dranlang hangeln ohne alle Blöck verstehen zu müssen. Sondern wir können die Model ID und die Blocklänge lesen, sehen ob das ein Model ist das uns interesiert und dann um die Blocklänge weitergehen, um dann das nächste Model zu lesen. Die Kette der Blöcke endet mit einem Model mit ID 0 und Blocklänge 0. Unser Scan geht alle Blöcke durch und zeigt dir dann die an die zählerartige Daten beinhalten. In deinem Fall Model 103 und 122. Dabei lesen wir die Daten des 122 Models gerade noch nicht aus, dass ist das was das "Nicht unterstützt" besagt. Das Problem in das du jetzt läufst betrifft Model ID 160. Das ist ein Model, das wiederholte Unterblöcke beinhaltent. Dessen Blocklänge hängt also von der Konfiguration deines Wechselrichters ab. Wir lesen jetzt hier im Scanvorgang 160 als Model ID und 48 als Blocklänge aus, was 8+2x20 entspricht, wie MatzeTF das oben erläutert. Danach überspringen wir dann die 48 Register, um die nächste Model ID zu lesen und bekommen einen ILLEGAL_ADDRESS Modbusfehler von deinem Wechselrichter. MatzeTF hatte sich das bei dir genauer angesehen und festgestellt, dass wir da wegen der falschen Blocklänge mitten in den Block des 160er Models lesen, was nicht erlaubt ist. Von den Daten her sieht es so aus, als wenn dein Wechelrichter 6 Module angeschlossen hat und daher einen 160er Block mit 6 wiederholten Unterblöcken melden sollte. Er liefert auch 6 wiederholte Unterblöcke, aber die Blocklänge passt nicht dazu. Gemeldet wird eine Blocklänge von 48 (8+2x20), richtig wäre aber wohl eine Blocklänge von 128 (8+6*20). Wenn MatzeTF händsich das 160er Model mit einer Blocklänge von 128 ausliest, dann funktioniert es und nach dem 160er Model folgt das 0er End Model in der Blockkette. Sprich dein Wechselrichter meldet nach unserem Verständnis nach das 160er Model mit falscher Blocklänge. Im 160er Model steht unter dem N Wert die Anzahl der wiederholten Unterblöcke. Aber auch hier steht in deinem Fall 2, was zur Blocklänge 48 passt, aber nicht zu den wiederholten Unterblöcken die dann wirklich vorhanden sind. Die Daten des 160er Models sind hier inkonsistent in einer Weise, die wir nicht retten können. Das sieht für uns nach einem Fehler im Wechslrichter aus denn nur SMA selbst beheben kann. Das 64870er Model ist ein Vender Specific Model von SMA. Wir melden dann verwirrenderweise "Unknown" für. Ich ändere das auf "Vender Specific" für die nächste Version.

Sorry für die späte Antwort. Tauchen die Bricks und Bricklets jetzt in Brick Viewer auf? Wenn ja, dann ist die einfachste Erklärung für den Timeout-Fehler, dass du dich bei der UID vertippt hast. Groß- und Kleinschreibung ist da wichtig. Kontrolliere bitte nochmal, dass die UID in deinem Python-Skript und Brick Viewer exakt übereinstimmen.

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?