Piles au lithium sur sa station météo ? Un plus ?

[MP84120]

Oui j'avais compris, c'est pour ça que j'ai précisé qu'il s'agissait d'une WMR200 pour ma part.

Je ne suis pas très connaisseur et je ne sais pas trop ce que tu veux dire dans "radio-pilotée", mais effectivement la station est sans fil, il y a une horloge dessus où l'heure se synchronise toute seule, sinon on peut la régler manuellement (ce que j'ai fais maintenant).

[tudgur]

Une horloge (ou une montre) radio-pilotée reçoit un signal émis par un émetteur (pour nous DCF77 en Allemagne).

Si la tension d'alimentation de ta console est un peu faible (ou selon ta position géographique ?) ou encore selon l'emplacement de ta console, celle-ci reçoit plus ou moins bien le signal et dans ce cas n'est plus synchronisée.

Si ta station est radio-pilotée tu dois pouvoir la synchroniser manuellement.

PS : je viens de voir que tu as la même réponse sur un sujet voisin...

[MP84120]

Oui, effectivement comme dit dans l'autre sujet, ça doit être du à la position géographique, j'habite dans un lotissement entouré de forêts et de collines, du coup la réception n'est pas terrible.

Merci en tout cas pour tes réponses /emoticons/smile@2x.png 2x" width="20" height="20">

[tudgur]

Personnellement, si cela est possible, je te conseille de quitter la synchronisation automatique de l'heure.

Une station à horloge radio-pilotée change automatiquement d'heure au printemps et à l'automne.

Ceci conduit à un "trou" dans le données au printemps et à une "perte" à l'automne.

Il vaut donc mieux avoir la console et le PC en UTC.

On règle l'horloge du PC sur un temps internet et de temps en temps, on synchronise l'horloge de la console avec celle du PC (par voie logicielle).

Heureusement que la Vantage n'est pas radio-pilotée (bien que certains le regrettent...)

[mm91]

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

Une station à horloge radio-pilotée change automatiquement d'heure au printemps et à l'automne.

Ceci conduit à un "trou" dans le données au printemps et à une "perte" à l'automne..........

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

L'as-tu vraiment observé ?

Ici, depuis onze ans j'observe avec grande attention et en détail mes enregistrements météo (faits avec Wswin32) lors de tous les changements d'heure; je n'ai jamais vu de "trous", de "pertes" ni décallage d'aucune sorte.

Les graphes sont toujours parfaitement continus (au pas de cinq minutes ici).

(on peut les observer sur mon site)

(je fonctionne en heure locale: station = synchro DCF77 et PC = synchro Internet 2 fois par jour)

Cela m'a effectivement un peu étonné, mais je crois avoir une explication !…

[tudgur]

L'as-tu vraiment observé ?

Certainement !!!

Et je ne suis pas le seul...

Les graphiques montraient bien ces changements d'heure.

Attention, avec la Vantage ! Avec les autres stations, je n'en sais rien.

Le 29 mars prochain, quand à 2h du matin, il sera 3h, où sont les données de 2h à 3h ? (on passe de 1h59 à 3h00)

Et le 25 octobre, on passera de 2h59 à 2h00 :on ne va pas doubler les données !

Avant de faire mon site en php, j'étais réticent, je ne voulais pas de l'heure UTC puisque je voulais afficher l'heure locale.

Mais avec le php, même en heure UTC, on peut afficher l'heure locale...

[Mitrale]

L'as-tu vraiment observé ?

Ici, depuis onze ans j'observe avec grande attention et en détail mes enregistrements météo (faits avec Wswin32) lors de tous les changements d'heure; je n'ai jamais vu de "trous", de "pertes" ni décallage d'aucune sorte.

Les graphes sont toujours parfaitement continus (au pas de cinq minutes ici).

(on peut les observer sur mon site)

(je fonctionne en heure locale: station = synchro DCF77 et PC = synchro Internet 2 fois par jour)

Cela m'a effectivement un peu étonné, mais je crois avoir une explication !…

C'est une question très pertinente mm91... Nos stations météo étant répertoriées et enregistrées avec leur fuseau horaire, la correction heure d'hiver/été et décalage horaire seraient "à priori" gérés par le site hôte!

• Perso, ma WebCam1 (qui affiche l'heure) est synchronisée sur serveur NTP (Network Time Provider) et mon ordi via NetTime (http://www.timesynctool.com/) sur ptbtime1.ptb.de, ptbtime2.ptb.de ou ptbtime3.ptb.de.

• Je n'ai resynchronisé l'heure de ma console VP2 qu'une seule fois en 6 mois (directement et manuellement sur la console).

Donc "à priori", activez et gardez toutes vos synchros DCF77 et NTP (soit l'heure UTC), sur tous vos équipements... qui par ailleurs nécessitent aussi la définition d'un fuseau horaire local pour leur permettre d'afficher au final l'heure locale!

Aux techniciens du site InfoClimat, pourriez-vous nous apporter votre éclairage?

[tudgur]

Avec une station radio-pilotée, je pense que les graphes sont effectivement continus, mais...

Observe bien tes graphes les jours de changement d'heure.

Si mes souvenirs sont bons, quand ma console était en heure locale, il fallait une tâche planifiée pour la mettre à l'heure à chaque changement d'heure, et cela causait des soucis.

Ce n'est pas pour rien qu'en 2007, 2008 et sans doute plus tard, il y a eu de très nombreux messages sur le forum, à propos des changements d'heure.

[Sebaas]

On observe également le trou ou l'écrasement des données (selon qu'on passe à l'une ou l'autre) au changement d'heure.

C'est bien pour cela que toutes les VP2 installées par l'association + un grand nombre de celles du réseau StatIC sont en heure GMT, avec le changement d'heure désactivé dès la mise en route.

[Mitrale]

On observe également le trou ou l'écrasement des données (selon qu'on passe à l'une ou l'autre) au changement d'heure.

C'est bien pour cela que toutes les VP2 installées par l'association + un grand nombre de celles du réseau StatIC sont en heure GMT, avec le changement d'heure désactivé dès la mise en route.

Merci/user/1052-sebaas/'> Sebaas, voilà qui est clair... ou presque! Je pensais que c'était l'heure GMT/UTC qui était enregistrée sur les serveurs... et que la correction en heure locale se faisait en fonction du fuseau horaire du client. Et si je passais ma VP2 en heure GMT tout en désactivant le changement d'heure, comment aurais-je alors mes graphes en heures locales?

Edit: La VP2 installée à "La Bourboule" est si je ne me trompe une station InfoClimat. Est-elle aussi configurée en heure GMT et sans changement d'heure été/hiver? Si oui, ses graphes et mesures ne devraient-ils pas être décalés d'une heure?

[tudgur]

..Et si je passais ma VP2 en heure GMT tout en désactivant le changement d'heure, comment aurais-je alors mes graphes en heures locales?

Tes graphiques (sur ton PC) seront en heure GMT...

Les données étant enregistrées en heure GMT, je ne pense pas que l'on puisse faire autrement.

Mais où est le problème ?

Ce qui est intéressant ce sont les statistiques et ne pas perdre de données.

@Michel : comment "caser" 24 heures de données dans une journée qui n'en dure que 23 ? Il y a forcément un écrasement d'une heure.

Et pour "caser" 24 heures de données dans une journée qui en dure 25 ? Il y a forcément une heure sans données.

[mm91]

Ci dessous les graphiques journaliers des six derniers changements d'heure:

(rappel: ici la station et le PC sont en heure locale avec changement été-hiver automatique)

On y remarque bien, le matin (entre 1 heure et 4 heures notamment) qu'il n'y a aucun manque (pas de trait continu supérieur au pas de 5 minutes), aucun redoublement des mesures et aucun décalage.

Observez bien, notamment lorsque une courbe présente une pente, il n'y a aucune discontinuité dans cette pente.

Je pense que le changement d'heure (Station et PC) est très bien fait, sans discontinuité dans le temps qui passe: aux changements d'heure, les paramètres météo (ou autres) continuent d'être enregistrés chronologiquement et c'est seulement l'affichage de l'heure qui change.

Chaque valeur de paramètre météo est associé à une heure et une seule.

Avec une station non synchronisée DCF (donc qui ne change pas d'heure) je pense que les problèmes que vous avez eu (discontinuité, décalages, manques ?), se produisent si votre PC change d'heure (par défaut Windows vendu en France est en heure locale avec changement d'heure automatique).

Evidemment que dans ce cas, aux changements d'heure du PC, le PC et la station se décalent, d'où les perturbations que vous constatez.

Vous auriez alors deux solutions:

1/ changer d'heure manuellement sur la station; Ce qui évidemment n'est pas envisageable dans un système que l'on veut automatique.

2/ Mettre le PC en heure fixe (UTC par exemple)

et c'est ce que vous faites.

Attention:

je ne discute pas ici de l'intérêt ou non de fonctionner en heure locale ou en heure UTC (c'est un autre débat).

Je dis simplement que votre choix de fonctionner en UTC vient du fait que votre station ne change pas d'heure (et ce n'est pas non plus un reproche que je lui fait, là n'est pas la question).

En tous cas lorsque station et PC changent d'heure en même temps il n'y a aucun problème dans les enregistrements.

Remarque:

Concernant les synchronisations avec des sites hôte (IC ou autres), l'info du type d'heure (UTC ou locale) est codée dans les infos que nous leur transmettons, ces sites savent donc quel type d'heure nous leur fournissons, donc ces sites font leur propre choix, en connaissance de cause, pour le traitement et l'affichage de nos données.

Concernant "statIC" plus particulièrement, je crois que ce site n'accepte que les stations Davis, donc des stations qui nechangent pas d'heure automatiquement, il semble donc pratiquement obligatoire de fonctionner en UTC.

[Mitrale]

Concernant "statIC" plus particulièrement, je crois que ce site n'accepte que les stations Davis, donc des stations qui n'échangent pas d'heure automatiquement, il semble donc pratiquement obligatoire de fonctionner en UTC.

Ma VP2 est en GMT+1 et "Daylight saving" = autodetect, elle change donc d'heure automatiquement...

Par ailleurs, la communication avec le réseau StatiIC s'effectue via le fichier StatIC.txt généré par le fichier StatIC.htx où les heures sont au format UTC. Voir les balises HTML ci-dessous:

Extrait du fichier StatIC.htx

date_releve=

heure_releve_utc=

Ce serait donc bien le site InfoClimat qui ferait la correction pour afficher l'heure locale dans les tableaux et graphes!

L'heure UTC est calculée par la station Davis en prenant l'heure locale réglée +/- le décalage horaire du fuseau horaire et programmation du mode été/hiver. Lors du passage à l'heure d'été, l'heure UTC de la station ne change pas. Par contre l'heure locale affichée avancera automatiquement d'une heure.

Quant aux fichiers downld02.txt et downld08.txt, l'heure est au format local. Les heures des fichiers .wlk semblent aussi être au format local, c'est du-moins ce que montre l'interface "Browse the station data" de WeatherLink.

Bon, il va peut-être falloir arrêter de polluer ce sujet et en ouvrir un nouveau!

Edit: Je confirme que les heures des fichiers .wlk sont au format local. Je viens de le vérifier avec WLKReaderWriter.exe

[mm91]

Ma VP2 est en GMT+1 et "Daylight saving" = autodetect, elle change donc d'heure automatiquement...

OK, la question est donc de savoir (si ton PC change aussi d'heure) si cela te pose des problèmes de décalage des graphiques (les tiens, pas ceux de "statIC") comme le disait Tudgur ?

Par ailleurs, la communication avec le réseau StatiIC s'effectue via le fichier StatIC.txt généré par le fichier StatIC.htx où les heures sont au format UTC. Voir les balises HTML ci-dessous:

Extrait du fichier StatIC.htx

date_releve=

heure_releve_utc=

Ce serait donc bien le site InfoClimat qui ferait la correction pour afficher l'heure locale dans les tableaux et graphes!

L'heure UTC est calculée par la station Davis en prenant l'heure locale réglée +/- le décalage horaire du fuseau horaire et programmation du mode été/hiver. Lors du passage à l'heure d'été, l'heure UTC de la station ne change pas. Par contre l'heure locale affichée avancera automatiquement d'une heure.

Quant aux fichiers downld02.txt et downld08.txt, l'heure est au format local. Les heures des fichiers .wlk semblent aussi être au format local, c'est du-moins ce que montre l'interface "Browse the station data" de WeatherLink.

Edit: Je confirme que les heures des fichiers .wlk sont au format local. Je viens de le vérifier avec WLKReaderWriter.exe

Oui, tu confirmes ce que je disais: le format de l'heure est toujours transmis avec l'heure.

Ensuite IC (ou autres) en fait ce qu'il en veut.

(merci de bien séparer les problèmes de décalage des graphiques (soulevés par Tudgur, c'est à ça que je répondais) et les problèmes d'interprétation de l'heure par "statIC")

Bon, il va peut-être falloir arrêter de polluer ce sujet et en ouvrir un nouveau!

Je serais assez d'accord, mais c'est l'auteur du sujet lui-même qui est passé des piles lithium à un problème d'heure (post #24). Grosse erreur !

Une solution serait de rajouter "problème d'heure DCF" dans le titre du sujet.

Et d'essayer de ne pas élargir la discussion à l'"heure en général"...

(simple suggestion)

[Sebaas]

Côté IC, y'a pas de magie: on intègre en base la donnée en heure UTC, et selon la saison on calcule l'heure locale à l'affichage. Et ceci pour la dizaine de milliers de stations de par le monde, quelque soit le fuseau horaire. D'ailleurs, il suffit de lire l'infobulle lorsque l'on passe la souris sur l'heure d'un relevé dans tous les tableaux.

[mm91]

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

@Michel : comment "caser" 24 heures de données dans une journée qui n'en dure que 23 ? Il y a forcément un écrasement d'une heure.

Et pour "caser" 24 heures de données dans une journée qui en dure 25 ? Il y a forcément une heure sans données.

Non, non !…

heureusement, même avec le changement d'heure la durée d'un jour est toujours de 24 heures.

Ouf !…(*)

Comme déjà expliqué (et démontré avec mes exemples de graphiques où tout est parfaitement bien "casé"):

ce n'est que le "nom" de l'heure qui change:

en été "15h30" (d'hiver) s'appelle "14h30", c'est tout !

Voilà comment on fait en informatique:

Prends l'exemple de Excel:

quand tu entres une date/heure ça affiche une date/heure, mais en réalité c'est une durée qui est notée en interne:

- 1/1/1900 = 1,

- aujourd'hui 2/3/2015 = 42065,00

(le chiffre après la virgule contient l'heure: 2/3/2015 à 15h30 = 42065.65)

- etc.

et c'est avec ce nombre que sont faits tous les calcul, même si les résultats sont affichés en date/heure.

Autre exemple:

Quand je regarde dans les tableaux de mesures de ma station que j'affiche sur mon PC, je vois souvent des erreurs de date; par exemple souvent à minuit, la date ne change pas, (elle ne devient bonne qu' après plusieurs fermetures-ouvertures du tableau).

Mais ceci n'est qu'un mauvais affichage dans ce tableau, car:

- l'édition des fichiers ".dat" donne toujours les bonnes dates.

- la date sur l'écran de la station est toujours bonne

- et surtout la date lue par Wswin32 est toujours bonne.

Je veux dire par là que quelque-soit la date affichée (qui peut être erronée, locale, GMT, etc…)

les calculs (et donc la datation des mesures) sont faits avec une autre référence.

Et d'une façon générale en informatique, les calculs de temps et de durées ainsi que les datations des événements sont fait avec une référence fixe.

C'est seulement à l'affichage (interface homme-machine) que, sur option, les dates/heures sont données en Local, avec changement été-hiver, GMT, etc, au choix de l'opérateur.

C'est parce que tu fais ton calcul avec l'heure lue (ou affichée) que tu trouves 23 (ou 25) heures aux changements d'heures.

Bien évidemment pour faire des calculs de durée (et des datation d'événement) on ne prends jamais ces heures-là !

(*) mais j'ai fait longtemps la même erreur que toi, et j'ai même écris sur mon site qu'il y avait des déclage dans mes graphique (je viens d'ailleurs de corriger).

Mais, comme toi c'était uniquement par déduction que je disais ça.

Après réflexion et observation (voir mes graphiques ci-dessus), je vois et j'explique pourquoi il n'y a pas de décalage.

PS:

pour toi je rabache, mais pour d'autres voir éventuellement: http://michel.mo.pagesperso-orange.fr/changement_d_heure_2.htm

[MP84120]

Bon là on s'éloigne totalement du sujet initial, donc au pire continuez votre conversation ailleurs, sur un autre sujet! /emoticons/wink@2x.png 2x" width="20" height="20"> merci.

[mm91]

Bon là on s'éloigne totalement du sujet initial, donc au pire continuez votre conversation ailleurs, sur un autre sujet! merci.

Tu parlais de la synchro heure DCF77 que tu ne captais plus

(ton post #24).

C'est vrai qu'on a beaucoup discuté de l'intérêt ou non de cette synchro et du changement d'heure automatique qui en découle.

Mais ainsi tu peux te faire ta propre opinion.

(et on n'est pas totalement éloigné de ton sujet)

Ces signaux, qui sont des basses fréquences se propageant par diffusion, sont peu sensibles aux obstacles (contrairement aux transmission UHF des sondes par exemple).

Ils sont par contre très sensible aux parasites;

Il faut des fois peu de chose pour capter à nouveau:

éloignement d'un perturbateur, rapprochement d'une fenêtre, etc.

Il faut aussi du temps: à chaque essai de déplacement attend au moins 24h.

Ce n'est qu'une synchro, c'est à dire qu'il peut suffire de quelques minutes de bonne réception (en général la nuit) pour mettre à l'heure l'horloge de la station.

Tu es à 770 Km de l'émetteur qui est donné pour une portée de 1000 à 1500 Km,

donc tu devrais sans doute arriver à capter.

[Mitrale]

Edit: Je confirme que les heures des fichiers .wlk sont au format local. Je viens de le vérifier avec WLKReaderWriter.exe

A ceci près, c'est que mon fichier .wlk est tout à fait contigüe le 26/10 dernier ce malgré le passage à l'heure d'hiver à 3h00 (pas de saut en arrière d'une heure). Le réglage heure d'été/hiver ne servirait alors qu'à modifier l'affichage de l'heure courante et des levés/couchés du soleil. Je verrai ce qui se passera le 29/03 prochain...

Ma station n'étant en service que depuis le 30/06/2014, je n'ai pas assez de recul pour vérifier la continuité de mes graphes...

[Mitrale]

Bon là on s'éloigne totalement du sujet initial, donc au pire continuez votre conversation ailleurs, sur un autre sujet! merci.

Mes plus plates excuses /user/22999-mp13850/'> MP13850 c'est bien de nous rappeler à l'ordre sans quoi nous finirions à mettre au point un formulaire à commander des pizzas!

Çà y est, c'est fait... j'ai créé un nouveau sujet: /topic/85945-synchros-dhorloges-fuseaux-horaires-et-changement-dheure-etehiver/'>http://forums.infoclimat.fr/topic/85945-synchros-dhorloges-fuseaux-horaires-et-changement-dheure-etehiver/

[MP84120]

Mon message n'était pas méchant, juste je disais qu'il faut éviter de trop s'éloigner du sujet initial, en tout cas merci à vous pour toutes vos réponses /emoticons/smile@2x.png 2x" width="20" height="20">

[Mitrale]

Mon message n'était pas méchant, juste je disais qu'il faut éviter de trop s'éloigner du sujet initial, en tout cas merci à vous pour toutes vos réponses

Lol... tkt je ne l'avais pas du tout perçu comme étant "méchant"! Ceci dit, des fois il faut savoir dire ce qui mérite d'être dit... et tu l'as très bien fait!