Bonsoir tout le monde.
Je viens de voir que j’ai ce problème également. Je ne m’y étais intéressé jusque là.
Je m’en suis rendu compte car je souhaite contrôler la conso de mon ballon thermodynamique.
Je suppose que le développeur du plugin n’a pas résolu le problème.
Certain d’entre vous ont trouvé une parade ?
Pronbleme idem chez moi…
Pas de solution semble t-il un an plus tard…
Ca peut pas marcher ça.
La consommation est une valeur qui ne fait qu’augmenter. C’est un index en fait.
Tu peux pas a chaque variation de l’index ajouter l’index à lui même…Ca te sortirait des valeurs exponentielles.
La formule serait plutôt d’ajouter à une variable uniquement la différence avec la valeur précédente et uniquement si c’est positif. De ce fait quand ça repasse à 0, la valeur est négative et donc pas pris en compte et ainsi de suite…
Oui mais je pense qu’on peut toujours attendre…
Voici mon scenario qui permet de palier a ce fonctionnement des shelly. A faire sur chaque circuit d’un shelly
bonsoir,
Je crois que tu as oublié le scénario
Oups
J’ai un seul scénario quelque soit le nombre de shelly. Dans les déclencheurs mettre toutes les commandes infos Consommation Totale des shelly.
C’est pour ça que j’ai un bloc if par shelly (avec verif du trigger)
- Nom du scénario : conso shelly
- Mode du scénario : provoke
- Evènement : #[Terrasse][Cuisine été ][Consommation Totale 1]#
- Evènement : #[Terrasse][Cuisine été ][Consommation Totale 2]#
La conso totale des shelly est remise à 0 systématiquement à chaque reboot. Ce scénario permet de construire une commande info dans un virtuel avec la conso sans remise à 0 de l'index (qui pose sinon souci sur le plugin info conso).
Corrige aussi l'unité Wh en kwH
ACTION
log - Options : {"enable":"1","background":"0","message":"declencheur : trigger()"}
SI trigger(#[Terrasse][Cuisine été ][Consommation Totale 1]#) == 1
ALORS
tag - Options : {"enable":"1","background":"0","name":"temp","value":"#[Terrasse][Cuisine \u00e9t\u00e9 ][Consommation Totale 1]# - variable(ShellyLastConsoCuisineEte1, 0)"}
(variable) Affectation de la variable : ShellyLastConsoCuisineEte1 à #68704#
SI tag(temp) > 0
ALORS
event - Options : {"enable":"1","background":"0","cmd":"#[Consommations][vShelly][Conso Cuisine Ete total 1]#","value":"#[Consommations][vShelly][Conso Cuisine Ete total 1]# + (tag(temp)\/1000)"}
SINON
SINON
et pour info, je suis allé voir sur les forums shelly, ce problème n’est pas un bug mais un comportement voulu de shelly.
En fait je pense (sans être sur à 100%) que ça n’impacte pas le plugin info-conso pour ceux qui l’utilisent si la case à cocher ne pas importer les écarts négatifs est bien coché. @superbricolo si tu peux nous confirmer ?
Pour mémo, la valeur de la consommation des shelly est remise à 0 systématiaquement au reboot du module.
Effectivement, en mode FGD-212 le plugin suivi-conso gère parfaitement ce comportement sans rien avoir à cocher pour la donnée de consommation
Bonjour à tous,
J’essaie désespérément de recréer ce scénario, mais je n’y arrive pas, je suis trop novice dans les histoires de « tag », « event » et Cie 
Est-ce que quelqu’un pourrait me faire une capture d’écran plutôt qu’un export SVP ?
Comme ça je pourrais recopier bêtement, en changeant juste mes équipements et virtuels 
Merci d’avance 
Dans le meme cas que toi, j’ai essayé de comprendre le scenario mais sans succès
Bon, après quasiment 24h de foulage de mon dernier petit neurone 
, je crois que j’ai réussi
Je suis reparti de zéro et sur le papier avec quelques calculs en exemples pour tenter de recréer le scénario de loic69 et je suis arrivé à ça qui semble marcher correctement :
#[Chambre ext][PAC][Conso]# = la ligne d’origine, nommée « conso » (celle en kW/h) dans l’équipement Shelly. Pensez bien à mettre la formule de calcul dans la ligne car la valeur d’origine n’est pas en kW/h :
#[Chambre ext][PAC][Conso histo]# = une ligne info (numérique) que j’ai ajoutée et qui sert à cumuler les valeurs en contournant les reset du Shelly. En gros, c’est un nouvel index de consommation.
avec comme déclencheur(s) la valeur « Conso » remontée par le(s) Shelly :
et dans le contenu, ces éléments :
<!> ERRATUM <!>
Sur la capture d’écran juste au-dessus, ce n’est pas « OU » mais « ET » qu’il faut mettre dans le tout premier bloc qui sert à initialiser les données au premier lancement :
Les variables ne sont pas forcément à créer, elles le seront lors du premier bloc du scénario si besoin.
Le premier bloc, justement, sert à contrôler si les variables existent, ainsi que si les lignes (=« commandes info ») que j’ai appelées « Conso histo » sont déjà remplies ou sont vides. En gros, si c’est le premier lancement du scénario ou pas, ou bien s’il y a eu un reset ou une création de commandes.
Ensuite on fait les tests décris par Loic69 :
Voilà, désolé c’est un peu compliqué à décrire, j’espère que ça aidera malgré tout ceux qui ont eu autant de mal que moi 
Et merci beaucoup à loic69 pour son scénario avec les explications pour enfin corriger ce problème de reset des Shelly
Merci pour ton explication je vais faire le test.
Juste pour ma culture, je ne connaissais pas la fonction Trigger dans un scénario.
Quand tu écris Trigger(Equipement) == 1 , cela veut dire qu’à chaque changement de valeur le scénario va se lancer ?
Non, trigger = déclencheur (du scénario).
ça sert donc à savoir qui/quoi a provoqué le déclenchement du scénario.
Regardes les descriptifs dans les blocs ‹ Commentaire › que j’ai mis dans le scénario 
