Hello… Pourquoi des # autour de test ?
parce que c’est un tag, pour qu’il le remplace par sa valeur, non?
Oui et Donc comme ton nom de commande n’en contient pas ça risque pas de marcher…
Pour exploiter un tag hors code de toutes façons c’est :
Tag(nom)
quand je mets #[#test#][Yeelight][Allumer]# je m’attends à ce qu’il interprête #test# qui est égal à « Salle à manger » et qu’il execute la commande #[Salle à manger][Yeelight][Allumer]# ; visiblement ce n’est pas le cas. Dans les logs ça marche sous les 2 formes :
#[#test#][Yeelight][Allumer]# ou #[tag(test,"")][Yeelight][Allumer]#
Avec ta première syntaxe je suis quasi sûr que jeedom cherche au mieux à remplacer ce qui est encadré par 2 # consécutifs…
Donc entre le 1 et le 2 puis entre le 3 et le 4… Et pas du tout en sachant faire la différence d’une commande entre 1 et 4 après avoir compris que c’était un tag entre 2 et 3…
Et pour le deuxième cas, il cherche le nom brut entre les #. Donc c’est mort sans bloc code
merci pour tes réponses, est ce qu’on peut remonter à l’équipe qui s’occupe des dév ? parce que ça me semble une bonne idée d’avoir des variable dans une commande …
Tu peux toujours remonter l’information… Personnellement je crois pas que ça change grand chose
dans mon cas c’est un vrai besoin, alors oui on peut faire un bloc code, mais c’est tellement plus pratique et lisible d’utiliser un paramètre dans une commande que d’utiliser un bloc code …
C’est pas moi qu’il faut convaincre…
non je t’explique juste 
merci en tous cas pour ton temps !
Hello
Ya certain petit bloc code qui ne sont pas bien mechant quand meme !
J’ai aucun souci à écrire du code, je suis développeur, je suis entrain de faire le scénario avec le bloc code, je mettrais 2 screenshots avec les 2 scénarios l’un à côté de l’autre, tu comprendras certainement pourquoi je voulais une variable dans une action
Oulaaa toutes mes excuses alors !..
bein non pas de soucis
bon bein voilà comment est le scénario (je t’épargne le scénario générique qui ne fait qu’executer une commande)
et voici le scénario comment il aurait dû être
je trouve la deuxième version plus lisible, et encore j’ai pris un scénario simple, dans un scénario complexe ça va d’autant plus complexifier la lecture (enfin toujours à mon avis)
1 « J'aime »
C est en effet une question de point de vue.
Perso je prefere la version 1 !
Si ton scenarion ne fait que ca, je ne vois pas vraiment l utilité des 2 bloc SI !? Autant finir les actions directement dans le code…
(Et question lisibilité str_replace sait prendre un tableau en parametre 
)
dans le cas 2 je récupère juste le nom de la chambre et je reprends un scénario normal avec les boites colorées, j’aime bien les boites, elles sont facilement lisibles, c’est loggué par défaut donc en cas de problème tu peux voir le déroulement … je sais que ce n’est pas indispensable comme feature puisqu’on peut le faire avec du code mais ça ferait au moins un heureux ( moi ) . et puis si on se disait ça pour chaque fonctionnalité, on aurait mis juste un bloc code et rien d’autre puisqu’on peut tout faire avec du code …
En tous cas merci pour tes réponses et ton temps!
Salut,
Je pense surtout que ça ajouterait pas mal de complexité à gérer par le core de Jeedom. Pas sûr qu’ils aient du temps à consacrer sur ce genre de point en particulier. Et comme tu dis ce c’est pas indispensable, même pour faire un heureux😉
Il faut hélas bien fixer une limite sur les fonctionnalités accordées par le core.
Salut @noodom,
Je comprends qu’on ne veuille pas le faire parce qu’il y a d’autres priorités, mais je ne suis pas sûr la complexité d’interprêter tous les tag() et variable() avant d’executer la commande. En tous cas, le fait est là, ce n’est pas possible aujourd’hui et ce ne sera pas possible demain apriori