Bug sur le multi-lancement de scénario

[Pierre_]

Bonjour,

J'ai écrit un petit scénario assez simple pour gerer l'ouverture du volet roulant de ma chambre :

• Je met ma variable PositionVoletChambre à 98 (ouvert)
• Je fais pleins de test pour savoir quel position doit avoir mon volet (dont vérifier si je suis en train de dormir)
• Si ma variable PositionVoletChambre est differente de la position actuel de mon volet, j'envoie une commande pour ajuster la position de mon volet

Pour les courageux ça donne ça :

Code : Tout sélectionner

- Nom du scénario : Gestion du volet de la chambre
- Objet parent : Chambre
- Mode du scénario : provoke
    - Evènement : #[Appartement][Helper Volet][Exposé au soleil]#
    - Evènement : #[Appartement][Controle de la présence][Présence globale]#
    - Evènement : #[Appartement][Activitée][Mode]#
    - Evènement : #[Chambre][Fenêtre de la chambre][Etat]#
    - Evènement : #[Appartement][Heliotropes][Altitude du Soleil]#



    
    ACTION
     (variable) Affectation de la variable : PositionVoletChambre à 98
    
    ACTION
         
        SI  #[Appartement][Controle de la présence][Présence globale]# == 1  
        ALORS
             
            SI #[Appartement][Helper Volet][Exposé au soleil]# >= 3
            ALORS
             (variable) Affectation de la variable : PositionVoletChambre à 0
            SINON
                 
                SI #[Appartement][Helper Volet][Exposé au soleil]# >= 2
                ALORS
                 (variable) Affectation de la variable : PositionVoletChambre à 10
                SINON
        SINON
             
            SI #[Appartement][Helper Volet][Exposé au soleil]# >= 1
            ALORS
             (variable) Affectation de la variable : PositionVoletChambre à 0
            SINON
         
        SI #[Appartement][Activitée][Mode]# == "Dormir"  
        ALORS
             
            SI #[Chambre][Fenêtre de la chambre][Etat]# == 0  OU #[Appartement][Heliotropes][Altitude du Soleil]# > -5
            ALORS
             (variable) Affectation de la variable : PositionVoletChambre à 0
            SINON
        SINON
         
        SI #[Chambre][Fenêtre de la chambre][Etat]# == 1  && #[Appartement][Helper Volet][Exposé à la pluie]# >= 2  
        ALORS
         (variable) Affectation de la variable : PositionVoletChambre à 0
        SINON
    
    SI variable(PositionVoletChambre) != #[Chambre][Volet roulant][Etat]#
    ALORS
     #[Chambre][Volet roulant][Positionnement]# - Options : {"enable":"1","background":"0","slider":"variable(PositionVoletChambre)"}
    SINON

Capture d’écran 2018-07-31 à 08.35.39.png (297.05 Kio) Consulté 3339 fois

Comme vous pouvez voir sur le screenshot, j'ai bien décoché Multi lancement.
Mais quand je regarde le log, je peux voir que le scénario a été lancé deux fois simultanément sur le même trigger à 3h du matin ([1] et [4]) :

Capture d’écran 2018-07-31 à 08.47.25.png (764.38 Kio) Consulté 3339 fois

La ou ça devient intéressant, c'est que les deux scénarios manipulent ma variable globale en même temps:

[1] 03:00:13 : la première instance du scénario se lance initialise ma variable à 98 (volet ouvert)
[2] 03:00:14 : la première instance du scénario voit que je suis en train de dormir et set ma variable à 0 (volet fermé)
[4] 03:00:13 : la deuxième instance du scénario se lance alors que la première tourne toujours
03:00:14 : la deuxième instance du scénario initialise ma variable à 98 écrasant la valeur setté par la première instance en train de tourner
[3] 03:00:14 : la première instance du scénario lit ma variable "hacké" par la deuxième instance et décide donc de rouvrir le volet (oui il est 3h du mat, ça pique)

Le log complet pour les courageux :

Code : Tout sélectionner

------------------------------------
[2018-07-31 02:55:08][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Appartement][Heliotropes][Altitude du Soleil].
[2018-07-31 02:55:08][SCENARIO] Exécution du sous-élément de type [action] : action
[2018-07-31 02:55:09][SCENARIO] Affectation de la variable PositionVoletChambre => 98 = 98
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [action] : action
[2018-07-31 02:55:09][SCENARIO] Exécution d'un bloc élément : 267
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 02:55:09][SCENARIO] Evaluation de la condition : [ 1 == 1  ] = Vrai
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 02:55:09][SCENARIO] Exécution d'un bloc élément : 338
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 02:55:09][SCENARIO] Evaluation de la condition : [0 >= 3] = Faux
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 02:55:09][SCENARIO] Exécution d'un bloc élément : 268
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 02:55:09][SCENARIO] Evaluation de la condition : [0 >= 2] = Faux
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 02:55:09][SCENARIO] Exécution d'un bloc élément : 277
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 02:55:09][SCENARIO] Evaluation de la condition : ["Dormir" == "Dormir"  ] = Vrai
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 02:55:09][SCENARIO] Exécution d'un bloc élément : 343
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 02:55:09][SCENARIO] Evaluation de la condition : [0 == 0  OU -21 > -5  ] = Vrai
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 02:55:09][SCENARIO] Affectation de la variable PositionVoletChambre => 0 = 0
[2018-07-31 02:55:09][SCENARIO] Exécution d'un bloc élément : 364
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 02:55:09][SCENARIO] Evaluation de la condition : [0 == 1  && 0 >= 2  ] = Faux
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 02:55:09][SCENARIO] Evaluation de la condition : [0 != 0] = Faux
[2018-07-31 02:55:09][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 02:55:09][SCENARIO] Fin correcte du scénario
------------------------------------
[2018-07-31 03:00:13][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Appartement][Heliotropes][Altitude du Soleil].
[2018-07-31 03:00:13][SCENARIO] Exécution du sous-élément de type [action] : action
[2018-07-31 03:00:13][SCENARIO] Affectation de la variable PositionVoletChambre => 98 = 98
[2018-07-31 03:00:13][SCENARIO] Exécution du sous-élément de type [action] : action
[2018-07-31 03:00:13][SCENARIO] Exécution d'un bloc élément : 267
[2018-07-31 03:00:13][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [ 1 == 1  ] = Vrai
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 338
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [0 >= 3] = Faux
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 268
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [0 >= 2] = Faux
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 277
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : ["Dormir" == "Dormir"  ] = Vrai
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 343
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [0 == 0  OU -20.8 > -5  ] = Vrai
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:00:14][SCENARIO] Affectation de la variable PositionVoletChambre => 0 = 0
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 364
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [0 == 1  && 0 >= 2  ] = Faux
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [98 != 0] = Vrai
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:00:14][SCENARIO] Exécution de la commande [Chambre][Volet roulant][Positionnement] avec comme option(s) : {"background":"0","slider":98}
[2018-07-31 03:00:15][SCENARIO] Fin correcte du scénario
------------------------------------
[2018-07-31 03:00:13][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Appartement][Heliotropes][Altitude du Soleil].
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : action
[2018-07-31 03:00:14][SCENARIO] Affectation de la variable PositionVoletChambre => 98 = 98
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : action
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 267
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [ 1 == 1  ] = Vrai
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 338
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [0 >= 3] = Faux
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 268
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [0 >= 2] = Faux
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 277
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : ["Dormir" == "Dormir"  ] = Vrai
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:00:14][SCENARIO] Exécution d'un bloc élément : 343
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:14][SCENARIO] Evaluation de la condition : [0 == 0  OU -20.8 > -5  ] = Vrai
[2018-07-31 03:00:14][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:00:15][SCENARIO] Affectation de la variable PositionVoletChambre => 0 = 0
[2018-07-31 03:00:15][SCENARIO] Exécution d'un bloc élément : 364
[2018-07-31 03:00:15][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:15][SCENARIO] Evaluation de la condition : [0 == 1  && 0 >= 2  ] = Faux
[2018-07-31 03:00:15][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:00:15][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:00:15][SCENARIO] Evaluation de la condition : [0 != 0] = Faux
[2018-07-31 03:00:15][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:00:15][SCENARIO] Fin correcte du scénario
------------------------------------
[2018-07-31 03:05:09][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Appartement][Heliotropes][Altitude du Soleil].
[2018-07-31 03:05:09][SCENARIO] Exécution du sous-élément de type [action] : action
[2018-07-31 03:05:09][SCENARIO] Affectation de la variable PositionVoletChambre => 98 = 98
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [action] : action
[2018-07-31 03:05:10][SCENARIO] Exécution d'un bloc élément : 267
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:05:10][SCENARIO] Evaluation de la condition : [ 1 == 1  ] = Vrai
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:05:10][SCENARIO] Exécution d'un bloc élément : 338
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:05:10][SCENARIO] Evaluation de la condition : [0 >= 3] = Faux
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:05:10][SCENARIO] Exécution d'un bloc élément : 268
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:05:10][SCENARIO] Evaluation de la condition : [0 >= 2] = Faux
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:05:10][SCENARIO] Exécution d'un bloc élément : 277
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:05:10][SCENARIO] Evaluation de la condition : ["Dormir" == "Dormir"  ] = Vrai
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:05:10][SCENARIO] Exécution d'un bloc élément : 343
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:05:10][SCENARIO] Evaluation de la condition : [0 == 0  OU -20.5 > -5  ] = Vrai
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:05:10][SCENARIO] Affectation de la variable PositionVoletChambre => 0 = 0
[2018-07-31 03:05:10][SCENARIO] Exécution d'un bloc élément : 364
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:05:10][SCENARIO] Evaluation de la condition : [0 == 1  && 0 >= 2  ] = Faux
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [action] : else
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [condition] : if
[2018-07-31 03:05:10][SCENARIO] Evaluation de la condition : [0 != 98] = Vrai
[2018-07-31 03:05:10][SCENARIO] Exécution du sous-élément de type [action] : then
[2018-07-31 03:05:10][SCENARIO] Exécution de la commande [Chambre][Volet roulant][Positionnement] avec comme option(s) : {"background":"0","slider":0}
[2018-07-31 03:05:10][SCENARIO] Fin correcte du scénario

Moralité :

• Il semblerait que decocher la case "Multi lancement" ne fonctionne pas dans certain cas
• Les variables globales dans un environnement multi threadé c'est le mal

Avez-vous déjà été confronté à ce genre de problème? Avez vous des best practices pour ce genre de problèmes avec Jeedom? Dans mon cas précis, utiliser des variables locales aurait résolu mon problème, mais je ne crois pas que ce concept existe dans Jeedom si? Quid des cas ou des variables globales sont vraiment nécessaire et ou tout marche bien car la plupart du temps les scénarios qui accèdent à cette variable ne sont pas lancé en même temps?

Merci d'avance pour vos lumières
Pierre

[kerdale]

variable locale pour un scénario c'est tag exemple
dans la case tag du scénario action=up
utilisable dans le scénario:
Si tag(action)="up"
alors ....
else ....
si pas de tag au lancement du scénario le tag sera =""

[Pierre_]

Les tags sont les paramètres d'un scénario non?
La je parles de variables qui auraient la même duré de vie que le scénario. Elles sont créées au lancement du scénario, détruites à la fin, et si le scénario est lancé deux fois en même temps, ce sont deux variables différentes qui ne communique pas entre elle.

[kerdale]

Oui mais tag est très puissant puisque le tag peut avoir comme valeur une variable globale
par exenple:
dans le lancement du scénario
tag: action=variable(v1) (avec variable(v1) mise à 1 ailleurs dans Jeedom (commande, scénario, calcul ...)
et dans le scénario (toujours un exemple à adapter)
si tag(action)=="1"
alors variable(v1)== "0" (bloque immédiatement le déroulement en double du scénario)
le sénario déroule la suite

else stop
par exemple
Avec v1 une variable globale qui peut etre manipulée ailleurs ou par exemple par le scénario lui mème en fin de job la remet à 1 pour revalider le scénario

Nota ce principe peut également etre utilisé sans les tag mais avec une variable globale destinée à permettre/interdire un scénario:
principe un peu identique
variable V1 valeur 0 ou 1 pour faire simple.
scénario:
premier bloc
Si variable(v1) == 0
alors
stop
Else
action variable(v1)=0
suite du scénar
à la fin
action variable(v1)=1
fin du scénar
il est pret à redérouler


Bon ça reste une rustine, trouver pourquoi le multilancement est effectif sans case cochée reste un todo pour la rentrée

[tomdom]

Bonjour,

Est-ce que ce problème ne se produit qu'à 3h00 du matin ou il se produit aussi à d'autres heures ?
Est-ce que c'est systématique à 3h00 du matin ?

[Pierre_]

@kerdale : Toi, tu viens d'émuler un sémaphore

@tomtom :
Bonjour,
à priori il ne s'est passé qu'une seule fois à 3h du matin.
J'avoue qu'après mon réveil à 3h du matin, j'ai juste dégagé le trigger qui a causé le double déclenchement pour ne pas prendre de risque.
En regardant les logs autour de 3h du matin, j'avais pu voir que le trigger Heliotrope en question se déclencher environ toutes les 5 minutes, sauf cette fois ci ou il s'était déclenché deux fois à la meme heure.
Il y a donc effectivement sans doute deux problèmes, Heliotrope déclenches deux triggers simultanement sur l'altitude du soleil dans certaines conditions et l'option de "Multi déclenchement" décoché n'empêche pas d'avoir deux instances du scenario en meme temps dans ce cas précis.

Je pars en vacance demain matin (le genre de vacance ou il n'y a vraiment pas internet), du coup je ne pourrais pas vous aider à affiner la repro, mais si tu as des idées de tests pour verifier quelque chose je m'en occuperais à mon retour.
Je dois pouvoir faire un scenario avec les meme triggers qui ne fait rien, pour voir si ça se reproduit, mais le log se vide trop rapidement pour pouvoir le lire aprés coup.

[Bercolly]

Bonjour,

1°) Variables globales

Utiliser des variables globales dans un environnement multi-threadé implique qu'ily ait des synchronisations , sinon l'exécution est imprévisible.
Donc dans le cas de Jeedom cela est à exclure !

2°) Multi lancement semble ne pas marcher :
j'ai regardé le code Jeedom. D'un premier constat, il ressort que le développeur vérifie qu'un scénario n'est pas en cours avant d'en lancer une deuxième instance. Pour cela le développeur s'appuie sur une variable du scénario dans lequel il indique un état d'exécution en cours. C'est une hypothèse d'exécution hasardeuse :
. d'une part, beaucoup de code est exécuté avant que cette variable soit positionnée, et donc rien n'empêche que plusieurs scénarios démarrent en même temps,

. d'autre part, il faudrait mettre en place un sémaphore (une sync) pour accéder à cette variable par un seul thread !

Je pense que le problème se situe, ici , dans la gestion un peu trop simplifiée d'un environnement multi-threadé.


A+
Bernard

[Mav3656]

Bonjour,

Je rencontre le même problème, et me pose exactement la même question.

J'ai un scénario de notification assez simple paramétré avec des tags. Le message final se construit dans une variable tout au long du scénario.

Ne sachant pas comment faire de variables locales à la fonction, j'ai décoché la case "multi lancement" pour contourner le problème. Mais cela n'empêche pas le scénario de se lancer plusieurs fois en même temps et les messages que je reçois ne sont pas cohérent.

Ce bug est-il connu d'autres personnes ? Est-il reconnu officiellement ? Est-il prévu qu'il soit corrigé ?

En attendant, est-il possible d'utiliser des variables locales ? Ce serait vraiment un + dans Jeedom de pouvoir faire ça. 2 moyens me viennent à l'esprit :
- pouvoir sélectionné une option "locale" ou "globale" quand on défini la variable avec le mot clé variable
- pouvoir déclarer et affecter une valeur à un tag dans un scénario (ce qui reviendrait à faire de la variable locale)

Equipe Jeedom, qu'en pensez-vous ?
Et comme je le dit toujours, bravo pour le travaille réalisé jusqu'à présent. Bonne journée à tous,
Mav3656

[Mav3656]

Quelques infos supplémentaires :

J'ai fait un test en créant un scénario, dans l'unique but de lancer 2 fois de suite mon scénario de Notification (celui que je veux empêcher de lancer 2 fois en même temps). J'observe des comportements très étrange que je vais essayer de décrire clairement. Pour info, j'appelle mon scénario avec un tag #message# dont la valeur est différente à chaque appel (mais il y a bien un message à chaque fois !).

Cas 1 : "Multi lancement" et "Mode synchrone" décoché
Quand je regarde les logs, je vois clairement que le scénario est appeler 1 fois sans tag et 1 fois avec mon 2ème message. Je ne reçois donc pas le contenu de mon premier message. De plus, dans ce cas, les 2 exécutions s'intercalent et le message reçu à la fin n'a pas de sens. Ce comportement est systématique (je peux fournir les logs et les scénario reproduisant ce comportement).

Cas 2 : "Multi lancement" coché et "Mode synchrone" décoché
Cette fois ci, on voit clairement dans les logs que chaque appel prend en paramètre le tag #message# avec la bonne valeur. (Ouf !). Par contre, les 2 exécutions s'intercalent toujours et le message reçu à la fin n'a toujours pas de sens. Ce comportement est systématique (ce sont les même scénarios que dans le cas 1 avec la case "Multi lancement" cochée dans mon scénario de Notification).

En conclusion, j'ai voulu décocher la case "multi lancement" pour empêcher l'exécution simultanée de mon scénario de Notification. Au lieu de résoudre ce problème, j'ai observé un autre problème ; la valeur du tag #message# de la première exécution est perdue.

Je précise qu'en mode synchrone, je reçois les bons messages 1 puis 2 dans le bon ordre. Sauf que ce n'est pas ce que je veux car ce scénario met un certain temps à notifier en fonction du contexte (sms qui ne part pas, message audio, ping et attente réponse pour savoir s'il y a internet, etc...)

Est-ce moi qui ai mal compris le sens de l'option "Multi lancement" ? N'est-ce pas sensé tout simplement mettre en attente le thread appelant le scénario si ce dernier est déjà en cours d'exécution dans un autre thread ?

Bonne journée à tous.

[PrFalKeN]

'jour,

A votre place je créerai un ticket...
Sauf si Loic lit ce poste et donnes déjà son ressenti vis à vis de ce que vous avez découvert.

[Mav3656]

'jour,

A votre place je créerai un ticket...
Sauf si Loic lit ce poste et donnes déjà son ressenti vis à vis de ce que vous avez découvert.

Merci pour votre avis. J'essaie parfois d'éviter de créer des tickets et de trouver des solutions pour contourner les problèmes rencontrés pour apporter des réponses aux autres également, mais je crois que je vais finir par suivre votre conseil.

[dukyduke]

Bonjour,

Il semble que j'ai le même problème.

Un scénario simple de notification d'évènement sur une camera Netatmo.
Case multi lancement décochée.
J'ai une variable globale qui conserve en mémoire le dernier évènement traité pour éviter de réagir 2 fois sur le même évènement.
J'ai en plus ajouté une pause de 1 minute à la fin par sécurité.

Généralement, ça fonctionne bien mais parfois j'ai 4/5 notifications à la suite.
Dans les logs, je vois bien les lancement de plusieurs scénario à la fois. J'ai donc une seconde exécution qui suit tout de suite la première alors que celle-ci n'a pas fini (tempo de 1 minute non écoulée, variable globale as encore mise à jour)

Bref avez-vous résolu vitre problème finalement ?

[korneo51]

Bonjour.
Même problème pour un scénario plus que basique. J'ai un Bp sur un GPIO de mon RPI et un relais.
J'ai essayé de faire différent scénario (toujours basique) mais je rencontrais des soucis. En regardant les logs, je m'aperçois que le scénar est lancé plusieurs fois, ce qui fait que parfois mon relais passe à 1 lors de l'appui et reviens à 0 lors du relachement...
Des solutions à ce soucis?

[Mav3656]

Bonjour à tous,

Je vais résumer ici le résultat de mon étude sur le sujet :

1ère partie : à quoi sert la case "mode synchrone"

Petite explication, mais sans faire un cours sur ce qu'est un appel asynchrone (je vous laisse regarder sur google pour ça si besoin) : lorsque vous appelez un scénario, vous avez le choix entre "start" (qui se veut faire un appel du scénario de manière asynchrone) et "start sync" (qui se veut faire un appel du scénario de manière synchrone). Pour faire simple, du point de vue utilisateur que nous sommes, si la case "mode synchrone" du scénario appelé est cochée, cela force l'appel du dit scénario en "start sync", même si vous essayez de l'appeler avec la méthode "start".

2ème partie : à quoi sert la case "multi lancement"

Si la case "multi lancement" est décochée, alors Jeedom empêche toute exécution concurrente. Explication : si le scénario est en train de tourner, alors tout appel pendant ce temps-là est tout simplement rejeté (confirmé par le support Jeedom, les appels ne sont pas rejoués plus tard, ils sont bien poubellisés).

3ème partie : un premier bug découvert si la case "multi lancement" n'est pas cochée

Observé par plusieurs d'entre-vous (c'est votre cas @dukyduke et @korneo51 et vous êtes loin d'être les seuls !) : la variable sur laquelle se base Jeedom pour dire "ça y est, le scénario est lancé, je dois empêcher tous les prochains lancements tant que le scénario n'est pas terminé" n'est pas "synchronisé". Comprenez ici que lorsqu'un autre thread viendra essayer de lancer le scénario, si cela se produit très rapidement, alors la variable n'aura pas encore été mise à jour en mémoire centrale. Le scénario n'aura pas encore connaissance de la nouvelle valeur, et, pensant que le scénario n'est pas en cours d'exécution, se permettra de lancer le scénario à nouveau !

Mauvaise nouvelle : en tant qu'utilisateur de la solution via l'interface web, je ne vois pas de solution pour contourner ce problème. Il faudrait que l'équipe Jeedom reconnaisse ce problème (qui est simple à mettre en évidence pour le coup) et prenne le temps de le corriger.

4ème partie : un deuxième bug découvert, cette fois-ci lorsque la case "multi lancement" est cochée (mince alors !). En cochant la case, on dit au système Jeedom que ce scénario a le droit d'être exécutée plusieurs fois en même temps.

Bug découvert : lorsqu'on appelle plusieurs fois en même temps un scénario avec des tags, alors les tags sont perdus pour certains des appels. Ce problème est observé uniquement lorsque le scénario est exécuté de manière asynchrone avec la méthode "scenario ->start".

J'ai fait un mail au support. Il faudrait également qu'ils reconnaissent le problème, et acceptent de le traiter. Pour l'instant on m'a répondu que c'était une limitation matérielle...pas cool. J'ai relancé Denis du support qui est très sympa, en fournissant des explications supplémentaires, à suivre !

5ème partie, une solution de contournement dans le cas où on a besoin de faire du "multi lancement" de manière asynchrone et avec des tags.
IMPORTANT : Cette solution se limite aux tags dont la valeur n'est pas évaluée par une variable. En effet, si un de vos tags est évalué par une variable, il y a de forte chance pour que la valeur de la variable ne soit plus la bonne lorsque le scénario sera effectivement lancé (le principe de l'asynchrone, rappelons-le, c'est qu'on ne sait pas quand est-ce que les instructions seront traitées, peut-être tout de suite, peut-être dans plusieurs secondes ou pourquoi pas plusieurs minutes en fonction de la charge à laquelle le système est soumis). Je ne m'étendrai pas sur ce sujet davantage pour ne pas noyer la solution proposée.

Et cette solution de contournement alors ? Et bien c'est tout simple..Puisque le problème n'est pas observé lorsque le scénario est appelé de manière synchrone avec la commande "start sync", alors commençons par l'appeler de cette manière ! (Rappelez-vous que vous pouvez aussi cocher la case "mode synchrone" dans le scénario appelé afin de forcer tous les appels qui lui sont fait à être synchrone). Ensuite, au moment de l'appel, là où vous faites l'appel au scénario avec "start sync", il vous suffit de cocher la petite case sur la gauche pour que cette instruction soit exécutée en parallèle des autres instructions (ce sont les 2 petits carrés sur la gauche de chaque instructions quand vous programmez un scénario, vous verrez une description apparaitre si vous passer votre souris dessus). Bingo, problème contourné.

Pour ceux qui ont suivi jusqu'ici, on vient de créer un nouveau thread qui lancera de manière synchrone un scénario paramétré avec des tags. On a donc, par rapport à notre programme de départ, réalisé un appel asynchrone à un scénario, en lui passant des paramètres.

6ème partie (bonus) : pour ceux qui souhaitent pouvoir modifier un tag pendant l'exécution d'un scénario, et ainsi faire des variables à portée "locales" - utilisez un bloc code et adaptez les lignes suivantes à votre utilisation (les lignes préfixées de // sont des commentaires et peuvent être modifiées/supprimées) - ATTENTION pensez à retaper vous même les apostrophes, si vous copiez-coller ces lignes (problème connu, renseignez vous !) :

Code : Tout sélectionner

// On récupère les tags stockées dans le scénario (ils sont tous là !)
$tags=$scenario->getTags();

// Définissez ici le nom du tag à modifier (pas obligatoire, permet juste de l'écrire une seule fois pour tout le bloc de code et ainsi d'éviter des erreurs) "monTagAModifier"
$tagToUpdate = '#monTagAModifier#';

// Mise à jour de la valeur du tag
$tags[$tagToUpdate] = 'maNouvelleValeur_mettezCeQueVousVoulez!';

// Si besoin, lorsque vous définissez la nouvelle valeur, vous pouvez utiliser l'ancienne valeur de votre tag avec : $tags[$tagToUpdate]
// Retenez que pour concaténer 2 chaines de caractères, il vous suffit de mettre un POINT entre les 2.
// Exemple : $tags[$tagToUpdate] = 'le préfix de mon choix '.$tags[$tagToUpdate].' le suffix de mon choix';

// Bien-sur, on termine par stocker ces nouvelles valeurs dans l'objet scenario pour que les instructions qui suivront dans ce même scénario puissent lire les nouvelles valeurs.
$scenario->setTags($tags);

Très bonne journée à tous.

[PrFalKeN]

Ouch ça c'est du rapport !
Je serai curieux de voir ce que Loic en pense...

[loic]

Bonjour,
Je suis d'accord avec toute l'analyse et tout est vrai dedans ainsi que les des bugs que l'équipe jeedom ou moi n'avons jamais cherché a cacher et qu'on nous reconnaissons pleinement. Malheureusement si c'était simple de les corriger ça sera déjà fait depuis longtemps. Il y a bien des possibilités mais ça fait une usine a gaz et ralenti fortement les scénarios donc je ne le ferai pas.

Par contre ce n'est pas indiqué clairement dans la documentation je me le note de rajouter ces 2 limitation dans la doc des scénarios pour que les utilisateurs suivant soient au courant.

[PrFalKeN]

Super merci Loic pour cette transparence

[loic]

J'ai peut être trouvé une demi solution au moins pour le multi-lancement, chez moi je n'arrive plus a reproduire le soucis (il y par contre toujours des cas ou ça peut arrivé sur un systeme pas forcement super rapide)

Pour le soucis des tags ca devrait aussi améliorer la situation je pense mais la chez moi j'ai jamais reussi a reproduire le soucis.

[solstice]

Hello Tous,

Je ne sais pas si cela peut aider certains.

J'ai rencontré le même problème de Multi-lancement d'un scénario provoqué par des mise à jour simultanées d'une donnée GPS.

Je m'explique. J'utilise l'application DomoWidget sur Android pour mettre à jour ma position GPS sur le plugin Géoloc. Dans le plugin Géoloc je calcule la distance par rapport à mon domicile afin de déclencher un scénario quand je suis à moins de 200m.

Mais pour une raison que je ne comprends pas, régulièrement je reçois une mise à jour multiple et simultanée de la position GPS, ce qui déclenche des lancements multiples et simultanées de mon scénario (2, 3 même 4 fois parfois). J'ai tenté toutes les options comme indiqué dans vos message sans succès.

Au final je suis parvenu à corriger mon problème en intervenant sur la données source bien avant le scénario. La propriété "Position GSM" du Plugin Géoloc qui reçoit la position GPS. Dans la configuration de la commande en modifiant l'option "Gestion de la répétition des valeurs" sur "jamais répéter". Et depuis plus aucun soucis chez moi.

Jeedom Répétition Valeur

2019-03-11 21_02_33-Jeedom répétition valeurs.png (55.67 Kio) Consulté 2557 fois

Au plaisir