Wenn ein Ladegerät das Backend erreicht, aber nie nutzbar zu sein scheint, liegt der Fehler fast immer in den ersten paar Nachrichten der Sitzung und nicht irgendwo später. Bei BootNotification und Heartbeat stellt eine Verbindung entweder eine Arbeitsbeziehung her oder scheitert stillschweigend daran.
Der Grund dafür, dass diese Probleme schwer zu diagnostizieren sind, liegt darin, dass in der Regel beide Seiten von Erfolgen berichten. Das Ladegerät sagt, es habe BootNotification gesendet. Die Plattform gibt an, eine Verbindung akzeptiert zu haben. Beides lügt nicht und das Ladegerät ist immer noch unbrauchbar.
Was BootNotification tatsächlich feststellt
BootNotification ist das Ladegerät, das sich vorstellt. Es sendet seine Identität und Hardwaredetails, und das Zentralsystem antwortet mit einem Status, der aktuellen Uhrzeit und einem Intervall, das dem Ladegerät mitteilt, wie oft Heartbeats gesendet werden sollen.
Diese Antwort ist wichtiger als die Bitte. Der Status bestimmt, ob das Ladegerät akzeptiert, zum Warten aufgefordert oder direkt abgelehnt wird, und jeder dieser Status führt danach zu einem sehr unterschiedlichen Verhalten.
Die drei Antworten und was sie bedeuten
Ein Ladegerät, das in der Warteschleife steckt, ist der am häufigsten fehldiagnostizierte Fall. Alles sieht verbunden aus, es treten keine Fehler auf und das Gerät startet keine Sitzung, da die Inbetriebnahme aus Sicht der Plattform noch nicht abgeschlossen ist.
- Akzeptiert: Das Ladegerät ist registriert und kann mit dem normalen Betrieb, einschließlich Transaktionen, beginnen.
- Ausstehend: Das Zentralsystem kennt das Ladegerät, ist jedoch nicht bereit, es zu autorisieren, normalerweise weil die Konfiguration oder Bereitstellung unvollständig ist. Das Ladegerät sollte warten und es erneut versuchen, anstatt fortzufahren.
- Abgelehnt: Das Zentralsystem akzeptiert dieses Ladegerät nicht. Es sollte erst nach dem angegebenen Intervall erneut versucht werden.
Identitätskonflikte sind die häufigste Ursache
Die von der Einheit gesendete Ladepunktidentität muss genau den Erwartungen der Plattform entsprechen. Ein nachgestelltes Leerzeichen, ein Unterschied zwischen Groß- und Kleinschreibung oder eine vom Etikett statt von der Firmware eingegebene Seriennummer führen zu einer Verbindung, die auf der Transportschicht hergestellt wird und auf der Anwendungsschicht fehlschlägt.
Es lohnt sich, dies zunächst zu prüfen, da es schnell auszuschließen ist und einen Großteil der Inbetriebnahmefehler verursacht. Lesen Sie die Identität anhand der Konfiguration des Ladegeräts und nicht anhand des Aufklebers ab.
Heartbeat ist eine Lebendigkeitsprüfung, kein Keepalive
Das in der BootNotification-Antwort zurückgegebene Heartbeat-Intervall teilt dem Ladegerät mit, wie oft es einchecken soll. Sein Zweck besteht darin, der Plattform mitzuteilen, dass das Ladegerät noch da ist, und die Uhr des Ladegeräts mit der der Plattform in Einklang zu bringen.
Daraus ergeben sich zwei Fehlermodi. Wenn das Intervall länger ist als das Leerlauf-Timeout des Netzwerks, bricht die Verbindung zwischen den Heartbeats ab und das Ladegerät scheint zu flattern. Wenn das Ladegerät das ihm zugewiesene Intervall ignoriert und sein eigenes verwendet, markiert die Plattform es möglicherweise als offline, während es glaubt, verbunden zu sein.
Schleifen wieder verbinden
Ein Ladegerät, das alle paar Sekunden die Verbindung wiederherstellt, wird normalerweise an einem Ort zurückgewiesen, an dem es keine Meldung erhalten kann. Häufige Ursachen sind ein WebSocket-Upgrade, das fehlschlägt, nachdem die TCP-Verbindung erfolgreich hergestellt wurde, eine Nichtübereinstimmung des Unterprotokolls, bei der sich die beiden Seiten nicht auf die OCPP-Version einigen können, oder ein Zertifikatproblem bei einer gesicherten Verbindung.
Schauen Sie sich hier die Transportschicht vor der Anwendungsschicht an. Ein Ladegerät, das nie weit genug kommt, um BootNotification zu senden, wird überhaupt keinen OCPP-Nachweis erzeugen, der selbst das Diagnosesignal ist.
Uhrendivergenz
Die BootNotification-Antwort überträgt die Zeit des zentralen Systems und Ladegeräte nutzen sie, um ihre eigene Zeit einzustellen. Wenn ein Ladegerät es nicht anwendet oder es anwendet und dann abweicht, stimmen die Transaktionszeitstempel zwischen den beiden Seiten nicht mehr überein.
Dies verhindert selten das Aufladen. Stattdessen wird der Abrechnungsabgleich stillschweigend beschädigt, was noch schlimmer ist, da er erst am Monatsende und nicht erst bei der Inbetriebnahme entdeckt wird.
Eine funktionierende Reihenfolge zum Debuggen
Jeder Schritt macht den nächsten bedeutungsvoll. Das Debuggen außerhalb der Reihenfolge führt zu der bekannten Situation, in der beide Parteien Beweise dafür haben, dass ihre Seite in Ordnung ist.
- Stellen Sie sicher, dass das Ladegerät das Backend überhaupt auf der Transportebene erreicht.
- Bestätigen Sie, dass das WebSocket-Upgrade abgeschlossen ist und beide Seiten sich auf ein OCPP-Unterprotokoll geeinigt haben.
- Erfassen Sie die BootNotification-Anfrage und lesen Sie die tatsächlich gesendete Identität.
- Lesen Sie den Antwortstatus. „Ausstehend“ und „Abgelehnt“ sind Antworten, keine Fehler.
- Bestätigen Sie, dass das Ladegerät das vorgegebene Heartbeat-Intervall übernommen hat.
- Vergleichen Sie nach dem Booten die Uhr des Ladegeräts mit der der Plattform.
Wenn es nicht am Ladegerät liegt
Plattformen unterscheiden sich darin, was sie beim Booten benötigen. Manche gehen davon aus, dass das Ladegerät keine Konfigurationsschlüssel sendet. Einige lehnen gültige, aber nicht vorregistrierte Identitäten ab. Ein Ladegerät, das gegen ein Backend funktioniert und gegen ein anderes ausfällt, hat sich nicht unbedingt geändert.
Dies ist der praktische Unterschied zwischen Protokollkonformität und Interoperabilität. Aus diesem Grund wird die Integration anhand der spezifischen Plattform und Version überprüft, die Sie ausführen möchten.