rtrbt

Moin, Sorry für die späte Antwort, die Corsas sind heute erst angekommen. Der Chip-Mangel macht auch vor Opel nicht halt ;) Wir haben das direkt an WARP 1 und WARP 2 mit deinem Szenario 1 getestet und es funktioniert in beiden Fällen: Wir haben sicherheitshalber zwei Stunden gewartet, damit eventuelle Energiesparsachen des Corsas definitiv angesprungen sind. Das Laden hat trotzdem sofort begonnen, als ich auf dem Webinterface auf Start gedrückt habe. Am Keyless Go liegt es nicht, wir haben extra den Corsa genommen, der das nicht hat ;) Ein möglicherweise relevanter Unterschied ist aber, dass unsere Corsas den 7,4 kW-Lader haben, nicht deinen mit 11 kW. Ich halte es aber für eher unwahrscheinlich, dass die Lader sich auf dem Niveau anders verhalten. Kannst du, am besten erst in den nächsten Tagen, wenn Firmware 1.3 verfügbar sein wird, nochmal testen, ob das bei deinem Corsa immer noch kaputt ist?

Moin, Das ist eine WARP2-Firmware, die funktioniert auf WARP 1 nicht. Die nächste WARP 1-Firmware (1.3) wird einen Schutz dagegen haben, damit man keine WARP2-Firmware flashen kann. Du kannst die Wallbox noch wie folgt wiederbeleben: Du brauchst ein USB-C-Kabel und einen PC auf dem Brick Viewer installiert ist (bekommst du hier: https://www.tinkerforge.com/de/doc/Software/Brickv.html) Mache die Wallbox stromlos Nimm die Frontplatte ab (wie hier beschrieben: https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf Seite 4 ff.) Rechts sitzt der ESP32-Brick (der auf dem der Zurücksetzen-Button ist), den musst du ausbauen. Dazu die weißen Stecker abziehen und die Plastik-Schrauben rausdrehen. An der Unterseite des ESPs steckt noch ein weiterer Stecker, den auch abziehen. Den ESP32-Brick dann per USB an einen PC anschließen und Brick Viewer starten Im Brick Viewer links auf Updates / Flashing, dann oben auf Brick Dort musst du zuerst den richtigen Serial Port auswählen, z.B. COM3, /dev/ttyUSB0 oder /dev/cu.usbserial-... je nach Betriebssystem. Der richtige Port ist der bei dem dahinter "CP2102N USB to UART Bridge Controller" steht Dann kannst du die Firmware auswählen. In deinem Fall WARP Charger (ohne 2!) Die aktuelle Version (1.2.4) sollte dann automatisch ausgewählt werden. Dann auf Flash drücken und abwarten, bis die Statusmeldungen durch sind WICHTIG Wenn das Flashen fertig ist, dauert es noch ungefähr eine Minute, bis der ESP seine Konfigurationspartition formatiert hat. Du darfst den ESP erst vom PC abziehen, wenn die blaue Status-LED blinkt. Wenn alles fertig ist, kannst du den ESP wieder in die Wallbox einbauen und sie wieder zuschrauben Wenn du die Box jetzt wieder mit Strom versorgst, sollte sie wie im Auslieferungszustand den WLAN-Access-Point aufmachen und du kannst sie wieder konfigurieren.

Kurzes Update: Ich habe den Prozess etwas vereinfacht, du kannst jetzt Firmwares einbetten, indem du die .zbin-Datei in den Ordner des Moduls legst. Die prepare.py erstellt daraus beim Bauprozess den Header, der reinkompiliert wird. Falls du deine Änderungen in ein eigenes Modul auslagerst, musst du dir die prepare.py aus einem der Module klauen, die Firmwares einbetten, also aus EVSE (2.0), NFC oder SDM72DM.

Der aktuelle Stand ist hier: TL;DR: Wir arbeiten dran ;)

Das stimmt soweit. Du musst die Firmware dann bauen, dann sollte in evse-bricklet/software/build eine evse-bricklet-firmware.zbin rausfallen. Das ist im Endeffekt eine Zip-Datei. Darin gibt es die evse-bricklet-firmware.bin, das ist die eigentliche Firmware. Die kannst du mit xxd -i evse-bricklet-firmware.bin > evse_firmware.h in den Header umwandeln. Wichtig! Bevor du das machst, mach den Header auf und kopiere die ersten 8 Zeilen raus, lass dann xxd laufen, paste die 8 Zeilen wieder und passe die Versionsnummer an. Die Wallbox-(lies ESP-)Firmware ist so gebaut, dass sie beim booten vom EVSE die installierte Firmware-Version ausliest, und wenn das eine andere ist als die, die in der ESP-Firmware eingebettet ist, diese überflasht. Wenn du also die Versionsnummer erhöhst, wird das EVSE automatisch umgeflasht. Du hast aber folgende Alternativen: Lass die Versionsnummer so, bette deine Firmware ein und drück dann nach dem ersten Booten im Webinterface unter Ladecontroller -> Low-Level-State auf neu flashen Wenn du [wallbox_ip]/hidden_proxy/enable aufrufst, kannst du dich mit dem Brick Viewer auf die Wallbox verbinden und das EVSE wie jedes andere Bricklet auch flashen. Da _musst_ du dann aber die Versionsnummer so lassen, wie sie in der eingebetteten Firmware ist, weil die Wallbox ansonsten die eingebettete Firmware wieder drüber flasht.

Moin, Ich habe das mal sinnvoller gelöst: Die pio_hooks installieren die Javascript-Abhängigkeiten jetzt automatisch, falls sie fehlen, das Authentication-Modul macht das jetzt genauso. Damit meinst du die für Bricklet-Firmwares? Die brauchst du für die Wallbox-Firmware selbst nicht. (Es sei denn du willst am Ladecontroller selbst Änderungen vornehmen) Edit: Vergiss das, habe gerade den anderen Thread gesehen ;)

Das kommt mit der nächsten Firmware, ist schon implementiert ;) https://github.com/Tinkerforge/warp-charger/commit/172dd1e27c76cafc5d55c69ff47ef86e70ffeeef

Kurzes Update: Bei den 4 Boxen ist der RAM-Verbrauch unverändert. D.h. ich würde ein Speicherleak erstmal ausschließen. Eventuell doch eher ein Kommunikationsproblem zwischen ESP und Ladecontroller. Ich gebe Bescheid wenn ich mehr weiß.

Moin Martin, Ich gehe mal davon aus, dass das -246°C sind, das ist der kleinste Wert, den das PTC-Bricklet messen kann. Ich kenne einen Fall bei dem das Problem dann war, dass eine der Steckverbindungen (Sensor -> Bricklet -> HAT -> Pi) nicht ganz saß und genau das Problem auftrat. Eventuell kann sich @KlausGünther an Details erinnern, bzw. ob das Problem bei ihm nochmal aufgetaucht ist. Ich hätte ansonsten folgenden Fragenkatalog: Welche Brick Daemon-Version hast du laufen? (steht im Log ganz oben) Wie lange hält der Fehler an? Hat sich das Problem von alleine gelöst, oder musstest du irgendetwas tun? War das bei allen Bricklets gleichzeitig? Wie sieht der Aufbau aus? Also was misst du für Temperatur-Bereiche, ist das "outdoor" usw. Poste am besten auch mal die Graphen und ein Brick Daemon-Log. Grüße, Erik

Da geht es um das Kabel, über das der Zähler ausgelesen wird. Das Kabel ist beim Zähler mit dabei: https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts/stromzaehler-sdm630.html

Gut zu hören! Das sollte ich eventuell dokumentieren. Die Konfigurationsversion ist immer die Version, mit der die Wallbox-Konfiguration zum ersten Mal geschrieben wurde (nach Auslieferung bzw. nach einem Reset auf Werkszustand). Stand jetzt ist die Version unwichtig, falls ich aber irgendwann brechende Änderungen machen muss, kann ich dann sauber migrieren.

Im Anhang ist die versprochene Firmware. Sorry, dass das bis heute gedauert hat. Nein, die Kalibrierung ist Box-spezifisch, würde in deinem Fall vermutlich nicht helfen. warp_firmware_1_2_90_615ff6f3_merged.bin

Das deckt sich soweit mit den Tests, die ich hier gemacht habe. Soweit du mit statischen IPs leben kannst, würde ich da erstmal nicht mehr Zeit investieren. Ich habe sowieso vor in nächster Zeit die ganze MQTT-Implementierung durch eine andere zu ersetzen, deshalb würde es sich nicht lohnen das weiter zu debuggen, solange MQTT grundlegend funktioniert. Das ist ein bekanntes Problem, ich bin aber bisher noch nicht dazu gekommen es zu fixen.

Moin Christoph, Mit Firmware 1.0.2 kannst du die Wallbox auch ohne Deckel und Taster betreiben. Grüße, Erik

Kurzes Update: Das Problem sollte in Firmware 1.0.2 entgültig behoben sein. Hatte noch eine zweite Stelle mit dem selben Bug übersehen.

:D Die Idee hatte ich auch, aber dann würden im Log nicht die ganzen Verbindungsversuche aufschlagen. Ich wühle mich gleich nochmal durch die MQTT-Bibliothek, in der Hoffnung herauszufinden, wo es bei dir hakt. Schonmal als Teaser: Jedes "Connecting to MQTT broker" sollte danach einen Fehler und/oder ein "Disconnected" mit Fehlercode erzeugen (das sind in der Firmware Callbacks aus der MQTT-Bibliothek). Da das nicht passiert, muss irgendetwas in der Bibliothek verquer sein. Auffällig ist, dass die Box relativ lange braucht, um einen IP zu beziehen: 5407 Ethernet connected 8376 Had to configure softAP ip 1 times. 10377 Soft AP started. 10377 SSID: warp2-WFk 10377 hostname: warp2-WFk 10730 IP: 10.0.0.1 10849 Connecting to MQTT broker 12568 Ethernet MAC: A8:03:2A:31:66:2F, IPv4: 192.168.12.24, Full Duplex, 100 Mbps 12569 Ethernet got IP address: 192.168.12.24. 12580 Network connected. Stopping soft AP 70861 Connecting to MQTT broker Das dauert so lange, dass der erste Verbindungsversuch passiert, wenn die LAN-Verbindung noch nicht besteht. Eventuell kommt da das Routing durcheinander und versucht über den Soft-AP zu gehen, obwohl der ja gestoppt ist. Ich melde mich nochmal, wenn ich mehr weiß.

Moin Patrick, Teste mal bitte die angehangenen Firmware, mit der du mehr Ausgaben in das Ereignis-Log bekommen solltest. Damit sollten wir rausfinden können, woran es hängt. Grüße, Erik Edit: Die Wallbox 1-phasig betreiben ist kein Problem. warp2_firmware_1_0_1_615d6394_merged.bin

Moin Henning, Das Problem scheint nichts mit den Sonderzeichen zutun zu haben, sondern nur mit kaputter Fehlerbehandlung beim Abschalten des APs, wenn die WLAN-Verbindung hergestellt wurde. Teste mal bitte die angehangene Firmware, da sollte der Bug behoben sein. Grüße, Erik warp2_firmware_1_0_1_615c5b77_merged.bin

Moin Christoph, Hast du die Wallbox bei der Installation der Zuleitung und dem Anschluss des LAN-Kabels jeweils ohne die Frontplatte betrieben? Das wäre die beste Erklärung warum die Konfiguration verloren gegangen ist. Zur Erklärung: Bei WARP 1 war es so, dass einer der Buttons auf dem ESP selbst einen Factory Reset (lies: ein Formatieren der Konfigurationspartition) auslöst. Das klappt bei WARP 2 so nicht, weil auf dem selben Signal wie der Button der Ethernet-Takt liegt. Deshalb hatte ich als Alternative dazu eingebaut, dass wenn man die Wallbox bestromt und der Taster in der Frontplatte gedrückt ist, der Reset ausgeführt wird. Das führt jetzt dazu (ganz ehrlich: da habe ich einfach nicht dran gedacht), dass der Reset ausgelöst wird, wenn du die Wallbox ohne die Frontplatte betreibst. Für die nächste Firmware-Version setzen wir den Factory Reset anders um, voraussichtlich muss man dann den ESP aus der (unbestromten!) Wallbox ausbauen, an einen PC anschließen und den Reset per Brick Viewer machen. Ist komplizierter, aber im Normallfall sollte der Reset ja unnötig sein. Danke für's melden! Erik

Moin Alex, Warp 2 unterstützt nur den SDM630. Das Lastmanagement funktioniert aber ohne Zähler, da es nur Maximalströme vorgibt, ob das Fahrzeug diesen Strom dann auch zieht ist ein anderes Problem. D.h. wenn du anderweitig den Shelly 3EM in deine Unterverteilung baust und in dein WLAN bekommst, müsste das funktionieren. Stand jetzt nicht. Ich hatte mir das Thema OCPP vor ein paar Monaten angesehen, habe es aber aufgrund der Komplexität erstmal hinten angestellt. OCPP-Unterstützung (dann voraussichtlich OCPP 1.6 JSON) wird irgendwann kommen, ich kann dir aber nicht versprechen wann. (Nur dass es dieses Jahr nichts mehr wird, das Jahr ist ja nicht mehr lang, die TODO-Liste aber schon ;) ) Aufgrund dessen wie OCPP funktioniert, sind die Wallboxen dann aber nur "Clients", werden also von einem OCPP-Server gesteuert, den du dann auch bräuchtest. Das ist aber bei den cfos-Boxen genauso soweit ich das spontan gelesen habe.

Korrekt. Das wird voraussichtlich die 1.3.0, aber ja darin sind sowohl die aktuelle Ladecontroller-Firmware, als auch der neue Web-Server und das Lastmanagement.

Moin Henning, Das ist auf jeden Fall ein Bug. Spontan wäre meine einzige Idee, dass das Konfigurieren des Access Points nicht klappt, aber aus irgendeinem Grund der AP trotzdem geöffnet wird. Lade von der Wallbox bitte den Debug-Report und das Ereignis-Log runter (beide unter System->Ereignis-Log) und hänge sie hier an, eventuell findet sich da etwas. Grüße, Erik

Moin Patrick, Mir ist absolut unklar, warum deine Box in den Zustand gekommen ist. Zur Erklärung: Username und Passwort, sowie ein Flag ob der Login aktiviert ist, werden im Flash der Wallbox gespeichert. Das Firmware-Update ändert an diesen Daten nichts. Selbst wenn jetzt z.B. das Speichern der Datei schiefgegangen ist, würde die Wallbox die Standardeinstellungen laden, bei denen der Login natürlich aus ist. Damit du erstmal wieder auf die Wallbox zugreifen kannst, müsstest du die Einstellungen zurücksetzen. Das ist wie man WARP 2 zurücksetzt, bei WARP 1 musst du die Frontplatte abnehmen und den IO0-Button 10 Sekunden gedrückt halten. Siehe hier: https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf (Seite 10)

Das ist interessant, weil es bedeutet, dass sowohl Ladecontroller, als auch der ESP, der das Webinterface hostet, noch liefen. Vermutlich war die Kommunikation zwischen beiden gestört. Ich versuche weiterhin mal das hier zu reproduzieren, bin aber wie gesagt die nächsten zwei Wochen im Urlaub, dauert also etwas.

Moin, Das sieht nach dem klassischen VW-Ladeproblem aus: Wenn das Auto von "Ich bin hier" auf "Ich will laden" umschaltet, springt der Widerstandsmesswert kurz extrem hoch, was die Wallbox als "Das Auto ist nicht mehr angeschlossen" interpretiert. Wir haben in der Firmware 1.2.3 dafür den ID.3-Modus eingebaut, der auf die Änderung träger reagiert. Welche Firmware hast du laufen? Falls es nicht 1.2.4 ist, teste mit der aktuellen nochmal (Findest du hier). Wenn das Problem dann immer noch auftritt, erstell bitte nochmal ein Ladelog. Du musst die Konfigurationen übrigens nicht rauslöschen: Passwörter können über das Webinterface nicht ausgelesen werden, d.h. du leakst höchstens deinen WLAN-Namen und den Hostnamen der Box (die kannst du natürlich gerne löschen, aber alles, was mit evse/ anfängt könnte hilfreich zum Debuggen sein ;) ) Grüße, Erik