Smart Home: Wir erstellen Verbrauchsdiagramme für Wasser und Strom in Home Assistant

Jedes Mal, wenn ich die Rechnung für Strom und Wasser bekomme, wundere ich mich – verbraucht meine Familie wirklich so viel? Ja, im Badezimmer gibt es eine Fußbodenheizung und einen Boiler, aber die laufen doch nicht ständig. Auch Wasser sparen wir, obwohl wir es lieben, im Bad zu planschen. Vor einigen Jahren habe ich bereits Wasserzähler angeschlossen und Strom an das Smart Home, aber damit war es dann auch. Erst jetzt habe ich endlich Zeit gefunden, den Verbrauch zu analysieren, worüber dieser Artikel handelt.

Kürzlich bin ich auf Home Assistant als Smart Home-System umgestiegen. Ein Grund war die Möglichkeit, eine große Menge an Daten zu sammeln und dabei einfach verschiedene Diagramme zu erstellen.

Die Informationen in diesem Artikel sind nicht neu, all diese Dinge wurden unter verschiedenen Vorwänden schon im Internet beschrieben. Aber in der Regel befasst sich jeder Artikel nur mit einem Ansatz oder Aspekt. Ich musste selbst die verschiedenen Ansätze vergleichen und den am besten geeigneten auswählen. Der Artikel liefert zwar keine umfassenden Informationen zur Datensammlung, ist aber eine Art Zusammenfassung, wie ich es gemacht habe. Konstruktive Kritik und Verbesserungsvorschläge sind willkommen.

Aufgabenstellung

Die heutige Übung hat also das Ziel, schöne Verbrauchsdiagramme für Wasser und Strom zu erstellen:

• Stündlich über 2 Tage
• Täglich über 2 Wochen
• (optional) wöchentlich und monatlich

Dabei stoßen wir auf einige Schwierigkeiten:

• Standard-Diagrammkomponenten sind in der Regel recht dürftig. Im besten Fall lässt sich ein Liniendiagramm aus Punkten erstellen.

  Wenn man gut sucht, kann man Drittanbieter-Komponenten finden, die die Möglichkeiten des Standarddiagramms erweitern. Für Home Assistant ist die Komponente mini-graph-cardim Grunde genommen nicht schlecht und sieht gut aus, aber auch sie hat einige Einschränkungen:

  • Es ist schwierig, die Parameter für das Säulendiagramm über große Zeiträume festzulegen (die Breite der Säule wird in Stundenbruchteilen angegeben, was bedeutet, dass Zeiträume von mehr als einer Stunde in Dezimalzahlen festgelegt werden müssen)
  • Man kann nicht verschiedene Entitäten (zum Beispiel Temperatur und Luftfeuchtigkeit oder ein Säulendiagramm mit einer Linie kombinieren) in ein Diagramm einfügen
• Es ist nicht nur so, dass der Home Assistant standardmäßig die einfachste SQLite-Datenbank verwendet (und ich, ungeschickt, die Installation von MySQL oder Postgres nicht bewältigen konnte), sondern auch, dass die Daten nicht optimal gespeichert werden. Beispielsweise wird bei jeder Änderung eines auch nur geringfügigen digitalen Parameters ein riesiges JSON, das etwa ein Kilobyte groß ist, in die Datenbank geschrieben.

  {"entity_id": "sensor.water_cold_hourly", "old_state": {"entity_id": "sensor.water_cold_hourly", "state": "3", "attributes": {"source": "sensor.water_meter_cold", "status": "collecting", "last_period": "29", "last_reset": "2020-02-23T21:00:00.022246+02:00", "meter_period": "hourly", "unit_of_measurement": "l", "friendly_name": "water_cold_hourly", "icon": "mdi:counter"}, "last_changed": "2020-02-23T19:05:06.897604+00:00", "last_updated": "2020-02-23T19:05:06.897604+00:00", "context": {"id": "aafc8ca305ba4e49ad4c97f0eddd8893", "parent_id": null, "user_id": null}}, "new_state": {"entity_id": "sensor.water_cold_hourly", "state": "4", "attributes": {"source": "sensor.water_meter_cold", "status": "collecting", "last_period": "29", "last_reset": "2020-02-23T21:00:00.022246+02:00", "meter_period": "hourly", "unit_of_measurement": "l", "friendly_name": "water_cold_hourly", "icon": "mdi:counter"}, "last_changed": "2020-02-23T19:11:11.251545+00:00", "last_updated": "2020-02-23T19:11:11.251545+00:00", "context": {"id": "0de64b8af6f14bb9a419dcf3b200ef56", "parent_id": null, "user_id": null}}}

  Ich habe ziemlich viele Sensoren (Temperatursensoren in jedem Raum, Wasser- und Stromzähler), und einige davon erzeugen außerdem eine beträchtliche Menge an Daten. Zum Beispiel erzeugt allein der Stromzähler SDM220 etwa zehn Werte alle 10-15 Sekunden, und ich würde gerne etwa 8 solcher Zähler installieren. Außerdem gibt es eine ganze Reihe von Parametern, die auf der Basis anderer Sensoren berechnet werden. So können all diese Werte die Datenbank leicht täglich um 100-200 MB aufblähen. Nach einer Woche wird das System kaum noch reibungslos laufen, und nach einem Monat wird der USB-Stick (im Falle einer typischen Home Assistant-Installation auf Raspberry Pi) ausfallen, geschweige denn, dass es möglich wäre, die Daten ein ganzes Jahr lang zu speichern.

• Wenn Sie Glück haben, kann Ihr Zähler selbst den Verbrauch erfassen. Sie können jederzeit den Zähler ansprechen und ihn nach dem aktuellen kumulierten Verbrauchswert fragen. In der Regel bieten alle Stromzähler mit digitaler Schnittstelle (RS232/RS485/Modbus/Zigbee) diese Möglichkeit.

  Schlimmer ist es, wenn das Gerät einfach nur einen bestimmten Momentanwert (zum Beispiel Momentanleistung oder Strom) messen kann, oder einfach Impulse alle X Wattstunden oder Liter generiert. Dann muss man darüber nachdenken, wie und womit man das integrieren und wo man die Werte speichern kann. Es besteht das Risiko, einen weiteren Bericht aus irgendeinem Grund zu verpassen, und auch die Genauigkeit des Systems insgesamt wirft Fragen auf. Man könnte natürlich alles dem Smart Home-System wie home assistant anvertrauen, aber der Punkt zur Anzahl der Einträge in der Datenbank ist nicht aufgehoben, und eine Abfrage der Sensoren öfter als einmal pro Sekunde lässt sich nicht einrichten (Architekturbegrenzung von home assistant).

Ansatz 1

Zunächst schauen wir uns an, was home assistant standardmäßig bietet. Die Messung des Verbrauchs über einen Zeitraum ist eine sehr gefragte Funktionalität. Natürlich wurde dies schon lange in Form einer spezialisierten Komponente – utility_meter – implementiert.

Der Kern der Komponente besteht darin, dass sie intern eine Variable für den aktuellen kumulierten Wert führt und diese nach Ablauf des festgelegten Zeitraums (Stunde/Woche/Monat) zurücksetzt. Die Komponente überwacht selbst die Eingangsvariable (den Wert eines Sensors), subscribiert sich selbst auf Änderungen des Wertes – Sie erhalten einfach das fertige Ergebnis. Diese Funktion lässt sich in nur wenigen Zeilen in der Konfigurationsdatei beschreiben.

utility_meter:
  water_cold_hour_um:
    source: sensor.water_meter_cold
    cycle: hourly
  water_cold_day_um:
    source: sensor.water_meter_cold
    cycle: daily

Hier ist sensor.water_meter_cold der aktuelle Wert des Zählers in Litern, den ich direkt von der Hardware über MQTT erhalte. Die Konstruktion erzeugt 2 neue Sensoren water_cold_hour_um und water_cold_day_um, die stündliche und tägliche Messwerte kumulieren und diese nach Ablauf des Zeitraums zurücksetzen. Hier ist das Diagramm des stündlichen Akkumulationswertes über einen halben Tag.

Der Code für die stündlichen und täglichen Graphen für die Lovelace-UI sieht so aus:

      - type: history-graph
        title: 'Stündlicher Wasserverbrauch mit Variablen'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Täglicher Wasserverbrauch mit Variablen'
        hours_to_show: 360
        entities:
          - sensor.water_day

Tatsächlich liegt in diesem Algorithmus das Problem dieser Herangehensweise. Wie ich bereits erwähnt habe, wird für jeden Eingangswert (aktuelle Zählerstand für jeden nächsten Liter) ein 1kB-Datensatz in der Datenbank generiert. Jeder Utility-Meter generiert zudem einen neuen Wert, der ebenfalls in die Datenbank eingetragen wird. Wenn ich stündliche/tägliche/wöchentliche/monatliche Ablesungen sammeln möchte, und das für mehrere Wasserleitungen, und dann noch eine Menge Stromzähler hinzufügen will – das wird extrem viele Daten bedeuten. Um genauer zu sein, die Daten sind nicht viel, aber da der Home Assistant eine Menge unnötiger Informationen in die Datenbank schreibt, wird die Größe der Datenbank explosionsartig wachsen. Ich habe sogar Angst, die Größe der Datenbank für wöchentliche und monatliche Diagramme einzuschätzen.

Darüber hinaus löst der Utility-Meter das gestellte Problem nicht von selbst. Der Graph der Werte, die der Utility-Meter ausgibt, ist eine monoton wachsende Funktion, die jede Stunde auf 0 zurückgesetzt wird. Wir benötigen jedoch ein für den Benutzer verständliches Diagramm des Verbrauchs, also wie viele Liter über den Zeitraum verbraucht wurden. Der Standardkomponent history-graph kann das nicht, aber der externe Komponent mini-graph-card könnte uns helfen.

Das ist der Code für die Karte für die Lovelace-UI:

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_hour_um
        group_by: hour
        hours_to_show: 48
        name: "Stündlicher Wasserverbrauch aggregiert nach Utility-Meter"
        points_per_hour: 1
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Neben den Standardkonfigurationen wie Sensorname, Diagrammtyp, Farbe (das Standardorange gefiel mir nicht) sind hier drei Einstellungen wichtig:

• group_by:hour — das Diagramm wird so generiert, dass die Balken am Beginn der Stunde ausgerichtet sind
• points_per_hour: 1 — ein Balken pro Stunde
• Und das Wichtigste, aggregate_func: max — das maximale Wert innerhalb jeder Stunde wird genommen. Diese Einstellung verwandelt das gezackte Diagramm in Balken.

Ignorieren Sie die Reihe von Balken links — das ist das Standardverhalten des Components, wenn keine Daten vorhanden sind. Und es gab keine Daten — ich habe die Datenerfassung für den Utility-Meter erst vor ein paar Stunden nur für diesen Artikel aktiviert (meinen aktuellen Ansatz werde ich gleich unten erläutern).

Auf diesem Bild wollte ich zeigen, dass manchmal die Datenanzeige tatsächlich funktioniert und die Balken die richtigen Werte widerspiegeln. Nur ist das bei weitem nicht der Fall. Der hervorgehobene Balken für den Zeitraum von 11 bis 12 Uhr zeigt aus irgendeinem Grund 19 Liter an, während wir im Zacken-Grafik etwas weiter oben für denselben Zeitraum vom selben Sensor einen Verbrauch von 62 Litern sehen. Entweder ein Bug oder es wurde falsch interpretiert. Warum die Daten rechts fehlen, habe ich noch nicht verstanden – der Verbrauch war dort im Normalbereich, was ebenfalls im Zacken-Grafik sichtbar ist.

Insgesamt ist es mir nicht gelungen, die Glaubwürdigkeit dieses Ansatzes zu erreichen – das Diagramm zeigt fast immer irgendeinen Unsinn.

Ein ähnlicher Code für den Tages-Sensor.

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_day_um
        group_by: interval
        hours_to_show: 360
        name: "Täglicher Wasserverbrauch aggregiert nach Versorgungszähler"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Beachten Sie, dass der Parameter group_by auf interval gesetzt ist und alle Punkte durch den Parameter points_per_hour bestimmt werden. Und darin liegt ein weiteres Problem dieser Komponente – points_per_hour funktioniert gut bei Diagrammen für eine Stunde oder weniger, aber schlecht bei größeren Zeiträumen. Um einen Balken für einen Tag zu erhalten, musste ich den Wert 1/24=0.04166666 eingeben. Von wöchentlichen und monatlichen Diagrammen will ich gar nicht reden.

Ansatz 2

Während ich mich noch in das Home Assistant einarbeite, bin ich auf dieses Video gestoßen:

Ein Bekannter sammelt Verbrauchsdaten von verschiedenen Arten von Xiaomi-Steckdosen. Seine Aufgabe ist etwas einfacher – einfach den Verbrauch für heute, gestern und für den Monat anzuzeigen. Es sind keine Diagramme erforderlich.

Lassen wir die Überlegungen zu der manuellen Integration von momentanen Leistungswerten beiseite – zur "Genauigkeit" dieses Ansatzes habe ich bereits oben geschrieben. Es ist unklar, warum er keine akkumulierten Verbrauchswerte verwendet hat, die bereits von derselben Steckdose gesammelt werden. Meiner Meinung nach wird eine Integration innerhalb des Gerätes besser funktionieren.

Aus dem Video übernehmen wir die Idee der manuellen Berechnung des Verbrauchs über einen Zeitraum. Der Typ betrachtet nur die Werte für heute und gestern, aber wir gehen weiter und versuchen, ein Diagramm zu zeichnen. Der Vorschlag besteht darin, dass ich in meinem Fall Folgendes tue.

Wir definieren die Variable wert_zum_Beginn_der_Stunde, in die wir die aktuellen Zählerstände schreiben.
Am Ende der Stunde (oder zu Beginn der nächsten) berechnen wir die Differenz zwischen dem aktuellen Messwert und dem zu Beginn der Stunde gespeicherten Wert. Diese Differenz wird der Verbrauch für die aktuelle Stunde sein – wir speichern den Wert im Sensor und werden in Zukunft basierend auf diesem Wert ein Diagramm erstellen.
Außerdem muss die Variable wert_zu_stundenbeginn zurückgesetzt werden, indem der aktuelle Wert des Zählers dort geschrieben wird.

All dies kann über die Mittel von Home Assistant selbst erledigt werden.

Es wird etwas mehr Code erforderlich sein als im vorherigen Ansatz. Zuerst erstellen wir diese "Variablen". Von Haus aus haben wir keine Entität "Variable", aber wir können die Dienste eines MQTT-Brokers nutzen. Wir werden Werte mit dem Flag retain=true dorthin senden – dies speichert den Wert im Broker, und wir können ihn jederzeit auch nach einem Neustart von Home Assistant wieder abrufen. Ich habe sowohl stündliche als auch tägliche Zähler erstellt.

- plattform: mqtt
  state_topic: "test/water/hour"
  name: wasser_stunde
  einheit: l

- plattform: mqtt
  state_topic: "test/water/hour_begin"
  name: wasser_stunde_begin
  einheit: l

- plattform: mqtt
  state_topic: "test/water/day"
  name: wasser_tag
  einheit: l

- plattform: mqtt
  state_topic: "test/water/day_begin"
  name: wasser_tag_begin
  einheit: l

Die ganze Magie geschieht in der Automatisierung, die jede Stunde und jede Nacht entsprechend ausgeführt wird.

- id: wasser_neue_stunde
  alias: wasser_neue_stunde
  initial_state: true
  trigger:
    - plattform: zeitmuster
      minuten: 0
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/hour"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_hour_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/hour_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

- id: wasser_neuer_tag
  alias: wasser_neuer_tag
  initial_state: true
  trigger:
    - plattform: zeit
      at: "00:00:00"
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/day"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_day_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/day_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

Beide Automatisierungen führen 2 Aktionen durch:

• Sie berechnen den Wert für das Intervall als Differenz zwischen dem Anfangs- und dem Endwert
• Sie aktualisieren den Basiswert für das nächste Intervall

Das Erstellen von Diagrammen wird in diesem Fall mit einem normalen history-graph gelöst:

      - type: history-graph
        title: 'Stündlicher Wasserverbrauch mit Variablen'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Täglicher Wasserverbrauch mit Variablen'
        hours_to_show: 360
        entities:
          - sensor.water_day

So sieht es aus:

Im Grunde ist dies bereits das, was benötigt wird. Ein Vorteil dieser Methode ist, dass die Daten nur einmal pro Intervall generiert werden. Das heißt, es gibt insgesamt 24 Einträge pro Tag für das Stunden-Diagramm.

Leider löst dies nicht das zugrunde liegende Problem einer wachsenden Datenbank. Wenn ich einen Monatlichen Verbrauchsbericht will, muss ich Daten mindestens für ein Jahr speichern. Da der Home Assistant nur eine einzige Einstellung für die Speicherdauer für die gesamte Datenbank bietet, bedeutet das, dass alle Daten im System ein ganzes Jahr lang aufbewahrt werden müssen. Zum Beispiel verbrauche ich im Jahr 200 Kubikmeter Wasser, was 200.000 Einträgen in der Datenbank entspricht. Wenn ich dann noch andere Sensoren berücksichtige, wird die Zahl wirklich unangemessen hoch.

Ansatz 3

Glücklicherweise haben kluge Köpfe bereits dieses Problem gelöst, indem sie die Datenbank InfluxDB entwickelt haben. Diese Datenbank ist speziell für die Speicherung zeitbasierter Daten optimiert und eignet sich hervorragend zur Speicherung von Werten verschiedener Sensoren. Das System bietet auch eine SQL-ähnliche Abfragesprache, mit der man Werte aus der Datenbank abrufen und auf verschiedene Arten aggregieren kann. Schließlich können unterschiedliche Daten unterschiedlich lange gespeichert werden. Zum Beispiel können häufig wechselnde Messwerte wie Temperatur oder Luftfeuchtigkeit nur ein paar Wochen lang gespeichert werden, während tägliche Wasserverbrauchswerte ein ganzes Jahr lang gespeichert werden können.

Neben InfluxDB haben kluge Köpfe auch Grafana erfunden – ein System zum Erstellen von Grafiken auf Basis von Daten aus InfluxDB. Grafana kann verschiedene Arten von Grafiken erstellen, diese detailliert anpassen und, was am wichtigsten ist, diese Grafiken können in die lovelace-UI des Home Assistant integriert werden.

Inspiriert von hier und hier. In den Artikeln wird der Prozess der Installation und Anbindung von InfluxDB und Grafana an den Home Assistant ausführlich beschrieben. Ich werde mich jedoch auf meine spezifische Aufgabe konzentrieren.

Also, als Erstes beginnen wir damit, den Wert des Zählers in InfluxDB zu speichern. Ein Stück der Home Assistant-Konfiguration (in diesem Beispiel werde ich mich nicht nur mit kaltem, sondern auch mit heißem Wasser beschäftigen):

influxdb:
  host: localhost
  max_retries: 3
  default_measurement: state
  database: homeassistant
  include:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

Wir deaktivieren das Speichern dieser Daten in der internen Datenbank von Home Assistant, um sie nicht unnötig aufzublähen:

recorder:
  purge_keep_days: 10
  purge_interval: 1
  exclude:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

Lassen Sie uns jetzt zur InfluxDB-Konsole übergehen und unsere Datenbank konfigurieren. Insbesondere müssen wir festlegen, wie lange bestimmte Daten aufbewahrt werden. Dies wird durch die sogenannte Retention Policy geregelt – das ist ähnlich wie Datenbanken innerhalb einer Hauptdatenbank, wobei jede interne Datenbank ihre eigenen Einstellungen hat. Standardmäßig werden alle Daten in der Retention Policy mit dem Namen autogen gespeichert, diese Daten werden eine Woche lang aufbewahrt. Ich möchte, dass stündliche Daten einen Monat lang aufbewahrt werden, wöchentliche Daten ein Jahr und monatliche Daten überhaupt nie gelöscht werden. Lassen Sie uns die entsprechenden Retention Policies erstellen.

CREATE RETENTION POLICY "month" ON "homeassistant" DURATION 30d REPLICATION 1
CREATE RETENTION POLICY "year" ON "homeassistant" DURATION 52w REPLICATION 1
CREATE RETENTION POLICY "infinite" ON "homeassistant" DURATION INF REPLICATION 1

Jetzt kommt der eigentliche Trick – die Aggregation von Daten mithilfe einer Continuous Query. Dies ist ein Mechanismus, der automatisch alle festgelegten Zeitintervalle einen Query ausführt, die Daten zu diesem Query aggregiert und das Ergebnis in einem neuen Wert speichert. Lassen Sie uns ein Beispiel durchgehen (ich schreibe es untereinander zur besseren Lesbarkeit, aber in Wirklichkeit musste ich diesen Befehl in einer Zeile eingeben).

CREATE CONTINUOUS QUERY cq_water_hourly ON homeassistant 
BEGIN 
  SELECT max(value) AS value 
  INTO homeassistant.month.water_meter_hour 
  FROM homeassistant.autogen.l 
  GROUP BY time(1h), entity_id fill(previous) 
END

Dieser Befehl:

• Erstellt eine Continuous Query mit dem Namen cq_water_cold_hourly in der Datenbank homeassistant.
• Die Abfrage wird jede Stunde ausgeführt (time(1h)).
• Die Abfrage wird alle Daten aus dem Measurement homeassistant.autogen.l (Liter) abfragen, einschließlich der Messwerte für kaltes und heißes Wasser.
• Die aggregierten Daten werden nach entity_id gruppiert, was uns separate Werte für kaltes und heißes Wasser liefert.
• Da der Literzähler eine monoton steigende Sequenz darstellt, muss innerhalb jeder Stunde der Höchstwert genommen werden, daher wird die Aggregation durch die Funktion max(value) durchgeführt.
• Der neue Wert wird in homeassistant.month.water_meter_hour gespeichert, wobei month der Name der Retention Policy mit einer Aufbewahrungsdauer von einem Monat ist. Dabei werden die Daten für kaltes und heißes Wasser in separaten Einträgen mit dem entsprechenden entity_id und dem Wert im Feld value gespeichert.

In der Nacht oder wenn niemand zu Hause ist, gibt es keinen Wasserverbrauch, und somit auch keine neuen Einträge in homeassistant.autogen.l. Um zu vermeiden, dass Werte in normalen Abfragen fehlen, kann fill(previous) verwendet werden. Dies zwingt InfluxDB, den Wert der letzten Stunde zu verwenden.

Leider hat die kontinuierliche Abfrage eine Besonderheit: der Trick fill(previous) funktioniert nicht und die Datensätze werden einfach nicht erstellt. Dabei handelt es sich um ein unüberwindbares Problem, das schon seit mehreren Jahren diskutiert wird.Wir werden uns später mit diesem Problem befassen, und fill(previous) in der kontinuierlichen Abfrage kann bleiben – es stört nicht.

Lass uns prüfen, was wir erreicht haben (natürlich müssen wir ein paar Stunden warten):

> select * from homeassistant.month.water_meter_hour group by entity_id
...
name: water_meter_hour
tags: entity_id=water_meter_cold
time                 value
----                 -----
...
2020-03-08T01:00:00Z 370511
2020-03-08T02:00:00Z 370513
2020-03-08T05:00:00Z 370527
2020-03-08T06:00:00Z 370605
2020-03-08T07:00:00Z 370635
2020-03-08T08:00:00Z 370699
2020-03-08T09:00:00Z 370761
2020-03-08T10:00:00Z 370767
2020-03-08T11:00:00Z 370810
2020-03-08T12:00:00Z 370818
2020-03-08T13:00:00Z 370827
2020-03-08T14:00:00Z 370849
2020-03-08T15:00:00Z 370921

Bitte beachten Sie, dass die Werte in der Datenbank in UTC gespeichert werden, weshalb sie in dieser Liste um 3 Stunden abweichen – die Werte um 7 Uhr morgens in der InfluxDB-Ausgabe entsprechen den Werten um 10 Uhr morgens in den obigen Grafiken. Beachten Sie auch, dass zwischen 2 und 5 Uhr morgens einfach keine Datensätze vorhanden sind – das ist die besagte Besonderheit der kontinuierlichen Abfrage.

Wie Sie sehen können, ist der aggregierte Wert ebenfalls eine monoton wachsende Folge, nur dass die Datensätze seltener kommen – einmal pro Stunde. Aber das ist kein Problem – wir können eine weitere Abfrage schreiben, die die richtigen Daten für das Diagramm abruft.

SELECT difference(max(value)) 
FROM homeassistant.month.water_meter_hour 
WHERE entity_id='water_meter_cold' and time >= now() -24h 
GROUP BY time(1h), entity_id 
fill(previous)

Ich werde das erklären:

• Wir ziehen Daten aus der Datenbank homeassistant.month.water_meter_hour für entity_id='water_meter_cold' der letzten 24 Stunden (time >= now() -24h).
• Wie ich bereits erwähnt habe, können in der Reihenfolge homeassistant.month.water_meter_hour einige Datensätze fehlen. Diese Daten werden wir neu generieren, indem wir die Abfrage mit GROUP BY time(1h) ausführen. Dieses Mal wird fill(previous) wie gewünscht funktionieren und fehlende Daten generieren (die Funktion nimmt den vorherigen Wert).
• Das Wichtigste an dieser Abfrage ist die Funktion difference, die die Differenz zwischen den stündlichen Markierungen berechnet. Sie selbst funktioniert nicht und erfordert eine aggregierende Funktion. Lassen wir es die zuvor verwendete max() sein.

Das Ergebnis sieht so aus:

name: water_meter_hour
tags: entity_id=water_meter_cold
time                 difference
----                 ----------
...
2020-03-08T02:00:00Z 2
2020-03-08T03:00:00Z 0
2020-03-08T04:00:00Z 0
2020-03-08T05:00:00Z 14
2020-03-08T06:00:00Z 78
2020-03-08T07:00:00Z 30
2020-03-08T08:00:00Z 64
2020-03-08T09:00:00Z 62
2020-03-08T10:00:00Z 6
2020-03-08T11:00:00Z 43
2020-03-08T12:00:00Z 8
2020-03-08T13:00:00Z 9
2020-03-08T14:00:00Z 22
2020-03-08T15:00:00Z 72

Von 2 bis 5 Uhr morgens (UTC) gab es keinen Verbrauch. Dennoch wird die Abfrage denselben Verbrauchswert zurückgeben, dank fill(previous), und die Funktion difference wird diesen Wert von sich selbst abziehen, sodass am Ende 0 herauskommt, was erforderlich ist.

Jetzt bleibt nur noch die Aufgabe, das Diagramm zu erstellen. Dazu öffnen wir Grafana, wählen ein bestehendes (oder erstellen ein neues) Dashboard und fügen ein neues Panel hinzu. Die Diagrameinstellungen werden wie folgt sein.

Ich werde die Daten für kaltes und warmes Wasser in einem Diagramm darstellen. Die Abfrage ist genau die gleiche, die ich oben beschrieben habe.

Die Anzeigeparameter werden wie folgt festgelegt. In meinem Fall wird es ein Linendiagramm (lines) sein, das in Treppenform (stairs) dargestellt wird. Den Parameter Stack werde ich gleich erläutern. Weiter unten gibt es noch ein paar Anzeigeparameter, die jedoch nicht so interessant sind.

Um das erhaltene Diagramm in Home Assistant einzufügen, müssen Sie:

• den Bearbeitungsmodus des Diagramms verlassen. Aus irgendeinem Grund werden die richtigen Freigabeeinstellungen für Diagramme nur von der Dashboard-Seite aus angeboten.
• Auf das Dreieck neben dem Diagrammnamen klicken und im Menü 'share' auswählen.
• Im sich öffnenden Fenster auf den Tab 'embed' wechseln.
• Das Häkchen bei 'current time range' entfernen – den Zeitbereich werden wir über die URL festlegen.
• Das benötigte Thema auswählen. In meinem Fall ist es light.
• Die resultierende URL in die Einstellungskarte lovelace-UI kopieren.

      - type: iframe
        id: graf_water_hourly
        url: "http://192.168.10.200:3000/d-solo/rZARemQWk/water?orgId=1&panelId=2&from=now-2d&to=now&theme=light"

Beachten Sie, dass der Zeitbereich (letzte 2 Tage) genau hier festgelegt wird und nicht in den Dashboard-Einstellungen.

So sieht das Diagramm aus. Warmwasser habe ich in den letzten 2 Tagen nicht verwendet, weshalb nur das Diagramm für kaltes Wasser angezeigt wird.

Ich habe mich bis jetzt nicht entschieden, welches Diagramm ich besser finde, das mit Linien in Treppenform oder das mit echten Säulen. Deshalb werde ich einfach ein Beispiel für ein Tagesdiagramm des Verbrauchs anführen, dieses Mal jedoch mit Säulen. Die Abfragen werden ähnlich wie die oben beschriebenen erstellt. Die Anzeigeparameter sind folgende:

So sieht dieses Diagramm aus:

Nun zum Parameter Stack. In diesem Diagramm wird die Säule für kaltes Wasser über der Säule für warmes Wasser gezeichnet. Die Gesamthöhe entspricht dem gesamten Verbrauch von kaltem und warmem Wasser über den Zeitraum.

Alle gezeigten Diagramme sind dynamisch. Man kann mit der Maus über einen interessierenden Punkt fahren und die Details sowie den Wert an diesem spezifischen Punkt einsehen.

Leider kam es nicht ohne einen Hauch von Kritik aus. In dem Säulendiagramm (im Gegensatz zu einem Treppendiagramm) befindet sich die Mitte der Säule nicht zur Mitte des Tages, sondern um 00:00 Uhr. Das bedeutet, dass die linke Hälfte der Säule an der Stelle des vorherigen Tages gezeichnet wird. So sind die Diagramme für Samstag und Sonntag etwas weiter links gezeichnet als die bläuliche Zone. Bis jetzt habe ich noch keine Lösung gefunden, wie ich das überwinden kann.

Ein weiteres Problem besteht darin, dass man nicht richtig mit Monatsintervallen arbeiten kann. Der Grund dafür ist, dass die Länge von Stunde/Tag/Woche festgelegt ist, während die Länge eines Monats jedes Mal unterschiedlich ist. InfluxDB kann nur mit gleichen Intervallen arbeiten. Bis jetzt hatte ich genug Verstand, um ein festes Intervall von 30 Tagen zu setzen. Ja, das Diagramm wird über das Jahr hinweg etwas verschoben sein und die Säulen werden nicht ganz genau mit den Monaten übereinstimmen. Aber da ich dies nur als Zeiger für mein Interesse sehe, ist mir das egal.

Ich sehe mindestens zwei Lösungen:

• Auf monatliche Diagramme verzichten und sich mit wöchentlichen begnügen. 52 wöchentliche Säulen pro Jahr sehen ganz gut aus.
• Das monatliche Verbrauchsquantifizieren als Methode Nr. 2 zu betrachten und Grafana nur für schöne Diagramme zu verwenden. Dadurch könnte eine ziemlich präzise Lösung entstehen. Man könnte sogar die Diagramme des vergangenen Jahres zur Vergleichung übereinanderlegen — dafür ist Grafana auch fähig.

Fazit

Ich weiß nicht warum, aber ich liebe solche Diagramme. Sie zeigen, dass das Leben pulsiert und sich alles verändert. Gestern gab es viel, heute wenig und morgen wird es irgendwie anders sein. Es bleibt nur abzuwarten, wie die Bedürfnisse der Haushaltsangehörigen in Bezug auf den Verbrauch sind. Aber selbst bei den aktuellen Ansprüchen verwandelt sich einfach eine große und unverständliche Zahl auf der Abrechnung in ein deutlich verständlicheres Bild des Verbrauchs.

Trotz fast 20 Jahren Erfahrung als Programmierer habe ich kaum mit Datenbanken gearbeitet. Daher schien mir die Installation einer externen Datenbank etwas sehr Kompliziertes und Unverständliches zu sein. Alles änderte sich durch den oben genannten Artikel, — es stellte sich heraus, dass das Anbinden eines geeigneten Werkzeugs in wenigen Klicks erledigt werden kann und mit einem spezialisierten Werkzeug wird die Aufgabe, Diagramme zu erstellen, etwas einfacher.

Im Titel habe ich den Stromverbrauch erwähnt. Leider kann ich momentan kein einziges Diagramm präsentieren. Ein SDM120 Zähler ist defekt, und der andere hat beim Zugriff über Modbus Probleme. Allerdings beeinflusst das das Thema dieses Artikels nicht — die Diagramme werden auf die gleiche Weise erstellt wie für Wasser.

In diesem Artikel habe ich die Ansätze dargestellt, die ich selbst ausprobiert habe. Sicherlich gibt es noch andere Möglichkeiten zur Organisation der Datenerfassung und -visualisierung, von denen ich nichts weiß. Erzählen Sie mir davon in den Kommentaren, ich wäre sehr interessiert. Ich freue mich über konstruktive Kritik und neue Ideen. Ich hoffe, das hier präsentierte Material hilft ebenfalls jemandem.

Quelle: habr.com