De ce que je comprends, nous ne sommes pas en train de nous demander comment faire pour corriger des données inexactes, mais de justifier le fait qu’elles le soient et que les utilisateurs n’ont pas le choix.
Evidemment, toute option/évolution, et même la première ligne de code, complique la vie des développeurs. Je ne vois néanmoins pas en quoi une option avec une valeur par défaut compliquerait la vie des utilisateurs.
Est-ce que j’ai juste en disant que le seul moyen dans Jeedom d’intercepter toutes les valeurs fournies par les senseurs a également pour conséquence de supprimer tout lissage lors de l’archivage de l’historique ?
C’est un peu le même soucis avec ce que j’avais remonté d’une consommation qui est normalement a 0 car la prise est éteinte mais qui est historisée a plus car c’est la moyenne qui est stockée. Pour ne plus avoir ce problème il faut en effet enlever la moyenne au risque d’avoir une base plus chargée par les historiques. C’est dommage de ne pas avoir cette optimisation du stockage tout en ayant un historique plus réel avec les vrais valeurs en max ou min, mais c’est peut être pas facile à mettre en place
J’emploie peut être pas les bons termes mais j’aime bien l’idée de ne pas garder toutes les valeurs d’une commande pour optimiser le stockage, mais plutôt qu’une moyenne ou il lissage, il faudrait pouvoir garder le max dans les positifs, le min dans les négatifs ou le 0 si il est majoritaire dans la période. Pour une température ou une puissance, ça me semble plus pertinent comment données. Après le lissage c’est sensé enlèver les extrêmes en positifs ou négatifs, la moyenne c’est la moyenne mais là c’est encore une autre méthode peut être.
Sincèrement vous vous prenez la tête pour rien. Passe en aucun lissage avec une limite de temps.
Ca va pas ralentir jeedom en fonctionnement, ca va alourdir un peu la bdd et le seul impact réel sera de ralentir le retour de la requête en base donc l’affichage de cet historique précis sur une grande durée quand vous irez consulter cet historique. Et éventuellement un peu de ram suivant les options d’optimisation de sql.
Je n’ai aucun historique lissé pour cette raison mais tous sont limités dans le temps. On a d’ailleurs ajouté les limites à 2 et 3 ans pour pouvoir faire des comparaisons entre années.
T’inquiète y’a aucun soucis A chaque demande on regarde, on cogite, on essaye d’améliorer.
Mais une moyenne est une moyenne, et sortir des valeurs arbitraires pour certaines commandes qui ne seront pas les bonnes pour d’autres n’as pas vraiment de sens et complexifierai le truc. Beaucoup de gens on déjà du mal à appréhender le lissage au début (j’en ai fais partis quand j’ai commencé sur Jeedom), alors si en plus c’est pas vraiment une moyenne parce que dans certains cas particuliers certaines valeurs sont pas lissées, imagine le truc Et là je parle même pas de l’usine à gaz en développement
Sur le fond, j’ai remarqué ce ‹ problème › de moyenne avec la commande puissance de la prise de mon lave-vaisselle, j’en suis pas encore sur, je dois faire des tests, mais j’ai l’impression que la commande de puissance que j’utilise dans une commande pour savoir si le lave-vaisselle est on ou off n’a pas fonctionnée, car il ne voyais pas la puissance a 0, comme si il voyait la valeur de l’historique, qui lui n’indiquait pas 0 a cause de la moyenne et non la valeur réelle de la commande. Je sais pas si c’est très claire. Est ce possible ? Dans ce cas c’est plus gênant
Dans ce cas, où tu base des tests sur une valeur précise, il te faut clairement aucun lissage.
Et pour savoir si ton lave vaisselle est allumé ou pas, tu n’a pas besoin d’historique au sens propre, donc limite dans le temps la plus courte (1j). çà n’aura strictement aucun impact sur le fonctionnement de ton Jeedom et tu aura le résultat attendu.
Si j’ai quand même besoin d’avoir un historique sur 1 an pour avoir ma consommation
Mais la valeur d’une commande doit forcément être la valeur renvoyée par le module et non une valeur lissée et je pense que c’est la cas dans Jeedom non ? Ou vous confirmez que si la commande a un historique lissé alors c’est la valeur du lissage est renvoyée a la commande et non sa valeur réelle ?
Il me semble qu’à la réception il n’y a pas de lissage, le lissage intervient après. Mais je n’utilise jamais de lissage, là seul @Loic pourra dire exactement quand le lissage intervient.
Ma pensée du matin : il est tout à fait possible d’avoir le meilleur des deux mondes en dupliquant l’information considérée dans une info virtuelle. Une info peut être non lissée et sans historique, et servir à l’affichage des min/max exacts, tandis que l’autre sera utilisée de manière plus « classique », par exemple avec une moyenne archivée…
En étendant cette configuration, on peut avoir autant de fonctionnements différents qu’on veut pour une même donnée : historiser à la fois la moyenne, et le min, et le max par exemple.
Merci les virtuels !
Oui mais ca complexifie un peu les choses ou alors faire un virtuel dédié a l’historisation et coller toutes les commandes que l’on veut historiser et laisser les commandes d’origines sans historique pour l’affichage de les scénarios,…
C’est pas mal comme idée du matin de 10h
@Loic t’en pense quoi ?
Ca va changer un peu Jeedom puisque tu déconseille la multiplication des virtuels ?
Mais ca c’est dans le cas où une commande utilise la donnée historiées et lissée pour son affichage, j’aimerais bien avoir une confirmation ou non de @Loic
La méthode de @Barbapapa doit pouvoir s’appliquer au cas par cas. Comme ça on limite les effets négatifs. Par contre, ça fait jongler entre les valeurs lissés et non lissées dans les scénario etc…
Perso, je préfère la règle que le cas par cas, un virtuel avec toutes les commandes ayant un historique et aucune commande historiée ailleurs c’est plus simple a gérer et a s’y retrouver
Oui, enfin ça implique de se trimbaler des historiques même quand il n’y a pas besoin…
Franchement, savoir que je suis sorti de la maison le 14 juillet 2016 à 21h37 en ouvrant le garage depuis la télécommande n°3 c’est pas aussi important que la température extérieure à la même époque l’année dernière et de comparer tout ça avec la conso électrique.
Ou bien ça veut dire que tu garde une profondeur d’historique adaptée au besoin et au plus juste pour chacun de tes éléments
Non, tu n’ajoutes la commande historisée dans le virtuel dédié que si tu en as besoin, je n’entendais pas par régle de faire systématiquement une commande historisée pour chaque commande mais de les regrouper, celles que l’on veut, dans un unique virtuel et bien sur tu adaptes aussi la durée suivant ton besoin
Ok je comprends mieux : genre un gros virtuel « historique » avec sa propre gestion par infos et juste les infos dont on a besoin. Effectivement c’est mieux que de se coller plusieurs virtuels un peu partout.
Et là je parle même pas de l’usine à gaz en développement 