EDIT :
En fait il doit s’agir d’un bug car ça ne fonctionne pas avec un « dans 0 » mais ça fonctionne avec un « dans 1 »
Bonjour,
pouvez vous me confirmer que dans les scénarios, les tags ne passent pas dans les « dans »
Je m’explique : si je fais
Normal. Le tag n’existe que lors de l’execution du dit scenario.
Le DANS crée un cron a executer en dehors, plus tard. Donc le tag n’existe plus.
Dans ce cas passe par une variable ou un info d’un virtuel
Intéressante question.
Du coup, je m’interroge :
Dans quel cas as-tu besoin de passer un tag a un scénario exécuté plus tard?
Par exemple, imaginons un scénario qui aura pour fonction de mettre une certaine température de consigne d’un radiateur à une certaine température, puis au bout d’une heure, de remettre la température initiale.
Le scénario
Mémorise la température actuelle de consigne (T0c) (j’aurai voulu le faire en local donc dans un tag)
impose une autre température
puis « dans 60 mn », impose la température T0c.
On pourrait aussi imaginer un scénario où l’on passe en paramètre via 2 tags la température de consigne initiale ainsi que la température de consigne que l’on doit imposer au bout d’une heure
Est ce une variable plutôt que un tag ?
Salut,
Sans avoir creusé le sujet, il n’y aurait pas moyen de construire le cron avec l’évaluation du tag au moment de cette création ? Ça ne sera pas toujours selon la valeur qui aura été affectée au tag avant mais ça résoudrait quelques problèmes.
Ok, je vois.
De mon point de vue, les scénario ne sont pas fait pour stocker de l’info, et ca me semble risqué : en cas de problème, tu perds l’infos.
Donc perso, pour mémoriser des trucs, je partirais sur une variable (ou mieux : un virtuel histoire d’avoir une visualisation et une modification possible depuis le dashboard).
Quel est le problème du fait que les variables sont globales? Si tu ne t’en sers que dans un scénario précis, ca ne change rien, ou bien?
Salut,
Utile pour plusieurs radiateurs dans son exemple.
Pour moi ce n’est pas du stockage, mais un algo de gestion de ses radiateurs. Ça reste une utilisation normale d’un scénario dont c’est le but initial 
tu appelles un unique scénario avec juste des valeurs de paramètres différents (tags) selon le radiateur à gérer. Sinon ça veut dire une voire plusieurs variables pour chaque radiateur (et à gérer si ajout de radiateurs). Et une logique à multiplier pour chaque scénario de Jeedom…
Gérer par variables communes ça me rappelle le temps de jeedom avant les tags😱 et les bugs inévitables du coup…
Ce que je veux dire, c’est que la temérature de consigne en question doit bien venir de quelque part. D’un équipement/virtuel jeedom j’imagine? Sinon comment modifier cette consigne pour l’envoyer aux scenarios?
Du coup, il ne me semble pas déconnant de stocker aussi la temperature de consigne précédente, surtout si le but est de revenir a cette consigne après un certain temps.
Ca me semblait plus cohérent. Mais j’ai peut-être rien compris 
Mais je suis d’accord avec toi : les tag ont apporté énormement de simplification et de souplesse aux scénarios. Du coup, je me sers des scénario quasi comme des fonctions unitaires avec passage de paramètres.
La température de consigne est géré par le programme du radiateur lui-même donc en dehors de jeedom. Il y a un plugin qui permet de la récupérer.
Lorsque l’on veut changer momentanément cette température de consigne, toujours via le plugin qui dialogue avec le programme du radiateur lui-même (enfin en réalité sa box), il faut être capable, à la fin du temps de dérogation de remettre la température telle qu’elle était avant que jeedom ne la modifie provisoirement. Il faut donc la stocker quelque part.
Les réponses faites par certains ci-dessus sont bonnes: l’avantage des tags est qu’il n’y a pas de risque de modification du contenu des variables par un autre appel à scénario pour un autre radiateur. C’est possible de le faire avec des variables, mais il faut en avoir autant que de radiateurs, et après, elle vont encombrer la mémoire pour rien (même si c’est en réalité négligeable). Au fait, il n’y a pas une commande permettant de libérer une variable ?
La vraie solution serait une programmation en PHP, mais même si je connais, je ne maitrise pas la programmation objet php or, il me semble que ce serait ce qu’il faut, mais c’est un autre sujet.
Tu a les solutions qu’il te faut, à toi de choisir.
Une variable par radiateur prevC_Rad1, prevC_Rad2 etc
ou un virtuel avec des commandes info
Et oui il y a une action pour supprimer une variable
C’est à toi de jouer …
C’est intéressant, j’utilise justement assez souvent ce fonctionnement.
Je viens d’essayer le scenario suivant :
Dans le moteur de tache, j’ai bien une tache avec montag correctement défini dans les options :
Et dans les logs d’execution le tag est bien repris dans la sous-tache :
Probablement un souci avec la fonction tag() alors, non ?
Jeedom v4.2.13
P.S. : Je viens d’essayer avec ce code pour être au plus proche de ton test :
Et en fait je n’arrive pas à reproduire ton pb…
J’ai fumé ou quoi ? 
Alors là, ce qui est bizarre est que avec un dans 0
Et merci d’avoir fait le test ! Je vais pouvoir utiliser les tags !
Et pourtant : dans la doc jeedom :
Ahhhh bien vuuuuuuuuuu, je n’avais encore une fois pas fait exactement le même test que toi
Avec « 0 », le code ne suis pas le même « chemin » :
Et les tags ne sont pas passé en paramètre du lancement de jeeScenario.php en CLI, qui doit pourtant pouvoir le supporter :
Je vais me fendre d’un petit PR sur le Core 
Bravo ! D’avoir trouvé la cause et merci pour la communauté d’avoir fait le PR 
Avec grand plaisir !
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.
