Aller au contenu

Ce tchat, hébergé sur une plateforme indépendante d'Infoclimat, est géré et modéré par une équipe autonome, sans lien avec l'Association.
Un compte séparé du site et du forum d'Infoclimat est nécessaire pour s'y connecter.

Raph06

Responsable Technique
  • Compteur de contenus

    480
  • Inscription

Tout ce qui a été posté par Raph06

  1. Bonjour à tous, Je suis en train d’écrire un script permettant de générer une base climato quotidienne des quelques stations que je « gère » (réseau de l’association Nice Météo 06). Pour la technique, les valeurs de ces stations sont enregistrées en base de données, et c’est le logiciel WeeWX qui gère cet enregistrement. Le but est ici de créer une BDD supplémentaire qui accueillera la climato quotidienne générée par ce script pour chacune des stations. Concernant les méthodes/normes, j’ai pas mal de questions sans réponses, malgré de nombreuses recherches sur le forum ici, sur les guides de l’OMM (WMO) et discussions avec des profs de climato… (dont Pierre Carrega). Tout reste un peu confus, et j’aimerais savoir si quelqu’un connait un document officiel (OMM ou Météo-France) avec des instructions pour le calcul de climatologie quotidienne, que j’aurai éventuellement pu louper… Et à défaut, quelle est la pratique la plus souhaitable à votre avis ? Mes interrogations portent principalement sur la définition d’une journée météorologique (au niveau des horaires de fin et début). Pour commencer : On sait tous que les Tn sont calculés entre 18h UTC la veille et 18h UTC le jour même. On sait tous que les Tx sont calculés entre 6h UTC le jour même et 6h UTC le lendemain. On sait tous que le cumul de précipitations (RR) est calculé entre 6h UTC le jour même et 6h UTC le lendemain. Ce sont les normes OMM, avec leurs avantages et inconvénients, je pense qu’il n’est pas la peine d’en débattre ici. Pour les températures En ce qui concerne le calcul de la moyenne quotidienne de température, plusieurs solutions/méthodes entre : La moyenne « standard » (Tn+Tx/2), La moyenne des valeurs horaires (T1h+T2h+T3h+...+T24h)/24, La moyenne des valeurs tri-horaires (T3h+T6h+T9h+...+T24h)/8, Et enfin, la moyenne de tous les échantillons disponibles. Ces 4 méthodes donnent des résultats différents, mais intéressants, que l’on pourra préciser/débattre ultérieurement. Mon but (et je le fais déjà d’ailleurs) est de calculer ces 4 moyennes et ensuite de les comparer. Mais pour les générer, plusieurs questions que je me pose : Pour les moyennes horaires et tri-horaires (tels qu’effectuées parfois (ou autrefois ?) par MF), la première valeur de la journée est-elle celle de 00h, ou bien celle de 01h comme écrit dans l’exemple ci-dessus ? Toujours pour les moyennes horaires et tri-horaires, faut-il prendre la valeur à l’heure UTC ou à l’heure LOCALE (en France, +1 en hiver et +2 en été) ? Pour la moyenne de tous les échantillons disponibles, j’aurai tendance à prendre toutes les valeurs relevées de 00h à 23h59min59sec UTC. Pour le vent, la pression, le rayonnement solaire, l’humidité, etc Différents calculs possibles et intéressants en commençant par les « basiques » : moyennes, minimum et maximum. Mais là encore : 4. Sur quelle tranche horaire se caler pour le calcul de ces statistiques ? de 00h à 24h UTC ? Ou de 06h UTC le jour même à 06h UTC le lendemain ? « Tous les passionnés », en commençant par la climato StatIC d’IC et la climato de ROMMA, ont l’air de faire de 00h à 24h pour le vent et le rayonnement. Pourquoi ? Existe-t-il un document officiel qui donne cette norme ? Car je trouve qu’il y a un problème avec cette méthode : Prenons l’exemple d’un orage se produisant de 03h UTC à 03h30 UTC un 15 Juillet par exemple (03h UTC = 05h LOCALE). Le cumul de précipitations de cet orage sera donc enregistré en date du 14 Juillet puisque s’étant produit le 15 avant 06h UTC. Mais la rafale max correspondant à cet orage sera enregistrée à la date du 15 Juillet puisque s’étant produite le 15 entre 00h et 24h UTC. Pas très logique non ? Idem avec la pression. En ce qui concerne le rayonnement solaire, je serai plutôt d’avis de le calculer de 00h à 24h LOCALE pour chez nous même si effectivement le fait de la calculer à l’heure UTC, ou même de 06h à 06h LOCALE ne change pas grand-chose pour la France… Je cherche donc dans un premier temps des réponses à ces 4 questions, puis probablement à plein d’autres. Merci d’avance pour toute proposition constructive, et à toute bonne âme ayant des informations utiles ou des docs à partager, qui pourront éventuellement resservir à d’autres plus tard 😃
  2. Bonsoir, La mise en place d'un WatchDog est pratique, mais attention ce n'est pas non plus une solution. Le WatchDog se "contente" (mais c'est déjà bien d'avoir cette solution) de faire un hard reboot du Pi s'il ne répond plus du tout. Dans l'idéal il est préférable de comprendre la raison du crash du Pi. Car à force de hard reboot on risque de corrompre la carte SD... Il faut donc accompagner le WatchDog d'un système de log, permettant d'enregistrer les redémarrage du Pi (avec date et heure), afin de se rendre compte du nombre de reboot. Si cela arrive plusieurs fois par jour, ce n'est clairement pas bon signe !
  3. Mais pour autant je vois d'autres stations qui ne sont pas en UTC et qui n'ont pas ce souci... 🙄
  4. Et au passage, StatIC de Vence hors ligne depuis hier midi, un camion a arraché la ligne cuivre... À suivre, réparation d'ici à lundi normalement...
  5. Salut Effectivement, c'est moi qui génère les fichiers pour toutes ces stations. Pas de logiciels, mais un script maison qui pioche dans une BDD. Conscient du problème depuis longtemps, mais je n'ai pas eu le temps d'aller au bout du débogage. Surtout que la pluie dans la climato est bonne... Le problème étant justement ce que soulève @mammillaria... aucune doc complète me permettant de comprendre précisément les paramètres obligatoires dans le fichier. Après de très nombreuses comparaisons et tests (merci @Oliv13 qui m'avais transmis à l'époque quelques exemples de fichiers textes ), j'avais abandonné. @mammillaria me vient en aide ces derniers jours pour essayer de comprendre le souci. J'utilise a peu près le même script pour la génération du fichier texte de transmission des données à ROMMA, et chez eux pas de soucis... Une chose qui est possible et qui me vient à l'instant suite à un souci évoqué avec @Sebaas, l'heure transmise dans le fichier, et notamment le paramètre "pluie_cumul_heure_utc" qui n'est pas en UTC de mon côté. Il faudrait peut-être que je test de ce côté la... Donc en attendant, si quelqu'un a une idée, ou une liste de paramètres obligatoires, afin de faire un tuto propre de ce qu'il faudrait intégrer dans le fichier texte afin d'intégrer StatIC, c'est avec plaisir ! Toute critique constructive étant bonne à prendre
  6. Et la possibilité de régénérer le token pour l'accès à l'API, dans les paramètres du compte... Ce n'était pas possible avant non ?
  7. Salut, Pour les parasites dont tu parles, es tu sur qu'il s'agisse vraiment de parasites ? Ce ne serait pas des intras nuageux ? Enfin si ça correspond à un jour avec ciel bleu... Effectivement ! Pour ma part, dans mon coin (PACA), je n'ai remarqué que très rarement de vrais parasites, et je sais que cela correspondait à une zone où l'armée est présente via des installations, ou bien une zone industrielle... Donc possible entraînement militaire avec je ne sais quoi, ou incident sur les zones industrielles.. enfin c'est ce que j'en avais déduis. Avec mon équipe et Yohan de Météo Varoise on compare souvent la localisation de l'impact sur Blitz' et en réel, et ces derniers temps... Elle était franchement bonne (tendance à l'amélioration) avec quelques impacts puissants parfaitement localisé. Il est clair que la densité du réseau améliore la localisation. Tu as une station toi ? Bon courage pour ton dev' !
  8. Une petite photo d'un trampoline, pour illustrer, à la Colle sur Loup par Olivier Morvan Edit : Et si vous vous sentez l'âme de regarder une pub vidéo pour lire un article qui ne mentionne pas une seule fois le terme "mini-tornade" (pour une fois !!) c'est par la : http://www.nicematin.com/vie-locale/des-passionnes-de-meteo-ont-retrace-lincroyable-tornade-de-villeneuve-loubet-qui-a-parcouru-13-kilometres-223638
  9. L'éternel problème aussi... Mais si la licence d'utilisation est bien choisie, je pense qu'il est possible d'utiliser des recours judiciaires si les termes de la licences ne sont pas respectés. En l’occurrence, l'utilisation de la licence CC BY-NC-ND 4.0 "autorise l’utilisation de l’œuvre originale à des fins non commerciales, mais n’autorise pas la création d’œuvres dérivés" : Attribution + Pas d’Utilisation Commerciale + Pas de Modification (BY NC ND) Mais bon c'est un sujet complexe que je ne maîtrise pas vraiment... Alors il faudra surement l'intervention d'un pro pour clarifier cette utilisation Edit : Et puis bon courage à l'équipe pour mettre en place l'API et lui donner les ressources serveurs nécessaires si elle est largement exploitée. Mais c'est le jeu..
  10. Pour compléter les propos de @Tristan06 j'ai sorti une première ébauche cartographique des dégâts que l'on a relevés, mais je n'ai pas encore eu le temps de pointer tous les dégâts relevés par notre collègue Antony car il a fait de nombreuses photos. En attendant pour donner un aperçu : https://static.meteo06.fr/2018.04.12_tornade/ Je mettrais la carte à jour dans la semaine en fonction de mes disponibilités et puis j'essayerai de faire un truc propre avec les photos directs dans les popups.
  11. Super Franck, je n'avais pas vu que tu avais fait un post sur IC ! Oregon, non merci, pour récupérer proprement les données derrière c'est trop emmer**** Superbe nouvelle ça !!! C'est vrai qu'il y aussi l'option des sites étrangers, ça fait des économies, mais d'un autre côté j'aime bien faire bosser MeteoShopping qui est vraiment top au niveau du SAV !!
  12. Exact, et j'avais évoqué le risque à mon collègue qu'avec des % dans le mot de passe, qui se retrouvait donc dans l'URL de l'API ça pouvait poser des problèmes, mais il m'avait justement fait remarquer que sur la première station d'installé et qui contenait aussi un %, cela fonctionnait sans soucis. J'avais donc écarté cette piste. Erreur que je ne reproduirais plus !
  13. Bien vu Fred !!! ça fonctionne ! Mais on va quand même changer les mots de passes histoire d'être tranquille !
  14. Pour info, ça pourra peut-être servir, évitez les symboles dans votre mot de passe de compte WL 2.0 sous peine que l'API ne fonctionne pas... 4 comptes différents avec un mot de passe contenant un "%" et chaque compte ayant une station d'enregistrée : l'API ne fonctionnait que pour un seul de ces comptes. Après plusieurs jours de batailles avec le service client de Davis par mail, on nous informe que finalement c'est le mot de passe qui pose problème, mais qu'ils n'ont pas d'explications du pourquoi cela fonctionne quand même sur un des comptes.... Bref, sans commentaires supplémentaires...
  15. A noter d'ailleurs que le firmware 3.80 était déjà chargé sur des VP2 reçu de chez MeteoShopping il y'a deux semaines de ça ! ça fait ça de moins à faire avant l'installation
  16. En ce qui concerne la fabrication d'un abri à coupelles pour la sonde thermo/hygro, si tu es bricoleur tu trouveras pas mal de tuto sur Internet en cherchant "abri coupelles". Sinon j'ai rédigé un tuto moi aussi, qui me donnes des abris plutôt réussis ça te donne une première base, mais n'hésite pas à consulter d'autres tutos Pour le mât, je laisse les spécialistes, moi j'ai toujours fait avec de la récup', mais ce n'est pas forcément hyper esthétique
  17. Nous avons pris avec @clansvp2 (et avec regret) la décision de ne pas monter... les 5-6 heures de route qui risquent de s'allonger largement au vu des conditions et l'annulation de l'AG en plus nous découragent... idem pour le retour dimanche après-midi, qui pourrait aussi se compliquer au vu des conditions attendues en fin d'aprèm et nuit sur les Alpes-Maritimes... Comme je disais à @Jeff04 nous sommes très déçu, mais on remet ça à une prochaine fois j’en suis certain ! Profitez bien dans ce havre de paix, et surtout soyez prudent sur la route !!
  18. Il faudrait surtout et absolument que tu te fabriques un abri maison ! Celui fourni avec la station est... quasi inutile ! Surchauffe assurée
  19. Et c'est à priori revenu à la normale puisque les données apparaissent de nouveau sur IC
  20. Raph06

    Meteoz

    Excellent ahah !! https://temperature.ga/ Beau boulot ! Au vu du bandeau en bas, tu récupères les données des Netatmo via Weather Underground ? LATITUDE : 43.61******° | LONGITUDE : 7.05******° | ALTITUDE : 122 m | DONNÉÉS : 82 STATIONS NETATMO + 0 STATIONS SYNOPTIQUES + 1 SIMULATION NUMÉRIQUE Par contre tu devrais arrondir le résultat Bonne continuation en tous cas !
  21. Merci pour l'info @Dum-Gui ! Je connais un peu tout ça, j'ai quelques stations qui tournent sous Weewx, mais toute reliée à internet par réseau classique. SigFox me tente depuis quelques temps.. ou Lora le problème est la couverture... Dans les Alpes-Maritimes c'est compliqué à priori des qu'on dépasse le littoral Bonne continuation dans ce projet et pour ta thèse !
  22. Bonjour, Merci pour ces informations, un projet intéréssant ! Je ne suis pas du coin du tout, mais juste un curieux Du coup petite question, sur les RPI (Raspberry Pi), vous ne dites pas dans le PDF joint ce que vous utilisez comme techno ou logiciel pour exploiter les données de la console ? Le logiciel Weewx ? Ou bien des scripts maison qui décodent les trames USB qui remontent de la console ?
  23. Et ça c'est si on arrive à y monter !
  24. Et tout en se servant des données sources de MF, ce site permet un aperçu rapide et pratique de l'ensemble des données du réseau réseau nivo-météorologique Lien direct vers Maljasset : http://nivologie.apyx.fr/station/7933
  25. Et de temps en temps on tombe sur ça aussi
×
×
  • Créer...