Déclencheur #start# non fonctionnel

Je n’ai pas réussi à redémarrer jeedom sous docker, il n’y a rien à faire. Ni le menu « redémarrer » ni « éteindre » qui n’éteint rien du tout Jeedom ne sait pas arrêter le container Docker dans lequel il est hébergé.
Dans le menu santé: Démarré OK 2020-12-02 22:06:10
Pourtant je l’ai redémarré en ligne de commande SSH sur le RPI sur lequel est installé Docker - et donc pas dans le container lui même - : docker container restart jeedom puis docker container ls
ab61d2ae5c6b docker-jeedom_jeedom "docker-php-entrypoi…" 5 weeks ago Up 7 seconds 0.0.0.0:80->80/tcp jeedom

Voila, pas mieux, donc en effet le déclencheur #start# n’est pas fonctionnel dans docker…

Merci à tous pour votre aide. J’essaye du coup l’alternative donne par @tomitomas

J’ai la requête http, le ficher sh, maintenant j’essaye de trouver comment et quand le lancer.
J’ai pas encore trouvé sur le démarrage de docker.
Et Dans le planificateur de tache du syno au demarrage c’est trop tôt car docker pas lancer. Mais je vais continuer d’essayer sur cette idée avec sleep dans min script.
Sauf qu’à force de jouer hier, j’ai eu peur d’avoir flingué mon jeedom. Ouf il est revenu après 3 redémarrages…
Du coup, je vais tout cleaner et refaire une install pour tester et après ré départ de 0 et restaurer une sauvegarde.

Merci encore de votre aide à tous

Bonjour! Je relance un peu le sujet car j’ai un problème qui se rapproche de celui évoqué plus haut.

J’ai créé un scénario qui descend les stores le soir. Celui-ci démarre tous les jours à 03:00 et le premier bloc est un bloc « A » dans lequel l’heure est fixée d’après l’heure de coucher du soleil.

Ce scénario fonctionne très bien sauf si je redémarre Jeedom durant la journée. (Je suis sur Raspberry Pi 4b). En effet, à ce moment, aucune tâche n’est plus programmée et elle le sort à nouveau quand mon scénario se réactivera à 03:00.

Afin de palier à ce problème, j’ai rajouté un déclencheur #start# en plus de la programmation mais mes stores ne se baissent pas malgré tout.

J’ai analysé le log et j’ai remarqué que la date est fausse au moment du démarrage de Jeedom, ce qui influe sur la date et l’heure du couché du soleil. Celle-ci est bien programmée mais dans le passé… Vous pouvez constater cela dans la copie du log ci-dessous: le 11.05 le scénario s’exécute correctement avec le lancement de la sous-tâche à l’heure prévue. Par contre sur les lignes suivantes on peut remarquer que la date du lot est en 2019 lors de l’exécution sur le start. Tout reviens ensuite normal lors de l’exécution programmée suivante.

Avez-vous une solution pour ajuster l’heure au démarrage. J’ai penser à insérer un wait mais je ne sais pas de combien de temps et j’aurais préféré une solution plus propre s’il en existe. Merci!

[2021-05-11 03:00:02][SCENARIO] Start : Scenario execute automatiquement sur programmation.
[2021-05-11 03:00:02][SCENARIO] Exécution du sous-élément de type [condition] : at
[2021-05-11 03:00:02][SCENARIO] Evaluation de la condition : [2113] = 2113
[2021-05-11 03:00:02][SCENARIO] Tâche : 9 programmée à : 2021-05-11 21:13:00
[2021-05-11 03:00:02][SCENARIO] Fin correcte du scénario
------------------------------------
[2021-05-11 21:13:02][SCENARIO] ************Lancement sous tâche**************
[2021-05-11 21:13:02][SCENARIO] Exécution du sous-élément de type [action] : do
[2021-05-11 21:13:02][SCENARIO] Exécution de la commande [Dressing][Store][Descendre]
[2021-05-11 21:13:02][SCENARIO] Exécution de la commande [Chambre][Store][Descendre]
[2021-05-11 21:13:02][SCENARIO] Exécution de la commande [Veranda][Store4][Descendre]
[2021-05-11 21:13:02][SCENARIO] Exécution de la commande [Chambre jaune][Store chambre jaune][Descendre]
[2021-05-11 21:13:02][SCENARIO] Exécution de la commande [Veranda][Store 5][Descendre]
[2021-05-11 21:13:02][SCENARIO] Exécution de la commande [Salon][Stores salon][Descendre]
[2021-05-11 21:13:03][SCENARIO] Affectation de la variable storessoir => 1 = 1
[2021-05-11 21:13:03][SCENARIO] ************FIN sous tâche**************
------------------------------------
[2019-02-14 11:13:03][SCENARIO] Start : Scenario execute sur evenement : #start#.
[2019-02-14 11:13:03][SCENARIO] Exécution du sous-élément de type [condition] : at
[2019-02-14 11:13:03][SCENARIO] Evaluation de la condition : [2116] = 2116
[2019-02-14 11:13:03][SCENARIO] Tâche : 9 programmée à : 2019-02-14 21:16:00
[2019-02-14 11:13:03][SCENARIO] Fin correcte du scénario

Bonjour,

Je vous propose une (presque) autre approche.

Vous créez un nouveau scénario, appelez-le : Relance démarrage (par exemple)
Déclencheur unique : #start#

Et dans ce scénario, vous faite un bloc DANS :

DANS : 1
Action : scenario => placez vos scénarios à relancer

Si 1 ne suffit pas, mettez 5 par exemple (c’est des minutes).

C’est très certainement que votre Pi n’arrive pas à se mettre à l’heure tout de suite. Vous avez laissé le serveur de synchronisation de temps par défaut dans Jeedom ?

2 « J'aime »

Bonjour! Merci pour votre réponse ultra-rapide!

Je vais essayer cette solution! Concernant le serveur de synchronisation je n’ai fait aucune modification et le champ de serveur optionnel est vide dans les réglages chez moi.

Bonne journée!

En principe cela devrais fonctionner, vous pouvez le tester à tout moment.

Avant de faire votre redémarrage de Jeedom, profitez en pour mettre à jour Raspberry Pi OS si vous ne l’avez jamais fait. Il est possible qu’une problème soit solutionné dans les mises à jour.

En SSH, faites :
sudo apt update && sudo full-upgrade -y

Et relancez après (soit en ssh par la commande : sudo reboot, soit depuis l’interface de Jeedom).

Re!

J’ai testé les différentes solutions. La mise à jour s’est bien passée mais n’a pas résolu le problème… J’ai ensuite créé le scénario relance démarrage qui s’exécute normalement mais toujours avec ce problème de date. Bien que j’ai ajouté le bloc « dans », Jeedom ajoute visiblement 5 minutes à la date située en 2019 donc cela ne résout rien :frowning:

[2019-02-14 11:13:03][SCENARIO] Start : Scenario execute sur evenement : #start#.
[2019-02-14 11:13:03][SCENARIO] Exécution du sous-élément de type [condition] : in
[2019-02-14 11:13:03][SCENARIO] Evaluation de la condition : [5] = 5
[2019-02-14 11:13:03][SCENARIO] Tâche : 187 programmée à : 2019-02-14 11:18:03 (+ 5 min)
[2019-02-14 11:13:03][SCENARIO] Fin correcte du scénario

Parallèlement, j’ai remarqué, depuis hier ou ce matin, que si je reboot Jeedom, celui-ci ne redémarre plus, à moins que je ne débranche l’alimentation (originale). Je mentionne ce problème ici car je en sais pas si cela peut être lié à ce problème de date?

Hier j’ai ajouté une clé bluetooth SENA à mon système. Je ne sais pas si cela joue un rôle mais c’est le seul changement récent. J’ai essayé de désactiver le protocole BLEA (qui fonctionnait déjà avant, avec un reboot qui fonctionnait aussi) et de débrancher la clé mais cela n’a pas permis un redémarrage autonome.

Merci encore pour l’aide

Salut,

De base, ça peut mettre jusqu’à 2 minutes avant de s’eteindre… Donc à verifier…

Ok pour ce scénario la

Mais, au bout des 5 minutes il doit relancer l’autre scénario, et ceux la doivent être a l’heure au bout de 5 minutes.

Il ne se sert pas de la date erronée pour calculer les cinq minutes ?
Un sleep avant le A doit résoudre le problème.

1 « J'aime »

Ha oui… Et du coup il ne se lance jamais !
- bien vue, merci

2 « J'aime »

Bonjour tous,
effectivement y a un bug avec le couple SYNOLOGY+DOCKER+JEEDOM

J’ai eu un bug avec mon dongle zwave et j’ai retourné toute mon installation dans tout les sens et effectivement le mot cle : #start# en provoqué ne fonctionne pas.

J’ai un scénario comme @Babasile mais qui doit envoyer une notification sur mon téléphone lors du reboot du jeedom et j’ai jamais rien reçu.

dans les logs y a que les lancements manuel

j’ai regardé le fichier /tmp/jeedom/started
il date du 15 novembre 2021 !!!
image

alors que j’ai redémarré tout mes systems, synology, conteneur et jeedom dans tous les sens.
j’ai réessayé a l’instant proprement via Jeedom => ‹ Réglages / Système / Redémarré › et rien j’ai toujours la date d’octobre 2021… :dizzy_face: