Non la visiblement ton scénario ne tourne pas, ce que tu vois c’est la ligne qui fait le grep pas le scénario en lui même donc à priori rien ne tourne.
Le kill d’un vrai scénario qui tourne ça ressemblerait à ça :
Du coup je me dis que si je commence à faire une boucle infinie, je prévoirais une petite variable de suicide quand même …
Tu crée une variable que tu initialise à 0. Dans la condition de ton while, tu vérifie que cette variable vaut 0. Si elle est passée à 1, tu n’est plus dans la condition du while et donc tu sors de ta boucle.
Si jamais tu te retrouves dans une solution impossible à arrêter tu passe la variable à 1 et le script devrait s’arrêter de lui même à la prochaine itération de la boucle.
1 « J'aime »
Oui tu fais bien d’en parler! 
J’ai pas pris le temps de le faire.
Effectivement. Du coup je ne comprends pas pourquoi la commande renvoie des pids, et différents chaque fois.
Très bien vu → je prévois ça pour la prod.
Bon j’ai testé le bloc code, mais j’ai une erreur de commande introuvable :
Pourtant la syntaxe me parait OK, je ne vois pas :
Une idée de ce qui coince ?
Salut,
Il manque au moins les # autour du nom de la commande.
Essai mais il me semble qu’il y a une subtilité avec cette fonction, je sais plus trop quoi. On verra après ta modification.
En effet merci.
J’ai oublié les ## autour de la commande.
C’est corrigé.
A part ma faute de ## je pense que ca devrait tourner.
J’utilse la même base pour la tempo de mon café avec fingerbot.
J’ai un autre scénario qui temporise l’arrêt selon la dernière exécution d’un café.
Bref !
C’est pas optimisé mais ca marche très bien
Sous Linux, quand tu fais un grep d’un processus par son nom tu vois apparaitre deux lignes :
- Le processus en lui même que tu cherchais
- Le process du grep (vu qu’il contient l’expression que tu cherchais !)
Du coup si un grep d’un ps ne renvoi que grep c’est qu’il n’y a pas de processus correspondant : c’est en fait ta recherche que tu vois.
En effet, j’étais à côté de la plaque 
Je viens d’ajouter les ##, le scénario se lance sans erreur mais :
- il n’appelle pas le scénario qui interroge l’IPX.
- il s’arrête de suite sans boucler.
Je découvre cette syntaxe, et les anomalies ne me sautent pas forcément aux yeux…
Voici ce que j’ai :
Pour info, le scénario appelé :
C’est quoi ta variable $LECTURE_ANALOGIQUE ?
Tu ne l’initalise pas et tu l’appelle.
Essaye de la commenter et de relancer pour voir.
C’est le scénario qui va lire les valeurs IPX.
Pour l’instant il ne contient qu’une instruction « message » pour test.
Le script modifié :
J’ai retiré la ligne faisant appel à LECTURE_ANALOGIQUE, mais j’ai toujours le message d’erreur #scenario714#. J’ai l’impression que c’est le scénario précédent qui continue de tourner en mémoire ?
Pourtant, rien ici en terminal :
ps -ax | grep jeeScenario.php
741882 pts/0 S+ 0:00 grep jeeScenario.php
Hum curieux, essaye d’appeller le scénario par son id plutot que par son nom pour voir …
Récupère l’id de ton scénario à lancer déja : il est écrit sur l’onglet général du scénario
Et dans ton code, remplace ton scenario::byString(…) par scenario::byId(67); (67 donc dans mon exemple)
Avec ce code, le scénario 714 se lance bien toutes les 5 secs.
Par contre, impossible de stopper le code principal.
Après un stop au bouton,il se relance tout seul. Même si je le désactive.
Il apparaît arrêter mais le log se remplit avec les erreurs antérieures
Donc c’est le scénario précédent qui vit sa vie :
Il y a bien une solution pour killer ça quand même 
J’essaie de trouver au lieu de rebooter.
T’a essayé le grep du process en ssh ?
Bob je n’ai pas trouvé comment « killer » le scénario en mémoire, j’ai donc rebooté.
En résumé :
- Le scénario « boucle while » se lance correctement.
- l’appel au scénario tiers toutes les 5 secondes est OK.
- Problème : une fois le scénario lancé, il est impossible de l’arrêter.
Toute modification ou même désactivation ne sert à rien, car cela ne s’applique pas à la session active en mémoire.
Help !
Oui et cela ne retourne rien :
ps -ax | grep jeeScenario.php
48184 pts/0 S+ 0:00 grep jeeScenario.php
Ben clairement c’est le danger des boucles infinies …
Je te conseille d’implémenter ce que j’ai dit plus haut.
Créer une variable jeedom stopboucle et mettre la valeur à 0
Initialiser une variable php stopboucle avec la valeur d’une variable stopboucle du même nom.
$stopboucle = $scenario->getData('stop-script-boucle');
Et ensuite conditionner ton while pour que ça boucle tant que $stopboucle == 0
Il faut penser à refaire le getData à chaque itération de la boucle aussi pour ta variable php soit actualisée si elle change coté jeedom.
Perso je commencerais déja par tester ça sans la boucle infinie voir si ça marche bien avant de relancer 
Ceci étant dit, moi j’aurais fait quelque chose de bien plus classique et moins casse figure.
Un virtuel on/off qui permet de démarrer un scénario.
Le scénario vérifier l’état du virtuel :
Si off il fait un exit et donc c’est fini
Si on il continue, fait le traitement que tu souhaites (lecture de ce que tu veux), fait un sleep de 5 sec puis relance le scénario lui même
Pas besoin de 2 scénarios, pas besoin de bloc code et on évite le risque de voir une boucle infinie
3 « J'aime »
Oui je suis d’accord avec toi, c’est ce que j’avais dit plus haut, pour moi jeedom est pas réellement fait pour faire des boucles infinies comme ça.
Sinon ça s’appelle un daemon et plus un script.