jackT

Voici donc une fonction php : function est_ensoleille($longitude,$latitude,$jour,$mois,$annee,$heure,$minute,$radiation){ if (checkdate($mois,$jour,$annee) and ($heure <> "--") and ($minute <>"--") ) { $utcdate = local_to_UTC($jour, $mois, $annee, $heure, $minute); $timestamp = mktime($utcdate['heure'], $utcdate['minute'], 0, $utcdate['mois'], $utcdate['jour'], $utcdate['annee']); $dayofyear = date("z", $timestamp); $theta = 360 * $dayofyear / 365; $equatemps = 0.0172 + 0.4281 * cos((pi() / 180) * ($theta)) - 7.3515 * sin((pi() / 180) * ($theta)) - 3.3495 * cos(2 * (pi() / 180) * ($theta)) - 9.3619 * sin(2 * (pi() / 180) * ($theta)); $corrtemps = $longitude * 4; $declinaison = asin(0.006918 - 0.399912 * cos((pi() / 180) * ($theta)) + 0.070257 * sin((pi() / 180) * ($theta)) - 0.006758 * cos(2 * (pi() / 180) * ($theta)) + 0.000908 * sin(2 * (pi() / 180) * ($theta))) * (180 / pi()); $minutesjour = $utcdate['heure'] * 60 + $utcdate['minute']; $tempsolaire = ($minutesjour + $corrtemps + $equatemps) / 60; $angle_horaire = ($tempsolaire - 12) * 15; $hauteur_soleil = asin(sin((pi() / 180) * ($latitude)) * sin((pi() / 180) * ($declinaison)) + cos((pi() / 180) * ($latitude)) * cos((pi() / 180) * ($declinaison)) * cos((pi() / 180) * ($angle_horaire))) * (180 / pi()); if ($hauteur_soleil > 3) { $seuil = (0.73 + 0.06 * cos((pi() / 180) * 360 * $dayofyear / 365)) * 1080 * pow((sin(pi() / 180 * $hauteur_soleil)), 1.25); if ($radiation > $seuil) return true; else return false; } else return false; } else return false; } Les paramètres de la fonction sont : longitude, latitude : coordonnées de l'emplacement du pyranomètre ou luxmètre jour, mois, année, heure, minute : la date et l'heure de la mesure de radiation radiation : la valeur, en W/m2, de la radiation mesurée La fonction retourne true si la radiation mesurée et en dessus du seuil, et false autrement L'idée est que pour chaque mesure successive de radiation, la fonction est appelée. SI la fonction retourne true, on considère ,par approximation, que la période entre la mesure précédente et cette mesure a été ensoleillée. Par exemple, avec un intervalle de mesure de 5 minutes, si la fonction retourne true, on comptabilisera 5 minutes d'ensoleillement pour cette mesure. Le mieux est d'avoir des intervalles de mesure de radiation le plus court possible , ce qui rendra le calcul d'ensoleillement plus précis.

L'estimation du temps d'ensoleillement en appliquant un seuil fixe (120 W/m2 ou autre) sur des données de pyranomètre ou luxmètre va donner des données très irréalistes. Concernant la comparaison pyranomètre Davis et luxmètre Ecowitt, je m'imaginais que les mesures seraient bien différentes, le pyrano Davis captant une bande de fréquence plus large que le spectre visible capté par un luxmètre, et que la formule du calcul de l'ensoleillement "DAVIS" ne serait pas applicable aux données d'un luxmètre. Ayant depuis quelques temps un Ecowitt WS90 (j'étais iinteressé par la technologie de mesure de pluie de ce capteur) , j'ai donc les mesures du luxmètre, et j'ai comparé les 2 mesures. Il est généralement admis qu'on peut "convertir" des données de luxmètre (lux) en W/m2 en utilisant la formule suivante : W/m2 = lux/126.7. En comparant avec mon pyranomètre Davis, la formule suivante W/m2 = lux/113, donne des valeurs les plus proches entre pyranomètre et luxmètre : Sur ce graphique des 7 derniers jours, les temps d'ensoleillement (indiqués en dessous du graphique) sont les même : 980 minutes , et sont calculés (par période de 10 minutes ) en utilisant la "formule DAVIS", celle utilisée par Infoclimat, ROMMA et par l'extension weewx que j'ai écrite. Le seuil d'ensoleillement calculé est affiché en noir sur le graphique. Sur les 30 derniers jours : avec un temps d'ensoleillement de 4010 minutes pour le pyranomètre VP2 et 3900 minutes pour le luxmètre, soit moins de 3% de différence. Les graphiques interactifs peuvent être vus ici : http://meteo-sciez.fr/site/graphiques_sun.php Il semble donc raisonnable d'utiliser la formule "DAVIS" pour estimer le temps d'ensoleillement à partir d'un luxmètre Ecowitt, en ajustant éventuellement le facteur de conversion lux -> W/m2. @Pascaloux : Si cela peut t'être utile et si tu es à l'aise avec le php, je peux te transmettre une fonction écrite en php qui fait le calcul du seuil et qui pourrait te permettre de calculer le temps d'ensoleillement .

A priori non, sauf si une autre station DAVIS d'un voisin proche est à portée et que les ID sont en conflit. Les mêmes intervalles de transmissions de deux ISS de même ID peuvent perturber la logique de réception. Pour le reste, même avec 5 fréquences distinctes utilisées par Davis, certaines perturbations électromagnétiques de sources diverses peuvent perturber la bonne réception des signaux des transmetteurs.

Oui. Pour les transmetteurs DAVIS européens, 5 fréquences sont utilisées dans un ordre successif pré-établi. Ce n'est pas la fréquence qui différencie les ID, mais l'intervalle d'émission de chaque ID est décalée pour minimiser les collisions. L'ID concerné est codé dans chaque paquet transmis. Pour les transmetteurs aux Etats-Unis, ce sont 51 fréquences qui sont utilisées ! Davis n'a jamais communiqué sur le protocole de transmission, mais celui-ci a été trouvé il y a déjà un certain nombre d'années et est utilisé par exemple par le "Meteostick" et la version Pro du Meteobridge - voir https://www.wxforum.net/index.php?topic=36267.0 Un driver weewx a aussi été développé (https://github.com/lheijst/weewx-rtldavis) qui peut être utilisé par exemple avec un raspberry Pi + une Clé USB RTL2832 qui capte directement les paquets envoyés par les transmetteurs Davis.

Vérifie dans les réglages de la console Vantage Vue que le "serial baud rate" est réglé à 19200. Le datalogger IP communique avec la console en 19200 baud voir aussi :

Tu peux toujours essayer, mais du coup je doute que cela change quelque chose. Comme tu sembles avoir 2 consoles, est-ce que les deux consoles affichent des rafales ou températures à 0 lorsque le problème survient? Si c'est le cas, c'est alors peut-être un problème avec la carte électronique de l'ISS.

Les paquets envoyés par les différents transmetteurs sont envoyés régulièrement, mais avec un décalage temporel pour éviter les collisions : ID=1 envoyé toutes les 2.5625 secondes ID=2 envoyé toutes les 2,625 secondes ID=3 envoyé toutes les 2.6875 secondes et ainsi de suite avec un décalage additionnel de 0.0625 secondes pour chaque ID supérieur. Le premier octet de chaque paquet contient le capteur concerné et le numéo de l'ID Un transmetteur utilise pour l'envoi de chaque paquet une des 5 fréquences définies (868077250 Hz, 868197250 Hz, 868317250 Hz, 868437250 Hz, 868557250 Hz), dans un ordre pré-établi.

L'ID de chaque transmetteur se règle en modifiant la position de 3 cavaliers situés en haut et à droite à l'intérieur de lu tranmetteur : Mets ton ISS principal sur l'ID 4 (off ON ON), et modifie le setup de la console pour qu'elle capte l'ISS sur l'ID 4 : presser simultanément sur la touche DONE et la touche - jusqu'à l'affichage suivant : presser sur DONE pour le réglage de lID 1, et appuyer sur la touche - pour mettre la réception du canal 1 à OFF presser trois fois sur la flèche droite (>) pour arriver au réglage du canal 4 presser la touche + pour activer (ON) la réception de l'ID 4. Si l'affichage indique autre chose que ON (ISS) , presser sur la touche GRAPH pour sélectionner ISS appuyer longuement sur DONE

c'est probable. Demande à ton voisin quel(s) ID il utilise - probablement au moins le 1 qui est celui par défaut. Si c'est le cas, essaie de changer l'ID de ton ISS avec un ID qui n'est pas utilisé par ton voisin. Tu pourras ainsi voir si le problème vient de là.

Ce n'est pas un skin weewx. mais j'ai le projet d'en faire un skin.

Dans le log de weewx, weewx.reportengine indique le plus souvent qu'aucun fichier n'a été copié. Un extrait de mon log indique aussi qu'aucun fichier n'a été copié : jan 21 12:50:17 meteopi5 weewxd-vp2[2742127]: INFO weewx.cheetahgenerator: Generated 8 files for report SeasonsReport in 0.27 seconds jan 21 12:50:17 meteopi5 weewxd-vp2[2742127]: INFO weewx.imagegenerator: Generated 19 images for report SeasonsReport in 0.30 seconds jan 21 12:50:17 meteopi5 weewxd-vp2[2742127]: INFO weewx.reportengine: Copied 0 files to /home/meteo/weewx-data/public_html/weewx jan 21 12:50:18 meteopi5 weewxd-vp2[2742127]: INFO weewx.cheetahgenerator: Generated 4 files for report tagssciez in 0.44 seconds jan 21 12:50:18 meteopi5 weewxd-vp2[2742127]: INFO weewx.reportengine: Copied 0 files to /home/meteo/weewx-data/public_html/weewx/tagssciez jan 21 12:50:39 meteopi5 weewxd-vp2[2742127]: INFO weewx.cheetahgenerator: Generated 10 files for report WdcReport in 15.31 seconds jan 21 12:50:39 meteopi5 weewxd-vp2[2742127]: INFO weewx.reportengine: Copied 0 files to /home/meteo/weewx-data/public_html/weewx/wdc ... ... jan 21 12:55:45 meteopi5 weewxd-vp2[2742127]: INFO user.sftp: sftpgenerator: transferred 61 files in 5.81 seconds et pourtant les fichiers ont bien été générés au bon endroit, puis transférés par sftp sur mon site ! Vérifie les fichiers qu'il y a dans /home/pi/weewx-data/public_html et leurs dates de modification pour confirmer que les fichiers ont bien été générés. EDIT : Note technique : Pour chaque "skin", il y a des fichiers générés (selon la section [CheetahGenerator] du fichier skin.conf) et des fichiers copiés (selon la section [CopyGenerator]) Les fichiers définis dans [CopyGenerator] (copy_once = ... ). ne sont copiés qu'une seule fois au démarrage de weewx Ensuite, seuls les éventuels fichiers définis dans copy_always = sont copiés à chaque archivage. Donc tous les skins qui n'ont pas de [CopyGenerator] copy_always = ... auront dans le log : INFO weewx.reportengine: Copied 0 files to ...

Ce paramètre "maxSolarRad_Wpm2" est bien calculé par weewx, mais ne concerne pas les UV. C'est la valeur théorique de radiation solaire maximum , en W/m2, qu'on peut s'attendre à mesurer en absence de nuages. Il y a le choix de deux algorithmes différents pour ce calcul, et deux paramètres additionnels peuvent être ajustés - voir https://weewx.com/docs/5.1/reference/weewx-options/stdwxcalculate/?h=maxsolarrad#maxsolarrad

Les capteurs baromètre, température et humidité intérieure sont à l'intérieur de la console, et donc aucune transmission 433 Mhz n'est faite pour ceux-ci. SI tu veux que weewx reçoive les données barométriques, il faudrait installer un capteur connecté directement au raspberry et s'arranger que weewx récupère ses données. Concernant les uv, il semble que ta station ( est-bien une Raddy MN6 Lite Station météo 5 en 1 ?) n'a pas de capteur uv ni de radiation solaire.

Un certain nombre d'hébergeurs ne permettent pas de connexions directes depuis l'extérieur sur leurs serveurs MySQL. A vérifier avec l'hébergeur en question. Une carte SD de qualité peut durer des années. Voir par exemple l'expérience de l'auteur de Weewx, qui utilise sans problèmes la même carte SD (Sandisk Extreme Plus 16GB SD card) depuis décembre 2014 : https://www.threefools.org/weewx/status/index.html

En ce qui concerne ta configuration du FTP, oui, il faut bien mettre : [[FTP]] # FTP'ing the results to a webserver is treated as just another report, # albeit one with an unusual report generator! skin = Ftp ... ... ... Sinon ton log indique bien les 53 transfers ftp sans erreurs vers meteo-montrealmalepere11.fr .... Côté meteo-montrealmalepere11.fr, peux tu consulter un log du serveur FTP pour voir si il y a des erreurs ? Edit : vérifie aussi sur ton hébergement que le dossier de base de l'utilisateur FTP que tu utilises pour les transfers FTP depuis weewx est bien à l'endroit que tu attends.

Comme ton problème semblait venir de la configuration de ton réseau, je n'avais inclu que les informations concernant les ports utilisés par le mqtt Le contenu complet de ma configuration mosquitto est la suivante : listener 1883 listener 8083 protocol websockets allow_anonymous false password_file /etc/mosquitto/passwd acl_file /etc/mosquitto/acl En utilisant le skin Belchertown, l'adresse du serveur mqtt utilisé ainsi que les éventuels nom d'utilisateur et mot se passe sont écrits en clairs dans le script belchertown.js. Si il n'y a pas un contrôle d'accès strict dans mosquitto, rien n'empêche quelqu'un d'averti de pouvoir utiliser ton serveur mqtt pour ses propres besoins. En ce qui me concerne, j'ai défini un nom d'utilisateur "public" et mot de pass "public" qui n'a accès qu'en lecture seule au serveur mqtt. J'utilise un autre utilisateur et mot de passe pour permettre à weewx de publier ses données au serveur mqtt.

Voici mes paramètres mosquitto : listener 1883 listener 8083 protocol websockets J'utilise le port 8083 pour les websockets, mais tu peux utiliser 9001 pour autant que ce port ne soit pas déjà utilisé par ton NAS. L'important est que le port websockets configuré dans mosquitto soit le même que celui configuré dans le skin Belchertown ( mqtt_websockets_port = 9001). Dernière chose : si tu veux que les navigateurs des visiteurs extérieurs puissent se connecter au mqtt , il faut aussi rediriger sur ta box le port 9001 vers le NAS.

J'ai zappé ce point ! Si il y a écrit connecté, c'est que le navigateur est bien connecté au serveur mqtt , mais qu'il ne trouve pas le "topic" loop qui contient en format json toutes les données agrégées des capteurs dont a besoin le skin belchertown . Donc comme suggéré par @970hPa, regardes avec mqtt explorer si tu as bien un topic "loop" dans les messages mqtt.

Donc dans ce cas, nginx ou tout autre serveur web n'est pas concerné, car la page web s'ouvre correctement. C'est le navigateur du visiteur du site qui, une fois la page web chargée, va essayer de communiquer directement (via un script javascript) avec le serveur mqtt configuré . Si ton site est accessible de l'extérieur, peux-tu communiquer l'URL du site, ce sera plus facile pour vérifier les erreurs javascript concernant la connexion au serveur mqtt et avancer pour résoudre le problème !. Edit : pour info, c'est la fonction connect() du script belchertown.js qui se connecte au serveur mqtt

Si j'ai bien compris, tu as une adresse ddns pour ton nas ( par exemple nas.synology.me) et un reverse proxy pour ton raspberry ( par exemple rasp.nas.synology.me). As-tu bien utilisé le domaine du nas (et non celui du raspberry) dans mqtt_websockets_host et aussi configuré sur ta box une redirection du port 1883 ( ou le port que tu a configuré dans mqtt_websockets_port) vers le nas?

Bonjour, Le skin Belchertown est-il configuré avec l'adresse interne LAN du NAS ? Par exemple # MQTT Websockets defaults mqtt_websockets_enabled = 1 mqtt_websockets_host = 192.168.x.x ... ... Dans ce cas, le NAS, et donc le mqtt, n'est pas accessible depuis l'extérieur et Il faudrait utiliser un service (dyndns, no-ip ou autre) qui redirige la connexion mqtt de l'extérieur vers ton NAS. Ton site belchertown est-il hébergé sur ton NAS ou bien chez un hébergeur externe ?

...et surtout éviter que le soleil soit dans le champ de vision ! Mon MLX90640 a mesuré hier une température de 324°C au niveau du soleil !

Oui, effectivement, pour les nuages hauts (>5000m), la température est surestimée, et donc difficile de calculer leur hauteur réelle. En ce qui concerne la mesure d'un index de couverture nuageuse, qui je pense est réalisable avec ce type de sonde , il me faudra plus de données ces prochaines semaines pour suivre les données et voir ce qu'on peut en tirer. Actuellement, mes sondes thermiques (je viens de rajouter à une MLX90614 une MLX90640 qui mesure sur un champ de vision d'environ 55° une matrice 32X24 de valeurs températures. (mini caméra thermique) ne sont pas orientées de manière optimale. Elles ont sous un avant-toit, protégées de la pluie et pointant le ciel avec un angle d'environ 50°. L'idéal est de mettre les sondes orientées à 90°, à la verticale , c'est là ou l'effet de l'atmosphère est le plus faible, et où les températures du "ciel clair" sont les plus froides . Il reste à trouver un boitier qui puisse permettre aux sondes de supporter la pluie si elles sont orientées à la verticale.

Une première correction à appliquer à de telles mesures est de considérer la différence entre la température apparente des nuages et la température au sol (sous abri) plutôt que la température brute mesurée par le capteur Par exemple, un nuage ayant sa base à 3000m peux avoir une température apparente de 8.8°c ( avec température au sol d'environ 25°C) en été et une température de -11.3°C en hiver (avec une température au sol de 5°C. ). Dans ces deux cas, le différentiel de température sol ( altitude 500m)- nuage est le même. Un deuxième point est que l'épaisseur de l'atmosphère entre le capteur et le nuage va influencer la mesure. Plus la distance sonde-nuage est grande , plus la température mesurée par la sonde IR sera sur-estimée. Donc la relation entre la température différentielle mesurée et la hauteur des nuages n'est certainement pas linéaire.

Ce qui est sûr, c'est que les mesures de la sonde IR MLX90614 que j'utilise (champ de vision de 35°) varient en fonction de la couverture nuageuse (-25°C pour un ciel sans nuage et températures plus hautes selon le pourcentage de nuages et/ou leur hauteur, jusqu'à quelques degrés en dessous de la température sous-abri pour des nuages très bas - status). La valeur de la température mesurée ne sera peut-être pas assez précise pour en déduire une hauteur de nuages, mais cela reste un bon moyen de mesurer un index de couverture nuageuse jour et nuit.