Bonjour,
Je voudrais vous soumettre un petit problème que je rencontre avec le lancement d’un scénario.
Celui ci est en mode provoqué et il se déclenche sur un capteur de mouvement.
Mon problème est le retard entre l’évenement « présence » et le « Start » du scénario. Environ 8 sec.
Voilà le log :
[2021-07-04 18:52:04][INFO] : Evènement sur la commande [Maison][Salon][Présence] valeur : 1
[2021-07-04 18:52:12][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Jour] déclenché par : [Maison][Salon][Présence]
Un deuxième test :
[2021-07-04 19:36:04][INFO] : Evènement sur la commande [Maison][Salon][Présence] valeur : 1
[2021-07-04 19:36:12][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Jour] déclenché par : [Maison][Salon][Présence]
Voici le log du scénario [Déclencheur_Jour]
------------------------------------
[2021-07-04 19:36:12][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Maison][Salon][Presence].
[2021-07-04 19:36:13][SCENARIO] Exécution du sous-élément de type [action] : action
[2021-07-04 19:36:14][SCENARIO] Pause de 30 seconde(s)
[2021-07-04 19:36:44][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-07-04 19:36:44][SCENARIO] Evaluation de la condition : ["Jour" == "Jour"] = Vrai
[2021-07-04 19:36:44][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-07-04 19:36:44][SCENARIO] Lancement du scénario : ActionsAlarmeON options : []
[2021-07-04 19:36:44][SCENARIO] Fin correcte du scénario
------------------------------------
C’est sans doute pas top (j’ai un Raspberry PI Zéro W) mais les temps de réponse des pages Web Jeedom sont nickels.
Je ne mets pas en cause le capteur car j’ai bien vu l’icone de présence du capteur sur le dashboard changer environ 5 sec après l’événement physique - donc ce qu’indique le log.
Pour comparaison, j’ai un benchmark de 9 sur un pi3b+ (et c’est pas extraordinaire).
Donc là un benchmark de 55 y’a comme un souci. Comme l’a dit fabrice, c’est peut-être la cause.
Ca ne le fait que sur ce scénario ?
Merci pour vos réponses.
Globalement il s’agit d’une alarme et le PI 0 ne fait que ca.
En gros 1 capteur de porte et 2 capteurs de présence.
Les 30 sec c’est une tempo pour avoir le temps de désarmer l’alarme via une clé Keyfob Fibaro qui se trouve dans la maison (je peux aussi désarmer l’alarme avec un déclencheur bâti avec un virtuel Jeedom)
Donc le process :
déclenchement de l’évènement (capteur de présence = 1)
ca déclenche le scénario « Declencheur_Jour » (et/ou Déclencheur_Nuit d’ailleurs car ce ne sont pas les mêmes capteurs… je ne rentre pas trop dans le détail).
j’attends 30 sec
je teste au bout de 30 sec une variable (Etat_Alarme) - si elle vaut OFF ==> on a désarmé l’alarme : tout va bien !
si c’est « Jour » ==> vrai alarme → on déclenche le scénario ActionAlarmeOn qui gère les actions à prendre (activation sirène, envoie SMS, …).
Donc rien de sorcier
8 sec, même si ca rame, c’est énorme tout de même.
Bon après c’est plus pour comprendre. Si ca fait systématiquement 8 sec, je peux aussi fixer mon délai à 22 sec au lieu de 30 et j’aurais le même résultat.
@Fabrice : quand vous dites : Honnêtement, je vois bien 8 secondes, mais on ne vois pas ce scénario.
→ il s’agit du scénario Declencheur_Jour - c’est vrai que j’ai fait une copie d’écran de Declencheur_Nuit - mais ce sont les 2 deux mêmes.
La log que j’ai mise en premier est issue du menu « Analyse »/« Temps réel » → les deux lignes (18:52:04 et 18:52:12) se suivent dans cette log du coup
La log du scénario est issue du bouton « log » dans le scénario « Declencheur_Jour »
@drs : je ferais un test demain avec un autre scénario et vous dirais si c’est pareil. Mais des scénarios je n’en ai pas beaucoup …
Pour info, quand je clic sur ma variable d’état
par exemple là si je clic sur le bouton de gauche, je passe à l’état " déclenchée" en ~1 à 2 sec.
Liste complète des scénarios mis en place dans Jeedom:
Si Jeedom est dessus, c’est beaucoup.
Un pi zéro c’est vraiment une toute petite machine.
Edit :
Ca (ci-dessous), ce n’est pas le log du scénario. La rétention des 8 secondes provient de quoi ?
[2021-07-04 19:36:04][INFO] : Evènement sur la commande [Maison][Salon][Présence] valeur : 1
[2021-07-04 19:36:12][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Jour] déclenché par : [Maison][Salon][Présence]
Si par exemple, vous placez la commande : [Maison][Salon][Présence] en déclencheur du scénario, quel est alors le délais ?
Car le log du scénario que je vois (1er message, 3eme log) tout est fluide.
Bonjour,
La log que vous avez reprise (les deux lignes) proviennent de la log temps réel - donc un mixte entre les évènements et les déclenchement des scénarios. Ce n’est en effet pas la log du scénario.
Par exemple, je viens de refaire un test et j’ai :
[2021-07-05 **13:31:57**][INFO] : Evènement sur la commande [Maison][Salon][Présence] valeur : 1
[2021-07-05 **13:32:01**][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Nuit] déclenché par : [Maison][Salon][Présence]
[2021-07-05 13:32:01][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Jour] déclenché par : [Maison][Salon][Présence]
[2021-07-05 13:32:28][INFO] : Evènement sur la commande [Maison][Salon][Présence] valeur : 0
[2021-07-05 **13:37:02**][INFO] : Evènement sur la commande [Maison][Salon][Présence] valeur : 1
[2021-07-05 **13:37:13**][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Jour] déclenché par : [Maison][Salon][Présence]
[2021-07-05 13:37:13][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Nuit] déclenché par : [Maison][Salon][Présence]
Donc une fois 4 sec, et le deuxième déclenchement 11 sec.
C’est ce laps de temps entre l’évènement et le run du scénarion qui m’interpelle.
Mais vu la différence ici (4 sec, 11 sec) on peut peut-être en conclure que ca vient du Pi Zéro.
Mais bon, c’est surprenant quand même il me semble.
Note: les scénarios [ALARME][Maison][Declencheur_Nuit] et [ALARME][Maison][Declencheur_Jour] sont déclenchés tous les deux car ils ont les mêmes évènements.
Le déclenchement se fait quand [Maison][Salon][Présence] vaut 1
Et pour répondre à votre dernière remarque :
Si par exemple, vous placez la commande : [Maison][Salon][Présence] en déclencheur du scénario, quel est alors le délais ?
c’est justement [Maison][Salon][Présence] qui sert directement de déclencheur du scénario :
Bon j’ai installer mon Jeedom sur un Raspberry PI 3 → benchmark total ~11 (au lieu de 55)
J’ai pris la carte SSD du PI Zéro que j’ai mise dans le PI 3
Et c’est mieux côté temps entre évènement et activation du scénario:
[2021-07-05 **21:36:03**][INFO] : Evènement sur la commande [Maison][Salon][Présence] valeur : 1
[2021-07-05 **21:36:03**][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Jour] déclenché par : [Maison][Salon][Présence]
[2021-07-05 21:36:03][INFO] : Exécution du scénario [ALARME][Maison][Declencheur_Nuit] déclenché par : [Maison][Salon][Présence]
Donc c’est bien la puissance du matériel qui est en jeu. Après c’est déjà bien que Jeedom tourne sur un PI Zéro W. En fonction de ce que l’on recherche (minimiser les coûts sans être trop pressé) c’est bon à savoir.
Oui, le Pi Zero, ce n’est pas top du tout, tu peux l’oublier si tu veux du temps réel. Pour Jeedom, il faut une machine assez puissance, point barre ! Sur ton benchmark, il faudrait multiplier ta puissance de calcul au moins par 5 (un RPi3 au minimum).
Je constate également que le délai entre le déclenchement du scénario et l’exécution du scénario est important. Avec le Pi4, j’ai trop de latence, genre 2 secondes entre la détection du capteur PIR et l’allumage de la lumière. Avec le NUC i3, l’exécution se fait en une fraction de seconde, c’est acceptable, mais je trouve un peu dommage qu’il faille une telle puissance pour faire de la logique séquentielle basique.
Je ne comprends pas, j’ai des pi 3 et 4 et le déclenchement d’un scénario et son action ne prend pas une seconde.
Cas d’usage, pression sur un télécommande rfxcom et allumage par scénario d’une prise rfxcom.
Je pense que ça dépend des besoins, avec 150 scénarios dont une bonne partie qui doit pouvoir, si besoin, s’exécuter en parallèle, les RPis ça ne suffit plus.
A voir les résultat du benchmark, j’ai l’impression que le soucis provient essentiellement des accès (surtout les écritures) disques.
Les « write » et « read » cache sont des accès dans /tmp.
Les modifications (write, update, delete) sont pénalisées par les écritures disque car les commit ne retournent que lorsque les données sont figées sur disque.
Les lectures de db sont rapides car la DB garde du cache en mémoire.
Ben je crois qu’il faut pas chercher beaucoup plus loin.
En plus, nombreux sont ceux qui ont eu des problèmes de carte SD défectueuse avec jeedom (j’en fait partie ) car jeedom effectue beaucoup d’écriture et les cartes SD aiment pas beaucoup ça.
) car jeedom effectue beaucoup d’écriture et les cartes SD aiment pas beaucoup ça.