Mitrale

Si tu peux ouvrir ta sonde Watermark, je serais intéressé de savoir quel capteur est utilisé, des photos permettraient aussi de voir le montage... Je viens de trouver cet article sur le net: http://www.pobot.org/Capteur-d-humidite-resistif.html. C'est peut-être ta sonde qui est HS. Tu devrais pouvoir la vérifier à l'ohmmètre si c'est aussi une "humidistance". Elle ne te coûterait dans ce cas que quelques euros (ex. chez Conrad) si tu devais la remplacer.

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...

Wouahhh.... du hard!

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

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...

Faudrait peut-être la tourner un "chouilla" à droite par ces périodes pré-électorales!

Lol, à gauche sur la tof on dirait une bébête, gentille ou pas... Un pensionnaire du Loch Ness égaré au pays du fromage ou encore un autre pote à Ellen Ripley ramené de l'USCSS Nostromo veillant sur sa progéniture (des œufs en chocolat) avec un tas de grains de café au premier plan? Décidément... la Suisse çà nous gagne!

Ç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)...

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...

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!

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" /applications/core/interface/file/attachment.php?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. VantageSerialProtocolDocs_v261.pdf

Tout à fait mm91 et personnellement je m'abstiendrai de toute modif de paramètre tant que je n'aurai pas une bonne compréhension du flux de données... jusqu'en bout de chaine (j'en ai trois).

Bonsoir jackT, Qu'appelles-tu un "réglage en heure locale"? Le saut d'une heure que t'avais observé le 30/03/14 implique l'écrasement d'une heure de données le 26/10/14. Je ne l'ai pas vu, les "timestamp" (heures de relevé) étant contigües... ben ça change tout! Merci pour l'info, je reverrai mon raisonnement demain avec je l'espère, une meilleure compréhension! Cordialement,

Bravo et merci!

Pour info, j'avais contacté le support WeatherUnderground lors du mois de novembre dernier... Je leur avais alors fait part de la gêne occasionnée par un nombre toujours grandissant de stations Netatmo sur leurs cartes occultant ainsi des stations plus précises et aux données plus complètes (vent et ensoleillement). Je leur ai suggéré d'étendre leurs possibilités de filtrage aux marques de stations ou types de données disponibles... Je viens de recevoir leur réponse.... "Oui, nous prévoyons d'ajouter cette fonctionnalité à notre filtre WunderMap bientôt." à suivre...

Je te rassure, moi aussi je n'ai pas tout compris... et te rejoins pour ta remarque concernant les logiciels différents! En fait, c'est toute la chaine logicielle qu'il faut considérer, depuis la station (marque, modèle et firmware), l'appli qui collecte les données (WeatherLink, Weather Display, Wswin etc...) déclinées elles aussi dans des versions différentes) puis finalement la restitution graphique des données sur les sites météo ou perso, soumise quant à elle à l'entière créativité et compréhension du développeur... Perso je porterai mon attention sur la chaine (VP2) ==> (WeatherLink) ==> (WeatherUnderground + InfoClimat + Météociel)

N'ayant vécu qu'un seul passage heure été/hiver depuis que j'ai ma station Davis, j'ai relevé dans mes fichiers d'archives (.wlk) une donnée particulière (ici la température) du 26/10/2014 de 00h00 à 4h00 par intervalle d'une heure. Puis j'ai observé à quelles heures elles étaient mémorisées et restituées dans WeatherLink et WeatherUnderground. [align=center] [/align] [align=center][/align] Voici mes observations suite au passage d'heure été/hiver du 26/10 à 3h00: Dans WeatherLink: Les archives wlk de WeatherLink ne semble mémoriser que l'heure "standard" c'est dire locale (GMT+1) et ce sans tenir compte des changements d'heure été/hiver. Les graphes de WeatherLink semble fonctionner sur ce même principe, je retrouve mes mêmes points de mesure exactement aux mêmes heures sur le graphe. [align=center][/align] Pendant la période hiver, l'affichage des graphs correspond à l'heure locale. Pendant la période été, l'affichage sera décalé avec une heure en retard. C'est à dire qu'une mesure effectuée par exemple à 15h (heure d'été) sera affichée sur le graphe à la position 14h. [align=center] [/align] [align=center] [/align] Dans WeatherUnderground: Envoyées sur le site WeatherUndergound ces mêmes données semblent être mémorisées sur ce même principe sans tenir compte des changements d'heure été/hiver. Je retrouve dans les tables mes points aux mêmes heures mais décalées de 3 min. Pendant l'heure d'été, les graphes de WeatherUnderground montrent que mes mesures sont décalées d'une heure en arrière. Ils reviennent à l'heure pour redevenir synchro lors du passage à l'heure d'hiver à 2h00 du matin. Le graphe laisse ainsi apparaitre une discontinuité avec un saut de 1h00 à 2h00 du matin! [align=center][/align] Concernant le décalage de 3 min, j'ai contacté le support WeatherUnderground pour leur demander comment leur module installé (.dll) dans WeatherLInk leur envoie les données... Pendant la période hiver, l'affichage des graphes correspond à l'heure locale (GMT+1). Pendant la période "été", l'affichage est décalé avec 2 heures en retard. Une mesure effectuée par exemple à 15h (heure locale d'été) sera enregistrée dans la ligne 14h de la table (je m' attendais) pour être affichée à la position 13h du graphe, au lieu de celle à 15h! Si mon raisonnement est exact, je pense qu'il s'agit là d'un bug... à moins que j'aie quelque part un réglage inapproprié!

Pour info, j'ai repris ce sujet dans la rubrique "Photos, vidéos et matériel de prise de vue": /topic/85948-photos-insolites-de-stations/'>http://forums.infoclimat.fr/topic/85948-photos-insolites-de-stations/

Qui sur ce forum expérimente une telle forêt de stations? http://www.vantagepro2.eu/vantage-pro-2/video-sur-le-toit-de-davis-instruments/

Au fil des sujets parcourus ici, je découvre régulièrement de nouvelles photos insolites de stations... que je perds très rapidement aussi dans les méandres et dédales de ce forum mais qui en font pourtant toute sa richesse! Faisant suite au sujet /topic/85902-photolive-proposition-dune-nouvelle-rubrique/#entry2519466'>http://forums.infoclimat.fr/topic/85902-photolive-proposition-dune-nouvelle-rubrique/#entry2519466 je vous propose de partager ici vos photos de stations devenues inopérationnelles suite aux aléas de la météo (ex. stations complètement givrées, "explosées" par la grêle ou le vent) ou de bricolages et manipulations délétères ou celles tout à fait remarquables de nos génies-bricoleurs (ex. ventilo de clim en guise d'anémo) ou encore celles que se sont appropriées des insectes et animaux divers... Je me rappelle celle tout à fait exceptionnelle d'un hibou perché sur une girouette (dommage, je ne la trouve plus)! Alors... à vos appareils!

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!

La VP2 de chez Davis est déclinée dans les deux versions... avec ou sans fil. Opte peut-être pour la version sans fil.... une valeur sûre et qui t'évitera de te reposer ces mêmes questions. Perso j'avais aussi "claqué" près de 150 Euros dans une station X et qui ne m'a apporté que frustrations avant d'opter pour une VP2 (sans fil). C'est clair, elle n'est pas donnée... mais çà roule!

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/

Voili voilou.... ce pour conserver la qualité du sujet initial proposé par /user/22999-mp13850/'>MP13850 et intitulé "En réponse à Piles au lithium sur sa station météo ? Un plus ?", la discussion étant partie dans une toute nouvelle direction et tout à fait inattendue, je créé donc ce nouveau sujet... "Dans quelle mesure la synchronisation DCF77 ou NTP (Network Time Provider) de nos horloges de station météo et de PC peut-elle influencer la qualité de nos graphes de données lors des changements d'heure été/hiver?" Merci d'avance à /user/1052-sebaas/'>Sebaas de bien vouloir "déplacer" (ce dans la mesure du possible), la partie de la discussion partie en "live" du sujet précédent!

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...