Bonjour à tous,
J’ai un petit souci avec le déclencheur #start# avec Jeedom en version 4.4.19, mais j’ai pu mettre en place une solution palliative que je vous expose ci-dessous.
Pour contextualiser ce problème, j’ai un petit scénario qui provoque tous les mois un reboot préventif de Jeedom, ce qui permet entre autre d’éviter certains problèmes potentiels…
Ce scénario est celui-ci (simplifié ici pour mes tests, mais le principe reste le même) :
Les déclencheurs :
Le principe est donc le suivant :
- périodiquement (tous les mois), le scénario se lance et comme le trigger n’est pas ‹ start › mais ‹ schedule ›, le test part sur la branche SINON et va déclencher un reboot après 15 secondes et un message d’alerte.
- Après le redémarrage de Jeedom, le scénario est donc redéclenché avec l’événement #start#, et vu que le trigger qui a déclenché ce scénario est cette fois ‹ start ›, il est censé me notifier par mail du redémarrage.
A priori, je ne vois rien qui pourrait ne pas marcher…
Le problème que j’ai constaté avec ce scénario :
La partie reboot périodique fonctionne très bien.
Exemple avec un reboot programmé ce jour à 10h34 sur mon RPi de test.
Par contre, après le redémarrage de Jeedom je ne reçois aucune notification comme prévu.
Le log du scénario montre ceci :
Et là, j’ai un peu de mal à comprendre ce qu’il trace exactement :
→ il se lance à 10:34:02, exécute le test (trigger = schedule) et lance donc la notification sous forme d’alerte et le reboot de jeedom à 10:34:17, soit 15 secs après. Ce qui est normal jusque là…
→ APRES le reboot, le log se complète en reproduisant exactement les mêmes traces avec les mêmes heures, sauf qu’il se termine avec cette ligne : [2024-11-11 10:34:21][SCENARIO] Fin correcte du scénario.
il n’y a donc pas de notification du redémarrage, et le déclencheur #start# n’est pas pris en compte. Il semble se contenter de recopier et compléter le log précédent, mais sans plus.
J’ai donc effectué quelques recherches et quelques tests complémentaires.
Mes tests démontrent que si l’ordre de redémarrage est externe au scénario, provoqué par exemple par :
- un ordre reboot envoyé en SSH,
- un ordre reboot envoyé par un scénario distinct (i.e. ce scénario est scindé en deux scénarios distincts, avec pour chacun son propre déclencheur : une programmation et l’autre avec #start#),
- ou un ordre reboot simulé par l’exécution par un autre scénario de ce code :
jeedom::event('start');(voir ici, merci à @Phpvarious pour cette astuce !) - un arrêt électrique.
→ dans tous ces cas, cela fonctionne bien comme prévu 
. Le trigger #start# est bien pris en compte, aucun souci, et le scénario envoie bien le mail :
J’ai testé aussi en modifiant un peu la syntaxe du déclencheur #start# :
Cette syntaxe ne sera valable qu’avec la prochaine version de Jeedom en v4.5 (voir ici), mais j’ai voulu en avoir le cœur net. Sans surprise, ça ne fonctionne pas en v4.4.19.
En résumé :
- si le redémarrage est dû à un événement externe : un ordre SSH, par un autre scénario, une perte d’alimentation,… c’est OK.
- si le redémarrage est dû à une programmation et qu’un seul scénario gère les deux actions : c’est KO.
Solution palliative :
Pour éviter ce comportement, il suffit donc de scinder ce scénario en deux parties :
Scénario 1 :
- déclencheur = programmation récurrente
- scénario = envoi d’une notification et reboot.
Scénario 2 :
- déclencheur = #start#
- scénario = envoi d’une notification du redémarrage.
Pour info, la page santé de mon Jeedom de test (certains plugins sont désactivés) :
(Jeedom et Debian 12 sont bien à jour).
Est-ce que quelqu’un a pu constater le même comportement de ce déclencheur dans ce cas particulier, et est-ce normal ? Doit-on s’attendre à la même chose avec la future v4.5 ?
Merci !
