La dernière exécution du scénario ne s'est pas lancée

Domatizer · Mai 11, 2020, 6:09

Bonjour,

J’ai remarqué que les scénarios sautent si le CPU est trop surchargé. J’ai des erreurs du style

[ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Mon simple scenario".

J’exécute pourtant mes scénarios seulement lorsque cela est nécessaire.

J’ai beaucoup de petits scénarios pour gérer 12/13 zones

24 pour les « minuteries » des portes (2 par porte)
68 pour la gestion de la présence (5 par zone)
26 pour les lumières principales (2 par lumière)

Le scénario prend toujours une seconde ou plus pour s’exécuter, c’est vraiment beaucoup pour faire si peu. Est-ce normal que cela prennent autant de temps ?

Pour une personne, en 2 secondes, on peut très bien quitter une pièce 1, fermer la porte, traverser le couloir, entrer dans une pièce 2, la traverser, ouvrir la fenêtre, fermer le volet battant à la main, fermer la fenêtre, et la lumière de la pièce 2 ne s’est toujours pas allumée.

Alors le soir, avec plusieurs personnes qui circulent dans le logement, la box est à genoux ! La domotique ne suit pas…
J’ai commencé à cocher le mode synchrone pour tous les scénarios d’allumage, ça accélère bien, mais je ne peux pas l’utiliser pour les scénario d’extinction. Ce mode fout le bazar dans les minuteries. Voir ici Mode Synchrone - #2 par Domatizer

Que peut-on faire d’autre pour optimiser les scénarios ?
S’il faut un NUC Intel Core i pour ouvrir une porte ou allumer une lumière, il y a un problème !

PS : je suis en train de regarder si je ne peux pas exécuter la logique domotique dans un automate software style CodeSys ou OpenPLC

iPapy · Mai 11, 2020, 6:13

Bonjour,

Comme pour toute demande un peu plus d’infos complémentaire serait utile!

Quelle version de jeedom, type de matériel, version d’OS ?
Une copie de la page santé pourrait peut être utile.

Sans cela tu risque de ne pas avoir beaucoup d’aide.

kiboost · Mai 11, 2020, 6:31

Et un peu de détails sur le scénario aussi, doit y’avoir moyen d’optimiser.

Domatizer · Mai 11, 2020, 7:07

Jeedom : 4.0.52
Matériel : RPi3b puis un vieux portable EeePC en attendant un RPi4b/4GB
OS : Debian Buster
Page santé : tout est au vert

Je scrute tous les log. C’est vraiment la charge CPU qui pose souci avec les scénarios. La nuit, pas de souci, il n’y a pas d’activité dans le logement. Mais en soirée, c’est la cata.

Avec le RPi3b, j’avais quelques ratés. J’ai voulu essayer avec un vrai PC que j’avais de dispo, mais c’est pire car il est moins puissant que le RPi. J’ai commandé un RPi4, donc j’espère ne plus avoir de avoir souci une fois reçu, mais la latence, peut-être moindre, sera toujours là.

Mais je m’interroge sur la charge CPU ainsi que la latence pour de si simples scénarios car c’est la base de la domotique

Typiquement pour une porte (x12) :

Le premier scénario ouvre la porte virtuelle dès que la porte réelle s’ouvre.
Le deuxième scénario ferme la porte virtuelle dès que la porte réelle est fermée depuis 35 secondes.

Déclencheur 1 : #[Bureau][Porte][Etat]# == 1
Scénario 1 :
SI #[Bureau][Porte][Etat]# == 1 ALORS #[Bureau][Porte][Ouvrir]#

Déclencheur 2 : #[Bureau][Porte][Etat]# == 0
Scénario 2 :
SI #[Bureau][Porte][Etat]# == 0 ALORS
WAIT #[Bureau][Porte][Etat]# == 1 TIME OUT 35
SI #[Bureau][Porte][Etat]# == 0 ALORS #[Bureau][Porte][Fermer]#

Si on ouvre et ferme la porte en quittant la pièce en 1 seconde, le scénario 1 ne marche même pas !
La condition #[Bureau][Porte][Etat]# == 1 lance le scénario mais le temps qu’il se lance, la vérification de la condition #[Bureau][Porte][Etat]# == 1 n’est plus valide. Il faudrait supprimer la condition #[Bureau][Porte][Etat]# == 1, mais ce n’est pas applicable pour les scénarios avec 2 conditions ou plus.

Je m’y prends peut-être pas correctement dans l’utilisation du scénario.
Mais je sais que je n’aurais pas ce genre de souci avec un automate.

Que peut-on faire pour que les scénarios s’exécutent à tous les coups quelque soit la charge CPU ?

[ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Mon simple scenario".

iPapy · Mai 11, 2020, 7:15

Tu utilise quoi comme capteur ?

Domatizer · Mai 11, 2020, 7:20

Que des modules Z-Wave Fibaro en non sécurisé :

Fibaro Door Sensor 2
Fibaro Motion Sensor
Fibaro Dimmer 2

kiboost · Mai 11, 2020, 7:21

Pas une bonne idée …

Domatizer · Mai 11, 2020, 7:29

Ouais je sais, mais je veux une minuterie précise de 35s !
Pas une truc à base de cron qui fonctionne à prochaine minute soit entre 1min et 1min59.
La fonction Dans fonctionne à la minute et pas à la seconde.

lunarok · Mai 11, 2020, 7:32

Si tu veux j’ai sortit sur le market Time Manager, qui s’appuie sur dkron. C’est in scheduler cc omme Cron mais a la seconde. Par contre ne fonctionne pas sur pi, mais tant que tu es sur du matos pc tu peux essayer.

Domatizer · Mai 11, 2020, 7:53

Super, dommage que je vais revenir sur le Pi.
Ton scheduler, c’est comme un SLEEP sans faire de SLEEP, mais ce n’est pas un WAIT.

Dans le WAIT, il y a une condition de sortie, c’est-a-dire si la porte s’ouvre avant les 35 secondes.
Sinon j’aurais mis un SLEEP de 35 secondes

Je précise que si la porte se ré ouvre entre temps, on sort du scénario de suite. Ainsi si on ouvre et ferme la porte toutes les 10 secondes, la porte virtuelle reste toujours ouverte.

En gros c’est la fonction TANT QUE, je que trouve compliquer à faire dans Jeedom.

On s’éloigne un peu du problème de départ qui reste la charge CPU avec les scénarios qui ne s’exécutent pas

axelpg · Mai 11, 2020, 7:58

Plutôt que des WAIT un « DANS » serait plus efficace.
A force de multiplier les pause, le système doit effectivement commencer à cracher ses poumons, surtout sur un eeepc.

Tu as vraiment besoin que ce soit 35 secondes ? 1 minute, c’est pas tellement plus et ça réglerai sûrement ton souci.

@ l’équipe de dev de jeedom : va falloir qu’on y passe un jour à la gestion de la seconde

Domatizer · Mai 11, 2020, 8:15

Je sais, je l’utilise aussi pour détecter les fenêtres ouvertes et fermées depuis X minutes.

Oui, il crache ses poumons.

La durée de mes capteurs de mouvement sont fixé à 30 secondes, je pourrais éventuellement les mettre à 55 secondes. Ensuite, je rajoute 5 secondes de marge, donc minuterie de 60 secondes pour les portes.
Mais ce n’est pas un Dans 1 min qu’il me faut, c’est un WAIT sans faire de WAIT ou un TANT QUE. Il me faudra toujours aussi d’autres TANT QUE de 5 secondes car je créé une présence virtuelle qui dure 5 secondes de plus que la durée du mouvement.

Et voire en dessous de la seconde pour les historiques, une porte qui s’ouvre et se ferme en moins d’une seconde, ça passe très mal. Le Z-Wave suit très bien la cadence mais pas Jeedom.

Pour un automate, c’est de la rigolade de genre de chose. Donc je trouve dommage qu’il faille autant de puissance CPU pour ça !

Domatizer · Mai 11, 2020, 10:29

Exemple d’un scénario (j’en ai 12 du même nom) qui est lent qui saute souvent (et ils n’ont pas de WAIT tous ceux qui ne s’exécutent pas bien)

------------------------------------
[2020-05-11 12:00:59][SCENARIO] La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution pour l'exécution à 2020-05-11 12:00:53.
------------------------------------
[2020-05-11 12:00:59][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Couloir Etage][Presence][Voisine].
[2020-05-11 12:01:00][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-05-11 12:01:00][SCENARIO] Mise à jour du tag #piece# => [Couloir Etage]
[2020-05-11 12:01:00][SCENARIO] Exécution du sous-élément de type [condition] : if
[2020-05-11 12:01:00][SCENARIO] Evaluation de la condition : [1 == 1] = Vrai
[2020-05-11 12:01:00][SCENARIO] Exécution du sous-élément de type [action] : then
[2020-05-11 12:01:00][SCENARIO] Log : Présence confirmée dans [Couloir Etage]
[2020-05-11 12:01:00][SCENARIO] Exécution d'un bloc élément : 1019
[2020-05-11 12:01:00][SCENARIO] Exécution du sous-élément de type [condition] : if
[2020-05-11 12:01:00][SCENARIO] Evaluation de la condition : [1 == 1] = Vrai
[2020-05-11 12:01:00][SCENARIO] Exécution du sous-élément de type [action] : then
[2020-05-11 12:01:00][SCENARIO] Log : Porte ouverte dans [Couloir Etage]
[2020-05-11 12:01:00][SCENARIO] Exécution d'un bloc élément : 1020
[2020-05-11 12:01:00][SCENARIO] Exécution du sous-élément de type [condition] : if
[2020-05-11 12:01:01][SCENARIO] Evaluation de la condition : [1 == 0 OU (1 == 1 ET 1 == 1)] = Vrai
[2020-05-11 12:01:01][SCENARIO] Exécution du sous-élément de type [action] : then
[2020-05-11 12:01:01][SCENARIO] Exécution de la commande [Couloir Etage][Presence][Ne pas confirmer]
[2020-05-11 12:01:02][SCENARIO] Fin correcte du scénario
------------------------------------

3 secondes pour faire 3 SI quand ça rame ! sinon c’est toujours 1 à 2 secondes en générale même avec le RPi3 et quelque soit le scénario !

Ici, je peux regrouper toutes les conditions en une pour faire un seul SI et virer les log. Je ne sais pas si les log font ralentir le scénario ? Mais pour le débug, c’est plus pratique de lire une phase que de traduire la condition [0 == 1 ET 1 == 1 ET (1 == 0 OU (1 == 1 ET 1 == 1))]

Domatizer · Mai 14, 2020, 8:41

J’ai revu un peu mes scénarios. Les scénarios pour la ventilation tournaient beaucoup trop souvent (à chaque remontée de température et de chaque pièce). Pour les scénarios de présence qui sont nombreux. J’ai regroupé tous les SI en 1 seul et viré tous les commentaires Log et rajouté plus de conditions dans les déclencheurs. Ils s’exécutent plus vite et un peu moins souvent : déclencheur plus complexe, 1 condition, 1 action.

Ainsi j’ai pu augmenter la vitesse d’exécution des scénarios et baisser la charge CPU depuis ces 2 derniers jours. À comparer avec une load max de 2.

Je n’ai quasiment plus de scénarios qui ne s’exécutent pas avec le EeePC, pas plus qu’avec le RPi3 et des scénarios mal optimisés. Donc lorsque je vais repasser sur un RPi4, je devrais être tranquille.

La commande htop montrait que l’utilisation CPU ne monte pas plus lorsque les scénarios sont en train de faire un « WAIT ». Je ne comprends toujours pas l’excitation générale lorsque quelqu’un utilise WAIT ou SLEEP. Il faudrait que l’équipe Jeedom trouve une fonction qui donne le même résultat sans bloquer le scénario.

Dans mon cas, lorsque le scénario est bloqué par un WAIT, ce n’est pas gênant, les conditions ne peuvent être réunies pour qu’il soit déclencher de nouveau. La porte doit s’ouvrir pour déclencher le scénario et être dans un WAIT qui attend au max 35 secondes que la porte se ferme. Il faut donc fermer la porte avant les 35 secondes qui mettra fin au WAIT et au scénario et la ré-ouvrir pour déclencher de nouveau le scénario.

J’avais aussi essayé l’option « synchrone », c’est effectivement plus rapide aussi, mais beaucoup d’effet de bords. Trop difficile à maîtriser pour moi.

Je savais que ce problème d’exécution de scénario non lancée est dû au CPU insuffisant. Mais j’aurais préféré une 2ème option multi-lancement qui relance le scénario à la fin (plutôt qu’en parallèle) du scénario déjà en cours d’exécution que de le jeter parce que le système n’a pas eu le temps de l’exécuter assez rapidement.