Bug or wrong program?

Hello everybody, I am writing a program to manage my watering with ESPHOME, it is the first time : I have a Rainbird system, and all the sprinkers were transferred in HA, when a sprinkler is on, I put the water pump ON, I register the starting hour, the flow of water and the stopping hour, for each register, I write on a data base and for several weeks , everything was perfect. Then I just want to add a new signal which is coming from another Valve and then, all the data Registered were wrong , I tested my cabling with a scope, all the signals were perfect
 I came back to the old program, and everybody became again correct !! I look for problems during hours without succes, If somebody have a good idea, I thank him or her in advance. I use a ESPhome ESP32 wroom 32U and a home assistant green with the last version of software:
I just add:


  - platform: gpio
    name: "Remplissage citerne"
    id: remplissage_citerne

    pin:
      number: GPIO26
      mode:
        input: true
        pullup: false

the wrong program is:

###############################################################################
#
# PROJET     : AIS - Arrosage Intelligent Supervision
#
# Fichier    : esphome-debit-arrosage.yaml
#
# Version    : V1.0.0
#
# Date       : 11/08/2026
#
# Description
# -----------
# ESP32 dédié à la supervision hydraulique de l'arrosage.
#
# Fonctions :
#
# - Mesure du débit d'arrosage par débitmÚtre à effet Hall
# - Calcul du débit instantané (L/min)
# - Calcul du volume distribué pendant un cycle
# - Remise à zéro du volume par service Home Assistant
# - Détection de la vanne de remplissage de la citerne (GPIO26)
#
###############################################################################

esphome:
  name: "esphome-debit-arrosage"
  friendly_name: esphome-debit-arrosage
  comment: "AIS V1.0.0 - DébitmÚtre + Remplissage citerne"
  min_version: 2026.4.0
  name_add_mac_suffix: false

esp32:
  variant: esp32
  framework:
    type: esp-idf

logger:

api:
  actions:

    # Remise à zéro du volume du cycle

    - action: raz_volume_cycle
      then:
        - pulse_counter.set_total_pulses:
            id: debit_impulsions
            value: 0

ota:
  - platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

sensor:

  ###########################################################################
  # Niveau WiFi
  ###########################################################################

  - platform: wifi_signal
    name: "ESP Débit Arrosage RSSI"
    update_interval: 60s

  ###########################################################################
  # Temps de fonctionnement
  ###########################################################################

  - platform: uptime
    name: "Allumé depuis (s)"
    id: uptime_sec

  ###########################################################################
  # DébitmÚtre
  ###########################################################################

  - platform: pulse_counter

    pin:
      number: GPIO27
      mode:
        input: true
        pullup: false

    count_mode:
      rising_edge: DISABLE
      falling_edge: INCREMENT

    name: "Débit impulsions"
    id: debit_impulsions

    unit_of_measurement: "imp/min"
    accuracy_decimals: 0
    update_interval: 1s

    total:
      id: volume_cycle
      name: "Volume cycle"
      unit_of_measurement: "L"
      device_class: water
      state_class: total
      accuracy_decimals: 2

    filters:
      - lambda: |-
          return x / 65.0;

  ###########################################################################
  # Débit instantané
  ###########################################################################

  - platform: template
    name: "Débit instantané"
    id: debit_l_min

    unit_of_measurement: "L/min"
    device_class: volume_flow_rate
    state_class: measurement
    accuracy_decimals: 2

    lambda: |-
      return id(debit_impulsions).state / 65.0;

    update_interval: 1s

###########################################################################
# Détection de la vanne de remplissage de la citerne
###########################################################################

binary_sensor:

  - platform: gpio
    name: "Remplissage citerne"
    id: remplissage_citerne

    pin:
      number: GPIO26
      mode:
        input: true
        pullup: false

###########################################################################
# Commandes
###########################################################################

switch:

  - platform: restart
    name: "Redémarrage"

I don’t understand from your description what kind of problem you actually have, you should have a look at your esphome logs to see what’s going on.

What is this gpio sensor? Does it have external pullup/pulldown? Some software filtering would likely make it more robust.

The problem is that my data-base was corrupted with strange and wrong data. The GPIO is a signal which is coming from a valve: I got the signal 24 volts AC, I transformer it in DC, after I have an opto-coupler with transform the signal to 0 or 3.3 volts DC, I checked the signal with a scope, and it is clean, the change between 0 —> 1 or reverse is transmitted to Home-assistant without problem.


Here is a view of the signal change, the voltage is only 3.12 volts

The interface opto-coupler is similar to the attachéd picture, do you need that is it nécessaire to add an option es pullup or pulldown?

I think it has sufficient pullup via 510R+LED.
But your signal is inverted, I don’t know if you considered it on your code.

It is unlikely that your esphome device corrupted your database. Which database is it? What exactly is corrupted? Is it the whole database or just some values of some sensors?

My database is SQLite, the wrong data were erased, Maybe that the word « corrupted » was wrong, During the problem (watering) the data were wrong

Still not really making sense. Are you saying some data was erased?

What data? For which sensors? Over what time period?

This makes a little more sense. But, how was the data wrong?

There are way too many variables here to solve the problem.

If I was trying to solve this type of problem on my system, I would start at the beginning. In this case that is the esphome device. I would be logging the logging so I could see what the esphome device thought was happening. That would either agree with what I thought should be happening or not. If not, I would focus on the esphome device, since clearly it was not doing the right thing.

That is what @Karosm suggested way back at the beginning. Only when you are sure the device is behaving correctly does it make sense to look at the wrong data being in the database.

N° Durée (s) Volume (L) Débit (L/min)
73 135 0 0
74 6 0 0
75 85 0 0
76 22 0 0
77 98 877 536
78 34 300 529
79 55 486 530

Here are the wrong data Line 77 —> 79, the data are out of range

Great, finally something that makes sense. The data stored in the database is not what you expect. (I don’t believe it is actually corrupted.)

I suspect your device is not working the way you expect it. So now you need to capture the esphome logs from the device when the data going to the database is incorrect. This will show if the error is in the device or after it leaves there on its way to the database.

My wild guess is that you have very fragile hardware setup, long wiring prone to interferences, bad connections or missing pullups on your pulse counter line.
Feel free to post how your HW is done.

Hello, thank you for your help, I already have some pullup resistor on the pulse input, but tomorrow, I shall add some filters to improve the cabling.

Hello, I solved my problem, I improve the cabling, I add some biggest capacitor to improve the 24 volt DC , and I changed the GPIO 26–> 33, now everything is fine. Thank you for the support.