Externaliser son historique - Stockage long terme

Au niveau configuration, j’ai :

Un Pi 4 qui fait tourner HA Supervised.
Un VPS Debian mais ça peut être un autre Pi, un PC…

Je n’utilise pas d’add-on pour InfluxDB (ça existe d’ailleurs :thinking: ?). J’ai simplement mis le code suivant dans mon fichier configuration.yaml.

influxdb:
  host: adresseipdelamachinehebergeantinfluxdb
  database: lenomdemabasededonnees
  include:
    - ...
  exclude:
    - ...

J’ai installé Grafana sur la même machine que InfluxDB.

Après, oui la base de données est alimentée par Home Assistant et le noms des mesures est donc celui de HA. Si tu veux t’affranchir de ce nom et structurer ta base de données selon tes envies, tu peux passer par Node-RED pour aller lire tes sensors dans Home Assistant et les envoyer dans ta base de données avec le nom que tu veux. Je fais également cette manipulation pour un autre projet et ça fonctionne super bien.

Je suis sur smartphone…si tu veux plus de précisions, demande.

2 « J'aime »

Merci @Guillaume_B,
C’est exactement ce dont j’ai besoin.

Du coup je vais me pencher plus attentivement sur l’ensemble InfluxDB + Grafana sur un second raspberry dédié avec docker compose. Je renommerai effectivement les données avec Nodered avant injection dans InfluxDB afin de garder la main pour le futur.

Je posterai içi un exemple une fois ma solution fonctionelle si cela est pertinent pour vous.

Tu n’es pas obligé de passer par Docker. J’ai installé cette solution directement sur Debian. Ça fait une couche en moins.

Attention à l’installation d’InfluxDB, il y a la version 2.0 qui est sortie. Elle amène beaucoup de changement. Personnellement je suis resté sur version 1.8 :wink:

A l’occasion, je vais essayer de t’envoyer la fonction que j’utilise pour mettre en forme les données dans Node-RED avant l’insertion dans la DB.

1 « J'aime »

Merci c’est gentil !

Je vais me pencher dessus mais je pense que je partirai sur la dernière version si node-red est compatible avec. Cela m’évitera une migration :wink:

Pensez-vous qu’un raspberry pi 3 B+ soit suffisant pour au minimum faire un test ? Car j’ai prévu à Noël prochain d’investir dans un NUC donc je migrerai après.

C’est sur, mais docker est quand même préconisé pour les débutant.

Le simple fait de tout retrouver dans un seul et unique répertoire, le synchroniser sur un nas pour sauvegarde et se dire que si demain on change de machine, on a rien a faire a part reprendre son container et sa configuration (docker-compose aide la aussi).

1 « J'aime »

Il y a une super explication qui colle exactement avec mon besoin !

=> https://forum.hacf.fr/t/influxdb-aller-encore-plus-loin/3673?u=neuvidor!

Je suis d’accord pour docker car je veux être indépendant du hardware pour facilement évoluer ou simplement en cas d’un crash matériel.

Concernant HA je crée des Snapshots que je synchronise sur mon NAS chaque nuit. Trop eu de mauvaise surprise ! Donc je pense que j’aimerai faire la même chose avec influxDB et Grafana.

1 « J'aime »

@Guillaume_B, @Clemalex,
Au final j’ai mis en place une machine de test avec Proxmox.

J’ai mis 2 container LXC Ubuntu 21.04 pour respectivement Grafana et InfluxDB. J’ai aussi mis une machine virtuelle avec Home Assistant OS afin de faire fonctionner tous ceci ensemble et apprendre à gérer les backup correctement.

Encore merci pour vos conseils !

Hello,

Sinon, sans passer par Influx, tu peux également déporter ton recorder en dehors de ta machine HA.
Dans HA, on peut utiliser « MariaDB » comme recorder (via l’addon) qui install le gestionnaire de DB dans un container (dans le cas de HAOS). Ensuite il faut ajouter :

recorder:
  db_url: mysql://homeassistant:password@core-mariadb/homeassistant?charset=utf8mb4

Mais il est possible d’utiliser une URL externe qui pointe ton MySQL/MariaDB :

recorder:
  db_url: mysql://homeassistant:password@remoteipaddress/homeassistant?charset=utf8mb4

Il faut juste veiller à ce que cette DB soit accessible de l’extérieure.

Bonjour @Akinaria,

Merci pour l’info.

J’avais effectivement vu que ceci était faisable mais cela ne convient pas à mon besoin. Je souhaite stocker des années et des années d’historique.

Ceci concernant la partie recorder, d’après ce que j’ai lu ceci n’est pas fait pour historiser sur du long terme. Dans mon cas 7 jours est suffisant concernant l’historique HA. Ceci pour avoir des temps de chargement des graphiques acceptable.

J’effectue actuellement des tests sur mon proxmox, la manip en cours :

  • 1x Virtual Machine avec HomeAssistant OS
  • 1x container LXC avec UBUNTU 21.04 & NodeRed
  • 1x container LXC avec UBUNTU 21.04 & InfluxDB v2.0
  • 1x container LXC avec UBUNTU 21.04 & Grafana

Chaque élément est indépendamment sauvegardé. Ceci de façon régulière sur un NAS de façon automatique. Pour le moment j’arrive à récupérer les données de HA dans Nodered et à l’envoyer dans InfluxDB v2.0 (et non pas v1.8 afin de ne pas me taper une migration dans peu de temps).

Il me reste maintenant à utiliser les données InfluxDB dans Grafana.
Viendra ensuite le nettoyage quotidien de la base de données pour ne garder que les MIN / MAX / MOYENNE par jour pour l’historique de plus de 7 jours. Ceci afin de limiter la taille de la base de données sur le long terme.

Hello @Neuvidor,

Effectivement, la sauvegarde sur le long terme est un peu différente et l’utilisation d’influx est plus appropriée. J’y passerai certainement très prochainement après l’installation du monitorage des consommations (je reçu hier ma commande d’un shelly 3em pour cela).

Salut à tous,

Bon j’arrive maintenant à intégrer des anciennes données en forçant le timestamp dans nodered du coup la bonne nouvelle c’est que je vais pouvoir intégrer mes anciennes data et donc ne pas perdre mon historique. => 8 années quand meme !

Je vais cependant regarder si cela ne serait pas plus simple (ou plus rapide) d’intégrer un fichier CSV.

Mon idée étant :

  • Exporter mes anciennes données issuent de la base mySQL de DOMOTICZ vers un fichier CSV
  • Modification du CSV pour correspondre à 100% à l’architecture de ma nouvelle database InfluxDB
  • Importer le CSV modifié dans influxDB v2.0
1 « J'aime »

Si tu as un peu de temps je serais intéressé par ta methode complète.

Récupération des donnée via Node Red, formatage et envoi vers influx et nettoyage des valeurs ne servant plus apres X jours.

Merci d’avance

1 « J'aime »

Salut @McFly,

Comme j’ai dit à Pulpy hier, j’ai malheureusement du mettre un peu en pause le sujet (découverte des Cryptomonnaie et du potentiel de la technologie blockchain).

Je partagerai bien évidemment ma solution, c’est le but de la communauté, obtenir de l’aide mais également en fournir (quand on peut) :grin:

Hello la communauté !

Juste pour vous tenir au courant, j’ai pas mal avancé et j’ai maintenant une solution fonctionnelle. Il me reste maintenant à peaufiner quelques filtres dans Nodered pour éviter d’injecter des valeurs nulles par exemple.

Je ferai un tuto dédié à ça une fois terminé, dans l’attente je vous laisse voir mes précédents échanges :
https://forum.hacf.fr/t/influxdb-v1-8-x-aller-encore-plus-loin/3673/97?u=neuvidor

Pour résumé ma solution, je tourne sur Proxmox de cette façon :

2 « J'aime »

Bonjour,

Ma base de données commençant à atteindre une taille indécente je m’intéresse fortement à ce sujet. D’autant plus que je trouve l’idée d’externaliser son historique à un endroit non lié à notre système domotique très pratique si on pense au futur et que l’on ne veut pas tout perdre. Et pour ça, comme le fait remarquer @Neuvidor, il faut garder la main aussi sur le formatage de ses données.
Et c’est un peu là mon problème : comment récupérer les valeurs d’un capteurs dans Node-Red pour ensuite formater les données reçues avant de les envoyer vers InfluxDB ? Pour des capteurs remontant dans MQTT je n’ai pas de problème mais pour les capteurs remontant directement via une intégration dans Home Assistant ?
J’ai bien installer le noeud « node-red-contrib-home-assistant-websocket » dans Node-Red mais ensuite impossible de recevoir les valeurs en utilisant « current state » :

Est-ce que quelqu’un a déjà pu mettre en place cela ?

Salut

Petite nuance quand même. La taille importante est généralement plus liée à la quantité des données à court terme.
Ensuite pourquoi passer par nodered pour injecter dans influxdb ? Si c’est pour choisir les valeurs à externaliser : le recorder de base fait pareil. Si c’est pour avoir la main sur le format, en dehors d’un calcul le reste sera imposé par la méthode influx

1 « J'aime »

Salut,

en dehors de la stratégie d stockage long terme dont parle @Pulpy-Luke, ta question sur NodeRed m’interpelle :slight_smile:

Je ne sais pas si c’est juste une illustration ou si ton screenshot est le flux que tu essayes de faire marcher?
Car si c’est tout ton flux, c’est normal, « current state » n’est pas un trigger, il te faut quelque chose avant et les infos de ton entité seront lues au passage.

Le plus simple étant un « inject » qui permet de lancer à la main. Mais en général plutôt un « state changed » ou autre trigger.

2 « J'aime »

Personnellement je procède de la manière ci-dessous qui est certainement perfectible :

STEP 01 : Je déclenche le flow chaque minute comme ceci :

STEP 02 : Je lis les données provenant de HA comme ceci :

  • image

Avec pour définition du serveur HA ceci :

  • image

STEP 03 : J’ordonne mes données comme ceci :

STEP 04 : J’injecte les données dans InfluxDB comme ceci :

  • image

Avec pour définition du serveur InfluxBD ceci :

  • image

Ce qui donne dans InfluxDB :
=> Attention à l’affichage dans InfluxDB, car par défaut cela affiche une moyenne (agregate function)

STEP 05 : Je lis les données InfluxDB sous Grafana ce qui me permet d’obtenir ceci :

from(bucket: "home1_raw_data")
 |> range(start: -1d)
  |> filter(fn: (r) => r["_measurement"] == "kWh")
  |> filter(fn: (r) => r["entity_id"] == "linky_base")
  |> filter(fn: (r) => r["_field"] == "value")
  |> filter(fn: (r) => r["domain"] == "energie")
  |> filter(fn: (r) => r["instance"] == "prod")
  |> filter(fn: (r) => r["source"] == "capteur")
  |> drop(columns: ["domain", "instance", "source", "_start","_stop", "_field", "_measurement"])
  |> aggregateWindow(every: 1h, fn: spread, createEmpty: false)
|> group() 
|> pivot(rowKey:["_time"], columnKey: ["entity_id"], valueColumn: "_value")
2 « J'aime »

Salut !

Pour le coup je suis d’accord, je pense qu’il faudrait que tu fasses un peu de ménage et vérifier la config de ton recorder. Perso je ne garde que 2 jours d’historique.

Personnellement cela me permet de classer mes données avec les arguments et l’échantillonnage que je souhaite. Si je ne dis pas de bétise ce n’est pas possible via le recorder d’aller autant dans le détails.

1 « J'aime »

Oui ça apporte une souplesse supplémentaire. Mais c’est pas la seule solution : pour l’échantillonnage par exemple, tu le fais aussi directement dans influxdb (min/max/moy)… Dans ton cas pour les conso électriques, tu exploses les données brutes pour les classer. C’est possible de faire ça coté HA et de collecter les sensors individuellement.
ça se défends par certains aspects…