Je débute sur Jeedom avec un scénario pour la lumière pour le moment (wouhou).
Cet après midi une coupure de courant est intervenue dans la maison, puis le courant est revenu.
Le scénario lumière n’a pas démarré automatiquement.
Naivement, je pensais que cela serait le cas.
Quelqu’un pourrait-il m’orienter vers une procédure (ajout dans le scénario ? Création d’un scénario qui redémarre les scénarios ?) pour que lors de la ré alimentation de ma box smart jeedom tout redémarre ?
J’ai un peu cherché j’ai trouvé des choses sur comment allumer la box si elle ne démarre pas toute seule mais pas vraiment ce que je cherche
Merci !
Bonjour,
Un scénario se déclenche soit sur événement, soit sur programmation (planification)
Donc tout dépend ce que tu as mis comme déclencheur pour ton scénario lumière et tu comprendras pourquoi il n’a pas démarré ici.
En dehors des commandes info des équipements pouvant servir de déclencheur, il y a quelques événements particuliers que tu trouveras dans la doc (qui devrait être la première source de recherche ): https://doc.jeedom.com/fr_FR/core/4.0/scenario#Les%20déclencheurs
a tout hasard, le #start#
Un système Jeedom peut s’apparenter à ce qu’on appelle un séquenceur plus une base de données évidemment.
Comme tout séquenceur bien conçu, il doit avoir un état initial qui est connu.
Le meilleur moyen de le connaitre est de le fixer soi même, en cas de panne et retour de courant par exemple
Tu débutes et ton système ne va pas arrêter de s’étoffer, il y a des chances.
Une bonne pratique que je recommande est la suivante :
Créer un scénario, le mien s’appelle « Jeedom Start » qui est déclenché par l’évènement #start#.
Dans ce scénario, tu y mettras toutes les opérations d’initialisation de tes variables et lancement des scénarios que tu veux voir effectués à l’initialisation.
J’y ajoute également une opération de messagerie qui m’informe que mon système à redémarré.
Merci pour vos réponses,
A la lecture du message de Mips je me demandais s’il était plus intelligent de mettre un scénario de démarrage ou un #start# a chaque scénario !
Bonne soirée à vous, et désolé pour la question stupide, la doc est abondante et parfois je me perds!
Comme @Mips j’ai aussi un scénario « maitre » qui traite quelques actions au démarrage… C’est probablement la solution plus efficace, parce que tu n’auras jamais besoin de relancer chaque scénario mais surtout parce que tu pourras prendre en compte quelques conditions : redémarrage en pleine nuit versus en pleine journée par exemple.
Si on voulait faire les choses proprement : Il manque juste un truc dans Jeedom : stocker dans un coin l’équivalent d’un heartbeat (toutes les minutes avec date et heure) et de mettre à jour une info comme quoi l’arrêt est « normal » (à ajouter dans la classe jeedom)… Ainsi au redémarrage, avec la date du heartbeat et l’info, on sait déterminer si c’est normal ou pas et relancer des actions si besoin… En l’écrivant, je me rends compte qu’on doit pourvoir faire ça facilement…
Attention cependant, il me semble avoir lu dans un coin une histoire de « reprise automatique » des scénario lors que relance de jeedom avec un fenêtre dans 30 minutes en arrière. @Loic doit pouvoir confirmer ça et confirmer la version concernée…
Il faudrait comprendre comment fonctionne ton scénario lumière
Il n’est probablement pas utile qu’il se mette en route si tu as plusieurs heures de coupure.
L’idée me plaisait tellement que j’ai codé un petit truc qui permet de :
De connaitre la date du dernier arrêt et démarrage de jeedom
Savoir si l’arrêt de jeedom est volontaire et est demandé par Jeedom lui-même ou par l’OS (genre ligne de commande) ou s’il s’agit d’un plantage genre panne de courant (sans onduleur sinon c’est trop facile)
De savoir à quelques secondes quand le plantage a eu lieu
De déclencher uniquement certains scénarios qui en ont besoin au redémarrage suivant
Je fini de tester et je proposerai un PR … Pour les utilsateurs avertis, je peux partager les infos en PM.
Techniquement ça marche parfaitement… Il faudrait que je passe un peu de temps à préparer la doc d’install (car c’est pas si trivial à la main), et surtout que le PR risque d’être long à valider.
Bon j’ai fait une mini procédure d’installation v4 ou v4.1 uniquement … Forcement, j’ai testé chez moi, mais ça n’exclue une erreur ou un oubli. Donc à utiliser AVEC PRECAUTION et pour les utilisateurs avertis
Faire un backup de jeedom et le mettre en sécurité
Copier le zip sur jeedom (/tmp par exemple)
Dezipper et se placer dans le répertoire obtenu
Lancer le script d’intallation avec la commande sh -x sh -x installHB.sh ou bash -x sh -x installHB.sh si le shell n’est pas présent
Salut
Je viens d’essayer d’installer ton script mais sans succès.
Faire un backup de jeedom et le mettre en sécurité => OK
Copier le zip sur jeedom (/tmp par exemple) => OK
Dezipper et se placer dans le répertoire obtenu => OK
Lancer le script d’intallation avec la commande sh -x 13-heartbeat.sh => OK ou presque, le fichier contenu dans ton zip s’appelle installHB.sh, et il manque « ba » a l’instruction bash, donc j’ai tapé « bash -x installHB.sh »
En principe ça donne => Presque tout bon sauf a la fin, j’obtiens une erreur:
root@raspberrypi:/var/www/html/install# systemctl status jeedomtrigger.service
● jeedomtrigger.service - Jeedom Shutdown Trigger
Loaded: error (Reason: Invalid argument)
Active: inactive (dead)
Aug 19 18:47:26 raspberrypi systemd[1]: [/etc/systemd/system/jeedomtrigger.service:7] Executable path is not absolute, ignoring: php /var/www/html/install/initstop.php
Aug 19 18:47:26 raspberrypi systemd[1]: jeedomtrigger.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Aug 19 18:48:57 raspberrypi systemd[1]: [/etc/systemd/system/jeedomtrigger.service:7] Executable path is not absolute, ignoring: php /var/www/html/install/initstop.php
Aug 19 18:48:57 raspberrypi systemd[1]: jeedomtrigger.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Effectivement c’était bien ça, donc au final l’install s’est bien passée et ça fonctionne. Merci! Je te tiens au courant si je vois quoi que ce soit de bizarre.
Sur ton snapshot, tu as une info supplémentaire, le heartbeat je pense… Comment tu récupères cette info? et elle correspond a quoi?
Cool si ça fonctionne. C’est une bonne nouvelle. Je vais voir si je peux améliorer un peu le script d’installation pour tenir compte de ce path obligatoire. Quelle distribution utilises-tu, car sur mon pi4/Buster/Raspios 64b ça fonctionne très bien en l’état.
Quant au heartbeat, effectivement, c’est une info qui existe également config::byKey('lastHeartbeat')
Elle indique la dernière vérification de fonctionnement de jeedom.
Pour l’exploiter, c’est le même principe que pour les infos de démarrage/arrêt : virtuel + scénario de mise à jour.
Je suis par contre plus interrogatif sur son besoin de l’afficher en tant que tel :
ça impose de faire un scénario de mise à jour toutes les minutes => conso de ressources
ça n’apporte pas de précision supplémentaire en temps normal => si jeedom est fonctionnel alors l’info est mise à jour. Si jeedom est KO, l’accès à l’info n’est même pas possible…
On retrouve cette date si elle est importante au reboot suivant => elle sera utilisée par l’info arret avec la mention anomalie/OS/Jeedom
EDIT : script d’install modifié pour prendre en compte le chemin absolu
Ok, je ne voyais pas trop ce que ca pouvait apporter, tu le confirmes…
J’ai une config différente de la tienne: pi3B+ / Stretch.
Copie de ma page santé si tu as besoin de plus d’infos:
Oui pendant la phase de test, ça m’étais un peu plus utile, désormais mon virtuel ressemble à ça
Je note le comportement différent, en principe, le nouveau script d’installation trouve le chemin de php et l’exploite dans le service. Donc ça doit marcher pareil désormais.
Tu as testé les cas suivants ?
Reboot depuis Jeedom
Reboot depuis SSH
Coupure du courant
Les infos du Widgets remontent bien les différences ?
Dans le cas d’un reboot depuis Jeedom ou reboot SSH, j’obtiens les messages: LastStart « OS: date et heure du reboot » et LastStop « date et heure du redemarrage » (du coup c’est inversé, non?)\
Dans le cas d’une coupure de courant (arf j’aime pas faire ca), j’obtiens les messages: LastStart « Anomalie : date et heure du reStart » et LastStop « date et heure de LastStart + 1seconde ». Juste une seconde d’ecart apparemment alors que j’ai coupé pendant une quizaine de secondes je pense…