beide Anschlüsse werden als belegt angezeigt, obwohl nur der 2. Anschluss belegt ist

[StBoll]

[dallmann-consulting]

Das passiert mit OCPP 2.0, richtig? Den Effekt hatte ich auch schon bemerkt. Die Ladetransaktion ist korrekt abgeschlossen (=> Anzeige der geladenen kWh anstelle der Ladezeit), aber der angezeigte Status ist verkehrt.

[StBoll]

Genau, das passiert mit 2.0 und besteht auch mit dem neuesten KEBA Update weiterhin.

[dallmann-consulting]

Ich kann das Verhalten leider nicht nachvollziehen. Weder mit Simulator, noch mit der echten KEBA-Box.
Ich habe in meinen Nachrichten gesehen, dass die KEBA-Box den Status schon 1-2 Sekunden vor dem Ende der Transaktion setzt. Aber auch das führt dazu, dass der Status unmittelbar "grün" wird.
Wie genau beenden Sie die Transaktion? Vielleicht passiert dies nur in einem speziellen Szenario, in welchem die KEBA-Box kein Status-Update übermittelt?

[StBoll]

1. Wenn kein Ladevorgang gestartet ist, werden beide Anschlüsse grün angezeigt.
2. Wird am Anschluß 2 ein LAdevorgang gestartet, werden beide Anschlüsse rot angezeigt.
3. wird der Ladevorgang durch abziehen des Ladekabels beendet, weden wieder beide Anschlüsse grün angezeigt, obwohl unter Anschlüsse der letzte Status von Anschluss 2 (fälschlicher Weise) als "Occupied" angezeigt wird.

Wenn der Server neu gestartet wird, wird scheinbar auch nur der Status von Anschluss 1 übermittelt. Von Anschluss 2 scheinbar nur der Zählerstand.

info: OCPPMiddleware[0]
OCPPMiddleware => SUCCESS: Found chargepoint with identifier=25464003
info: OCPPMiddleware[0]
OCPPMiddleware => No authentication for chargepoint '25464003' configured
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=9775b801-d594-4270-9556-be76fa3de8d4 / Action=Heartbeat)
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=c12d4491-1950-4a33-aa23-99bcebdca030 / Action=Heartbeat)
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=bf3740f3-5a91-4648-ac6b-fe0994e2281b / Action=StatusNotification)
info: OCPP.Core.Server.ControllerOCPP20[0]
StatusNotification => ChargePoint=25464003 / Connector=1 / newStatus=Available
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (1ms) [Parameters=[@__p_0='?' (Size = 8), @__p_1='?' (DbType = Int32)], CommandType='Text', CommandTimeout='30']
SELECT "c"."ChargePointId", "c"."ConnectorId", "c"."ConnectorName", "c"."LastMeter", "c"."LastMeterTime", "c"."LastStatus", "c"."LastStatusTime"
FROM "ConnectorStatus" AS "c"
WHERE "c"."ChargePointId" = @__p_0 AND "c"."ConnectorId" = @__p_1
LIMIT 1
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (1ms) [Parameters=[@p1='?' (Size = 8), @p2='?' (DbType = Int32), @p0='?' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
UPDATE "ConnectorStatus" SET "LastStatusTime" = @p0
WHERE "ChargePointId" = @p1 AND "ConnectorId" = @p2
RETURNING 1;
info: OCPP.Core.Server.ControllerOCPP20[0]
UpdateConnectorStatus => Save ConnectorStatus: ID=25464003 / Connector=1 / Status=Available / Meter=(null)
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=71bf57ee-715e-4996-b7cd-966b55b3e813 / Action=StatusNotification)
info: OCPP.Core.Server.ControllerOCPP20[0]
StatusNotification => ChargePoint=25464003 / Connector=1 / newStatus=Available
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (1ms) [Parameters=[@p1='?' (Size = 8), @p2='?' (DbType = Int32), @p0='?' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
UPDATE "ConnectorStatus" SET "LastStatusTime" = @p0
WHERE "ChargePointId" = @p1 AND "ConnectorId" = @p2
RETURNING 1;
info: OCPP.Core.Server.ControllerOCPP20[0]
UpdateConnectorStatus => Save ConnectorStatus: ID=25464003 / Connector=1 / Status=Available / Meter=(null)
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=7c088bef-67d2-4ca6-8566-35662a75ecd3 / Action=MeterValues)
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (2ms) [Parameters=[@p2='?' (Size = 8), @p3='?' (DbType = Int32), @p0='?' (DbType = Double), @p1='?' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
UPDATE "ConnectorStatus" SET "LastMeter" = @p0, "LastMeterTime" = @p1
WHERE "ChargePointId" = @p2 AND "ConnectorId" = @p3
RETURNING 1;
info: OCPP.Core.Server.ControllerOCPP20[0]
UpdateConnectorStatus => Save ConnectorStatus: ID=25464003 / Connector=1 / Status=(null) / Meter=3499.3307999999997
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=17464551-9c0e-430d-ae2b-db4624ee88fe / Action=MeterValues)
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=a0e9ef32-6fe8-45fd-b58e-4cb16e7547d8 / Action=MeterValues)
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (0ms) [Parameters=[@__p_0='?' (Size = 8), @__p_1='?' (DbType = Int32)], CommandType='Text', CommandTimeout='30']
SELECT "c"."ChargePointId", "c"."ConnectorId", "c"."ConnectorName", "c"."LastMeter", "c"."LastMeterTime", "c"."LastStatus", "c"."LastStatusTime"
FROM "ConnectorStatus" AS "c"
WHERE "c"."ChargePointId" = @__p_0 AND "c"."ConnectorId" = @__p_1
LIMIT 1
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (2ms) [Parameters=[@p1='?' (Size = 8), @p2='?' (DbType = Int32), @p0='?' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
UPDATE "ConnectorStatus" SET "LastMeterTime" = @p0
WHERE "ChargePointId" = @p1 AND "ConnectorId" = @p2
RETURNING 1;
info: OCPP.Core.Server.ControllerOCPP20[0]
UpdateConnectorStatus => Save ConnectorStatus: ID=25464003 / Connector=2 / Status=(null) / Meter=5191.8077
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=10495041-5e97-483e-aef0-3bca4471c371 / Action=MeterValues)
info: OCPPMiddleware.OCPP20[0]
OCPPMiddleware.Receive20 => OCPP-Message: Type=2 / ID=b101e8b6-95b0-43bd-9fa6-0fb1888fdbb0 / Action=MeterValues)
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (2ms) [Parameters=[@p1='?' (Size = 8), @p2='?' (DbType = Int32), @p0='?' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
UPDATE "ConnectorStatus" SET "LastMeterTime" = @p0
WHERE "ChargePointId" = @p1 AND "ConnectorId" = @p2
RETURNING 1;

[dallmann-consulting]

Was mich total verwirrt und ich mir überhaupt nicht erklären kann, ist die Aussage unter 2.), dass beide Anschlüsse als belegt angezeigt werden. Wie??? :-)
Im Moment wartet OCPP.Core darauf, dass die Wallboxen relevante Nachrichten senden, was normalerweise auch passiert. Sollte der OCPP-Server mal offline sein, sollen die Wallboxen ihre Nachrichten auch zwischenspeichern und später erneut senden. Es dürfte also nichts verloren gehen. Der Server kann auch bestimmte Nachrichten anfordern und damit z.B. den Status aktualisieren. Das passiert aber immer alles asynchron und wäre damit kompliziert und war nicht nötig.

Wenn eine Wallbox einen Status oder Zählerstände schickt (das sind separate Nachrichten) schreibt OCPP.Core das jeweils mit einem Zeitstempel in die DB. Das ist das, was in den Anschlüssen im Web-UI angezeigt wird. Zusätzlich hält der Server einen parallelen Status im Arbeitsspeicher. Da stehen der Status und Zählerstand nochmal drin und nur so weiß das Web-UI z.B. welche Wallboxen online sind. Und sofern eine Wallbox verbunden ist, zeigt das Web-UI in der Übersicht diesen Status als grün/rot an. Der Status in der DB ist dann egal, weil er veraltet sein könnte. Die Aktualisierung beider Datenstände passiert immer parallel aus derselben Nachricht der Wallbox.
In dem Zusammenhang fällt mir auf, dass bei den Kacheln oben der Footer mit dem Status fehlt. Da wird gezeigt, ob die Wallbox online oder offline ist. Das sollte folgendermaßen aussehen:

Der Status der beiden Anschlüsse (Connector 1 und 2) ist völlig entkoppelt und ich sehe keinen Grund, warum beide Anschlüsse gleichzeitig als belegt angezeigt werden sollte, es sei denn die Wallbox schickt für beide Anschlüsse einen entsprechenden Status. Ich kann das in unserer Umgebung auch nicht nachvollziehen. Es hat gerade ein Nachbar geladen und nur sein Anschluss war rot.

Aufgefallen war mir vor ein paar Wochen, dass ich längst abgesteckt und weggefahren war, der Anschluss aber weiter rot angezeigt wurde. Die Wallbox hat also keine StatusNotification geschickt oder OCPP.Core hat diese nicht korrekt verarbeitet. Das konnte ich bisher aber nicht reproduzieren. Weder mit den echten KEBA-Boxen, noch mit automatisierten Tests. Der Status war immer korrekt.

Wäre es eventuell möglich, dass Sie einmal alle OCPP-Nachrichten aus dem Dump-Verzeichnis (ggf. aktivieren) für dieses Szenario zukommen lassen?

[StBoll]

Leider dauerte es etwas bis endlich mal wieder ein Hotelgast die Wallbox genutzt hat.
Es wurde wirder der Anschluß 2 belegt (die Slave Box) und wieder werden beide Anschlüße als belegt angezeigt?

Im Backend der Masterbox wird zum selben Zeitpunkt alles richtig angezeigt:

Hier einige Logs aus den Temp Verzeichnis:

2025-10-06_16-25-35-0125_ocpp201-in.txt
2025-10-06_16-25-42-0001_ocpp201-in.txt
2025-10-06_16-25-42-0122_ocpp201-out.txt
2025-10-06_16-26-04-4605_ocpp201-in.txt
2025-10-06_16-26-04-4625_ocpp201-out.txt
2025-10-06_16-26-05-0231_ocpp201-in.txt
2025-10-06_16-26-05-0272_ocpp201-out.txt
2025-10-06_16-26-05-0982_ocpp201-in.txt
2025-10-06_16-26-05-1047_ocpp201-out.txt
2025-10-06_16-26-12-0006_ocpp201-in.txt
2025-10-06_16-26-12-0081_ocpp201-out.txt
2025-10-06_16-26-34-4727_ocpp201-in.txt
2025-10-06_16-26-34-4734_ocpp201-out.txt
2025-10-06_16-26-35-0133_ocpp201-in.txt
2025-10-06_16-26-35-0188_ocpp201-out.txt
2025-10-06_16-26-35-0797_ocpp201-in.txt
2025-10-06_16-26-35-0866_ocpp201-out.txt
2025-10-06_16-26-42-0139_ocpp201-in.txt
2025-10-06_16-26-42-0216_ocpp201-out.txt

Und noch das aktuelle Log aus dem Ordner Server/logs:

OCPP.Core.Server-143.log

[StBoll]

Nachtrag:
Wird der Ladevorgang beendet, werden beide Anschlüsse auch wieder grün angezeigt.
Es wirkt ein bisschen so, als würde nicht die Anschluss ID, sondern die Kennung für den Status genutzt. Mit 1.6 funktioniert alles fehlerfrei.