FAQ

Drei Voraussetzungen für den Anschluss einer Ladestation:

• Die Ladestation hat eine stabile Internetverbindung (kabelgebundenes Netz bevorzugt);
• Die Ladestation besitzt ein Administrationswerkzeug, über das Sie die CSMS-URL ändern können;
• Die Ladestation läuft vor der ersten Verbindung zum CSMS mit aktueller Firmware.

Die Ladestation lässt sich erst nach der ersten Verbindung aus der Ferne aktualisieren. Achtung: Ein Firmware-Update kann Fehlfunktionen oder Rückschritte verursachen. Wir empfehlen, die Firmware immer zuerst an einer Testladestation zu prüfen.

Nutzt die Ladestation ein lokales Netzwerk, muss die IT den ausgehenden Datenverkehr der Ladestationen zur Domain charge-angels.com (TCP-Port 443) erlauben und die ausgehende Firewall deaktivieren oder die IP-Adressen unseres Servers freigeben (bei einem Administrator anzufragen).

Das Netzwerk sollte nach Möglichkeit kabelgebunden sein, um Entfernungs- und Bandbreitengrenzen zu vermeiden. Die tolerierte Netzwerklatenz muss unter 500 ms liegen.

Ladestationen können verschiedene Kommunikationswege nutzen: LAN (Ethernet) oder WAN (WLAN). In den meisten Fällen kommuniziert die Ladestation standardmäßig mit dem DHCP (Dynamic Host Configuration Protocol) des lokalen Netzwerks und erhält automatisch eine IP-Adresse; andernfalls muss in der Ladestation eine feste IP-Adresse eingetragen werden. Der Router verbindet sich über den Anbieter des Kunden mit dem Internet: ADSL, Glasfaser oder GSM.

Wenn Sie ein 4G-Netz bevorzugen, benötigen Sie M2M-SIM-Karten (für IoT), vorzugsweise mit Roaming. Rechnen Sie beim Datenvolumen mit 200 kByte pro Ladepunkt.

• Die APN-Konfiguration hängt vom Anbieter ab.
• Zu bevorzugen sind SIM-Karten mit aktiviertem Roaming: Das beste Netz wird in Echtzeit gewählt. Das Roaming kann je nach Bedarf auf Frankreich beschränkt oder weltweit sein.
• Planen Sie bei intensiver Nutzung in der Regel einen Datentarif von 200 MB pro Ladepunkt ein.
• Ein VPN ist nicht nötig, wenn die Ladestation über WSS kommuniziert.

ChargeAngels nutzt zwischen Ladestation und Backend eine sichere WebSocket-Verbindung (WSS). Wir unterstützen ausschließlich TLS 1.3 (TLS 1.2 gilt als veraltet). ChargeAngels unterstützt SSL-Zertifikate mit RSA und ECDSA. Zur Verarbeitung der WebSockets setzen wir Node.js mit der Bibliothek uWebSockets.js ein.

• WebSocket (WS) wurde 2011 geschaffen und ist ein Netzwerkprotokoll der Anwendungsschicht, das zwischen Client und Server „bidirektional, asynchron und vollduplex“ arbeitet; es ist von der IETF in RFC 6455 und vom W3C standardisiert.
• WebSocket öffnet eine dauerhafte Vollduplex-Verbindung zwischen Client und Server: Der Server kann – anders als beim HTTP-Protokoll – von sich aus Daten an einen Client senden.
• WebSocket Security (WSS) nutzt wie HTTPS die Transportschicht TLS zur Verschlüsselung der Kommunikation und ist daher sicherer.

Wie in der Spezifikation „OCPP 1.6 security whitepaper edition 3“ beschrieben, unterstützen wir:

• Sicherheitsprofil 1: WS mit Basic Authentication (Benutzer / Passwort oder Authorization Key, nach Wahl);
• Sicherheitsprofil 2: Basic Authentication oder WSS TLS mit dem Server-Root-Zertifikat (ISRG Root X1);
• Sicherheitsprofil 3: WSS TLS sowohl am Ladepunkt als auch auf Serverseite (getestet, aber nicht offiziell im Produktivbetrieb).

OCA-Tests: Die Testfälle TC_085_CSMS (Basic Authentication, gültige Kombination aus Benutzername / Passwort), TC_086_CSMS (TLS, gültiges Serverzertifikat) und TC_087_CSMS (TLS, gültiges Clientzertifikat) werden mit dem Testwerkzeug der Open Charge Alliance bestanden.

Authorization Key: mindestens 16 Zeichen und hexadezimale Kodierung, zwischen 20 und 40 Zeichen.

Wir empfehlen, die erste Verbindung der Ladestation immer zuerst mit Sicherheitsprofil 1 (WS), dann mit 2 (WS und WSS) und danach mit 3 (WSS) zu testen.

Ein Tenant ist ein Unterbereich der Hauptdomain, zum Beispiel cpo1.charge-angels.com.

• Wenn Sie sich für die SaaS-Lösung entschieden haben, strukturieren Sie Ihren Tenant im Reiter „Organisation“ des CSMS.
• Wenn Sie sich für die Full-Cloud-Lösung entschieden haben, haben Sie Zugriff auf den „Master Tenant“ und können beliebig viele „Cloud Tenants“ anlegen.

Der Tenant hat eine gemeinsame Nutzerdatenbank, deren zentraler Schlüssel die E-Mail-Adresse ist. Er lässt sich in mehrere Hierarchieebenen gliedern: Unternehmen, Standorte und Zonen.

• Standorte können verschiedene geografische Bereiche ein und desselben Kunden sein (zum Beispiel Busdepots).
• Standorte können auch verschiedene Unterkunden sein, die sich eine gemeinsame Nutzerdatenbank teilen.
• Eine Zone ist eine Gruppe von Ladestationen; sie bildet die physische Topologie des Ortes ab: Eine Zone kann einem Niederspannungshauptverteiler (TGBT) oder einem Netzanschluss entsprechen (zum Beispiel einem 220-kVA-Anschluss).
• SmartCharging wird pro Zone getrennt betrieben (Maximalleistung am Hauptverteiler angegeben).

Ein „Token“ ist eine WSS-Verbindungs-URL, mit der sich die Ladestation mit den Servern des ChargeAngels-CSMS verbindet. Der Token ist einmalig und gilt für genau eine Zone.

Sobald Ihre Organisation angelegt ist, können Sie im Menü „Ladestation“ unter „Ladestation verbinden“ einen oder mehrere Verbindungstoken zum Backend erstellen: anlegen, Titel, Gültigkeitsdatum und Zone hinzufügen und speichern.

Sie können den Token für die spätere oder sofortige Verwendung kopieren (zum Beispiel „OCPP 1.6 JSON“). Er kann an die Teams weitergegeben werden, die die Ladestationen vor Ort installieren. Aus Gründen der Cybersicherheit hat sich ChargeAngels – anders als andere CSMS – für dynamische Token mit Gültigkeitsdatum entschieden.

Der Token (bzw. die URL) besteht aus 4 Teilen

• das Präfix: HTTP / HTTPS / WS oder WSS;
• „OCPP16“ oder „OCPP201“, je nach OCPP-Version;
• der erste Teil des Tokens ist die eindeutige Kennung des Tenants;
• der zweite Teil ist die Kennung des Tokens selbst, die einer Zone zugeordnet ist;
• der letzte Teil ist der Name der Ladestation: die ChargeBoxID.

wss://charge-angels.com/OCPP16/<tenant-id>/<token-id>/CHARGER-01

Sobald der Token in die Administration der Ladestation kopiert ist, öffnet die Ladestation einen Socket zu den CSMS-Servern. Die Ladestation (hier CHARGER-01) erscheint automatisch im Dashboard, ohne dass im Backend etwas zu tun ist. Sobald sie sichtbar ist, bearbeiten Sie ihre Attribute (Maximalleistung, Standort, Anschlüsse usw.).

In der Administration mancher Ladestationen sind URL und ChargeBoxID auf mehrere Felder aufgeteilt: „Host“, „Port“, „Path“ und „ChargeBoxID“ (der Name der Ladestation). Manchmal muss die so zusammengesetzte URL geprüft werden (auf die unterschiedlichen Schrägstriche achten).

Ladestationen benennen

Wir empfehlen, eine Namenskonvention für Ladestationen festzulegen. Die ChargeBoxID ist in der Datenbank mit allen Informationen und dem Ladeverlauf der Ladestation verknüpft: Sie lässt sich später nicht ändern, ohne diesen Verlauf zu verlieren. Beispiel einer Konvention: „STADT-ORT-LADESTATION-01“. Achtung: Die ChargeBoxID ist auf 48 Zeichen begrenzt (Gireve-Limit).

Sind Token und Name der Ladestation eingetragen, zeigt die Ladestation auf den Tenant, den Token und damit auf die betreffende Zone. Manchmal muss die Ladestation neu gestartet werden, damit diese Einstellungen greifen. Solange die Ladestation nicht im Dashboard erscheint, ist entweder die URL fehlerhaft oder die Ladestation offline: Prüfen Sie die Logs.

Ablauf des Tokens

CHARGER-01 muss in Betrieb genommen und mit dem erstellten Token verbunden werden, bevor der Token abläuft, sonst wird die OCPP-BootNotification abgelehnt. Sobald das Backend die Ladestation zum ersten Mal akzeptiert hat, wird der Token in der Datenbank gespeichert: Auch nach Ablauf kann die Ladestation problemlos neu starten.

Wir empfehlen, Token – auch abgelaufene – aufzubewahren: Für weitere Inbetriebnahmen genügt es, ihr Gültigkeitsdatum zu verlängern. Nicht verwendete Token können Sie dagegen löschen, das vermeidet Fehler.

Wir raten dazu, die ChargeAngels-Logs während der Inbetriebnahme zu beobachten und regelmäßig zu prüfen.

Manche Ladestationen benötigen das Root-Zertifikat unseres Servers: ISRG Root X1 (Let’s Encrypt). Wir stellen es auf Anfrage bereit, Sie können es aber auch in einer Linux- oder macOS-Kommandozeile mit folgendem Befehl abrufen:

curl https://letsencrypt.org/certs/isrgrootx1.pem

Kopieren Sie das in der Antwort angezeigte Zertifikat (ISRG Root X1), fügen Sie es in eine Textdatei ein und speichern Sie sie als „ISRG Root X1.crt“. Speichern Sie es lokal und in der Ladestation: Beim Neustart nutzt die Ladestation dieses Zertifikat und die WSS-URL, um sich mit dem Backend zu verbinden.

Dieses Zertifikat wird in OCPP mit Sicherheitsprofil 2 und dem serverseitigen Zertifikat verwendet.

Sobald die Ladestation mit dem Backend verbunden ist, können Sie alle OCPP-Parameter aus der Ferne ändern. Manche Parameter sind in der OCPP-Spezifikation standardisiert, andere sind optional oder sogar herstellerspezifisch.

Liste der zu prüfenden Parameter, je nach Bedarf:

Manche Ladestationen haben ein Feld „CSMS URL“ und „ChargeBoxID“: Damit lassen sich die Backend-URL oder der Name der Ladestation aus der Ferne ändern, ohne vor Ort in die Konfiguration der Ladestation zu gehen.

Sie können alle OCPP-Parameter exportieren, um sie später mit denen anderer Ladestationen zu vergleichen. Einige Schlüssel sind schreibgeschützt.

Das Erste, was bei der Inbetriebnahme zu beobachten ist, ist die Stabilität der WebSockets. Das Öffnen eines WebSockets geht ausschließlich von der Ladestation aus, nicht vom CSMS.

Die Logs finden Sie im Bereich „Log“ des CSMS; dort können Sie nach Ladestation, Schweregrad und Aktion filtern. Zwei Gruppen von Logs sind nützlich: WebSocket-Logs (Verbindung) und OCPP-Logs (ausgetauschte Nachrichten), beschrieben in den nächsten beiden Fragen.

Sind die WebSockets nicht stabil (ungewollte Verbindungsauf- und -abbrüche), kann die Ladestation über OCPP nicht korrekt starten und befindet sich in einem ungewissen Zustand.

Filtern Sie im Bereich „Log“ nach den Aktionen WsServerConnectionOpen und WsServerConnectionClose.

• WsServerConnectionClose zeigt an, dass der Socket auf Seiten der Ladestation geschlossen wurde (auf Initiative der Ladestation), zum Beispiel: Close > WS Connection ID 'FsRi9' closed with code '1000', reason: 'Normal closure'.
• Das CSMS hat keine weiteren Informationen zum Grund dieser Trennung. Meistens liegt ein Netzausfall (die Zeitpunkte von Schließen und Öffnen sind dann bei allen Ladestationen gleich) oder ein Stromausfall zugrunde.
• Sie können die Anzahl der WsServerConnectionClose-Ereignisse überwachen: Es sollten nicht mehr als einige pro Tag sein.

Das CSMS sendet alle 60 Sekunden einen „Ping“ an die Ladestation; schlagen 2 Pings fehl, schließen wir den WebSocket. Auch die Ladestation pingt unseren Server alle 30 Sekunden an. Die Ping-Häufigkeit lässt sich mit dem OCPP-Parameter WebSocketPingInterval anpassen.

Im Bereich „Log“ können Sie nach Ihrer Ladestation und einigen einfachen Aktionen filtern, zum Beispiel: OcppBootNotification, OcppStatusNotification, OcppStartTransaction, OcppStopTransaction, OcppMeterValues. Logs werden von unten nach oben gelesen (der jüngste steht in der ersten Zeile).

Es gibt vier Schweregrade, wie in jedem IT-System:

• ERROR: kritisch, darf nie auftreten;
• WARNING: ernst, aber ohne Folgen für den Betrieb;
• INFO: lesbare (textuelle) Informationen;
• DEBUG: Debug-Informationen mit den JSON-Anfragen und -Antworten.

Im Modus DEBUG enthalten die Nachrichtendetails die Richtung der Anfragen, nach folgender Konvention:

• << = Anfrage / Antwort von der Ladestation an das Backend;
• >> = Anfrage / Antwort vom Backend an die Ladestation.

Dieselbe Konvention gilt für den JSON-Server, OCPI, OICP, Batch oder externe APIs (das Backend steht rechts).

Logs zu OCPP-JSON-Befehlen lassen sich auch auf einer noch tieferen Ebene lesen, indem man die nebeneinanderstehenden WebSocket-Nachrichten betrachtet: WsClientMessage für die Anfrage und WsServerMessage für die Antwort, mit einer eindeutigen Kennung (UID) für jede Nachricht auf CSMS- und Ladestationsseite. Zum Beispiel:

Message > Send WS Message Request: '[2,"f3f0e8b8-59a2-4f4c-816a-fce3b059f0a0","ClearChargingProfile",{"connectorId":1}]'

Message > Received WS Message: '[3,"f3f0e8b8-59a2-4f4c-816a-fce3b059f0a0",{"status":"Unknown"}]'

Dieses Format wird beim Debugging manchmal für die Kommunikation mit den Ladestationsherstellern benötigt.

ChargeAngels hat eine gemeinsame Nutzerdatenbank pro Tenant. Nutzer haben 3 Berechtigungsstufen (Rollen):

• Administrator: alle Rechte auf dem Tenant;
• Standard: Rechte für Endkunden, die Elektrofahrzeuge laden;
• Standortadministrator: ein „Standard“-Nutzer mit Administrationsrechten für einen oder mehrere Standorte.

Die Details der Berechtigungen je Rolle sind in der Integrationsdokumentation beschrieben, die auf Anfrage erhältlich ist.

Eine vierte Rolle, „Demo“, steht für die anonymisierte öffentliche Anzeige zur Verfügung. Außerdem gibt es eine spezielle Rolle für die Server-zu-Server-Kommunikation (API): Sie lässt sich bei einem generischen Nutzer, dem „technischen Nutzer“, aktivieren, der sich nicht über das Frontend (Web- oder Mobile-App) anmelden kann.

Die nächsten drei Fragen erläutern die allgemeinen Regeln, die Zuordnung zu Standorten und die Kontostatus.

Neue Nutzer können ihr Konto anlegen:

• über die Weboberfläche, direkt auf der Seite https://<subdomain>.charge-angels.com/auth/register;
• über die Mobile-App, nach dem Scannen des QR-Codes der Organisation bei „SaaS“-Kunden oder direkt beim Öffnen der App bei „Full-Cloud“-Kunden.

In beiden Fällen müssen sie die „Endbenutzer-Lizenzvereinbarung“ (EULA) akzeptieren, wie sie in der DSGVO (Datenschutz-Grundverordnung) definiert ist.

• Die E-Mail-Adresse ist der eindeutige Schlüssel eines Nutzers in der Datenbank.
• Aus Sicherheitsgründen sind Passwörter in der Datenbank verschlüsselt: Sie sind auch für Administratoren nicht im Klartext sichtbar.
• Ein Nutzer, der sich 3-mal mit falschem Passwort anmeldet, wird gesperrt; nur ein Administrator kann das Konto auf Anfrage entsperren.
• Ein Nutzer, der sein Passwort vergessen hat, kann per E-Mail eine automatische Erneuerung anfordern – über die Web-App (https://<subdomain>.charge-angels.com/auth/reset-password) oder die Mobile-App („Passwort vergessen?“).
• Nur ein Administrator kann die Berechtigungen eines „Basic“-Nutzers auf „Administrator“ oder „Basic / Site Administrator“ erhöhen. Ebenso kann ein Standortadministrator auf den ihm zugewiesenen Standorten einen weiteren Standortadministrator benennen.

Da die Nutzerdatenbank für den gesamten Tenant gilt, kann der Administrator die Strategie für die Zuordnung von Nutzern zu Standorten wählen: Entweder ist die Option „Neue Nutzer diesem Standort automatisch zuweisen“ auf allen Standorten aktiviert oder sie ist deaktiviert.

1. Option deaktiviert: Der neue Nutzer sieht nach der Kontoerstellung keine Ladestation. Der Administrator (oder Standortadministrator) muss ihn manuell zuweisen. Der Nutzer kann dann alle Ladepunkte des Standorts sehen und einen Ladevorgang starten.
2. Option aktiviert: Der neue Nutzer wird allen Standorten zugewiesen, auf denen die Option aktiv ist; er sieht alle Ladepunkte dieser Standorte und kann einen Ladevorgang starten. Der Administrator (oder Standortadministrator) muss dann Nutzer entfernen, die die betreffenden Standorte nicht sehen sollen.

Hinweise:

• Alle „Administrator“-Nutzer werden standardmäßig allen im Tenant angelegten Standorten zugewiesen.
• Ein Administrator kann einen Nutzer manuell mit einem Passwort seiner Wahl anlegen. In diesem Fall muss er den Nutzer auch manuell den Standorten zuweisen, für die er Rechte haben soll.
• Die Option „Dieser Standort ist öffentlich“ betrifft nur das Roaming-Szenario (Gireve / Hubject).

Außerdem können Sie für den gesamten Tenant die Strategie für die Anlage neuer Nutzerkonten im Bereich „Technische Einstellungen“ / „Nutzer“ aktivieren oder deaktivieren:

• wenn aktiviert: Alle neuen Nutzer können ihr Konto automatisch anlegen;
• wenn deaktiviert: Sie erhalten eine Push-Benachrichtigung und eine E-Mail, um zu entscheiden, ob das Konto aktiviert wird. Anschließend müssen Sie die automatische Zuweisung auf den Standorten prüfen oder manuell vornehmen – je nach der oben festgelegten Strategie.

Entscheidet sich ein Kunde, mehrere Kundenkonten im selben Tenant anzulegen, ist er selbst dafür verantwortlich, alle seine Nutzer (alte wie neue) ordnungsgemäß zu verwalten.

Ein Nutzerkonto kann sich in mehreren Zuständen befinden:

• Aktiv: freigeschaltet, nutzt alle Funktionen der Website;
• Suspendiert: von einem Administrator deaktiviertes Konto, kann später wieder aktiviert werden;
• Inaktiv: Konto seit mehr als 6 Monaten nicht genutzt (keine Anmeldung auf der Plattform);
• Gesperrt: automatische Sperre nach drei Fehlversuchen bei der Passworteingabe;
• Ausstehend: wartet auf die Freigabe des Kontos durch einen Administrator.

Ein automatischer Mechanismus prüft und deaktiviert inaktive Nutzerkonten auf der ChargeAngels-Plattform – im Einklang mit der europäischen DSGVO.

So funktioniert es

Die Aufgabe läuft jeden Montag um Mitternacht (Europe/Paris). Sie betrifft nur aktive Nutzer mit der Rolle Basic (technische Konten sind ausgenommen). Der Ablauf hat zwei Schritte:

1. Warnung (nach 6 Monaten Inaktivität): Nutzer, die sich 6 Monate nicht angemeldet haben, erhalten eine Warnmeldung und haben so Zeit, sich erneut anzumelden und die Deaktivierung zu vermeiden.
2. Deaktivierung (nach 7 Monaten Inaktivität): Hat sich der Nutzer einen Monat nach der Warnung immer noch nicht angemeldet, wechselt das Konto automatisch in den Status Inaktiv und es wird eine Benachrichtigung über die Statusänderung gesendet.

Geprüfte Kriterien: Datum der letzten Anmeldung, Datum der Zustimmung zu den Bedingungen (EULA), Datum des letzten Ladevorgangs. Aktuelle Konfiguration: Inaktivitätsschwelle von 6 Monaten, Ausführung jeden Montag um 00:00 Uhr.

Eine Ladestation kann je nach Einstellungen in ChargeAngels (Organisation / Zonen), vor allem aber je nach Einstellungen der Ladestation selbst (und ihres Modells) völlig offen oder sehr gesichert sein.

Ist die Zugangskontrolle auf ChargeAngels-Seite deaktiviert, akzeptiert ChargeAngels unabhängig von den Einstellungen der Ladestation alle von der Ladestation angeforderten Ladevorgangsstarts. In diesem Fall ist es unmöglich, bestimmte Nutzer zu sperren oder abzurechnen.

Ist die Zugangskontrolle aktiviert, hängt das Verhalten von den Einstellungen der Ladestation ab: FreeVending, RFID, Autocharge oder Plug&Charge. ChargeAngels kann eine unbegrenzte Zahl von Token vom Typ RFID, eMAID oder MAC-Adresse verwalten – automatisch, manuell oder per CSV-Import.

• Gireve definiert einen Token als Zeichenfolge von 4 bis 7 Byte, also 8 bis 14 hexadezimalen Zeichen. Wir empfehlen, diese Regel einzuhalten, damit das Roaming korrekt funktioniert. Empfohlen werden nur NFC/RFID-Karten vom Typ MIFARE.
• Legt ein neuer Nutzer über die Weboberfläche (https://<subdomain>.charge-angels.com/auth/register) oder die Mobile-App ein Konto an, wird automatisch eine virtuelle 4-Byte-Karte erstellt und diesem Nutzer zugewiesen.
• Token lassen sich manuell einzeln oder per CSV-Import anlegen. Wird ein Token manuell angelegt, muss der Administrator ihn einem Nutzer zuweisen.
• Ein Nutzer kann beliebig viele Token haben, darunter einen Standard-Token: Dieser wird beim Start eines Ladevorgangs automatisch angeboten.

Beim Anlegen eines Tokens abgefragte Angaben

• die Badge-ID bzw. UID: der im physischen RFID-Chip gespeicherte Code;
• die Kartennummer: die sichtbar auf die RFID-Karte aufgedruckte Nummer;
• die Beschreibung (Freitext);
• der mit der Karte verknüpfte Nutzer;
• der Kartenstatus;
• Standardkarte: die Karte, die beim Start eines Ladevorgangs automatisch angeboten wird;
• Erlauben, dass diese Karte mehrere Ladevorgänge gleichzeitig an verschiedenen Ladestationen startet.

Wie füge ich eine physische Karte (oder eine virtuelle eMAID) hinzu, wenn ich ihre UID nicht kenne?

1. Fügen Sie im Bereich „Logs“ einen Filter für Ihre Ladestation und den Schweregrad ERROR hinzu.
2. Suchen Sie im Filter „Aktion“ nach der Aktion OcppAuthorize.
3. Halten Sie Ihre Karte an die Ladestation.
4. Es erscheint ein ERROR-Log mit der UID (idTag) in den Fehlerdetails.

Notieren Sie sich diese UID für später oder fügen Sie sie im Menü „Karte“ hinzu. Mit der Export-Schaltfläche können Sie außerdem alle Karten exportieren.

CSV-Import

Ein Import im CSV-Format mit Komma als Trennzeichen ist ebenfalls möglich: Erstellen Sie eine XLS-Datei mit den Pflichtfeldern id und visualID sowie den optionalen Feldern description, limitKwh, email, firstName, name, siteIDs und speichern Sie sie als CSV. Testen Sie mit einigen Karten, bevor Sie eine Liste mit Tausenden Karten importieren.

Ladestationshersteller bieten in der Regel Zahlungsterminal-Lösungen (POS) wie diese an:

Prinzip: Das POS ist über die serielle Schnittstelle (MDB) mit der Ladestation verbunden.

1. Der Fahrer hält seine Bankkarte an das in die Ladestation integrierte Zahlungsterminal (Nayax, Ingenico oder Payter).
2. Das Backoffice des Bezahldienstes der Bank prüft und autorisiert den Ladevorgang.
3. Das Zahlungsterminal sendet über das MDB-Protokoll einen vordefinierten Token an die Ladestation, um eine Autorisierung anzufordern.
4. Die Ladestation sendet eine Autorisierungsanfrage mit dem Token an das Überwachungs-Backend und startet den Ladevorgang.

Ist auf POS-Seite (Cloud des Herstellers) alles konfiguriert, sendet die Ladestation beim Auflegen einer Bankkarte eine OCPP-StartTransaction mit einem idTag. Dieses Tag muss in den OCPP-Parametern der Ladestation eingetragen werden: Es ist kein Standard-OCPP-Parameter und unterscheidet sich je nach Ladestationsmarke.

Dieses Tag muss außerdem als virtuelle Karte und bei einem virtuellen Nutzer (Administrator) hinterlegt sein, damit die Überwachung die Ladeanforderung akzeptiert. Dieser Nutzer muss zudem den entsprechenden Standorten zugewiesen sein.

Voraussetzung: die Tarifkonfiguration und das Stripe-Bankkonto. Sie können die Tarife unabhängig einrichten, ohne die Abrechnung zu aktivieren.

Bei geschlossenen Flotten oder Firmenflotten können Sie Ihren Nutzern direkt Folgendes geben:

1. die URL für den Zugang zur Webplattform: https://<subdomain>.charge-angels.com/auth/login;
2. die QR-Codes der Mobile-App:

3. der QR-Code Ihrer „Organisation“, der beim Anlegen eines Kontos abgefragt wird. Sie finden ihn im Menü „Technische Einstellungen“ unter „QR-Code anzeigen“. Speichern Sie ihn als JPG-Datei: Sie benötigen ihn für Ihre Nutzeranleitungen. Eine Plakatvorlage zum Anpassen und Aufkleben auf Ihre Ladestationen ist auf Anfrage erhältlich.
4. ein QR-Code pro Anschluss: Sie können auch je Anschluss einen erzeugen, um einen Ladevorgang zu starten, ohne die Ladestation in der Mobile-App suchen zu müssen. Die Liste der QR-Codes lässt sich für jeden Standort im Menü Organisation / Standort exportieren.

Achtung: Die QR-Codes enthalten die vollständige URL der Ladestationen (ChargeBoxID und Anschluss-ID). Wird eine Ladestation umbenannt, ändert sich ihr QR-Code: Sie müssen ihn dann ersetzen.

Das Erste, was bei der Inbetriebnahme zu beobachten ist, ist die Stabilität der WebSockets. Das Öffnen eines WebSockets geht ausschließlich von der Ladestation aus, nicht vom CSMS. Sind die WebSockets nicht stabil (ungewollte Verbindungsauf- und -abbrüche), kann die Ladestation über OCPP nicht korrekt starten und befindet sich in einem ungewissen Zustand.

Erscheint eine Ladestation nicht in der Weboberfläche (Dashboard), kann das viele Ursachen haben:

• Die Ladestation ist nicht mit Strom versorgt (Ausfall) oder befindet sich in einem undefinierten Zustand;
• Die Ladestation ist nicht oder nicht mehr mit dem Netzwerk verbunden;
• Die Ladestation läuft über ein gesichertes Netzwerk (ausgehende Firewall);
• Die Ladestation läuft über ein lokales Netzwerk: LAN- oder WAN-Router;
• Die Internetverbindung ist unzureichend;
• Die Firmware der Ladestation ist nicht aktuell.

Reihenfolge der Fehlersuche

1. Seite der Ladestation

• Prüfen Sie die physischen Verbindungen: Kabel und Router.
• Schalten Sie die Ladestation und die externen Kommunikationsgeräte (Router) für 5 Minuten stromlos und wieder ein.
• Prüfen Sie, wenn möglich, die Logs der Ladestation in der Administration des Herstellers.

RJ45-Verbindungen sind oft fehlerhaft oder schlecht verkabelt. Der beste Test ist, anstelle der Ladestation einen Computer mit denselben Netzwerkeinstellungen anzuschließen (automatisches DHCP oder feste IP).

• Prüfen Sie bei einer Ladestation mit 4G-Modem, ob APN sowie Benutzer / Passwort stimmen, und anschließend den 4G-Signalstatus, der oft an der Ladestation oder am externen 4G-Router abrufbar ist.
• Aktualisieren Sie die Firmware auf die neueste offizielle Version von der Website des Herstellers.
• Versuchen Sie zuerst, den Token auf WS umzustellen (ungesichert, Port 80).
• Wenn das funktioniert, wechseln Sie anschließend zurück auf WSS (gesichert, Port 443).

2. Seite der Überwachung, wenn auf Seiten der Ladestation alles in Ordnung ist

• Prüfen Sie die Logs auf Überwachungsseite (vorzugsweise in der Weboberfläche), wie in den Fragen zu Logs beschrieben. Geht keine Anfrage zum Öffnen eines WebSockets ein, kommuniziert die Ladestation nicht korrekt – besonders dann, wenn bereits andere Ladestationen im selben Cloud-Bereich verbunden sind.
• Prüfen Sie außerdem den Zustand des Tokens (Gültigkeit und Sperrung) im Menü „Ladestation / Neue Ladestation verbinden“.
• Prüfen Sie, ob die Ladestation auf OCPP-Befehle (Reset, StartTransaction …) reagiert, und beobachten Sie dabei die Backend-Logs.

Wann und wie Sie uns kontaktieren

Reagiert keine Ladestation mehr und liegt es nicht am Netzwerk, kann ein Fehler auf Überwachungsseite vorliegen. Bitte kontaktieren Sie uns dann (Kategorie „Support-Anfrage“) mit einer genauen Beschreibung des Problems: Datum des Vorfalls, Reproduzierbarkeit, Namen der betroffenen Ladestationen, durchgeführte Tests usw.

Scheint das Problem mit den Ladestationen, mit einer bestimmten Ladestation oder mit einem Firmware-Update zusammenzuhängen, sammeln Sie die Logs von Ladestation und Überwachung und eröffnen Sie ein Ticket beim Hersteller.

Debugging ist bei ChargeAngels eine kostenpflichtige Leistung – außer bei einem nachgewiesenen und dokumentierten Fehler auf Überwachungsseite. Nur von ChargeAngels zertifizierte Ladestationen sind durch unseren Supportvertrag abgedeckt. In den meisten Fällen werden Fehler durch einen Absturz der Ladestation, ein Netzwerkproblem oder eine falsche Handhabung durch Nutzer verursacht.

Bewährte Vorgehensweisen

• Am besten halten Sie eine „Referenz“-Ladestation in der Nähe Ihrer Räumlichkeiten vor, zum Debuggen und zum Nachstellen von Störungen oder Fehlern. Ein Firmware-Update ist ein riskanter Vorgang, der eine Ladestation manchmal dauerhaft unbrauchbar machen kann. Ohne dedizierte Testladestation führen Sie Ihre Tests an einer isolierten, wenig genutzten Ladestation durch.
• Führen Sie bei der Inbetriebnahme von Ladestationen, die Sie nicht kennen, vor der endgültigen Installation einen Inbetriebnahmetest durch.
• Analysieren Sie bei 4G-Ladestationen vorab die 4G-Netzabdeckung (dafür gibt es Messgeräte).
• Für Funktionstests gibt es Ladesimulatoren für AC-Ladestationen (Typ 2) von Metrel. Wir empfehlen außerdem Tests mit einem echten Elektrofahrzeug.

Das Lesen von JSON-Logs oder anderen Formaten erfordert IT-Kenntnisse. Die OCPP-Nachrichten zwischen den Ladestationen und unserem Server sind in der OCPP-Spezifikation standardisiert, die wir zuerst zu lesen empfehlen: openchargealliance.org/my-oca/ocpp. Wir bieten außerdem Schulungen zu diesem Protokoll sowie operative Schulungen (Logs lesen und Debugging) an, zusätzlich zur IRVE-P2/P3-Qualifizierung.

Drei Gruppen von Problemen treten am häufigsten auf. Sie werden in den nächsten Fragen erläutert:

• Probleme bei der Anbindung der Ladestation an das Backend;
• Probleme beim Abschluss von Ladevorgängen: keine StopTransaction empfangen;
• Probleme beim Abschluss von Ladevorgängen: StopTransaction empfangen, aber falscher Status.

Symptom: Die Ladestation erscheint nicht im Dashboard des ChargeAngels-CSMS, obwohl das Netzwerk funktioniert, oder es gehen WS-/WSS-Anfragen ein, die aber fehlerhaft sind.

Erklärungen: Das Öffnen eines WebSockets geht ausschließlich von der Ladestation aus, nicht vom CSMS. Geht auf Überwachungsseite keine WS- oder WSS-Anfrage ein und funktioniert das Netzwerk (die Ladestation erreicht das Internet, zum Beispiel den DNS von Google), ist die in der Ladestation eingestellte URL wahrscheinlich falsch, fehlerhaft oder unvollständig. Jede Marke und jedes Modell hat Besonderheiten und braucht manchmal ein spezielles Werkzeug, um diese URL einzustellen: Web-App, Mobile-App, eigene Windows-Anwendung usw.

Lösungen: Wir empfehlen, zuerst die gesamte FAQ zu lesen, insbesondere die Fragen zu den WebSocket-Logs. Nach dem Netzwerk ist die URL-Einstellung in 99 % der Fälle die Ursache des Problems: Gehen Sie daher sequenziell und iterativ vor.

Eine fehlerhafte URL hat oft mehrere Ursachen:

1. Manche Ladestationen unterstützen nur WS: Wir empfehlen, damit zu beginnen (wer mehr kann, kann auch weniger).
2. Manche Ladestationen unterstützen WSS erst nach dem neuesten Firmware-Update.
3. Manche Ladestationen verlangen eine erste Verbindung über WS und danach den Wechsel auf WSS (Schneider, je nach Firmware).
4. Manche Ladestationen unterstützen WSS, aber nur mit TLS 1.2 und nicht mit TLS 1.3.
5. Manche Ladestationen verlangen ein bestimmtes Sicherheitsprofil: Wir haben kein spezifisches Profil, aber Stufe 2 wird mit jedem Passwort akzeptiert.
6. Manche Ladestationen benötigen das Root-Zertifikat des CSMS (Root-CA-Zertifikat).
7. Manche Ladestationen verlangen Port 80 oder 443: Ergänzen Sie ihn in diesem Fall in der URL.
8. Manche Ladestationen trennen Host, Port, Pfad und ChargeBoxID und setzen daraus die WSS-URL für ausgehende Aufrufe zusammen.
9. Manche Ladestationen bieten kein ChargeBoxID-Feld: Dann muss es am Ende der URL ergänzt werden, sonst wird der Aufruf auf unserer Seite abgelehnt (dieses Feld ist der Primärschlüssel in unserer Datenbank).
10. Manche Ladestationen hängen am Ende der URL einen Schrägstrich an, andere nicht (auf unserer Seite gibt es dazu keine Einschränkung).
11. Manche Ladestationen kürzen die URL, weil sie zu lang ist (immer seltener).

Symptom: Im Menü Sitzungen / Verlauf erscheinen Geistersitzungen, und ein laufender Ladevorgang lässt sich nicht beenden. Fehlerlog: Remote Stop Transaction has been rejected in 1.52s, reason 'Rejected'.

Ablauf in den Logs:

EVSE <- CSMS : remoteStartTransaction with transactionID
EVSE -> CSMS : accepted
EVSE -> CSMS : StartTransaction with tagID
EVSE <- CSMS : accepted
...
EVSE <- CSMS : remoteStopTransaction with the same transactionID
EVSE -> CSMS : rejected   <- error message: you are blocked here
EVSE -> CSMS : StopTransaction with same tagID
EVSE <- CSMS : accepted

Erklärungen: Die Sitzung bleibt auf CSMS-Seite offen, unabhängig vom tatsächlichen Zustand der Ladestation, da wir ihren Zustand nicht kennen (es wurde keine StopTransaction empfangen). Ein Neustart der Ladestation hat daher keinen Einfluss auf die offene Sitzung, solange das CSMS nicht die StopTransaction der Ladestation mit der richtigen Transaktions-ID erhält. Das Starten einer weiteren Sitzung erzeugt eine weitere TransactionID, also einen weiteren Eintrag in unserer Datenbank.

Lösung: Sie haben nur eine Möglichkeit: Wählen Sie in der Benutzeroberfläche die Schaltfläche „Force Stop“, die bei jeder laufenden Sitzung verfügbar ist. Damit wird das Beenden auf CSMS-Seite erzwungen.

Symptom: Im Menü Sitzungen / Verlauf erscheinen Geistersitzungen oder ein ungewöhnlicher Status der Ladestation (anders als CHARGING / SUSPENDED / FAULTED / RESERVED).

Normalfall, wenn die StopTransaction empfangen wird

• StopTransaction + AVAILABLE (FINISHING optional): Die Transaktion wird beendet und abgeschlossen.
• FINISHING ist nicht erforderlich: Geprüft werden nur AVAILABLE oder PREPARING (FINISHING dient der Berechnung der Parkzeit).
• SUSPENDED, FAULTED und RESERVED haben keinen Einfluss auf den Ablauf.

„Ungewöhnliche“ Fälle, die automatisch behandelt werden

1. StopTransaction empfangen, aber nach X Minuten nie eine StatusNotification: automatischer „Force Stop“ durch eine geplante Aufgabe des CSMS (30 Minuten Verzögerung).
2. Neue StartTransaction ohne vorherige StopTransaction empfangen: Ohne Verbrauch wird die Transaktion gelöscht; bei Verbrauch erfolgt ein automatischer „Force Stop“.
3. StatusNotification AVAILABLE ohne unmittelbar vorherige StopTransaction: Die Transaktion bleibt aktiv (keine sofortige Aktion). Trifft der Stopp danach ein, verläuft der Abschluss normal; trifft er nicht ein, wendet die geplante Aufgabe einen „Force Stop“ an (30 Minuten).
4. StatusNotification AVAILABLE vor der StopTransaction: Das System erzeugt künstlich eine StatusNotification aus dem aktuellen Anschlussstatus (Available) und dem Zeitstempel der StopTransaction, um die zusätzliche Standzeit korrekt zu berechnen.

Beispiel für einen realen Ablauf:

T1: Available received   -> no action (no StopTransaction)
T2: Stop received        -> detects connector = Available
                          -> creates a synthetic StatusNotification
                          -> finalises the transaction

Lösung: In allen anderen als den oben beschriebenen Fällen können Sie die Transaktion manuell bei den „laufenden“ Sitzungen mit der Schaltfläche „Force Stop“ beenden.