Chaque fois que je reçois un paiement pour l'électricité et l'eau, je me demande : est-ce que ma famille consomme vraiment tellement ? Eh bien, oui, il y a un plancher chauffant et une chaudière dans la salle de bain, mais ils ne travaillent pas tout le temps comme pompiers. Nous semblons également économiser l'eau (même si nous aimons aussi éclabousser dans la salle de bain). Il y a quelques années, j'ai déjà и à une maison intelligente, mais c'est là que les choses se sont bloquées. Les mains n'ont atteint l'analyse de la consommation que maintenant, ce qui, en fait, est le sujet de cet article.
Je suis récemment passé à Home Assistant comme système de maison intelligente. L'une des raisons était simplement la possibilité d'organiser la collecte d'une grande quantité de données avec la possibilité de construire facilement différents types de graphiques.
Les informations décrites dans cet article ne sont pas nouvelles, toutes ces choses sous différentes sauces ont déjà été décrites sur Internet. Mais chaque article, en règle générale, ne décrit qu'une approche ou un aspect. J'ai dû comparer toutes ces approches et choisir moi-même la plus adaptée. L'article ne fournit toujours pas d'informations exhaustives sur la collecte de données, mais est une sorte de résumé de la façon dont je l'ai fait. Les critiques constructives et les suggestions d'amélioration sont donc les bienvenues.
Formulation du problème
Ainsi, le but de l'exercice d'aujourd'hui est d'obtenir de beaux graphiques de consommation d'eau et d'électricité :
- Horaire pendant 2 jours
- Tous les jours pendant 2 semaines
- (facultatif) hebdomadaire et mensuel
Il y a quelques difficultés à cela :
- Les composants graphiques standard ont tendance à être assez pauvres. Au mieux, vous pouvez construire un graphique linéaire par points.
Si vous recherchez bien, vous pouvez trouver des composants tiers qui étendent les capacités du graphique standard. Pour aide à domicile, en principe, un bon et beau composant , mais c'est aussi un peu limité :
- Il est difficile de définir les paramètres du graphique à barres à de grands intervalles (la largeur de la barre est définie en fractions d'heure, ce qui signifie que les intervalles supérieurs à une heure seront définis en nombres fractionnaires)
- Vous ne pouvez pas ajouter différentes entités à un graphique (par exemple, température et humidité, ou combiner un graphique à barres avec une ligne)
- Non seulement l'assistant à domicile utilise par défaut la base de données SQLite la plus primitive (et moi, le bricoleur, ne maîtrisais pas l'installation de MySQL ou de Postgres), les données ne sont pas stockées de la manière la plus optimale. Ainsi, par exemple, à chaque modification de chaque paramètre numérique, même le plus petit d'un paramètre, un énorme json d'environ un kilo-octet est écrit dans la base de données
{"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 pas mal de capteurs (capteurs de température dans chaque pièce, compteurs d'eau et d'électricité), et certains génèrent aussi pas mal de données. Par exemple, seul le compteur d'électricité SDM220 génère environ une douzaine de valeurs toutes les 10 à 15 secondes, et j'aimerais en installer 8. Et il y a aussi tout un tas de paramètres qui sont calculés sur la base d'autres capteurs. Ce. toutes ces valeurs peuvent facilement gonfler la base de données de 100 à 200 Mo par jour. Dans une semaine, le système tournera à peine et se retournera, et dans un mois, le lecteur flash mourra (dans le cas d'une installation typique d'assistant domestique sur raspberry PI), et il ne peut être question de stockage de données pendant une année entière.
- Si vous êtes chanceux, votre compteur lui-même peut compter la consommation. Vous pouvez contacter le compteur à tout moment et demander à quelle heure est la valeur de consommation cumulée. En règle générale, tous les compteurs d'électricité dotés d'une interface numérique (RS232/RS485/Modbus/Zigbee) offrent une telle possibilité.
Pire encore, si l'appareil peut simplement mesurer un paramètre instantané (par exemple, la puissance ou le courant instantané), ou simplement générer des impulsions tous les X wattheures ou litres. Ensuite, vous devez réfléchir à comment et avec quoi l'intégrer et où accumuler de la valeur. Il y a un risque de manquer le prochain rapport pour une raison quelconque, et l'exactitude du système dans son ensemble soulève des questions. Vous pouvez, bien sûr, confier tout cela à un système de maison intelligente comme home assistant, mais personne n'a annulé le point sur le nombre d'entrées dans la base de données, et l'interrogation des capteurs plus d'une fois par seconde ne fonctionnera pas (une limitation du architecture d'aide à domicile).
Approche 1
Voyons d'abord quel assistant à domicile est fourni prêt à l'emploi. Mesurer la consommation sur une période est une fonctionnalité très demandée. Bien sûr, il a été implémenté il y a longtemps en tant que composant spécialisé - utility_meter.
L'essence du composant est qu'il démarre la variable current_accumulated_value à l'intérieur et la réinitialise après une période spécifiée (heure/semaine/mois). Le composant lui-même surveille la variable entrante (la valeur d'un type de capteur), s'abonne aux modifications de la valeur elle-même - vous obtenez simplement le résultat final. Cette chose est décrite 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 j'obtiens par mqtt. La conception crée 2 nouveaux capteurs water_cold_hour_um et water_cold_day_um, qui accumulent les lectures horaires et quotidiennes, les remettant à zéro après une période. Voici un graphique de la batterie horaire pour une demi-journée.
Le code graphique horaire et quotidien pour lovelace-UI ressemble à ceci :
- 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
En fait, dans cet algorithme réside le problème de cette approche. Comme je l'ai déjà mentionné, pour chaque valeur entrante (le relevé actuel du compteur pour chaque litre suivant), 1 ko d'un enregistrement est généré dans la base de données. Chaque compteur génère également une nouvelle valeur, qui est également ajoutée à la base. Si je veux collecter des relevés horaires/journaliers/hebdomadaires/mensuels, oui, pour plusieurs colonnes montantes, et même ajouter un pack de compteurs électriques, ce sera beaucoup de données. Eh bien, plus précisément, il n'y a pas beaucoup de données, mais comme l'assistant à domicile écrit un tas d'informations inutiles dans la base de données, la taille de la base de données augmentera à pas de géant. J'ai même peur d'estimer la taille de la base pour les graphiques hebdomadaires et mensuels.
De plus, le compteur d'électricité lui-même ne résout pas le problème. Le tracé du compteur d'électricité est une fonction croissante monotone qui se réinitialise à 0 toutes les heures. Nous avons également besoin d'un calendrier de consommation convivial, indiquant combien de litres ont été consommés au cours de la période. Le composant standard de graphique d'historique ne fait pas cela, mais le composant externe de mini-carte graphique peut 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: "Hourly water consumption aggregated by utility meter"
points_per_hour: 1
show:
graph: bar
type: 'custom:mini-graph-card'En plus des réglages standards 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 ici :
- group_by:hour - le graphique sera généré avec des colonnes alignées sur le début de l'heure
- points_per_hour : 1 - une barre par heure
- Et le plus important,aggregation_func: max consiste à prendre la valeur maximale à chaque heure. C'est ce paramètre qui transforme le graphique en dents de scie en barres.
Ne faites pas attention à la rangée de colonnes à gauche - c'est le comportement standard du composant s'il n'y a pas de données. Mais il n'y avait pas de données - j'ai seulement activé la collecte de données à l'aide du compteur d'électricité il y a quelques heures juste pour les besoins de cet article (je décrirai mon approche actuelle un peu plus bas).
Dans cette image, je voulais montrer que parfois l'affichage des données fonctionne même et que les barres reflètent vraiment les valeurs correctes. Mais ce n'est pas tout. Pour une raison quelconque, la colonne en surbrillance pour la période de 11h à 12h affiche 19 litres, bien que sur le graphique à pleines dents un peu plus haut pour la même période du même capteur, nous voyons une consommation de 62 litres. Soit un bug ou les mains sont tordues. Mais je ne comprends toujours pas pourquoi les données de droite se sont interrompues - la consommation y était normale, ce qui est également visible sur le graphique à pleines dents.
En général, je n'ai pas réussi à atteindre la plausibilité de cette approche - le graphique montre presque toujours une sorte d'hérésie.
Code similaire pour le capteur diurne.
- 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'
Veuillez noter que le paramètre group_by est défini sur intervalle et que le paramètre points_per_hour régit tout. Et c'est un autre problème avec ce composant - points_per_hour fonctionne bien sur les graphiques d'une heure ou moins, mais dégoûtant sur des intervalles plus grands. Donc, pour obtenir une colonne en une journée, je devais entrer la valeur 1/24=0.04166666. Je ne parle pas des graphiques hebdomadaires et mensuels.
Approche 2
Alors que je cherchais encore l'assistant à domicile, je suis tombé sur cette vidéo :
Le camarade collecte les données de consommation de plusieurs types de prises Xiaomi. Sa tâche est un peu plus simple - il suffit d'afficher la valeur de la consommation d'aujourd'hui, d'hier et du mois. Aucun graphique requis.
Laissons de côté les arguments sur l'intégration manuelle des valeurs de puissance instantanées - j'ai déjà écrit sur la «précision» de cette approche ci-dessus. On ne sait pas pourquoi il n'a pas utilisé les valeurs de consommation cumulées, qui sont déjà collectées par le même point de vente. À mon avis, l'intégration à l'intérieur de la pièce de fer fonctionnera mieux.
De la vidéo, nous reprendrons l'idée de compter manuellement la consommation pendant une période. Pour un homme, seules les valeurs d'aujourd'hui et d'hier sont considérées, mais nous allons aller plus loin et essayer de tracer un graphique. L'essence de la méthode proposée dans mon cas est la suivante.
Nous allons créer une variable value_at_the_beginning_of_hour, dans laquelle nous écrirons les relevés de compteur actuels
Selon la minuterie à la fin de l'heure (ou au début de la suivante), nous calculons la différence entre la lecture actuelle et celle enregistrée au début de l'heure. Cette différence sera la consommation pour l'heure actuelle - nous enregistrerons la valeur dans le capteur et, à l'avenir, nous construirons un graphique basé sur cette valeur.
Vous devez également "réinitialiser" la variable value_at_beginning_of_hour en y écrivant la valeur actuelle du compteur.
Tout cela peut être bien fait ... au moyen de l'assistant à domicile lui-même.
Vous devrez écrire un peu plus de code que dans l'approche précédente. Commençons par ces "variables". Par défaut, nous n'avons pas l'entité "variable", mais vous pouvez utiliser les services d'un courtier mqtt. Nous y enverrons des valeurs avec l'indicateur retention=true - cela enregistrera la valeur à l'intérieur du courtier, et elle pourra être extraite à tout moment, même lorsque l'assistant domestique est redémarré. J'ai fait des compteurs horaires et journaliers à la fois.
- 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: lToute la magie se produit dans l'automatisation, qui fonctionne respectivement toutes les heures et toutes les nuits.
- 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: trueLes deux automatisations font 2 choses :
- Calculer la valeur par intervalle comme la différence entre la valeur de début et la valeur de fin
- Mettre à jour la valeur de base pour le prochain intervalle
La construction des graphes dans ce cas est résolue par le graphe historique habituel :
- 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_dayCela ressemble à ceci:
En principe, c'est déjà ce dont vous avez besoin. L'avantage de cette méthode est que les données sont générées une fois par intervalle. Ceux. un total de 24 entrées par jour pour le graphique horaire.
Malheureusement, cela ne résout toujours pas le problème général d'une base croissante. Si je veux un graphique de consommation mensuel, je devrai stocker les données pendant au moins un an. Et puisque l'assistant domestique ne fournit qu'un seul paramètre de durée de stockage pour l'ensemble de la base de données, cela signifie que TOUTES les données du système devront être stockées pendant une année entière. Par exemple, en un an, je consomme 200 mètres cubes d'eau, ce qui représente 200000 XNUMX entrées dans la base de données. Et si vous prenez en compte d'autres capteurs, le chiffre devient généralement 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 de données est spécialement optimisée pour stocker des données temporelles et est idéale pour stocker les valeurs de différents capteurs. Le système fournit également un langage de requête de type SQL qui vous permet d'extraire des valeurs de la base de données, puis de les agréger de différentes manières. Enfin, différentes données peuvent être stockées à des moments différents. Par exemple, les lectures changeant fréquemment telles que la température ou l'humidité peuvent être stockées pendant quelques semaines seulement, tandis que les lectures quotidiennes de la consommation d'eau peuvent être stockées pendant une année entière.
En plus d'InfluxDB, des personnes intelligentes ont également inventé Grafana, un système permettant de dessiner des graphiques à partir de données d'InfluxDB. Grafana peut dessiner différents types de graphiques, les personnaliser en détail et, plus important encore, ces graphiques peuvent être « branchés » sur l'assistant domestique lovelace-UI.
être inspiré и . Les articles décrivent en détail le processus d'installation et de connexion d'InfluxDB et de Grafana à l'assistant domestique. Je vais me concentrer sur la résolution de mon problème spécifique.
Donc, tout d'abord, commençons à ajouter la valeur du compteur dans influxDB. Un morceau de la configuration de l'assistant à domicile (dans cet exemple, je vais m'amuser non seulement avec du froid, mais aussi avec de l'eau chaude):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldDésactivons l'enregistrement des mêmes données dans la base de données interne de l'assistant à domicile, afin de ne pas la gonfler à nouveau :
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldPassons maintenant à la console InfluxDB et configurons notre base de données. En particulier, vous devez configurer la durée de stockage de certaines données. Ceci est réglementé par le soi-disant. politique de rétention - similaire aux bases de données à l'intérieur de la base de données principale, chaque base de données interne ayant ses propres paramètres. Par défaut, toutes les données sont ajoutées à la politique de rétention appelée autogen, ces données seront stockées pendant une semaine. Je souhaite que les données horaires soient stockées pendant un mois, les données hebdomadaires pendant un an et que les données mensuelles ne soient jamais supprimées du tout. Nous créerons des politiques de rétention appropriées
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 1Maintenant, en fait, l'astuce principale est l'agrégation de données à l'aide d'une requête continue. Il s'agit d'un mécanisme qui lance automatiquement une requête à des intervalles spécifiés, agrège les données de cette requête et ajoute le résultat à une nouvelle valeur. Regardons un exemple (j'écris dans une colonne pour plus de 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)
ENDCette commande :
- Crée une requête continue nommée cq_water_cold_hourly dans la base de données homeassistant
- La requête sera exécutée toutes les heures (time(1h))
- La requête extraira toutes les données de la mesure'a homeassistant.autogen.l (litres), y compris les lectures d'eau froide et chaude
- Les données agrégées seront regroupées par entity_id, ce qui créera des valeurs distinctes pour l'eau froide et l'eau chaude.
- Étant donné que le compteur de litres est une séquence croissante de manière monotone au cours de chaque heure, vous devrez prendre la valeur maximale, de sorte que l'agrégation sera effectuée par la fonction max(value)
- La nouvelle valeur sera écrite dans homeassistant.month.water_meter_hour où month est le nom de la politique de rétention avec une période de rétention d'un mois. De plus, les données sur l'eau froide et chaude seront dispersées dans des enregistrements séparés avec l'entity_id correspondant et la valeur dans le champ de valeur
La nuit ou lorsqu'il n'y a personne à la maison, il n'y a pas de consommation d'eau et, par conséquent, il n'y a pas non plus de nouveaux enregistrements dans homeassistant.autogen.l. Pour éviter les 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é : l'astuce de remplissage (précédent) ne fonctionne pas et les enregistrements ne sont tout simplement pas créés. De plus, il s'agit d'une sorte de problème insurmontable, qui . Nous traiterons ce problème plus tard, et laisserons remplir (précédent) dans la requête continue - cela n'interfère pas.
Vérifions ce qui s'est passé (bien sûr, vous devez 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 de la base de données sont stockées en UTC, donc cette liste diffère de 3 heures - les valeurs de 7h du matin dans la sortie InfluxDB correspondent aux valeurs de 10h du matin dans les graphiques ci-dessus. Notez également qu'entre 2 et 5 heures du matin, il n'y a tout simplement aucun enregistrement - c'est la caractéristique même de la requête continue.
Comme vous pouvez le voir, la valeur agrégée est également une séquence croissante de manière monotone, seules les entrées sont moins fréquentes - une fois par heure. Mais ce n'est pas un problème - nous pouvons écrire une autre requête qui extraira les données correctes 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 décrypterai:
- De la base de données homeassistant.month.water_meter_hour, nous extrairons les données pour entity_id='water_meter_cold' pour le dernier jour (time >= now() -24h).
- Comme je l'ai mentionné, certaines entrées peuvent être manquantes dans la séquence homeassistant.month.water_meter_hour. Nous allons régénérer ces données en exécutant la requête avec GROUP BY time(1h). Cette fois, fill(previous) fonctionnera correctement, générant les données manquantes (la fonction prendra la valeur précédente)
- La chose la plus importante dans cette requête est la fonction de différence, qui calculera la différence entre les marques d'heure. En soi, cela ne fonctionne pas et nécessite une fonction d'agrégation. Soit le max() utilisé auparavant.
Le résultat de l'exécution ressemble à ceci
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 72De 2h du matin à 5h du matin (UTC) il n'y a pas eu de consommation. Néanmoins, la requête retournera la même valeur de consommation grâce à fill(previous), et la fonction de différence se soustraira cette valeur et obtiendra 0 en sortie, ce qui est en fait nécessaire.
Il ne reste plus qu'à construire un graphique. Pour ce faire, ouvrez Grafana, ouvrez un tableau de bord existant (ou créez un nouveau), créez un nouveau panneau. Les paramètres du graphique seront les suivants.
J'afficherai les données d'eau froide et d'eau chaude sur le même graphique. La demande est exactement la même que celle décrite ci-dessus.
Les paramètres d'affichage sont définis comme suit. Pour moi, ce sera un graphique avec des lignes (lignes), qui va par étapes (escaliers). Le paramètre Stack sera expliqué ci-dessous. Il y a quelques autres options d'affichage ci-dessous, mais elles ne sont pas si intéressantes.
Pour ajouter le graphique résultant à l'assistant domestique, vous devez :
- quitter le mode d'édition du graphique. Pour une raison quelconque, les paramètres de partage de graphique corrects ne sont proposés qu'à partir de la page du tableau de bord
- Cliquez sur le triangle à côté du nom du graphique, sélectionnez partager dans le menu
- Dans la fenêtre qui s'ouvre, allez dans l'onglet embed
- Décochez la plage de temps actuelle - nous définirons la plage de temps via l'URL
- Sélectionnez le sujet requis. Chez moi c'est léger
- Copiez l'URL résultante 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"
Veuillez noter que la plage horaire (2 derniers jours) est définie ici, et non dans les paramètres du tableau de bord.
Le graphique ressemble à ceci. Je n'ai pas utilisé d'eau chaude au cours des 2 derniers jours, donc seul un graphique d'eau froide est dessiné.
Je n'ai pas décidé moi-même quel graphique je préfère, une ligne de progression ou de vraies barres. Je vais donc simplement donner un exemple de programme de consommation journalière, uniquement cette fois dans des bars. Les requêtes sont construites de la même manière que décrit ci-dessus. Les options d'affichage sont :
Ce graphique ressemble à ceci :
Donc, à propos du paramètre Stack. Dans ce graphique, une barre d'eau froide est dessinée au-dessus d'une barre chaude. La hauteur totale correspond à la consommation totale d'eau froide et d'eau chaude pour la période.
Tous les graphiques affichés sont dynamiques. Vous pouvez déplacer la souris sur le point d'intérêt et voir les détails et la valeur à un point particulier.
Malheureusement, ce n'était pas sans quelques mouches dans la soupe. Sur un graphique à barres (contrairement au graphique avec des lignes en escalier), le milieu de la barre n'est pas au milieu de la journée, mais à 00:00. Ceux. la moitié gauche de la barre est tracée à la place du jour précédent. Les graphiques de samedi et dimanche sont donc tracés un peu à gauche de la zone bleutée. Jusqu'à ce que je trouve comment le gagner.
Un autre problème est l'incapacité de travailler correctement avec des intervalles mensuels. Le fait est que la durée de l'heure/jour/semaine est fixe, mais la durée du mois est différente à chaque fois. InfluxDB ne peut fonctionner qu'avec des intervalles égaux. Jusqu'à présent, mon cerveau a suffi à fixer un intervalle fixe de 30 jours. Oui, le graphique flottera un peu au cours de l'année et les barres ne correspondront pas exactement aux mois. Mais puisque cette chose m'intéresse juste en tant que compteur d'affichage, je suis d'accord avec ça.
Je vois au moins deux solutions :
- Pour marquer sur des graphiques mensuels et vous limiter à des graphiques hebdomadaires. 52 barres hebdomadaires en un an ont l'air plutôt bien
- Considérez la consommation mensuelle elle-même comme la méthode n° 2, et n'utilisez le grafana que pour de beaux graphiques. C'est une solution assez précise. Vous pouvez même superposer les graphiques de l'année écoulée à des fins de comparaison - grafana peut le faire.
Conclusion
Je ne sais pas pourquoi, mais j'adore ce genre de graphiques. Ils montrent que la vie bat son plein et que tout change. Hier il y avait beaucoup, aujourd'hui il y a peu, demain il y aura autre chose. Reste à travailler avec les ménages sur le thème de la consommation. Mais même avec les appétits actuels, juste un chiffre important et incompréhensible dans la facture se transforme déjà en une image assez compréhensible de la consommation.
Malgré ma carrière de près de 20 ans en tant que programmeur, je n'ai pratiquement pas croisé les bases de données. Par conséquent, l'installation d'une base de données externe semblait quelque chose d'aussi abstrus et incompréhensible. Tout a changé - il s'est avéré que le vissage d'un outil approprié se fait en quelques clics, et avec un outil spécialisé, la tâche de traçage devient un peu plus facile.
Dans le titre, j'évoquais la consommation d'électricité. Malheureusement, pour le moment, je ne peux fournir aucun graphique. Un compteur SDM120 est mort et l'autre est bogué lorsqu'il est accessible via Modbus. Cependant, cela n'affecte en rien le sujet de cet article - les graphiques seront construits de la même manière que pour l'eau.
Dans cet article, j'ai donné ces approches que j'ai moi-même essayées. Il existe sûrement d'autres façons d'organiser la collecte et la visualisation des données que je ne connais pas. Parlez-en moi dans les commentaires, je serai très intéressé. Je serai heureux de critiques constructives et de nouvelles idées. J'espère que le matériel ci-dessus aidera également quelqu'un.
Source: habr.com