Maison intelligente : Construisons des graphiques de consommation d'eau et d'électricité dans Home Assistant

Chaque fois que je reçois ma facture d'électricité et d'eau, je suis étonné : ma famille consomme-t-elle vraiment autant ? Certes, nous avons un chauffage au sol et un chauffe-eau dans la salle de bain, mais ils ne fonctionnent pas en continu. Nous essayons aussi d'économiser l'eau (même si nous aimons nous détendre dans la baignoire). Il y a déjà plusieurs années, j'ai installé des compteurs d'eau et d'électricité à la maison intelligente, mais je me suis arrêté là. Ce n'est que récemment que j'ai vraiment commencé à analyser mes consommations, et c'est de cela que parle cet article.

Récemment, je suis passé à Home Assistant comme système de maison intelligente. L'une des raisons était justement la possibilité de collecter une grande quantité de données et de construire facilement divers types de graphiques.

Les informations décrites dans cet article ne sont pas nouvelles ; toutes ces choses ont déjà été abordées sous différentes formes sur Internet. Mais chaque article se concentre généralement sur une seule approche ou un seul aspect. J'ai dû comparer toutes ces approches et choisir celle qui me convenait le mieux. Cet article n'apporte pas d'informations exhaustives sur la collecte de données, mais constitue plutôt un résumé de ma propre expérience. Je suis donc ouvert à toute critique constructive et à des suggestions d'amélioration.

Définition du problème

Ainsi, l'objectif de l'exercice d'aujourd'hui est d'obtenir de jolis graphiques de consommation d'eau et d'électricité :

• Horaire sur 2 jours
• Journalier sur 2 semaines
• (optionnel) Hebdomadaire et Mensuel

Nous rencontrons quelques difficultés ici :

• Les composants graphiques standards sont généralement assez limités. Dans le meilleur des cas, on peut créer un graphique linéaire à partir de points.

  Si l'on cherche bien, on peut trouver des composants tiers qui élargissent les capacités des graphiques standards. Pour Home Assistant, il y a un composant qui est à la fois joli et fonctionnel : mini-graph-card, mais il est aussi un peu limité :

  • Il est difficile de définir les paramètres d'un histogramme sur de grands intervalles (largeur de la barre définie en fractions d'heure, donc les intervalles de plus d'une heure doivent être spécifiés par des nombres décimaux)
  • On ne peut pas ajouter différentes entités sur un même graphique (par exemple, combiner la température et l'humidité, ou mélanger un histogramme avec une ligne)
• Non seulement Home Assistant utilise par défaut une base de données SQLite assez rudimentaire (et moi, avec mes compétences limitées, je n'ai pas réussi à installer MySQL ou Postgres), mais les données sont également stockées de manière peu optimale. Par exemple, à chaque changement de n'importe quel paramètre numérique, même le plus insignifiant, un énorme JSON d'environ un kilooctet est enregistré dans la base.

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

  J'ai un nombre assez élevé de capteurs (des capteurs de température dans chaque pièce, des compteurs d'eau et d'électricité), et certains génèrent également une quantité importante de données. Par exemple, le compteur électrique SDM220 génère environ une dizaine de valeurs toutes les 10 à 15 secondes, et j'aimerais installer environ 8 de ces compteurs. De plus, il y a toute une série de paramètres calculés sur la base d'autres capteurs. Ainsi, toutes ces valeurs peuvent facilement gonfler la base de données de 100 à 200 Mo par jour. Après une semaine, le système aura du mal à fonctionner, et après un mois, la clé USB risque de rendre l'âme (dans le cas d'une installation typique de Home Assistant sur un Raspberry Pi), et il est hors de question de stocker les données pendant un an.

• Si vous avez de la chance, votre compteur est capable de calculer la consommation par lui-même. Vous pouvez à tout moment interroger le compteur pour connaître la valeur accumulée de la consommation. En général, tous les compteurs électriques disposant d'une interface numérique (RS232/RS485/Modbus/Zigbee) offrent cette possibilité.

  Il est pire si l'appareil peut simplement mesurer un certain paramètre instantané (par exemple, la puissance instantanée ou le courant), ou générer des impulsions toutes les X watts-heure ou litres. Dans ce cas, il faut réfléchir à comment et avec quoi l'intégrer et où stocker la valeur. Il existe un risque de manquer un rapport pour une raison quelconque, et la précision du système en général soulève des questions. Bien sûr, on peut tout confier à un système de maison intelligente comme Home Assistant, mais le point concernant le nombre d'enregistrements dans la base n'est pas à ignorer, et il n'est pas possible de sonder les capteurs plus d'une fois par seconde (restriction de l'architecture de Home Assistant).

Approche 1

Commençons par voir ce que Home Assistant propose par défaut. La mesure de la consommation sur une période est une fonctionnalité très demandée. Évidemment, cela a été réalisé depuis longtemps sous la forme d'un composant spécialisé : utility_meter.

Le principe du composant est qu'il crée en interne une variable current_accumulated_value, et la réinitialise à l'expiration de la période définie (heure/semaine/mois). Le composant surveille lui-même la variable d'entrée (la valeur d'un capteur quelconque), s'abonne aux changements de valeur - vous obtenez simplement le résultat final. C'est décrit en quelques lignes dans le fichier de configuration.

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

Ici, sensor.water_meter_cold est la valeur actuelle du compteur en litres, que je reçois directement de l'appareil via MQTT. La structure crée 2 nouveaux capteurs water_cold_hour_um et water_cold_day_um, qui accumulent les lectures horaires et journalières, les réinitialisant à l'expiration de la période. Voici le graphique de l'accumulateur horaire pour une demi-journée.

Le code des graphiques horaire et journalier pour l'interface Lovelace ressemble à ceci :

      - type: history-graph
        title: 'Consommation d'eau horaire utilisant des variables'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Consommation d'eau quotidienne utilisant des variables'
        hours_to_show: 360
        entities:
          - sensor.water_day

En réalité, c'est dans cet algorithme que réside le problème de cette approche. Comme je l'ai déjà mentionné, pour chaque valeur d'entrée (la lecture actuelle du compteur pour chaque litre suivant), 1 Ko d'enregistrement est généré dans la base. Chaque compteur utilitaire génère également une nouvelle valeur qui s'ajoute à la base. Si je veux collecter des relevés horaires/journaliers/hebdomadaires/mensuels, et ce pour plusieurs colonnes d'eau, tout en ajoutant une pile de compteurs électriques — cela va générer une quantité énorme de données. En réalité, les données ne sont pas très nombreuses, mais puisque l'assistant domestique écrit une quantité d'informations superflues dans la base, la taille de celle-ci va croître de manière exponentielle. J'ose même pas estimer la taille de la base pour des graphiques hebdomadaires et mensuels.

De plus, le compteur utilitaire ne résout pas le problème posé. Le graphique des valeurs fournies par le compteur utilitaire est une fonction constamment croissante qui est réinitialisée à 0 chaque heure. Nous avons besoin d'un graphique de consommation compréhensible pour l'utilisateur, montrant combien de litres ont été consommés sur une période donnée. Le composant standard history-graph n'est pas capable de cela, mais un composant externe comme mini-graph-card pourrait nous aider.

Voici le code de la carte pour lovelace-UI :

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_hour_um
        group_by: hour
        hours_to_show: 48
        name: "Consommation d'eau horaire agrégée par compteur utilitaire"
        points_per_hour: 1
        show:
          graph: bar
        type: 'custom:mini-graph-card'

En plus des paramètres standard comme le nom du capteur, le type de graphique, la couleur (je n'ai pas aimé l'orange standard), il est important de noter 3 réglages :

• group_by:hour — le graphique sera généré en alignant les barres au début de l'heure
• points_per_hour: 1 — une barre pour chaque heure
• Et le plus important, aggregate_func: max — prendre la valeur maximale dans chaque heure. C'est ce paramètre qui transforme le graphique en dents de scie en barres.

Ne vous inquiétez pas pour les barres sur la gauche — c'est le comportement standard du composant s'il n'y a pas de données. Et il n'y avait pas de données — je n'ai commencé à collecter les données via le compteur utilitaire que quelques heures avant cet article (je vous parlerai de mon approche actuelle un peu plus bas).

Sur cette image, je voulais montrer que parfois l'affichage des données fonctionne, et que les barres reflètent réellement les bonnes valeurs. Cependant, ce n'est pas le cas pour tout. La barre sur la période de 11h à 12h affiche inexplicablement 19 litres, alors que sur le graphique dentelé juste au-dessus pour la même période provenant du même capteur, nous voyons une consommation de 62 litres. Soit c'est un bug, soit la manipulation est défectueuse. Je ne comprends pas encore pourquoi les données de droite ont été perdues — la consommation y était normale, comme le montre également le graphique dentelé.

Globalement, je n'ai pas réussi à obtenir la crédibilité de cette approche — le graphique montre presque toujours des absurdités.

Code similaire pour le capteur quotidien.

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_day_um
        group_by: interval
        hours_to_show: 360
        name: "Consommation d'eau quotidienne agrégée par compteur de service"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Notez que le paramètre group_by est défini sur interval, et c'est le paramètre points_per_hour qui en dépend. Et c'est là qu'est un autre problème de ce composant — points_per_hour fonctionne bien sur les graphiques d'une heure ou moins, mais est horrible sur des intervalles plus longs. Pour obtenir une barre pour une journée, il a fallu entrer la valeur 1/24=0.04166666. Je ne parle même pas des graphiques hebdomadaires et mensuels.

Approche 2

Alors que je commençais à comprendre l'assistant domestique, je suis tombé sur cette vidéo :

Un camarade collecte des données de consommation de plusieurs types de prises Xiaomi. Sa tâche est un peu plus simple — il s'agit simplement d'afficher la valeur de consommation pour aujourd'hui, hier et pour le mois. Aucun graphique n'est requis.

Mettons de côté les réflexions sur l'intégration manuelle des valeurs instantanées de puissance — j'ai déjà écrit ci-dessus sur la 'précision' de cette approche. Il n'est pas clair pourquoi il n'a pas utilisé les valeurs accumulées de consommation, qui sont déjà collectées par la même prise. À mon avis, l'intégration à l'intérieur du matériel fonctionnera mieux.

Nous allons prendre de la vidéo l'idée du calcul manuel de la consommation sur une période. L'homme ne compte que les valeurs d'aujourd'hui et d'hier, mais nous irons plus loin et essayerons de dessiner un graphique. L'essence de la méthode proposée dans mon cas est la suivante.

Nous allons créer une variable valeur_au_début_de_l_heure, dans laquelle nous enregistrerons les relevés actuels du compteur.
À la fin de chaque heure (ou au début de la suivante), nous allons calculer la différence entre la lecture actuelle et celle mémorisée au début de l'heure. Cette différence correspondra à la consommation pour l'heure en cours — nous allons enregistrer cette valeur dans le capteur et dans le futur, nous allons construire un graphique basé sur cette valeur.
Il est également nécessaire de "réinitialiser" la variable valeur_au_début_de_l'heure en y écrivant la valeur actuelle du compteur.

Tout cela peut être réalisé grâce aux moyens fournis par home assistant.

Nous devrons écrire un peu plus de code que dans l'approche précédente. Pour commencer, créons ces "variables". Par défaut, nous n'avons pas d'entité "variable", mais nous pouvons utiliser les services du broker mqtt. Nous allons y envoyer des valeurs avec le drapeau retain=true — cela conservera la valeur à l'intérieur du broker, et il sera possible de l'extraire à tout moment, même après un redémarrage de home assistant. J'ai immédiatement créé des compteurs horaires et journaliers.

- 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

Toute la magie se produit dans l'automatisation, qui s'active chaque heure et chaque nuit respectivement.

- 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

Les deux automatisations effectuent 2 actions :

• Elles calculent la valeur pour l'intervalle en prenant la différence entre la valeur de départ et celle de fin.
• Elles mettent à jour la valeur de base pour le prochain intervalle.

La construction de graphiques se fait ici avec un history-graph ordinaire :

      - type: history-graph
        title: 'Consommation d'eau horaire utilisant des variables'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Consommation d'eau quotidienne utilisant des variables'
        hours_to_show: 360
        entities:
          - sensor.water_day

Cela ressemble à ceci :

En principe, c'est déjà ce dont nous avons besoin. L'avantage de cette méthode est que les données sont générées une seule fois par intervalle. C'est-à-dire au maximum 24 enregistrements par jour pour le graphique horaire.

Malheureusement, cela ne résout toujours pas le problème général de la base de données croissante. Si je veux un graphique de la consommation mensuelle, je vais devoir stocker des données pendant au moins un an. Étant donné que Home Assistant ne propose qu'un seul paramètre de durée de conservation pour toute la base, cela signifie que TOUTES les données du système devront être conservées pendant une année entière. Par exemple, au cours de l'année, je consomme 200 mètres cubes d'eau, ce qui équivaut à 200000 enregistrements dans la base. Et si l'on considère d'autres capteurs, ce chiffre devient vraiment indécent.

Approche 3

Heureusement, des personnes intelligentes ont déjà résolu ce problème en écrivant la base de données InfluxDB. Cette base est spécialement optimisée pour le stockage de données temporelles et convient parfaitement à la conservation des valeurs de différents capteurs. Le système propose également un langage de requête similaire à SQL, qui permet d'extraire des valeurs de la base, puis de les agréger de différentes manières. Enfin, on peut conserver différentes données pendant des périodes différentes. Par exemple, des mesures qui changent fréquemment, comme la température ou l'humidité, peuvent être stockées pendant seulement quelques semaines, alors que les relevés quotidiens de consommation d'eau peuvent être conservés pendant un an entier.

En plus d'InfluxDB, des personnes intelligentes ont également inventé Grafana — un système de création de graphiques à partir des données d'InfluxDB. Grafana peut créer différents types de graphiques, les personnaliser en détail, et, surtout, ces graphiques peuvent être 'intégrés' dans l'interface Lovelace de Home Assistant.

S'inspirer de ici et ici. Les articles décrivent en détail le processus d'installation et de connexion d'InfluxDB et de Grafana à Home Assistant. Quant à moi, je vais me concentrer sur la résolution de mon problème spécifique.

Alors, tout d'abord, nous allons commencer par enregistrer la valeur du compteur dans InfluxDB. Voici un extrait de la configuration de Home Assistant (dans cet exemple, je vais m'amuser avec de l'eau froide et chaude) :

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

Nous allons désactiver la sauvegarde de ces mêmes données dans la base interne de Home Assistant, afin de ne pas l'encombrer inutilement :

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

Passons maintenant à la console InfluxDB et configurons notre base de données. En particulier, il est nécessaire de définir combien de temps certaines données seront conservées. Cela est régulé par la politique de conservation, qui est similaire à des bases de données à l'intérieur de la base de données principale, chaque base interne ayant ses propres paramètres. Par défaut, toutes les données sont stockées dans la politique de conservation appelée autogen, ces données seront conservées pendant une semaine. Je voudrais que les données horaires soient conservées un mois, hebdomadaires - un an, et que les mensuelles ne soient jamais supprimées. Créons les politiques de conservation correspondantes.

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

Maintenant, le principal tour de magie - l'agrégation des données à l'aide d'une requête continue. C'est un mécanisme qui exécute automatiquement une requête à intervalles réguliers, agrège les données selon cette requête et stocke le résultat dans une nouvelle valeur. Démontrons-le avec un exemple (j'écris en colonne pour la lisibilité, mais en réalité, j'ai dû entrer cette commande sur une seule ligne).

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

Cette commande :

• Crée une requête continue nommée cq_water_cold_hourly dans la base homeassistant.
• La requête sera exécutée chaque heure (time(1h)).
• La requête récupérera toutes les données de la mesure homeassistant.autogen.l (litres), y compris les relevés d'eau froide et chaude.
• Les données agrégées seront regroupées par entity_id, ce qui nous donnera des valeurs distinctes pour l'eau froide et l'eau chaude.
• Étant donné que le compteur de litres est une séquence monotone croissante, dans le cadre de chaque heure, il faudra prendre la valeur maximale, donc l'agrégation se fera avec la fonction max(value).
• La nouvelle valeur sera enregistrée dans homeassistant.month.water_meter_hour, où month est le nom de la politique de conservation avec une période de stockage d'un mois. Les données d'eau froide et chaude seront réparties dans des enregistrements distincts avec les entity_id correspondants et les valeurs dans le champ value.

La nuit ou lorsque personne n'est à la maison, il n'y a pas de consommation d'eau, et donc pas de nouvelles entrées dans homeassistant.autogen.l non plus. Pour éviter des valeurs manquantes dans les requêtes normales, vous pouvez utiliser fill(previous). Cela forcera InfluxDB à utiliser la valeur de l'heure précédente.

Malheureusement, la requête continue a une particularité : le truc fill(previous) ne fonctionne pas et les enregistrements ne sont tout simplement pas créés. Il s'agit d'un problème apparemment insurmontable, qui est discuté depuis plusieurs années déjà.. Nous aborderons ce problème plus tard, et pour le moment, la fonction fill(previous) dans la requête continue pourra rester — elle ne gêne pas.

Vérifions ce que nous avons obtenu (bien sûr, il faut attendre quelques heures) :

> 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

Notez que les valeurs dans la base sont enregistrées en UTC, donc dans cette liste, elles diffèrent de 3 heures — les valeurs à 7 heures du matin dans le rendu InfluxDB correspondent aux valeurs à 10 heures du matin sur les graphiques ci-dessus. Notez également qu'il n'y a tout simplement pas d'enregistrements entre 2 et 5 heures — c'est cette même particularité de la requête continue.

Comme vous pouvez le voir, la valeur agrégée est également une séquence croissante monotone, les enregistrements étant seulement moins fréquents — une fois par heure. Mais ce n'est pas un problème — nous pouvons écrire une autre requête qui extraira les bonnes données pour le graphique.

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)

Je vais clarifier :

• Nous allons extraire les données de la base homeassistant.month.water_meter_hour pour entity_id='water_meter_cold' au cours des dernières 24 heures (time >= now() -24h).
• Comme je l'ai déjà mentionné, il peut manquer certains enregistrements dans la séquence homeassistant.month.water_meter_hour. Nous allons régénérer ces données en lançant une requête avec GROUP BY time(1h). Cette fois, fill(previous) fonctionnera comme il se doit, en générant les données manquantes (la fonction prendra la valeur précédente).
• L'élément le plus important dans cette requête est la fonction difference, qui calculera la différence entre les horodatages horaires. Elle ne fonctionne pas seule et nécessite une fonction d'agrégation. Cela sera max() utilisée auparavant.

Le résultat d'exécution est le suivant :

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

De 2 à 5 heures du matin (UTC), il n'y a eu aucune consommation. Cependant, la requête renverra la même valeur de consommation grâce à fill(previous), et la fonction difference soustraira cette valeur d'elle-même, ce qui nous donnera 0, ce qui est justement ce qui est requis.

Il ne reste plus qu'à construire le graphique. Pour cela, ouvrons Grafana, prenons un tableau de bord existant (ou créons-en un nouveau), puis créons un nouveau panneau. Les paramètres des graphiques seront les suivants.

Je vais afficher les données sur l'eau froide et chaude sur un seul graphique. La requête est exactement celle que j'ai décrite ci-dessus.

Les paramètres d'affichage sont définis comme suit. Pour moi, ce sera un graphique à lignes (lines), qui sera en escalier (stairs). Je vais expliquer le paramètre Stack un peu plus bas. Il y a encore quelques paramètres d'affichage en dessous, mais ils ne sont pas aussi intéressants.

Pour ajouter le graphique obtenu à l'assistant maison, il faut :

• sortir du mode d'édition du graphique. Étrangement, les paramètres corrects de partage des graphiques ne sont proposés que depuis la page du tableau de bord.
• Cliquer sur le triangle à côté du nom du graphique, puis dans le menu, choisir partager.
• Dans la fenêtre qui s'ouvre, aller à l'onglet embarquer.
• Désélectionner la case current time range — la plage horaire sera définie via l'URL.
• Choisir le thème nécessaire. Dans mon cas, c'est clair.
• Copier l'URL obtenue dans la carte de paramètres 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"

Notez que la plage horaire (les 2 derniers jours) est définie ici, et non dans les paramètres du tableau de bord.

Le graphique ressemble à ça. Je n'ai pas utilisé d'eau chaude au cours des 2 derniers jours, donc seul le graphique de l'eau froide est affiché.

Je n'ai pas encore décidé quel graphique je préfère, celui en escalier ou les vrais barres. Par conséquent, je vais juste donner un exemple d'un graphique de consommation quotidienne, mais cette fois avec des barres. Les requêtes sont construites de manière similaire à celles décrites ci-dessus. Les paramètres d'affichage sont les suivants :

Ce graphique ressemble à ça :

À propos du paramètre Stack. Dans ce graphique, la barre d'eau froide est dessinée au-dessus de celle d'eau chaude. La hauteur totale correspond à la consommation totale d'eau froide et chaude pour la période.

Tous les graphiques affichés sont dynamiques. Vous pouvez passer la souris sur un point d'intérêt et voir les détails et la valeur à un point précis.

Malheureusement, il y a eu quelques points négatifs. Dans le graphique à barres (contrairement au graphique à lignes en escalier), le milieu de la barre ne se situe pas au milieu de la journée, mais à 00h00. Autrement dit, la moitié gauche de la barre est dessinée à la place du jour précédent. Les graphiques pour samedi et dimanche sont donc légèrement décalés vers la gauche par rapport à la zone bleutée. Je n'ai pas encore trouvé comment y remédier.

Un autre problème réside dans l'impossibilité de travailler correctement avec des intervalles mensuels. En fait, la durée de l'heure / du jour / de la semaine est fixe, tandis que la durée du mois varie à chaque fois. InfluxDB ne peut travailler qu'avec des intervalles identiques. Pour l'instant, j'ai trouvé le moyen de définir un intervalle fixe de 30 jours. Oui, le graphique va un peu dériver au cours de l'année et les barres ne correspondra pas tout à fait aux mois. Mais comme cette fonctionnalité m'intéresse juste à titre d'indicateur, cela me convient.

Je vois au moins deux solutions :

• Abandonner les graphiques mensuels et se limiter aux hebdomadaires. 52 barres hebdomadaires par an se présentent plutôt bien.
• Considérer la consommation mensuelle comme méthode n°2, et utiliser Grafana uniquement pour de beaux graphiques. Cela donnera une solution assez précise. On peut même superposer les graphiques de l'année précédente pour comparaison — Grafana sait le faire.

Conclusion

Je ne sais pas pourquoi, mais j'adore ce genre de graphiques. Ils montrent que la vie bouillonne et que tout change. Hier il y avait beaucoup, aujourd'hui peu, et demain sera encore différent. Il reste à travailler avec les membres du ménage sur le sujet de la consommation. Mais même avec les appétits actuels, un chiffre simplement grand et incompréhensible sur la facture devient déjà un tableau de consommation assez clair.

Malgré presque 20 ans de carrière en tant que programmeur, je n'ai pratiquement pas eu de contacts avec les bases de données. C'est pourquoi l'installation d'une base de données externe me semblait quelque chose de follement complexe et inconnu. Tout a changé l'article mentionné ci-dessus — il s'est avéré que la connexion d'un outil approprié se fait en quelques clics, et avec un outil spécialisé, la tâche de construction de graphiques devient un peu plus simple.

Dans le titre, j'ai mentionné la consommation d'électricité. Malheureusement, je ne peux pas fournir de graphiques pour le moment. Un compteur SDM120 est tombé en panne, et l'autre fonctionne mal lors de l'accès via Modbus. Cela dit, cela n'a aucune incidence sur le sujet de cet article : les graphiques seront construits de la même manière que pour l'eau.

Dans cet article, j'ai présenté les approches que j'ai expérimentées moi-même. Il existe sûrement d'autres méthodes pour organiser la collecte et la visualisation des données dont je ne suis pas au courant. N'hésitez pas à m'en parler dans les commentaires, cela m'intéressera beaucoup. Je serai ravi des critiques constructives et des nouvelles idées. J'espère que le matériel exposé pourra également aider quelqu'un.

Source : habr.com