Bonjour,
J’ai une info binaire dans un virtuel qui me renvoie des 0 ou 1 en fonction de la consommation d’un appareil
Je ne veux pas que le 1 soit répété a chaque changement de puissance de l’appareil, pour se faire j’ai mis NON sur « répéter les valeurs identiques ».
Mais dans les faits j’ai bien plusieurs 1 qui remontent dans l’historique…
Comment je peux corriger ce problème ?
Merci pour votre aide
Sinon, j’y pensais, tu peux essayer de gérer le truc en faisant un compteur toi.
Genre faire un scénario qui incrémente un virtuel à chaque fois que la puissance est supérieure à 5W et tu RAZ le virtuel quand tu veux.
Tu peux même regarder pour transférer la valeur du compteur dans une info « H-1 » avant de faire la RAZ pour pouvoir gérer ton histoire de monter ou descente. 
Bonjour,
Je reproduis la même chose avec une commande info binaire #[Consommations][Ecocompteur2 (MQTT)][Inst3]# > 400?1:0 dans le plugin virtuel.
Jeedom : 4.3.23
Curieux ça tout de même …
Je regarderais sur une 4.4 si c’est reproductible
Merci d’avoir regardé. donc le problème ne vient pas de chez moi.
Bonjour,
Non, ce n’est pas un problème;
ta commande a été mise à jour donc il y a une entrée dans l’historique mais par contre comme c’est en « ne pas répéter », les évènements ne sont pas déclenchés; donc les scénarios par exemple ne seront pas déclenchés
Tu es sur de toi Mips ?
De ce que je vois en 4.3.23, mais je dois me gourrer …
addHistoryValue() n’est appelé que dans la fonction event()
event() n’est appelé dans checkAndUpdateCmd() que dans les cas (hormis si on spécifie une date) :
Du coup je ne vois vraiment pas à quel moment la valeur est inséré dans l’historique ?
A l’évidence je loupe une truc mais je ne vois pas où
Bonjour,
en l’occurrence pour ce cas, le event (pompe active) est effectué dans le même event que l’info principale (Puissance):
c’est donc bien un event et pas un checkAndUpdateCmd…
Hello,
Tu veux dire que ces 2 commandes seraient dans le même équipement donc dès que la puissance est mise à jour ça boucle avec un event sur l’ensemble des commandes de l’équipement ?
Non, lors de l’event sur la « puissance » le core vérifie tout autre equipement qui utilise cette commande, comme « pompe active » l’utilise dans son « calcul » il est aussi mis a jour l’info.
La boucle « loop » sert a mon avis de sécurité pour d’éviter de rentrer dans une boucle infini…
Donc le fonctionnement décrit ici n’est plus d’actualité ?
Il était question que le comportement devienne identique à « ne jamais répéter » et aucune action n’était réalisée avec ce paramètre.
Enfin bon je ne tiens pas spécialement à remettre le sujet sur la table mais quand même, une commande pour laquelle on souhaite qu’elle ne soit jamais répétée ne devrait ni déclencher des scénarios ni alimenter l’historique quand sa valeur est mise à jour 
.
Il me semblait bien que c’était pour ça qu’il y avait eu autant de bruit à ce sujet en il 2/3 ans.
Jai pas trop eu le temps de regarder le Post, mais pense pas qu’il concerne le calcul d’une commande, ou peut-être un oubli…
Je n’ai pas vérifié si il y a un effet de bord si le calcul passe par checkAndUpdateCmd, c’est peut-être pour ca qu’il est resté en event… faudrait faire le test, avec plusieurs commandes dans le calcul [#cmd1#] + [#cmd2] …
Cest normalement le cas, seul une consignation en histo… et pas de declenchement de scenario, listener…
Sur le post Aurélien indiquait :
Donc moi j’avais compris que dans le cas du « Jamais répété », rien n’était effectué, même pas l’historisation.
Comme ce « Jamais répété » est devenu la norme sauf quand on spécifie Répéter les valeurs identiques : Oui alors j’avais compris qu’il ne devait pas y avoir d’historisation dans l’éventualité ou la valeur était la même que la dernière.
ah mais je dit pas le contraire 
,
Je dis juste que :
Seul une personne de la team pourrait répondre.
En gros, actuellement pour que l’info « pompe active » ne soit pas considéré en répétitives il faudrait que l’info « puissance » ne le soit pas non plus. Et pour une puissance c’est plus souvent une valeur qui évolue en permanence donc quasiment impossible.
