Graphiques et fuseaux horaires

Les graphiques semblent ne pas prendre en compte le fuseau horaire paramétré dans Gladys ce qui fait un décalage horaire des données (1 heure pour le fuseau Paris)

Ça doit être autre chose. Je n’ai pas ce problème.

Du coup, je ne sais pas d’où cela vient. Si je prend en compte ce graphique de ma batterie de portable, je serais partie vers 08h et revenu à 11h55.
image

Les enregistrements correspondant de la table t_device_feature_state sont les suivant :
image

L’heure de mon raspberry est correcte :
image

Et la configuration du fuseau horaire dans Gladys est bien GMT+1
image

Du coup, je ne vois pas ce qui fait que j’ai ce décalage d’une heure :unamused:

Intéressant @Tolkyen ! Par curiosité, tes valeurs viennent de quelle intégration?

Effectivement, il semble y avoir un décalage d’une heure.

Est-ce que tu pourrais ouvrir la console de ton navigateur sur le dashboard, faire un refresh et regarder la requête GET IP_DE_TON_PI/api/v1/device_feature/aggregated_states?

Et nous mettre la réponse JSON ici :slight_smile:

Je veux voir si c’est un souci côté serveur, ou un problème d’affichage du front

J’utilise l’application Presence Publisher pour le valeur de la batterie de mon téléphone et de ma présence.

Voici le JSON suite à la requête GET http://IP_DE_MON_PI/api/v1/device_feature/aggregated_states?interval=1440&max_states=100&device_features=mqtt-galaxynote9-battery
[HTTP/1.1 200 OK 86ms]

[{“device”:{“name”:“GalaxyNote9”},“deviceFeature”:{“name”:“Batterie Galaxy Note 9”},“values”:[{“created_at”:“2021-12-02T17:10:00.000Z”,“value”:54},{“created_at”:“2021-12-02T17:25:00.000Z”,“value”:53},{“created_at”:“2021-12-02T17:40:00.000Z”,“value”:52},{“created_at”:“2021-12-02T17:55:00.000Z”,“value”:52},{“created_at”:“2021-12-02T18:10:00.000Z”,“value”:48},{“created_at”:“2021-12-02T18:25:00.000Z”,“value”:47},{“created_at”:“2021-12-02T18:40:00.000Z”,“value”:46},{“created_at”:“2021-12-02T18:55:00.000Z”,“value”:44},{“created_at”:“2021-12-02T19:10:00.000Z”,“value”:42},{“created_at”:“2021-12-02T19:25:00.000Z”,“value”:41},{“created_at”:“2021-12-02T19:45:00.000Z”,“value”:40},{“created_at”:“2021-12-02T20:00:00.000Z”,“value”:40},{“created_at”:“2021-12-02T20:15:00.000Z”,“value”:39},{“created_at”:“2021-12-02T20:30:00.000Z”,“value”:39},{“created_at”:“2021-12-02T20:45:00.000Z”,“value”:38},{“created_at”:“2021-12-02T21:00:00.000Z”,“value”:37},{“created_at”:“2021-12-02T21:15:00.000Z”,“value”:37},{“created_at”:“2021-12-02T21:30:00.000Z”,“value”:37},{“created_at”:“2021-12-02T21:45:00.000Z”,“value”:36},{“created_at”:“2021-12-02T22:05:00.000Z”,“value”:34},{“created_at”:“2021-12-02T22:25:00.000Z”,“value”:34},{“created_at”:“2021-12-02T22:40:00.000Z”,“value”:34},{“created_at”:“2021-12-02T22:55:00.000Z”,“value”:35},{“created_at”:“2021-12-02T23:10:00.000Z”,“value”:45},{“created_at”:“2021-12-02T23:25:00.000Z”,“value”:55},{“created_at”:“2021-12-02T23:40:00.000Z”,“value”:74},{“created_at”:“2021-12-02T23:55:00.000Z”,“value”:84},{“created_at”:“2021-12-03T00:10:00.000Z”,“value”:92},{“created_at”:“2021-12-03T00:25:00.000Z”,“value”:100},{“created_at”:“2021-12-03T00:40:00.000Z”,“value”:100},{“created_at”:“2021-12-03T00:55:00.000Z”,“value”:100},{“created_at”:“2021-12-03T01:10:00.000Z”,“value”:100},{“created_at”:“2021-12-03T01:30:00.000Z”,“value”:100},{“created_at”:“2021-12-03T01:45:00.000Z”,“value”:100},{“created_at”:“2021-12-03T02:00:00.000Z”,“value”:100},{“created_at”:“2021-12-03T02:15:00.000Z”,“value”:100},{“created_at”:“2021-12-03T02:30:00.000Z”,“value”:100},{“created_at”:“2021-12-03T02:45:00.000Z”,“value”:100},{“created_at”:“2021-12-03T03:00:00.000Z”,“value”:100},{“created_at”:“2021-12-03T03:20:00.000Z”,“value”:100},{“created_at”:“2021-12-03T03:35:00.000Z”,“value”:100},{“created_at”:“2021-12-03T03:50:00.000Z”,“value”:100},{“created_at”:“2021-12-03T04:05:00.000Z”,“value”:100},{“created_at”:“2021-12-03T04:20:00.000Z”,“value”:100},{“created_at”:“2021-12-03T04:40:00.000Z”,“value”:100},{“created_at”:“2021-12-03T04:55:00.000Z”,“value”:100},{“created_at”:“2021-12-03T05:10:00.000Z”,“value”:100},{“created_at”:“2021-12-03T05:25:00.000Z”,“value”:100},{“created_at”:“2021-12-03T05:40:00.000Z”,“value”:100},{“created_at”:“2021-12-03T05:55:00.000Z”,“value”:100},{“created_at”:“2021-12-03T06:10:00.000Z”,“value”:97},{“created_at”:“2021-12-03T06:25:00.000Z”,“value”:93},{“created_at”:“2021-12-03T06:40:00.000Z”,“value”:91}]}]

Pourrais tu me montrer les valeurs de DB qui vont avec? Ou juste me dire si ces valeurs sont bonnes ou pas?

En fait je veux comparer si ces valeurs retournés par l’API sont bonnes ou au contraire déjà fausse, pour voir si le souci vient du backend ou du frontend :slight_smile:

Voici les valeurs de DB correspondantes :

  • table t_device_feature_state_aggregate
|54.0|2021-12-02 18:10:40.675 +00:00|
|53.0|2021-12-02 18:25:41.109 +00:00|
|52.0|2021-12-02 18:40:40.905 +00:00|
|52.0|2021-12-02 18:55:41.552 +00:00|
|48.0|2021-12-02 19:10:47.604 +00:00|
|47.0|2021-12-02 19:25:41.760 +00:00|
|46.0|2021-12-02 19:40:41.855 +00:00|
|44.0|2021-12-02 19:55:41.953 +00:00|
|42.0|2021-12-02 20:10:49.072 +00:00|
|41.0|2021-12-02 20:25:54.034 +00:00|
|40.0|2021-12-02 20:45:41.672 +00:00|
|40.0|2021-12-02 21:00:40.320 +00:00|
|39.0|2021-12-02 21:15:41.600 +00:00|
|39.0|2021-12-02 21:30:41.297 +00:00|
|38.0|2021-12-02 21:45:41.712 +00:00|
|37.0|2021-12-02 22:00:42.655 +00:00|
|37.0|2021-12-02 22:15:41.565 +00:00|
|37.0|2021-12-02 22:30:41.205 +00:00|
|36.0|2021-12-02 22:45:43.283 +00:00|
|25.0|2021-12-01 23:08:30.201 +00:00|
|22.0|2021-12-01 23:23:31.792 +00:00|
|22.0|2021-12-01 23:40:40.647 +00:00|
|22.0|2021-12-01 23:56:07.923 +00:00|
|26.0|2021-12-02 00:08:41.407 +00:00|
|25.0|2021-12-02 00:23:46.843 +00:00|
|33.0|2021-12-02 00:40:40.587 +00:00|
|40.0|2021-12-02 00:55:41.045 +00:00|
|42.0|2021-12-02 01:02:26.640 +00:00|
|42.0|2021-12-02 01:02:52.282 +00:00|
|42.0|2021-12-02 01:17:52.988 +00:00|
|50.0|2021-12-02 01:35:40.807 +00:00|
|65.0|2021-12-02 01:51:04.835 +00:00|
|80.0|2021-12-02 02:06:05.795 +00:00|
|89.0|2021-12-02 02:22:09.764 +00:00|
|96.0|2021-12-02 02:37:13.891 +00:00|
|100.0|2021-12-02 02:52:15.646 +00:00|
|100.0|2021-12-02 03:07:19.726 +00:00|
|100.0|2021-12-02 03:22:23.787 +00:00|
|100.0|2021-12-02 03:37:27.571 +00:00|
|100.0|2021-12-02 03:52:30.694 +00:00|
|100.0|2021-12-02 04:07:31.926 +00:00|
|100.0|2021-12-02 04:22:37.040 +00:00|
|100.0|2021-12-02 04:37:39.550 +00:00|
|100.0|2021-12-02 04:52:40.525 +00:00|
|100.0|2021-12-02 05:07:41.597 +00:00|
|100.0|2021-12-02 05:22:42.267 +00:00|
|100.0|2021-12-02 05:39:05.699 +00:00|
|100.0|2021-12-02 05:55:17.492 +00:00|
|100.0|2021-12-02 06:10:28.649 +00:00|
|100.0|2021-12-02 06:25:40.858 +00:00|
|100.0|2021-12-02 06:40:45.551 +00:00|
|100.0|2021-12-02 06:55:47.611 +00:00|
|99.0|2021-12-02 07:11:04.254 +00:00|
|97.0|2021-12-02 07:26:08.659 +00:00|
|94.0|2021-12-02 07:41:10.997 +00:00|
|94.0|2021-12-02 08:00:41.909 +00:00|
|80.0|2021-12-02 11:57:10.334 +00:00|
|79.0|2021-12-02 12:15:41.014 +00:00|
|78.0|2021-12-02 12:30:42.156 +00:00|
|74.0|2021-12-02 12:45:41.144 +00:00|
|54.0|2021-12-02 18:10:40.675 +00:00|
|53.0|2021-12-02 18:25:41.109 +00:00|
|52.0|2021-12-02 18:40:40.905 +00:00|
|52.0|2021-12-02 18:55:41.552 +00:00|
|48.0|2021-12-02 19:10:47.604 +00:00|
|47.0|2021-12-02 19:25:41.760 +00:00|
|46.0|2021-12-02 19:40:41.855 +00:00|
|44.0|2021-12-02 19:55:41.953 +00:00|
|42.0|2021-12-02 20:10:49.072 +00:00|
|41.0|2021-12-02 20:25:54.034 +00:00|
|40.0|2021-12-02 20:45:41.672 +00:00|
|40.0|2021-12-02 21:00:40.320 +00:00|
|39.0|2021-12-02 21:15:41.600 +00:00|
|39.0|2021-12-02 21:30:41.297 +00:00|
|38.0|2021-12-02 21:45:41.712 +00:00|
|37.0|2021-12-02 22:00:42.655 +00:00|
|37.0|2021-12-02 22:15:41.565 +00:00|
|37.0|2021-12-02 22:30:41.205 +00:00|
|36.0|2021-12-02 22:45:43.283 +00:00|
|34.0|2021-12-02 23:07:53.886 +00:00|
|34.0|2021-12-02 23:25:41.196 +00:00|
|34.0|2021-12-02 23:40:40.659 +00:00|
|35.0|2021-12-02 23:55:41.747 +00:00|
|45.0|2021-12-03 00:10:44.620 +00:00|
|55.0|2021-12-03 00:25:45.664 +00:00|
|74.0|2021-12-03 00:40:53.666 +00:00|
|84.0|2021-12-03 00:56:02.976 +00:00|
|92.0|2021-12-03 01:11:04.401 +00:00|
|100.0|2021-12-03 01:26:08.855 +00:00|
|100.0|2021-12-03 01:43:03.981 +00:00|
|100.0|2021-12-03 01:59:05.630 +00:00|
|100.0|2021-12-03 02:14:10.224 +00:00|
|100.0|2021-12-03 02:31:09.721 +00:00|
|100.0|2021-12-03 02:46:11.790 +00:00|
|100.0|2021-12-03 03:01:16.744 +00:00|
|100.0|2021-12-03 03:16:22.653 +00:00|
|100.0|2021-12-03 03:31:28.816 +00:00|
|100.0|2021-12-03 03:48:06.341 +00:00|
|100.0|2021-12-03 04:04:56.066 +00:00|
|100.0|2021-12-03 04:20:09.611 +00:00|
|100.0|2021-12-03 04:39:11.196 +00:00|
|100.0|2021-12-03 04:54:26.893 +00:00|
|100.0|2021-12-03 05:09:29.539 +00:00|
|100.0|2021-12-03 05:24:38.653 +00:00|
|100.0|2021-12-03 05:40:40.061 +00:00|
|100.0|2021-12-03 05:55:44.694 +00:00|
|100.0|2021-12-03 06:11:17.572 +00:00|
|100.0|2021-12-03 06:26:22.620 +00:00|
|100.0|2021-12-03 06:41:26.797 +00:00|
|100.0|2021-12-03 06:56:30.470 +00:00|
|97.0|2021-12-03 07:11:33.062 +00:00|
|93.0|2021-12-03 07:26:55.649 +00:00|
|91.0|2021-12-03 07:42:05.299 +00:00|
  • table t_device_feature_state
|54.0|2021-12-02 18:10:40.675 +00:00|
|53.0|2021-12-02 18:25:41.109 +00:00|
|52.0|2021-12-02 18:40:40.905 +00:00|
|52.0|2021-12-02 18:55:41.552 +00:00|
|48.0|2021-12-02 19:10:47.604 +00:00|
|47.0|2021-12-02 19:25:41.760 +00:00|
|46.0|2021-12-02 19:40:41.855 +00:00|
|44.0|2021-12-02 19:55:41.953 +00:00|
|42.0|2021-12-02 20:10:49.072 +00:00|
|41.0|2021-12-02 20:25:54.034 +00:00|
|40.0|2021-12-02 20:45:41.672 +00:00|
|40.0|2021-12-02 21:00:40.320 +00:00|
|39.0|2021-12-02 21:15:41.600 +00:00|
|39.0|2021-12-02 21:30:41.297 +00:00|
|38.0|2021-12-02 21:45:41.712 +00:00|
|37.0|2021-12-02 22:00:42.655 +00:00|
|37.0|2021-12-02 22:15:41.565 +00:00|
|37.0|2021-12-02 22:30:41.205 +00:00|
|36.0|2021-12-02 22:45:43.283 +00:00|
|34.0|2021-12-02 23:07:53.886 +00:00|
|34.0|2021-12-02 23:25:41.196 +00:00|
|34.0|2021-12-02 23:40:40.659 +00:00|
|35.0|2021-12-02 23:55:41.747 +00:00|
|45.0|2021-12-03 00:10:44.620 +00:00|
|55.0|2021-12-03 00:25:45.664 +00:00|
|74.0|2021-12-03 00:40:53.666 +00:00|
|84.0|2021-12-03 00:56:02.976 +00:00|
|92.0|2021-12-03 01:11:04.401 +00:00|
|100.0|2021-12-03 01:26:08.855 +00:00|
|100.0|2021-12-03 01:43:03.981 +00:00|
|100.0|2021-12-03 01:59:05.630 +00:00|
|100.0|2021-12-03 02:14:10.224 +00:00|
|100.0|2021-12-03 02:31:09.721 +00:00|
|100.0|2021-12-03 02:46:11.790 +00:00|
|100.0|2021-12-03 03:01:16.744 +00:00|
|100.0|2021-12-03 03:16:22.653 +00:00|
|100.0|2021-12-03 03:31:28.816 +00:00|
|100.0|2021-12-03 03:48:06.341 +00:00|
|100.0|2021-12-03 04:04:56.066 +00:00|
|100.0|2021-12-03 04:20:09.611 +00:00|
|100.0|2021-12-03 04:39:11.196 +00:00|
|100.0|2021-12-03 04:54:26.893 +00:00|
|100.0|2021-12-03 05:09:29.539 +00:00|
|100.0|2021-12-03 05:24:38.653 +00:00|
|100.0|2021-12-03 05:40:40.061 +00:00|
|100.0|2021-12-03 05:55:44.694 +00:00|
|100.0|2021-12-03 06:11:17.572 +00:00|
|100.0|2021-12-03 06:26:22.620 +00:00|
|100.0|2021-12-03 06:41:26.797 +00:00|
|100.0|2021-12-03 06:56:30.470 +00:00|
|97.0|2021-12-03 07:11:33.062 +00:00|
|93.0|2021-12-03 07:26:55.649 +00:00|
|91.0|2021-12-03 07:42:05.299 +00:00|

Apparemment, il y a bien un décalage

J’ai le même problème que toi et j’ai créé une issue Github https://github.com/GladysAssistant/Gladys/issues/1430

Alors ce n’est pas un bug (oui, oui ^^), mais juste un choix technique que j’ai fais suite à mes observations (qui peut-être re-challengé)

Chaque agrégation ne calcule les valeurs agrégées que pour la période précédant la période courante.

Pour l’agrégation horaire, ça calcule uniquement les heures qui sont déjà terminées.

Par exemple, si il est 14h50, l’agrégation horaire ne va calculer que jusqu’à la dernière heure « entièrement finie », c’est à dire jusqu’à 13:59:59.

Dans l’UI, le front n’affiche que les données agrégée, et donc sur les intervalles qui sont en heure, il y a une heure de retard car la dernière heure n’est pas encore agrégées.

Sur les intervalles en jour, il y a toujours un jour de retard.

J’avais fais des tests pour faire une requête qui fait une double requête: agrégées + données live, mais ça rendait pas beau du tout visuellement car les données live étaient naturellement plus fine que les données agrégées.

Ce qu’on pourrait éventuellement faire, c’est faire une agrégation « à chaud » lors du requêtage, mais avec un nombre d’évènement au pro-rata du temps passé sur l’interval en cours pour que les données soient au même niveau de « finesse » dans l’UI (sinon ça sera sale).

Après, ce sera un traitement plus lourd qui pourrait ralentir les requêtes donc à voir si ça vaut le coup, et je pense pas que ce soit aussi simple que ça d’avoir un rendu propre, j’ai peur qu’on voit la séparation entre les données agrégées et les données « live mais agrégées à chaud au pro-rata »

Je sais pas si c’est clair ?

Pour les données récentes y’aurai pas moyen de faire du 24h “glissant” mais avec un pas de 5 minutes ? ( comprendre recalculer plus souvent plutôt qu’à chaud )

Il faut tester si ça rend bien, mais le rendu sera forcément différent et ça peut se voir dans la courbe

Sur une vue 24h, on garde uniquement 100 valeurs. Donc 24*60 = 1440 minutes par jour / 100 = une valeur toutes les 14,4 minutes en moyenne

Le “en moyenne” est très important, car l’agrégation ne calcule par des points fixes (c’est pas un point tous les 14 minutes), mais essaie de faire 100 points dont la courbe sera la plus proche de la courbe avec tous les points.

Du coup si on augmente la fréquence de l’interval de calcul pour les dernière 24h, on a pas connaissance du “tableau général” de la journée, et on va forcément faire un rendu différent d’un rendu 24h réel.

Après je suis d’accord que la solution actuelle ça manque un peu ces données live sur ces intervalles.

En gros il faut coder le truc et faire différents tests, avec plein de jeux de données différents, pour voir ce qui marche le mieux visuellement… :slight_smile:

Je comprends, mais j’ai plus d’1 heure de décalage (Jusqu’à 2h59min de décalage).

A 10h23 ce matin, dernière donnée vers 9h (alors que la dernière agrégation a eu lieu à 10h20)
image

Effectivement, dans ce cas-là il y a peut-être un double problème dont un problème de timezone

Tu pourrais regarder en DB dans la table t_device_feature_state & t_device_feature_state_aggregate, et comparer avec ce que tu récupère dans le front ?

Histoire de voir si le problème il vient de la DB, du back ou du front ?

En fait tout va bien…
Si je prends un capteur qui envoie très régulièrement des états :

  • le dernier event est à 21h50
  • la dernière aggrégation horaire a eu lieu à 21h20 (pour les données jusqu’à 21h00)
  • le graphe frontend montre des données jusqu’à 21h00

Mon sentiment de retard venait de capteurs qui n’envoient pas des états régulièrement (parfois 1 état en 2 heures).

Tant mieux!

Après le fonctionnement peut-être amélioré je suis d’accord, avoir un mix de data live + agrégée dans l’UI ça serait cool.

Après dans le développement initial (qui avait déjà duré 2 mois si je me rappelle bien), j’avais pas réussi à faire fonctionner ça de façon propre aussi facilement que ça, et du coup j’avais mis de côté.

Si c’est une demande récurrente, je peux investir du temps dessus mais c’est vraiment pas un développement simple je pense