Un grand merci.
Bonsoir, dernière question vous avez pris quoi comme widget ?
C’est du fait maison avec la création de Widget du Core.
Le premier, voila les 2 images :
Le 2ème, associé à un détecteur de pluie, j’en ai parlé plus haut.
Pour la valeur, c’est le widget « Tile » du core appliqué sur la valeur numérique du virtuel que j’ai créé pour le pluviomètre.
Merci à @Salvialf pour son super site d’icônes 
http://jeedomalf.free.fr/galerie/
Je l’ajouterai à mon topic sur le pluviomètre
1 « J'aime »
Bonjour à tous,
Un grand merci pour toutes les idées, les stl, etc. Je me suis aussi lancé enfin dans la réalisation récemment.
Impression 3D basée sur le STL de la discussion. Nickel, j’ai eu cependant un souci pour la fermeture entre le capot et la bas. j’ai du rogner un peu les encoche au cutter. Surement mes paramètres d’impression j’imagine… ça bloquait pour fermer complétement le pluviomètre.
Voilà quelques photos de l’impression sur une geetech a20m :
Après quelques tests d’équilibrage, je pense avoir réussi à trouver une situation optimale, mais celle ci va changer plus-tard donc je devrais refaire le boulot de mise à niveau… en attendant, j’ai déposé le pluviomètre dans un pot de fleur et remis de niveau… il s’y confond presque avec la couleur du PLA…
Pour la partie Jeedom, voilà ma logique… en me basant sur les différents cas postés ci-dessus, j’ai pris le parti d’utiliser l’historique de Jeedom pour faire mes calculs en mm. Il n’y aura pas de scénario à chaque changement d’état du capteur. Je n’ai pas vraiment besoin d’avoir la valeur à jour à chaque changement. Une valeur mise à jour toutes les heures par exemple me suffit amplement.
J’ai donc un scénario qui se lance toutes les heures. A voir dans le temps si ça correspond à mon besoin. Et si la lecture de l’historique ne devient pas trop lourde avec le temps.
Pour commence, le capteur appairé sous le plugin Zigbee :
Avec l’historique d’activé.
J’ai un virtuel qui recense 8 commandes…
4 commandes qui vont contenir le nombre de changement de valeur pour chaque périodes (Jour / Semaine / Mois / Trimestre) :
4 commandes qui contiennent le calcul pour la transcription en mm
CommandeNombreDeChangement*0.25584795
Pour la partie scénario voilà comment j’ai procédé…
1 scénario qui parcours l’historique et met le nombre de changement de valeur de la période souhaitée dans mes 4 commandes virtuelles.
Il s’exécute toutes les heures, largement suffisant sans trop solliciter jeedom. Cela me semble un bon compromis qui peut surement changer plus-tard.
Il est relativement simple :
4 actions « event » pour modifier chaques commandes de mon virtuel (heure/jour/mois/trimestre) en se basant sur l’historique du capteur aqara.
Je me suis basé sur la fonction stateChange. (J’ai un comportement que je n’ai pas compris, j’ai du additionner les state change de la valeur 1 et 0 car si je ne met pas de paramètre de valeur, il compte que les changements de la valeur en cours)
Ca donne ça pour chaque commande :
Jour :
stateChanges(#[Environnement][pluviometre][Ouverture]#,0,1 day)+stateChanges(#[Environnement][pluviometre][Ouverture]#,1,1 day)
Semaine :
stateChanges(#[Environnement][pluviometre][Ouverture]#,0,1 week)+stateChanges(#[Environnement][pluviometre][Ouverture]#,1,1 week)
Mois :
stateChanges(#[Environnement][pluviometre][Ouverture]#,0,1 month)+stateChanges(#[Environnement][pluviometre][Ouverture]#,1,1 month)
Trimestre :
stateChanges(#[Environnement][pluviometre][Ouverture]#,0,3 month)+stateChanges(#[Environnement][pluviometre][Ouverture]#,1,3 month)
Voilà, encore une façon de faire différente. Avec ses avantages et inconvénient. Mais cela me convient pour l’instant. Mon objectif était de simplifier le plus possible mon scénario et réduire ses lancements.
Pour la partie visuel, je reste sobre avec le widget core « Rain » qui est vraiment nickel pour moi.
Comme tout sur la domotique, ça va forcément évoluer, s’améliorer avec le temps et les retour de chacun 
Plus qu’a le voir évoluer dans le temps. j’ai pas encore beaucoup de recul. Surtout que je l’ai mis en place il y a peu. Et depuis … il ne pleut plus vraiment
Mikeul
7 « J'aime »
Et voila le tuto :
J’ai mis en bonus un détecteur de pluie et un détecteur d’inondation basé sur les capteurs d’ouverture de porte
4 « J'aime »
Super merci
1 « J'aime »
Bonjour, j’essai de réaliser ce pluviomètre.
Le capteur fonctionne bien l’équilibrage est correct, la bascule se produit avec 2,7 ml d’eau.
J’ai été infoutu de convertir en mm d’eau.
Je n’utilise pas jeedom mais ma propre application (ex informaticien à la retraite ça me fait passer le temps l’hiver)
Mon appli est basée sur zigbee2mqtt + un collecteur qui récupère les changements des capteurs + un interface Web d’affichage
En comparant avec un pluviomètre de jardin, je suis loin du compte 4,8 mm contre 18 mm
En plus quand il pleut très peu j’ai l’impression que le PLA ne ‹ glisse pas assez ›
Pourriez-vous me donner un avis.
Merci
Bonjour, je veux bien que vous m’expliquiez vos calculs, j’ai du mal avec et mes résultats sont assez décevants.
Hello,
1- Il faut sûrement utiliser un entonnoir très lisse où l’eau ne puisse pas faire de goulette.
2- Je pense qu’il faut procéder par comparaison. On arrose en même temps le pluviometre connecté et le pluviometre gradué puis on fait ces calculs pour obtenir le même résultat.
ex= 50mm en réel pour 5 bascules donc pour chaque bascule, on incrémente de 10 mm une variable « pluie ».
Cette variable pluie peut être utiliser dans d’autres variable de type « pluie par jour », « pluie pour la semaine »
Hello, même retour sur le côté rugueux des strilles de l’impression.
J’ai légèrement amélioré la chose en passant un spray hydrophobe qui forme une couche plutôt lisse sur la surface.
1 « J'aime »
Peut-être plus de réponses dans mon tuto ?
Pour ma part, je fais le comptage avec cette formule :
(statistics(#[Logia][Compteur de pluie][etat]#,count,today)) * 0.25584795Chaque mouvement est multiplié par 0.25584795, le résultat est en « mm » de pluie.
Ce nombre provient d’un calcul qui a été fait avec la surface de récupération du capot et la quantité d’eau d’un côté du chariot.
@mikeul oui j’ai fait pareil avec un tropicalisant
1 « J'aime »
j’en est une entre la rochelle et niort si tu as toujours besoin
Oui je suis toujours preneur mais on est pas à coté car je suis à Pau
lol effectivement
1 « J'aime »
Hello @PaTiTan j’ai un peu créer le même système avec un MISOL soudé à un capteur ouverture aqara.
Seul soucis la fonction statistics me compte 9 bascule ce jour alors que je n’ai pas eu de pluie, en regardant l’historique pas de passage à 0 du capteur mais il compte un changement à chaque date de valeur
Une idée pour corriger ceci ou si possible de partager ton calcul ? (si il a changé)
Merci
Salut,
Regarde au niveau des répétitions de valeurs sur le déclencheur
S’il est a oui c’est que même en étant à 0, il déclenchera.
La fonction statistique est bien sur l’info de ton capteur ?
C’est aussi bien le déclencheur de ton scénario ?
Tu as bien activé l’historique sur cet information ? si oui, il devrait te montrer les différents changements d’état pour avoir 9 bascules…
mon calcul qui était dans le lien plus haut :
(statistics(#[Logia][Compteur de pluie][etat]#,count,today)) * 0.25584795
Ce matin, 5.11mm de pluie
je n’ai pas de scenario je tente juste un virtuel deja avec statistics et j’ai plus de comptage que de changement d’etat…