Synthétiser des scénarios

Est-il possible de simplifier un scénario qui lance lui-même plusieurs actions…
Ce n’est pas clair… Voici l’exemple que je souhaite simplifier


Le scénario est lancé avec 2 tag : le nom du volet et le sens du déplacement
Au lieu d’avoir toutes ces lignes de commandes, comment faire pour synthétiser cela ?
J’aimerai par exemple avoir:
Room : bureau
Sens: up
et comme action paramétrée :
[tous les volets][#Room#][#Sens#]

est-ce possible ? Si oui, comment faire ?

Bonjour,
Déjà la syntaxe des tag est incorrecte.
Si ch-amis est la valeur du tag room il faut écrire dans le si:
tag(room) == ch_amis. ou valeur du tag entre guillemet

Merci pour ce conseil.
Mais cette syntaxe ( #Room# == « ch_amis » ) fonctionne …?

ch_amis entre guillemets: "

Bonjour,

Elle fonctionne effectivement, mais pas dans tous les cas et chez tout le monde. La formulation recommandée par Kerdale tag(XXXXX) est recommandée par Jeedom car plus pérenne. C’est la formulation d’avenir :wink:.

Pour le fond, ta question rejoint les interrogations régulières sur le forum quant à la possibilité qu’un scénario appelant (scénario « père ») puisse passer une commande en tag à un scénario appelé (scénario « fils »). Sans solution à ma connaissance à ce jour :slightly_frowning_face:. Ça doit pouvoir se coder en PHP/script, probablement, mais pas vu.

Transmettre au scénario appelé/fils les chaines de caractère correspondant à la commande (ici pour toi « ch-amis », « bureau », « UP »,…) ne pose pas de problème via des tags bien sûr (éventuellement utilisation de la commande name() ).

Mais ensuite, au sein du scénario appelé/fils, reconstituer la commande avec les chaines de caractère transmises, commande qui soit pleinement utilisable, est plus compliqué ! Je ne connais pas de solution, du moins pas en programmation visuelle.

Merci, je vais utiliser la formulation recommandée :slight_smile:
Pour le fond du problème, dommage. Je vais réfléchir au problème et tenter d’alléger tout cela.
Merci encore pour la réponse.!

Quand je te disais que la question se posait régulièrement :wink:. Fil de discussion en cours actuellement :

En effet on peut voir que la question est assez souvent évoquée, mais sans réponse valable.
Ah si seulement on pouvez passer un équipement par « tag » !

1 « J'aime »

Bonjour,

J’avance doucement dans ma maîtrise de Jeedom, et, ces temps-ci, plus particulièrement en direction des blocs code et du PHP. J’ai ainsi une solution à te proposer.

Transmettre des parties d’un nom de commande (dans ton cas les parties « Équipement » et « Commande », mais pas « objet ») à un scénario « fils » nécessite que le scénario fils reconstitue l’entièreté du nom de la commande pour pouvoir l’utiliser (ou de l’ID de la commande, ce qui revient au même). Il faudra alors un bloc code, avec concaténation de chaines de caractère, et je pense une fonction du genre getHumanName().

À la place, je te propose de transmettre par tag le nom entier des commandes UP et DOWN (par exemple dans ton cas #[Tous les Volets][salon][up]# et #[Tous les Volets][salon][down]#). Le scénario fils n’aura pas le travail de reconstitution à faire, et pourra directement utiliser les commandes transmises via les tags, dans des blocs code.

Exemple ici avec un tout simple double clignotement d’ampoule que j’utilise depuis peu :

C’est très basique, mais le principe est réutilisable pour des scénarios fils plus complexes et donc plus interessants à n’écrire qu’une seule fois et pas à chaque fois qu’on en a besoin.

Limitation actuelle (limitation liée à mes connaissances actuelles :roll_eyes: !) : j’ai des pistes, mais je ne sais pas encore comment transmettre facilement une commande Info par tag.

Ainsi, mon scénario précédent est conçu pour une ampoule ou un groupe d’ampoules (via le très utile plugin Groupe de ZygOm4t1k !) éteinte. J’ai son jumeau pour une ampoule (ou un groupe d’ampoules) allumée. En ajoutant un tag avec la commande d’état de l’ampoule, un seul scénario suffirait (qui décidera de la séquence à appliquer On-Off-On-Off ou Off-On-Off-On en fonction de l’état initial de l’ampoule).

Bonjour!
C’est une idée que je n’avais pas envisagée… Je creuse la question dès que possible.
A bientôt

Salut,

Quelques pistes car tu dois pouvoir faire plus propre et optimal comme scénario :

  • Appeler le scénario fils avec juste un tag nb-répétition

Dans le scénario fils

  • Faire un bloc code avec 1 boucle for (autant de fois que le nb-répétition)
  • Actions de la boucle : on / pause 1 s/off /pause 1 s

Tu divises par 4 les actions de lecture des tags, qui consomment des ressources
Tu n’as qu’un bloc pour gérer autant de clignotement que tu veux

Pour aller plus loin et rendre le truc complètement générique. Tu ajoute un deuxième tag…pour l’id de la commande :

cmd::byId($tagid)->execCmd();

Salut,

Désolé du manque de réactivité, je n’ai pas consulté le forum depuis une semaine (trop de boulot !).

Voici l’état actuel de mon scénario de clignotement, avec maintenant le nb de clignotement variable (via une boucle en visuel, pas encore en bloc code !) et la prise en compte de l’état initial de l’ampoule (éteinte ou allumée, avec fin du clignotement sur le même état).

Pour ce dernier point, je n’ai pas trouvé plus simple que d’ajouter encore un nouveau tag :roll_eyes: (ici appelé CommandeEtat).

Voici ce que ça donne, si ça peut aider certains (version transitoire : un jour tout ça va bien finir en PHP bloc code intégral ou en script fonction :blush:).

Le lancement dans le scénario père :

Le clignotement géré dans le scénario fils d’après les commandes transmises par le père :

Par contre, je ne comprends pas trop ta dernière proposition.

Pour aller plus loin et rendre le truc complètement générique. Tu ajoute un deuxième tag…pour l’id de la commande :
cmd::byId($tagid)->execCmd();
[/quote]

Il faut la commande d’extinction et la commande d’allumage pour provoquer le clignotement, et je ne peux pas déduire l’une de l’autre (je n’ai pas que des commandes nommées « On » et « Off » sur mes ampoules/groupes d’ampoules). Donc je ne vois pas comment faire autrement que de passer les deux commandes en autant de tags.

C’est tout à fait possible de déduire automatiquement plein de choses !
Par exemple le virtuel qui contient tes 2 commandes ON/OFF et l’état


Le nom complet du virtuel est

  • #[Aucun][DemoLien]#

et les trois commandes

  • #[Aucun][DemoLien][Etat]#
  • #[Aucun][DemoLien][On]#
  • #[Aucun][DemoLien][Off]#

Il suffit donc de rajouter la chaine [On] ou [Off] ou [Etat] au nom pour obtenir les bonnes commandes…
Tu peux donc passer le nom directement sous forme d’une chaine en un seul et unique tag et après concaténation de faire l’appel de la commande ($cmd=cmd::byString(‹ #[Aucun][DemoLien][Etat]# ›)… voire même de ne faire passer que l’id ($eq=eqLogic::byID(752); et de retrouver le nom ($name=$eq->getHumanName()) …

Je me suis mal exprimé : faire comme tu le dis est tout à fait correct bien sûr (et ce serait même une solution efficace !), mais elle implique que toutes mes commandes d’extinction s’appellent par le même nom (« Off » par exemple), toutes mes commandes d’allumage aussi (« On » par exemple) et idem pour la commande d’état.

Or, je souhaite être le minimum contraint dans le nommage des commandes de mes équipements. Genre dans 15 ans, je change une lettre d’un nom de commande d’un périphérique obscur, et paf plantage du bazar :grin: :angry:.

OK, c’est un peu une position de principe, presque « idéologique ». J’accepte de supporter la contrainte (m’obliger à passer 3 tags plutôt qu’un seul) pour garder mon idéal de pureté programmatique :wink:.

C’est juste totalement l’inverse des « conventions de nommage » que l’on applique dans l’informatique… Non seulement tu n’auras pas besoin de changer le nom du virtuel parce qu’il ne sera pas obscur, mais en plus dans 15 ans, il ne te faudra que quelques secondes pour comprendre comment ça fonctionnait à l’époque… Et pour couronner le tout, tu risqueras moins de planter le fonctionnement…
C’est pas forcement le cas sous jeedom, mais quand il s’agit de reprendre le code de quelqu’un, tu es bien content que ça soit clair sans y passer des heures à essayer de comprendre

Après c’est un choix . Je sais pas s’il faut appeler « idéal » mais il n’y a pas de doute pour le caractère individuel/personnel