Get best of the week

Smart Home: Erstellen Sie Wasser- und Stromdiagramme in Home Assistant


Jedes Mal, wenn ich eine Rechnung für Strom und Wasser erhalte, frage ich mich - verbraucht meine Familie wirklich so viel? Ja, das Badezimmer hat eine Fußbodenheizung und einen Heizkessel, aber sie heizen nicht ständig. Wir scheinen auch Wasser zu sparen (obwohl wir es auch lieben, im Badezimmer zu planschen). Vor ein paar Jahren habe ich bereits Wasser- und Stromzähler an ein Smart Home angeschlossen, aber das blieb hängen. Erst jetzt ging es um die Analyse des Verbrauchs, um die es in diesem Artikel tatsächlich geht.

Ich habe kürzlich als Smart-Home-System zu Home Assistant gewechselt. Einer der Gründe war nur die Möglichkeit, die Erfassung einer großen Datenmenge mit der Möglichkeit zu organisieren, verschiedene Arten von Diagrammen bequem zu erstellen.

Die in diesem Artikel beschriebenen Informationen sind nicht neu, all diese Dinge mit unterschiedlichen Saucen wurden bereits im Internet beschrieben. Jeder Artikel beschreibt jedoch in der Regel nur einen Ansatz oder Aspekt. Ich musste all diese Ansätze vergleichen und selbst den am besten geeigneten auswählen. Der Artikel enthält immer noch keine umfassenden Informationen zur Datenerfassung, ist jedoch eine Art Zusammenfassung meiner Vorgehensweise. Konstruktive Kritik und Verbesserungsvorschläge sind daher willkommen.

Formulierung des Problems


Das Ziel der heutigen Übung ist es also, schöne Diagramme des Wasser- und Stromverbrauchs zu erhalten:

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

Hier erwarten uns einige Schwierigkeiten:

  • , , . .

    , , . home assistant, , mini-graph-card, :

    • ( , )
    • ( , )
  • , home assistant SQLite ( , , MySQL Postgres), . , , json

    {"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}}}

    ( , ), . SDM220 10-15 , 8. , . .. 100-200 . , ( home assistant raspberry PI), .
  • , . . (RS232/RS485/Modbus/Zigbee) .

    ( ), X - . . , . , , home assistant, , ( home assistant).

1


Lassen Sie uns zunächst sehen, was der Heimassistent sofort bereitstellt. Die Messung des Verbrauchs über einen bestimmten Zeitraum ist eine sehr gefragte Funktion. Natürlich wurde es vor langer Zeit in Form einer speziellen Komponente realisiert - Utility_meter.

Das Wesentliche der Komponente ist, dass darin die Variable current_accumulated_value gestartet und nach einem bestimmten Zeitraum (Stunde / Woche / Monat) zurückgesetzt wird. Die Komponente selbst überwacht die eingehende Variable (den Wert einer Art Sensor), abonniert Änderungen des Werts selbst - Sie erhalten nur das Endergebnis. Diese Sache wird in der Konfigurationsdatei in wenigen Zeilen beschrieben.

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 per mqtt direkt vom Eisenstück bekomme. Das Design erstellt zwei neue Sensoren water_cold_hour_um und water_cold_day_um, die stündliche und tägliche Messwerte sammeln und diese nach einer gewissen Zeit zurücksetzen. Hier ist eine halbstündige Batterietabelle.

Bild

Der Stunden- und Tages-Chartcode für die Lovelace-Benutzeroberfläche sieht folgendermaßen aus:

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

Tatsächlich liegt das Problem dieses Ansatzes in diesem Algorithmus. Wie bereits erwähnt, wird für jeden Eingabewert (der aktuelle Zählerstand für jeden nächsten Liter) 1 KB Datensatz in der Datenbank generiert. Jeder Stromzähler generiert außerdem einen neuen Wert, der sich ebenfalls zur Datenbank summiert. Wenn ich stündliche / tägliche / wöchentliche / monatliche Messwerte und für mehrere Wasseraufsteiger erfassen und sogar ein paar Stromzähler hinzufügen möchte, sind dies viele Daten. Genauer gesagt, es gibt nicht viele Daten, aber da der Heimassistent eine Reihe unnötiger Informationen in die Datenbank schreibt, wird die Größe der Datenbank sprunghaft zunehmen. Ich habe sogar Angst, die Größe der Basis für wöchentliche und monatliche Charts zu schätzen.

Darüber hinaus löst der Stromzähler allein die Aufgabe nicht. Das Diagramm der Werte, das der Betriebszähler anzeigt, ist eine monoton ansteigende Funktion, die stündlich auf 0 zurückgesetzt wird. Wir brauchen eine benutzerfreundliche Verbrauchstabelle, wie viele Liter während des Zeitraums gegessen wurden. Die Standard-Verlaufsgraphenkomponente weiß nicht, wie das geht, aber die externe Mini-Grafikkartenkomponente kann uns helfen.

Dies ist der Kartencode für die Liebes-Benutzeroberfläche:

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_hour_um
        group_by: hour
        hours_to_show: 48
        name: "Hourly water consumption aggregated by utility meter"
        points_per_hour: 1
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Zusätzlich zu den Standardeinstellungen wie dem Namen des Sensors, der Art des Diagramms und der Farbe (mir hat das Standardorange nicht gefallen) ist es wichtig, 3 Einstellungen zu beachten:

  • group_by: hour - Das Diagramm wird mit den am Anfang der Stunde ausgerichteten Spalten erstellt
  • points_per_hour: 1 - ein Balken pro Stunde
  • , aggregate_func: max — .



Achten Sie nicht auf eine Reihe von Spalten auf der linken Seite - dies ist das Standardverhalten einer Komponente, wenn keine Daten vorhanden sind. Und es gab keine Daten - ich habe die Datenerfassung für Versorgungszähler erst vor ein paar Stunden nur wegen dieses Artikels aktiviert (ich werde etwas später auf meinen aktuellen Ansatz eingehen).

In diesem Bild wollte ich zeigen, dass die Datenanzeige manchmal sogar funktioniert und die Balken wirklich die richtigen Werte widerspiegeln. Aber das ist nicht alles. Die ausgewählte Spalte für das Intervall von 11 bis 12 Uhr morgens zeigt aus irgendeinem Grund 19 Liter an, obwohl auf der Zahnkarte für denselben Zeitraum ein etwas höherer Verbrauch von 62 Litern vom selben Sensor angezeigt wird. Entweder ein Käfer oder Hände sind schief. Aber ich verstehe nicht, warum die Daten auf der rechten Seite abgebrochen sind - der Verbrauch dort war normal, was auch auf dem Zahnplan sichtbar ist.

Im Allgemeinen habe ich es nicht geschafft, die Glaubwürdigkeit dieses Ansatzes zu erreichen - die Grafik zeigt fast immer eine Art Häresie.

Der gleiche Code für den Tagessensor.

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_day_um
        group_by: interval
        hours_to_show: 360
        name: "Daily water consumption aggregated by utility meter"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Beachten Sie, dass der Parameter group_by auf Intervall festgelegt ist und der Parameter points_per_hour alles regelt. Und dies ist ein weiteres Problem dieser Komponente - points_per_hour funktioniert gut für Diagramme in einer Stunde oder weniger, ist aber in großen Intervallen widerlich. Um eine Spalte an einem Tag zu erhalten, musste ich den Wert 1/24 = 0,04166666 eingeben. Ich spreche nicht von Wochen- und Monats-Charts.

Ansatz 2


Als ich gerade den Heimassistenten herausgefunden habe, bin ich hier auf dieses Video gestoßen:


Ein Freund sammelt Verbrauchsdaten von verschiedenen Arten von Xiaomi-Verkaufsstellen. Seine Aufgabe ist etwas einfacher - zeigen Sie einfach den Wert des Verbrauchs für heute, gestern und für den Monat an. Es sind keine Zeitpläne erforderlich.

Lassen wir die Diskussion über die manuelle Integration von Momentanleistungswerten beiseite - ich habe bereits über die „Genauigkeit“ dieses Ansatzes geschrieben. Es ist nicht klar, warum er die kumulierten Verbrauchswerte, die bereits von derselben Verkaufsstelle gesammelt wurden, nicht verwendet hat. Meiner Meinung nach funktioniert die Integration in das Stück Eisen besser.

Aus dem Video nehmen wir die Idee, den Verbrauch für den Zeitraum manuell zu berechnen. Der Bauer zählt nur die Werte für heute und gestern, aber wir werden weiter gehen und versuchen, eine Grafik zu zeichnen. Das Wesentliche der vorgeschlagenen Methode ist in meinem Fall wie folgt.

  • ___,
  • ( ) . — , .
  • “” ___ .

All dies kann getan werden , w ... durch Mittel des Hauses Assistent selbst.

Sie müssen mehr Code schreiben als im vorherigen Ansatz. Lassen Sie uns zunächst genau diese „Variablen“ abrufen. Standardmäßig haben wir keine "variable" Entität, aber Sie können die Dienste des mqtt-Brokers nutzen. Wir senden dort Werte mit dem Flag keep = true - dies speichert den Wert im Broker und Sie können ihn jederzeit abrufen, auch wenn der Home Assistant neu startet. Ich habe sofort Stunden- und Tagzähler gemacht.

- platform: mqtt
  state_topic: "test/water/hour"
  name: water_hour
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/hour_begin"
  name: water_hour_begin
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day"
  name: water_day
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day_begin"
  name: water_day_begin
  unit_of_measurement: l

Alle Magie geschieht in der Automatisierung, die jede Stunde bzw. jede Nacht ausgeführt wird.

- id: water_new_hour
  alias: water_new_hour
  initial_state: true
  trigger:
    - platform: time_pattern
      minutes: 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: water_new_day
  alias: water_new_day
  initial_state: true
  trigger:
    - platform: time
      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 zwei Aktionen aus:

  • Der Wert für das Intervall wird als Differenz zwischen Start- und Endwert berechnet
  • Aktualisieren Sie den Basiswert für das nächste Intervall

Die grafische Darstellung wird in diesem Fall durch das übliche Verlaufsdiagramm gelöst:

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

Es sieht so aus:



Im Prinzip ist dies bereits das, was Sie brauchen. Der Vorteil dieser Methode ist, dass die Daten einmal pro Intervall generiert werden. Jene. Nur 24 Einträge pro Tag für das Stunden-Chart.

Leider löst dies immer noch nicht das allgemeine Problem einer wachsenden Basis. Wenn ich einen monatlichen Verbrauchsplan haben möchte, muss ich die Daten mindestens ein Jahr lang speichern. Und da der Heimassistent nur eine Einstellung für die Speicherdauer der gesamten Datenbank bereitstellt, müssen ALLE Daten im System ein ganzes Jahr lang gespeichert werden. Zum Beispiel verbrauche ich ein Jahr lang 200 Kubikmeter Wasser, was bedeutet, dass es 200.000 Datensätze in der Datenbank sind. Und wenn Sie andere Sensoren berücksichtigen, wird die Zahl überhaupt unanständig.

Ansatz 3


Glücklicherweise haben kluge Köpfe dieses Problem bereits durch das Schreiben der InfluxDB-Datenbank gelöst. Diese Datenbank ist speziell für die Speicherung zeitbasierter Daten optimiert und eignet sich ideal zum Speichern von Werten verschiedener Sensoren. Das System bietet auch eine SQL-ähnliche Abfragesprache, mit der Sie Werte aus der Datenbank auswählen und dann auf verschiedene Arten aggregieren können. Schließlich können unterschiedliche Daten zu unterschiedlichen Zeiten gespeichert werden. Beispielsweise können häufig wechselnde Messwerte wie Temperatur oder Luftfeuchtigkeit nur einige Wochen gespeichert werden, während tägliche Messwerte des Wasserverbrauchs ein ganzes Jahr lang gespeichert werden können.

Neben InfluxDB haben Smart People auch Grafana erfunden, ein Diagrammsystem, das auf Daten von InfluxDB basiert. Grafana kann verschiedene Arten von Diagrammen zeichnen, sie detailliert anpassen und vor allem können diese Diagramme auf dem Home-Assistenten der Lovelace-Benutzeroberfläche „hängen bleiben“.

Lassen Sie sich hier und hier inspirieren . In den Artikeln wird detailliert beschrieben, wie InfluxDB und Grafana installiert und mit dem Heimassistenten verbunden werden. Ich werde mich auf die Lösung meines spezifischen Problems konzentrieren.

Beginnen wir also zunächst damit, den Zählerwert in influxDB zu addieren. Ein Teil der Home Assistant-Konfiguration (in diesem Beispiel werde ich nicht nur mit kaltem, sondern auch mit heißem Wasser Spaß haben):

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

Deaktivieren Sie das Speichern derselben Daten in der internen Datenbank des Heimassistenten, um sie nicht erneut aufzublasen:

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

Wir gehen jetzt zur InfluxDB-Konsole und richten unsere Datenbank ein. Insbesondere müssen Sie konfigurieren, wie lange diese oder jene Daten gespeichert werden. Dies wird durch die sogenannten geregelt Aufbewahrungsrichtlinie - Dies ähnelt den Datenbanken in der Hauptdatenbank, wobei jede interne Datenbank ihre eigenen Einstellungen hat. Standardmäßig werden alle Daten in einer Aufbewahrungsrichtlinie namens autogen gespeichert. Diese Daten werden eine Woche lang gespeichert. Ich möchte, dass die stündlichen Daten für einen Monat, die wöchentlichen für ein Jahr und die monatlichen Daten niemals gelöscht werden. Erstellen Sie eine entsprechende Aufbewahrungsrichtlinie

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

Tatsächlich ist der Haupttrick die Datenaggregation mithilfe einer kontinuierlichen Abfrage. Dies ist ein Mechanismus, der automatisch eine Abfrage in bestimmten Intervallen startet, Daten für diese Abfrage aggregiert und das Ergebnis einem neuen Wert hinzufügt. Schauen wir uns ein Beispiel an (ich schreibe zur besseren Lesbarkeit in eine Spalte, musste diesen Befehl jedoch 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 fortlaufende Abfrage mit dem Namen cq_water_cold_hourly in der homeassistanten Datenbank
  • Die Anfrage wird stündlich ausgeführt (Zeit (1h))
  • Bei der Anforderung werden alle Daten aus der Messung "homeassistant.autogen.l" (Liter) abgerufen, einschließlich der Messwerte für kaltes und heißes Wasser
  • Aggregierte Daten werden nach entity_id gruppiert, wodurch separate Werte für kaltes und heißes Wasser erstellt werden.
  • , max(value)
  • homeassistant.month.water_meter_hour, month retention policy . entity_id value

Nachts oder wenn niemand zu Hause ist, gibt es keinen Wasserverbrauch und dementsprechend gibt es auch keine neuen Einträge in homeassistant.autogen.l. Um zu vermeiden, dass Werte in regulären Abfragen fehlen, können Sie fill (vorherige) verwenden. Dadurch wird InfluxDB gezwungen, den Wert für die letzte Stunde zu verwenden.

Leider hat die kontinuierliche Abfrage eine Besonderheit: Der Fülltrick (vorheriger Trick) funktioniert nicht und Datensätze werden einfach nicht erstellt. Darüber hinaus ist dies ein unüberwindbares Problem, das seit mehr als einem Jahr diskutiert wird . Wir werden uns später mit diesem Problem befassen und die fortlaufende Abfrage ausfüllen (vorher) - es stört nicht.

Lassen Sie uns überprüfen, was passiert ist (natürlich müssen Sie 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 sind. Daher unterscheiden sie sich in dieser Liste um 3 Stunden. Die Werte für 7 Uhr in der InfluxDB-Ausgabe entsprechen den Werten für 10 Uhr in den obigen Grafiken. Beachten Sie auch, dass zwischen 2 und 5 Uhr morgens einfach keine Datensätze vorhanden sind - dies ist das gleiche Merkmal der kontinuierlichen Abfrage.

Wie Sie sehen können, ist der aggregierte Wert auch eine monoton ansteigende Sequenz, nur Datensätze sind weniger häufig - einmal pro Stunde. Dies ist jedoch kein Problem. Wir können eine weitere Abfrage schreiben, die die richtigen Daten für das Diagramm liefert.

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 entschlüsseln:

  • Aus der Datenbank homeassistant.month.water_meter_hour extrahieren wir die Daten für entity_id = 'water_meter_cold' für den letzten Tag (time> = now () -24h).
  • Wie ich in der Sequenz homeassistant.month.water_meter_hour erwähnt habe, fehlen möglicherweise einige Einträge. Wir werden diese Daten neu generieren, indem wir eine Abfrage mit der GROUP BY-Zeit (1 Stunde) ausführen. Diese Zeitfüllung (vorherige) funktioniert nach Bedarf und generiert die fehlenden Daten (die Funktion übernimmt den vorherigen Wert).
  • Das Wichtigste bei dieser Anforderung ist die Differenzfunktion, mit der die Differenz zwischen den Stundenmarkierungen berechnet wird. An sich funktioniert es nicht und erfordert eine Aggregatfunktion. Es sei das zuvor verwendete max ().

Das Ergebnis der Ausführung 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. Trotzdem gibt die Abfrage aufgrund der Füllung (vorherige) denselben Verbrauchswert zurück, und die Differenzfunktion subtrahiert diesen Wert von sich selbst und wir erhalten 0 an der Ausgabe, was tatsächlich erforderlich ist.

Sie müssen nur noch einen Zeitplan erstellen. Öffnen Sie dazu Grafana, öffnen Sie ein vorhandenes (oder erstellen Sie ein neues) Dashboard und erstellen Sie ein neues Bedienfeld. Die Diagrammeinstellungen werden so aussehen.



Ich werde Daten zu kaltem und heißem Wasser auf einer Karte anzeigen. Die Anfrage ist genau die gleiche wie oben beschrieben.

Die Anzeigeparameter werden wie folgt eingestellt. Ich werde eine Grafik mit Linien haben, die über Treppen führt. Ich werde den Stack-Parameter unten erläutern. Es gibt unten ein paar weitere Anzeigeoptionen, die jedoch nicht so interessant sind.



Um den empfangenen Zeitplan zum Heimassistenten hinzuzufügen, benötigen Sie:

  • . -
  • , share
  • embed
  • current time range — URL
  • . light
  • URL lovelace-UI

      - 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"

Bitte beachten Sie, dass der Zeitbereich (die letzten 2 Tage) hier und nicht in den Dashboard-Einstellungen festgelegt wird.

Das Diagramm sieht so aus. Ich habe in den letzten 2 Tagen kein heißes Wasser verwendet, daher wird nur eine Grafik mit kaltem Wasser gezeichnet.



Ich habe mich nicht entschieden, welchen Zeitplan ich am liebsten mag, eine Step-Line oder echte Bars. Daher werde ich nur ein Beispiel für ein tägliches Verbrauchsdiagramm geben, diesmal jedoch in Spalten. Anfragen werden auf die gleiche Weise wie oben beschrieben erstellt. Die Anzeigeparameter lauten wie folgt:



Diese Grafik sieht folgendermaßen aus:



Also über den Stapelparameter. In diesem Diagramm wird eine Kaltwassersäule auf eine Heißwassersäule gezogen. Die Gesamthöhe entspricht dem Gesamtverbrauch an kaltem und heißem Wasser für den Zeitraum.

Alle gezeigten Grafiken sind dynamisch. Sie können mit der Maus über einen Punkt von Interesse fahren und die Details und den Wert an einem bestimmten Punkt anzeigen.

Leider konnten ein paar Löffel Teer nicht. Im Balkendiagramm (im Gegensatz zum Diagramm mit Schrittlinien) befindet sich die Mitte des Balkens nicht in der Mitte des Tages, sondern um 00:00 Uhr. Jene. Die linke Hälfte der Spalte wird anstelle des vorherigen Tages gezeichnet. Die Karten für Samstag und Sonntag sind also etwas links als die bläuliche Zone gezeichnet. Bis ich herausgefunden habe, wie ich es gewinnen kann.

Ein weiteres Problem ist die Unfähigkeit, in monatlichen Abständen korrekt zu arbeiten. Tatsache ist, dass die Länge der Stunde / des Tages / der Woche festgelegt ist, die Länge des Monats jedoch jedes Mal anders ist. InfluxDB kann nur in regelmäßigen Abständen arbeiten. Bisher reichte mein Gehirn aus, um ein festes Intervall von 30 Tagen festzulegen. Ja, die Grafik schwebt im Laufe des Jahres ein wenig und die Spalten entsprechen nicht genau den Monaten. Aber da dieses Ding für mich einfach als Anzeigegerät interessant ist, bin ich damit einverstanden.

Ich sehe mindestens zwei Lösungen:

  • Punktzahl nach monatlichen Zeitplänen und Beschränkung auf wöchentlich. 52 wöchentliche Bars für das Jahr sehen ziemlich gut aus
  • №2, . . — .



Ich weiß nicht warum, aber ich trete auf solche Charts. Sie zeigen, dass das Leben in vollem Gange ist und sich alles verändert. Gestern war viel, heute ist nicht genug, morgen wird etwas anderes sein. Es bleibt die Arbeit mit den Haushalten zum Thema Konsum. Aber selbst bei aktuellem Appetit verwandelt sich bereits eine große und unverständliche Zahl in der Zahlung in ein ziemlich klares Bild des Konsums.

Trotz der fast 20-jährigen Karriere als Programmierer habe ich mich praktisch nicht mit Datenbanken überschnitten. Daher schien die Installation einer externen Datenbank etwas so Abstruses und Unverständliches zu sein. Durch den oben genannten Artikel wurde alles geändert - es stellte sich heraus, dass das Verschrauben eines geeigneten Werkzeugs mit wenigen Klicks erledigt werden kann und mit einem speziellen Werkzeug die grafische Darstellung etwas einfacher wird.

In der Überschrift habe ich den Stromverbrauch erwähnt. Leider kann ich im Moment kein einziges Diagramm geben. Ein SDM120-Zähler ist tot und der andere ist fehlerhaft, wenn über Modbus zugegriffen wird. Dies hat jedoch keine Auswirkungen auf das Thema dieses Artikels - die Grafiken werden auf die gleiche Weise wie für Wasser erstellt.

In diesem Artikel habe ich die Ansätze zitiert, die ich selbst ausprobiert habe. Sicher gibt es einige andere Möglichkeiten, die Erfassung und Visualisierung von Daten zu organisieren, die ich nicht kenne. Erzähl mir davon in den Kommentaren, es wird sehr interessant für mich sein. Ich freue mich über konstruktive Kritik und neue Ideen. Ich hoffe, dass das präsentierte Material auch jemandem hilft.

More articles:


All Articles