EV-Ladegerät APIs
Ein API in einem Ladenetzwerk hat nicht die gleiche Form wie die meisten APIs, da sich am anderen Ende Hardware auf einem Parkplatz befindet, die möglicherweise offline, mitten in der Sitzung oder physisch von jemandem besetzt ist, der nicht Ihr Benutzer ist. Die interessanten Designfragen drehen sich um diese Lücke.
Auf dieser Seite wird erläutert, was ein aufladender API offenlegt, warum Lese- und Steuerungsrechte unterschiedlich autorisiert sind, welche Echtzeitoptionen und wann jeweils richtig sind, Umfang und Ratenbeschränkungen und was bewusst nicht offengelegt wird.
EntwicklerzugriffFür Ein Entwickler oder Produktbesitzer integriert das Laden in eine Anwendung, die seine eigenen Benutzer verwenden werden.
Was wird freigelegt
Wischen, um zu vergleichen
| Ressource | Typische Verwendung |
|---|---|
| Ladegeräte und Anschlüsse | Entdeckung, Status, Fähigkeit, Standort |
| Verfügbarkeit | Ob eine Bucht jetzt genutzt werden kann |
| Sitzungen | Start, Stopp, aktueller Zustand, Verlauf |
| Tarife | Was kostet eine Sitzung vor Beginn? |
| Benutzer und Autorisierung | Wer darf zu welchen Konditionen Gebühren erheben? |
| Telemetrie | Zählerwerte und Status während einer Sitzung |
| Befehle | Fernstart, Stopp, Entsperren, Zurücksetzen |
| Störungen und Ereignisse | Was ist wann schief gelaufen? |
Lesen und Steuern sind unterschiedliche Probleme
Der Lesestatus ist ein normales API-Problem. Das Ausgeben eines Befehls ist nicht der Fall, da der Befehl an physische Geräte weitergeleitet wird, die möglicherweise nicht zuhören, und die Antwort, die Sie erhalten, sich eher auf die Anfrage als auf das Ergebnis bezieht.
- Ein erfolgreicher Fernstart bedeutet, dass der Befehl angenommen wurde und nicht, dass ein Auto aufgeladen wird. Das Ergebnis kommt später als Zustandsänderung
- Das Ladegerät ist möglicherweise offline. In diesem Fall muss der Befehl in der Warteschlange stehen, abgelehnt oder abgelaufen sein, und Ihre Anwendung muss wissen, welcher Befehl vorliegt
- Die physische Welt kann Ihnen widersprechen: Kein Fahrzeug angeschlossen, der Laderaum ist von einem Auto belegt, das nicht lädt, der Stecker ist nicht eingerastet
- Befehle müssen idempotent sein, da ein Client, der keine Antwort gesehen hat, es erneut versucht
Daher werden Steuervorgänge getrennt von Lesevorgängen autorisiert, und eine Integration sollte so konzipiert sein, dass sie Ergebnisse beobachtet, anstatt Bestätigungen zu vertrauen.
Echtzeit-Updates erhalten
- 1
Webhooks
Die Plattform postet Veranstaltungen für Sie. Effizient und die richtige Voreinstellung. Erfordert, dass Sie erreichbar sind, schnell reagieren und mit Duplikaten und Lieferungen außerhalb der Reihenfolge umgehen können.
- 2
Streaming
Eine dauerhafte Verbindung für kontinuierliche Telemetrie. Geeignet für ein Live-Dashboard, für die meisten Anwendungen unnötig und macht Ihren Client zustandsbehaftet.
- 3
Umfrage
Einfach, funktioniert immer und lässt sich schlecht skalieren. Gut für eine Handvoll Ladegeräte und falsch für ein Netzwerk. Außerdem führt es zu veralteter Verfügbarkeit, was den Fehler darstellt, den Benutzer bemerken.
Die meisten Integrationen enden mit Webhooks für Ereignisse und einer engen Umfrage für die spezifischen Dinge, die niemals veraltet sein dürfen, was in der Praxis die Verfügbarkeit ist.
Authentifizierung und Scoping
- Anmeldeinformationen beziehen sich auf eine Reihe von Ladegeräten oder Standorten, nicht auf das gesamte Netzwerk, sodass eine Partnerintegration nicht über den eigenen Bereich hinausgehen kann
- Lesen und Steuern sind getrennt, sodass eine Analyseintegration keine Sitzungen starten kann
- Anmeldeinformationen pro Integration statt gemeinsamer Anmeldeinformationen, sodass der Zugriff widerrufen werden kann, ohne dass alles andere kaputt geht
- Benutzerkontext, in dem ein Endbenutzer handelt, sodass eine Aktion einer Person und nicht einer Anwendung zuzuordnen ist
- Ein Prüfpfad der Befehle, der nach einem Vorfall von Bedeutung ist
Ratenbegrenzungen und gutes Verhalten im Maßstab
Der Fehlermodus ist normalerweise nicht, dass ein Kunde missbräuchlich ist. Es handelt sich um hundert gut erzogene Clients, die alle innerhalb derselben Minutengrenze abfragen, oder um eine Flotte von Ladegeräten, die nach einem regionalen Ausfall gleichzeitig die Verbindung wiederherstellen und bei der jede Integration gleichzeitig reagiert.
- Machen Sie bei einer Ablehnung einen Rückzieher, anstatt es sofort noch einmal zu versuchen, was aus einer arbeitsreichen Zeit einen Ausfall macht
- Jittern Sie geplante Anfragen, anstatt sie auf die Minute abzustimmen
- Bevorzugen Sie Ereignisse gegenüber Abfragen, sofern die Daten dies zulassen
- Zwischenspeichern, was sich nicht ändert, nämlich die meisten Metadaten des Ladegeräts
Was bewusst nicht offengelegt wird
Manche Dinge werden absichtlich zurückgehalten, und das Wissen, was ein Integrationsdesign rettet, das nicht funktionieren kann.
- Alles, was es einem API-Anrufer ermöglichen würde, das Sicherheitsverhalten zu beeinflussen. Die Reihenfolge und der Schutz der Schütze sind konstruktionsbedingt nicht adressierbar
- Persönliche Rohdaten, die über das hinausgehen, was der Umfang der Integration rechtfertigt
- Direkter Protokollzugriff auf das Ladegerät, der den eigenen Status und die Autorisierung der Plattform umgehen würde
- Offensichtlich sind es die Daten anderer Mandanten zu einer gemeinsamen Bereitstellung, die eher bestätigt als angenommen werden sollten
Auf Ihren eigenen Standort angewendet?
EntwicklerzugriffTechnisch geprüft von Deepu Joy, Director of Products and Delivery. Zuletzt geprüft 2026-09-10.
Häufig gestellte Fragen
Bedeutet ein erfolgreicher Fernstart, dass das Auto geladen wird?
Nein. Das bedeutet, dass der Befehl angenommen wurde. Das Ergebnis kommt später als Zustandsänderung, und Ihre Integration sollte Ergebnisse beobachten und nicht auf Bestätigungen vertrauen.
Webhooks oder Umfragen?
Webhooks für Ereignisse, mit einer engen Umfrage für alles, was niemals veraltet sein darf, was in der Praxis die Verfügbarkeit ist. Wenn alles abgefragt wird, lässt es sich schlecht skalieren und erzeugt genau die Veraltung, die Benutzer bemerken.
Können wir nur auf unsere eigenen Websites zugreifen?
So sollte der Umfang sein. Anmeldeinformationen sollten einen definierten Bereich abdecken, wobei Lese- und Kontrollzugriff getrennt und pro Integration statt gemeinsam genutzt werden sollten.
Können wir direkt über OCPP mit dem Ladegerät kommunizieren?
Nein. Dadurch werden der Status und die Autorisierung der Plattform umgangen, und zwei Systeme, die ein Ladegerät steuern, sind eher ein Fehlermodus als eine Funktion.
Was passiert, wenn das Ladegerät offline ist, wenn wir einen Befehl senden?
Abhängig vom Befehl befindet er sich in der Warteschlange, wird abgelehnt oder ist abgelaufen. Ihre Integration muss wissen, welcher Befehl vorliegt. Ein Befehl, der stillschweigend verschwindet, ist schlimmer als einer, der fehlschlägt.
Auf ein Ladenetzwerk aufbauen?
Teilen Sie uns mit, was Ihre Anwendung leisten muss. Durch die Aufteilung von Lesen und Steuern wird das Design normalerweise in einem Gespräch festgelegt.
Entwicklerzugriff