Et après une coupure de courant?

Bonjour,

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 :wink:): https://doc.jeedom.com/fr_FR/core/4.0/scenario#Les%20déclencheurs
a tout hasard, le #start# :innocent:

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é.
:slightly_smiling_face:

2 « J'aime »

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!

Salut.

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…

Surtout pas car sinon tous tes scénarios seront lancés lors de chaque démarrage.

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.

Alternative : utiliser un onduleur :speak_no_evil:

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

image

Je fini de tester et je proposerai un PR … Pour les utilsateurs avertis, je peux partager les infos en PM.

6 « J'aime »

Ah oui, ça a l’air sympa ça. Tu nous tiens au courant quand tu auras avancé :wink:

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.
image

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

  1. Faire un backup de jeedom et le mettre en sécurité
  2. Copier le zip sur jeedom (/tmp par exemple)
  3. Dezipper et se placer dans le répertoire obtenu
  4. 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
  5. En principe ça donne
root@raspberrypi:/tmp/installHB# sh -x installHB.sh (ou bash -x installHB.sh si le shell n'est pas présent)
+ dirname installHB.sh
+ BASEDIR=.
+ ls /var/www/html/install/update/4.1.1.php /var/www/html/install/update/4.1.2.php /var/www/html/install/update/4.1.3.php /var/www/html/install/update/4.1.4.php /var/www/html/install/update/4.1.5.php /var/www/html/install/update/4.1.7.php
+ echo Version 4.1 ...
Version 4.1 ...
+ apply_patch heartbeat41.diff
+ to_patch heartbeat41.diff
+ sudo head -n 1 ./heartbeat/heartbeat41.diff
+ cut+  -d   -f 2
cut -f 1
+ tofile=/var/www/html/core/class/jeedom.class.php
+ sudo patch -N /var/www/html/core/class/jeedom.class.php
patching file /var/www/html/core/class/jeedom.class.php
Reversed (or previously applied) patch detected!  Skipping patch.
4 out of 4 hunks ignored -- saving rejects to file /var/www/html/core/class/jeedom.class.php.rej
+ install_all
+ echo Installation ...
Installation ...
+ sudo cp ./heartbeat/initstop.php /var/www/html/install/
+ sudo chown www-data:www-data /var/www/html/install/initstop.php
+ sudo echo [Unit]
+ sudo echo Description=Jeedom Shutdown Trigger
+ sudo echo DefaultDependencies=no
+ sudo echo Before=shutdown.target reboot.target halt.target
+ sudo echo [Service]
+ sudo echo Type=oneshot
+ sudo echo ExecStart=php /var/www/html/install/initstop.php
+ sudo echo [Install]
+ sudo echo WantedBy=halt.target reboot.target shutdown.target
+ sudo systemctl enable jeedomtrigger.service
+ sudo systemctl start jeedomtrigger.service
  1. Vérifier que jeedom fonctionne toujours…
  2. Pour créer un scénario spécifique et le lancer le nouveau déclencheur #start_error# est disponible (en plus du #start# classique)
  3. Pour afficher les infos dans un virtuel, les id des commandes info sont à obtenir : 8606 et 8607 chez moi

    et le scénario de mise à jour

A renommer .zip
heartbeat.zip.txt (3,3 Ko)

3 « J'aime »

Salut
Je viens d’essayer d’installer ton script mais sans succès.

  1. Faire un backup de jeedom et le mettre en sécurité => OK
  2. Copier le zip sur jeedom (/tmp par exemple) => OK
  3. Dezipper et se placer dans le répertoire obtenu => OK
  4. 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 »
  5. En principe ça donne => Presque tout bon sauf a la fin, j’obtiens une erreur:
root@raspberrypi:/tmp# bash -x installHB.sh
++ dirname installHB.sh
+ BASEDIR=.
+ ls '/var/www/html/install/update/4.1*.php'
+ ls /var/www/html/install/update/4.0.11.php /var/www/html/install/update/4.0.15.php /var/www/html/install/update/4.0.1.php /var/www/html/install/update/4.0.23.php /var/www/html/install/update/4.0.2.php /var/www/html/install/update/4.0.34.php /var/www/html/install/update/4.0.39.php /var/www/html/install/update/4.0.3.php /var/www/html/install/update/4.0.42.php /var/www/html/install/update/4.0.45.php /var/www/html/install/update/4.0.4.php /var/www/html/install/update/4.0.5.php /var/www/html/install/update/4.0.6.php /var/www/html/install/update/4.0.7.php
+ echo 'Version 4.0 ...'
Version 4.0 ...
+ apply_patch heartbeat40.diff
++ to_patch heartbeat40.diff
++ sudo head -n 1 ./heartbeat/heartbeat40.diff
++ cut -f 1
++ cut -d ' ' -f 2
+ tofile=/var/www/html/core/class/jeedom.class.php
+ sudo patch -N /var/www/html/core/class/jeedom.class.php
patching file /var/www/html/core/class/jeedom.class.php
+ install_all
+ echo 'Installation ...'
Installation ...
+ sudo cp ./heartbeat/initstop.php /var/www/html/install/
+ sudo chown www-data:www-data /var/www/html/install/initstop.php
+ sudo echo '[Unit]'
+ sudo echo Description=Jeedom Shutdown Trigger
+ sudo echo DefaultDependencies=no
+ sudo echo Before=shutdown.target reboot.target halt.target
+ sudo echo '[Service]'
+ sudo echo Type=oneshot
+ sudo echo ExecStart=php /var/www/html/install/initstop.php
+ sudo echo '[Install]'
+ sudo echo WantedBy=halt.target reboot.target shutdown.target
+ sudo chmod +x /etc/systemd/system/jeedomtrigger.service
+ sudo systemctl enable jeedomtrigger.service
Created symlink /etc/systemd/system/halt.target.wants/jeedomtrigger.service → /etc/systemd/system/jeedomtrigger.service.Created symlink /etc/systemd/system/reboot.target.wants/jeedomtrigger.service → /etc/systemd/system/jeedomtrigger.service.
Created symlink /etc/systemd/system/shutdown.target.wants/jeedomtrigger.service → /etc/systemd/system/jeedomtrigger.service.
+ sudo systemctl start jeedomtrigger.service
Failed to start jeedomtrigger.service: Unit jeedomtrigger.service is not loaded properly: Invalid argument.
See system logs and 'systemctl status jeedomtrigger.service' for details.

Controle du service:

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.

Et la je sèche… une idée?

1 « J'aime »

Salut.

À priori un souci de chemin.
Tu peux essayer de faire la commande : which php
Et adapter le chemin dans le fichier du service ?

Merci pour le retour ! Je note pour le point 4 (nom du fichier sh) mais en principe sh est shell également disponible

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?
image

Salut,

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

1 « J'aime »

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
image

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 ?

J’ai uniquement testé le reboot depuis Jeedom. Je teste les autres ce soir et je te tiens au jus.

Tests réalisés a l’instant:

  • 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…

Merci pour ces retours

Ouais là si tu n’as pas inversé les ID dans le scénario, j’ai du loucher sur le code… Tu peux vérifier ?

Là c’est plus troublant, 1 seconde c’est peu : c’est même pas le temps du boot. Je vais jeter un oeil voir si je comprend comment c’est possible