rtrbt

Moin, Sorry dein Thread ist irgendwie untergegangen. Wenn du nach WLANs scannst, taucht dein Netz dann auf? Hast du eventuell Repeater mit dem selben Netzwerknamen und der Brick versucht sich aus irgendwelchen Gründen zu dem Repeater zu verbinden? (Das kontrolliert das BSSID-Lock) Du kannst dir die Liste der gefundenen WLANs unter http://10.0.0.1/wifi/scan_results runterladen.

Der Work-Around ist in der frisch veröffentlichten 2.0.6, damit sollte der Fehlerzähler nicht mehr beim Reset hochzählen.

Moin, Testet beide bitte mal die Firmware 2.0.6, wir hatten mit 2.0.5 einen esoterischen Bug mit dem Schlüsselschalter gefixt, aber uns damit mehr Probleme eingehandelt, als gelöst. Außerdem haben wir die ID.3-Kompatibilität nochmal verbessert. In Summe sollte es jetzt wieder problemlos klappen.

Moin, Testet beide bitte mal die Firmware 2.0.6, wir hatten mit 2.0.5 einen esoterischen Bug mit dem Schlüsselschalter gefixt, aber uns damit mehr Probleme eingehandelt, als gelöst. Außerdem haben wir die ID.3-Kompatibilität nochmal verbessert. In Summe sollte es jetzt wieder problemlos klappen.

Moin, Gute Idee! Ist in der frisch veröffentlichten Firmware 2.0.6. Wenn die Synchronisierung klappt bekommst du einen separaten Eintrag dafür (und alle danach haben dann richtige Zeitstempel). Falls du etwas Ausgabe erzeugen willst kannst du z.B. einen WLAN-Netzwerkscan starten. Wenn die Synchronisierung klappt wiederholt die Wallbox sie nach 6 Stunden. Wenn eine Synchronisierung nicht klappt, hat der entsprechende Code einen Timeout von 15 Sekunden, der bei jedem Fehlschlag verdoppelt wird, bis maximal 150 Sekunden, also 15s, 30s, 60s, 120s, 150s, 150s, ... Das du Tagelang keine Synchronisierung bekommst würde ich also tendenziell eher auf die WLAN-Probleme schieben.

Firmware: WARP 2.0.6 und WARP2 2.0.6 WLAN-Scan-Timeout für Access-Point-Kanalsuche erhöht Aussehen der Form-Validierung repariert Netzwerk-Zeitsynchronisierungszustand und aktuelle Uhrzeit auf Statusseite hinzugefügt (WARP1) Work-Around für SDM72DM-Bug beim Zurücksetzen des Zählers hinzugefügt (WARP1) Sichergestellt, dass Ladevorgang nie gestartet werden kann, wenn Schlüsselschalter auf "aus" steht (durch Update auf Ladecontroller-Firmware 2.1.3) (WARP1) Längere Wartezeit für ID.3-Zustandswechsel hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.3) (WARP1) Sichergestellt, dass LED bei jedem Zustandswechsel bis zum Stand-By reagiert (durch Update auf Ladecontroller-Firmware 2.1.3) (WARP2) Sichergestellt, dass Ladevorgang nie gestartet werden kann, während Taster gedrückt ist (durch Update auf Ladecontroller-Firmware 2.1.5) (WARP2) Kompatibilität mit einigen Versionen des SDM630 erhöht (durch Update auf Ladecontroller-Firmware 2.1.5) Download: WARP 2.0.6 bzw. WARP2 2.0.6

Ich bin dem mal nachgegangen: Anscheinend hat der Stromzähler einen Bug in der Modbus-Kommunikation. Was beim Reset intern passiert ist, dass ich einen Schreibbefehl auf ein spezielles Register schicke, worauf hin der Zähler den Wert zurücksetzen und mir darauf antworten sollte, dass er das getan hat. In Modbus funktioniert das so, dass die Slaves (also der Zähler in dem Fall) IDs haben, damit wenn mehrere an einem Bus angeschlossen sind, der Master spezifisch mit einem Slave reden kann. Damit die Antworten unterschieden werden können, müssen die Slaves ihre eigene ID in die Antwort schreiben. Wenn ich z.B. einen Zählerwert lese sieht das mit dem Logic Analyzer so aus: Request an DeviceID 1 (den Zähler): Response von DeviceID 1: Der Zähler schickt jetzt aber, wenn ich den Reset auslöse eine Antwort nicht mit seiner ID (der 1) sondern aus irgendeinem Grund mit einer 0. Die 0 ist reserviert für Broadcasts, die darf von Slaves überhaupt nicht verwendet werden. Request an DeviceID 1: Response vom Zähler mit falscher DeviceID: Das Problem tritt aber nur bei dem Reset auf, beim Lesen der Zählerwerte, selbst beim Schreiben anderer Konfigurationswerte (mit der selben Funktions-ID) ist die Antwort korrekt. Das RS485-Bricklet (mit dem wir mit dem Zähler kommunizieren) sieht beim Reset dann die kaputte Antwort, wirft sie weg und betrachtet das als einen Timeout. Die Lösung des Problems wird sein, dass wir in der Wallbox-Firmware, falls beim Reset auslösen ein Timeout auftritt diesen ignorieren. In der Praxis habe ich es bisher nicht beobachten können, dass der Reset nicht funktioniert. Das sollten wir aber trotzdem prüfen, z.B. indem die Firmware dann den Wert, der zurückgesetzt wird, nochmal ausliest und prüft, dass er erwartet klein ist (also z.B. maximal x ms * 32 A * 230 V * 3 Phasen groß, wobei x die Zeit vom Auslösen des Resets bis zum Empfang des neuen Werts ist). Falls der Wert dann zu groß ist, lösen wir den Reset nochmal aus, mit maximal z.B. 3 Versuchen. Das zu implementieren ist etwas Aufwand, deshalb habe ich erstmal ein Issue dafür angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/147 Als schnelle Lösung für die nächste Firmware nehme ich erstmal raus, den Fehlerzähler bei Reset-Timeouts hochzuzählen. Das fühlt sich immer etwas falsch an zu sagen "nein nein hier zählt der Fehler nicht weil..." aber ich glaube in dem Fall ist es berechtigt: https://github.com/Tinkerforge/esp32-firmware/commit/7ec89afcbad67460b14527bbf318f7d266800392

Gibt es derzeit nicht, will ich jetzt auch nicht versprechen. Ich habe mal ein low-priority Issue angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/145

Das sind durchschnittlich 21,5 Minuten zwischen den Fehlern, ~ 0,012% Fehlerrate, aber trotzdem mehr als ich erwarten würde. Exception Code -1 heißt, dass das RS485-Bricklet (das kommuniziert per Modbus mit Zähler) eine Antwort des Zählers nicht innerhalb des Timeouts (eine Sekunde) bekommen hat. Was mir jetzt beim Schreiben auffällt: Es werden keine Request-IDs mit ausgegeben. Bist du auf der aktuellen Firmware? Falls ja, dann sind das alles Fehler, die beim Zurücksetzen der Zählerwerte aufgetreten sind. Eventuell ist der Timeout da einfach zu kurz gewählt.

Habe mal ein Issue dafür angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/144 Ansich wäre das schon ein cooles Feature, ich will aber nicht versprechen, dass wir das implementieren.

Moin, Teste bitte mal mit der angehangenen Firmware. Damit sollte der Schlüsselschalter wie erwartet blockieren und auch wenn du auf Start klickst nichts passieren. (Was noch fehlt ist im Webinterface den Button auch zu deaktivieren, wenn der Schlüsselschalter blockiert: https://github.com/Tinkerforge/esp32-firmware/issues/142) warp_firmware_2_0_5_628dfcab_merged.bin

Wenn du das Auto angeschlossen lässt, es aber voll ist, dann läuft die Ladezeit weiter. Egal ob NFC aktiv ist oder nicht. Prinzipiell ja, das hat aber folgende Probleme: Das Auto kann jederzeit wieder von 2 (das ist btw. IEC-State B) auf 3 (C) gehen, wenn es wieder Strom anfordert (das passiert z.B. wenn du im Winter die Standheizung anschaltest, wenn das Auto sich nach mehreren Stunden/Tagen wieder etwas leergestanden hat, oder gerüchteweise wenn der Akku zu warm wird) Solche Ladepausen kann das Auto übrigens auch einlegen ohne dass es von 3 auf 2 wechselt. Wenn z.B. das Lastmanagement der Wallbox kurzzeitig den Strom entzieht kannst du von 3 auf 1 (das ist auch IEC-State B) wechseln und z.B. eine halbe Stunde später (wenn wieder Strom verfügbar ist) wieder auf 3 gehen. Ist das dann ein Ladevorgang oder zwei? Ist die halbe Stunde die das Laden blockiert war Ladezeit oder nicht? Was ist, wenn du bis nach Zustand 3 kommst, das Auto aber z.B. einen Ladeplan hat der sagt dass es erst in einer Stunde anfängt Strom zu ziehen? Fairerweise: Das ist esoterisch, gibt es aber. Schlussendlich kann man dann auch grundlegend in Frage stellen, ob die Ladezeit (im Gegensatz zur Standzeit) überhaut eine hilfreiche Information ist. Wenn man keinen Zähler hat kann man daran sowieso nicht ablesen, wie viel geladen wurde (das Auto muss ja keinen Strom ziehen). Wenn ein Zähler vorhanden ist, dann ist z.B. "Das Auto war 8 Stunden angeschlossen und hat währenddessen 30 kWh gezogen" doch trotzdem interessanter als "Das Auto hat in zwei Stunden 30 kWh gezogen, aber danach noch unbekannt lang die Wallbox blockiert". Ich spiele derzeit mit dem Gedanken, zwei Zähler mitzuführen. Einen der die Zeit vom Anstecken bis zum Abziehen des Autos trackt (und dann auch nicht erst anfängt wenn man ein NFC-Tag an die Box hält) und einen, der die Zeit die wirklich in State 3 bzw. C verbraucht wurde, misst. Das hat aber noch ein paar Probleme in der Umsetzung, deshalb will ich das an der Stelle nicht versprechen ;)

Hm das deckt sich mit meinen Tests. Scheint in der Tat vom NFC-Chip im Handy abzuhängen, siehe auch hier: https://stackoverflow.com/a/27998215 Ich bekomme aber mit meinem Handy auch mit dem NFC/RFID-Bricklet (das den NFC-Chip verbaut hat, den du auch benutzt) nur 01:02:03:04... als ID. Interessanterweise aber als NFC-Typ 1 und beim neueren NFC-Bricklet als Typ 4. Fazit: um mit Handys die Wallbox freizugeben müssen wir irgendetwas höheres über NFC sprechen. Gibt schon ein Issue dafür: https://github.com/Tinkerforge/esp32-firmware/issues/90

Moin, Aktualisiere mal auf Firmware 2.0.5 (findest du hier: https://www.warp-charger.com/#firmware) Nicht dass wir alte Bugs jagen. Im Ereignis-Log sind einige interessante Fehler am 18.05. ab 00:15. Hattest du den e-up da gerade angeschlossen? Laut Ladelog fängt sich die Wallbox nach ein paar Stunden. Hat das Laden dann wirklich funktioniert oder sind die Aufzeichnungen falsch? Z.b. hier vom 12.05.: "12.05.2022 20:29","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "12.05.2022 21:06","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "12.05.2022 21:07","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "12.05.2022 21:09","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "12.05.2022 21:10","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "12.05.2022 21:11","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "12.05.2022 21:12","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "12.05.2022 21:14","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "12.05.2022 21:15","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" [60 Einträge gekürzt] "13.05.2022 00:10","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "13.05.2022 00:11","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "13.05.2022 00:12","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "13.05.2022 00:14","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "13.05.2022 00:15","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "13.05.2022 00:16","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "13.05.2022 00:17","Unbekannter Benutzer","NaN","0","","N/A","N/A","Unbekannter Benutzer" "13.05.2022 00:18","Unbekannter Benutzer","NaN","22850","","N/A","N/A","Unbekannter Benutzer" Wenn das Log stimmt lief dann am Ende 6 Stunden lang ein Ladevorgang. Hörst du, wenn das passiert alle ~ 20 Sekunden ein Klicken aus der Wallbox?

Das Verhalten sollte sich eigentlich nicht geändert haben. Die Ladedauer musst du aber eher als Standzeit betrachten. Ladestart und Ende haben wir so definiert: Wenn die NFC-Freigabe aktiv ist: Start, wenn per Tag der Ladevorgang freigegeben wird Stop, wenn per Tag der Ladevorgang gestoppt wird, oder wenn das Auto abgezogen wird Wenn die NFC-Freigabe nicht aktiv ist: Start, wenn das Auto angesteckt wird Stop, wenn das Auto abgezogen wrid Die Zeit zwischen Start und Stop ist die Ladedauer. Stattdessen die wirkliche Ladedauer zu bestimmen ist aus diversen Gründen kompliziert. Vorallem weil die Logik auch ohne Zähler funktionieren muss.

Kommunikationsfehler mit dem Stromzähler treten in der Tat manchmal auf, sind aber nicht kritisch. Um ein Gefühl für die Frequenz zu bekommen kannst du einen Blick ins Ereignis-Log werfen. Wenn du Glück hast, dann sind die Nachrichten vom Start noch erhalten, dann interessant ist eine Nachricht der Form 2022-05-13 15:24:42,264 NTP synchronized at 16,571! Diese sagt z.B. dass die Wallbox am 13.05. um 15:24:26 gestartet ist (die Zeit hinten ist die Zeit seit dem die Box läuft in Sekunden). Falls die Boot-Nachrichten schon aus dem Event-Log geschoben wurden, kannst du dir einen Debug-Report ziehen. In Zeile 4 siehst du die Uptime. (Achtung: 32-Bit Zähler in Sekunden, der kann überlaufen) Damit du das in ein Verhältnis setzen kannst: WARP1 liest alle 500ms drei Werte vom Zähler aus. Da die Modbus-Register nicht direkt hintereinander liegen sind das 6 Modbus-Lese-Anfragen pro Sekunde.

https://datatracker.ietf.org/doc/html/rfc4180 (das nächst-beste zu einem Standard über CSV) erwähnt explizit, dass Excel schwierig ist, weil es die Anführungszeichen ignoriert. Für Excel sicherlich, wir müssen aber auch sicherstellen, dass andere Software die Datei noch versteht. Es gibt noch ein paar Tricks von denen wir jetzt die richtige Kombination finden müssen. Wir arbeiten dran ;)

Anschlussfrage: Wie fakst du mit dem Handy das NFC-Tag? Also mit welcher App und welcher Android-Version? Den PN532 haben wir auf dem Vorgänger des NFC-Bricklets verbaut (dem NFC-RFID-Bricklet), d.h. Hardware zum Testen habe ich hier.

Für EVCC ist nur relevant, dass du auf irgendeine Weise den PV-Überschuss messen kannst. Wenn deine Solaranlage den direkt ausgibt (muss sie ja, wenn sie die Heizung kontrollieren kann), dann sollte das eigentlich reichen. Falls du dich da einlesen willst: https://docs.evcc.io/docs/Home EVCC würde in dem Setup dann die Solaranlage per Modbus TCP auslesen und dem WARP Charger per MQTT steuern. Das aufzusetzen involviert aber etwas Handarbeit.

Das Ladelog scheint in der Tat mit Excel Probleme zu machen. Eigentlich sollte Excel zwischen den Dezimaltrennern und den Feldtrennern unterscheiden können, weil jeder Wert mit Anführungszeichen umschlossen ist. Ich habe mal ein Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/141

Ist der Quellcode davon verfügbar? Dann würde ich mir wie gesagt mal ansehen, wie der Reader das auslesen macht.

The bricklet returns its UID in the enumerate response. For the enumerate request you don't have to set a UID, but use 0 (or "1" if base58-encoded) This is basically the "normal" enumerate: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html#broadcast-functions but with another function ID (252).

Moin, Modbus-TCP können die Wallboxen derzeit nicht. Ich habe noch auf meiner Liste, mir anzusehen ob und wenn ja wie man Support dafür hinzufügt. Der SolarLog-Zähler wird aber von EVCC unterstützt: https://docs.evcc.io/docs/devices/meters/#solarlog D.h. du könntest dir eine EVCC-Instanz aufsetzen, die den Zähler ausliest und die Wallboxen steuert.

Hi, You don't have to implement the SPI protocol yourself if you don't want to. Instead you can use the C/C++ bindings for microcontrollers. Those bindings implement the SPI-TFP protocol for you, so that you can use more or less the same API as with the normal C bindings. See for example here for the Load Cell Bricklet API. To use the bindings you have to use a Hardware Abstraction Layer (HAL) for your Arduino, but currently there is no generic one available. (We've released the bindings just some weeks ago). You basically have two options here: Patch the Arduino ESP32 Brick HAL or try to use the prototype Arduino HAL, however I'm not sure if this one works right now. If you really want to implement the SPI protocol yourself, you have to take a look at our implementations, as there currently is no documentation of the SPI protocol. The implementation used in the microcontroller bindings is here: https://github.com/Tinkerforge/generators/tree/master/uc (have a look at spitfp.h/.c) As a very short overview (so you know what to grep for ;) ): The SPI protocol (called SPITFP) wraps the TFP protocol that is also used over TCP. See here for the TFP protocol: https://www.tinkerforge.com/en/doc/Low_Level_Protocols/TCPIP.html and for example the Load Cell 2.0 packets: https://www.tinkerforge.com/en/doc/Software/Bricklets/LoadCellV2_Bricklet_TCPIP.html SPITFP consists of two header bytes, a wrapped TFP packet (if it is not only an ACK) and one footer byte: The packet length: 3 bytes for an acknowledgement or 11 to 83 bytes for a payload packet The sequence number of this packet (4 bit) and the sequence number that is acknowledged with this packet (also 4 bit) (Footer) A checksum over all packet bytes except this one. This is a Pearson hash . See here for an implementation Only one packet in flight is allowed in each direction. A bricklet will resend the last packet if you don't acknowledge it. Bricklets expect that you send a CoMCU-enumerate as first packet. If you don't, the bricklet will send a response for the enumerate by itself.

Ja, das ist egal, die Firmware fragt am Anfang an allen Ports ab, was für ein Bricklet jeweils angeschlossen ist.