rtrbt

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.

Ich teste selber noch gegen andere OCPP-Server, aber ansonsten wars das. Wir versuchen außerdem an das offizielle OCPP-Test-Tool zu kommen, das dauert aber vermutlich noch etwas.

Ich habe erstmal eingebaut, dass der interne Zustand der OCPP-Implementierung im Webinterface angezeigt wird: https://github.com/Tinkerforge/esp32-firmware/commit/49f9e241514325584d251e108ddff23f12b6bcb4 Ich versuche jetzt nochmal, deine Probleme zu reproduzieren, vielleicht bekommen wir mit den zusätzlichen Ausgaben mehr raus.

Korrekt. Der ESP schreibt dann nie einen Strom > 0 in die Benutzer-Ladestromgrenze (die auf dem EVSE liegt) Laut der Daten hat sich also mindestens der ESP in der Nacht vom 7. auf den 8. aufgehangen. Falls du das nochmal erzeugt bekommst, versuche mal, ob du den ESP noch anpingen kannst und ob (notfalls über den Access-Point des ESPs) du auf http://10.0.0.1/recovery (bzw. eine andere IP wenn du nicht über den ESP-Access-Point gehst) kommst. Falls ja zieh da mal einen Debug-Report.

Im Moment sollten deine Module noch funktionieren, weil ich jedes Frontend-Modul erstmal einzeln nach Preact umgestellt habe. Es steht noch aus, das Seiten-Template ansich umzuschreiben. Wenn wir das implementiert haben und du das nachziehen willst, musst du dann deine Module umstellen.

Das ist wirklich interessant: Die LED wird vom Ladecontroller (dem EVSE Bricklet) gesteuert. Die Ladecontroller-Firmware ist so ausgelegt, das selbst wenn der ESP-Brick (über den läuft das Webinterface, MQTT, usw.) nicht funktioniert, das Laden (und die LED) weiterlaufen. Wenn also nicht mal die LED angeht, wenn du ein Auto ansteckst, dann muss der Ladecontroller selbst hängen. Mir ist ehrlicherweise unklar, wie das passieren kann. Ich habe gerade getestet, wie sich der ESP-Brick in dem Fall verhält, aber außer vielen Fehlermeldungen im Ereignis-Log der Form 2022-11-08 12:53:13,767 all_data_1 -1 funktioniert alles wie erwartet. Die APIs unter evse/ aktualisieren sich dann nicht mehr, aber prinzipiell bleiben Webinterface, MQTT usw. erreichbar. D.h. irgendwie müssen sowohl EVSE, als auch ESP bei dir (unabhängig voneinander?) in ein Problem laufen. Wir bauen für die nächste Firmware mal ein, dass das EVSE-Bricklet und der ESP-Brick jeweils neustarten, falls die Kommunikation eine lange Zeit gestört ist (z.B. weil eben die andere Komponente hängt). Ob das bei deinem Problem hilft ist mir aber unklar. Je nachdem welche Daten du in deine Datenbank geloggt hast könnten wir vielleicht erkennen, ob sich der Ladecontroller zuerst aufgehangen hat. Hast du einen der häufig wechselnden Werte in die Datenbank geschrieben? (z.B. irgendetwas aus evse/low_level_state).

If you only want to change the prefix (i.e. tinkerforge/) you can use the --global-topic-prefix command line argument:https://www.tinkerforge.com/en/doc/Software/API_Bindings_MQTT.html#topic-prefix To also change the suffix to /config, you have to write your own script or change the bindings. (You can techically add a suffix to any tinkerforge-topic however home assistant does not allow node_ids with / in them so this doesn't work in your case)

Deine Firmware ist älter als die global_current_update-API. Aktualisiere die Wallbox mal auf Firmware 2.0.8 (findest du hier: https://www.warp-charger.com/warp2.html#firmware) dann sollte es gehen.

Korrekt.

Ah sorry, hatte ich schon am Freitag: https://github.com/Tinkerforge/tfocpp/commit/0db43d863f58b7b84914b4c37d060ec3f62006ef Habe gerade esp32-firmware gepusht, sollte jetzt auf den aktuellen tfocpp-Commit verweisen.

Eigentlich sollte das gehen. Zieh bitte mal einen Debug-Report (unter System->Ereignis-Log) und poste ihn hier.

Wenn der Taster nicht angeschlossen ist, ist das für die Wallbox so als ob der Taster permanent gedrückt ist (bzw. als ob der Schlüsselschalter auf deaktiviert steht).

Hm das ist keine schlechte Idee. Habe mal ein Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/172

Leider noch nicht.

Wie hast du es hier geschafft, einen zweiten RemoteStartTransaction.req zu schicken, wenn schon eine Transaktion läuft? Ich habe das gestern Nachmittag probiert, eCarUp lässt mich aber wenn eine Transaktion läuft (dann steht in deren Webinterface als Status "Besetzt"), nicht nochmal auf "Activate" klicken, stattdessen kann ich nur mit "Deactivate" ein RemoteStopTransaction.req schicken. Abgesehen davon muss ich nochmal die Spezifikation überfliegen, wie genau ein RemoteStartTransaction zu beantworten ist, wenn schon eine Transaktion läuft. Das war kaputt. Weil ich da direkt von TRANSACTION nach IDLE gehe, schicke ich nie die StopTransaction-Nachricht raus. Habe ich gerade gefixt.

Nein, das müssen wir in der Firmware fixen. Das Logging war einfach bisher nicht darauf ausgelegt, dass man es länger als ein paar Minuten laufen lässt. Genau.

Die Zählerwerte sind gefühlt das komplizierteste an OCPP. Grundlegend läuft das so, dass der Server der Wallbox vorgeben kann, welche Zählerwerte periodisch (clock-aligned, also z.b. "immer zur vollen Stunde") und in einem Intervall während Transaktionen ("sampled", also z.B. "nach Transaktionsbeginn minütlich bis Transaktionsende") übertragen werden sollen. Außerdem konfiguriert der Server die Periode bzw. Intervalllänge. Je nach der Konfiguration muss die Wallbox dann von sich aus MeterValues-Nachrichten schicken, die diese Werte beinhalten. D.h. das ist der Teil, den entweder eCarUp nicht konfiguriert (wüsste spontan auch nicht, wo im eCarUp-Webinterface die Werte angezeigt werden sollten), oder der bei uns kaputt ist. Zusätzlich dazu kann eine StopTransaction-Nachricht auch Zählerwerte enthalten (wieder jeweils verschiedene für clock-aligned und sampled!), die dann über die gesamte Transaktion gesammelt werden müssen. Den Teil unterstützen wir im Moment nicht, weil dann je nach Server-Konfiguration der RAM einfach zu klein ist (z.b. wenn man sekündlich alle Werte aufzeichen soll und eine Transaktion ja beliebig lange dauern kann). Glücklicherweise gibt es Konfigurationswerte mit denen ich dem Server mitteilen kann, wie viele Messwerte maximal in einer StopTransaction-Nachricht enthalten sein können. Das habe ich einfach auf 0 gesetzt. Außerdem gibt es noch die direkten Energiewerte in Start- und StopTransaction. Die müssen immer enthalten sein und sind einfach der Zählerstand beim Start bzw. Ende der Transaktion.

Nein ich habe nur Freitag Nachmittag Dinge programmiert und nicht richtig getestet. ocpp/txn_msg ist ein Ordner und die remove_directory-Funktion löscht nicht rekursiv Unterordner. Habe das gerade gefixt:https://github.com/Tinkerforge/esp32-firmware/commit/8d50f811239842b5a9df0dac577efca8a7027177

Hm im Debug log fehlen leider die interessanten Einträge. Da ist das Webinterface vermutlich in eine String-Längenbeschränkung gelaufen, weil die Aufzeichnung so lange lief. Das müssen irgendwie besser implementieren. Habe dazu mal ein Issue aufgemacht:https://github.com/Tinkerforge/esp32-firmware/issues/171 Ich dachte erst, dass du eventuell einen Bug in Kombination mit EVCC hast, aber die 45-Sekunden-Ladevorgänge treten auch auf, wenn gerade keine MQTT-Verbindung besteht. Ich habe mir das Charge Log nochmal angesehen. Auffällig ist, dass die 45-Sekunden-Ladevorgänge immer nach einem "normalen" lang laufenden Ladevorgang passieren. Vielleicht tritt das Problem nur auf, wenn das Auto voll ist. Kannst du testweise mal das Auto an die Wallbox hängen wenn es noch zu ~ 95% voll ist, es voll laden und dann nachsehen ob die kurzen Ladevorgänge wieder passieren? Das sollte auch auffallen wenn du an der Wallbox vorbeigehst. Ich würde erwarten, dass das Schütz dann alle 45 Sekunden schaltet.