💟 🎇 🔘 Maison intelligente: création de tableaux d'eau et d'électricité dans Home Assistant 👴🏿 🔐 🆓

Chaque fois que je reçois une facture d'électricité et d'eau, je me demande - ma famille consomme-t-elle vraiment autant? Eh bien, oui, la salle de bain a un plancher chauffant et une chaudière, mais ils ne s’alimentent pas constamment. Nous semblons également économiser de l'eau (même si nous aimons aussi les éclaboussures dans la salle de bain). Il y a quelques années, j'avais déjà connecté des compteurs d'eau et d' électricité à une maison intelligente, mais c'était collé là-dessus. Les mains ne sont arrivées à l'analyse de la consommation que maintenant, à propos de laquelle, en fait, cet article concerne.

Je suis récemment passé à Home Assistant en tant que 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 avec des sauces différentes 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 appropriée. L'article ne fournit toujours pas d'informations complètes sur la collecte de données, mais c'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, l'objectif de l'exercice d'aujourd'hui est d'obtenir de beaux graphiques de consommation d'eau et d'électricité:

Toutes les heures pendant 2 jours
Tous les jours pendant 2 semaines
(facultatif) hebdomadaire et mensuel

C'est là que quelques difficultés nous attendent:

, , . .

, , . 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

Tout d'abord, voyons ce que l'assistant à domicile est fourni hors de la boîte. Mesurer la consommation sur une période est une fonctionnalité très demandée. Bien sûr, il a été réalisé il y a longtemps sous la forme d'un 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'une sorte de capteur), souscrit 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 directement de la pièce de fer par mqtt. La conception crée 2 nouveaux capteurs water_cold_hour_um et water_cold_day_um, qui accumulent des lectures horaires et quotidiennes, les réinitialisant après une période. Voici un tableau de batterie d'une demi-heure.

Le code du 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, le problème de cette approche réside dans cet algorithme. Comme je l'ai 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 de données. Chaque compteur d'utilité génère également une nouvelle valeur, qui s'ajoute également à la base de données. Si je veux collecter des relevés horaires / quotidiens / hebdomadaires / mensuels, et pour plusieurs élévateurs à eau, et même ajouter un tas 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 dans la base de données un tas d'informations inutiles, 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 des graphiques hebdomadaires et mensuels.

De plus, le compteur d'utilité seul ne résout pas la tâche. Le graphique des valeurs que le compteur d'utilité donne est une fonction augmentant de façon monotone qui se remet à 0 toutes les heures. Nous avons besoin d'un tableau de consommation convivial, combien de litres ont été consommés au cours de la période. Le composant standard de graphique d'historique ne sait pas comment procéder, mais le composant de mini-carte graphique externe 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 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 paramètres:

group_by: hour - le graphique sera généré avec les colonnes alignées au début de l'heure
points_per_hour: 1 - une barre pour chaque heure
, aggregate_func: max — .

Ne faites pas attention à un certain nombre de colonnes sur la gauche - c'est le comportement standard d'un composant s'il n'y a pas de données. Et il n'y avait pas de données - j'ai seulement activé la collecte de données des compteurs d'utilité il y a quelques heures seulement pour le plaisir de cet article (je vous dirai mon approche actuelle un peu plus tard).

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. La colonne sélectionnée pour l'intervalle de 11 à 12 heures du matin pour une raison quelconque affiche 19 litres, bien que sur le tableau à pleines dents un peu plus élevé pour la même période, nous voyons une consommation de 62 litres à partir du même capteur. Soit un insecte, soit des mains tordues. Mais je ne comprends pas pourquoi les données de droite se sont interrompues - la consommation y était normale, ce qui est également visible sur le calendrier à pleines dents.

En général, je n'ai pas réussi à obtenir la crédibilité de cette approche - le graphique montre presque toujours une sorte d'hérésie.

Le même code pour le capteur de jour.

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

Notez que le paramètre group_by est défini sur intervalle et que le paramètre points_per_hour règle tout. Et c'est un autre problème de ce composant - points_per_hour fonctionne bien sur les graphiques en une heure ou moins, mais dégoûtant à de grands intervalles. Donc, pour obtenir une colonne en une journée, je devais entrer la valeur 1/24 = 0,04166666. Je ne parle pas de graphiques hebdomadaires et mensuels.

Approche 2

Je viens de découvrir l'assistant à domicile, je suis tombé sur cette vidéo ici:

Un ami recueille les données de consommation de plusieurs types de points de vente Xiaomi. Sa tâche est un peu plus facile - il suffit d'afficher la valeur de la consommation pour aujourd'hui, hier et pour le mois. Aucun horaire n'est requis.

Laissons de côté la discussion sur l'intégration manuelle des valeurs de puissance instantanées - j'ai déjà écrit sur la «précision» de cette approche. On ne sait pas pourquoi il n'a pas utilisé les valeurs de consommation accumulées, qui sont déjà collectées par le même point de vente. À mon avis, l'intégration à l'intérieur du morceau de fer fonctionnera mieux.

De la vidéo nous prenons l'idée de calculer manuellement la consommation de la période. Le paysan ne compte que les valeurs d'aujourd'hui et d'hier, mais nous allons aller plus loin et essayer de dessiner un graphique. L'essence de la méthode proposée dans mon cas est la suivante.

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

Tout cela peut être fait ~~par le~~ biais de l'assistant à domicile lui-même.

Vous devrez écrire un peu plus de code que dans l'approche précédente. Pour commencer, obtenons ces mêmes «variables». Hors de la boîte, nous n'avons pas l'entité "variable", mais vous pouvez utiliser les services du courtier mqtt. Nous y enverrons des valeurs avec le drapeau retenue = vrai - cela enregistrera la valeur à l'intérieur du courtier, et vous pouvez la retirer à tout moment, même lorsque l'assistant à domicile redémarre. J'ai fait tout de suite des compteurs d'heures et de jours.

- 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 opère dans l'automatisation, qui s'exécute 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:

La valeur de l'intervalle est calculée comme la différence entre la valeur de début et la valeur de fin
Mettre à jour la valeur de base pour l'intervalle suivant

Le graphique dans ce cas est résolu par le graphique 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_day

Cela 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. seulement 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 calendrier de consommation mensuel, je devrai stocker des données pendant au moins un an. Et comme l'assistant à domicile ne fournit qu'un seul paramètre pour la 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, pendant un an, je consomme 200 mètres cubes d'eau, ce qui signifie que ce sont 200 000 enregistrements dans la base de données. Et si vous prenez en compte d'autres capteurs, le chiffre devient indécent du tout.

Approche 3

Heureusement, les 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 de sélectionner des valeurs dans la base de données, puis de les agréger de différentes manières. Enfin, différentes données peuvent être stockées à différents moments. Par exemple, les relevés changeant fréquemment tels que la température ou l'humidité peuvent être stockés pendant seulement quelques semaines, tandis que les relevés quotidiens de la consommation d'eau peuvent être stockés pendant une année entière.

En plus d'InfluxDB, les gens intelligents ont également inventé Grafana, un système de cartographie basé sur les 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 «collés» sur l'assistant à domicile lovelace-UI.

Inspirez-vous ici et ici . 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 à additionner 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_cold

Désactivez l'enregistrement des mêmes données dans la base de données interne de l'assistant à domicile afin de ne pas les gonfler à nouveau:

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

Nous allons maintenant à la console InfluxDB et configurons notre base de données. En particulier, vous devez configurer la durée de stockage de telle ou telle donnée. Ceci est réglementé par le soi-disant politique de rétention - elle est 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 stockées dans une 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, l'hebdomadaire pendant un an et que le mensuel ne soit jamais supprimé. Créer une politique de rétention appropriée

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, 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 démarre 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 fait j'ai dû saisir 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 de données homeassistant
La demande sera exécutée toutes les heures (temps (1h))
La demande va récupérer 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.
, max(value)
homeassistant.month.water_meter_hour, month retention policy . entity_id value

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

Malheureusement, la requête continue a une particularité: l'astuce de remplissage (précédente) ne fonctionne pas et les enregistrements ne sont tout simplement pas créés. De plus, il s'agit d'un problème insurmontable qui fait l'objet de discussions depuis plus d'un an . Nous traiterons ce problème plus tard, et laissons 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

Veuillez noter que les valeurs de la base de données sont stockées en UTC, par conséquent, dans cette liste, elles diffèrent de 3 heures - les valeurs de 7 h dans la sortie InfluxDB correspondent aux valeurs de 10 h 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 même caractéristique de la requête continue.

Comme vous pouvez le voir, la valeur agrégée est également une séquence à augmentation monotone, seuls les enregistrements sont moins fréquents - une fois par heure. Mais ce n'est pas un problème - nous pouvons écrire une autre requête qui produira 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 extrayons les données pour entity_id = 'water_meter_cold' pour le dernier jour (heure> = maintenant () -24h).
Comme je l'ai mentionné dans la séquence homeassistant.month.water_meter_hour, certaines entrées peuvent être manquantes. Nous régénérerons ces données en exécutant une requête avec l'heure GROUP BY (1h). Ce remplissage de temps (précédent) fonctionnera selon les besoins, générant les données manquantes (la fonction prendra la valeur précédente)
La chose la plus importante dans cette demande est la fonction de différence, qui calculera la différence entre les marques horaires. En soi, il 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 72

De 2 à 5 heures du matin (UTC), il n'y avait pas de consommation. Néanmoins, la requête renverra la même valeur de consommation en raison du remplissage (précédent), et la fonction de différence soustraira cette valeur d'elle-même et obtiendra 0 à la sortie, ce qui est réellement requis.

Il ne reste plus qu'à construire un planning. 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 comme ceci.

Je vais afficher les données sur l'eau froide et chaude sur un graphique. La demande est exactement la même que celle décrite ci-dessus.

Les paramètres d'affichage sont définis comme suit. J'aurai un graphique avec des lignes, qui passe par des escaliers. Je vais expliquer le paramètre Stack juste en dessous. Il y a quelques autres options d'affichage ci-dessous, mais elles ne sont pas si intéressantes.

Pour ajouter le programme reçu à l'assistant à domicile dont vous avez besoin:

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

Veuillez noter que la plage de temps (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 de l'eau froide est dessiné.

Je n'ai pas décidé par moi-même quel horaire je préfère, une ligne de pas ou de vrais bars. Par conséquent, je vais simplement donner un exemple de graphique de consommation quotidienne, mais cette fois en colonnes. Les demandes sont construites de la même manière que celle décrite ci-dessus. Les paramètres d'affichage sont les suivants:

Ce graphique ressemble à ceci:

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

Tous les graphiques présenté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 spécifique.

Malheureusement, quelques cuillères à soupe de goudron n'ont pas pu faire. Sur le graphique à barres (contrairement au graphique avec des lignes de pas), le milieu de la barre n'est pas au milieu de la journée, mais à 00h00. Ceux. la moitié gauche de la colonne est dessinée à la place de la veille. Les cartes du samedi et du dimanche sont donc un peu plus à gauche que la zone bleuâtre. Jusqu'à ce que je comprenne comment le gagner.

Un autre problème est l'incapacité de fonctionner correctement à 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'à intervalles réguliers. Jusqu'à présent, mon cerveau était suffisant pour définir un intervalle fixe de 30 jours. Oui, le graphique flottera un peu au cours de l'année et les colonnes ne correspondront pas exactement aux mois. Mais comme cette chose m'intéresse simplement en tant que périphérique d'affichage, je suis d'accord avec ça.

Je vois au moins deux solutions:

Score sur les horaires mensuels et limite hebdomadaire. 52 bars hebdomadaires pour l'année ont l'air plutôt bien
№2, . . — .

Je ne sais pas pourquoi, mais je marche sur ce genre de graphiques. Ils montrent que la vie bat son plein et que tout change. Hier, c'était beaucoup, aujourd'hui ne suffit pas, demain sera 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 le paiement se transforme déjà en une image assez claire de la consommation.

Malgré une carrière de programmeur de près de 20 ans, 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'abstrus et d'incompréhensible. Tout a été changé par l' article susmentionné - 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 graphique devient un peu plus facile.

Dans le titre, j'ai mentionné la consommation d'électricité. Malheureusement, pour le moment, je ne peux pas donner un seul graphique. Un compteur SDM120 est mort et l'autre est bogué lors de l'accès via Modbus. Cependant, cela n'affecte pas le sujet de cet article - les graphiques seront construits de la même manière que pour l'eau.

Dans cet article, j'ai cité les approches que j'ai moi-même essayées. Il y a sûrement d'autres façons d'organiser la collecte et la visualisation de données que je ne connais pas. Dites-le moi dans les commentaires, ça va être très intéressant pour moi. Je serai heureux de recevoir des critiques constructives et de nouvelles idées. J'espère que le matériel présenté aidera également quelqu'un.

Maison intelligente: création de tableaux d'eau et d'électricité dans Home Assistant

Formulation du problème

1

Approche 2

Approche 3

More articles: