Data Scraper

Der Data Scraper ist die zentrale Datenerfassungs-Engine innerhalb des Mirox-Agent, die aktiv Echtzeitinformationen von allen überwachten Anlagenkomponenten Ihres Parks abruft. Er verbindet sich mit Ihren Loggern, Wechselrichtern, Zählern und Batteriesystemen über eine Bibliothek herstellerspezifischer Adapter, normalisiert alles in ein einheitliches Metrik-Vokabular und leitet das Ergebnis an den Rest der Plattform weiter — während er einen wachsenden Satz von Edge-Analysen (Performance-Ratio, Curtailment-Tracking, Clear-Sky-Baselines, Prognosen und Netzwerküberwachung) direkt an der Anlage ausführt.

Zweck und Rolle

Der Data Scraper verfolgt einen einzigen, fokussierten Zweck: aktiv Rohmesswerte von Anlagenkomponenten erfassen und zur Verarbeitung weiterleiten. Er fungiert als Brücke zwischen unterschiedlichen Geräten verschiedener Hersteller und der einheitlichen Mirox-Plattform und übersetzt proprietäre Datenformate in standardisierte Metriken.

Kernverantwortlichkeiten:

• Verbindung zu Datenloggern und Überwachungsgeräten über herstellerspezifische Adapter
• Abruf von Rohmesswerten nach konfigurierbaren Zeitplänen
• Umwandlung herstellerspezifischer Daten in ein standardisiertes Metrikformat
• Automatische Erkennung und Verfolgung von Anlagenkomponenten
• Überwachung der Komponentenaktivität und des Betriebsstatus
• Ausführung von Edge-Analysen (erwartete Leistung, Performance-Ratio, Curtailment, Clear-Sky und Prognosen)
• Inspektion des lokalen Netzwerks der Anlage und Auditierung von Gerätezugriffen
• Weiterleitung von Metriken an die Zeitreihendatenbank und den Digital-Twin-Dienst
• Meldung von Komponentengesundheit und Betriebsstatus an die IoT Cloud

Diese Trennung der Zuständigkeiten hält den Data Scraper schlank, fokussiert und unabhängig deploybar.

Architekturüberblick

Der Data Scraper arbeitet als asynchroner, ereignisgesteuerter Dienst, in dem mehrere Datenerfassungs-Tasks gleichzeitig laufen:

Zentrale Architekturprinzipien:

• Zustandslos: Kein persistenter Zustand zwischen Neustarts
• Adapterbasiert: Ein dedizierter, herstellerspezifischer Adapter spricht das Protokoll jedes Geräts
• Selbstheilend: Automatische Fehlerbehebung mit exponentiellem Backoff
• Nebenläufig: Jede Datenquelle wird unabhängig erfasst
• Edge-deployt: Läuft an oder nahe der Anlage, nahe an den Geräten, die er ausliest

Das Adaptersystem

Konzept

Ein Adapter ist ein herstellerspezifisches Konnektormodul, das weiß, wie man mit einer bestimmten Gerätefamilie kommuniziert. Jeder Adapter wird handgebaut und gegen die eigene Web-, API- oder Datenbankschnittstelle des jeweiligen Geräts per Reverse Engineering entwickelt — es gibt keine einzelne „Spricht-jedes-Protokoll"-Engine. Das Adaptersystem ist der zentrale Erweiterungsmechanismus: Die Unterstützung eines neuen Geräts bedeutet, einen neuen Adapter hinzuzufügen, was wir auf Anfrage tun (siehe unten).

Jeder Adapter ist ein in sich geschlossenes Modul, das verantwortlich ist für:

1. Verbindungsmanagement – Aufbau und Aufrechterhaltung der Kommunikation
2. Datenabruf – Abruf von Messwerten unter Verwendung des passenden Protokolls
3. Datentransformation – Umwandlung in das standardisierte Metrikformat

Alle Adapter erben von einer Basisklasse, die Gesundheitsüberwachung, automatische Wiederholungslogik, exponentiellen Backoff bei Fehlern, Metrikvalidierung und Statusmeldungen an die IoT-Plattform bereitstellt.

Gesundheitsmanagement

Jeder Adapter implementiert einen automatischen Zustandsautomaten:

• INITIALIZING: Hochfahren und Aufbau der ersten Verbindungen
• HEALTHY: Normalbetrieb mit erfolgreichen Datenerfassungen
• UNHEALTHY: Fehler treten auf, aber der Betrieb wird fortgesetzt
• RECONNECTING: Durchführung von Wiederherstellungsmaßnahmen nach wiederholten Fehlern
• FROZEN: Das Gerät liefert veraltete Daten — dieselben Werte wiederholen sich, oder innerhalb des erwarteten Zeitfensters ist kein neuer Messwert eingetroffen
• PAUSED: Vorübergehend per Benutzerbefehl pausiert; setzt automatisch fort, wenn die Pause abläuft

Das System wechselt automatisch zwischen den Zuständen, meldet den Status an die Plattform und versucht die Wiederherstellung ohne manuellen Eingriff. Der Zustand FROZEN ermöglicht es der Plattform, einen tatsächlich ausgefallenen Logger von einem zu unterscheiden, der lediglich einen festgefahrenen Wert wiederholt.

Unterstützte Geräte

Der Data Scraper wird mit rund fünfzehn herstellerspezifischen Adaptern ausgeliefert, von denen jeder für eine bestimmte Gerätefamilie gebaut wurde. Die folgende Liste spiegelt wider, was heute unterstützt wird, und wächst, sobald ein neues Gerät integriert wird.

Erstellung neuer Adapter

Es können neue Adapter entwickelt werden, um zusätzliche Geräte oder Protokolle zu unterstützen. Das modulare Design und die Funktionalität der Basisklasse verkürzen die Entwicklungszeit erheblich.

Kompatibilität mit Altgeräten: Wir können Adapter für ältere Geräte erstellen, die nie speziell für den Datenexport ausgelegt waren. Solange das Gerät seine Daten auf irgendeine zugängliche Weise bereitstellt — sei es über eine REST-API, eine Weboberfläche, eine Datenbank, ein Dateisystem oder einen beliebigen anderen Mechanismus — können wir diese Daten extrahieren und in die Plattform integrieren.

Uneingeschränkte Datenerfassung: Unsere Adapter sind nicht auf die vordefinierten Datenexportformate beschränkt, die Datenlogger typischerweise bereitstellen. Wir können alle Daten erfassen, die das Gerät verfügbar macht, und gehen damit über den Standardsatz an Metriken hinaus, den der Logger eines Herstellers möglicherweise offenlegt. Verfügt ein Gerät über zusätzliche Diagnoseinformationen, erweiterte Parameter oder verborgene Datenpunkte, die über seine Schnittstelle zugänglich sind, können wir diese abrufen und standardisieren.

Onboarding über die Plattform

Für eine Teilmenge von Geräten können Sie einen Logger über die Plattform in Betrieb nehmen, ohne von Hand eine Konfiguration zu schreiben. Ein Onboarding-Assistent fordert den Agent auf, eine Probe-Verbindung zum Gerät herzustellen, und streamt die Live-Ergebnisse der Prüfung an Sie zurück, sodass Sie sofort sehen, ob die Verbindung funktioniert, bevor Sie sie festlegen. Es gibt zwei Varianten:

• Zero-Config-Onboarding – der Adapter besitzt bereits den vollständigen Messwertsatz des Geräts, sodass der Assistent nur eine Nur-Lese-Live-Vorschau zeigt und Sie speichern. Heute verfügbar für Janitza-Zähler, Huawei SmartLogger und Phoenix-Contact-Controller. Janitza benötigt dabei überhaupt keine Anmeldedaten.
• Interaktive Zuordnung für generische Logger – manche Logger stellen beliebige Rohwerte bereit, die die Plattform nicht von sich aus interpretieren kann. Für diese fordert der Assistent den Agent auf, jeden vom Gerät bereitgestellten Rohwert aufzuzählen (Gruppe, Name, Einheit, Live-Stichprobe), der Bediener ordnet jeden einer bekannten Metrik zu, und ein zuordnungsgesteuerter Probelauf zeigt vor dem Speichern eine Vorschau der genauen Metriken, die erzeugt würden. QReader ist der erste auf diese Weise unterstützte generische Logger.

Metrik-Standardisierung

Alle erfassten Daten werden in ein standardisiertes Metrikformat umgewandelt, das durch die Metrik-Taxonomie der Plattform definiert ist. Dies gewährleistet Konsistenz über alle Datenquellen hinweg und ermöglicht eine einheitliche nachgelagerte Verarbeitung.

Metrikstruktur

Jede Metrik folgt einer standardisierten Struktur, die mit modernen Zeitreihendatenbanken kompatibel ist:

Komponenten:

• Name: Standardisierter Metrik-Bezeichner aus einer vordefinierten Taxonomie
• Wert: Numerischer Messwert in SI-Basiseinheiten
• Labels: Schlüssel-Wert-Paare zur Komponentenidentifikation und -gruppierung
• Zeitstempel: Optionale Beibehaltung des ursprünglichen Gerätezeitstempels

Standard-Labels:

• Typ und Instanznummer des Quelladapters
• Menschenlesbare Namen
• Komponentenbezeichner (Wechselrichter-ID, Stringnummer usw.)
• Physischer Standort oder Gruppierungsinformationen

Einheitenkonventionen

Alle Metriken verwenden SI-Basiseinheiten, unabhängig davon, was das Gerät des Herstellers meldet:

• Leistung: Watt (W)
• Energie: Wattstunden (Wh)
• Spannung: Volt (V)
• Stromstärke: Ampere (A)
• Temperatur: Celsius (°C)
• Einstrahlung: Watt pro Quadratmeter (W/m²)

Adapter konvertieren während der Transformationsphase automatisch von herstellerspezifischen Einheiten (kW, MWh usw.) in diese Standards.

Metrik-Kategorien

Die Plattform definiert 376 standardisierte Metriktypen, organisiert in 11 Familien:

Label-Erweiterungen (pro String, pro Phase, pro Wechselrichter usw.) vervielfachen diese in einer realen Anlage zu weit mehr einzelnen Zeitreihen. Die vollständige Metrik-Taxonomie und Definitionen finden Sie unter Metrik-Erfassung.

Datenerfassungsablauf

Polling-Strategien

Adapter unterstützen zwei Polling-Modi:

Intervallbasiert (Standard): Wird alle N Sekunden ausgeführt, nachdem die vorherige Erfassung abgeschlossen ist. Einfach und reaktionsfähig gegenüber variierenden Erfassungsdauern.

Statisch zeitbasiert: Wird in festen Intervallen ab Mitternacht mit optionalem Offset ausgeführt (z. B. um 00:01, 05:01, 10:01 bei 5-Minuten-Intervallen mit 1-Minuten-Offset). Nützlich zur Abstimmung mit externen Systemen.

Verarbeitungspipeline

Nach der Erfassung durchlaufen die Metriken mehrere Verarbeitungsstufen:

Metrikvorbereitung: Quell-Labels werden hinzugefügt, Zeitstempel angewandt und die Struktur validiert.

Filterung: Konfigurierte Filter können Werte verändern, Bereiche validieren oder Metriken anhand von Regeln überspringen.

Berechnungen: Automatisierte Kalkulatoren leiten zusätzliche Metriken ab:

• Solarstrahlungsleistung wird zu Einstrahlungsenergie integriert
• Stringspannung × Stromstärke wird zu Leistung berechnet
• Leistungswerte werden über die Zeit zu Energie integriert

Komponentenerkennung: Während die Metriken durchfließen, erkennt und identifiziert der Data Scraper automatisch Anlagenkomponenten. Dies ist eine entscheidende Funktion — da der Data Scraper die Schicht ist, die aktiv Daten erfasst, weiß er inhärent, welche Komponenten existieren und Daten liefern. Das System erkennt automatisch:

• Wechselrichter (aus Wechselrichter-Leistungsmetriken)
• String-Combiner-Boxen / GAKs (aus GAK-Metriken)
• Einzelne Strings (aus Stringspannungs-/-strommetriken)
• Einstrahlungssensoren (aus Strahlungsmetriken)
• Netzanschlusspunkte (aus Netzenergiemetriken)

Erkannte Komponenten werden zur Bestandsverwaltung mit der IoT-Plattform synchronisiert und erzeugen so ein in Echtzeit selbstpflegendes Anlagenregister ohne manuelle Konfiguration.

Produktionserkennung: Das System überwacht den Betriebszustand der Anlage:

• Erkennt anhand von Einstrahlung und Leistung, wann die Produktion beginnt
• Identifiziert unerwartete Abschaltungen während der Produktionszeiten
• Meldet Zustandsübergänge für die Alarmierung

Metrik-Gruppierung: Metriken werden nach Zeitreihe gebündelt, um die Performance des Datenbankeinfügens zu optimieren.

Datenexport

Verarbeitete Metriken werden an zwei Ziele weitergeleitet:

Zeitreihendatenbank: Metriken werden in Batches mit Ratenbegrenzung und Wiederholungslogik zur Langzeitspeicherung und historischen Abfrage übertragen.

Digital-Twin-Webhook: Ein separater Hintergrund-Task leitet kontinuierlich die neuesten Metrikwerte an den Digital-Twin-Dienst (ein völlig separater Microservice) zur Echtzeitanalyse weiter. Der Data Scraper hat keine Kenntnis davon, was der Digital Twin mit den Daten macht — er stellt lediglich die Metriken bereit. Informationen zur Digital-Twin-Verarbeitung finden Sie unter Digital Twin.

Zustandsloser Betrieb

Der Data Scraper ist so konzipiert, dass er vollständig zustandslos ist:

• Kein persistenter Speicher — der gesamte Zustand existiert nur im Arbeitsspeicher
• Kann ohne Datenverlust gestoppt und neu gestartet werden
• Mehrere Instanzen können unabhängig für verschiedene Parks laufen
• Jeder Polling-Zyklus ist unabhängig von vorherigen Zyklen
• Absturzsicher, ohne Risiko, persistenten Zustand zu beschädigen

Der einzige persistente Zustand existiert extern:

• Konfigurationsdateien (versionskontrolliert)
• Zeitreihendatenbank (externes System)
• IoT-Cloud-Komponentenregister (externes System)

Dieses Design sorgt für betriebliche Einfachheit, Zuverlässigkeit und einfache horizontale Skalierung.

Trennung der Zuständigkeiten

Der Data Scraper hat eine eng abgegrenzte, fokussierte Verantwortung, die eine klare Abgrenzung von anderen Plattformkomponenten ermöglicht:

Data Scraper:

• Erfasst Rohmesswerte von Anlagenkomponenten
• Wandelt Daten in das Standardformat um
• Erkennt und verfolgt Komponenten
• Überwacht den Aktivitätsstatus von Komponenten
• Leitet Metriken an andere Dienste weiter

Digital Twin: Validiert gegen physikalische Modelle und erkennt Anomalien und Verluste

Zeitreihendatenbank: Speichert historische Daten, stellt eine Abfrageschnittstelle bereit

IoT Cloud: Pflegt das Komponentenregister, verfolgt den Gerätestatus, verwaltet den Anlagenbestand

Diese Trennung ermöglicht die unabhängige Entwicklung, das Testen, die Bereitstellung und die Skalierung jeder Komponente, während jeder Dienst sich auf seine Kernkompetenz konzentriert.

Erweiterte Funktionen

Automatische Gesundheitsüberwachung

Jeder Adapter implementiert einen Zustandsautomaten, der die Betriebsgesundheit verfolgt, mit automatischer Meldung an die Plattform und Bereitstellung über die Metrik-API für die betriebliche Überwachung.

Automatische Komponentenerkennung

Die Position des Data Scrapers als Datenerfassungsschicht verschafft ihm einen einzigartigen Vorteil: Er weiß inhärent, welche Komponenten an einer Installation existieren, weil er direkt mit den von ihnen erzeugten Metriken interagiert. Während die Metriken durch das System fließen, werden Komponenten automatisch aus Metrik-Labels erkannt und bei der IoT-Plattform registriert.

Erkennungsprozess:

1. Metriken treffen mit identifizierenden Labels ein (Wechselrichter-ID, Stringnummer, Sensorstandort usw.)
2. Der Data Scraper extrahiert Komponenteninformationen aus diesen Labels
3. Neue Komponenten werden automatisch bei der IoT Cloud registriert
4. Komponenten-Metadaten (Typ, Bezeichner, Standort) werden synchronisiert
5. Die Plattform pflegt einen aktuellen Anlagenbestand ohne manuelle Eingabe

Dieser Selbsterkennungsmechanismus stellt sicher, dass die Plattform stets weiß, welche Anlagenkomponenten an der Installation existieren, wodurch der Bedarf an manueller Konfiguration entfällt und die Bereitstellungszeit reduziert wird.

Produktionszustandserkennung

Der Dienst überwacht den Betriebszustand der Anlage und erkennt Produktionsstarts, unerwartete Abschaltungen während der Produktionszeiten sowie Zustandsübergänge für Alarmierung und Analyse, wobei er nur dann meldet, wenn sich der Zustand tatsächlich ändert. Er achtet außerdem auf Überproduktion — Leistung oberhalb des Clear-Sky-Modells über einen anhaltenden Zeitraum —, was auf einen Logger hinweisen kann, der eingefrorene Werte liefert, und greift in diesem Fall auf das Clear-Sky-Modell zurück, damit der Datenstrom sinnvoll bleibt. Dies bietet betriebliche Echtzeitkenntnis, die über reine Rohmesswerte hinausgeht.

Berechnete Metriken

Mehrere Kalkulatoren leiten automatisch Metriken aus Rohmesswerten ab — Solarstrahlung wird zu Einstrahlungsenergie integriert, Stringleistung wird aus Spannung und Stromstärke berechnet und Leistungswerte werden über die Zeit zu Energie integriert. Diese Berechnungen erfolgen transparent und reichern den Datenstrom an, ohne eine explizite Konfiguration zu erfordern.

Edge-Analytik

Über die reine Erfassung hinaus führt der Data Scraper einen Satz von Analysen direkt an der Anlage aus, die aus dem Live-Metrik-Feed berechnet und neben den Rohdaten als darstellbare Zeitreihen exportiert werden.

Erwartete Leistung und Performance-Ratio

Der Agent berechnet die erwartete Leistung für jede Anlage aus ihren Einstrahlungsquellen (Pyranometer vor Ort, Satellitenstrahlung oder Wettermodell) und vergleicht sie mit der tatsächlichen Leistung, um die Performance-Ratio (PR) abzuleiten — ein normalisiertes Maß dafür, wie gut die Anlage verfügbares Sonnenlicht in Strom umwandelt. Die PR wird pro Tag berechnet und berücksichtigt Clipping, Frost und Datenqualitätsfilter, sodass anomale Tage das Ergebnis nicht verfälschen.

Live-Curtailment-Tracking

Wenn eine Anlage weniger produziert, als sie könnte, ordnet der Agent die entgangene Produktion ihrer Ursache zu: Curtailment durch den Direktvermarkter (eine bewusste marktgetriebene Begrenzung) gegenüber Curtailment durch den Netzbetreiber. Diese Unterscheidung ist wichtig für die Verlustabrechnung und das vertragliche Reporting. Curtailment wird pro Minute verfolgt und sowohl als momentane Leistung als auch als kumulierte Energie ausgegeben. Wie Curtailment in die gesamte Verlustzuordnung passt, erfahren Sie unter Verlusterkennung.

Clear-Sky-Baseline und Prognose

• Clear-Sky-Baseline: eine theoretische PV-Kurve unter Idealbedingungen, die als Langzeitaufzeichnung gepflegt wird und Ihnen eine stabile Referenz zum Vergleich mit der tatsächlichen Leistung liefert.
• Day-Ahead-Prognose: eine kurzfristige PV-Produktionsprognose, die aus Wetterdaten abgeleitet wird, sodass Sie die Leistung des nächsten Tages antizipieren können. Diese basieren auf Wetterphysik, nicht auf statistischen Schätzungen.

Historisches Backfill

Wenn eine Anlage erstmals angebunden wird oder nach einer Lücke kann der Agent historische Daten nachladen (Backfill) — er spielt Rohmesswerte erneut ab und leitet die oben genannten Analysen für ein angefordertes Zeitfenster neu ab und übergibt das Ergebnis dann an die Live-Pipelines, sodass die Diagramme von Tag eins an vollständig sind, statt leer zu beginnen.

Netzwerküberwachung

Der Data Scraper enthält einen integrierten Inspektor für das lokale Netzwerk, der parallel zur Datenerfassung läuft und das Vor-Ort-Netzwerk der Anlage kartiert. Er erkennt Geräte in den konfigurierten Netzwerkbereichen, indem er nach erreichbaren Hosts sucht, die Adresstabelle ausliest, Hersteller anhand von Hardware-Adressen identifiziert und Geräte nach ihrer Identität abfragt. Erkannte Geräte werden gegen eine umfangreiche Bibliothek bekannter Netzwerkgeräte-Profile klassifiziert, und ein Schritt zur KI-Geräteidentifikation hilft, Gerätefamilien zu erkennen, die einfache Regeln verpassen.

Sobald Geräte bekannt sind, fragt der Inspektor sie auf Erreichbarkeit und Gesundheit ab (Antwortzeit, Schnittstellen- und Ressourcenstatus) und meldet die Ergebnisse an die Plattform. Sie können einen Erkennungsscan auslösen oder stoppen, ein einzelnes Gerät erneut prüfen und das erkannte Netzwerk einsehen — siehe Inspektor für das lokale Netzwerk.

Proxy-Auditierung

Für Anlagen, die über den Mirox Browser-Proxy erreichbar sind, auditiert der Agent den menschlichen Zugriff auf lokale Geräteschnittstellen. Er gruppiert die Aktivität jeder Person in Sitzungen, schwärzt sensible Abfragedaten, bevor irgendetwas gespeichert wird, und kann eine KI-generierte Zusammenfassung dessen erstellen, was eine Sitzung getan hat. Dies fließt in den Zugriffs-Audit-Trail der Plattform ein — siehe Zugriffs-Audit-Log.

Leistungsmerkmale

Typische Leistung:

• Polling-Frequenzen: 1–300 Sekunden pro Adapter (konfigurierbar)
• Nebenläufige Adapter: 20+ gleichzeitig in Betrieb
• Durchsatz: 10.000+ Metriken pro Minute dauerhaft
• Latenz: Unter 100 ms von der Erfassung bis zum Datenbankeinfügen
• Ressourcennutzung: 5–15 % CPU, 100–500 MB Arbeitsspeicher auf Edge-Hardware

Die asynchrone Architektur gewährleistet hohe Nebenläufigkeit ohne Blockierung und ermöglicht eine effiziente Erfassung von vielen Quellen gleichzeitig.

Verwandte Funktionen

• Digital Twin — die physikbasierte Analyse-Engine, die die vom Data Scraper erfassten Metriken verarbeitet
• Mirox-Agent Überblick — wie sich der Data Scraper in den umfassenderen Edge-Agent einfügt
• Bereitstellungsoptionen — Abwägungen zwischen Vor-Ort- und Cloud-Bereitstellung des Agent
• Metrik-Erfassung — die vollständige standardisierte Metrik-Taxonomie
• Inspektor für das lokale Netzwerk — die Oberfläche zur Vor-Ort-Netzwerküberwachung
• Verlusterkennung — wie Curtailment und andere Verluste zugeordnet werden