evcc-io
Ocpp: fix connector not de-registered
Refs https://github.com/evcc-io/evcc/issues/19761
@mfuchs1984 ich hab jetzt mal stumpf Claude bemüht und zumindest ein Teilproblem gelöst. Das könnte ggf. schon passen solange die stationid gefüllt ist. Könntest Du mal ein Auge drauf werfen? Evtl. fehlt noch das canceln des Contexts im richtigen Moment?
Habe es gerade getestet (mit station ID). Das wiederholte "Prüfen" funktioniert jetzt, der Fehler dort taucht nur noch auf, wenn man zu schnell ist, weil der context cancel dauert etwas länger als das Anzeigen der Fehlermeldung. Damit kann man wohl leben, beim nächsten Klick klappts dann. Aber: drückt man dann final auf "Überprüfen & Speichern", landet man wieder im Fehler, da dann der connector wieder neu resgistriert wird. Ein cancel zwischendrin gibts ja nicht, das das Prüfen vorher erfolgreich war.
Aber: drückt man dann final auf "Überprüfen & Speichern", landet man wieder im Fehler, da dann der connector wieder neu resgistriert wird. Ein cancel zwischendrin gibts ja nicht, das das Prüfen vorher erfolgreich war.
@naltatis wir müssen das zu Testzwecken angelegte Gerät wieder abräumen damit das funktionieren kann.
Bin nächste ab übermorgen eine Woche im Urlaub, versuche es vorher noch unterzubringen, kann aber nicht versprechen, dass es klappt.
Ich hab gerade getestet. Mit dieser Änderung klappt das "Prüfen" und auch das nachfolgende "Anlegen" eines OCPP Ladepunkts.
Voraussetzung ist, dass es einen Client gibt, der sich erfolgreich connected. Das wird durch das UI heute noch nicht klar. Hier überleg ich mir was.
Was noch nicht funktioniert:
- Aktualisieren (und Prüfen) von Änderungen eines bestehenden OCPP chargers bei gleichbleibender StationId. Anwendungsfall: OCPP Parameter anpassen.
Wir haben auch noch ein grundlegendes Problem beim Hochfahren. Verbindet sich kein OCPP Client während des Boots kommt die Weboberfläche nicht wieder hoch und der Nutzer hat keine Chance mehr etwas zu machen (bspw. Charger löschen). Ich habe mit dem connectTimeout rumgespielt (default 5m). Aber auch nach Ablauf des Timeouts kommt evcc nicht hoch.
Mindestanforderung: Kurzes Timeout beim Starten einführen damit der Nutzer mind. löschen/editieren kann Wunschlösung: Sofortiger Start ohne auf OCPP Client zu warten (lazy connect). Verbunden/Nicht-Verbunden Status (OCPP) wird im UI angezeigt.
Bei ocpp Wallboxen muss man wohl mit sehr langen timeouts rechnen. Verbinde ich meine (Bender Controller) per ocpp, kann ich sehr schön in ihren logs beobachten, dass sie den reconnect erst nach einem timeout mit Zufallsfaktor versucht. Dieses kann durchaus auch mal 10 Minuten betragen. ich vermute damit sollen die backends nach Ausfällen vor massenhaften gleichzeitigen connects geschützt werden. Das deckt sich auch mit Beobachtungen aus Diskussionen und issues hier, viele ocpp Wallboxen brauchen unter Umständen sehr lange bis zum connect. Das ist natürlich ein grundlegender Unterschied zu bspw. Modbus.
Aber auch nach Ablauf des Timeouts kommt evcc nicht hoch.
Mhm, das ist komisch- mindestens müsste der Timeout funktionieren. Das ist ein Bug.
Mindestanforderung: Kurzes Timeout beim Starten einführen damit der Nutzer mind. löschen/editieren kann
Das wäre ein Feature: OCPP immer hochfahren und temporär Fehler zurück geben. Aktuell keine gute Lösung da wieder das Problem besteht, dass die technischen Eigenschaften zu dem Zeitpunkt noch nicht feststehen. Das ist analog "Starten wenn Geräte nicht da".
Voraussetzung ist, dass es einen Client gibt, der sich erfolgreich connected. Das wird durch das UI heute noch nicht klar. Hier überleg ich mir was.
Weitere Verbesserung.
Bleibt aber die Frage: ist das hier jetzt nicht besser als gar nix und wir sollten den schonmal mergen?
Mindestens für den Start brauchen wir eine ordentliche Lösung. Aktuell kommst du damit nicht mehr an dein System ran und muss in der Datenbank rumfummeln (Ladepunkt und Charger löschen) um wieder Zugriff zu bekommen.
Dieses kann durchaus auch mal 10 Minuten betragen.
Ah Interessant. Ich hab das hier mit meinem Go-e getestet. Der verbindet sich quasi "instant".
Mindestens für den Start brauchen wir eine ordentliche Lösung. Aktuell kommst du damit nicht mehr an dein System ran und muss in der Datenbank rumfummeln (Ladepunkt und Charger löschen) um wieder Zugriff zu bekommen.
Ja, das ist aber völlig unabhängig von diesem PR der Fall. Oder meinst Du das ins UI zu bringen macht das Problem größer?
Oder meinst Du das ins UI zu bringen macht das Problem größer?
Definitiv. Aus der yaml kannst du es immer wieder rauslöschen. Da hat der Nutzer das ja auch selbst reingeschrieben.
Wenn wir ihn was im UI erstellen lassen was er nicht wieder loswerden kann ist das ein großes Problem.
Den Update-Fall können wir meinet wegen in nem separaten PR behandeln. Da könnte man sich mit Löschen und Neuanlagen behelfen.
@naltatis ich kanns nicht reproduzieren:
type: ocpp
connecttimeout: 5s
[main ] FATAL 2025/08/01 13:53:04 charger [charger_2] cannot create charger 'charger_2': cannot create charger type 'ocpp': timeout
[main ] FATAL 2025/08/01 13:53:04 will attempt restart in: 15m0s
Weitere Tests kann ich nicht machen, da es leider immer noch nicht möglich ist, einen Charger nach Fehler dennoch anzulegen:
[httpd ] ERROR 2025/08/01 17:28:43 http: panic serving [::1]:53851: runtime error: invalid memory address or nil pointer dereference
goroutine 470 [running]:
net/http.(*conn).serve.func1()
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:1947 +0xb0
panic({0x103056c80?, 0x105f39a70?})
/opt/homebrew/Cellar/go/1.24.5/libexec/src/runtime/panic.go:792 +0x124
github.com/evcc-io/evcc/charger.(*OCPP).Status(0x105f42b00?)
/Users/a25058/htdocs/evcc/charger/ocpp.go:207 +0x18
github.com/evcc-io/evcc/server.testInstance({0x1033c4360, 0x0})
/Users/a25058/htdocs/evcc/server/http_config_helper.go:268 +0x9f4
github.com/evcc-io/evcc/server.deviceStatusHandler({0x1036a2430, 0x14000dba2a0}, 0x140000655f8?)
/Users/a25058/htdocs/evcc/server/http_config_device_handler.go:245 +0x174
net/http.HandlerFunc.ServeHTTP(0x0?, {0x1036a2430?, 0x14000dba2a0?}, 0x1?)
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:2294 +0x38
github.com/evcc-io/evcc/server.(*HTTPd).RegisterSystemHandler.ensureAuthHandler.func17.1({0x1036a2430, 0x14000dba2a0}, 0x1400084eb40)
/Users/a25058/htdocs/evcc/server/http_auth.go:154 +0x134
net/http.HandlerFunc.ServeHTTP(0x14001701380?, {0x1036a2430?, 0x14000dba2a0?}, 0x10030b3f4?)
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:2294 +0x38
github.com/gorilla/handlers.(*cors).ServeHTTP(0x140016ae5a0, {0x1036a2430, 0x14000dba2a0}, 0x1400084eb40)
/Users/a25058/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x2d0
github.com/gorilla/handlers.CompressHandler.CompressHandlerLevel.func1({0x10369c2a0, 0x1400168c700}, 0x1400084eb40)
/Users/a25058/go/pkg/mod/github.com/gorilla/[email protected]/compress.go:141 +0x4dc
net/http.HandlerFunc.ServeHTTP(0x10330b140?, {0x10369c2a0?, 0x1400168c700?}, 0xc?)
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:2294 +0x38
github.com/evcc-io/evcc/server.jsonHandler.func1({0x10369c2a0, 0x1400168c700}, 0x1400084eb40)
/Users/a25058/htdocs/evcc/server/http_site_handler.go:80 +0xf0
net/http.HandlerFunc.ServeHTTP(0x14000ceee70?, {0x10369c2a0?, 0x1400168c700?}, 0x140000659b8?)
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:2294 +0x38
github.com/evcc-io/evcc/server.NewHTTPd.func1.1({0x10369c2a0, 0x1400168c700}, 0x1400084eb40)
/Users/a25058/htdocs/evcc/server/http.go:54 +0x100
net/http.HandlerFunc.ServeHTTP(0x1400084ea00?, {0x10369c2a0?, 0x1400168c700?}, 0x105fa0220?)
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:2294 +0x38
github.com/gorilla/mux.(*Router).ServeHTTP(0x14000e7a780, {0x10369c2a0, 0x1400168c700}, 0x1400084e8c0)
/Users/a25058/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0x194
net/http.serverHandler.ServeHTTP({0x140017001b0?}, {0x10369c2a0?, 0x1400168c700?}, 0x6?)
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:3301 +0xbc
net/http.(*conn).serve(0x140016ae120, {0x1036a50e0, 0x140016f3650})
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:2102 +0x52c
created by net/http.(*Server).Serve in goroutine 1
/opt/homebrew/Cellar/go/1.24.5/libexec/src/net/http/server.go:3454 +0x3d8
stationid ist jetzt bei UI-Anlage erforderlich. Damit ist https://github.com/evcc-io/evcc/pull/22115 keine blockierende Abhängigkeit mehr.