Bonjour
Ma tête émettrice sur mon compteur d’eau ne fonctionnait pas depuis qu’elle avait été changée par le service des eaux : status ERROR_FLAGS_0 . J’ai craqué, je l’ai démonté, nettoyée, remontée. Status OK.
Depuis 30 Ans j’ai eu 3 à 4 fuites importantes dont une il y a 2 ans. Cela coûte très cher et c’est du gaspillage. Il y a un plugin stop fuite (stopleak) sur le market. J’ai étudié le principe utilisé et il me semble intéressant. https://www.pasteck.com/plugin-jeedom-stop-fuite/
J’ai donc repris le principe et fais 5 scénarios. Par contre je n’ai pas repris le % de remplissage.
Je vous montre seulement le scénario petite fuite.
avec Durée (sec) : variable(PF_duree_periode) - 5
Suite:
avec Durée (sec) : variable(PF_duree_periode)
Le scénario est lancé en mode programmé toute les minutes.
Il n’est pas possible simplement de boucler un scénario sur l’infini, j’arrête le scénario 5 secondes. Il est redémarré par le cron 1 minute. ( avec Durée (sec) : variable(PF_duree_periode) - 5 )
Cela va induire une petite erreur.
Pour les courbes et les calculs, je travaille avec les 4 derniers chiffres de mon compteur, j’ai créé un virtuel avec :
Le virtuel Petite fuite:
Mon compteur me délivre 1 à 4 trames par minute:
Les alarmes:
Pour les petites fuites l’alarme est générée après les 24 périodes d’une heure. la pré-alarme est générée à la 12ème période. J’anticipe. Les alarmes sont mémorisées, un scénario reset les alarmes en manuel.
En conclusion: La détection de fuite d’eau n’est pas si simple lorsque que l’on y réfléchi.
Je ne suis pas un pro du scénario, je pense que l’on peux faire mieux et optimiser.
Jeedom est installé sur une VM Proxmox, pour le compteur j’ai utilisé le programme wmbusmeters sur une autre VM avec remontée des trames sur mqtt manager.
Je remercie MrGreen pour le principe de détection.
Nota : Ne pas prendre mon scénario pour argent comptant, c’est plutôt expérimental.
Cordialement












