Quelle Base de donnees vous utilisez ?

[rantanplan]

Coucou, j'en viens à me poser une question

Je vous donne mon install actuelle

Un module logique KNX ABB aba
Un Jeedom actuellement qui ne sert qu'as stocker les données
Un module Rti pour la liaison knx<=>A/V

Tout ce monde focntionne parfaitement seulement voila... Je veux me passer de Jeedom

Où stockez vous vos données/Historiques... ?
Comment fonctionnez-vous ?
c'est quand même un point manquant.. ?

Car l'ABB aba ne garde pas en mémoire les données sur du long terme ? par exemple, chaque fois que je fais une modif dans le logiciel, les données historique repartent à zéro...

[filou59]

Quel type de donnée souhaites tu garder ?

Il y a quelques année je t'aurais dit MySQL/MariaDB , mais ce qui a le vent en poupe de nos jour ce sont des solutions basé sur InfluxDB , couplé a Grafana et Prometheus par exemple.

[rantanplan]

Merci filou,

Ben les data du bus. (les températures/consommations/etc...)

et pouvoir en faire des extractions dans le aBB & la visu Rti par exemple..

Je sais que jeedom peut le faire et le fait, mais il n'existe rien en plus "simple" ?
c'est bizarre qu'il n'existe rien en knx...,

[richardpub]

Si c'est juste pour archiver, tu peux utiliser Node-red avec un Node KNX et un Node vers influx DB pour stocker les données avec un filtre sur les données venant du bus KNX. Par défaut tout ce qui entre et sort du bus est archivé. Moi j'ai commencé mais fini avec une BD Néo4J No SQL qui géré en fonctions des relations entre les données et non les données elles-mêmes, ce qui permet une gestion plus souple de la BD en cas d'évolution des participants KNX.
Si quelqu'un a des bonnes connaissances en Néo4J, je serais heureux d'en discuter.

[Ives]

Où stockez vous vos données/Historiques... ?
Comment fonctionnez-vous ?
c'est quand même un point manquant.. ?

Car l'ABB aba ne garde pas en mémoire les données sur du long terme ? par exemple, chaque fois que je fais une modif dans le logiciel, les données historique repartent à zéro...

L'ABA n'est pas fait pour stocker des historiques de données car il ne gère pas de base de données.

Jusqu'à maintenant, je conservais les historiques sur 3 ans avec Lifedomus mais suite à l'annonce par Delta Dore d'abandonner cette box je suis passé à Home Assistant en utilisant Node-red (add-on de Home Assistant) qui va directement lire les valeurs des objets KNX pour les stocker dans InfluxDB, une base de données optimisée pour le stockage se séries temporelles (Time series).

Ensuite avec Grafana (add-on de Home Assistant) je peux exploiter les résultats et les afficher sous forme graphique dans Home Assistant.
J'ai déjà validé le principe pour disposer des consommations d'eau, de gaz et d'électricité (y compris les calculs pour la RT2012) pour les périodes jour, mois, année mais je manque un peu de temps actuellement pour tout mettre en place de façon définitive.

In fine, je pourrai très probablement installer InfluxDb sur une VM de mon NUC (hors Home Assistant) ce qui permettrait un lien direct KNX --> Influx DB et d'ignorer ainsi les conséquences d'un éventuel plantage de Home Assistant.

[filou59]

In fine, je pourrai très probablement installer InfluxDb sur une VM de mon NUC (hors Home Assistant) ce qui permettrait un lien direct KNX --> Influx DB et d'ignorer ainsi les conséquences d'un éventuel plantage de Home Assistant.

C'est la solution qu'il faut adopter.
C'est le principe meme de la virtualisation/containerisation, dissocier au maximum chaque tache/service afin qu'il y ait le moins d'impact possible en cas d'arret/de maintenance sur une des taches.

On peut aussi voir ca autrement :
Aujourd'hui certains partent sur HA.... , si on utilise HA + Nodered + Base de donnée + ... , la migration vers une nouvelle version de HA ou la migration vers une autre solution rendront les choses compliqué, et on peut vite baisser les bras a cause de ca.

Si il n'y a qu'HA qui fait que de la supervision, on peut facilement tester et basculer sur mieux le moment voulu sans avoir aucun frein.

[Kevlille]

Hello

Perso je m'oriente plutôt comme Ives, à savoir:

* VM pour InfluxDB/RedNode
* VM pour HA

Ainsi si un jour je compte changer/tester des superviseurs (HA, OpenHAB etc) le switch sera plus simple et rapide.