Add dummy_id_tag to OCPP config for overriding RFID card

[snoerenberg]

Description

This feature adds the ability to configure a default/dummy RFID card ID in the OCPP settings. When configured, this ID-Tag will be used for all OCPP transactions (StartTransaction and StopTransaction) regardless of whether a physical RFID card was scanned.

Use Case

This is useful when:

• You don't want to scan an RFID card for every charging session
• Your OCPP backend requires an ID-Tag but you don't have physical RFID cards
• You want to use a fixed ID-Tag for all transactions from this chargepoint

Changes

Backend (core):

• Added dummy_id_tag field to Ocpp dataclass
• Modified chargepoint logic to use dummy_id_tag (if configured) as the first priority for both start_transaction and stop_transaction calls

Frontend (openwb-ui-settings):

• Added "Standard ID-Tag" input field in OCPP settings section
• Includes help text explaining the feature

Behavior

dummy_id_tag	Result
Set	Always use this value for OCPP transactions
Empty	Fall back to scanned RFID tag or vehicle ID (existing behavior)

Configuration

The setting is available under: Ladeeinstellungen → Übergreifendes → OCPP Anbindung → Standard ID-Tag

[snoerenberg]

UI: openWB/openwb-ui-settings#875

[snoerenberg]

Discussion in Forum:
https://forum.openwb.de/viewtopic.php?t=11272

[snoerenberg]

Not yet fully tested, only storing the dummy id card is working.
I still struggle to test it within a "virtual environment" using a Raspberry PI 4.

[snoerenberg]

Tested and is working - added some debug code.

2026-01-06 11:59:12,453 - {ocpp:456} - {INFO:MainThread} - GKS_000: send [2,"ef7ec0b6-d92e-4572-8641-fec3b6e4d10e","StartTransaction",{"connectorId":3,"idTag":"xxx","meterStart":139,"timestamp":"2026-01-06T10:59:12.103725+00:00"}]
2026-01-06 11:59:14,459 - {control.ocpp:78} - {DEBUG:MainThread} - Transaction ID: 145295987 für Chargebox ID: GKS_00079 mit Tag: xxx und Zählerstand: 139.98 erhalten.
2026-01-06 11:59:14,461 - {control.chargepoint.chargepoint:757} - {INFO:MainThread} - OCPP Debug cp3: Transaction started, ocpp_transaction_id=145295987

2026-01-06 11:59:42,844 - {ocpp:456} - {INFO:MainThread} - GKS_000: send [2,"f0ede562-f8c1-4ca2-8e75-a37972867648","StopTransaction",{"meterStop":177,"timestamp":"2026-01-06T10:59:42.672274+00:00","transactionId":145295987,"reason":"EVDisconnected","idTag":"xxx"}]
2026-01-06 11:59:44,851 - {control.ocpp:128} - {DEBUG:MainThread} - Transaction mit ID: 145295987 für Chargebox ID: GKS_00079 mit Tag: xxx und Zählerstand: 177.54 beendet.
2026-01-06 11:59:45,935 - {control.chargepoint.chargepoint:740} - {INFO:MainThread} - OCPP Debug cp3: plug_state=False, plug_state_prev=True, ocpp_transaction_id=145295987, charge_state=False

[snoerenberg]

The go-e charger has a similar functionality built in.

I thought to put it beside the "OCPP-Chargebox ID" in the chargpoint settings but in the general settings it makes sense as well. Up to someone to decide. I guess in 99% of the cases the current solution is sufficient.

Only possibility that you have 2 chargers where you frequently charge always the same care and want to use different "DummyIDCards" per chargepoint.

[snoerenberg]

@LKuemmel könntest du dir das Feature mal anschauen? Danke

[LKuemmel]

Vielen Dank für den PR und die Mühe, die du dir gemacht hast.
Wir verstehen den Anwendungsfall und dass es Situationen gibt, in denen ein Backend zwingend ein ID-Tag erwartet, obwohl vor Ort keine physischen RFID-Karten eingesetzt werden. Trotzdem können wir diese Änderung leider nicht übernehmen.
Der vorgeschlagene PR ermöglicht es, Transaktionen unabhängig von einer tatsächlichen Authentifizierung mit einem „Dummy“-ID-Tag zu starten und zu beenden. Damit würde die openWB faktisch eine Funktion bereitstellen, um Abrechnungs- oder Authentifizierungsmechanismen von OCPP-Backends zu umgehen oder zu manipulieren – und dabei möchten wir keine Hilfestellung geben.

[snoerenberg]

@LKuemmel danke für die Rückmeldung.

Die OpenWB prüft eh nicht auf das Ergebnis von "StartTransaction" ob dies erfolgreich war oder nicht. Eigentlich müsste es für die korrekte Abrechnungs- oder Authentifizierungsmechanismen von OCPP-Backend auch eine "Authorize" aufrufen und danach "StartTransaction". Die aktuelle Implementierung ist so rudimentär das man nur das nötigste an der Hand hat um mit etwas Glück die Transaktion beim OCPP Backend irgendwie abzuliefern.

Somit verstehe ich zwar die Bedenken aber es hat auch nicht wirklich eine Auswirkung.
https://ocpp.md/ocpp-1.6j/sequences/

Aktuell nutze ich eine selbstgeschriebene Middleware die auf der einen Seite OCPP Client ist und auf der anderen Seite MQTT mit der Box spricht. Wenn angesteckt wird OCPP Session gestartet etc. - das würde ich mir gern sparen.

Ob man die RFID Karte clont (selbe UID) oder ein DummyID hinterlegt, ist am Ende das selbe nur mit mehr Aufwand :)

Danke dennoch