tudgur

Difficile à vérifier à cause du peu de fidélité du pluvio. Je dirais plutôt : équilibrage des augets = vides, ils restent en équilibre, à l'horizontale.

Voilà une explication à un défaut qui n'en serait donc pas un ! Cependant, mon pluvio de Plouguerneau étant séparé du reste de la station, à moins d'un mètre de haut et dans un endroit (volontairement) cloisonné par des haies de 1.5 à 2 m, je ne modifierai pas cet équilibrage. De plus, ici, avec la rosée très fréquente, on manquerait des basculements... Par contre, à Serre Chevalier, il faut que je le supprime ! Mais donc, pour des installations classiques, ou au-dessus d'un faîtage, il faudrait donc ne pas faire cet équilibrage.

Je pensais à l'éprouvette pour le volume d'eau à verser dans la poche de perf...

Je ne pense pas que tu aies besoin d'une précision extrême pour tes mesures. En effet, le pluvio Davis est mécanique et comme la plupart des appareils de mesure mécaniques,il ne doit pas être très "fidèle" (au sens physique du terme bien entendu !) On le voit bien quand on veut faire un calibrage avec un volume donné : difficile d'obtenir des basculements successifs avec un même volume d'eau.

Étonnant que tu aies eu la même idée ! (Je ne vais pas utiliser la formule de circonstance au risque de ma faire enfler les chevilles...) Tu n'as pas d'éprouvette graduée de 500 mL ? Je ne pense pas que l'essuyage des augets soit nécessaire : dès le premier remplissage, ils seront mouillés !!!

Une suggestion : essaye de récupérer une "poche de perfusion" (je n'en connais pas le nom exact) et son goutte à goutte réglable. Et tu perfuses ton pluvio avec un volume connu ! Il existe aussi des éprouvettes graduées (mais pas d'un grand volume) avec robinet réglable.

Le "gloops" était plus pour le 5.2 mais je vois que c'est aussi corrigé : cela me paraissait énorme ! Déjà, 4.4 mL...

C'est aussi ce que je fais. Je ne sais plus si c'est moi qui le premier ai parlé de calibrer à 3.8 mL après avoir constaté la très importante sous-estimation du pluvio de la Vantage (par rapport au SPIEA) avec un calibrage à 4.2 mL. Il est bien évident qu'il ne s'agit pas de "recalibrer" tous les jours. Mes absences répétées de plusieurs semaines, atteignant parfois le mois et demi, me permettent d'ajuster les vis comme le fait aussi jackT... Lors de mon retour, au début de cette semaine, le SPIEA n'était pas loin de déborder... Autrement dit, le calibrage devrait, à mon sens, se faire une fois au moment de l'installation. Gloups ! (mm ou mL ?)

Pas du tout ! J'attendais de recevoir le matériel avant de résilier... Du coup, je fais mon RAR aujourd'hui. De temps en temps, j'arrive à me connecter en WiFi sur la box d'un voisin, à environ 50m, avec SFR WiFi FON ! Voilà une info ! Je n'utilise pas ce mode de fonctionnement puisque chez moi Wswin est démarré toutes les 5 minutes. Pour autant, je laisserai PC et console en UTC puisque cela n'apporte aucun inconvénient, surtout pour un PC qui ne sert que pour la météo !

Je n'ai plus de connexion Internet jusqu'à lundi après-midi au plus tôt. Abonnement souscris chez Free hier et ligne coupée par SFR moins de 24h après !!!! Free pourrait faire parvenir le matos avant de modifier le ligne.

Bonne question ! A laquelle je ne saurais répondre puisque mon PC et ma console sont en heure UTC... Il faudrait que je fasse la manip sur un autre PC avec ma deuxième console, mais j'ai d'autres tests en cours. Entre autre, la mesure de l'ensoleillement avec un pas de 1min vs pas de 5 minutes : la différence serait significative mais c'est hors sujet ! Je vais essayer (en sauvegardant les fichiers en cours). Edit : Après copie de tout le répertoire Wswin32. PC mis en heure locale, donc passage de 10h à 11h. Je constate qu'il faut aussi mettre Wswin en heure locale, chose que je ne savais plus. Le PC pourrait donc être en heure locale et Wswin en UTC (par réglage du fuseau horaire) Mais je laisse la console en UTC. Voici ce que donnent les tags (extraits de mes fichiers variables.txt et variables.php) : Un seul tag, %ws_utc_hour% est censé donner l'heure UTC $tab['time'] = '%ws_time%';$tab['heureUTC'] = '%ws_hour%';$tab['UTC_heure'] = '%ws_utc_hour%';$tab['minute'] = '%ws_minute2%';$tab['heure_utc'] = '%ws_replacestr=:~h~%ws_time%%'; $tab['time'] = '10:10';$tab['heureUTC'] = '10';$tab['UTC_heure'] = '10';$tab['minute'] = '10';$tab['heure_utc'] = '10h10'; Pourtant tous les tags donnent l'heure UTC. Seule la console est restée en heure UTC : c'est donc elle qui mène la danse !

Mon fichier static.txt n'a strictement rien à voir avec WeatherLink et les fichiers .wlk ! Tu ne connais pas Wswin32 ???? Nous sommes pourtant très nombreux à l'utiliser et il a été cité dans le sujet présent... Ce logiciel pilote directement ma console ! A partir de tags, il crée des fichiers "customs". Voici le fichier qui permet de créer static.txt : # INFORMATIONS# INFOCLIMAT.FR / Type VWS3 / Avril 2012 / V1.0staticmode=vws3/rv1.0id_station=00098version=Wswin32%curminmaxhour_on%date_releve=%ws_date%heure_releve_utc=%ws_hour%h%ws_minute%# PARAMETRES TEMPS REEL %unit_off%temperature=%curval[2]%pression=%curval[33]%pression_tendance_txt=%unit_off%%ws_baro3h%humidite=%curval[18]%point_de_rosee=%curval[43]%vent_dir_moy=%curval[36]%vent=%curval[35]%vent_moyen=%avg10minwind%vent_rafales_1h=%curminmaxhour[2,1,45]%pluie_intensite=%rainrate%pluie_sur_1h=%rain1h%pluie_cumul=%rain24h%pluie_jour=%rainday%pluie_24h =%curminmaxhour[4,24,34]%ensoleillement=%sunday_d%uv=--radiations_solaires_wlk=%ws_calc[-]=%curval[42]%~17~0%tn_1h=%curminmaxhour[1,1,6]%tx_1h=%curminmaxhour[2,1,7]%tn_deg_c=%curminmaxhour[1,0,6]%tx_deg_c=%curminmaxhour[2,0,7]%temperature_10_cm=%curval[14]%temperature_10_cm_sous_sol=%curval[13]%hrn_1h=%curminmaxhour[1,1,18]%hrx_1h=%curminmaxhour[2,1,18]%humidite_feuillage=--test_1_raf=%ws_arraygust[5]%test_2_raf=%ws_arraygust[10]%pression_min_mer=%curminmaxhour[1,1,33]%dh_debut_gelee=%ws_lasticedaystart%dh_fin_gelee=%ws_lasticeday%last_temperature=%ws_arraytemp[60]%TSV_H=%vaporpressurcur%hr_history=%ws_arrayhum[60]%%curminmaxhour_off%%ws_delline% Mon heure de relevé UTC est obtenue par deux tags : %ws_hour% qui donne l'heure de la console et %ws_minute% qui donne les minutes. La console étant en heure UTC, ces deux tags affichent donc l'heure UTC. Je remarque quand même que dans ton fichier, l'heure est au format 16:30 et chez moi 16h30. Mon fichier static.txt est envoyé toutes les 5 minutes chez mon hébergeur mais statIC ne le "prend" que toutes les 30 minutes alors que pour d'autres c'est toutes les 10 minutes ! Sebaas aurait-il une réponse ? Si ma console était en heure locale, avec le tag %ws_utc_hour%:%ws_minute2% on arriverait au même résultat: 16:30 Mais ne cherches-tu pas trop de complications ? StatIC reçoit les données en heure UTC et les affiche en heure locale : où est le problème ? Je le fais moi-même sur mon site (en php, par l'intermédiaire de l'hébergeur), sans être un pro de l'informatique !

Il se passe la même chose si la console et le PC sont en heure UTC... Mon fichier static.txt est généré à partir de Wswin.

C'est vrai que l'on devrait donner la pression en kPa puisque en physique on utilise toujours une puissance multiple de 3 ou -3 devant une unité ! Et le Pascal est l'unité légale de pression. Sans doute utilise t-on plus couramment le hPa pour sa correspondance avec le mbar ?

Personne n'a dit le contraire. 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 ! 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 ? 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" !

Très bonne, la devise !

Et ça sert à quoi ?

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

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

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 !

Je ne comprends pas du tout ton raisonnement ! Je raisonne en "segments" Peu importe que le début de la journée, à 0h00 soit en heure d'hiver et la fin de la journée en heure d'été. Toute journée commence bien à 0h00 et se termine à 23h59. Si ce jour de changement d'heure, un patron demande à son employé de travailler toute le journée, c'est à dire de 0h00 à 23h59, dis moi donc combien d'heures il va travailler ???? Dans cette "journée", il y aura 23 "segments" d'une heure et non pas 24 puisque le segment de 2h00 à 3h00 n'existe pas ! Lorsque tu bossais, tu n'aurais pas apprécié que l'on passe de 9h59 à 17h00 ? Ta journée de boulot aurait été plus courte, non ? Je te ramène donc à ton exercice !

Ce qui veut dire que WeatherLinkIP ne tient pas compte de l'heure du PC ? Et comment fais-tu pour maintenir ta console à l'heure ?

Ouh là ! Il faut s'accrocher, je n'ai pas tout compris. Dans une semaine je serai de retour à Plouguerneau. Avec mes deux consoles je pourrai donc faire des tests mais il semble que des logiciels différents aient des comportements différents face au changement d'heure. Je ne sais plus exactement ce qu'il se passait sur mes graphes Wswin lorsque j'étais en heure locale. Les quelques années ou j'ai fonctionné en heure locale, je pense que j'ai "corrigé" les graphiques. Au passage à l'heure d'été, on passe directement de 1h59 à 3h00. Si on considère qu'une "journée" commence à 0h00 et se termine à 23h59 celle-là ne dure donc que 23 heures puisqu'il manque la période allant de 2h00 à 2h59. Je me trompe ? Et donc, le jour du passage à l'heure d'hiver, la "journée" dure 25 heures. Pourriez vous confirmer ou expliquer puisque Michel n'est pas d'accord avec ce raisonnement.

J'ai effectivement vu ton Edit (sans h ) Je ne saurais plus dire ce qu'il se passait exactement quand mon PC et la console étaient en heure locale. Wswin a toujours piloté directement la console et je n'utilise Weatherlink que de façon accessoire, bien que permanente. Mais il me semble avoir constaté à plusieurs reprises, lors de manips, que Wswin n'écrasait pas des données déjà enregistrées. Quant à Weatherlink, je n'ai jamais vraiment regardé... Toujours est-il qu'en ayant le PC et la console en heure UTC, on est sûr de son coup et certain de ne rater aucune donnée puisqu'il y a continuité de l'heure et des enregistrements.

Voilà comment je vois le problème (sans chercher d'explication sur un tableur...) : Au changement d'heure à l'automne, on passe de 2h59 à 2h00. Wswin (puisque l'on parle aussi de ce logiciel, tout comme Weatherlink) enregistre les lignes de données à : 2h00 ... 2h57 2h58 2h59 Puis il est à nouveau 2h00 ! Mais cette ligne de 2h00 est déjà enregistrée dans le fichier.DAT (et le fichier.wlk) Et que se passe t-il au niveau du datalogger ? WsWin ne va pas écraser cette ligne mais n'enregistrera la prochaine ligne qu'à 3h00. (C'est là ma petite différence d'analyse avec celle de Jacques : il n'y a pas écrasement, mais peu importe) Donc, pendant une heure, Wswin ne va rien enregistrer : ces données sont perdues. Jusqu'à 2h59, on a les données de l'heure d'été et à partir de 3h00 les données de l'heure d'hiver. Sur un graphique, tout peut être OK, mais une heure de données à été perdue.