Cloud-API oder lokales Gateway für Energiestandorte?

Ein Wechselrichter, eine Ladesäule oder eine Wärmepumpe, die bereits Daten an ihren Hersteller sendet, bietet zwei Wege zu diesen Daten: Sie können die Hersteller-API abfragen oder das Gerät vor Ort über Modbus oder eine andere lokale Schnittstelle auslesen. Unterzähler daneben haben meist keine Cloud-Verbindung. Für sie ist ein lokales Gateway der einzige Weg. Entscheiden Sie für jedes Gerät einzeln, nicht pauschal für den gesamten Standort.

Manche Drittanbieter-APIs bündeln die Clouds mehrerer Hersteller. Das spart Integrationsarbeit, schaltet aber einen zweiten Anbieter mit eigenem Intervall und eigener Abfragegrenze zwischen Sie und die Daten.

Die beiden Wege im Vergleich

Wann eine Cloud-API passt

Eine Cloud-API ist der schnellere Weg, wenn die Geräte bereits online sind und nur Berichte gebraucht werden. Das Abfragekontingent bestimmt dann, wie aktuell die Daten sein können. Die Enlighten API v4 von Enphase erlaubt im kostenlosen Watt-Tarif 10 Aufrufe pro Minute und 1.000 pro Monat, im Kilowatt-Tarif 50.000 und im Megawatt-Tarif 300.000 pro Monat (Enphase-Entwicklertarife). Eine Abfrage je Anlage alle 15 Minuten ergibt 96 Aufrufe täglich, also etwa 2.900 monatlich. Schon eine Anlage übersteigt damit den kostenlosen Tarif. Vierzig Anlagen benötigen etwa 117.000 monatliche Aufrufe und überschreiten den Kilowatt-Tarif.

Dieselben 40 Anlagen benötigen dagegen nur 40 Aufrufe täglich, wenn die Integration nachts von einer Schnittstelle sämtliche Intervalle des Vortags in einem Aufruf erhält. Ein monatlicher Portfoliobericht funktioniert damit gut. Ein Dashboard, das die letzte Stunde zeigen muss, nicht.

Prüfen Sie Folgendes mit einem echten Konto und einem echten Gerät, nicht nur mit Beispielen aus der Dokumentation:

• Welches Intervall liefert die API für Ihre Geräte tatsächlich, und welches Kontingent gilt für Ihren Tarif?
• Wie weit reicht die Historie zurück, und erscheinen verpasste Intervalle später?
• Ist jeder Zeitstempel Messzeit oder Uploadzeit, und welche Zeitzone gilt?
• Wie zeigt die API ein offline gegangenes Gerät: als Lücke, wiederholten letzten Wert oder null?
• Wem gehört das Konto, und wie wird der Zugriff bei Verkauf des Standorts oder der Anlage übertragen?
• Wie früh kündigt der Anbieter die Abschaltung einer Schnittstelle an?

Der letzte Punkt ist ein reales Risiko. Am 20. Februar 2026 kündigte Enphase an, neun Endpunkte am 16. März 2026 abzuschalten, 24 Tage später. Seit diesem Datum antworten Aufrufe dieser Endpunkte mit HTTP 401 (Enphase-Hinweis zur Abschaltung).

Wann ein lokales Gateway passt

Ein lokales Gateway passt, wenn Geräte lokale Schnittstellen, aber keine Cloud-Verbindung haben. Ein Beispiel ist ein Standort mit 20 Modbus-RTU-Unterzählern an einem RS-485-Bus, einem Impulsausgang am Gaszähler und einer Gebäudeleittechnik über BACnet/IP. Keines dieser Geräte sendet Daten an einen Cloud-Dienst. Das Gateway liest sie in einem von Ihnen gewählten Intervall, speichert die Historie vor Ort und führt Automatisierungen ohne Umweg über einen Server aus.

Wischen Sie, um dem System zu folgen

Wenn Sie ein Gerät selbst auslesen, tragen Sie auch die Verantwortung für die Zuordnung der Daten. Häufige Fehler liegen auf Registerebene: Bei einem 32-Bit-Wert werden zwei Wörter in falscher Reihenfolge gelesen, ein Skalierungsfaktor wird zweimal angewendet oder ein Energieregister liefert Wh, obwohl die Registertabelle kWh angibt. Jeder Fehler erzeugt eine plausible, aber falsche Zahl. Der Leitfaden zu Modbus-Registertabellen zeigt, wie Sie jeden Datenpunkt mit dem Display des Zählers abgleichen.

Auch das Gateway ist Betriebsmittel, das jemand verantworten muss. Legen Sie bei der Inbetriebnahme eine Person für Softwareaktualisierungen, Backups und Firewallregeln fest. Ein Gateway ohne Verantwortliche wird nicht aktualisiert.

Zeitstempel und Leistungsintervalle

Ein Leistungspreis für 15-Minuten-Intervalle wird aus der Energie jedes Intervalls berechnet. Deshalb entscheidet der Zeitstempel, welchem Intervall ein Messwert zugeordnet wird. Angenommen, ein Gerät puffert während eines dreistündigen Ausfalls bei durchschnittlich 400 kW und lädt bei Wiederverbindung um 14:07 Uhr 1.200 kWh hoch. Wenn die API oder Plattform die Werte mit der Uploadzeit versieht, fallen alle 1.200 kWh in das Intervall von 14:00 bis 14:15 Uhr. Dieses Intervall zeigt dann 4.800 kW Leistung, das Zwölffache des tatsächlichen Werts.

Abhilfe schafft die durchgängige Bewahrung der Messzeit vom Gerät bis zur Plattform. Auch eine lokale Abfrage hat eine kleinere Variante dieses Problems. Das Gateway versieht einen Modbus-Wert bei der Abfrage mit einem Zeitstempel. Ein Zählerregister, das sich nur einmal pro Minute aktualisiert, kann daher beim Lesen fast eine Minute alt sein. Der Leitfaden zu Mess- und Ankunftszeit erklärt, wie Sie die Bedeutung der Zeitfelder festlegen. Der Intervallleistungsrechner zeigt, wie ein falsch zugeordnetes Intervall den verrechneten Höchstwert verändert.

Hybride Architekturen

Ein Standort nutzt häufig beide Wege. Betrachten wir eine PV-Anlage mit 250 kW, deren Wechselrichter an das Herstellerportal melden, sowie einen Hauptbezugszähler und sechs Modbus-Unterzähler. Einer dieser Unterzähler sitzt am PV-Abgang. Zwei Regeln halten die Architektur konsistent.

Erste Regel: eine Quelle je Datenpunkt. Für das Viertelstundenintervall bis 13:00 Uhr misst der Zähler am PV-Abgang 182 kW; die Wechselrichter-API meldet 185 kW. Das sind zwei Messungen desselben Energieflusses. Werden beide zur Standorterzeugung addiert, meldet der Bericht 367 kW aus einer 250-kW-Anlage. Nutzen Sie den Abgangszähler, dessen Genauigkeitsklasse Sie kennen. Bewahren Sie den API-Wert für die Diagnose des Wechselrichters auf. Ersetzen Sie einen fehlenden Zählerwert nur dann durch den API-Wert, wenn Sie ihn als Ersatzwert kennzeichnen.

Zweite Regel: ein Verantwortlicher je beschreibbarem Datenpunkt. Eine Flexibilitätsplattform steuert die Standortbatterie über die Hersteller-API und setzt für ein Ladeereignis die Entladeleistung auf 0 kW. Gleichzeitig schreibt eine lokale Regel zur Begrenzung von Lastspitzen 150 kW Entladeleistung, sobald der Netzbezug über die Schwelle steigt. Beide Schnittstellen melden Erfolg. Der Sollwert ändert sich bei jedem Schreibzugriff; seine Zeitreihe zeigt ein Sägezahnmuster. Übertragen Sie die Verantwortung für den Sollwert einem System. Das andere liest ihn oder bittet das verantwortliche System um eine Änderung.

Der Leitfaden zur Datenqualität erklärt, wie Ersatzwerte und veraltete Daten gekennzeichnet werden.

Sicherheit und Zugriff

Die Vertrauensgrenze liegt auf den beiden Wegen an unterschiedlichen Stellen. Bei einer Cloud-API ist der Zugangsschlüssel das kritische Gut. Enlighten API v4 nutzt OAuth 2.0. Der Systeminhaber genehmigt die Anwendung; das Zugriffstoken gilt einen Tag, das Refresh-Token einen Monat (Enphase-Schnelleinstieg). Erneuert die Integration den Zugriff nicht innerhalb dieses Monats, ist eine neue Freigabe des Inhabers erforderlich. Halten Sie fest, unter wessen Konto jede Anlage registriert ist. Ein Standortverkauf oder Installateurwechsel kann den Zugang entziehen.

Bei einem Gateway ist das Gerät in Ihrem OT-Netz das kritische Gut. Es braucht keinen zum Internet geöffneten Eingangsport, weil es selbst die Verbindung zur Plattform herstellt. NIST SP 800-82 Rev. 3, Abschnitt 5.2.3.1, empfiehlt die Segmentierung von OT und IT, Verbindungen nur zwischen benachbarten Zonen und ebenso strenge Regeln für ausgehenden wie für eingehenden Verkehr. Für ein Gateway bedeutet dies eine Positivliste seiner tatsächlichen Ziele: Broker oder Endpunkt der Plattform, Zeitserver und Aktualisierungsdienst. Eine allgemeine Regel, die sämtlichen ausgehenden HTTPS-Verkehr erlaubt, ist keine Positivliste.

Einen Ausfall testen

Bevor Sie ein Portfolio auf einen der beiden Wege stützen, unterbrechen Sie unter einem vereinbarten Prüfplan die Internetverbindung an einem Pilotstandort. Trennen Sie den WAN-Anschluss, nicht die Stromversorgung des Gateways: Ein Stromausfall prüft einen anderen Fehlerfall. Lassen Sie die Verbindung mindestens zwei Stunden unterbrochen. Das umfasst acht 15-Minuten-Leistungsintervalle.

1. Dokumentieren Sie während des Ausfalls, was vor Ort weiterläuft: Erfassung, lokale Historie, Dashboards und Automatisierung.
2. Halten Sie fest, wie die Plattform den fehlenden Zeitraum zeigt: als Lücke, unverändert gehaltenen veralteten Wert oder Nullen. Nullen sind das schlechteste Ergebnis, weil sie wie echte Messungen aussehen.
3. Stellen Sie die Verbindung wieder her und zählen Sie die eintreffenden Werte. Fünfzig Datenpunkte im Minutenintervall ergeben über zwei Stunden 6.000 Messwerte. Weniger deutet auf Verluste hin. Mehr deutet auf Duplikate hin, die die Plattform entfernen muss. MQTT QoS 1 garantiert mindestens einmalige Zustellung (MQTT 5.0, Abschnitt 4.3.2). Duplikate nach einer Wiederverbindung sind daher normales Verhalten, kein Fehler.
4. Prüfen Sie, ob nachgelieferte Werte ihre ursprünglichen Messzeiten behalten und kein Leistungsintervall eine Spitze wie im obigen Beispiel zeigt.
5. Prüfen Sie bei einer API, ob und wie schnell der Anbieter die Lücke schließt und ob Ihre Integration den fehlenden Zeitraum erneut anfragt.

Der Test ist bestanden, wenn die Anzahl stimmt, jeder Messwert seinen ursprünglichen Zeitstempel behält und die Plattform den Ausfall nie als Nullen dargestellt hat. Die Inbetriebnahme-Checkliste bietet eine Aufzeichnung für den Test. Der Leitfaden zu Store and Forward zeigt, wie Sie lokalen Speicher für den längsten geplanten Ausfall bemessen.

Berichte und Steuerung sind unterschiedliche Aufgaben

Eine Berichtsintegration braucht regelmäßige Lesezugriffe. Eine Steuerungsintegration braucht einen Befehlsablauf mit Gültigkeitsende, lokalen Grenzen, gemessener Rückmeldung und einem Fallback bei Verbindungsausfall. Eine Cloud-API kann diesen Fallback nicht bereitstellen, weil die ausgefallene Verbindung ihr Weg in die Cloud ist.

Eine erfolgreiche API-Antwort besagt, dass der Anbieter den Befehl angenommen hat. Eine Modbus-Schreibantwort besagt, dass ein Register geschrieben wurde. Keines von beiden belegt eine Aktion der Anlage. Der Leitfaden zur Verifikation von BESS-Befehlen zeigt, wie Sie die Reaktion anhand von Messungen nachweisen. Die Fehlermatrix für lokale Verriegelungen hilft festzulegen, was der Standort bei Ausfall des Befehlspfads tut.

Edge auf dem Gateway

Edge läuft vor Ort auf dem ZGW-20 Gateway. Es führt EpiSensor-Funkgeräte, Zigbee- und LoRaWAN-Geräte von Drittanbietern, Modbus-TCP- und -RTU-Geräte sowie BACnet/IP-Controller in einem Geräteverzeichnis zusammen. Es speichert die Historie lokal und betreibt Dashboards und Automatisierungen ohne Internetverbindung. Daten sendet es über MQTT oder HTTPS oder als JSON- beziehungsweise CSV-Dateien per FTPS weiter. Ein EpiSensor-Cloud-Dienst liegt nicht auf diesem Pfad. Das Gateway benötigt im Leerlauf 5 W und höchstens 15 W.

Im Ausfalltest legt Edge fehlgeschlagene Zustellungen in einer Warteschlange auf der Festplatte ab. Für die von Edge verwalteten Ziele prüft es die Warteschlange jede Minute und sendet erneut, sobald das Ziel wieder erreichbar ist. Die nachgesendeten Werte behalten ihre ursprünglichen Zeitstempel und lösen die lokale Automatisierung nicht noch einmal aus. Zwei Grenzen beeinflussen die Anzahl in Schritt 3: Ein Batch, der beim Stromausfall des Gateways noch im Arbeitsspeicher liegt, kann verloren gehen. Ein Batch, den der Empfänger gespeichert hat, bevor Edge den Erfolg dokumentierte, kann doppelt eintreffen.