Station personnelle

Hello Thierry.

Désolé de cette réponse tardive… et un grand merci pour ton avis sur le plugin.

Si je comprend bien, tu as un système (un ensemble de capteurs) qui répond pour chaque valeur sur une url distincte (ai-je bien compris ?). Si c’est le cas, je vais être franc, je n’avais pas du tout envisagé ce genre de cas de figure.
En fait, dans Weather Station, chaque station est composée d’un certain nombre de modules “physiques” qui sont accessibles par la même url.

Pour gérer le système dont tu me parles, il y a donc trois solutions.
– la plus rapide est que tu réalise un module supplémentaire (logiciel et/ou physique) qui se charge d’interroger les bonnes url et fourni un “agrégat” sur une url particulière. Cet agrégat peut être au format ClientRaw ou Realtime pour le moment. Dans une version proche (3.2.x?) le format pourra être aussi stickertags (c’est le format le plus synthétique, et je pense le plus adapté à ton cas).
– la deuxième solution est que j’implémente dans Weather Station un tel type de station. Mais pour faire cela, j’ai un peu besoin d’en tester l’intérêt “pour le plus grande nombre”. Ta station est-elle con?ue de fa?on totalement perso ou repose t’elle sur un article ou un modèle utilisé par d’autres ? As-tu des liens que je puisse aller voir ?
– la troisième est de reprendre les sources du plugin (il est en GPL) et de les modifier toi même.

Dans tous les cas, saches que cela m’intéresse grandement et que je reste à ton écoute pour plus de détails…

Pierre

Hello Pierre !

Pas grave pour le retard dans la réponse ??
Mes modules sont totalement perso… mais inspiré en fait !
On trouve sur Internet pas mal de projets de la sorte : si tu cherches “ESP8266 DHT22” (ou “DHT11”), tu vas tomber sur tout un tas de sites qui proposent le même genre de module. En général on utilise une platine à base de chipset Wifi ESP8266 (qui est programmable comme un ordinateur, soit avec un “OS” intégré (“LUA” ou Python par exemple) ou que l’on reprogramme avec l’environnement Arduino) et un capteur derrière. Voir le schema sur cette page.
Il existe un tas de capteurs dispo pour quelques euros sur eBay; on compte ainsi le DHT22 par exemple qui mesure la température et l’hygrométrie, mais aussi le BME280 qui mesure en plus, la pression atmosphérique. Si tu veux un capteur UV, de qualité d’air, etc… c’est disponible !
Mes modules me reviennent à moins de 10€ pièce… et j’ai souhaité redéveloppé moi même le firmware intégré car les exemples sur internet proposent souvent trop de fonctions ou ne correspondent pas à ce que je souhaitait. Le(s) firmware()s sera(ont) dispo sur mon blog un peu à l’abandon prochainement… le temps de les rendre plus “présentable” ??

Je n’avais pas vu que le plugin utilisait qu’un seul point d’entré (matériel) : je pensais qu’il pouvait en gérer plusieurs en même temps.

Je ne connais pas les agregats “ClientRaw” ou “Realtime” : une doc quelque part ? Je peux peut être implémenter cela dans le firmware ? car je suis loin de pouvoir/savoir modifier ton plugin, même si je connais PHP ??

Thierry

Effectivement, pour le moment le plugin peut gérer plusieurs stations, mais pour chaque station il n’y a qu’un “point d’alimentation” (une url, un web service, un fichier, etc.). Mais ce n’est pas par impossibilité technique ou de conception. C’est juste que pour l’instant je n’y avais pas vu d’application… ?a va peut-être changer, du coup ??

Actuellement, si j’ai bien compris tu as un “endpoint” par valeur mesurée. Publies-tu aussi de cette manière l’unité de mesure ? Ou est-ce que tu “induit” (parce que tu connais ton système) l’unité de mesure ? As-tu la possibilité de les agréger ?

Si tu peux les agréger, c’est top, tu peux les publier aux formats ClientRaw et Realtime qui sont deux formats texte avec séparateur (c’est assez basique, mais ?a fait le job). Pour le ClientRaw, tu peux trouver un descriptif sommaire ici : https://github.com/mapkyca/WD-clientraw-parse et un parser en ligne qui fonctionne bien ici : https://www.tnetweather.com/wdparserold/ . Pour Realtime, tu as des choses ici : https://wiki.sandaysoft.com/a/Realtime.txt et pour le stickertags qui sera supporté dans la 3.2 du plugin, tu as tout ce qu’il faut ici : https://reseaumeteofrance.fr/instructions.php Note que si tu veux voir un fichier stickertags valide, il te suffit de paramétrer Weather Station sur une station WeatherUnderground ou OpenWeatherMap quelconque et choisir de la publier au format stickertags (toute la doc ici : https://weather.station.software/fr/documentation/ )

Je vais regarder l’effort de dev que représente une station dont chaque valeur est sur une url différente. Je pense qu’au niveau ihm/écran ?a peut être un peu lourd, mais why not ?

Je regarde ce week end…

Aujourd’hui les modules envoient une information sous forme de chiffre en texte brut : il n’y a aucune information en dehors de l’URL en elle même pour indiquer quelle type de valeur on re?oit; même si aujourd’hui, j’ai une “différenciation” entre la température et l’humidité par exemple au niveau de mes “endpoints” via la définition de l’URL mais il est vrai que que l’on ne peut pas savoir s’il s’agit d’une température en Celsius, Kelvin ou Fahrenheit ! La valeur est simplement envoyée sous forme de texte “text/plain”.

Aujourd’hui, les valeurs sont rassemblées au sein d’un logiciel “domotique” qui s’appelle tout simplement “Domotics“.

Je vais voir de mon coté si je peux créer un module qui rassemblerait mes capteurs et renverrai alors un état sous forme de fichier Realtime qui me semble simple.

Questions :
– Est-il possible qu’un module n’envoie qu’une ou deux données ? et renvoie cela au format Realtime ? pour être par la suite exploité par ton module ? Il n’y a pas de minimum à renvoyer ?
– Quand on ajoute dans le plugin une source Realtime, il est demandé de définir un type de station : n’y-a-t-il pas un type de source que je pourrais utilisé pour faire des tests ?

Hello !

Désolé de mon temps de réponse, en ce moment je jongle entre boulot et le support du plugin… et ce n’est pas simple ??

Pour ton realtime, il n’y a pas de souci à n’avoir que quelques valeurs dedans. L’essentiel est que ce soient des valeurs qui soient bien “placées”. Par exemple, c’est très important de respecter la distinction intérieur/extérieur. Si ces différences n’étaient pas respectées, Weather Station s’y perdrait totalement pour les calculs d’indices…
Pour le type de station, tu t’en fiches. Mets ce que tu veux (voire, je peux définir un type particulier, genre “home made”). En fait cette valeur n’a pas d’impact sur l’utilisation des valeurs du fichier, elle est là à la demande de certains utilisateurs du plugin qui gèrent plusieurs stations sur un même point (si, ?a existe) et qui voulaient les différencier autrement que par le nom…

à part ?a, ce week-end j’ai regardé comment je pourrais implémenter ce type de stations. Deux remarques à ce sujet : c’est un boulot assez conséquent ET ?a pourrais avoir un interêt certain. Ce qui est sur c’est que ?a ne sera pas dans version 3.x, il y a trop d’autres choses importantes dans mon backlog. Mais pour la 4.x ?a peut être jouable…
Concernant tes modules, je me posais une question : ont-ils la capacité à faire un POST ou utiliser un modèle publish/subscribe de type MQTT. Si je pose cette question, c’est que dans la 4.x j’ai comme idée de faire de Weather Station un mini broker (MQTT ?) et que ?a pourrait aussi être une réponse à ta question.

A+
Pierre