OCPP-2.0.1-Testtool für Ladestations- und Wallbox-EntwicklerSehen Sie, was Ihre Ladestation wirklich sendet
EVSExplorer ist ein OCPP-2.0.1-Test-CSMS für die Entwicklung von Ladestationen und Wallboxen. Verbinden Sie eine echte Station, prüfen Sie jede Nachricht gegen die offiziellen Schemata, analysieren Sie die Verbindungsstabilität, senden Sie beliebige Requests und automatisieren Sie alles über die REST-API. In unserer Cloud oder auf Ihrer eigenen Hardware.
- Cloud oder eigene Hardware: Ihre Wahl, gleiches Produkt
- OCPP-2.0.1-WebSocket-Server für echte Ladestationen
- Jede Nachricht gegen die offiziellen JSON-Schemata validiert
- Vollständige REST-API für CI und Testskripte
- Bereit für KI-Agenten (Skill-Datei inklusive)
Für das ganze Ladestations-Team
Von der ersten BootNotification eines neuen Prototyps bis zum Release-Testbericht. Ein Werkzeug für den Prüfstand.
Entwickler
Jede Nachricht live verfolgen, während Sie entwickeln. Beobachten Sie die OCPP-J-Nachrichten Ihrer Station in Echtzeit, prüfen Sie schema-validierte Payloads und beantworten Sie „Was haben wir eigentlich gesendet?“ in Sekunden, ohne serielle Logs zu durchsuchen.
Tester
Machen Sie Wackelkandidaten reproduzierbar. Schließen Sie WebSocket-Verbindungen, blockieren Sie Reconnects, antworten Sie automatisch mit eigenen oder absichtlich fehlerhaften Payloads und beobachten Sie genau, wie sich die Station erholt.
Projektleiter
Wissen, wo jeder Prototyp steht. Ein Live-Dashboard über alle Geräte auf dem Prüfstand, Uptime-Zahlen und Ladehistorien, die Sie direkt in den Statusbericht übernehmen können.
Ein genauerer Blick
Echte Screenshots, echte Datenflüsse! So sieht der Alltag mit EVSExplorer aus.
Nachrichten-Log
Jede OCPP-Nachricht, validiert und durchsuchbar
Rohe OCPP-J-Nachrichten in beide Richtungen, geprüft gegen die offiziellen OCPP-2.0.1-JSON-Schemata. Filtern Sie nach Aktion, Richtung oder Payload-Inhalt, blenden Sie Heartbeats aus und öffnen Sie jede Nachricht, um zu sehen, was tatsächlich übertragen wurde.
- Request-/Response-/Error-Zuordnung mit Anomalie-Erkennung (verspätete, doppelte und unzuordenbare Antworten werden markiert)
- Volltextsuche in Payloads
- Rollierende Zeitfenster oder historische Zeiträume
Verbindungsstabilität
Finden Sie instabile Verbindungen vor Ihren Kunden
Sitzungen, Offline-Lücken und abgewiesene Verbindungsversuche werden aus den rohen WebSocket-Ereignissen abgeleitet, inklusive der Frage, wer die Verbindung beendet hat und warum.
- Uptime, Verbindungszähler und längste Offline-Lücke je Zeitfenster
- Close-Codes und Verursacher: Hat die Station den Socket geschlossen oder das CSMS?
- Sitzungsverlauf sekundengenau
Ladevorgänge
Vom ersten TransactionEvent bis zum letzten Messwert
Ladevorgänge mit vollständiger Ereignis-Zeitleiste und Diagrammen für jeden gemeldeten Messwert (Leistung, Energie, Ladezustand, Spannung, Strom, je Phase, sofern verfügbar).
- Sequenznummern sichtbar gemacht (Lücken zeigen verlorene Ereignisse)
- Offline aufgezeichnete Messwerte werden gekennzeichnet
- Stop-Grund, ID-Token und Remote-/Lokal-Kontext je Ladevorgang
Kommando-Konsole
Senden Sie jeden Request, auch absichtlich nicht OCPP-konforme
Senden Sie jede CSMS-initiierte OCPP-2.0.1-Aktion mit editierbarer Payload-Vorlage. Schema-Verletzungen sind ausdrücklich erlaubt: Negativtests sind ein Feature, kein Fehler.
- Payload-Vorlagen für alle OCPP-2.0.1-Aktionen
- %UTC_TIMESTAMP%-Platzhalter wird beim Senden aufgelöst
- Antworten werden verfolgt, bis sie abgeschlossen sind, fehlschlagen oder das Timeout greift
Alles, was Sie für OCPP 2.0.1 brauchen
Keine Mock-Daten, keine Magie. Jede Funktion arbeitet auf Basis der echten Nachrichten Ihrer Ladestationen.
OCPP-2.0.1-CSMS
Ein WebSocket-Server für OCPP-J 2.0.1 mit vielen Ladepunkten gleichzeitig, optional mit HTTP Basic Auth je Station.
Schema-Validierung
Jede ein- und ausgehende Nachricht wird gegen die offiziellen OCPP-2.0.1-JSON-Schemata geprüft, sodass Compliance-Probleme sofort auffallen.
Live-Dashboard
Alle registrierten Ladepunkte mit Verbindungs- und Ladestatus, Firmware- und Herstellerinfo, automatisch aktualisiert.
Automatische Antworten
Beantworten Sie stationsseitige Requests automatisch: eigene Payloads je Aktion, Standard-CallErrors oder volle manuelle Kontrolle.
Verbindungsanalyse
Uptime, Sitzungen, Offline-Lücken, Close-Codes und abgewiesene Verbindungsversuche, abgeleitet aus jedem einzelnen WebSocket-Ereignis.
WebSocket-Kontrolle
Trennen Sie die Verbindung einer Station oder blockieren Sie Reconnects für definierte Zeiträume, um das Offline-Verhalten Ihrer Ladestation zu testen.
Ladevorgänge & Messwerte
Ereignis-Zeitleisten mit Erkennung verlorener Ereignisse und Diagramme je Messgröße für die detaillierte Analyse.
Security-Ereignisse
Sicherheitsmeldungen und zertifikatsbezogene Ereignisse jeder Ladestation an einem Ort.
Device-Model-Browser
Fordern Sie einen Base Report an und navigieren Sie durch den EVSE-/Komponenten-/Variablen-Baum der Station.
Kommando-Konsole
Jede CSMS-initiierte Aktion mit editierbaren Payloads, auch absichtlich ungültige für Negativtests.
Nachrichten-Historie
Durchsuchen und filtern Sie sämtliche OCPP-Nachrichten in rollierenden oder historischen Zeitfenstern.
REST-API
Alles, was die Oberfläche kann, gibt es als dokumentierte REST-API, die Basis für skriptgesteuerte Tests und CI.
Automatisieren Sie alles über die REST-API
Die Oberfläche ist nur ein Client. Registrieren Sie Stationen, senden Sie Kommandos, lesen Sie Logs und prüfen Sie Ergebnisse aus Ihren Testskripten oder der CI-Pipeline. Die OpenAPI-Spezifikation dokumentiert jeden Endpunkt.
- Beliebige OCPP-Aktionen senden und das Ergebnis abfragen (202, dann completed, failed oder timed out)
- Nachrichten-Logs, Verbindungsereignisse, Ladevorgänge und Messwerte mit Zeitfiltern abfragen
- Automatische Antworten und Verbindungsblockaden zur Laufzeit konfigurieren
Läuft auch auf Ihrer eigenen Hardware (ein Raspberry Pi genügt). Ihre OCPP-Nachrichten verlassen niemals Ihr Labor.
# Register a charge point identity
curl -X POST http://bench-pi:8081/api/charge-points \
-H 'Content-Type: application/json' \
-d '{"id": "PROTO-0042", "name": "Prototype 42"}'
# Fire an OCPP request at the station
curl -X POST http://bench-pi:8081/api/charge-points/PROTO-0042/commands/TriggerMessage \
-d '{"requestedMessage": "BootNotification"}'
# 202 Accepted {"message_id": "4f2a97c1-..."}
# Poll the result and assert on the reply
curl http://bench-pi:8081/api/charge-points/PROTO-0042/commands/4f2a97c1-...
# {"status": "completed", "response": {"status": "Accepted"}}Bereit für KI
Lassen Sie Ihren KI-Agenten den Prüfstand bedienen
Die REST-API ist auf die effiziente Nutzung durch LLM-basierte Agenten ausgelegt, und EVSExplorer liefert eine Skill-Datei mit, die Ihrem KI-Assistenten das Domänenmodell, die Interaktionsmuster und die typischen Arbeitsabläufe beibringt, damit er den Prüfstand für Sie bedient.
- Selbsterklärend: die Instanz liefert ihre Skill-Datei unter /api/skill.md aus. Verweisen Sie Claude Code oder ein anderes agentisches Tool darauf und der Agent lernt Domänenmodell und Workflows an Ort und Stelle
- Token-effizient von Haus aus: serverseitige Limits, Zeitfilter, Aktions-Ausschluss und schlanke Feldauswahl halten Antworten klein genug für Modelle mit begrenztem LLM-Kontextfenster
- Maschinenlesbare Fehlercodes und ein asynchrones Kommando-Muster, das Agenten deterministisch abfragen können
- Auch die OpenAPI-Spezifikation wird von der Instanz ausgeliefert, sodass Agenten jeden Endpunkt zur Laufzeit entdecken können
I have an EVSExplorer instance at bench-pi:8081. Fetch the skill.md from http://bench-pi:8081/api/skill.md and tell me which devices are online.
I'll fetch that skill file from the local API.
Ran 1 shell command
Now I understand the API. Let me query the charge points endpoint filtered for connection status.
Ran 1 shell command
Of the 7 registered charge points, only one is currently online: – MyBox — connected, state: Idle The other 6 are offline (disconnected), among them: – CBOX 01 (Idle) – CBOX 02 (Charging — likely stale, since it's disconnected)
✳ Cooked for 15s
When was CBOX 01 last connected?
Ran 1 shell command
CBOX 01 was last connected on 2026-07-16 at 12:14 UTC, then disconnected at 06:32 UTC the next day (reason: no_status_rcvd, disconnect initiated remotely) — so it's been offline for about a day.
✳ Brewed for 7s
What's the configured MessageTimeout on that charge point?
Ran 1 shell command
messageTimeoutSeconds is 30 (the default) — that's the window the CSMS waits for a response to a CSMS-initiated request before it's classified late.
✳ Brewed for 6s
How long is MyBox connected?
Ran 2 shell commands
MyBox reconnected at 2026-07-18 13:57:51 UTC and has been connected for about 12 minutes (as of now, 14:09:56 UTC).
✳ Cooked for 12s
Reboot that charge point
Ran 1 shell command
Reset command sent. Checking the outcome.
Ran 1 shell command
The charge point accepted the Reset (Immediate) command — status Accepted, command completed. It should be rebooting now.
✳ Crunched for 31s
Check if it reconnected
Ran 1 shell command
Not yet — it disconnected (going_away, remote-initiated) at 14:11:02 UTC in response to the reset, but hasn't reconnected. It's currently rebooting. Want me to keep polling?
Aus einer echten Agenten-Session (Claude CLI) gegen eine Prüfstand-Instanz.
Holen Sie EVSExplorer auf Ihren Prüfstand
Erzählen Sie uns von Ihrem Setup und Ihren Testanforderungen. Wir zeigen Ihnen EVSExplorer live und bringen Sie innerhalb weniger Tage an den Start.
Kontaktieren Sie uns
Sprechen Sie mit uns über Ihre OCPP-Testanforderungen und erfahren Sie, wie EVSExplorer in Ihren Workflow passt.
Kontakt aufnehmenExpertenunterstützung
Technische Beratung von OCPP-Spezialisten
Schnelle Einrichtung
Testen Sie Ihre Ladepunkte innerhalb weniger Stunden
Individuelle Lösungen
Maßgeschneiderte Implementierungen für Ihre Anforderungen