Fix Alfen OCPP Authorization Flow #16088
Conversation
Mir wäre nicht klar, wofür? Die Authorisierung macht die WB, nicht evcc. |
Co-authored-by: andig <[email protected]>
| @@ -21,6 +21,14 @@ func (cp *CP) Authorize(request *core.AuthorizeRequest) (*core.AuthorizeConfirma | |||
| }, | |||
| } | |||
|
|
|||
| // Set idTag for all connectors in available state | |||
There was a problem hiding this comment.
Das fühlt sich komisch an. Wenn die WB das Tag bei der Initialisierung mit gibt- warum ist das hier notwendig?
There was a problem hiding this comment.
Korrigier mich wenn ich falsch liege aber die Logik aus dem init / cp_setup läuft beim Start wenn der erste Kontakt mit der Wallbox aufgenommen wird. Hier werden die Einstellungen abgeglichen und z.B. die Plug and Charge ID übernommen (falls konfiguriert).
Der Auth / cp_core wird ausgeführt wenn eine RFID Karte an die Wallbox gehalten wird um eine neue Transaktion zu autorisieren. Hier können wir also den idTag für den bevorstehenden Ladevorgang abgreifen.
Die Art und Weisse wie man das am besten machen kann ohne den konkreten Connector zu kennen ist wohl die große Frage.
Das stimmt wohl in den meisten Fällen allerdings kommt das im OCPP Fall (mit RFID Auth) sehr auf die Konfiguration der Wallbox an. Bei meiner Alfen Wallbox sieht das ganze so aus.
Wenn ich nun die Autorisierung über die Lokale Whitelist auf der Wallbox handle bin ich mir nicht sicher ob der Auth Request immer noch an den OCPP Server gestellt wird oder ob dieser Schritt überprungen wird und direkt die Start Transaction Anfrage rausgeht. In dem Fall wird der idTag allerdings nicht an evcc geschickt. Die Alternative ist das man die Wallbox zwingt die Auth Requests an den OCPP Server zu schicken, hier sollte es jetzt egal sein ob die Lokale Whitelist aktiv ist der OCPP Server sagt ja immer "ja" was die Lokale Whitelist überschreibt (use-case bei OCPP ist wohl Neuer Benutzer verwendet die Wallbox ist dem Server aber bekannt). Wir brauchen also eine Kombination aus Lokaler Whitelist und Auth Request an den OCPP Server, falls das nicht Möglich ist müsste der Server also wissen ob der idTag laden darf oder nicht. Hier die Screenshots aus den Wallbox Einstellungen.
|
Das verwendete idTag wird IMMER mit StartTransaction ans CS gesendet. Die Entscheidung ob eine Karte tatsächlich zu einer Ladefreigabe durch evcc führen kann ist nicht von der Akzeptanz einer Karte oder eine Transaktion mit einem bestimmten idTag abhängig. Wir arbeiten hier, wie bei allen anderen Boxen auch, mit Default-Mode "off" und einer Freigabe über den Default-Modus eines (erkannten) Fahrzeugs. Für die Fahrzeugerkennung kann ein RFID-Tag verwendet werden. Dies erfährt evcc eben über StartTransaction. |
Alles klar, habe gerade noch mal etwas auf dem Parkplatz getestet und musste feststellen das meine Wallbox kein StartTransaction Request rausschickt weshalb die Logik auch nicht laufen konnte. Der Auth Request wird gesendet und anschließend beginnt direkt der Ladevorgang, klingt also ganz nach Fehlkonfiguration. Ich habe auch mal getestet was bei den aktuellen Wallbox Einstellungen passiert wenn ich einen neuen RFID Tag vorhalte und musste wie vermutet feststellen das er auf die Lokale Whitelist übernommen wurde was aber wenn ich dich richtig verstehe so gewollt ist? Heisst es kann zwar jeder fremde seine Karte vorhalten aber der Ladevorgang / die Autorisierung erfolgt erst über StartTransaction bzw. über die idTags die am vehicle konfiguriert sind? Ich teste jetzt mal ob sich die OCPP Auth Requests komplett abschalten lassen und ob ich das Setting finde das für die StartTransaction Requests zuständig ist. Update nach dem Testen In den Online/Offline Settings der Wallbox (siehe Screenshot von oben) habe ich "Pre Authorize with local lists" ausgewählt, zuvor war "Wait for authorization by BackendOffice" aktiv. Eine andere Einstellung gibt es hier nicht.
Unter Connectivity / Transaction data habe ich die Message attempts von 0 (factory default) auf 3 gestellt.
Ansonsten habe ich keine Einstellungen gefunden die deaktiviert sind bzw. offensichtlich etwas mit den transactions zutun haben. Habt ihr noch eine Idee? Anbei meine evcc.yaml + die Logs von Wallbox und evcc, hier sieht man ja auch das Konfigurationsobject das von der Wallbox an evcc geschickt wird. Eventuell sieht man hier welcher Key nicht passt? https://gist.github.com/egnerfl/e80fa562abf19af28d9fcc83cfac6051 Die tatsächlichen RFID Tag IDs habe ich gegen DEBUG_TAG_UNKOWN und DEBUG_TAG_KOWN ausgetauscht. Danke für eure Hilfe! |
|
Es braucht weder eine "Local List" noch eine "White List" noch irgendwelche Einträge darin. Einfach der OCPP-Standard-Flow für öffentliche Ladepunkte. |
|
Alles klar, danke dir. Habe die Wallbox jetzt komplett auf Werkseinstellungen zurückgesetzt und nun gehen endlich startTransaction Requests raus und die Identifikation funktioniert. Das Verhalten mit dem Auth Request macht so auch Sinn und die Plug and Charge Sonderlogik auch. Keine Ahnung was mit der Wallbox los war das sie sich so verhalten hat. Das Ding hat mich echt wahnsinnig gemacht. |
Hallo, erstmal Danke für all die Arbeit / Zeit die Ihr in evcc steckt. Ich habe selten solche gut maintainten Open Source Projekte gesehen 👍
Hier auch die Warnung bzw. der Hinweiss das ich wenig Erfahrung mit go habe und gerade deswegen äusserst Dankbar für jegliches Feedback / Änderungsvorschläge bin.
Jetzt zum eigentlichen PR
Ich habe versucht meine Alfen Wallbox über OCPP mit evcc zu verbinden und hatte hierbei einige Probleme die ich mit diesem PR beheben möchte.
1. ID Tag - OCPP Authorize (Enhancement)
Die Alfen Wallbox sendet leider nur den ID Tag beim
Authorizerequest, hier gab es bereits ein Issue in dem besprochen wurde das man hierbei ja einfach den IdTag am Connector setzten könnte was zumindest im Fall von einem einzelnen Connector kein Problem darstellen sollte. Irgendwie scheint sich dieses Issue jedoch im Sand verlaufen zu haben bzw. wurde durch einen anderen PR geschlossen der aber an derAuthorizefunction nichts veränderte.Mein Gedanke war das es eigentlich kein Problem sein sollte für alle verfügbaren Connectors den idTag zu setzten. Hierdurch werden laufende Ladevorgänge nicht verändert.
Vermutlich ist mit dem check auf
ChargePointStatusAvailablenicht jeder Randfall abgedeckt, hier wäre euer Feedback also sehr wichtig.Alternativ könnte man auch einfach wie ursprünglich besprochen prüfen ob es nur einen Connector gibt und nur dann die ID setzten.
Zum Thema OCPP Auth hatte ich mich auch gefragt ob etwas gegen eine einfache "authorized_tags" Liste in der config sprechen würde? Ist nichts für diesen PR aber wenn das für euch gut klingt würde ich das implementieren.
2. Alfen - Plug and Charge (Bugfix)
Der Alfen
PlugAndChargeIdentifierüberschreibt immer den IdTag des Connectors.In nicht eichrechtskonformen Alfen Wallboxen lässt sich "Plug and Charge" aktivieren, hierzu muss man in der Wallbox eine ID hinterlegen die dann anstelle der RFID Tag ID gesetzt wird. Das Problem an der aktuellen Implementierung in evcc hierbei ist das immer die PlugAndCharge ID verwendet wird auch wenn das Feature nicht aktiv ist.
Die sauberste Lösung hierzu wäre vermutlich den
AuthorizationMethodzu checken der in der selben OCPP Response vorhanden ist, im RFID Tag Fall wird hier "RFID" gesetzt. Den Plug and Change Fall konnte ich leider nicht testen da ich eine Eichrechtskonforme Wallbox habe und dort seit einigen Firmware Versionen Plug and Change nichtmehr zur Verfügung steht.Danke für eurer Feedback!
VG,
Florian