SunSpec für PV-Komponenten: Datenmodelle und Interoperabilität einordnen
09.10.2026
SunSpec-Datenmodelle schaffen ein gemeinsames Raster für die Kommunikation mit PV- und Energiesystem-Komponenten. Der Überblick erklärt den Aufbau am Wechselrichterbeispiel und zeigt, warum ein gemeinsames Modell allein noch keine reibungslose Integration garantiert.
Ein gemeinsames Vokabular statt Herstellerregister
PV-Anlagen bestehen selten nur aus einem Wechselrichter. Zähler, Speicher und weitere Komponenten liefern Messwerte oder nehmen Sollwerte entgegen. Ohne ein gemeinsames Datenmodell muss eine übergeordnete Software für jedes Fabrikat und oft sogar für jede Gerätefamilie eigene Registerzuordnungen und Bedeutungen pflegen. SunSpec setzt hier an: Informationsmodelle legen fest, wie bestimmte Datenpunkte beschrieben und gruppiert werden. Der Nutzen ist nicht, dass alle Geräte identisch wären, sondern dass eine Anwendung für unterstützte Modelle ein wiedererkennbares Vokabular verwenden kann. Die Alliance veröffentlicht Modellbeschreibungen unter anderem als JSON und SMDX; pySunSpec2 kann diese Definitionen verwenden. [SunSpec Models und pySunSpec2](https://github.com/sunspec/pysunspec2)
Was steckt in einem Datenmodell?
Ein Datenmodell ist weder das Gerät selbst noch die Verbindung zu ihm. Es ist eine strukturierte Beschreibung der Datenpunkte: etwa Bezeichner, Datentyp, Einheiten, Zugriffseigenschaften und gegebenenfalls Skalierungsinformationen. Für die Zuordnung sind Identifikator und Länge bedeutsam: Die dokumentierte pySunSpec2-Erkennung nutzt beide Angaben, um Modellblöcke im Gerät zu finden. In der Praxis bilden Transport und Modell also zwei verschiedene Ebenen: Modbus liefert den Zugriff auf Register, das Informationsmodell hilft der Software, deren Inhalt einzuordnen. Diese Trennung erleichtert es, dieselbe Anwendungslogik für verschiedene unterstützte Geräte zu schreiben. [pySunSpec2](https://github.com/sunspec/pysunspec2)
Wechselrichter-Beispiel: Messung ist nicht gleich Steuerung
Das offizielle Modell 123 veranschaulicht, dass ein Modell neben Status- oder Messdaten auch steuerbare Punkte umfassen kann. Es ist als „Immediate Inverter Controls“ beschrieben. Ein Eintrag dient dazu, die Wirkleistung auf ein vorgegebenes Niveau zu setzen; ergänzende Punkte beschreiben ein Zeitfenster für die Änderung und die Rampenzeit vom bisherigen zum neuen Sollwert. Für Betreiber ist diese Unterscheidung wichtig: Ein Monitoring-Dashboard kann Werte lediglich lesen, während ein Energiemanagementsystem gegebenenfalls auch Sollwerte schreiben muss. Vor einer Steuerintegration sind deshalb Lese- und Schreibrechte, erwartete Einheiten und das Verhalten bei Zeitüberschreitungen anhand des jeweiligen Geräts und seiner Spezifikation zu prüfen. [Modell 123, SunSpec Models](https://github.com/sunspec/models/blob/master/json/model_123.json)
So lässt sich Interoperabilität praktisch einordnen
Ein hypothetischer Integrationsablauf macht den Gewinn greifbar: Ein Gateway liest die verfügbaren SunSpec-Modelle eines Wechselrichters ein, ordnet die Datenpunkte anhand ihrer Definition zu und übergibt sie an ein Anlagenmonitoring. Unterstützt auch die zweite Komponente dasselbe Modell, kann ein Teil der Zuordnungslogik wiederverwendet werden. Für die Kommunikation gibt es Bibliothekszugänge über Modbus RTU und Modbus TCP. Das spart jedoch nicht jede Integrationsarbeit: Netzparameter, Gerätefreigaben, unterstützte Modellversionen und konkrete Gerätekonfiguration bleiben zu prüfen. Standardisierung macht Schnittstellen vergleichbarer; sie ersetzt nicht die Inbetriebnahme und Abnahme im konkreten System. [pySunSpec](https://github.com/sunspec/pysunspec) und [pySunSpec2](https://github.com/sunspec/pysunspec2)
Grenzen: Modell vorhanden heißt nicht vollständig verstanden
Eine wichtige Einschränkung zeigt bereits die Bibliotheksdokumentation: Wenn bei der Erkennung eine Modellkennung ohne verfügbare Definition auftaucht, kann die Software den Inhalt nicht interpretieren. Ein Gerät kann also Daten bereitstellen, ohne dass die eingesetzte Anwendung sie bereits sinnvoll abbildet. Ebenso sollte man ein gemeinsames Modell nicht mit einer Garantie verwechseln, dass jede Option eines konkreten Geräts verfügbar oder freigeschaltet ist. Das sind unterschiedliche Fragen: Welche Modellbeschreibung existiert, welche Punkte setzt das Gerät um, und welche davon sind in der Installation erreichbar? Ein Abgleich zwischen Herstellerdokumentation, Modellkennung und tatsächlichem Lese- beziehungsweise Schreibverhalten schließt diese Lücke. [pySunSpec2](https://github.com/sunspec/pysunspec2)
Prüfliste für Planung und Betrieb
Vor der Auswahl oder Anbindung lohnt ein kurzer, konkreter Abgleich: Welcher Kommunikationsweg ist vorgesehen? Welche Modelle und Modellversionen meldet das Gerät? Sind die relevanten Punkte nur lesbar oder auch schreibbar? Stimmen Einheiten, Skalierung und Zeitverhalten mit der übergeordneten Anwendung überein? Bei steuerbaren Funktionen sollte zusätzlich festgelegt werden, wer Sollwerte setzen darf und wie die Anlage bei Kommunikationsausfall reagiert. Die SunSpec-Definition liefert ein standardisiertes Raster, auf dem diese Prüfung aufsetzen kann; ihre Ergebnisse müssen für die tatsächliche Geräte- und Anlagenkonfiguration verifiziert werden. So wird Interoperabilität nicht als Aufdruck missverstanden, sondern als überprüfbare Eigenschaft der gesamten Kette aus Gerät, Modell, Kommunikation und Anwendung.