Je commence à utiliser influxdb et j’utilise ce plugin pour alimenter la base de données.
Pour limiter le nombre d’échange j’avais décidé de ne planifier l’injection des données que toutes les minutes et pas en temps réel.
En faisant cela, je me suis rendu compte que si une commande d’équipement se met à jours plusieurs fois dans la minute (par exemple le compteur EDF sur la consommation d’un phase), le plugin n’envoie que la dernière valeur de la minute.
Par contre si l’on configure le plugin en temps réel, toutes les données remontent bien.
Est-ce un bug ou une erreur de ma part ?
Ne faudrait il pas avec une option pour permettre d’envoyer toutes les valeurs même si l’on choisie une mise à jour à une durée définie (limiter la charge pour l’envoi des données) ?
Et ma dernière question, est-ce que le plugin envoie le time stamp de la valeur de la commande dans influxdb ou est ce que le plugin laisse influxdb ‹ tager › le time stamp au moment de la réception de la valeur. Je pose cette question car il y a évidemment une différence car la deuxième solution génère une latence qui peut être importante suivant le matériel mis en place et donc une différence entre les données de Jeedom et influxdb.
Merci d’avance pour votre aide
Ni l’un ni l’autre, c’est le comportement voulu, pour des statistiques à moyen ou long terme je doute qu’il soit nécessaire d’avoir plus qu’une valeur par minute
La plupart du temps cela sera le timestampe de l’envoi, il faudrait que je réfléchisse aux conséquences de changer cela, par exemple, que ce passera-t-il dans influx si on renvoit un même point (avec le même timestamp car il n’y a pas eu de nouvelle donnée en fait)
De nouveau, en terme de stats pour voir des tendances je ne suis pas convaincu que ca soit fort important.
Oui je suis d’accord pas obligatoirement utile mais comment savoir quelle est la donnée à conserver, n’y Jeedom ni le plugin peut le savoir, si dans une minute le compteur fournit 1A, 15A, 10A, quelle est la valeur pertiante à garder ?
En fait , je pense que cela à son importance car influxdb est là pour collecter l’info pertinente ou pas pour un capteur, il y a des outils de type grafana pour effectuer les analyses qui permettent justement de traiter la donnée et de prendre en compte les multi infos en effectuant l’analyse mathématique voulue sur une minute par exemple (permettant d’inhiber une donnée déviante par exemple sur une tendance globale).
C’est pourquoi je suis étonné que le plugin effectue par lui même une ‹ analyse › pour limiter le nombre de données envoyées.
En sélectionnant l’envoi en temps réel cela fonctionne très bien mais peut être la cause d’une charge importante du système, le pourquoi de mon commentaire pour n’effectuer la com vers influxdb que toute les minutes (par exemple) mais en transmettant l’intégralité de la donnée collectée.
Juste mon input au regard des usages que je peux avoir au travail sur la collecte de données de capteurs industriels et le retraitement dans Grafana (même contexte que celui exposé sur e compteur EDF)
Dans jeedom une commande a une et une seule valeur à un instant T, lors de l’envoi le plugin lit cette valeure et l’envoi. Cette valeur est en cache donc ca ne « coute » rien (ou quasi).
Les autres valeurs ne sont dispo que dans l’historique donc déjà il faudrait obligatoirement que la commande soit historisée => c’est une contrainte que je ne veux pas imposer (et c’est un peu dommage d’imposer un historique dans jeedom si le but c’est d’avoir l’historique dans influx )
De plus lire dans l’historique imposerait un aller-retour DB => je ne veux pas cela non plus, trop couteux
C’est clair, je n’ai pas pensé à cela.
Il faut donc resté en mode temps réel pour envoyer toutes les valeurs comme dans l’historique.
Il est vrai que l’historique n’est plus nécessaire si on utilise influxdb en mode réel et grafana.
Merci encore pour les réponses et bon courage pour la suite
