rtrbt

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.

Nein, das Ladeprotokoll solltest du max. ein paar Minuten laufen lassen. Du musst eher, wenn das Problem auftritt, das Protokoll starten, ~ 30 Sekunden laufen lassen und das dann runterladen. Das hat natürlich das Problem, dass du das mitbekommen musst, während es passiert.

Habe ich gepusht. Der große rote Knopf tritt einmal den kompletten OCPP-Zustand weg. Danach sollte es wieder funktionieren. Mich wundert es trotzdem, dass die Wallbox und der eCarUp server sich aus dem Zustand nicht befreien können: Nach dem Neustart wird der StopTransaction.req ja neu geschickt, danach müsste laut Spec der Server mit einer StopTransaction.conf antworten: (D.h. selbst wenn der Server damit nichts anfangen kann soll er das tun, damit eben nicht die Wallbox hängen bleibt) Die Situation kann auch auftreten, wenn die Wallbox ewig lang offline war und währenddessen mehrere komplette Transaktionen durchgeführt hat (was erlaubt ist, man kann z.B. einen Auth. Cache für die Tags haben). Das das RemoteStopTransaction rejected wird, ergibt Sinn, nur die Fehlermeldung ist falsch, da passte nicht die Connector-ID nicht, sondern die Transaktions-ID. Der Server sagt der Wallbox im Endeffekt "stoppe bitte Transaktion ABC123" und wenn es die nicht gibt muss die Wallbox mit rejected antworten. Lange Rede kurzer Sinn: gib Bescheid, falls du das nochmal auslösen kannst. Ich habe das Problem hier spontan nicht erzeugen können. Gibt es rein technisch gesehen schon, habe aber noch nicht rausgefunden wie eCarUp das konfigurieren will.

Sorry für die späte Antwort, wir mussten erstmal ein iPad besorgen zum reproduzieren des Problems. Hier klappt es aber problemlos (mit iPad OS 16.1). Machst du, damit die Fehlermeldung kommt irgendetwas anderes als das Webinterface zu laden, auf System->Benutzerverwaltung zu gehen, den Namen zu ändern und das zu speichern? Zieh am besten mal einen Debug-Report und häng ihn hier an, eventuell ist das ein Problem mit deiner spezifischen Konfiguration.

Haben wir vor, bisher hatte nur keiner Zeit das zu implementieren:https://github.com/Tinkerforge/esp32-firmware/issues/53 (Die Dokumentation wird von einem Python-Script erstellt, das dann auch Beispiel-Befehle erzeugen können sollte) Tippfehler in MQTT-Topic-Namen sind tatsächlich ein Problem. Ich habe mal ein paar Issues dafür (und für Key-Namen in JSON-Objekten) aufgemacht, damit die Wallbox da mehr Fehlermeldungen ausspuckt, wenn man was falsch macht: https://github.com/Tinkerforge/esp32-firmware/issues/167 https://github.com/Tinkerforge/esp32-firmware/issues/168 https://github.com/Tinkerforge/esp32-firmware/issues/169

Der Teil ist interessant: 2022-10-27 18:53:02,947 Received RemoteStopTransaction.req 2022-10-27 18:53:02,957 TRANSACTION -> FINISHING_UNLOCKED 2022-10-27 18:53:02,958 Attempting to send stop transaction but next stop reason is none! 2022-10-27 18:53:03,020 Unexpected EVSEState 4 while Connector is in state 10 2022-10-27 18:53:03,021 Sending StatusNotification.req: Status Finishing for connector 1 2022-10-27 18:53:03,045 Sending StopTransaction.req at connector 1 for tag at 724.372 kWh. StopReason 11 2022-10-27 18:53:03,046 Sending RemoteStopTransaction.conf Accepted 2022-10-27 18:53:03,173 Received message [3, "107", {}] (len 14) 2022-10-27 18:53:03,174 Received StatusNotification.conf for connector 1 Es sieht so aus als ob der Server das StopTransaction nicht akzeptiert. Deshalb wird die Nachricht nach Neustarts der Wallbox auch immer wieder geschickt. StopTransaction ist eine "transaction-related message" laut Spezifikation und solche Nachrichten 1. muss ich immer wieder schicken, bis der Server sie akzeptiert und 2. müssen die in der korrekten Reihenfolge übertragen werden, d.h. ich kann erst wieder ein StartTransaction schicken, wenn das Stop durchgegangen ist. Es gibt da eine Chance wieder in den "normalen" Zustand zu kommen, und zwar wenn der Server mehrfach meldet, dass er die Nachricht nicht parsen konnte. Dann darf ich sie nach X Versuchen wegwerfen. Ich muss das hier mal reproduzieren, in der Hoffnung, dass ich sehe warum der Server das StopTransaction ablehnt. Damit sollten wir rausbekommen was das Problem ist. Abgesehen davon baue ich mal einen Button ins Webinterface, damit du die persistierten Nachrichten löschen kannst.

Kommt in den nächsten Tagen. Dann hoffentlich gleich mit einem Prototypen des Smart-Charging-Profils. Damit kannst du dann per Home Assistant auch den Ladestrom setzen.

@poohnet Nach einem kurzen Kampf mit Build-Systemen sollte es jetzt klappen und bei dir auch gleich die aktuelle arduino-esp32- und tfocpp-Version runterladen. Geh mal auf Commit 54236351.