Ce qui est faisable : tu sauvegardes Jeedom et tu transfères la sauvegarde sur PC
Tu refais ensuite une installation complète de Raspbian (https://downloads.raspberrypi.org/raspbian_full_latest)
Puis tu re-installes jeedom et tu restaures la sauvegarde
Ca occupe les jours de confinement …
PS : je te conseille de tester la manip complète décrite dans mon tuto sur un raspberry de test (qui ne sert à rien d’autre). C’est ce que j’ai fait, ne serait-ce que pour trouver comment arriver à un résultat qui marche ! Ce n’est qu’ensuite que j’ai installé le tout sur un raspberry contenant Jeedom. Good luck !
Patoche94,
la dernière date de l’information sur le site GRDF reste désespérément en date du 23/3 est ce normal a ton avis?
MAJ CORRECTION: ils ont mis a jour les 3 jour cet après midi.
Y a t’il un moyen de positionner correctement au niveau des dates ? le 23 est positionné le 25 et le 25 est positionné le 26, rien entre les deux et dates décalés
Hello,
J’imagine que tu as fait la petite modif que je préconisais dans le fichier client.py de pygazpar ?
Dans ce cas, le script pointe toujours sur la dernière ligne du fichier excel de grdf (c’est déjà mieux que dans le script d’origine qui scrutait une plage de lignes fixe)
Ensuite c’est au gré des mises à jour coté GRDF effectivement … et il semble arriver que, parfois, la mise à jour se fasse pour 2 jours d’un seul coup (3 j’ai jamais eu, mais je teste depuis à peine 1 mois)
Dans ce cas (1 jour sans mise à jour, puis 1 mise à jour « de rattrapage »), c’est vrai, le script fait qu’il y a un « trou » dans l’historique des relevés dans jeedom
Pour le moment j’ai pas de solution mais ça mérite d’y réfléchir je suis d’accord …
J’avais cherché des solutions sans fil hors DIY, car pas le temps de bricoler et je voulais que ça marche. L’inconvénient majeur est que les modules RF vendus ne communiquent que de temps en temps au cours d’une journée, souvent 1 ou 2 fois par jour. Cela leurs permet de tenir 10 ans. Avec une remontée d’une fois par jour, autant aller chercher l’info sur son compte client comme le font certains ici. Pourtant Gazpar est aussi sur batterie et il communique à chaque impulsion sur son port exotique JAE (1 impulsion pour 10L de gaz) et doit durer 10 ans.
Je voulais récupérer les impulsions en temps réel, même si ça bouffe plus de piles. J’ai donc opté pour l’utilisation du capteur de porte Aeotec DoorWindow Sensor 7 (ZWA008). Il fonctionne avec la technologie Z-Wave. C’est le seul module sur pile que j’ai trouvé qui a une entrée contact sec externe. Il peut détecter les différent type d’appuis (simple, double, triple, …, et appui long et relâchement de l’appui). J’ai simplement 1 scenario qui incrémente une variable correspondante à l’index réel du compteur à chaque impulsion. L’impulsion étant trop longue avec Gazpar, elle n’est pas considérée comme un simple appuis mais comme un appuis long, donc j’utilise l’information du relâchement de l’appui en fin d’impulsion.
En utilisant ces scènes, la fonction principale du capteur d’ouverture avec l’aimant reste disponible pour surveiller en plus si quelqu’un ouvre le regard par exemple. Génial !
Voilà une solution à 70 € (40 € le capteur, 15€ le connecteur JAE et 5 € de boîtier plus gaine pour faire propre). Ce n’est pas du tout prévu pour cela, mais le résultat est là même si ce n’est pas parfait pour l’exactitude de l’index. De temps en temps, je vérifie si les index entre Gazpar et Jeedom sont identiques.
Et j’ai utilise le même système pour le compteur d’eau…
@golfvert Il te faut un connecteur JAE comme celui-ci Connecteur JAE pour sortie impulsion compteur Gazpar. Ce n’est pas donné pour ce que c’est et j’ai du rajouter plusieurs couches de gaines thermos-rétractable pour renforcer le câble au niveau du connecteur. Il est livré avec un bout de câble de 80 cm environ.Tu connectes tout simplement les 2 fils sur les bornes 3-4 du capteur d’ouverture. Il n’y a pas de sens, c’est un contact qui de ferme côté Gazpar lors de l’impulsion. Le module Aeotec possède 4 bornes mais les bornes 1-2 sont inutilisées. Voir les explications ici Door / Window 7 user guide : Aeotec Help Desk
Avec cette solution, il faut bien avoir en tête que si Jeedom ou le réseau Z-Wave est en cours redémarrage, il ne faut pas qu’il y ait de consommation de gaz (ou d’eau) sinon des impulsions seront perdues. L’index dans Jeedom ne correspond plus à celui du compteur physique et il faudra faire un réajustement manuel.
Une meilleure solution serait d’avoir un module qui a un compteur d’impulsions embarqué et qui transmet l’index au lieu des impulsions. Ainsi, en cas de raté, l’index sera bon au prochain envoi…
Ils installent des millions de compteurs Gazpar mais je trouve qu’il n’existe pas vraiment de produits destinés au consommateur pour suivre sa consommation. L’intérêt est bien plus pour GRDF que pour le consommateur.
bonjour
meme probleme que scotty92fr
Traceback (most recent call last):
File « PyGazpar/gaz.py », line 17, in
client.update()
File « /home/pi/PyGazpar/pygazpar/client.py », line 56, in update
driver = webdriver.Firefox(executable_path=self.__firefox_webdriver_executab le, firefox_profile=profile, options=options, service_log_path=self.__tmp_direct ory + ‹ /geckodriver.log ›)
File « /usr/local/lib/python3.7/site-packages/selenium/webdriver/firefox/webdri ver.py », line 174, in init
keep_alive=True)
File « /usr/local/lib/python3.7/site-packages/selenium/webdriver/remote/webdriv er.py », line 157, in init
self.start_session(capabilities, browser_profile)
File « /usr/local/lib/python3.7/site-packages/selenium/webdriver/remote/webdriv er.py », line 252, in start_session
response = self.execute(Command.NEW_SESSION, parameters)
File « /usr/local/lib/python3.7/site-packages/selenium/webdriver/remote/webdriv er.py », line 321, in execute
self.error_handler.check_response(response)
File « /usr/local/lib/python3.7/site-packages/selenium/webdriver/remote/errorha ndler.py », line 242, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: invalid argument: can’t kill an exited process
c’etait une version strech lite en python 3.5, j’ai upgrader vers python 3.7 mais toujours le meme message?
Si quelqu’un avais une idée pour m’aider
cordialement
J’ai résolu mon problème en passant tout d’abord par un RPI sous buster, puis j’ai refait mon Jeedom (install buster, jeedom puis restauration du backuo).
les 2 cas, aucun problème, le script fonctionnait sous cet environnement.
oui voilà je confirme, pour que ça fonctionne j’étais aussi reparti d’un version « propre » de Raspbian (version complète, pas la version lite sinon ça marche pas)
par contre la solution de @Domatizer me parait très bien : je cherchais depuis un moment un détecteur d’impulsions sans fil qui puisse faire l’affaire (car mon compteur est dans un coffret dans la rue, sans possibilité de tirer un fil entre ma maison et le coffret), et j’avais pas trouvé cette référence. J’essayerai à l’occasion car la solution avec pygazpar aura certainement une fin un jour (le jour où grdf ajoutera un captcha sur son site)
bonjour @Domatizer : concernant le capteur AEOTEC dont tu parles, je voyais que l’autonomie annoncée de la batterie est de 3 ans, sur une base de 5 détections par jour (donc 5 « réveil » du capteur par jour - j’ai lu ça sur le site domadoo.fr).
Si je fais un petit calcul simple : la sortie contact sec du compteur gazpar est, si j’ai bien vu, activée à chaque dm3 consommé. Ma consommation actuelle de gaz étant de l’ordre de 5 m3/jour, cela fait 5000 dm3, donc 5000 impulsions.
Or la durée de vie de la batterie correspond, comme indiqué ci-dessus à 3 ans * 365 jours * 5 impulsions/jour = 5500 impulsions environ
Conclusion : on risque avoir vidé les piles en quelques jours … en théorie bien sûr
Pourrais-tu faire un retour sur la durée de vie des piles, ne serait-ce que pour confirmer que mon inquiétude est trop théorique pour être exacte
ok merci je vais voir a refaire une install complete
par contre pourriez vous me dire quel resultat vous avez quand vous tapez
sudo python -V
sur mon rpi moi ca me donne python 2.7.13 et si je fais sudo python3 -V j’ai 3.7.2
c’est peut etre la difference avec une install ou on a python V3.7 en natif
merci
Attention, ne pas confondre détection et réveil. Par défaut, le capteur se réveil 1 fois par jour. Pour les détections, 5 fois par jour, c’est peu, donc ça peut tenir 3 ans. Dans notre cas, le nombre de détection, c’est de l’ordre de la centaine ou plusieurs centaines.
Gazpar fournie 1 impulsion pour 10dm3 soit 10L et non pas à chaque litre. Tu peux diviser par 10 ton calcul.
Dans mon cas, je consomme au max 2m3 par jour de Gaz pour le chauffage et l’eau chaude sanitaire. Lorsque le chauffage fonctionne en rythme de croisière j’ai 1 à 2 impulsion toutes les 10 à 20 min. En revanche, lorsqu’on tire de l’eau chaude, comme c’est de l’instantané, là ça monte au max à 1 impulsion en 10 seconde au démarrage de la fonction chauffe eau (à 1L/seconde, la roue tourne vite) car toute la puissance de la chaudière est utilisée. Puis on passe à 1 impulsion toutes les 35 secondes environ pour une douche (eau à 38°C). Soit 20 impulsions en 12 min, ce qui fait 200L ou encore 0.2m3 de gaz pour une douche ! Faut pas rester traîner sous l’eau…
Côté compteur d’eau, c’est 1 impulsion à chaque litre. Nous, on est en moyenne à 200 L/jour, donc 200 communications par jour. Le débit max de l’eau est à 6L/min donc ça fait 1 impulsion toutes les 10 s. Le seul souci que j’ai eu une fois, c’est le scénario dans Jeedom qui n’arrivait pas à suivre le rythme. Bon, j’avais tiré beaucoup d’eau pour laver ma terrasse.
Dans les 2 exemples gaz et eau, cela reste raisonnable en terme de communication pour ne pas saturer le réseau Z-Wave.
J’ai installé mes modules fin janvier 2020. Depuis, cela représente une consommation d’environ 100 m3 de gaz et 11 m3 d’eau, soit déjà 10 000 impulsions chacun en tout pour ces 2 modules en 2 mois. J’ai dépassé de 2 fois tes calculs. Le niveau des piles indique toujours 100% pour les 2, est-ce que ça va diminuer d’un coup, je n’en sais rien. Pour info, j’ai eu d’autres détecteurs Fibaro utilisés pour les portes et fenêtres qui entaient déjà entre 60 et 80% au moment de l’installation. À voir sur le long terme.
Après, on pourrait aussi utiliser une batterie plus grosse en externe…
Un tel niveau de précision permet de voir ce qu’on consomme pour les différentes activités dans une journée. C’est assez intéressant.
@lepeno82 : pareil que scotty pour les versions de python
@Domatizer : merci de la réponse détaillée - oui effectivement je m’étais planté, c’est 1 pulse/10 dm3 sur le gazpar. Après je ne sais effectivement pas ce qui est le plus consommateur d’énergie pour le capteur : son réveil ? l’émission d’une info vers le contrôleur z-wave ? On peut en effet imaginer que sur une succession d’impulsions espacées de quelques secondes ou dizaines de secondes, le capteur reste éveillé.
Mais tu me rassures déjà si après 3 mois ça tient encore
J’en commanderai un pour voir je pense (mais il faut déjà que je teste avec un autre appareil z-wave qu’il arrive bien à communiquer avec le contrôleur depuis le coffret du compteur : à une bonne vingtaine de mètres de la maison + les murs … ça peut être limitatif)
Lorsqu’il y a une succession d’impulsions, le capteur n’est pas réveillé, il envoie juste les impulsions. Le contrôleur peut lui parler seulement lorsqu’il se réveille 1 fois par jour.
Attention à la distance avec le Z-Wave, mon compteur est sur la rue 8 m à vol d’oiseau du contrôleur, n’est pas vu en direct avec le contrôleur.
…
merci