je relance un sujet fermé précédemment par @Juju31, pour envoyer via ask 2 personne sans passer par un plugin supplémentaire, moi je me suis inspiré du tuto sur la sortie des poubelles :
et je l’ai adapté pour me l’envoyé à moi et ma moitié et ensuite le premier qui répond clôture le sujet (scenario) :
cependant j’aimerais bien savoir si on peut connaitre via une variable, le nom de l’expéditeur de la réponse pour faire encore une réponse plus adapté, genre « J… à répondu merci :) »
Comme le 2nd Ask destiné à Jul. ne s’exécute que si Sop. (eh, fallait mieux effacer les prénoms sur ta capture d’écran ) a répondu non (ou n’a pas répondu), il y a moyen pour le scénario de savoir qui a fini par sortir les poubelles.
Par exemple :
En tout début de scénario tu crées une variable, disons varQuiASortiLaPoubelle, que tu initialises avec la valeur « Sop. ».
Dans le 1er bloc SI/ALORS, avant le ASK vers le téléphone de Jul., tu affectes la valeur « Personne » à la variable varQuiASortiLaPoubelle. [En effet, si on en est là, c’est que ce n’est finalement pas Sop. qui a sorti les poubelles !]
Toujours dans le 1er bloc, mais cette fois après le ASK, ajoute un SI/ALORS qui fera ceci : SI AskPoubellesSMS égal Oui, ALORS varQuiASortiLaPoubelle prend la valeur Jul.
Ainsi, à la sortie de ce 1er bloc SI/ALORS, la variable varQuiASortiLaPoubelle aura l’identité de celle ou celui qui a sorti les poubelles : Sop., Jul. ou Personne.
À tester pour voir s’il y a pas un bug…
(Edit : je relis la question de x2005254, et je me demande si je l’ai bien comprise…)
Effectivement ton raisonnement marcherais, et je vais surement le mettre en place d’ailleurs, mais avec le temps depuis que j’utilise mon scenario je me suis rendu compte aussi qu’il y avait un truc qui me dérange.
je m’explique :
Jeedom m’envoi un message via mon scenario pour sortir les poubelle j’ai X minute pour répondre et si je ne réponds pas, le scenario l’envoi à ma moitié.
sauf que si entre temps je vois le message de mon coté, mais que le délais est dépassé et que je réponds à jeedom, il me répond qu’il comprends pas ma demande (c’est normal me dirais vous)
donc si ma moitié répond, avec ce genre de scenario effectivement on peut vite savoir qui répond.
Seul Bémol en fait je voulais faire un truc plus interactif, c’est à dire que tout le monde peut répondre en même temps et pas à tout de role.
Dans ce cas il faut que je regarde mais je pense devoir passer par un plugin.
Alors mon scenario est déjà fonctionnel tel que et avec la solution du @Avallo on peut déduire qui répond en fonction d’où on se trouve dans le scenario donc pour moi c’est résolu, mais maintenant avec le temps mon besoin change j’aimerais envoyé le message au 2 personne en meme temps et que tous le monde puisse répondre, pas seulement une personne, puis ensuite une autre en fonction d’où je suis suis dans le scenario.
je vais donc commencer à regarder les plugin d’envoi groupé
C’est ce que je cherche à faire aussi,
A priori c’est faisable avec télégramme, mais je préférerais passer par des sms en cas de coupure de courant
Je sais pas trop si il est possible de crée un conversation groupée ou quelque chose comme ça.
Cela permettrais au deux personne d’avoir la question, d’y répondre, et de voir si quelqu’un à déjà répondu…
Je vais essayé de creuser du coté du plugin JPI qui me permet d’envoyer des sms
Quant à l’approche « tout scénario », je ne vois pas en analyse rapide comment s’en sortir : autant que je le sache, un Ask ne peut s’adresser qu’à une personne à la fois (ou un groupe dans le cas particulier de Telegram). Il faudra donc deux Ask, qui devront être simultanés. C’est-à-dire qu’au moins un des deux devra avoir sa case « Action en parallèle » cochée. Or, un Ask n’a d’intérêt que si la suite du scénario utilise sa réponse. Le scénario doit donc « attendre » cette réponse. Contradictoire avec l’action en parallèle.
Votre approche par plugin (JPI, plugin d’envoi groupé) me semble plus prometteuse… (même si finalement, les plugin ne sont que des programmes , mais le PHP ou autre langage aura certainement plus de ressources.)
Mettons que votre scénario principal lance 2 sous scénarios en parallèle, chaque sous scénario interroge 1 personne via un Ask SMS et attend une réponse.
Dès qu’1 des 2 personnes répond, son sous-scénario tue l’autre sous-scénario et gère la suite (avec éventuellement un petit message à l’autre personne expliquant que Jeedom lui a posé une question mais que c’est n’est plus nécessaire d’y répondre !).
C’est un peu conceptuel, mais il y a à creuser pour voir si c’est utilisable.
J’ai essayer Telegram, j’ai créé mon bot, je me suis ajouté, j’ai ajouté ma conjointe, mais je n’arrive pas à créer un groupe avec ma conjointe qui soit reconnu dans jeedom…
Ca c’est de l’idée! je suis surpris car d’habitude j’ai ce genre de raisonnement et j’y ai même pas pensé avant, maintenant faut que je trouve 5 minutes pour le mettre en pratique mais surtout que je fasse les tests croisés avec les téléphone et que je vérifie si ca fonctionne bien. mais encore une fois merci, comme quoi avec des scenario c’est comme les scripts on fait presque tout ce qu’on veut si on réfléchi bien, qui peuvent éviter d’installer une application telegram sur les téléphone, ma nana est contre installer une appli juste pour pouvoir échanger avec la domotique…
si je répond donc il censé m’envoyé merci, et dire à nana que c’est bon j’ai sortie les poubelles (ca c’est la théorie, car je pense que si j’ai 2 ask en attente en //, on s’est pas quel scenario va nous répondre…)
et ensuite ca kill le scenario parent. si on répond pas au bout de 28 minutes il se passe rien.
le deuxième scenario enfant, celui qui envoi un sms, à ma nana (c’est quasi le même avec des message différent) :
Je suppose que [Jardin][ScenSMSPoubelle] est le nom du scénario principal. Pourquoi le relancer au bout de 30 mn ? Une fois qu’il a lancé les 2 scénarios enfants, ce sont ces derniers qui gèrent. Le job est terminé pour le scénario parent. Ou j’ai raté quelque chose dans ton raisonnement ?
Du coup, dans cette logique du scénario parent qui se termine après avoir lancé les scénarios enfants, dans chacun d’entre eux il s’agit de « killer » l’autre scénario enfant, pas le scénario parent (des enfants qui se killent entre eux plutôt que de killer le parent, ça devient bizarre cette histoire ).
Alors oui tu as raison, ca peut paraitre bizarre de relancer le scenario parent au bout de 30 minutes, je pourrais le refaire sur chaque enfant toutes les 30 minutes, mais j’ai un raisonnement d’informaticien feignant et donc je préfère forker un seul wait et une seule relance de scenario, une boucle plutôt que deux en somme
Alors suite au test, il y a eu quelque modification je vous montre mais ca marche d’enfer!!
Le scenario parent a changer j’ai augmenter le sleep entre les lancement de scenario enfant, car sinon des fois je recevais pas le deuxième sms sur le deuxième téléphone quand les envois sont trop rapprocher, les inconvénient des sms et de la clé 3g… et j’ai viré la relance du scenario toutes les 30 minutes pour le déplacer dans chaque scenario enfant :
les deux scenario enfant ont subi 2 à 3 modifications, 2 pour le mien, j’ai du rajouter le kill du scenario frere et la relance au bout de 45 minute dans le else :
et l’autre scenario enfant a 3 modifications, les 2 premiers c’est le même que moi, il tue son frère soit mon scenario et la relance du scenario, et la troisième modification c’est de renommer la variable ask pour que le retour de sms se fasse dans le bon scenario, en gros chaque ask doit avoir une variable de retour différente :
le dernier effet de bord bizarre la commande ask ne peut avoir un wait supérieur à 999 sec, si tu met une valeur au dessus il attend rien et passe direct au else du coup :
Voilà encore merci à tous pour votre contribution je pense que cette méthode répond parfaitement à l’envoi groupé pour palier à telegram, par contre au dessus de 2 personnes ca commence à être une usine à gaz et je le déconseille dans ce cas…
Bien vu le renommage de la variable ! Avec le dédoublement du scénario, évident mais il fallait y penser .
Par contre, pour être perfectionniste, il y a un petit souci avec les blocs DANS : ils lancent un Cron, qui ne sera donc pas annulé lorsque le scénario sera killé par l’autre scénario enfant. Avec donc relance de la question de la poubelle alors qu’elle aura déjà été sortie.
Là, dans l’immédiat je ne vois pas de solution simple. Un Sleep éviterait un Cron, mais un Sleep de 45 mn, pfff… pas trop recommandé !
Toutefois la situation a peu de chance de se produire : il faudrait que tu ne sortes pas les poubelles, et que ta compagne le fasse dans les dernières secondes de ses 900 s de délai Ask (à un moment où ton propre scénario, qui a été lancé 30 s avant, a lancé le bloc DANS). Peut-être (là aussi pour être perfectionniste !) en réduisant de 30 s le délai de sa réponse à elle…
En tout cas, la solution globale est à retenir ! Je vais me la mettre de côté pour possible utilisation ultérieure !
bien vu pour le dans qui utilise le cron, il y a effectivement des cas ou si je reponds juste avant la fin du delais, ca peut déjà est pris en compte en cron dans l’un des scenario enfant ou alors il faut comme tu dis que je mette le dans à 44,5 minutes…
je vais voir à l’usage si je suis embêté par ca et au pire je mettrais des « sleep » à la place des « dans », je suis pas contre les sleep de manière général, c’est pas consommateur, mais le risque c’est que le scenario tombe pour x raison et la la chaine est cassée…
:
) a répondu non (ou n’a pas répondu), il y a moyen pour le scénario de savoir qui a fini par sortir les poubelles.
.
:
.
: ils lancent un Cron, qui ne sera donc pas annulé lorsque le scénario sera killé par l’autre scénario enfant. Avec donc relance de la question de la poubelle alors qu’elle aura déjà été sortie.