rtrbt

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

Leider noch nicht.

On 11/2/2022 at 2:40 PM, poohnet said:

2022-11-01 09:58:36,030  Received RemoteStartTransaction.req for connector 1 and tag B7YKBU4DF5A8G5FE3VVQ
2022-11-01 09:58:36,041  Sending RemoteStartTransaction.conf Accepted
2022-11-01 09:58:36,057  Ignoring remote start transaction in state TRANSACTION

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.

On 11/2/2022 at 2:40 PM, poohnet said:

2022-11-01 10:00:00,049  Unexpected EVSEState 0 while Connector is in state 8. Aborting transaction!
2022-11-01 10:00:00,049  TRANSACTION -> IDLE

Das war kaputt. Weil ich da direkt von TRANSACTION nach IDLE gehe, schicke ich nie die StopTransaction-Nachricht raus. Habe ich gerade gefixt.

19 hours ago, gustavpaula said:

Kann ich da irgendwas  verbessern beim nächsten Log? Gibt es Stufen der Mitteilsamkeit? (Verbosity)

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.

19 hours ago, gustavpaula said:

Wenn du mit "voll" 100% geladen meinst:  Ich lade nur bis 80%. Meinst du vielleicht, das Problem tritt auf, wenn das Auto sagt "ich bin satt" und den Ladevorgang  beendet?

Genau.

On 10/29/2022 at 2:11 PM, poohnet said:

Wie funktioniert die Übertragung des Zählerstands denn grundsätzlich? Wenn ich meinen Wagen unterwegs über die eCharge-App lade, dann erhalte ich auch regelmäßige Updates des Zählerstands...

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.

On 10/28/2022 at 9:12 PM, poohnet said:

Hast du irgendeine Idee, warum die Datei nicht gelöscht werden kann? Ist sie vielleicht noch durch irgendetwas im Hintergrund geöffnet?

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.

22 hours ago, gustavpaula said:

Das hab ich jetzt mal gestartet, aber kann das über Wochen laufen??

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.

3 hours ago, poohnet said:

Das ist sicherlich keine schlechte Idee (gerade jetzt in der Betaphase), denn selbst das Trennen der Stromversorgung hat nicht geholfen und die WARP wird bei eCarUp nun als "inaktiv" angezeigt.

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:

Quote

It is likely that The Central System applies sanity checks to the data contained in a StopTransaction.req it
received. The outcome of such sanity checks SHOULD NOT ever cause the Central System to not respond with a
StopTransaction.conf. Failing to respond with a StopTransaction.conf will only cause the Charge Point to try the
same message again as specified in Error responses to transaction-related messages.

(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.

3 hours ago, poohnet said:

Baut ihr auch eine regelmäßige Übertragung des Zählerstands mit ein, z. B. alle fünf Minuten?

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.

14 hours ago, michael99 said:

Warum also werden nicht plausible Beispiele vorgegeben? Das würde es doch einfacher machen.

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.

wss sollte eigentlich gehen, probiere ich gleich nochmal aus.

Ich gehe davon aus, dass die Ladeprobleme von den kaputten Zeiten kommen. Das ist ein Problem mit dem iso8601-Zeitstempel-Parser, das ich eigentlich behoben hatte, aber scheinbar habe ich den Fix beim Einbinden von TFOCPP als Abhängigkeit wieder verloren. Das muss ich nochmal kurz nachvollziehen.

16 hours ago, poohnet said:

Die Heartbeats kommen für Connector 0, die Steuerungsbefehle für Connector 1. Gibt's da vielleicht noch irgendwo ein "+/-1 Problem"? Oder muss der Ladepunkt bei eCarUp noch weiter konfiguriert werden?

Das muss so sein: OCPP ist darauf ausgelegt, dass du pro Charge Point mehrere Connectoren haben kannst (wie bei so einer großen DC-Ladesäule an der Autobahn z.B.). Connector 0 addressiert den ganzen Charge Point und die eigentliche Verbindung zum Auto geht dann bei uns immer über Connector 1.

Und ich dachte beim Einfügen der Funktionen noch "Das brauchen wir erstmal nur im EVSE_V2" :D Zieh mal bis 887f0e95 nach, dann sollte es gehen.

Das OCPP-Modul ist jetzt im esp32-firmware-Git. (Sorry hatte es heute erst geschafft. Da hing mehr dran als ich in Erinnerung hatte.)

Edit: Bau am besten gegen den Stand von 8aef2cd4, das sollte funktionieren.

Stimmt, das fehlt im Repo. Kommt morgen.

Prinzipiell ist es keine gute Idee, wenn du in einer Schleife ohne irgend eine Art von Limitierung die GUI zu verändern. Außerdem solltest du mal testen, ob die Schleife überhaupt beendet wird. Ersetze den Code-Schnipsel mal durch z.B.

Do Until volt > 2
    txt_Motor_Lift_Pos.Text = "volt " & volt
    Thread.Sleep(100)
Loop

Dann solltest du sehen können, was die Schleife tut.

Okay ich habe raus, was da schief gelaufen ist. Die Firmware hält sich an einer Stelle nicht an die Spezifikation (Nachrichten mit einer Liste von Stromzählerwerten müssen mindestens einen Wert enthalten), das versucht die OCPP-Integration von Home Assistant als Fehler zu melden, hält sich aber dabei selbst nicht an die Spezifikation und das wiederum versteht die Firmware dann nicht. Daraus entsteht dann die deserialize-Katastrophe.

Ich habe das Problem in der OCPP-Integration bzw. in der Bibliothek die diese verwendet, mal gemeldet: https://github.com/mobilityhouse/ocpp/issues/381 Den Rest fixe ich gerade auf unserer Seite.

Das sieht interessant aus, danke! Gerade die JSON-Fehler muss ich mir mal genauer ansehen. Ich verwende da einen sehr minimalistischen Serializer, den ich eventuell an einer Stelle falsch benutze.

Das lag soweit ich das sehe an den Umbauten in der Config, die ich gemacht habe. Mit https://github.com/Tinkerforge/esp32-firmware/commit/102d7967be99aba3ba4c197675cd8553cbd23de4 sollte es wieder funktionieren. Sorry dafür.

Ja, das geht. (Auch mit mehr als 2 Karten)

Moin,

Kannst du das Problem mit der Firmware im Anhang immer noch erzeugen? (Nicht von der Versionsnummer verwirren lassen: Das ist ein Abkömmling der OCPP-Beta-Firmware, aber ohne dass OCPP reinkompiliert ist)

warp2_firmware_2_0_90_63453d05_merged.bin

On 10/2/2022 at 5:51 PM, Little_Company said:

Das ist ja wunderbar für alle warp2 User, allerdings habe ich da nichts davon. Meine Frage zielte auf den Warp1 Pro welcher gerade einmal 1 Jahr in meiner Garage hängt und nun diese wichtige Unterstützung wenn ich es richtig gelesen habe nicht bekommen soll...

Sorry, hatte überlesen, dass du von Warp1 redest. Prinzipiell ist es so, dass es die OCPP-Beta erstmal nur für Warp 2 gibt. Wenn das ganze "Feature-Complete" ist, werden wir uns nochmal in Ruhe ansehen, ob wir OCPP auf Warp 1 zum Laufen bekommen.

On 10/9/2022 at 9:15 PM, poohnet said:

 Was meinst du? Setzt die OCPP-Implementierung auch den neuen Ladecontroller voraus oder würde der o. g. Weg funktionieren? Einen ESP32-Ethernet-Brick habe ich bereits und Firmware-Anpassungen habe ich ja mittlerweile auch schon mehrere durchgeführt. OCPP würde mich nämlich ebenfalls interessieren…

Nein, OCPP geht auch mit dem alten Ladecontroller. Das ist im Moment ein reines RAM-Verbrauchsproblem vs. die Priorisierung die wir natürlich vornehmen müssen um überhaut mal was fertig zu bekommen ;)