Hello
2 pistes :
Une autre :
Est ce le même E/R que le mien ? Sait il démarrer une émission avec une impulsion de 300 ms ? Avec ml. Émetteur ça ne posait pas de problème.
Tente de simuler à la main cette impulsion en remplaçant le gazpar par 2 fils que tu touches très vite. Ça fera jamais 300ms ! Mais ca te permettra déjà de voir si le récepteur réagit
Amitiés
Philippe
Hello
Un avis sur quoi ?
Philippe
Hello @Pbranly si tu regardes mon message précédent il faisait référence au message de St4n : « Sur le site d’achat du cable gazpar, il y a deux tableaux ATEX qui indiquent que la tension max admissible à l’état ouvert est de 5,5V sur l’entrée du gazpar.
Ne vaudrait-il pas mieux utiliser une grosse pile 4,5V au lieu de 9V? »
À ok
Bein peut être !
Avec 4,5 V la portée sera sûrement plus faible . Il faut tester
Philippe
Perso j’ai connecté le cable sur un capteur d’ouverture de porte RF433 qui a une pile AAA, et je récupère l’info via RFLink. Ca fait 5 mois et c’est plutôt fiable.
C’est une super solution quand on a déjà un RFLINK
de même que la solution zigbee sur base télécommande IKEA quand on a déjà du zigbee
Philippe
Merci de ta réponse.
En ce qui concerne le couple E/R, j’ai effectué un test avec un relay piloté par l’esp32 pour simuler la fermeture du circuit. Avec une configuration internal_filter à 100ms, je capte sans problème les impulsions d’une durée de 130ms (en dessous, il semble que je perde une impulsion sur 10 environ). En descendant l’option internal_filter à 50ms, tout réagit correctement avec des impulsions de 100ms. Or, les infos trouvées sur ce site montre que le circuit se ferme pendant au moins 225ms.
En ce qui concerne la polarité, mon circuit semble être correct (le test réalisé le montre). La seule possibilité d’erreur que je peux imaginer viendrait d’une polarité du compteur gazpar. Ma compréhension est qu’il agit exactement comme un relais (donc non polarisé), mais peut-être que je me trompe.
Je ne sais pas encore comment tester la TIC du gazpar indépendament. Un ohmètre pourrait peut-être capter le changement (encore que si ca dure 200ms je n’en suis pas sûr).
Une possibilité serait de supprimer le système E/R pour un test et brancher directement le cable gazpar sur l’ESP32 en supposant que ca pourrait montrer le circuit fonctionner. Sinon une simple diode branchée en série de la pile.
J’ai lu la même info que @St4n à propose de la bande acceptable de tension [2V-5.5V], j’espère que je n’ai pas abimé la TIC en branchant le circuit avec la pile 9V.
Avec un multimètre digital à mon avis tu ne verras rien
Avec un vieux à aiguille ce serait mieux
Sinon une pile une résistance 4,7 Kohms et une led
Tu verras les pulses de 300 ms
Phil
A quand la possibilité d’acheter une version clef en main zigbee ? 
Bonjour,
De mon côté j’ai du mal à arriver à une solution stable. Je préviens, je suis développeur, l’électronique c’est malheureusement pas là ou je brille. J’ai du 5V qui arrive à mon compteur, donc côté problème d’alim je suis tranquille. J’ai trouvé plusieurs montages sur internet, et je suis arrivé à quelques chose de plutôt simple, très inspiré du montage Gazpar-light :
Seulement voilà, globalement ça fonctionne très bien, j’ai bien les remontées, mais environ une fois par jour, j’ai des pulse en trop, je remonte par exemple, il y a 3 jours, 100kw vers 18h. J’ai l’impression que ça correspond à un plus gros tirage de gaz, genre pendant une douche, mais c’est pas systématique. Enfin, mon relevé grdf est lui « normal », pas ce genre d’aberration.
Le code esphome est sur mon repos git, mais je peux pas mettre de lien sur le forum apparement.
Des idées ?
100 kW ça fait 10 m3 donc 1000 pulses . C’est encorme. Tu as mis un filtrage de largeur de pulse sur ton code ?
Tu peux mettre ton code directement sur le forum ( filtre juste ce qui est privé comme l’accès wifi)
Merci de ta réponse @Pbranly (j’ai cru comprendre que nous sommes plus ou moins voisins).
J’ai bien mis un filtrage (par défaut j’ai mis 100ms comme dans la doc, j’ai essayé 400ms, ça n’a pas changé mon soucis) :
esphome:
name: gazpar
esp8266:
board: esp01_1m
# Enable logging
logger:
# Enable Home Assistant API
api:
password: !secret home_assistant_password
ota:
password: !secret ota_password
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
manual_ip:
static_ip: 10.0.3.1
gateway: 10.0.0.1
subnet: 255.255.0.0
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Gazpar Fallback Hotspot"
password: !secret ap_password
time:
- platform: homeassistant
id: homeassistant_time
timezone: Europe/Paris
# on_time:
# - seconds: 57
# minutes: 59
# hours: 23
# then:
# - pulse_meter.set_total_pulses:
# id: gazpar
# value: 0
captive_portal:
###############################################################################
# SENSORS
text_sensor:
############################ BASICS
- platform: template
name: Uptime
id: uptime_human
icon: mdi:clock-start
binary_sensor:
############################ BASICS
- platform: status
name: "Statut"
button:
############################ BASICS
- platform: restart
name: "Reboot"
sensor:
############################ BASICS
- platform: wifi_signal
name: "WiFi Signal"
update_interval: 60s
unit_of_measurement: dB
accuracy_decimals: 0
force_update: false
icon: mdi:wifi
- platform: uptime
id: uptime_seconds
name: "Uptime"
update_interval: 60s
unit_of_measurement: s
accuracy_decimals: 0
force_update: false
icon: mdi:timer
on_raw_value:
then:
- text_sensor.template.publish:
id: uptime_human
state: !lambda |-
int seconds = round(id(uptime_seconds).raw_state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
return (
(days ? to_string(days) + "d " : "") +
(hours ? to_string(hours) + "h " : "") +
(minutes ? to_string(minutes) + "m " : "") +
(to_string(seconds) + "s")
).c_str();
############################ GAZ
# Consommation gaz
- platform: pulse_meter
id: gazpar
pin:
number: GPIO2
unit_of_measurement: "l/mn"
icon: mdi:fire
internal_filter: 100ms
name: "Débit Gaz"
state_class: measurement
filters:
- multiply: 10
total:
unit_of_measurement: "m³"
name: 'Volume Gaz'
filters:
- multiply: 0.01
accuracy_decimals: 3
icon: mdi:fire
id: gazpar_gaz_m3
device_class: "gas"
- platform: template
name: "Puissance Gaz"
lambda: |-
return id(gazpar_gaz_m3).state * 10.01;
device_class: energy
unit_of_measurement: "kWh"
accuracy_decimals: 3
id: gazpar_puissance_gaz
state_class: total_increasing
Sur le forum jeedom, il y a un post avec un module gazpar/espeasy, il est écrit
Après quelques tests, l’option Opto a été retenu, sans lui des impulsions supplémentaires arrivent d’on ne sait où !
Voici le schéma, mais je commence à être largué (sorti des résistances, et encore, ça devient complexe pour moi) :
Quand je repense au créateur du lixee (que je recommande par ailleurs) que j’ai contacté pour savoir s’il avait l’intention de faire le même pour gazpar, il m’a répondu que non car « c’est tout simple il suffit de mettre un compteur d’impulsion », je me sens vraiment tout mauvais 
Il a mis en place un sondage sur Twitter il va peut être changer d’avis si il a assez d’avis positif… De mon côté j’ai été voter pour!
Moi pareil j’ai voté pour
Je ne saisis pas non plus pourquoi ça fonctionne mieux .
L’intérêt du schéma c’est que durant l’impulsion , la led s’allume et l’état du GPIO passe à zéro.
Mais si ça fonctionne ……! Il ne faut pas se poser de question
Je vais voter, mais je vais quand même essayer d’aller au bout de ce que j’ai entamé.
J’ai commandé un opto et la résistance de redressement, je vais tester. J’avais bien saisi que la led c’était juste pour du « debug », je vais voir si je la met ou pas.
Je vais tenté comme ça, et je tiendrai au courant après quelques jours/semaines de test. Si c’est concluant, je mettrai mon schéma final etc.
