Synchros d'horloges, fuseaux horaires et changement d'heure ét

[Boudu34]

Je compatis, mes bons petits amis mais je suis hors de ces problèmes !

Mon grand-père, scientifique du siècle dernier, m'a apris à huit ans que la seule heure valable pour nous était l'heure GMT (Appelation d'Origine Contrôlée !)

Depuis que ma 2300 est en service, une bonne dizaine d'années, elle est à la seule heure universelle, la GMT.

Je me moque totalement des pitreries économico-politiques (le changement d'heure n'a jamais rien économisé !) et elle m'enregistre sans faille ses données 24 h sur 24. Excel est là ensuite, pour tout traiter graphiquement à la minute près, sans l'aide d'un quelconque vendeur de gris-gris qui propose des traitements superfétatoires dont on n'a absolument pas besoin.

Le siècle de la consommation est en marche ... avec ses inepties ...

-

[mm91]

Oui, il y en a un bien sûr! Voici le graphique Wswin, mais c'est idem sur Weatherlink ( je rappelle que chez moi, Wswin est en mode surveillance de fichier et il est donc tout à fait normal que le comportement des 2 logiciels soit le même)

(pas obligé; voir mes remarques précédentes).

Les 2 logiciels relient simplement par un segment le point mesuré à 1h50 à celui mesuré à 3h00, aucune mesure n'existant entre les 2 points. On le voit encore mieux avec les points de la direction du vent : aucune valeur affichée entre 2h et 2h50.

.................................

Dur dur….

je te demandais s'il y avait un saut sur l'échelle du graphique.

(l'échelle (des x) c'est les graduations et les chiffres sur la ligne horizontale, en bas).

Eh bien je constate que ton échelle est parfaitement continue.

Comme la mienne puisque c'est Wswin32

Mais c'est l'échelle correspondant au tableau (à weatherlink) qui m'intéressait.

Mais ce n'est pas grave car maintenant j'ai compris ce que tu montrais.

(c'est ce que je suis en train de chercher dans mes propres enregistrements (HW et Wswin32)

Mais ma (nouvelle) théorie se précise:

(à confirmer bien sûr, je n'oublie pas que ma première théorie était fausse !...)

Au changement d'heure l'informaticien (celui qui fait les logiciels) à le choix:

- 1/ soit,

il change d'heure sur l'échelle;dans ce cas, suivant le sens du changement il y aura deux fois les mêmes heures sur l'échelle (un recoupement) ou un espace plus grand entre deux heures.

Dans ce cas les graphiques (les courbes) seront continues (et rien n'est perdu)

- 2/ soit,

il est obligé:

dans un sens: de redoubler les mesures (on verra un saut sur les courbes si c'est sur une variation, comme sur mon exemple), ou d'en supprimer (pour des raisons esthétique ?), ce qui est plus grave (*) !

dans l'autre sens: de tirer un trait droit (comme sur ton exemple)

Je crois bien que c'est le choix 2/ qui est toujours fait.

Mais personnellement j'aurai préféré le choix 1/ :

aucune perte de données, aucun saut sur les courbes, quitte à avoir une échelle pas très claire (*)

(*) ce sont des pertes sur les graphiques, mais rien ne prouve que toutes les données (en interne dans le programmes) ne sont pas utilisées pour les records, les statistiques, etc…

Ca reste à vérifier…

Je continue mes investigations.

[mm91]

Je compatis, mes bons petits amis mais je suis hors de ces problèmes !

Mon grand-père, scientifique du siècle dernier, m'a apris à huit ans que la seule heure valable pour nous était l'heure GMT (Appelation d'Origine Contrôlée !)

Depuis que ma 2300 est en service, une bonne dizaine d'années, elle est à la seule heure universelle, la GMT.

Je me moque totalement des pitreries économico-politiques (le changement d'heure n'a jamais rien économisé !) et elle m'enregistre sans faille ses données 24 h sur 24. Excel est là ensuite, pour tout traiter graphiquement à la minute près, sans l'aide d'un quelconque vendeur de gris-gris qui propose des traitements superfétatoires dont on n'a absolument pas besoin.

Le siècle de la consommation est en marche ... avec ses inepties ...

-

Ah, mais la dessus on ne peut pas être, tous les deux, plus d'accord que ça !

Ca fait quand même longtemps que tu peux lire ça sur mon site:

http://michel.mo.pagesperso-orange.fr/changement_d_heure_2.htm

(je l'ai même amélioré dernièrement)

allez, je descend à la pizzéria...

[jackT]

Je compatis, mes bons petits amis mais je suis hors de ces problèmes !

Je ne pense pas que l'on puisse appeler cela un problème, du moment qu'on a la possibilité de régler la station en heure UTC, gommant ainsi les inconvénients apportés par le changement d'heure .

Chacun fait son choix et doit donc l'assumer!

[tudgur]

comme tu ne l'as (malheureusement) pas trouvée je te donne donc la (les) réponse(s):

Heureusement que je t'ai renvoyé à ton exercice puisque nous y apportons la même réponse !

Dans ton exercice, change donc le mot train par bureau, usine...

Et change durée du trajet par durée du travail...

Ou encore, change le mot train par journée et durée du trajet par durée de la journée...

Tu n'as pas répondu à toutes mes questions ...

Mais pourquoi vas-tu chercher midi à quatorze heures ?

Je raisonne comme un individu lambda (et je pense ne pas résonner comme une cloche).

Aux changements d'heure, il y a une journée à 23h qui conduit à une perte d'une heure (chevauchement, écrasement, peu importe...) de données et une journée à 25h qui conduit à un trou dans les données.

Ces problèmes sont reconnus depuis longtemps sur le forum et c'est Boudu34 (qui vient d'intervenir) qui m'avait convaincu de passer à l'heure UTC, il y a 7 ans ou plus (nous avions pourtant été en désaccord si je me souviens bien...).

Il est évident que d'avoir le PC et la console en heure UTC évite tout problème (et tu l'as reconnu).

Il est vrai qu'un vieil adage dit : "pourquoi faire simple quand on peut faire compliqué ?"

Alors, quel est l'avantage d'être en heure locale ?

Quel est l'inconvénient d'être en heure UTC ?

Tu pourras faire toutes les recherches que tu veux sur tes tableaux, tes graphiques, travailler sur Excel, mais pour arriver à quoi ?

Peu importe où sont les problèmes puisque l'on sait qu'ils existent, sauf en UTC !

Qu'un débutant laisse son matériel en heure locale, je comprends, mais un pro, je ne comprends pas.

Qu'il est difficile de te convaincre, de te faire changer d'avis, quel que soit le sujet !

Je pensais faire quelques manips de changements d'heure virtuels la semaine prochaine, mais dans quels buts finalement ?

C'est complètement inutile !

Et on en est, encore une fois, à une discussion tout à fait stérile.

Heureusement, cela n'est pas toujours le cas !

[Cyrilleb]

Oui, déjà on devrait peut-être arrêter les discussions sur l'intérêt du changement d'heure ou sur les trains suisses, ça ne fait pas avancer les choses...

Pour répondre à Tudgur plus haut:

Ce qui veut dire que WeatherLinkIP ne tient pas compte de l'heure du PC ?

Weatherlink ne tient pas compte de l'heure du PC en effet pour récupérer les données de la console.

Par exemple, s'il est 21h05 sur le PC et que la console affiche 19h04, le dernier enregistrement que je recevrai dans weatherlink sera celui de 19h (avec un pas de 15min). Il s'agit de 19h car la console affichait 19h lorsque les dernières données ont été enregistrées dans le datalogger.

Dans le datalogger, il faut imaginer qu'il y a une case mémoire par enregistrement. Dans cette case mémoire, il y a l'heure de la console au moment de l'enregistrement et les données météo.

Quand on télécharge le contenu du datalogger dans weatherlink, weatherlink ne fait que récupérer les données et les stocker dans un fichier, sans tenir compte de l'heure du PC.

Actuellement, la console est en heure TU et le PC est en heure légale. Il y a quelques jours, j'ai eu un souci avec ma VP2 de Foussais-Payré: suite à une coupure de courant, les piles n'ont pas tenu (elles étaient HS) et la console a redémarré. Le soir, en téléchargeant les données, j'avais un écart de 2h avec l'heure du PC, au lieu d'une heure (heure d'hiver). A 21h05, je récupérais les données de 19h...

J'ai donc vérifié sur la console, et elle affichait bien 2 heures de moins que le PC (à 21h sur ma montre, elle affichait 19h au lieu de 20h, car 20h TU = 21h heure légale). La coupure de courant avait déréglé l'horloge de la console.

Cela montre que l'heure du PC n'a pas d'importance, c'est l'heure de la console qui compte.

Attention! Peut-être que le problème est différent si weatherlink exporte des données en permanence vers un site web, ce qui n'est pas mon cas. Quelle heure weatherlink envoie-t-il vers le site, celle du PC ou celle de la console?

Et comment fais-tu pour maintenir ta console à l'heure ?

Je laisse la console tourner avec son horloge interne. De temps en temps, je vérifie l'heure et je fais une correction sur la console si nécessaire. La dérive est faible, moins de 30s par an je pense. En tout cas, ça ne me pose pas de problème. Je ne synchronise pas l'heure de la console sur celle du PC.

Je précise que je suis en weatherlink IP, je ne laisse pas le PC tourner 24/24. Je télécharge les données une fois par jour, ou moins.

Sinon, je suis allé vérifier dans weatherlink pour voir ce qu'il se passait au moment du changement d'heure, quand la console était en heure légale (ce qui n'est plus le cas aujourd'hui).

Pour le passage à l'heure d'été, il n'y a pas de données entre 2h et 3h dans weatherlink. Sur les graphiques, l'échelle de temps est continue; il y a les graduations pour 1h, 2h, 3h, 4h.

Mais il n'y a pas de données entre 2h et 3h, une ligne continue relie la donnée de 1h45 à celle de 3h.

(voir ce post de jackT: /topic/85945-synchros-dhorloges-fuseaux-horaires-et-changement-dheure-et/#entry2522516'>http://forums.infoclimat.fr/topic/85945-synchros-dhorloges-fuseaux-horaires-et-changement-dheure-et/#entry2522516 )

Pour le passage à l'heure d'hiver, les données de 0h à 1h TU sont écrasées et remplacées par celles de 1h à 2h TU. Il y a ainsi une discontinuité lors du passage de 1h45 à 2h. J'observe un saut de température ou de pression à ce moment là, car il manque une heure de données. Ce saut se voit bien sur les graphiques.

Bref, un conseil: mettez la console en heure TU si vous voulez éviter les décalages ou les données perdues au moment du changement d'heure (ne pas oublier de configurer la page weatherlink.com pour ceux qui sont en weatherlink IP).

Pour l'heure du PC, peu importe pour weatherlink (à confirmer), à voir pour les autres logiciels.

Cyrille

[Mitrale]

A tous les passionnés de trains et j'en étais aussi plus jeune... et même avant! Bonne nouvelle... tous les trains sont rentrés en gare!

Ceux qu'on a arrêtés pendant une heure et même ceux qu'on a dû faire rouler deux fois de suite pour des besoins d'économie d’énergie. Aux dernières nouvelles, on n'en a perdu aucun dans l'espace temps et aucun n'est arrivé plus de deux fois de suite sans respecter exactement l'intervalle réglementaire d'une heure! Nous voilà donc tous rassurés!

Bref, habitant aussi la région frontalière franco-suisse... et allemande aussi, je peux vous rassurer, leurs pendules sont bien à l'heure! Au plaisir de relire les "ferrovipathe" de ce forum... lol, encore un mot que j'ai dû googler pour le trouver!

[tudgur]

Oui, déjà on devrait peut-être arrêter les discussions sur l'intérêt du changement d'heure ou sur les trains suisses, ça ne fait pas avancer les choses...

Effectivement, il était temps de remettre les pendules à l'heure !

[Boudu34]

-

Eh oui, "Chacun voit midi à son clocher", c'est bien connu !

-

[tudgur]

Pour l'heure du PC, peu importe pour weatherlink (à confirmer), à voir pour les autres logiciels.

C'est donc vrai pour WeatherLinkIP, mais pour WeatherLink ?

Si c'est le cas, ce l'est donc aussi pour WsWin en surveillance de fichier.

Mais Wswin en pilotage direct de la station, je ne le pense pas . Il me semble que cela posait des problèmes sur mes graphiques et c'est la raison pour laquelle je suis passé en heure UTC (PC et console).

D'autre part, nous n'avons pas tous les mêmes utilisations de nos données.

Apparemment, tu n'as pas de site météo perso, seulement tes données sur Weatherlink.com.

Tu n'as donc pas de soucis d'affichage d'heure, de date, de mois, d'année puisque tu ne crées pas de fichiers persos.

Pour le décalage de l'heure de la console, je dépasse largement les 30s par an et ce, sur mes trois consoles !

Tous les 45 jours environs, je constate sur mes sites que l'heure de relevé est par exemple 16h59 au lieu de 17h00 et 18h24 au lieu de 18h25 (par exemple !)

Je synchronise donc régulièrement la console sur l'heure du PC.

Cela se fait en quelques clics...

En écrivant ces lignes, je constate qu'un relevé peut être daté de 16h59 (heure de la console) alors qu'il a été fait par Wswin à l'heure du PC : 17h00.

Donc, se passerait-il la même chose avec Wswin qu"avec WeatherLinkIP ?

A vérifier...

[Mitrale]

J'ai installé un analyseur de trafic sur mon PC me permettant de suivre tous les échanges de données entre mon ordi et ma console VP2. On peut ainsi voir défiler des commandes LOOP 1, LOOP 30, DMPAFT etc... envoyés régulièrement par WeatherLink, puis en retour les réponses de la console sous la forme de "LOOP packets" et qui sont faciles à interpréter grâce au document ci-dessous... un vrai régal!

"Vantage Pro, Vantage Pro2, and Vantage Vue Serial Communication Reference Manual"

/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=19899'>VantageSerialProtocolDocs_v261.pdf

J'ai pour l'instant encore trop de profils "internet" actifs dans WeatherLink (avec des redondances) pour déterminer avec certitudes les éléments à l'origine de trafic.

J'ai complété cet après-midi ma "boite à outils" avec un analyseur de protocole me permettant d'analyser octet par octet le contenu des paquets de données envoyés par WeatherLink sur le net vers mes sites météo... le premier a passer sous la loupe est WeatherUnderground!

Exemple d'un paquet LOOP (sur commande "LOOP 1") nécessaire aux mises à jour du site WU:

Les paquets LOOP commencent tous par "LOO". En position 12 on trouvera par exemple la température 79 01 qu'il faut lire 01 79 soit 37,7°F ou 3,16°C. Ils ne comportent pas d'heure de relevé.

Exemple de la lecture de la mémoire d'archive de la console pour alimenter les fichiers donwld02.txt (ou downld08.txt) et fichiers .wlk de WL (ici un bloc de 5 enregistrements):

Les enregistrements commence ici par 61 1E mais faut lire 1E 61 qui correspond à la date d'aujourd'hui 15/03/05 en format US, puis 3E 08 qu'il faut lire 08 3E et qui correspond à l'heure soit 21:10 puis 78 01 qu'il faut encore lire 01 78 qui correspond à 37,6°F ou 3,11°C etc...

et finalement le tout mis en boite pour être envoyé sur le net vers le site WU:

On trouvera par exemple la balise &tempf=45.1°F soit 7,3°C... à 15h34

à suivre...

[tudgur]

Et ça sert à quoi ?

[Sebaas]

Devise geek: "Tout ce qui est inutile est parfaitement indispensable" /emoticons/wink@2x.png 2x" width="20" height="20">

[tudgur]

Très bonne, la devise !

[Mitrale]

Et ça sert à quoi ?

Ça sert à comprendre comment sont envoyées nos données vers les sites météo ce toujours dans le contexte des changements d'heure...

Dans le datagramme envoyé à WU, on peut clairement voir qu'il contient l'heure au format UTC (balise &dateutc). C'est l'information que WU utilise pour ranger les données dans la table et les restituer dans les graphes... soit à UTC+1. Il suffit de générer un datagramme bidon pour le vérifier. Le décalage de +1 heure est sûrement une information à mettre en lien avec le fuseau horaire défini pour la station.

ex: http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=IALSACEL8&PASSWORD=********&dateutc=2015-03-05%2022:30:00&winddir=68&windspeedmph=0&windgust=1&windgustdir=68&humidity=80&tempf=50&dewptf=28.1&rainin=0.00&dailyrainin=0.00&baromin=30.64&solarradiation=0&softwaretype=Wunderground%20v.1.15%20PWSDec%2027%202007

Avec une heure UTC à "2015-03-05 22:30" on créera un point de mesures le 5 mars 2015 à 11:30PM (23:30).

Les mêmes datagrammes sont générés pour un "upload" depuis les fichiers WLK (à partir de "File" -> "Wunderground settings..." -> "Upload Observations"). Ils sont tous en UTC...

Cependant on vérifiera facilement dans les paquets DMPAFT que la console envoie les données "archive data" en utilisant l'heure locale. A priori c'est la dll du module WU installé dans WL qui fait la conversion en heure UTC pour avoir un dénominateur commun à tous. A moins qu'ils soient déjà mémorisés en UTC dans les fichiers WLK... je l'ignore.

Là maintenant je suis à la recherche d'un document décrivant la structure des fichiers WLK pour pouvoir les lire avec un éditeur hexadécimal pour savoir si les enregistrements sont à l'heure UTC ou locale, tout autre éditeur de fichier WLK faisant sa propre cuisine... Je crois savoir que c'est juste un nombre de minutes depuis 00h00 qui est utilisé pour que chacun puisse y mettre l'offset qu'il veut mais je n'en suis pas sûr....

Voili voiloo mes éclaircissements... et interrogations!

PS: Les paquets LOOP ne comportent pas de "time stamp" (relevé d'heure)...

[mm91]

Si l'on considère qu'on s'intéresse au fonctionnement de nos enregistrements lors des changement d'heure (et c'est mon cas dans ce post),

le boulot de Mitrale est très intéressant.

Il a pris la voie informatique (puisque c'est dans ses compétences).

Moi non plus je ne comprend pas tout (peut-être éventuellement ne pas trop détailler tes essais, mais je les respecte…) , mais j'attends son résultat, c'est à dire expliquer au final (ou à mesure) le plus clairement possible comment sont traités les changements d'heure ?

Est-ce qu'il y a des manques, des saut, sur les courbes, sur les échelles, dans quels fichiers, etc.?

Et aussi, par exemple, pourquoi je vois des décalage dans mes courbes (de Wswin32) la veille du changement d'heure alors que le fichier de la station a changé d'heure au bon moment ?

Pour cela il faut bien d'abord observer et constater ce qui se passe.

On ne peut pas expliquer un comportement si on ne sait même pas s'il existe !...

Pour ma part j'ai pris la voie "Excel" pour analyse du comportement des fichiers face aux changements d'heure.(je ne détaille pas mes procédures dans ce post, mais sur un autre forum)

C'est un long "boulot", mais j'ai le temps et la motivation de comprendre.

Résoudre ce problème (qui n'en est pas vraiment un d'ailleurs !) par l'heure UTC c'est très bien, mais cela empêcherait-il de chercher à comprendre (pour ceux qui le souhaitent) comment ça se passe en heure légale ?

Merci aux intervenants qui continuent sur ce sujet

[Boudu34]

-

Magnifique, Mistrale ! C'est vraiment du beau travail. Ça me rappelle le premières recherches qu'on faisait (en hexa) sur la comunication des WS 2500 ...

Ce sont des choses comme ça qu'on voudrait voir écrites plus souvent sur le forum ...

-

[Mitrale]

Moi non plus je ne comprend pas tout (peut-être éventuellement ne pas trop détailler tes essais, mais je les respecte) , mais j'attends son résultat, c'est à dire expliquer au final (ou à mesure) le plus clairement possible comment sont traités les changements d'heure ?

Ce n'est pas toujours facile de rester pour tous au bon niveau de détails... Perso, je documente au fur et à mesure mes manips et observations dans un document Word ainsi qu'ici. Ça m'oblige à une certaine rigueur et m'évite de prendre des raccourcis non vérifiés.

En procédant ainsi, je souhaite permettre aux lecteurs de relever d'éventuelles erreurs d'interprétation me conduisant à de fausses conclusions et au besoin, de me suggérer d'autres vérifications...

[jackT]

Là maintenant je suis à la recherche d'un document décrivant la structure des fichiers WLK pour pouvoir les lire avec un éditeur hexadécimal pour savoir si les enregistrements sont à l'heure UTC ou locale, tout autre éditeur de fichier WLK faisant sa propre cuisine... Je crois savoir que c'est juste un nombre de minutes depuis 00h00 qui est utilisé pour que chacun puisse y mettre l'offset qu'il veut mais je n'en suis pas sûr....

Bonjour,

Pour info, ce document n'est pas difficile à trouver : fichier Readme x.x.x.wri (où x.x.x indique la version de Weatherlink), à la racine du dossier dans lequel Weatherlink est installé.

Cordialement

[Mitrale]

Bonjour,

Pour info, ce document n'est pas difficile à trouver : fichier Readme x.x.x.wri (où x.x.x indique la version de Weatherlink), à la racine du dossier dans lequel Weatherlink est installé.

Cordialement

Cool, merci beaucoup pour l'info jackT! J'ai trouvé, chez moi il s'appelle Readme 6.0.rtf... génial!

[meteo-melin]

Un passage vite fait avec quelques liens qui pourraient en intéresser certains:

http://madscientistlabs.blogspot.ca/2011/01/davis-weatherlink-software-not-required.html

http://madscientistlabs.blogspot.be/2011/10/build-your-own-davis-console-datalogger.html

http://madscientistlabs.blogspot.be/2012/02/make-your-diy-davis-datalogger-work.html

http://madscientistlabs.blogspot.be/2011/11/bad-news-and-good-news.html

http://madscientistlabs.blogspot.be/2010/12/davis-weather-station-hacking.html

http://madscientistlabs.blogspot.be/2014/02/build-your-own-davis-weather-station_17.html

[Mitrale]

Un passage vite fait avec quelques liens qui pourraient en intéresser certains:

http://madscientistlabs.blogspot.ca/2011/01/davis-weatherlink-software-not-required.html

http://madscientistlabs.blogspot.be/2011/10/build-your-own-davis-console-datalogger.html

http://madscientistlabs.blogspot.be/2012/02/make-your-diy-davis-datalogger-work.html

http://madscientistlabs.blogspot.be/2011/11/bad-news-and-good-news.html

http://madscientistlabs.blogspot.be/2010/12/davis-weather-station-hacking.html

http://madscientistlabs.blogspot.be/2014/02/build-your-own-davis-weather-station_17.html

Wouahhh.... du hard!

[Mitrale]

Avec le document Readme 6.0.rtf que m'a indiqué jackT j'ai pu trouver comment les "archive data" étaient mémorisées dans les fichiers .WLK.

On trouve déjà les informations "mois" et "année" dans le nom même du fichier ici: 2015-03.wlk. J'en ai fait une copie ce 7 mars 2015 à 00:37 pour la suite de ce post et pour éviter de bloquer une nouvelle fois WL...

J'ai par ailleurs l'archive interval" de ma console réglé à 5 minutes et les lis toutes les 10 minutes depuis un profil "Internet settings" de WL.

Pour faire simple, ce fichier est organisé en trois parties comme le serait un livre. Une introduction, une table des matières et puis des pages de données pour chaque jour du mois.

En l'ouvrant avec un éditeur hexadécimal (ici HxD - Dexeditor), dans les 20 premiers bytes on trouve ce qu'on appelle un header, c'est notre "intro". On y trouve la version "WDAT 5.3" puis dans les 4 derniers bytes "D3 06 00 00" mais faut lire "00 00 06 D3" soit 0x000006D3 soit 1 747 lignes d'enregistrements de données.

Je supprime cette intro pour afficher la "table d'index des jours" qui comporte 6 bytes par jour. En passant l'affichage sur 6 colonnes on fait apparaitre 32 lignes pour les 31 jours d'un mois, le jour 0 n'est pas utilisé. C'est notre "table des matières".

Pour chaque jour du mois on trouve dans les 2 premiers bytes le nombre de lignes de données du jour, à savoir 2 pour les stats journalières (min/max, ensoleillement etc...) et une pour chaque "archive data" lu dans la console.

Ici on voit "22 01" mais faut lire "01 22" soit 0x0122 ou 290 "lignes" de données par jour. Ce qui correspond à (2 + (24h * 60min / 5 min)) = 290 lignes. Les 4 derniers bytes de chacune des lignes de la "table d'index des jours" indique l'adresse des lignes de données du jour suivant dans le fichier WLK.

Dans la ligne 8 du tableau donc du 7 mars on trouve la valeur 0x0007 soit 7 lignes. Donc à priori, 2 lignes de stats journalières + 5 lignes "archive data". Pour en revenir aux 1 747 lignes mentionnés plus haut, elles correspondent aux enregistrements du 1 au 7 mars à 00:37, soit 6 jours entier et un jour jusqu'à 00:37, soit (6 * 290) + 7 = 1 747.

Je supprime maintenant la "table d'index des jours" pour n'afficher plus que les lignes de données de 88 bytes chacune. En passant l'affichage sur 88 colonnes on fait apparaitre maintenant les lignes d'enregistrements de données.

Chaque jour commence par 2 enregistrements de stats journalières (types 0x02 et x03) puis suivent des enregistrements de type 0x01, ce sont les "archive data".

Le premier de type 0x02 (ici du 1er mars) montre la valeur 0x05A0 soit 1 440 minutes ou (24h x 60min) correspond à la durée d'enregistrement du jour, donc un jour entier.

Les lignes "archive data" commençant en 0x01 montre entre autre la valeur 0x05 correspondant à mon "archive interval" de 5 minutes puis un peu plus loin... des "timestamps" 0x0005, 0x00A, 0x000F, 0x0014 correspondant au nombre de minutes écoulées depuis 00h00 soit 5, 10, 15, 20 etc... mais est-ce 00h00 en heure locale ou UTC?

Pour répondre à cette question, voyons ce qui c'est passé ce 7 mars au petit matin...

On trouve bien (en rouge) 7 enregistrements dont 2 pour les stats journalières (type 0x02 et 0x03). En 0x02 on trouve (en rose) la valeur 0x0019 soit 25 minutes d'archive data jusqu'à 00:37, l "archive interval" (en orange) de 5 min et 5 "timestamps" (en bleu) à 5 minutes d'intervalle à 00h00 +5, +10, +15 +20 et +25 min. On remarquera au-dessus (marqué aussi en bleu) le dernier enregistrement du 6 mars est à 0x05A soit 1 440 minutes soit 24h.

En vert, j'ai marqué les champs "outsidetemp" (en dixième de degré Fahrenheit), ben ouai tout est ici codé en language MacDo... tout comme les pressions (en millième de InHg) et les vitesses (en mph)

- 00h05 0x0150 = 33.6°F (0,88°C)

- 00h10 0x0151 = 33.7°F (0,94°C)

- 00h15 0x0153 = 33.9°F (1,05°C)

- 00h20 0x014F = 33.5°F (0,83°C)

- 00h25 0x0150 = 33.6°F (0,88°C)

J'avais pris une photo de ma console à 00:22 (heure locale), elle indiquait 0,8°C... et en filigrane le photographe et son iPhone:

C'est donc bien les heures locales qui sont enregistrées dans les fichiers .WLK.

Voyons ce qu'affiche la vue "Browse the station data" de WL...

La vue reprend donc les mêmes heures (locale) que celles du fichier WLK. Les mesures sont converties dans le système métrique.

EDIT: Rajout des copies d'écran WU table et graph

Pour résumer le transfert des données vers le site WU à l'heure d'hiver:

- La console VP2 enregistre et envoie ses "archive data" à WL en heure locale

- WL enregistre les "archive data" dans les fichier WLK en heure locale

- WL affiche dans "Browse the station data" les "archive data" avec ces mêmes heures locales

- La dll WU envoie les données à WU en heure UTC/GMT, puis WU les corrige en heures locales

Que se passera-t-il le 29 mars prochain lorsqu'à 2h00 on passera à l'heure d'été?

A priori on devrait s'attendre à un trou d'une heure dans les fichiers WLK à moins que l'heure utilisée reste l'heure locale (GMT+1) sans tenir compte du décalage d'une heure supplémentaire introduit par le passage à l'heure d'été... Je ne peux pas voir ce qui c'était passé le 30 mars 2014 dernier, mon installation date seulement du 30 juin...

[tudgur]

le boulot de Mitrale est très intéressant.

Personne n'a dit le contraire.

Pour cela il faut bien d'abord observer et constater ce qui se passe.

On ne peut pas expliquer un comportement si on ne sait même pas s'il existe !...

Je pense que l'on peut affirmer qu'il y a des problèmes aux changements d'heures.

Sinon, ce sujet n'existerait pas.

Mais trouver l'origine d'un problème ne signifie pas que l'on peut le régler !

Résoudre ce problème (qui n'en est pas vraiment un d'ailleurs !) par l'heure UTC c'est très bien, mais cela empêcherait-il de chercher à comprendre (pour ceux qui le souhaitent) comment ça se passe en heure légale ?

Non, pas du tout !

La démarche de Mitrale, pour chercher à comprendre est sûrement intéressante même si elle n'est pas à la portée de tout le monde.

Mais peu importe, et si cela ne permet pas de corriger le(s) problème(s), il reste la "beauté du geste".

Cependant, quand il existe un moyen hyper simple d'éviter le(s) problème(s) en question, pourquoi ne pas l'appliquer ?

Que ce passera-t-il le 29 mars prochain lorsqu'à 2h00 on passera à l'heure d'été?

J'attends le résultat avec impatience et curiosité.

Bravo pour ton boulot de spécialiste, même si je n'essaye pas de "suivre" !

[Mitrale]

Concernant la publication des données de ma station sur le site Meteociel.fr, la solution proposée consiste en l'installation d'une petite appli qui copie au choix le fichier downld02.txt ou downld08.txt (encore faut-il avoir un profil WL qui génère l'un ou l'autre de ces fichiers). Avec l'accord d'un administrateur de leur site, je copie depuis mon fichier downld02.txt directement par FTP.

Appli Météociel:

L'intervalle d'affichage des points de mesures (table et graphes) n'est que de 1 heure. On retrouve sur le site Meteociel.fr les mêmes mesures (ici de température) aux heures pleines que celles contenues dans le fichier downld02.txt.

Pour résumer le transfert des données vers le site Meteociel.fr à l'heure d'hiver:

- La console VP2 enregistre et envoie ses "archive data" à WL en heure locale

- WL enregistre les "archive data" dans les fichiers WLK en heure locale, données qu'on retrouve dans le fichier downld02.txt.

- Les données sont reçues et affichées par le site Meteociel.fr avec ces mêmes heures locales

à suivre... pour l'heure d'été!