Je me demandais, s’il serait utile/apprécié/demandé/nécessaire de proposer d’autres manières de compresser les courbes qu’en faisant une moyenne horaire comme c’est le cas aujourd’hui.
Je travaille dans le contrôle de process (automatisme) et nous utilisons Aveva PI pour la collecte de données. PI utilise un algorithme de compression des courbes assez performant tout en gardant une résolution correcte. Ce que, par définition, la méthode des moyennes horaires ne permet pas.
L’algorithme de compression de PI prend en paramètre un pourcentage. Si entre 2 points A et P les points (B, C, …) se trouvent sur la droite reliant A et P à plus ou moins le pourcentage, alors les points intermédiaires sont supprimés.
Alors, oui cette méthode est plus gourmande en place que la méthode des moyennes et ne peut pas être la méthode de compression par défaut, mais elle permet aussi de garder les variations sur un temps inférieur à une heure.
Avec l’évolution des machines et l’augmentation des capacités de stockage des disques durs,
En cas de changement de type de compression, il faudrait que le core sache quels sont les points déjà compressés. Pour ça il faudrait rajouter une colonne à la table des historiques. Une chaine de 20 caractères max, par exemple. hourly serait la méthode par défaut. Ca pourrait aussi être un index: la clé primaire d’une nouvelle table contenant les méthodes de compression (id, name, function, parameters).
J’écris ce qui me vient comme ça me vient, c’est peut-être brouillon mais l’idée serait de proposer différentes méthodes de compression pour les historiques en fonction des besoins et des possibilités des utilisateurs.
Je pose la question avant de me lancer pour un PR qui me serait refusé.
Vous en pensez quoi ?
A+
Michel
edit: En y réfléchissant, je me suis dis que cet algorithme pourrait être particulièrement efficace pour les courbes de compteurs qui ne font qu’augmenter et souvent de manière linéaire.
Ca ne servirait qu’à diminuer le nombre de points à afficher et pas le nombre de points à stocker dans la base de données. Le principe étant de réduire le nombre de points à stocker, je pense.
D’après le chapitre principe de l’article en lien, ça y ressemble beaucoup, oui.
Perso, je trouve que l’idée d’avoir une meilleure résolution dans les historiques/graphiques, sans consommer beaucoup de place, est bonne. Par contre, redévelopper encore un composant supplémentaire pour gérer la « compression » etc, me semble fastidieux, voir superflu.
Pourquoi ne pas déléguer l’historisation à une base influx, dont le travail est justement de fournir nativement la meilleure résolution et la gestion des « time series » ?
Ma proposition, serait donc plutôt d’intégrer InfluxDB au core Jeedom pour la gestion des historiques.
Il n’y aurait pas de développement fastidieux, puisque la fonction de compression existe déjà et qu’il ne s’agirait que d’un choix entre plusieurs possibilités (switch case) et l’appel de la bonne fonction. Il ne devrait pas y avoir trop de possibilités. A vrai dire j’en vois 2 pour le moment à savoir les moyennes horaires et l’algorithme de Douglas-Peucker.
C’est donc une option à rajouter dans les paramètres avec ces 2 choix. Ca reste largement dans le domaine du faisable, je pense.
Sur la partie superflue, maintenant que je t’ai lu, si influxDB sait faire et que l’intégration au core est facile, en ce qui me concerne, bien sûr que c’est la voie que je privilégierais aussi.
Je ne connais pas influxDB et ne peux donc pas me prononcer. Par contre je te fais confiance sur ton expertise.