Esp32 lolin32 v1 weird behavior

Hello all,

I am using an ESP32 lolin32 v1 to automate some a small water pump that is placed in a large container filled with water. The pump is controlled with a relay and I also have a water level sensor like this one.

Basically this is a on/off type sensor. It worked fine until a few weeks ago when it stopped registering changes.
Here is my configuration file:

  name: flowers
  platform: ESP32
  board: lolin32

  ssid: !secret wifi-ssid
  password: !secret wifi-pass

  # Enable fallback hotspot (captive portal) in case wifi connection fails
    ssid: !secret flowers-ap-ssid
    password: !secret flowers-ap-pass


# Enable logging

# Enable Home Assistant API
  password: !secret flowers-api-pass
  password: !secret flowers-ota-pass

  - platform: gpio
      number: 19
      mode: INPUT_PULLUP
      inverted: false
    name: "Level Sensor"
      - delayed_on: 30s
    id: level

  - platform: gpio
    pin: 26
    name: "Pump Switch"
    inverted: true
    id: pump
  - platform: restart
    name: "Flowers restart"
    id: restart_switch_flowers

  - platform: homeassistant
      - seconds: 0
        minutes: 0
        hours: 4
        days_of_week: MON-SUN
           - switch.toggle: restart_switch_flowers

The only thing that is different from when it was working is the fact that the esphome addon started to behave strangely when I tried to add another esp32, stating that I wasn’t connected to the internet or something. Reading online I found that switching to the dev branch which was on version 1.15-dev would fix the problem. And it did (or it seems it did), only now I cannot read any values from this binary sensor. The water pump switch works fine. I also tried with another esp32 board (identical to the first one) and same result.

Anyone has any clue what is happening? Have they changed something that somehow failed to document? I found that the documentation is quite strange. For example:

Here is the documentation for the binary sensor on the esphome site. They say that the pin numbers should be addressed with D and a number. But in my file it I set pin: D23 it comes out with an error saying that there is no such pin…

What you have is ok.



ESPHome always uses the chip-internal GPIO numbers . These internal numbers are always integers like 16 and can be prefixed by GPIO . For example to use the pin with the internal GPIO number 16, you could type GPIO16 or just 16 .

Most boards however have aliases for certain pins. For example the NodeMCU ESP8266 uses pin names D0 through D8 as aliases for the internal GPIO pin numbers. Each board (defined in ESPHome section) has their own aliases and so not all of them are supported yet. For example, for the D0 (as printed on the PCB silkscreen) pin on the NodeMCU ESP8266 has the internal GPIO name GPIO16 , but also has an alias D0 . So using either one of these names in your configuration will lead to the same result.

From here: Configuration Types — ESPHome

Well then why is the level sensor not working? I have it here with me on my desk. ESP32 is connected to my pc and running. I look at the logs and nothing is happening when I play with the level sensor. Is like they are not communicating somehow. I checked the sensor and it does work correctly: when the lever is up the circuit is closed and when it is down it is open.

Edit: could it be a problem with esphome? Maybe the new firmware has some bugs? should I try Tasmota?

some small proggress:

If I put the pin in mode: INPUT then something is happening:

[08:26:15][D][binary_sensor:036]: 'Level Sensor': Sending state OFF
[08:26:15][D][binary_sensor:036]: 'Level Sensor': Sending state ON
[08:26:15][D][binary_sensor:036]: 'Level Sensor': Sending state OFF
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state ON
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state OFF
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state ON
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state OFF
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state ON
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state OFF
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state ON
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state OFF
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state ON
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state OFF
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state ON
[08:26:16][D][binary_sensor:036]: 'Level Sensor': Sending state OFF

Not what I want but at least I know there is some communication now. Why is the INPUT_PULLUP mode not working anymore?

Lost the ground reference on the other side of the level switch?

No idead but check this out. After I tried with just INPUT and I got all those ON/OFF messages, I reverted to mode: INPUT_PULLUP and surprise! It works again as intended. WHY?!?

Is it possible that a pin gets “stuck” somehow? and I released it like that? so weird

Ah, the ol’ fixed AIBM* method. I put that on a lot of fault resolution cards.

*as if by magic.

well not quite… on the board I had it initially connected, the same method doesn’t work… so weird

I just today had a pin stuck high in output mode. ESP32 as well, no idea why. Maybe damaged? I swapped to another pin and works fine.

Pumps, water, electronics - perhaps the board has been damaged?

unlikely. the board never gets wet. i put it in a water sealed box away from the pump and water tank.

OK so I have figured it out. On the initial board where the problem appeared, it seems that PIN 23 is somehow stuck (I can’t get the state to change from ON to OFF). If I change to PIN19 (the one next to it) all is well. It may be a problem with the pull up resistor on that pin.

On the other board all is working but with that AIBM method @tom_l mentioned…

How are you powering the pump? The problem might be that you are powering the pump from the microcontroller instead of an external source.

I power the pump from a different 12V power supply than the module. The level sensor tells HA if there is water in the tank. If there is, i.e. it is ON then the module activates a relay through a defined switch module.

So I don’t think there is some sort of feedback back to the module to destroy that pin. One thing is certain. That pin doesn’t work now!