non j’ai récupéré sur le forum un script qui désactive les groupes de scénarios …
Je ne comprends pas bien ce que vous tentez de faire.
Puisque Loïc a dit qu’il mettait ce dans le côté
Si pb heure désactive scénarios et crons
Pourrait-on avoir plus de précisions sur ce qui ‹ remontera › ? Sans attendre le mois d’octobre 2021 ?
Où peut-on consulter la modification ?
Comme toute modification du code sur le github comme c’est le cas depuis les debut de jeedom
Bonjour,
J’ai trouvé une modification dans la version alpha.
du genre : new DateTime(‹ today midnight +1 day ›))->format(‹ I ›)
Pas certain que cela fournisse l’indication heure été/hiver si l’on ne fournit pas le timezone ?
Bonjour,
J’ai trouvé une modification dans la version alpha.
du genre : new DateTime(‹ today midnight +1 day ›))->format(‹ I ›)
Pas certain que cela fournisse l’indication heure été/hiver si l’on ne fournit pas le timezone ?
Je sais pas moi c’est que donne la doc php…
Tu peux toujours tester ce que cela donne.
Chez moi cela ne marche pas !
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 