Artikel

Langzeitstatistiken verstehen und Datenqualität prüfen

Langzeitstatistiken sind nur so verständlich wie ihre Ausgangsdaten. Der Artikel erklärt Messgrößen, Zähler, Einheiten und Datenlücken anhand eines fiktiven Prüfablaufs und zeigt, wie aus plausiblen Diagrammen belastbare Vergleiche werden.

BlackZackBlackZack

1585 Wörter · 8 Min. Lesezeit

  • home-assistant
  • statistik
  • datenqualität
Langzeitstatistiken verstehen und Datenqualität prüfen

Schematische Illustration zur Artikelserie; keine privaten Betriebsdaten.

Ein Jahresdiagramm kann ordentlich aussehen und trotzdem die falsche Frage beantworten. Vielleicht zeigt es eine Leistung, obwohl eigentlich Energie verglichen werden sollte. Vielleicht enthält ein Monatswert nur wenige aufgezeichnete Tage. Oder ein Gerät wurde ersetzt, ohne den Übergang kenntlich zu machen. Die schwierige Arbeit beginnt deshalb vor der Auswahl einer Diagrammkarte: Welche Bedeutung hat die Zahlenreihe, und unter welchen Bedingungen bleibt diese Bedeutung erhalten?

Home Assistant liefert dafür technische Bausteine. Die Entscheidung, ob zwei Zeiträume fachlich vergleichbar sind, bleibt eine eigene Aufgabe. Das folgende Beispiel verwendet ausschließlich erfundene Sensoren und Zahlen. Es beschreibt einen Prüfprozess für eine geplante Installation, keine Messdaten eines tatsächlichen Haushalts. Im Mittelpunkt steht eine kleine Werkstatt mit einem Temperaturfühler und einem Energiezähler, deren Werte später über längere Zeiträume betrachtet werden sollen.

Die Frage vor dem Diagramm formulieren

Für die Werkstatt entstehen zunächst zwei unterschiedliche Fragen. Bei der Temperatur interessiert, ob die Bedingungen im Wochenvergleich ähnlich waren. Beim Zähler interessiert, welche Energiemenge innerhalb eines Zeitraums hinzugekommen ist. Beide Reihen bestehen aus Zahlen, aber ein identischer Rechenweg wäre falsch. Ein durchschnittlicher Zählerstand beantwortet keine Verbrauchsfrage. Die Summe von Temperaturwerten hilft beim Vergleich der Raumtemperatur ebenfalls kaum weiter.

Eine gute Fragestellung benennt Messgröße, Zeitraum und erwartete Aussage. Beispielsweise: Wie unterscheiden sich die gemessenen Temperaturen während zweier vollständiger Wochen am selben Messort? Das Wort vollständig ist dabei bewusst gewählt. Ohne ausreichende Datenabdeckung könnte eine Woche nur kalte Nachtstunden enthalten, während die andere den ganzen Tagesverlauf abbildet. Ein Unterschied im Mittelwert wäre dann zunächst ein Unterschied der Beobachtung, nicht zwingend des Raums.

Daneben sollte feststehen, welche Entscheidung aus dem Ergebnis folgen darf. Eine auffällige Woche kann Anlass sein, den Sensorstandort oder eine Zeitsteuerung anzusehen. Sie beweist nicht automatisch einen Defekt. Diese Begrenzung verbessert die Analyse: Wer nur eine gezielte Kontrolle auslösen möchte, braucht häufig weniger komplizierte Kennzahlen als jemand, der eine belastbare Jahresbilanz erstellen will.

Messung und Zähler auseinanderhalten

Die Sensorbeschreibung kennt unter anderem die Zustandsklassen measurement, total und total_increasing. Für Langzeitstatistiken müssen geeignete Eigenschaften vorhanden sein. Die Klasse beschreibt dabei die Bedeutung des Werts; sie ist kein nachträglicher Schalter, mit dem jede Zahl zu einem sinnvollen Statistikwert wird. Die Unterschiede erläutert die offizielle Sensor-Dokumentation.

Im Beispiel ist die Raumtemperatur eine momentane Messung. Der Energiezähler stellt dagegen eine aufsummierte Größe bereit. Vor der Konfiguration wird geprüft, was dessen Hersteller tatsächlich ausgibt: einen dauerhaft fortgeschriebenen Stand, einen Tageszähler oder einen Wert, der beim Ausschalten zurückgesetzt wird. Diese Information gehört zur Gerätebeschreibung. Sie lässt sich nicht zuverlässig aus einem freundlich klingenden Entitätsnamen ableiten.

Ein kleiner Sprung nach unten verdient besondere Aufmerksamkeit. Bei einer Temperatur ist er gewöhnlich. Bei einem fortlaufenden Zähler kann er einen Neustart, Gerätewechsel oder fehlerhaften Messwert bedeuten. Wer alle drei Situationen gleich behandelt, beschädigt die Auswertung möglicherweise dauerhaft. Deshalb wird ein verdächtiger Zählerverlauf zuerst gegen die Rohdaten und bekannte Änderungen geprüft, bevor eine statistische Korrektur erfolgt.

Einheiten sind Teil der Daten

Die fiktive Werkstatt dokumentiert für jede Reihe Einheit und Herkunft. Eine Leistung in Watt ist nicht dieselbe Größe wie Energie in Kilowattstunden. Auch zwei Werte derselben Größe können unterschiedlich skaliert sein. Deshalb sollte eine Tabelle nicht bloß „Verbrauch“ enthalten, sondern beispielsweise „aufsummierte elektrische Energie, vom Gerät geliefert, Einheit Kilowattstunden“. Diese Beschreibung verhindert spätere Interpretationsfehler besser als ein besonders kurzer Name.

Beim Geräteaustausch wird der Übergang als eigener Prüffall behandelt. Liefert das Ersatzgerät Wattstunden, darf nicht nur das sichtbare Einheitenetikett geändert werden. Der Zahlenwert muss zur Einheit passen. Andernfalls sieht die Darstellung zwar einheitlich aus, doch der Verlauf enthält einen künstlichen Sprung. Die Prüfung betrachtet daher immer Zahlenwert und Einheit gemeinsam, einschließlich eventuell vorgeschalteter Templates oder Umrechnungen.

Eine praktische Gegenprobe nutzt einen bekannten, absichtlich einfachen Testwert. Wenn eine Umrechnung tausend Wattstunden in eine Kilowattstunde überführt, muss diese Beziehung im Test sichtbar bleiben. Das bestätigt nur die Umrechnung, noch nicht die Messgenauigkeit des Geräts. Diese beiden Prüfungen werden getrennt dokumentiert, damit aus einer korrekten Formel keine unbegründete Aussage über den Sensor entsteht.

Drei Ebenen nebeneinander ansehen

Für eine auffällige Stelle werden der aktuelle Sensorzustand, der detaillierte Verlauf und die verdichtete Darstellung nebeneinander betrachtet. Damit lässt sich eingrenzen, auf welcher Ebene eine Unstimmigkeit erstmals erscheint. Ist bereits der aktuelle Zustand unplausibel, hilft keine andere Diagrammkarte. Ist der Detailverlauf richtig und nur ein Vergleich missverständlich, liegt die Ursache eher in Zeitraum, Aggregation oder Darstellung.

Der Recorder bildet die Grundlage vieler gespeicherter Ansichten. Seine Aufgabe und die Verbindung zu Verlauf und Statistiken beschreibt die Recorder-Dokumentation. Für den eigenen Prüfprozess folgt daraus eine einfache Regel: Aufnahmefilter gehören zur Datenqualität. Eine Entität kann auf dem Dashboard aktuell korrekt erscheinen, obwohl ihre Vergangenheit für die gewünschte Untersuchung gar nicht aufgezeichnet wurde.

Die drei Ebenen sollten denselben Zeitraum und dieselbe Zeitzone verwenden. Ein Vergleich zwischen einem lokalen Kalendertag und einem anders begrenzten Export kann sonst scheinbar widersprüchliche Ergebnisse liefern. Das ist besonders an Tagesgrenzen sichtbar. Im Prüfprotokoll stehen deshalb Beginn und Ende ausdrücklich, statt lediglich „gestern“ oder „letzte Woche“ zu notieren.

Fehlende Werte nicht als Null tarnen

Ein ausgefallener Temperatursensor hat keine Temperatur von null Grad gemessen. Ein nicht erreichbarer Energiezähler meldet auch keinen sicheren Nullverbrauch. Die Ersatzannahme erscheint bequem, weil Berechnungen dann immer eine Zahl erhalten. Inhaltlich führt sie aber eine neue, unbewiesene Messung ein. Gerade Mittelwerte und Differenzen können dadurch überzeugend aussehen, obwohl sie nur den Fehler der Vorverarbeitung abbilden.

Für einen selbst gebauten Beispielsensor wird die Verfügbarkeit deshalb getrennt behandelt. Das folgende illustrative Fragment setzt voraus, dass die erfundene Quellentität tatsächlich eine Temperatur in Grad Celsius liefert. Es gehört in eine vorhandene Template-Konfiguration und muss dort passend zusammengeführt werden. Seine Aufgabe ist lediglich, einen fehlenden Eingang nicht als vermeintliche Temperatur zu veröffentlichen.

template:
  - sensor:
      - name: "Beispiel Werkstatt Temperatur geprüft"
        unique_id: beispiel_werkstatt_temperatur_geprueft
        unit_of_measurement: "°C"
        device_class: temperature
        state_class: measurement
        availability: >-
          {{ is_number(states('sensor.beispiel_werkstatt_temperatur_roh')) }}
        state: >-
          {{ states('sensor.beispiel_werkstatt_temperatur_roh') | float }}

Die verwendete Verfügbarkeitsvorlage ist in der Template-Dokumentation beschrieben. Zusätzlich braucht die Installation eine fachliche Plausibilitätsprüfung. Eine numerische Zeichenfolge kann formal gültig und dennoch offensichtlich falsch sein. Solche Auffälligkeiten sollten zunächst markiert werden. Heimliches Abschneiden auf einen vermeintlich normalen Bereich würde die Ursache verbergen und die historische Reihe verändern.

Datenabdeckung als eigene Information

Zu jeder längeren Auswertung gehört die Frage, wie viel des betrachteten Zeitraums tatsächlich beobachtet wurde. Eine Linie ohne sichtbare Unterbrechung ist dafür kein ausreichender Nachweis. Die Darstellung kann Punkte verbinden oder über lange Abschnitte denselben zuletzt bekannten Zustand zeigen. Deshalb wird im Beispiel zusätzlich festgehalten, wann die Quelle nachweislich neue Informationen geliefert hat und wann die Datenverbindung unterbrochen war.

Dabei ist ein unveränderter Messwert nicht automatisch veraltet. Ein Gerät kann wiederholt denselben Wert senden. Umgekehrt beweist ein sichtbarer Zahlenwert keine aktuelle Verbindung. Für eine verlässliche Beurteilung muss bekannt sein, ob die Integration einen geeigneten Empfangszeitpunkt, Verfügbarkeitsstatus oder regelmäßigen Bericht bereitstellt. Fehlt das, bleibt die Aktualität eingeschränkt beurteilbar; ein selbst erfundener Zeitstempel behebt diese Wissenslücke nicht.

Für den Wochenvergleich werden problematische Zeiträume zunächst markiert und getrennt besprochen. Eine unvollständige Woche muss nicht vollständig verworfen werden. Sie kann noch Auskunft über einen bestimmten beobachteten Abschnitt geben. Die Aussage wird dann enger formuliert: verglichen werden beispielsweise zwei dokumentierte Vormittage, nicht pauschal zwei ganze Wochen. Das erhält Nutzen, ohne fehlende Daten zu erfinden.

Rollende Statistik ist eine andere Aufgabe

Neben der langfristigen Betrachtung kann ein rollender Mittelwert hilfreich sein, etwa um kurzfristiges Schwanken auf einer Übersicht zu beruhigen. Die Statistics-Integration arbeitet mit einem eigenen Wertebuffer. Dessen zeitliche und mengenmäßige Begrenzung beeinflusst das Ergebnis. Das ist eine andere Fragestellung als die langfristige Speicherung einer Sensorreihe, wie die Dokumentation der Statistics-Integration erklärt.

Im Werkstattbeispiel wird ein geglätteter Wert ausschließlich als zusätzliche Anzeige verwendet. Der Rohsensor bleibt sichtbar und wird nicht durch die geglättete Reihe ersetzt. So lässt sich erkennen, ob eine langsame Reaktion vom Raum oder von der gewählten Glättung stammt. Ein größerer Beobachtungsbereich macht die Anzeige ruhiger, kann aber auch eine tatsächliche Änderung später erkennbar machen.

Bei unregelmäßigen Messabständen wird die Bedeutung des gewählten Mittelwerts ausdrücklich geprüft. Viele schnell hintereinander gelieferte Werte sollen nicht unbeabsichtigt einen langen, ruhig beobachteten Abschnitt verdrängen. Dafür genügt ein kleines künstliches Datenset mit unterschiedlichen Abständen. Entscheidend ist, ob das Ergebnis die gewünschte zeitliche Aussage trifft, nicht ob eine angebotene Kennzahl besonders wissenschaftlich klingt.

Korrekturen nachvollziehbar durchführen

Vor einer Korrektur werden Ursache, betroffener Zeitraum und beabsichtigte Wirkung beschrieben. Ein offensichtlicher Einheitenfehler ist anders zu behandeln als ein unbekannter Messausfall. Im ersten Fall existiert möglicherweise eine eindeutige Umrechnung. Im zweiten fehlen Informationen. Diese Unterscheidung verhindert, dass eine bequem interpolierte Kurve später als tatsächlich gemessener Verlauf gelesen wird.

Das Prüfprotokoll enthält einen Ausschnitt vor und nach der Änderung sowie die verwendete Annahme. Es braucht dafür keine vollständige Veröffentlichung privater Messreihen. Eine lokale Notiz mit den relevanten Entitätsbezügen genügt. Werden Beispiele geteilt, erhalten sie künstliche Namen und ersetzte Werte. So bleibt die technische Begründung überprüfbar, ohne den realen Nutzungsverlauf offenzulegen.

Nach einer Änderung wird nicht ausschließlich die korrigierte Stelle angesehen. Auch angrenzende Tage und daraus abgeleitete Monatswerte verdienen einen Vergleich. Eine Reparatur kann eine lokale Unstimmigkeit beseitigen und zugleich eine andere Auswertung verändern. Deshalb ist ein vorher festgelegtes Prüffenster sinnvoller als die spontane Feststellung, dass die auffällige Spitze verschwunden sei.

Ein überschaubarer Abnahmetest

Für die erste Freigabe der Werkstattstatistik werden vier künstliche Situationen durchgespielt: ein ruhiger Verlauf, eine deutliche gültige Änderung, eine fehlende Quelle und ein dokumentierter Gerätewechsel. Zu jeder Situation wird vorher aufgeschrieben, welche Darstellung erwartet wird. Der Ausfall soll als unsichere Datenlage erkennbar bleiben. Der Gerätewechsel soll eine Erklärung erhalten. Keine der beiden Situationen darf stillschweigend als gewöhnlicher Messverlauf durchgehen.

Anschließend liest eine zweite Person die Diagramme ohne mündliche Einführung. Kann sie Messgröße, Zeitraum und bekannte Lücken erkennen, ist die Darstellung brauchbar. Muss sie erst nachfragen, warum eine Linie springt oder was die Einheit bedeutet, fehlt Beschriftung. Dieser Lesetest prüft eine andere Qualität als die technische Berechnung und ist gerade bei langfristig selten betrachteten Ansichten wertvoll.

Die fertige Statistik erhält schließlich einen kurzen Begleittext: Herkunft, Zweck, bekannte Einschränkungen und Datum der letzten fachlichen Prüfung. Bei einem Sensorwechsel wird dieser Text aktualisiert. So bleibt eine Jahresübersicht auch Monate später verständlich. Ihr Wert entsteht aus der nachvollziehbaren Verbindung zwischen Messung und Aussage, nicht aus möglichst vielen farbigen Kurven auf einer Seite.

Quellen