Ben aujourd’hui non c’est sur on est pas en changement d’heure… Mais j’ai testé dimanche et ca marchait.
Ok, autant pour moi, je testais avec une date en string et non avec ‹ today › ou ‹ now › qui contiennent le time zone.
Je continue à explorer la modification.
A quoi sert le test isDateOk() . Si on accède à un serveur de temps (bien configuré), la date est toujours exacte, c’est le but du jeu ! Il est possible d’ajouter l’adresse de la machine jeedom pour pallier le fait que le réseau est HS.
Le isDateOK() a pour effet de relancer sans cesse la synchronisation (provoque des erreurs ) voir ci-dessous :
Oct 25 02:04:30 rasppi-4 ntpd[2424]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
Oct 25 02:04:30 rasppi-4 ntpd[2424]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
A chaque arrêt/relance cela produit ces signalements :
Oct 25 02:03:14 rasppi-4 ntpd[1113]: unable to bind to wildcard address :: - another process may be running - EXITING
Oct 25 02:03:14 rasppi-4 systemd[1]: ntp.service: Main process exited, code=exited, status=1/FAILURE
Cela a priori ne sert à rien, car c’est le job du service NTP de synchroniser l’heure machine.
D’ailleurs on peut voir dans les logs qu’à 3h l’heure machine est repassée à 2h.
On pourrait (?) simplifier le code en faisant le test suivant :
si today == dernier dimanche d’octobre
et si heure comprise entre 02:00:00 et 02:29:59 et heure d’hiver alors ne pas traiter le scénario ( c’est le deuxième passage).
(Peut-être adapté la fourchette 2h/3h en fonction des différents time zone).
A+
Bernard
Tous les jeedom n’ont pas forcément de ntp ou internet et en plus redémarre pas forcément a l’heure où n’ont pas la bonne tant que la pile etc n’a pas fait son boulot
Sûrement pas en dur… Tout le monde ne change pas d’heure en même temps
C’est toi qui vois.
Mais c’est un faux problème car si pas d’internet ou de ntp tu n’exécutes pas cette séquence ! Non ?
Mais à quoi sert le isDateOk() ?
Il faut lire le tout. La fourchette pourrait être variable en fonction du time zone.
Petite parenthèse qui ne va pas résoudre notre problème actuel mais qui me permet de parer à ce genre d’éventualité. (Bien que je n’ai pas eu ce bug)
J’ai dès le départ de ma mise en place de Domotique créé un equipement Automate avec le plugin Mode, comportant les modes Automatique/Manuel/Arrêt, Et pour faire simple, tous mes scénarios en tiennent compte dès la première ligne. Si Automate != Automatique Alors Stop. Ça tient une ligne et ça sauve la vie quand on est un boulet comme moi 
Ça permet de passer en manuel et vice versa utra rapidement le temps du changement d’heure, ou quand on foire un équipement chauffage, alarme ou que sais-je, ou encore qu’on joue dans le coffret domotique, etc 
Salut
As-tu un exemple concret stp ?
Ah j’ai relu 2 fois la première condition, je pensais que tu t’étais un peu « lâché ».
Merci donc, j’ai appris un mot au passage : Le nycthémère
4 « J'aime »
En tout cas c’est clairement un problème lié au moteur de cron interne (surcouche) de Jeedom.
Je tourne sous Raspbian GNU/Linux 9.13 (stretch) et si il avait un aussi énorme bug dans la gestion de l’horloge sa se saurait 
Il faut rester honnête et dire que tu as édité ton message par la suite pour rajouter cette parenthèse…
Et cela ne sera toujours pas bon, renseigne toi sur le fonctionnement des timezone ce n’est pas toujours le même jour donc juste adapter l’heure ne fonctionne pas.
Je te signale que les différentes éditions d’un poste et son historique sont visibles par tout le monde.
Bonjour à tous,
Je rajoute ma petit pierre d’info sur ce qu’à mentionné Dom plus haut.
RPI 3B+ / Buster / jeedom v 4.0.61
Également eu mes scenarii avec déclencheur(s) temporel(s) d’exécutés entre 2h et 2h46 (pas de retentissement pour moi car ce sont des programmateur en grande partie).
J’ai eu le déclenchement toutes les minutes avec l’exécution complète du scénario, sauf pour ceux qui utilisent un #timestamp# dans les calcul, avec un log à ce moment tel que :
annulé car il utilise une condition de type temporelle et que la date système n’est pas OK
Bonjour Loic,
Je me permets d’intervenir dans cette discussion vu que mon arrosage automatique s’est déclenché toutes les minutes à 2h du mat jusqu’à 2h27. Cela s’est arrêté tout seul, je ne sais pas vraiment pourquoi (et ça ne nous a pas révéillés !). Il se déclenche normalement à 20h (scénario programmé).
En informatique, comme on le fait en avion d’ailleurs, il vaut mieux utiliser le temps UTC plutôt que le temps local d’une région. Le temps UTC, lui, ne recule ou n’avance jamais, ce qui évite tout problème de recalage. En France, nous sommes à UTC+2 en été et UTC+1 en hiver. La cron Jeedom devrait donc, selon moi, être gérée en UTC. Je me doute bien que cela doit avoir de grosses conséquences sur le code… De plus, à chaque changement d’heure, si on veut par exemple conserver l’ouverture des volets à 7h le matin local time, il faut que la cron indique 5h en été et 6h en hiver. Il faut donc traiter la modification de la cron à chaque changement d’heure. Gros avantage, si on a une tâche planifiée pour 2h30, en se basant sur l’heure UTC, elle ne s’exécutera qu’une fois. En local time, elle s’exécutera deux fois.
Bonne journée à tous,
Aurélien
Bonjour,
Tu as surement raison mais je n’ai pas les compétences ne serait ce que pour imaginer les conséquence sur le code ou même quoi modifier.
Pas totalement, c’est vrai pour les FPL, TAF, METAR NOTAM, (les non pilotes, cherchez pas) mais pas pour le commun des mortels, notamment pour les horaires d’avions, ce qui fait le bordel.
Oui, et en été tu ton réveil sonne à 6h, et en hiver à 7h, et tu te fais engueuler par ton chef parce que tu es en retard.
Eric
Hello, même soucis cette nuit à 2h du mat, j’ai cru que l’on jouait avec mon installation …
Tous mes volets se sont ouvert, etc en boucle,
La désactivation puis réactivation on résolu le soucis mais bon c’est pas top.
1 « J'aime »