Subscribe & get the latest news in your email
Door
Joachim Lohse
September 15, 2026
De lader geeft de status Beschikbaaraan. De bestuurder sluit de kabel aan. Er gebeurt niets. Of de sessie loopt twee uur en stopt bij 4% onder het doel, terwijl het dashboard de hele tijd aangeeft dat de poort online is.
Elke beheerder krijgt hier wekelijks mee te maken. Bijna niemand publiceert de beslisboom hiervoor.
Deze gids is die beslisboom. Het verdeelt storingen in EV-laadsessies in drie takken op basis van wat er om 6 uur 's ochtends op een terrein zichtbaar is — wat de lader deed — en geeft vervolgens het diagnosesignaal voor elk scenario: de OCPP-status en foutcode die je kunt verwachten, of het bewijs in het logboek van de lader of het backend-logboek staat, en hoe je een voertuigfout, laderfout en netwerkfout van elkaar onderscheidt. Het laatste deel behandelt de operationele laag: welke storingen zichzelf herstellen, welke een reset op afstand vereisen, waarvoor een monteur ter plaatse moet komen, en hoe je elke melding doorstuurt zonder je team te overspoelen met alerts.
De volgorde is belangrijk. Tak één betekent dat de lader nooit zou gaan werken; wat de bestuurder ook doet, dat verandert niets. Tak twee en drie zijn de moeite waard voor een bestuurder.
Hoe het eruitziet. Het statuslampje is rood. Het scherm geeft 'niet beschikbaar', 'defect', 'buiten gebruik' of een vergelijkbare melding aan. Dit is zichtbaar voordat er iets wordt aangesloten.
Wat de bestuurder moet doen. Niets. Dit is belangrijk om duidelijk te vermelden, omdat bestuurders hier tijd verliezen. Een lader in deze staat zal het authenticatieproces helemaal niet starten — inpluggen en een pasje scannen zal geen sessie opleveren, hoe vaak het ook wordt geprobeerd. Als er een alternatieve lader is, gebruik die dan. Als dit de enige optie is, bel dan de beheerder van de locatie of de supportlijn en laat hen het probleem oplossen.
Wat er aan de hand is. In OCPP 1.6 is dit een StatusNotification met status Faulted of Niet beschikbaar, en de bijbehorende errorCode is de diagnostische payload. Veelvoorkomende codes en waar ze op wijzen:
Drie verschillende oorzaken leiden tot deze status, en ze zijn niet allemaal even waarschijnlijk:
ChangeAvailability naar Inoperative in de backend, geen defect. Het zou uw eigen team nooit moeten verrassen, maar het verrast bestuurders regelmatig.Wat het meestal niet is: een verbindingsprobleem. Dit is een veelgemaakte misdiagnose. Laders zijn ontworpen om een tijdje te blijven werken zonder backend-verbinding door gebruik te maken van gecachte autorisatielijsten. Een lader die de netwerkverbinding is verloren, zal doorgaans gewoon blijven laden; hij zal meestal niet op Faultedspringen. Als uw locaties te maken hebben met echte offline periodes, is dat een geval voor connectiviteit met redundantie en fallback en ondersteuning voor offline laden — maar zoek de oorzaak niet in het netwerk als je naar een rood lampje kijkt.
Hoe het eruitziet. De lader is groen. De bestuurder plugt in en authenticeert — via de mobiele app, laadpas of automatische authenticatie via het voertuig. De lader doet zichtbaar iets: het scherm verandert, het lijkt alsof hij zich voorbereidt. Vervolgens springt hij terug naar beschikbaar of naar een foutmelding. Haal de kabel eruit en hij wordt weer groen.
Dit is de meest verwarrende tak voor bestuurders, omdat alles eruitziet alsof het zou moeten werken.
Herhaalstappen voor de bestuurder — in deze volgorde:
Wat er op de achtergrond gebeurt. De lader gaat van Beschikbaar → Voorbereiden het moment dat een kabel of kaart wordt aangeboden. Die overgang is normaal en betekent dat de lader zijn werk doet. Wat daarna gebeurt is waar het misgaat, en er zijn twee verschillende soorten defecten die er van buitenaf hetzelfde uitzien.
Categorie A — autorisatie en backend. De lader verstuurt een Authorize verzoek (of de idTag in een StartTransaction) naar de backend. De backend antwoordt met een idTagInfo status:
Invalid — kaart of account onbekend in dit systeemBlocked — bekend, maar geblokkeerdExpired — geldigheidsduur verstrekenConcurrentTx — dit token heeft al ergens een actieve sessieAccepted — vrijgegeven om te ladenElke niet-Geaccepteerd antwoord beëindigt de poging en de lader keert terug naar Beschikbaar. Dit is deterministisch: het zal bij elke nieuwe poging op dezelfde manier mislukken, en dat is het teken. Het bewijs staat in het backend-logboek, niet in de lader. De lader weet alleen dat het werd geweigerd; de backend weet waarom.
Er is een derde mogelijkheid in deze categorie: de backend heeft helemaal niet geantwoord omdat er een time-out optrad of omdat deze overbelast was. Dit komt minder vaak voor, maar levert hetzelfde zichtbare gedrag op — en in tegenstelling tot een geweigerde kaart kan een nieuwe poging hier wel degelijk slagen. Dit is het enige geval waarin "probeer het opnieuw" een oprecht advies is in plaats van een vertragingstactiek.
Categorie B — de lader kan niet communiceren met het voertuig. Lader en voertuig wisselen gegevens uit via de control pilot in de kabel: gereedheid, beschikbare stroom, foutstatussen. Als het voertuig al een tijdje geparkeerd staat, kan de communicatiecontroller in de slaapstand zijn gegaan en niet meer wakker worden om te antwoorden.
In OCPP 1.6 verschijnt dit als errorCode: EVCommunicationError, of als een sessie die SuspendedEV bereikt en daar blijft hangen — de lader is klaar en biedt stroom aan, maar het voertuig neemt deze niet af. Dat onderscheid is het meest bruikbare signaal in deze hele gids: SuspendedEVSE betekent dat de lader of de locatie de stroomtoevoer inhoudt; SuspendedEV betekent dat het voertuig in de wacht staat. De ene is voor jou om op te lossen, de andere is voor het wagenpark.
De uit/aan/uit-cyclus in de herhalingsreeks is er specifiek om de controller van het voertuig te wekken. Dit werkt vaak genoeg om het te proberen voordat er wordt opgeschaald.
Hoe je de families snel uit elkaar houdt: als het elke keer identiek mislukt met een schone terugkeer naar Beschikbaar, vermoed dan een autorisatieprobleem — controleer de backend. Als het gedrag varieert tussen pogingen, of als de sessie blijft hangen in een opgeschorte status, vermoed dan een probleem met de voertuigcommunicatie. Real-time OCPP-waarschuwingen en status van lader en connector geven je dit onderscheid zonder dat iemand ruwe logs op een terrein hoeft te lezen.
Hoe het eruitziet. De sessie is correct gestart. Het voertuig heeft daadwerkelijk energie afgenomen — enkele kWh, mogelijk gedurende uren. Daarna stopte het, terwijl het voertuig nog niet vol was.
Acties voor de bestuurder: start een nieuwe sessie. Als dat niet werkt, zet het voertuig uit en aan en probeer het opnieuw. Als het nog steeds niet lukt, probeer dan een andere kaart of account.
Wat het onderliggend betekent. Omdat je een werkende sessie had, is een hardwarestoring de minst waarschijnlijke verklaring. Begin daarom eerst met het beleid.
Meest voorkomende oorzaak: een ingestelde SoC-limiet. Veel depots en openbare locaties begrenzen laadsessies op een beoogde laadstatus (SoC). Dit is een bewuste keuze om twee goede redenen. Ten eerste neemt de laadsnelheid bij de meeste voertuigen vanaf ongeveer 80% SoC sterk af, waardoor het laatste deel onevenredig lang duurt en de lader bezet houdt voor het volgende voertuig. Ten tweede verkort het dagelijks volledig opladen tot 100% meetbaar de levensduur van het accupakket. Als uw wagenpark dit doet, zorg er dan voor dat chauffeurs hiervan op de hoogte zijn — een geplande stop die niet is gedocumenteerd, leidt tot dezelfde supportvraag als een daadwerkelijk defect.
Tweede oorzaak: een autorisatielimiet. Op openbare locaties hanteren tankpassen en creditcards pre-autorisatielimieten. Wanneer de kosten van de sessie dat plafond bereiken, beëindigen veel exploitanten de sessie liever dan het risico te lopen. Een nieuwe sessie reset de limiet, en dat is waarom opnieuw starten vaak werkt.
Derde oorzaak: er is daadwerkelijk iets misgegaan. OCPP StopTransaction bevat een reason veld, en dit is de snelste manier om dit uit te sluiten:
Een Remote stop op een depotlocatie is vaak uw eigen load balancing die precies doet waarvoor deze is geconfigureerd. Controleer dat voordat u iemand op pad stuurt.
De twee logboeken beantwoorden verschillende vragen, en het raadplegen van de verkeerde kost de eerste twintig minuten van elk onderzoek.
InternalError of OverigeFout.De praktische regel: als de fout deterministisch en schoonwas, is het een backend-kwestie. Als deze rommelig, intermitterend of fysiekwas, is het een lader-kwestie.
Voorheen moest je voor het laderlogboek naar de locatie toe. Dat zou niet nodig moeten zijn. Hardware-diagnostiek en laderlogging en audit zorgen ervoor dat dit een taak is die vanaf je bureau kan worden uitgevoerd. Dat is belangrijk, want het verschil tussen diagnose op afstand en diagnose op locatie is een volledige werkdag van een monteur.
Diagnose is het halve werk. De andere helft is routering: bepalen welke fouten überhaupt menselijke aandacht vereisen.
Zelfherstel: log het, maar stuur geen melding. Thermische derating die zichzelf herstelt. Enkele SuspendedEV gebeurtenissen bij voertuigen die daarna prima opladen. Kortstondige onderbrekingen in de heartbeat die binnen het retry-venster herstellen. Door hier meldingen van te sturen, leert je team om waarschuwingen te negeren, wat een slechter resultaat is dan ze missen.
Reset op afstand: probeer het automatisch, stuur alleen een melding bij een mislukking. ConnectorLockFailure, ReaderFailureen vele InternalError gevallen lossen op met een soft reset. Probeer dit eerst en schakel pas een medewerker in als de reset niet helpt of de foutmelding terugkeert. Lader op afstand bedienen en geautomatiseerde firmware-updates vangen het grootste deel van deze categorie op — terugkerende firmwarefouten moeten in het bijzonder worden opgelost met een versie-update, niet met herhaaldelijke resets.
Monteur aansturen — direct alarmeren, inclusief context. GroundFailure, PowerSwitchFailure, PowerMeterFailure, fysieke schade aan de connector en alles wat na twee resets nog steeds niet werkt. Een lader die echt defect is, moet worden geïnspecteerd of gerepareerd, wat uren tot dagen kan duren. De melding moet direct de foutcode, het logboekfragment en de resethistorie bevatten, zodat de monteur precies weet wat hij kan verwachten. Multi-channel notificaties, het waarschuwingscentrum, en teamoverleg over waarschuwingen voorkomen dat dit een eindeloze belronde wordt.
Niet jouw probleem? Stuur het door. Storingen aan de voertuigzijde zijn voor het wagenpark of de OEM. Betalings- en roamingproblemen zijn voor de eMSP. Leveringsproblemen zijn voor het energiebedrijf. De kosten zitten hier niet in de reparatie, maar in het uur dat je kwijt bent om vast te stellen dat het jouw schuld niet was. Eerstelijns helpdesk en tweedelijns ondersteuning zijn er om die triage op te vangen voordat het je technici bereikt.
Het basisprincipe: elke waarschuwing moet leiden tot een actie die iemand kan ondernemen. Al het andere is ruis, en door die ruis worden echte storingen gemist. Door dit te combineren met preventief onderhoud voor laders verdwijnt een aanzienlijk deel van deze defecten volledig uit de reactieve wachtrij.
Waarom geeft mijn lader 'Beschikbaar' aan, maar start de sessie niet?De lader is klaar voor gebruik, maar er gaat in de vervolgstap iets mis. Meestal is dit een autorisatieweigering vanuit de backend, een time-out van de backend, of een communicatiefout tussen de lader en het voertuig via de kabel. Het voertuig uit- en weer aanzetten en binnen 20 seconden opnieuw proberen, lost het probleem aan de voertuigzijde vaak op.
Waarom is mijn laadsessie gestopt voordat de batterij vol was?Meestal is dit een bewuste keuze. Veel depots en openbare locaties begrenzen sessies tot een bepaalde laadstatus om de aansluiting vrij te maken en de levensduur van de accu te beschermen. Een andere veelvoorkomende oorzaak is een limiet voor pre-autorisatie op een tank- of creditcard. Het starten van een nieuwe sessie hervat doorgaans het laden.
Hoe kan ik zien of het probleem bij de lader of het voertuig ligt?Controleer welke kant de sessie heeft onderbroken. In OCPP betekent SuspendedEVSE dat de lader of de locatie de stroomtoevoer blokkeert; SuspendedEV betekent dat het voertuig de stroom niet accepteert. EVCommunicationError wijst op een probleem met de datalink van de kabel naar het voertuig.
Stopt een lader met werken als de internetverbinding wegvalt?Over het algemeen niet. Laders blijven een tijdje werken zonder verbinding met het back-end door gebruik te maken van opgeslagen autorisatiegegevens. Een rode of defecte lader heeft veel vaker een hardware- of configuratieprobleem dan een netwerkprobleem.
Bij welke laadstoringen is een bezoek aan de locatie nodig?Aardfouten, defecten aan contactors of meters, fysieke schade en elke fout die na twee keer op afstand resetten terugkeert. De meeste andere categorieën — zoals vergrendelingsfouten, lezerfouten, thermische incidenten en veel interne fouten — kunnen op afstand worden opgelost.
Bespaar op onnodige servicebezoeken. Ampcontrol biedt operators real-time OCPP-meldingen, diagnose op afstand en afstandsbediening voor elk merk lader — de basis voor het monitoren en onderhouden van uw laders en voor het gebruik van OCPP voor laadoperaties op grote schaal. Boek een demo om te zien hoe het werkt voor uw eigen locaties.
Ampcontrol is een cloudgebaseerde software die naadloos aansluit op laadnetwerken, voertuigen, wagenparksystemen en andere softwaresystemen. Geen hardware nodig, slechts een eenmalige integratie.
