rtrbt

Das ist natürlich fatal, kann ich hier aber nicht reproduzieren. Kannst du das nochmal ausprobieren? Das müsste wieder der Bug sein, den ich eCarUp gemeldet habe: Mein StopTransaction.req wird nicht bestätigt und dann läuft der Zustand auf der WARP und bei eCarUp auseinander. Ich muss da nochmal mit Wireshark draufgucken, das Timing sieht bei dir interessant aus. Da du das auch mit SteVe erzeugen kannst, ist das natürlich noch seltsamer. Sehe ich mir mal an.

Firmware WARP2 2.0.92 Details hier:

Habe den Fix gleich in OCPP-Beta 3 gepackt.

Das stimmt, das ist aber okay. Die Wallbox wartet nur eine gewisse Zeit auf ein NFC-Tag, bevor sie nach Finishing geht. Aus Finishing kannst du aber mit einem Tag (oder RemoteStartTransaction, also z.B. per App) wieder nach Preparing gehen. Das passiert in deinem Fall auch, nur dass RemoteStartTransaction sofort nach Transaction geht weil das Kabel auch angesteckt ist. Folgendes ist aber sehr interessant: Beim Übergang nach Transaction sollte ein StartTransaction.req geschickt werden, das passiert aber nicht. Das ist auf meiner Seite kaputt. Ich sehe mir das nochmal in Ruhe an (Änderungen an dem Zustands-Automaten sind immer etwas heikel).

Ah das erklärt warum ich das falsch interpretiert habe. Jedenfalls: evse/start_charging (und auch /stop_charging) haben sich anders verhalten als der Taster. Du konntest damit unabsichtlicherweise eine zukünftige Ladung starten, ohne dass ein Auto angeschlossen ist. Das ist in WARP 2.0.8 bzw. WARP2 2.0.9 gefixt. Gib bitte Bescheid, falls du das Problem dann immer noch hast)

Aktualisiert bitte alle mal auf WARP 2.0.8 bzw. WARP2 2.0.9. Das Problem sollte damit weg sein. (FYI hier der Commit, der den Bug behebt: https://github.com/Tinkerforge/esp32-firmware/commit/675387f331678918176ece325fdbf83416a33ae9)

Firmware: ESP32 Brick 2.0.2, ESP32 Ethernet Brick 2.0.2 Add WireGuard support Make authentication secret, listen port and address configurable Add NTP state and synced time to status page Improve firmware update error handling in web interface Update timezone database Improve translations Fix commands without payload via HTTP GET Add reset API for configurations Add reset button to configuration pages Fix firmware hanging after 2^32 ms (~ 49 days 17 hours) Fix access point as fallback not starting correctly Download: ESP32 Brick, ESP32 Ethernet Brick

Firmware: ESP32 Brick 2.0.2, ESP32 Ethernet Brick 2.0.2 WireGuard-Unterstützung hinzugefügt Authentication-Secret, Listen-Port und -Adresse konfigurierbar gemacht NTP-Zustand und synchronisierte Zeit zur Statusseite hinzugefügt Fehlerbehandlung bei Firmware-Updates verbessert Zeitzonen-Datenbank aktualisiert Übersetzungen verbessert Auslösen von Kommandos ohne Payload via HTTP GET repariert Reset-API für Konfigurationen hinzugefügt Zurücksetzen-Buttons in Webinterface-Unterseiten hinzugefügt Firmware-Probleme nach ~ 49 Tagen Laufzeit behoben Access-Point als Fallback repariert Download: ESP32 Brick, ESP32 Ethernet Brick

Firmware: WARP 2.0.8 und WARP2 2.0.9 Strompreis-Konfiguration und Ladekosten-Anzeige für Webinterface und Ladelogbuch hinzugefügt WireGuard-Unterstützung hinzugefügt Real-Time Clock Bricklet 2.0 Unterstützung hinzugefügt Fehlerbehandlung bei Firmware-Updates verbessert Freigabe-Button der Ladestromgrenzen deaktiviert falls bereits freigegeben Zeitzonen-Datenbank aktualisiert Übersetzungen verbessert Bestätigungsdialog zu Stromzähler-Reset hinzugefügt Auslösen von Kommandos ohne Payload via HTTP GET repariert Behoben, dass Stromlimits verloren gingen, wenn eine bereits aktive Ladestromgrenze aktiviert wrude (WARP2) Front-Taster und GPIO-Konfiguration persistent gemacht (durch Update auf Ladecontroller-Firmware 2.1.8) Reset-API für Konfigurationen hinzugefügt Zurücksetzen-Buttons in Webinterface-Unterseiten hinzugefügt Firmware-Probleme nach ~ 49 Tagen Laufzeit behoben Access-Point als Fallback repariert evse/start_charging und stop_charging-API-Verhalten bei nicht angeschlossenem Fahrzeug repariert Download: WARP 2.0.8 bzw. WARP2 2.0.9 Edit: Links repariert

Die entsprechende Ladestromgrenze steht auf "clear_on_disconnect": true, das ist auch korrekt. In der Stromgrenze steht aber max_current 32000, so als ob jemand start_charging aufgerufen hat. Ich habe nochmal kurz die API getestet, folgendes ist mir aufgefallen: Wenn kein Auto angeschlossen ist, Auto-Start aus ist und du den Taster drückst, dann passiert nichts, so wie man das erwarten würde. Das Webinterface lässt dich dann auch nicht auf Start klicken. Die API kannst du aber aufrufen und dann wird in die Ladestromgrenze des Auto-Starts 32000 geschrieben. Das ist inkonsistent und passt auch nicht zur Dokumentation (da steht "Ein Aufruf dieser Funktion ist äquivalent zum Starten über den Taster an der Wallbox"). Fixen wir mit der nächsten Firmware. Eigentlich hat evse/stop_charging aber das selbe Problem, d.h. wenn das auch durchgekommen ist, hätte am 20.11. morgens die Stromgrenze wieder auf 0 gesetzt werden müssen. Eventuell Netzwerk-Probleme?

Es sieht so aus als wäre das leider nicht so einfach. Die Modbus-Implementierung, die wir verwenden hat die Informationen zwar intern, aber wir können die von außen nicht einfach abfragen. Ich habe mal ein Issue aufgemacht, dass wir entscheiden müssen, ob man "schlimme Dinge" programmieren möchte, um das auszulesen: https://github.com/Tinkerforge/esp32-firmware/issues/176

Aktuell geht das nicht. Ich habe mal ein Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/175 Wir müssen aber prüfen, ob das umsetzbar ist.

Für den maximal verfügbaren Strom ist nicht nur der Strom an den Wallboxen relevant, sondern auch wie die Zuleitungen angeschlossen sind D.h. wenn du z.b. jede Wallbox mit 16 A abgesichert hast, und dein Hausanschluss aber nur mit 3x40A abgesichert ist, dann darfst du den maximalen Ladestrom höchstens auf 40A (eher weniger, du hast ja eventuell noch andere Verbraucher) einstellen. 64 A sind nur dann sicher, wenn deine Verkabelung (bis zu dem Punkt wo sich die einzelnen Wallbox-Zuleitungen auftrennen) das erlaubt. Dann lädt sie nur mit 16 Ampere. Alle aktiven Stromgrenzen (die der Dip Schalter, die des Typ-2-Kabels, des Lastmanagements usw.) werden von der Wallbox nie überschritten.

Ja. Im Idealfall ziehst du, wenn der Ladevorgang anfängt einen Debug-Report, machst dann und ziehst danach noch einen Debug-Report.

D.h. der Ladecontroller lief zumindest noch. Das ist schonmal gut. Das ist sehr interessant. In letzter Zeit häufen sich die Meldungen über genau das Problem und die letzte Firmware ist zwei Monate alt. Wir haben hier zwei Wallboxen laufen, die in der Nacht zum Samstag die 50 Tage Uptime erreichen (=2^32 Millisekunden). Eventuell haben wir uns ein Timestamp-Überlauf-Problem eingetreten (auch wenn der Code das eigentlich korrekt behandelt). Ich melde mich am Montag nochmal ;)

Firmware WARP2 2.0.91 Details hier:

Es gibt jetzt eine (vorkompilierte ;) ) zweite OCPP-Betaversion. Ich habe dafür einen eigenen Thread aufgemacht, da auch einige andere Features dazugekommen sind: OCPP-Feedback gerne weiter hier.

Moin, EDIT: Alle Features diese Beta sind in "fertiger" Version in Firmware 2.1.0 enthalten. In die zweite OCPP-Beta (siehe hier für Beta 1) habe ich weitere neue Features gepackt, die wir in den letzten Monaten hinzugefügt haben. Die Dokumentation fehlt noch, deshalb hier eine kurze Erklärung pro neuem Feature: Modbus-TCP Wenn Modbus-TCP auf der entsprechenden Unterseite im Webinterface aktiviert wird, kann der Zustand des WARP Charger per Modbus-TCP ausgelesen werden. Optional kann auch eine Ladesteuerung über Modbus-TCP erlaubt werden. Auf der Unterseite findet sich die Dokumentation der unterstützten Register. (Siehe Screenshot für einen Ausschnitt). Neben dem WARP-eigenen Registerset kann der WARP Charger die Registertablle der Keba c-Series-Wallboxen, sowie des Bender CC612/613-Ladecontrollers, der in vielen Wallboxen eingesetzt wird, emulieren. Damit sollte es möglich sein, ohne weitere Anpassungen einen WARP Charger in z.B. ein Hausautomatisierungssystem, einen Energiemanager etc. einzubinden, der eine der emulierten Wallboxen unterstützt. WireGuard Der WARP Charger kann jetzt über WireGuard VPN-Verbindungen aufbauen.Die hierfür benötigten Schlüssel müssen von Hand erstellt und auf das Webinterface eingegeben werden. Siehe hier für Details: https://www.wireguard.com/quickstart/#key-generation RTC-Unterstützung mit dem Real-Time Clock Bricklet 2.0 Wie mehrfach gewünscht, kann jetzt ein Real-Time Clock Bricklet 2.0 an einen WARP Charger (bzw. an dessen ESP32 (Ethernet) Brick) angeschlossen werden. Sobald das Bricklet erkannt wurde, wird es automatisch verwendet. Der Haupteinsatzzweck ist, dass mit dem RTC Bricklet Ladevorgänge, ohne dass eine Netzwerkverbindung bestehen muss, zeitgenau aufgezeichnet werden können. Das RTC Bricklet (und damit die Systemzeit) werden automatisch gestellt, wenn das Webinterface mit einem Browser geöffnet wird. Falls die Zeit doch über das Netzwerk synchronisiert werden kann, wird die RTC auch gestellt. OCPP - jetzt mit SmartCharging Die OCPP-Implementierung unterstützt jetzt das Smart-Charging-Profil. Damit kann der Ladestrom über OCPP gesetzt werden, Zeitpläne vorgegeben werden usw.. Getestet wurde das SmartCharging-Profil unter anderem mit der HomeAssistent-OCPP-Integration. Ansonsten arbeiten wir weiter daran, ein möglichst großes OCPP-Feature-Set zu unterstützen und mit möglichst vielen Backend-Servern zu testen. Die Entwicklung könnt ihr im OCPP-Beta-Thread verfolgen. Ich freue mich wie immer über Feedback! Grüße, Erik warp2_firmware_2_0_93_63a45ecd_merged.bin

SteVe kannst du auch in Docker laufen lassen, mache ich zumindest so.

charge_tracker ist kein eigenes Topic. Es gibt aber charge_tracker/state, charge_tracker/last_charges, charge_tracker/current_charge usw. (siehe hier: https://www.warp-charger.com/api.html#reference-charge_tracker) Die Topics sollten immer geschickt werden, wenn es eine Änderung gibt, also z.B. wenn eine getrackte Ladung beginnt.

Wenn du das das nächste Mal erzeugen kannst, zieh bitte mal einen Debug-Report und schick mir den bzw. poste ihn hier.

Beispiele mit mehreren Bricklets sind in der Tat selten. Sieh dir z.B. das hier mal an https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Rugged/Tutorial.html#tutorial-rugged-approach

Reagiert bei euch beiden die Wallbox-LED noch darauf, wenn ein Auto angeschlossen wird? Wenn das der Fall ist, aktualisiert bitte auf 2.0.8 (bzw. WARP1 2.0.7). Wir hatten in den Firmwares davor Probleme mit der WebSocket-Implementierung, die zu genau dem Verhalten geführt haben. Meines Wissens (leider ist die einzige Möglichkeit das zu testen, eine Wallbox ein paar Wochen laufen zu lassen) sollte das aber mit der jeweils aktuellen Firmware nicht mehr auftreten. Falls doch, bitte nochmal Bescheid geben!

The plot thickens: Ich habe mir einen Switch mit Port-Mirroring besorgt um den Traffic zwischen eCarUp und dem WARP Charger mitlesen zu können und folgendes festgestellt: Wenn ich eine Transaktion per App/Webseite starte, dann stoppe (das Auto angeschlossen lasse) und wieder starte funktioniert alles wie erwartet. Wenn ich aber die zweite Transaktion stoppe, dauert das im eCarUp-Webinterface ein paar Sekunden länger, der Status springt dann aber auf "verbunden" um. Laut Wireshark schickt eCarUp dann aber nie den RemoteStopTransaction.req, deshalb läuft die Transaktion bei uns weiter. Wenn ich dann z.B. das Auto abziehe, antwortet eCarUp nie auf den StopTransaction.req. Mit dem Switch konnte ich jetzt sehen, dass die Pakete wirklich nicht ankommen (bei RemoteStartTransaction) bzw. rausgehen aber von eCarUp nicht bestätigt werden (StopTransaktion). D.h. nach meinem Verständnis liegt das Problem nicht bei uns. Ich habe den eCarUp-Leuten mal einen Bugreport geschickt.

Kurzes Update: Ich schaffe es jetzt auch auf verschiedene Arten, dass eCarUp-App und Webseite einen anderen Zustand anzeigen als tatsächlich der Fall ist (im Extremfall sogar dass eine Transaktion läuft aber eCarUp sagt das die schon beendet wurde). Aber es gibt auch eine gute Nachricht: wss funktioniert wieder. Das muss auf deren Servern für ein paar Tage kaputt gewesen sein.