Filtrage des données reçues => min/max erronés

Page : index.php?v=d&m=openzwave&p=openzwave&id=63#commandtab
Jeedom_version : 4.0.24
Uname : Linux pidom.trychlos.lan 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux


Message :
Bonjour,
Ceci est un rapport de bug sur l’enregistrement des valeurs en sgbd.

Je suis en Jeedom 4.0.24 (pour fixer les choses, mais ça fait longtemps que je constate ce fonctionnement).
Il semble que Jeedom n’enregistre en sgbd qu’une valeur (pour une commande) toutes les 5 minutes maximum. Ce faisant, il « perd » la trace des données intermédiaires, et produit donc des min/max erronés.

Ex: soit une prise ZWave FWGPE, et les valeurs> 700 reçues en event ce jour :

# cat event | grep -E « ^[$(date ‹ +%Y-%m-%d ›) » | grep -F ‹ [Cage serveurs][FGWPE.3][Puissance] valeur : › | sed -e ‹ s|[INFO]|| › | awk ‹ { if( $NF > 700.0 ) printf( « %s %s %s\n », $1,$2,$NF )} ›
[2019-10-25 00:17:22] 700.5
[2019-10-25 10:42:07] 710.9

Mais le sgbd n’a enregistré que 12 valeurs, et pas les maxima (ça aurait été un grand hasard) :

MariaDB [jeedom]> select * from history where cmd_id=564 and hour(datetime) >= 10 and hour(datetime) < 11 order by datetime asc;
±-------±--------------------±----------------+
| cmd_id | datetime | value |
±-------±--------------------±----------------+
| 564 | 2019-10-25 10:00:00 | 405.71646137951 |
| 564 | 2019-10-25 10:05:00 | 415.70304384771 |
| 564 | 2019-10-25 10:10:00 | 406.67883898708 |
| 564 | 2019-10-25 10:15:00 | 446.80730375616 |
| 564 | 2019-10-25 10:20:00 | 408.04995240597 |
| 564 | 2019-10-25 10:25:00 | 377.91612824813 |
| 564 | 2019-10-25 10:30:00 | 307.1901692502 |
| 564 | 2019-10-25 10:35:00 | 473.05327726996 |
| 564 | 2019-10-25 10:40:00 | 320.82667880317 |
| 564 | 2019-10-25 10:45:00 | 392.42706456012 |
| 564 | 2019-10-25 10:50:00 | 411.99345326451 |
| 564 | 2019-10-25 10:55:00 | 394.52854092071 |
±-------±--------------------±----------------+
12 rows in set (0.00 sec)

On constate bien ci-dessus la période d’enregistrement à 5mn.
J’ajouterais bien un screenshot du widget qui affiche un max à 473 W, ce qui est évidemment à la fois contrariant et loin de la réalité, mais je ne sais pas ajouter une PJ.

Question : cette période d’enregistrement peut-elle être supprimée (je n’ai pas trouvé où) ?

Dans l’affirmative, tant mieux, c’est juste que je n’ai probablement pas assez lu la doc (et si vous pouviez m’indiquer un lien vers le paragraphe concerné, ce serait gentil de votre part).

Sinon, je ne comprends pas la raison de ce choix, et d’autant moins que la plupart des senseurs peuvent régler eux-même leur fréquence d’émission.

Comme une alternative, au moins les valeurs extrêmes devraient être enregistrées en sgbd.

Merci d’avance de votre aide sur ce point.

Cordialement,
Barbap’s
.

Bonjour,
Vous trouverez tous ce que vous voulez dans la configuration avancé de la commande ou vous allez pouvoir choisir la méthode de lissage (min,max,moyenne,aucune). En ce qui concerne la période de lissage ça peut se configurer dans l’administration de jeedom partie commande

Bonjour Loïc,

Il me semble que la méthode de lissage concerne l’archivage des données : en l’occurence, la moyenne me convient parfaitement, mais ça n’a pas de rapport à mon sens avec le problème que je signale.

Idem, la partie Commandes de la configuration de Jeedom concerne :

  • la période de calcul des min/max/moyenne : 24h, et ça me convient
  • la période de calcul pour la tendance : 1h, et ça me convient.

J’avoue que je reste dubitatif : rien de tout ça n’explique qu’une valeur max ne soit pas enregistrée et prise en compte ?

Cordialement,
Pierre

Ben la valeur max est lissé avec la valeur d’après ou d’avant sur une période de 5min donc forcement ca fait pas un max mais c’est normal tu demande une moyenne

Je m’ajoute au sujet parce que ça ressemble étrangement à ce que je vois ici aussi.
Mes consignes T° z-waves sont 14, 17, 18.5 …
Je retrouve bien ces valeurs dans les traces (scenarios, log zwave etc)…
Par contre, je constate que l’historique contient des valeurs exotiques : 17.75
image
Ce 17.75 n’existe QUE dans l’historique, jamais ailleurs et pas non plus sur les affichages de tête thermostatiques
Étrangement 17,75 c’est la moitié (moyenne) entre 17 et 18.5… Et j’ai aussi ces écarts à 5 minutes d’intervalle…

Je sais pas comment vous l’expliquer le systeme fait une moyenne sur 5min puis à 00h00 une moyenne sur 2h des moyennes sur 5min. Donc oui si tu as une valeur de 17 à t puis une de 18.5 à t+4 ben ca va faire du 17.75 c’est le principe du moyenne… Pas oublié non plus que si tu a t+5 tu a a nouveau 17 ben ca sera la moyenne entre 17.75 et 17, on ne stock pas tout pour faire une vrai moyenne ponderée

OK Je reformule pour voir si j’a bien compris.

Les valeurs réels ne sont pas forcement reçues toutes les 5 minutes… Mais jeedom fait la moyenne de ces valeurs pour enregistrer l’historique à xH00 xH05 etc…
Et avec le même principe avec la plage de 2h…

Je comprends le but qui est de limiter la quantité de données…Personnellement j’aurai quand même préféré que ça ne s’applique qu’aux données « archivées » et pas sur celles « live »… Parce que du coup les données « live » ne sont plus la vérité…

C’est ca et si ca va pas ya toujours de passer en aucun lissage

Ben, la phrase clé est « le systeme fait une moyenne sur 5min ». C’est très clair pour moi, et très probablement la cause du problème que j’ai signalé.
Je ne vois pas que cette durée soit configurable quelque part ?

Comme un contournement, et comme toutes les valeurs passent quand même dans les scenarii, serait-il possible (mais je trouve ça moche) d’enregistrer les valeurs désirées depuis un scenario ?

L’inconvénient de passer en « aucun lissage », c’est que ça affecte aussi bien les données « live » que les données archivées, non ?

@Barbapapa donc il faut virer le lissage

Merci @Loic. Pendant un moment le lissage ne s’appliquait que sur l’archivage non ?

Même déduction/impression …

Il n’est pas possible de modifier la période de 5min, se comportement existe depuis jeedom v0 a peut pret.

Je ne parlais pas des 5 minutes (ça me va bien) mais du fait que le lissage s’appliquait à l’archivage uniquement avant, puis maintenant à l’archivage ET aux données « live ».

Ya eu 0 changement la dessus ça c’est toujours appliqué au 2 depuis la v1… Voir même avant…

OK, merci pour ces infos

@Loic : est-ce une question de principe (la structure de Jeedom), ou bien accepteriez-vous éventuellement un patch pour rendre la chose un peu plus souple ?

Le soucis c’est que j’ai aucune idée des conséquences d’un tel changement et la on est en phase d’une stable donc je vais pas prendre de risque.

L’autre soucis c’est que ça fait encore une option et je veux pas en ajouter plus surtout une comme ça qui sera comprise par moins de 10 utilisateurs

L’option activée ou inactivée par défaut permettrait de conserver le comportement actuelle donc peu d’impact
Reste le fait d’avoir une option de plus… Les 2 points de vue se défendent. Je n’avais pas jusqu’à maintenant vu le comportement du lissage, preuve que l’option n’était pas forcement indispensable

Personnellement, je viens de corriger chez moi : suppression du lissage, mais réduction de la plage de rétention à 3 mois. ça sera suffisant pour suivre le chauffage.
Sur d’autres suivis plus critiques (conso ou production électrique me vient en tête), c’est pas forcement aussi simple et l’option est une bonne idée.

Par expérience on est déjà tombé dans ce truc de mettre une option a chaque demande utilisateurs qui au final et très peu utilisé mais nous prend un temps de fou pour la maintenance c’est pas rentable et je veux pas retomber dedans. Jeedom doit pas être une machine a option ca complique la vie des utilisateurs et ceux des développeurs