J’espère que tu l’a installé car aujourd’hui tu aurait pu carrément le tester avec la flotte qu’on viens de prendre 
Le miens viens de boire 33mm.
2 « J'aime »
Malheureusement non!
J’ai pas eu le temps de faire les réglages…
2 « J'aime »
Merci pour ce thread,
pour info, pour le scenario, j’ai fait un peu plus simple :
1 virtuel avec 4 commandes de type info (horaire, quotidienne, hedbomadaire et mensuelle, :
- 4 scenarios très (très) simple, programmés, qui se lancent respectivement toutes les heures (à 00), tous les jours (minuit), toutes les semaines (Lundi à 00h00) et tous les mois, avec une action event qui renseigne respectivement les 4 commandes ci-dessus avec la valeur
stateChanges(#[Infra Domo][_pluviometre][Ouverture]#,1 day)
1 day a adapter en fonciton de la commande info concernée (1 hour, 1day, 1week, 1 month)
dans le cas ci-dessus le nombre de chgt d’etat du capteur d’ouverture == le nombre de bascules du chariot sur le dernier jour.
Suffit ensuite de multiplier soit dans le scenario, soit via une formule dans la commande info virtuelle par la contenance d’un chariot
Norbert
2 « J'aime »
J’ai par contre un petit pb de positionnement du capteur d’ouverture. J’ai du mal à trouver la position ou il détecte l’ouverture d’un coté de la bascule et la fermeture de l’autre coté.
Comment avez vous positionné les repères présents sur les 2 pièces du capteur ?
Norbert
Le calcul, ce n’est pas simplement la contenance du chariot.
Il prend en compte la surface de récupération de la pluie (capot supérieur).
Pour notre cas, 1 mouvement correspond à 0.25584795mm d’eau, donc une hauteur.
Sinon bonne idée ce virtuel !! je me le rajouterai 
Pour le placement du capteur et de son aimant, le capteur a une petite encoche, c’est le côté ou l’ILS est placé, il devient passant quand un aimant se place devant.
Sur ma photo du milieu, post #11, tu peux voir que le capteur n’est pas centré. Il est légèrement sur l’un des côté.
Il ne change d’état que quand l’aimant se place en face quand il bascule.
Il faut trouver le bon placement, le bon équilibre.
Bon c’est vrai que c’est chiant, mais quand ça marche 
Bonjour à tous,
pour votre info, une petite pièce pour « caller » le chariot et éviter qu’il ne saute, lorsqu’on bouge le pluviomètre, à positionner coté opposé du détecteur d’ouverture et bien sur ne touche pas le chariot …
CALLE PLUVIOMETRE v3.stl.txt (274,9 Ko)
Norbert
2 « J'aime »
Salut PaTitan,
Merci pour le partage.
Tu pourrais m’expliquer quelques points de ton scénario?
Tout d’abord, quelle est la condition de déclanchement? Provoqué avec le changement d’état du capteur d’ouverture j’imagine. Ou c’est un cron style « toutes les minutes ou heures »?
Que se cache derriere #personnes telegram PaTiTan - xxxx#? J’imagine que c’est des notifications mais je ne vois aucun tags ou autre pour définir le message.
Dans ton premier bloc « alors », il y a un sous bloc « dans » qui démarre un scenario non renseigné. Quel est le but?
Dans le bloc « sinon », sous bloc « dans 15 »: le calcul de pluy_conso_fin et pluy_total est le même, c’est normal?
Merci pour ton retour.
s[quote=« PaTiTan, post:9, topic:55733, full:true »]
Pour les photos, c’est pas tout de suite car il pleut^^
Pour le scénario, il est un peu grand mais complet. Il m’envoi cela :
Voila le scénario (glisser l’image dans un nouvel onglet pour la voir clairement.
Je précise que je ne suis pas un expert, le scénario peux être allégé.
[/quote]
Salut
Tout d’abord, quelle est la condition de déclanchement? Provoqué avec le changement d’état du capteur d’ouverture j’imagine. Ou c’est un cron style « toutes les minutes ou heures »?
Oui c’est le changement d’état du capteur qui provoque le scénario.
Que se cache derriere #personnes telegram PaTiTan - xxxx#? J’imagine que c’est des notifications mais je ne vois aucun tags ou autre pour définir le message.
C’est mon télégram personnel, j’ai remplacer les chiffres par des X (question de sécurité).
Les messages associés les voila dans l’ordre :
Dans ton premier bloc « alors », il y a un sous bloc « dans » qui démarre un scenario non renseigné. Quel est le but?
le scénario non renseigné est en fait ce scénario, (il est passé sur « aucun » lors d’une fausse manip).
C’est pour l’actualisé.
Dans le bloc « sinon », sous bloc « dans 15 »: le calcul de pluy_conso_fin et pluy_total est le même, c’est normal?
Oui car l’un me sert pour le 2ème message, l’autre pour un virtuel.
Merci pour ton retour.
Et en déclenchement, tu n’as que ca? Tu ne le déclanche pas à 00h00 aussi? Sinon, comment tu executes la derniere action « a 0001 »?
Oui je n’ai que ça
Car quand ce scénario se déclenche, c’est qu’il a plu donc une action est programmé à 0001 pour remettre à zéro la variable.
Par contre, elle n’a pas besoin d’être systématique car s’il ne pleut pas, il n’y a pas besoin de la remettre à zéro.
Bonjour, j’ai réalisé votre pluviomètre zigbee. Il me reste juste à faire la formule ou scénario pour le comptage.
1 « J'aime »
Jolie !!
Il faut bien veiller à l’équilibré (base et chariot) pour que les calculs soient correctes.
Quand c’est fait, la petite formule qui va bien et un scénario puis c’est fini
Voila le calcul brut de la sauce qu’on viens de prendre aujourd’hui :
Le chariot a basculé 48 fois, ce qui donne 12.28mm de tombé aujourd’hui
la valeur d’un Netatmo pas trop loin de chez moi :
1 « J'aime »
Merci, pour les infos. J’ai équilibré le chariot avec un écrou et du double face.
Le calcul, je vais tester.
Oui j’ai vu ça 
Si le chariot bascule d’un côté à l’autre avec la même quantité de liquide alors la justesse du calcul sera à son paroxysme (mot compte triple).
Faut que je prenne le temps d’ouvrir un topic pour ce pluviomètre, ça pourrait en intéressé plus d’un
Je lance l’impression d’un pluviomètre, je ferais le tuto avec car la flemme de le faire avec celui installé dehors.
1 « J'aime »
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 »