Je ne crois pas:
1 « J'aime »
Salut,
Aucun soucis avec la Atlas, tout s’est bien passé pour moi
Bonjour,
dans la nuit de samedi à dimanche, en france, à 3h du matin, l’heure et passée à 2h du matin.
Le fuseau horaire de la France est passé de GMT+2 (heure d’été) à GMT+1 (heure d’hiver).
Voici une petite comparaison de l’heure système entre les box Smart et Atlas (Jeedom v4.1.25) :
Réglages > Système > Configuration > OS/DB > Administration Système
taper commande :
timedatectl
Smart (Debian Buster) :
Avant :
Local time: Tue 2021-10-26 16:28:28 UTC
Universal time: Tue 2021-10-26 16:28:28 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Après :
Local time: Sun 2021-10-31 08:36:00 UTC
Universal time: Sun 2021-10-31 08:36:00 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Atlas (Armbian Buster) :
Avant :
Local time: Tue 2021-10-26 10:48:12 CEST
Universal time: Tue 2021-10-26 08:48:12 UTC
RTC time: Tue 2021-10-26 08:48:14
Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
Après :
Local time: Sun 2021-10-31 09:38:31 CET
Universal time: Sun 2021-10-31 08:38:31 UTC
RTC time: Sun 2021-10-31 08:38:27
Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
Remarques :
- la time zone de la smart au niveau système n’est pas correcte. (et pourtant curieusement la « date système » indiquée dans la page santé de Jeedom et l’heure indiquée sur le bandeau de menus, en haut à gauche sont correctes !)
(autrement dit le système n’a pas la même heure que Jeedom) - la time zone de l’Atlas au niveau système est correcte. Après un reboot, la « date système » indiquée dans la page santé de Jeedom et l’heure indiquée sur le bandeau de menus, en haut à gauche sont correctes.
- l’Atlas dispose d’un module RTC.
- pour le service de temps, la Smart utilise le démon systemd-timesyncd (avec
NTP=time.cloudflare.com) et pas ntpd. C’est l’inverse pour l’Atlas.
akenad 
ARRGH!!! J’avais zappé la correction de @Loic l’année dernière… Donc tout scénario programmé entre 00h59 et 04h00 ne se lance pas 
comme la programmation quotidienne de mon chauffage qui est lancé à… 01h00.
Pas grave, l’Ile de France n’est pas l’Alaska et j’ai échappé au lanement des commandes toutes les 2 mn.
Je n’ai pas le souvenir de ce qu’il s’est passé les aures années, mais avec l’âge…
De base, le fuseau horaire de la Smart est mal ou n’est pas configuré.
Sur ma Smart pour après j’ai:
Local time: Sun 2021-10-31 10:33:34 CET
Universal time: Sun 2021-10-31 09:33:34 UTC
RTC time: n/a
Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Commande en ssh pour initialiser correctement la timezone:
sudo timedatectl set-timezone Europe/Paris
Cela permet d’avoir tous les logs sur le même fuseau horaire que les logs Jeedom.
Pas de cron jusqu’à 4h du matin … et 0 annonces aux dev
Pour info, tous mes plugins qui ont des informations horaires calculés en daily utilise le cronHourly pour se calculer à 3h du matin (et ainsi éviter de le faire à minuit comme fait cronDaily avec les mauvaises valeurs)
Résultat ce matin je constate que pas de mises à jour côté Héliotrope, Salat par exemple.
Ca faisait des années que mon paliatif marchait et paf à refaire
Merci pour l’info. J’avais fait en sorte de ne programmer aucun scenario entre 2H et 3H mais je vais revoir ma copie pour décaler ceux entre 00h59/2h et 3h/4h qui n’ont pas tournés cette nuit.
Pourquoi avoir pris une plage aussi aussi large ? Au cas ou le changement en se fait pas exactement à 3H ?
Sachant que 4h c’est trop tard pour calculer les levers du soleil pendant la phase du mois de juin par exemple. Donc effectivement tout stopper jusqu’à 4h …
1 « J'aime »
Hello,
J’ai également subit quelques soucis cette nuit. Déjà aucunes scénarios programmés c’est lancés. Logique de se que je lis pas de cron durant un lapse de temps.
J’ai également eu un soucis de chauffage avec thermostat en mode temporelle et re-execution des commandes par cron5. Le chauffage était probablement allumé au moment de l’arrêt du cron jeedom et est donc resté allumé jusqu’à notre réveil de ce matin. Un changement de consigne a rétabli le fonctionnement normale.
Brice.
Bonjour,
Tous les matins est lancée une tâche qui consiste à ouvrir les volets roulants de mon poulailler 5 minutes après l’heure du lever du soleil.
Un exemple de bon fonctionnement avec la log du Samedi 30 octobre 2021 :
[2021-10-30 08:17:03][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Maison][Meteo][Lever du soleil].
[2021-10-30 08:17:03][SCENARIO] Exécution du sous-élément de type [condition] : at
[2021-10-30 08:17:03][SCENARIO] Evaluation de la condition : [823 ] = 823
[2021-10-30 08:17:03][SCENARIO] Tâche : 35 programmée à : 2021-10-30 08:23:00
[2021-10-30 08:17:03][SCENARIO] Exécution du sous-élément de type [condition] : at
[2021-10-30 08:17:03][SCENARIO] Evaluation de la condition : [828] = 828
[2021-10-30 08:17:03][SCENARIO] Tâche : 56 programmée à : 2021-10-30 08:28:00
[2021-10-30 08:17:03][SCENARIO] Fin correcte du scénario
------------------------------------
[2021-10-30 08:23:02][SCENARIO] ************Lancement sous tâche**************
[2021-10-30 08:23:02][SCENARIO] Exécution du sous-élément de type [action] : do
[2021-10-30 08:23:02][SCENARIO] Exécution de la commande [Poulailler][VR][Up]
[2021-10-30 08:23:02][SCENARIO] ************FIN sous tâche**************
------------------------------------
[2021-10-30 08:28:03][SCENARIO] ************Lancement sous tâche**************
[2021-10-30 08:28:03][SCENARIO] Exécution du sous-élément de type [action] : do
[2021-10-30 08:28:03][SCENARIO] Affectation de la variable PositionVR => Position du VR = (99) = Position du VR = (99)
[2021-10-30 08:28:03][SCENARIO] Exécution d'un bloc élément : 57
[2021-10-30 08:28:03][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-10-30 08:28:03][SCENARIO] Evaluation de la condition : [99 < 80] = Faux
[2021-10-30 08:28:03][SCENARIO] Exécution du sous-élément de type [action] : else
[2021-10-30 08:28:03][SCENARIO] ************FIN sous tâche**************
------------------------------------
Et voici celui de ce matin **Dimanche 31 octobre 2021** :
[2021-10-31 08:18:03][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Maison][Meteo][Lever du soleil].
[2021-10-31 08:18:03][SCENARIO] Exécution du sous-élément de type [condition] : at
[2021-10-31 08:18:03][SCENARIO] Evaluation de la condition : [725 ] = 725
[2021-10-31 08:18:03][SCENARIO] Tâche : 35 programmée à : 2021-11-01 07:25:00
[2021-10-31 08:18:03][SCENARIO] Exécution du sous-élément de type [condition] : at
[2021-10-31 08:18:03][SCENARIO] Evaluation de la condition : [730] = 730
[2021-10-31 08:18:03][SCENARIO] Tâche : 56 programmée à : 2021-11-01 07:30:00
[2021-10-31 08:18:03][SCENARIO] Fin correcte du scénario
Ce matin, alors que l’heure du lever du soleil est prévue à 7h20, le scénario se déclenche à 8h18 (???), mais la tâche crée programme bien l’heure (7h25) mais pour le lendemain lundi 1er novembre 2021.
Et donc le volet roulant d’ouverture de mon poulailler est resté fermé. Heureusement que j’ai été alerté par une activité anormale dans le poulailler à mon réveil !
Je sens que le passage à l’heure d’hiver y est pour quelque chose, mais je n’arrive pas à comprendre le pourquoi du phénomène. Si quelqu’un à une idée, je suis preneur !
Voici mon scénario:
L’heure de lever du soleil a pas été rafraichie. Selon le plugin que vous utilisez, les infos n’ont pas ete mise a jour
2 « J'aime »
une bonne solution pourie serait de faire ton cron a 3h du matin tous les jour et à 4h05 en octobre et novembre, et cela pour faire simple et pas etre obliger de detecter le changement d’heure
Je croyais que cela n’impactait que Heliotrope mais je constate que le mal est plus profond…
Ca ira mieux demain mais ce serait bien d’avoir quand même une solution fiable pour un système domotique.
Je ne sais pas si les autres plateforme domotique rencontrent vraiment ce problème.
Merci Jeedom !
Bonsoir,
Pour le moment j’utilise héliotrope pour un spot d’éclairage, même souci, le spot n’est pas encore allumé… pourtant le « cron de calcul » tourne à 4h du matin.
D’une façon générale, si vous n’êtes pas satisfait du plugin héliotrope, faites les calculs des heures de lever et de coucher vous-mêmes.
De la sorte, vous maîtriserez l’heure de bascule d’une journée sur l’autre.
Plusieurs sujets ont été postés là-dessus.
Mais c’est un petit HS.
1 « J'aime »
salut
juste avant le couché du soleil ce soir , je n’avais pas les bons horaires indiqués dans Héliotrope
j’ai modifié la géocalisation pour la mettre en « configuration Jeedom »
La modification des heures s’est effectuée …
1 « J'aime »
À 3h07, le scénario qui programme les heures de lever et coucher ne s’est pas lancé ce matin. Donc, Jeedom est resté en mode « Nuit » toute la journée.
Du coup, j’ai décalé d’une heure, ce sera maintenant 4h07.
Sauf que si tu lisais le sujet, si tu fais tes cron qui font les calculs à 3h.
J’aime bien Déjà qu’utiliser le cronHourly en vérifiant si il est 3h ca fait tellement roustine
Faudra pas oublier de mettre le mois de mars au ban des punis aussi, peut etre que lui ca sera jusqu’à 5h ?
2 « J'aime »
Peut-être n’ai-je pas été suffisamment clair mais mon propos n’était pas de critiquer les plugins mais les utilisateurs qui veulent toujours que les plugins quelqu’ils soient s’adaptent exactement à leur propre besoin.
Donc, oui j’ai lu le sujet mais les critiques me fatiguent.