Interface Wifi du compteur Gazpar

Sur la demande de @scotty92fr je me suis penché sur le module Gazpar décrit ici:https://github.com/xlyric/Gazpar-light
Le but de scotty92fr serait de réaliser une sorte de Gazpar en boitier DIN.
j’ai récupéré les sources (merci à clyric pour son travail)
juste une petite erreur lors de la compilation
ligne 50 il y a #define Gazpar D1 il faut #define Gazpar 5
bref ça fonctionne ! (ne pas oublier de téléverser les SPIFFS !)
N’ayant pas de compteur gaz, je ne peux que tester par impulsion réalisé manuellement.


le Dashboard est plutôt sympa.
Sous Jeedom je récupère bien l’info dans un virtuel…sauf que ! sa valeur est toujours 1.
La question que je me pose et aussi à ceux qui maîtrise le code.
Est-ce normal ?
Est-ce que sous Jeedom on se contente de compter les impulsions.
donc de mettre dans le virtuel un value+value ? ? pour additionner les impulsions et du coup le M3 de gaz ?

Je pense que le module n’enregistre pas le cumule et donc il envoi 1 au virtuel a chaque dm3.
L’idéal serait de pouvoir envoyer un cumul de valeur (le nombre de dm3) et donc l’idéal serait de pouvoir initialiser cette valeur

Oui, effectivement, d’après le créateur du programme, une info « 1 » est envoyé à chaque impulsion du Gazpar, charge à Jeedom de compter.
j’ai créé un virtuel qui reçois cette info « 1 »
maintenant, reste à trouver une solution pour incrémenter un compteur .
j’ai fait un scénario, mais c’est pas terrible, il doit y avoir un autre moyen ? j’ai pas trouvé

j’ai testé manuellement:
en faisant un virtuel ‹ testGAZ › avec 2 commandes d’info et un scenario ‹ testGaz ›
Le virtuel:


La commande info Valeur reçoit le 1
la commande info Result conserve le cumul

Le scénario se déclenche a la modification de la commande Valeur:

- Nom du scénario : testGaz
- Mode du scénario : provoke
    - Evènement : #[Sous Sol][test1][Valeur]#
 
  ACTION
     event - Options : {"enable":"1","background":"0","cmd":"#[Sous Sol][testGAZ][Result]#","value":"#[Sous Sol][testGAZ][Result]#+ #[Sous Sol][testGAZ][Valeur]#"}
     event - Options : {"enable":"1","background":"0","cmd":"#[Sous Sol][testGAZ][Valeur]#","value":"0"}

en émulant l’action du module, cela fonctionne . on conserve bien le total dans jeedom

Oui, c’est ce que j’ai fait, mais je trouve bizarre que jeedom ne propose pas un truc plus simple un simple compteur sur impulsion.
J’ai cherché dans les widgets/ plugin ? Et sur l’ancien forum… rien trouvé ? Quelque début d’explication mais pas assez pour finaliser.
La question que je me pose? Est ce qu’avec ESPEasy, ça ne serait pas plus simple ?
Tu as un device pour enregistrer les impulsions et la possibilité d’enregistrer par un dummy le total , ya pas de beau dashboard, mais c’est un peu gadget.

Je ne connais pas l’ ESPEasy, je suis d’accord l’interface est très secondaire, si ça cumule directement les l’impulsion ce serait mieux pour fiabiliser la chose et je vote pour :slight_smile:

C’est bien, l’utilisation d’un scénario est assez simple et fiable, pourtant.
Avec mon module de porte, je reçois toujours la valeur de scène 11 à chaque relâchement de l’impulsion.

  • Une variable IndexGaz stocke la valeur de l’index, que je peux modifier si la valeur est incorrecte
  • Un scénario incrémente de 10dm3 la variable à chaque fois que la scène est mise à jour à 11
  • Enfin un virtuel avec une commande Info qui récupère simplement la valeur de la variable variable(IndexGaz,0)

@scotty92fr, ta commande Result = Result + Valeur fonctionne bien ?

#[Sous Sol][testGAZ][Result]#","value":"#[Sous Sol][testGAZ][Result]#+ #[Sous Sol][testGAZ][Valeur]#

Pour toutes les commandes qui prennent en compte un état précédent, je passe par une variable.

Sinon, il existe des fonctions qui peuvent compter le nombre de fois où la commande est à telle valeur pendant une certaine période. Mais je trouve que les fonctions statistiques ne sont pas fiables.

Toute la problématique est là pour la transmission RF d’un compteur d’impulsion !

J’avais aussi pensé à détourner un capteur de pluie car il a un compteur intégré et transmet la quantité de pluie totale, mais le compteur est limité à 9999mm, soit 99.99m3 de gaz !

Oui ça fonctionne très bien, maintenant ce sont des tests manuels par envoi manuel de
http://serveurJeedom/core/api/jeeApi.php?apikey=ApiKeyVirtuel&type=virtual&id=NumCommande&value=1

Bonjour, j’ai trouvé un module qui transmet en 433 l’index des impulsions à chaque impulsion

J’ai acheté un détecteur d’ouverture Aeotec zwa008 : pour le moment pas encore raccordé au Gazpar, je voulais tester la portée du z-wave au niveau du compteur et a priori ça passe.
Je l’ai pour le moment raccordé à mon compteur d’eau en utilisant l’entrée externe et je dois dire que le résultat est très bon après 2 semaines de test (bien meilleur que tout ce que j’avais pu bricoler jusqu’a présent et qui conduisait régulièrement à des comptages intempestifs - là après 2 semaines j’ai 40l d’écart pour une conso moyenne de 500l par jour donc 7000l sur 2 semaines environ, ça nous fait du 0,6% d’erreur c’est très bon !)
Je vais donc en commander un deuxième et acheter le câble spécial pour équiper mon gazpar

J’ai par contre trouvé le capteur assez capricieux pour le paramétrer (il faut activer l’entrée externe qui est désactivée par défaut) : il ne prenait pas la commande même en le réveillant - j’ai dû le désappairer/réappairer au moins 10 fois avant que ça marche (mon contrôleur z-wave est peut être pas top … c’est une clé que j’avais eu avec ma box TaHoma de Somfy - sûrement moins bien que les clés Aeotec)

Ça me fait plaisir que ça marche bien chez toi.

J’ai activé le paramètre 13 pour avoir les scènes qui fonctionne avec l’entrée externe et laissé le paramètre 1 par défaut avec l’aimant, il reste donc disponible, avec en plus la fonction tilt. Ainsi, on a du 3-en-1.

À garder en tête, ne pas bricoler le réseau Z-Wave (ou redémarrer Jeedom) lorsqu’on tire l’eau. Idem pour le gaz, couper la chaudière avant et ne pas cuisiner.

Bonjour @Domatizer,

Je viens de mettre en place le dispositif
ZWA008 + câble JAE aec scénario sur Jeedom + plugin Energie

Mon scenario :
Déclencheur :
#[Maison][Détecteur dimpulsion][Scene]#==11
Scénario :

Mon virtuel :

Et assez étrangement, mon index sur Jeedom a dépassé mon index sur le Gazpar.
Je pourrais comprendre que la situation inverse se produise ( index Jeedom en retard ( car perte d’impulsion) mais pas en avance … )

As-tu déjà eu ce cas ?
Mon déclencheur de scénario et scénario est bon ?

Merci d’avance,

Bonjour @odemg

Super, tu as réussi à faire fonctionner le plugin (officiel) Energie ?

Oui, ton scénario est bon.
Ton virtuel ressemble aussi au mien (index en dm3, index en m3, coeff, kWh,…)

Bonne remarque ! Oui, j’ai déjà eu ce cas, 1 ou 2 impulsions d’avance sur les 2 compteurs gaz et eau.

Je n’ai pas investigué pour savoir exactement quand ces fausses impulsions ont lieu. Mais, je soupçonne un rafraîchissement des valeurs lors du premier réveil du module après redémarrage du réseau Z-Wave (Il se passe des choses étranges voir l’exemple des portes qui se ferment toutes seules Door/Window Sensor 2 se ferme tout seul lors du 1er réveil).

Dans notre cas, scene vaut toujours 11, il suffit que l’équipement rafraîchisse simplement les valeurs des commandes et hop le scénario se déclenche. Je n’ai trop pas cherché à résoudre ce problème puisque les erreurs d’index en cas de perte d’impulsions l’emporteront sur le long terme.

En revanche, j’ai amélioré le scénario pour lisser les index en cas de correction (dans les 2 sens) si besoin. Pour cela, j’ai créé un 2nd index qui correspond au relevé manuel à un instant t.

  1. Si l’index Jeedom est en avance sur l’index réel, alors je ne fait pas de correction d’index en arrière pour ne pas me retrouver avec des conso négatives et je ne compte pas d’impulsion tant que les 2 index ne sont pas égaux. (Le scénario « attend » que l’index Jeedom rattrape l’index relevé à la main)
  2. Si l’index Jeedom est en retard sur l’index réel, je compte double les impulsions tant que les 2 index ne sont pas égaux.

    Ainsi cela se corrige tout seul dans le temps sans faire des à-coups dans les consommations.

EDIT : Une fois que l’index Jeedom vaut l’index réel relevé à la main, le scénario fait évoluer les 2 index ensemble à chaque impulsion.

Bonjour @Domatizer

Oui ça semble fonctionner, je l’utilise pour l’Elec et je l’ai utilisé pour l’eau ( quand le plugin veolia fonctionnait)

Et si en dernière étape du scénario on change la valeur du scène à 12 par exemple ?

Par contre en regardant les log temps réel, j’ai quand même des pertes de MAJ d’index alors que j’ai bien reçu l’impulsion.

Est ce du à un problème de délais avant re-exécution du scénario ?

J’ai l’impression qu’au mieux mon scénario s’exécute toute les 10s, pourtant sa durée d’exécution n’est que d’1s.

Peut être on peut le corriger en cochant dans le scénario « Multi-lancement » ?

Merci

L’historique dans Jeedom fonctionne à la seconde. Or, la durée de l’impulsion du Gazpar est de l’ordre de la seconde. Bien souvent, c’est trop rapide. L’historique de la commande scene n’a pas le temps de passer à 12 et d’enregistrer cette valeur. C’est pourquoi j’avais choisi 11 comme déclencheur ( le relâchement du bouton d’un appui long) qui marche à tous les coups. Plus tard, en regardant les log openzwave, j’ai vu que les passages scene==12 et scene==11 ont pourtant bien lieu à chaque impulsion.

Tu perds vraiment les impulsions ? Est-ce que tu as des problèmes de scénario qui ne se lancent pas ?
(La dernière exécution du scénario ne s'est pas lancée)

Je vois. C’est frustrant ! Quelle est ta charge CPU ?
Perso, je trouve qu’il faille beaucoup de ressources CPU pour l’exécution d’un basique scénario comme celui-ci.

Je me suis posé aussi la même question. En cas de lenteur dans l’exécution, permettre un nouveau lancement peut aider, au moins, il n’est pas mis à la poubelle lorsqu’il n’a pas eu le temps de finir la précédente exécution.

Bonjour,

Ok donc si je comprend bien la log temps réel n’affiche pas forcement chaque chaque impulsion ni chaque exécution de scénario.
Peut être pour ça que dans mon cas en Screenshots précédant il me manquai une exécution de scénario.

Je ne pense pas avoir un problème de ressources CPU c’est une installation toute fraiche de jeedom ( sans sauvegarde)
image

Merci je viens de copier ton scénario :smiley:

je vais monitorer pendant 1 semaine pour voir si j’ai un delta qui apparaît entre le réel et jeedom.

Merci pour ton aide

Petit retour sur la durée de vie des piles.

La pile du module (Aeotec Door Sensor 7 ZWA008) pour le compteur d’eau a tenu 5 mois (avec 1 réveil par jour) pour un peu plus de 22 m3, soit un peu plus de 22000 impulsions. Le problème est que le niveau de la pille passe de 100% à 0% ! Donc c’est reparti pour un 2ème tour avec une pile neuve. Peut-être que l’autonomie sera supérieure car la première pile était celle fournie avec le module ?

1 « J'aime »

Pour ma part assez déçu de l’autonomie : compteur d’eau avec une moyenne de 500 impulsions par jour (500 litres), la pile d’origine a tenu 2 mois seulement ce qui représente dans les 30000 impulsions (et effectivement passage brutal de 100 à 0%).

C’est donc cohérent avec ce que tu obtiens @Domatizer sauf que dans mon cas ça ne dure que 2 mois !
Les réglages sont ceux par défaut, sauf l’activation du contact externe (et donc désactivation du contact interne)
Du coup comme mon compteur d’eau est en intérieur, j’ai branché une alim externe (3.3 V connecté entre les bornes 1 et 4) : ça fonctionne nickel

J’hésite a en acheter un second pour le gaz car le compteur est en extérieur sans possibilité de tirer une alim externe (sans compter que mettre une alim électrique à côté d’un compteur de gaz …). En hiver je consomme dans les 5 m3 de gaz par jour soit 500 impulsions par jour là aussi … donc 2 mois d’autonomie … pas génial …

A voir effectivement si avec une pile vraiment neuve c’est mieux

30000 impulsions, c’est pas mal ! Maintenant, il faut économiser plus d’eau :smiley:

Merci de la confirmation, il faudra se fier au nombre d’impulsions pour avoir une approximation de l’état de la pile.

J’avais pensé à 2 bonnes piles 1.5V AA LR06