Als een oplader de backend bereikt maar nooit bruikbaar lijkt, ligt de fout bijna altijd in de eerste paar berichten van de sessie en niet ergens later. BootNotification en hartslag zijn de plekken waar een verbinding een werkrelatie tot stand brengt of daar stilletjes niet in slaagt.
De reden dat deze problemen moeilijk te diagnosticeren zijn, is dat beide partijen doorgaans succes melden. De oplader zegt dat hij BootNotification heeft verzonden. Het platform zegt een verbinding te hebben geaccepteerd. Geen van beide liegt en de oplader is nog steeds onbruikbaar.
Wat BootNotification feitelijk tot stand brengt
BootNotification is de oplader die zichzelf introduceert. Het verzendt zijn identiteit en hardwaregegevens, en het centrale systeem antwoordt met een status, de huidige tijd en een interval dat de oplader vertelt hoe vaak hartslagen moeten worden verzonden.
Dat antwoord is belangrijker dan het verzoek. De status bepaalt of de oplader wordt geaccepteerd, moet wachten of ronduit wordt afgewezen, en elk daarvan veroorzaakt daarna heel ander gedrag.
De drie reacties en wat ze betekenen
Een oplader die vastzit in In behandeling is het vaakst verkeerd gediagnosticeerde geval. Alles lijkt met elkaar verbonden, er verschijnen geen fouten en het apparaat zal geen sessie starten, omdat het vanuit het perspectief van het platform nog niet klaar is met inbedrijfstelling.
- Geaccepteerd: de oplader is geregistreerd en kan normaal functioneren, inclusief transacties.
- In behandeling: het centrale systeem kent de lader, maar is nog niet klaar om deze te autoriseren, meestal omdat de configuratie of inrichting onvolledig is. De oplader moet wachten en het opnieuw proberen, in plaats van verder te gaan.
- Afgewezen: het centrale systeem accepteert deze oplader niet. Het zou het pas opnieuw moeten proberen na het opgegeven interval.
Identiteitsmismatch is de meest voorkomende oorzaak
De laadpuntidentiteit die het apparaat verzendt, moet precies overeenkomen met wat het platform verwacht. Een spatie, een verschil in hoofdletters of een serienummer dat vanaf het label wordt ingevoerd in plaats van vanaf de firmware, zal allemaal een verbinding opleveren die tot stand komt op de transportlaag en mislukt op de applicatielaag.
Dit is de moeite waard om eerst te controleren, omdat het snel kan worden uitgesloten en verantwoordelijk is voor een groot deel van de fouten bij de inbedrijfstelling. Lees de identiteit af van de eigen configuratie van de oplader en niet van de sticker.
Heartbeat is een liveness check, geen keepalive
Het hartslaginterval dat wordt geretourneerd in het BootNotification-antwoord vertelt de oplader hoe vaak hij moet inchecken. Het doel is om het platform te laten weten dat de oplader er nog is, en om de klok van de oplader op één lijn te houden met die van het platform.
Daaruit volgen twee faalwijzen. Als het interval langer is dan de time-out voor inactiviteit van het netwerk, valt de verbinding tussen hartslagen weg en lijkt het alsof de oplader klappert. Als de oplader het gegeven interval negeert en zijn eigen interval gebruikt, kan het platform deze offline markeren terwijl hij denkt dat hij verbonden is.
Sluit de lussen opnieuw aan
Een oplader die om de paar seconden opnieuw verbinding maakt, wordt meestal ergens afgewezen waar hij geen melding kan maken. Veelvoorkomende oorzaken zijn een WebSocket-upgrade die mislukt nadat de TCP-verbinding tot stand is gebracht, een subprotocol dat niet overeenkomt waarbij de twee partijen het niet eens kunnen worden over de OCPP-versie, of een certificaatprobleem met een beveiligde verbinding.
Bekijk hier de transportlaag vóór de applicatielaag. Een oplader die nooit ver genoeg komt om BootNotification te verzenden, zal helemaal geen OCPP-bewijs opleveren, wat zelf het diagnostische signaal is.
Klokdivergentie
Het BootNotification-antwoord draagt de tijd van het centrale systeem over, en opladers gebruiken deze om hun eigen tijd in te stellen. Wanneer een oplader dit niet toepast, of het wel toepast en vervolgens afwijkt, komen de transactietijdstempels niet meer overeen tussen de twee partijen.
Dit verhindert zelden het opladen. In plaats daarvan corrumpeert het stilletjes de factureringsafstemming, wat nog erger is, omdat het aan het einde van de maand wordt ontdekt in plaats van bij de inbedrijfstelling.
Een werkende opdracht om in te debuggen
Elke stap maakt de volgende betekenisvol. Foutopsporing in de verkeerde volgorde levert de bekende situatie op waarin beide partijen het bewijs hebben dat hun kant in orde is.
- Controleer of de oplader überhaupt de backend op de transportlaag bereikt.
- Bevestig dat de WebSocket-upgrade is voltooid en dat beide partijen een OCPP-subprotocol zijn overeengekomen.
- Leg het BootNotification-verzoek vast en lees de identiteit die het daadwerkelijk heeft verzonden.
- Lees de reactiestatus. In behandeling en afgewezen zijn antwoorden, geen fouten.
- Controleer of de oplader het opgegeven hartslaginterval heeft overgenomen.
- Vergelijk de klok van de oplader met die van het platform na het opstarten.
Wanneer het niet de oplader is
Platforms verschillen in wat ze nodig hebben bij het opstarten. Sommigen verwachten configuratiesleutels die de oplader niet verzendt. Sommigen wijzen identiteiten af die geldig zijn maar niet vooraf zijn geregistreerd. Een oplader die tegen de ene backend werkt en tegen de andere faalt, is niet noodzakelijkerwijs veranderd.
Dit is het praktische verschil tussen protocolnaleving en interoperabiliteit, en daarom wordt de integratie geverifieerd aan de hand van het specifieke platform en de specifieke versie die u wilt gebruiken.