ID-IDEAL - OCPP Integration
Zielsetzung
Der Ladepunkt ist an das Backend des Projektes angeschlossen über eine Secure-Websocket Verbindung:
wss://ocpp-idideal.corrently.cloud/steve/websocket/CentralSystemService/{LADEPUNKT}
Die Kommunikation folgt dem OCPP 1.6 Standard und ist dadurch zu den meisten heutigen Ladeparks kompatibel.
Request: StartTransaction (LP->Backend)
{
connectorId:0,
idTag:'12345678901234567890',
meterStart:100,
timestamp:new Date().toISOString()
}
Responds: StartTransaction (In Band Backend->LP)
{
transactionId: 1,
idTagInfo: { status: 'Accepted', expiryDate: '2022-05-31T23:59:33.294Z' }
}
Request: StopTransaction (LP -> Backend)
{
idTag:'12345678901234567890',
meterStop:101,
transactionId:tx.transactionId,
timestamp:new Date().toISOString()
}
Responds: StopTransaction (In Band Backend->LP)
{
idTagInfo: { status: 'Accepted', expiryDate: '2022-06-01T00:04:05.727Z' }
}
Ergebnis
Auf Basis der Nutzerkennung muss es dem Backend möglich sein den Eigentümer für das CO2 Zertifikat eindeutig zu erkennen und einen Kommunikationskanal für die Presentation abzuleiten.
Transaktionsdaten
{
connectorId:0, // vergeben durch LP
transactionId: 2, // vergeben durch Backend
startTime:'2022-05-31T23:59:33.294Z', // von LP
endTime:'2022-05-31T23:59:53.123Z', // von LP
meterStart: 100, // von LP
meterEnd: 101, // von LP
idTag: '12345678901234567890', // von LP (TSE)
chargePoint: '1337' // von Backend
}
Überlegung: idTag
Vorteil:
Wir können diese zeitlich begrenzen, integrieren und zusätzlich absichern sowie durch weitere Meta-Informationen in unserem Backend anreichern.
Nachteil:
Wir verschließen uns vor den existierenden Tags (Ladekarten), wir benötigen eine Chameleon Hardware (aktiver RFID Sender mit ESP32) bei jedem (Test-)Nutzer
https://smith.corrently.cloud/applications/6296a405eda8d2559c7aca15/pages/6296a405eda8d2559c7aca18