Nouvelle installation toute fraiche, avec accès local (web / ssh) et à jour.
Ok, je me demande si c’est pas lié à ce qu’on se dit en privée, si tu faisais des scènes très agressives toutes les 5 secondes avec insertion de donnée à chaque fois, est-ce que ça impacterait pas cette route d’affichage ?
Tu pourrais afficher l’inspecteur du navigateur et regarder au moment où tu switch de graphique ce qui se passe dans cette requête ?
Justement j’ai essayé plusieurs fois et je ne vois rien dans la console du navigateur.
Ok, c’est peut-être lié à DuckDB, je serais curieux de savoir si le souci persiste dans les prochaines heures maintenant que tu ne fais plus de scènes agressives toutes les 5 secondes.
Pour l’instant, les graphiques 1h sont toujours KO.
C’est fou ! Pour le coup il doit y avoir quelque chose de different sur ton instance parce que ça marche bien ça 
C’est fou oui !
Pourtant, j’ai tout installé proprement pour éviter ça 
24h plus tard, les graphiques sont toujours KO. 
Sûr que ce n’est pas un probleme d’horodatage ? Sur le 24h on va chercher toutes les valeurs depuis 24h avant, donc les dernières apparaissent et sont rendus avec la bonne heure car c’est l’affichage qui fait la traduction d’heure non ?
Mais sur le 1h, si y a 1h de decalage, il ne trouvera rien en db ?
@lmilcent, sur le 24h, tu n’aurais pas 1h de plus d’affiché à gauche du graph par hasard ? Sur les imprim écran que tu donnes ca débute à 15h pour finir à 9h … bizarre non ?
Aurais-tu des appareils qui donnent des valeurs moins fréquemment (pour avoir moins de points sur 24h) pour les données réelles et non agrégées !
alors moi c’est pas KO
mais il y a toujours des trou quand c’est sur 1 heure aussi
aussi bien devant que derriere le graph mais en 24 heure pas de souci
et pareil les capteur sont tous les meme donc je suppose que les remontes sont a peu pres sur les meme timing
Je pense avoir une piste.
Gladys est sur la timezone America/Toronto. En revanche le conteneur Zigbee2MQTT n’est pas lancé sur la meme timezone.
Je viens de tout reinstaller, avec restauration Gladys Plus. Donc les valeurs ont moins de une heure.
Si je verifie manuellement les dates dans les conteneurs :
Mais comme Gladys affiche les bonnes heures j’imagine qu’elle traite les dates en UTC.
SAUF QUE j’ai modifié la date dans le conteneur Zigbee2MQTT (avant la restauration), car mes thermostats sont mis a l’heure avec un message de Z2M. Donc ca me posait problème que z2m soit en UTC, l’heure de mes thermostats etait affiché en UTC.
1 « J'aime »
Hello,
je ne sais pas si ça rejoint ce soucis mais j’étais en GMT-04 pendant ces vacances d’hiver, téléphone en heure locale.
Lorsque je regardais les graphiques sur mon tél connecté en VPN chez moi, je voyais les graphs en GMT-04, soit avec un décalage de 5h par rapport au Gladys de la maison.
Le pic à 3000W sur la photo correspond au démarrage du cumulus à 22h00 mais montre un démarrage à 17h00 
Je voulais faire un post dédié à mon retour mais en voyant a dernière réponse de @lmilcent je me dis que c’est peut-être lié.
1 « J'aime »
@lmilcent,
Tu nous diras dans 24h du coup (enfin moins maintenant ^^)
Je pense que tu as raison. Le graphique affiche le dernier point a l’heure actuelle (vers 10h) et le premier point a l’heure de Paris (environ 16h, soit 10h locale + 6h).
Forcément l’affichage de la dernière heure ne fonctionne pas car c’est probablement décalé.
Pourtant Gladys est bien sur TZ=America/Toronto, j’ai manuellement appliqué ca aussi sur z2m, mais toujours la meme chose.
Oui, ca ne changera rien les reglages de z2m. La donnée en base de données est écrite par Gladys sur son created_at et updated_at. Gladys ne prend pas la valeur réelle de prise de donnée mais celle de l’ecriture en base.
On doit juste avoir un soucis de formattage sur la requête (prise en compte de l’heure locale … ou autre). Supposition, sans avoir regardé.
@pierre-gilles saura peut-être si cela vient de là.
1 « J'aime »
Top cool que vous ayez pu débugger tout ça 
@lmilcent Effectivement ça ressemble fort à un souci de timezone, trop cool qu’on ait enfin un utilisateur dans une autre timezone pour voir tout ces soucis 
A mon avis il y a un endroit de la stack ou la timezone est mal géré (ça peut-être côté front, côté back, côté DB), à voir d’où ça vient, si quelqu’un peut enquêter un peu 
Si non, je veux bien une issue Github et je me pencherais sur le sujet, mais ça sera pas tout de suite j’ai pas encore traité ma pile de todo qui s’est accumulé pendant mes congés comme d’habitude 
Salut @mutmut, c’est un autre sujet à mon avis
En général sur la plupart des applications c’est le comportement attendu, le frontend affiche dans ta timezone l’heure d’un évènement venant d’une autre timezone. Exemple: si un proche en vacances aux US t’envoie un message sur What’s App, tu verras l’heure d’envoie du message dans ta timezone et pas dans la sienne.
Dans le cas de Gladys, je pense qu’il faut réfléchir au cas par cas, par exemple pour les graphiques c’est vrai que ça se discute. Mais ça sort du scope de cette discussion, si tu veux qu’on en parle tu peux créer un sujet séparé ?
1 « J'aime »
salut @pierre-gilles , on peut faire un autre sujet sans problème, tu le déplaces ou on recrée ?