InfluxDB permet de définir la stratégie au cas par cas pour chaque data.
Ex : je me fiche de garder l’historique de mes switch de lumière par contre certaines données comme la conso EDF, la météo pour faire des corrélations, peuvent être intéressantes à garder.
On peut également fixer des stratégies plus complexes autre que “on garde un certain temps puis on efface” (à moins que je n’ai pas saisi comment c’était fait dans Gladys): on peut décider de garder toutes les données pendant 3 mois, faire des moyennes journalières de 3 mois à 6 mois, faire des moyennes hebdo de 6 à 12 et effacer après 12 mois, …
J’ai oublié d’ajouter ‘en attendant’ que ce soit géré par Gladys…
Je sais que c’est prévu mais ça pourrait permettre de patienter…
Si tu préfères, on pourrait le laisser comme option externe en expliquant comment faire dans un tuto.
En attendant que ce soit géré dans Gladys, ça peut permettre d’afficher les courbes capteurs mais aussi de générer des sous-dashboards, par pièce , par exemple.
J’ai mis ça en oeuvre chez moi très récemment pour mettre au point une régulation auto de piscine : j’ai un capteur de pH et je veux vérifier qu’il reste bien stable. J’ai également mis un capteur de pression et j’essaie de déterminer les modes de filtration en analysant les données.
Je compte me servir très rapidement de la partie dashboard pour faire une vue de gestion piscine qui serait accessible sur mon réseau local mais également dispo sur un écran tactile dans le local piscine…
Ok, du coup tu peux peut-être renommer la feature request et enlever grafana? Je pense qu’on va le faire en interne directement, c’est pas si compliqué et ça sera plus simple que faire du grafana
Par contre, j’aime bien aussi l’aspect base de données InfluxDB qui est vraiment intéressant pour les données temporelles avec la notion de stratégies de rétention.
De plus, elle s’interface avec beaucoup d’outils d’analyse de données…
Des choses qu’on ne pourrait pas faire en interne dans Gladys? Il y a déjà une stratégie de rétention dans Gladys, que l’utilisateur choisit à la configuration de son instance
Je pense vraiment que la visualisation des données, c’est la base en domotique. A nous de développer des beaux graphes en interne, il y a des supers libs JS de visualisation de données.
Pour ceux qui sont expert InfluxDB, j’ai confiance en leur capacité à importer les données de Gladys dedans.
Edit: je me suis permis d’éditer le titre de cette feature request, est-ce que c’est bon pour toi? Si oui, peut tu éditer ton message aussi qui ne correspond pas du coup ?
InfluxDB c’est surtout fait pour ça. Grafana c’est beau et on peut avoir la même chose dans Gladys.
Le hic avec Gladys c’est que tu ne peux pas garder 2 ans de téléinfo par exemple et 3 mois de capteurs températures. C’est tout ou rien. D’où nos besoins avec influxDB.
Faudra voir comment gère SQlite avec 2 ans de data ( me semble que tu avait bench @pierre-gilles )
En l’état Rien ne nous empêche de changer ce fonctionnement, on a déjà un attribut « keep_history » dans device, rien ne nous empêche de faire des groupes de device avec des politique d’historique différentes.
Je serais intéressé de savoir aussi comment ça performe sur des requêtes de graph avec de l’échantillonnage.
Après je suis d’accord, pour certains utilisateurs avancés, avoir un service InfluxDB ça peut être cool.
Bon du coup, je pense que ça vaudrait le coup d’avoir 2 features requests:
Box sur le dashoard « historique de capteur »
Service InfluxDB
Etant donné que ce feed parle principalement d’InfluxDB, je vais renommer ce topic et en créer un nouveau pour la box sur le dashboard.
Je pense que développer un service InfluxDB est plus compliqué et plus long en dev que de développer la box sur l’écran d’accueil + historisation custom par device !
Alors étant donné mon utilisation pas très avancée de Gladys, je vote plutot pour l’historique sur le dashboard car InfluxDB me semble plus poussé que ce dont j’ai réellement besoin
