[Solved] Help with simple chicken door automation (H bridge, normal motor)

Hi everyone,

I’m new to EspHome, and my first project shows a weird behaviour. I hope someone could help me, because I have no idea about where is the problem.

I have an ESP32-CAM controlling a motor through a H-Bridge (DRV 8871). It also has two limit switches on each top. I’m using an ESP32 CAM because I would like to add a camera in the future.

On ESPHome, I set up two binay sensors, one for each limit switch. I also set up two switches, one for each conection of the H-Bridge. This configuration is really simple, so I can’t realise where is the problem.

Normal behaviour:
When the door is at the lower endstop (door closed) position, I can open the door without any problems until the upper endstop.
When it is at the upper enstop (door open) position, I can close the door without any problems until the lower endstop.
Problem:
When the door is at the middle of the stroke, when I turn on any of the switches, the door goes on the direction I selected, but after a few seconds, it stops, reverses direction and after that, the ESP reboots itself.

I read the YAML time after time, and I couldn’t find anything out of normal.

Here is the YAML:

esphome:
  name: galineiro
  friendly_name: Galiñeiro

esp32:
  board: esp32cam
  framework: 
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "???????"

ota:
  password: "??????"

wifi:
  networks:
  - ssid: !secret wifi_ssid2
    password: !secret wifi_password2
  - ssid: !secret wifi_ssid3
    password: !secret wifi_password3
  
  manual_ip:
    static_ip: 192.168.1.11
    gateway: 192.168.1.1
    subnet: 255.255.255.0
    dns1: 192.168.1.1
    dns2: 8.8.4.4

  ap:
    ssid: "Galineiro Fallback Hotspot"
    password: "??????"

captive_portal:

web_server:
  port: 80
 
text_sensor:
  - platform: wifi_info
    ip_address:
      name: Direccion IP
    ssid:
      name: Nome da rede
    mac_address:
      name: MAC
    scan_results:
      name: Redes Dispoñibles

#Controladores, cara o drv do motor. Pines 13 e 33
switch:
- platform: gpio
  pin: GPIO13 #12 #GPIO2
  name: "Abrir galiñeiro"
  id: abrir_gali
- platform: gpio
  pin: GPIO33 #15
  name: "Cerrar galiñeiro"
  id: cerrar_gali

# Sensores, desde o final de carrera NO. Cando a porta chega ao final de carrera, accionase, e desde o com chega unha señal que fai que pare. Ao mesmo tempo, o final de carrera desconecta o abrir.
binary_sensor:
- platform: gpio
  pin: GPIO14 #1 #4 2 no va, 13 no va, 16 no carga. Quitar o led 
  name: Galiñeiro Aberto
  id: gali_aberto
- platform: gpio
  pin: GPIO4
  name: Galiñeiro Cerrado
  id: gali_cerrado

Additional information

If someone wants to see the problem, here is a link:

I’m not a youtuber, I published the video there because I couldn’t attach the file (>10 MB)

Sorry if I do something against the rules, I opened a thread on Github but they told me to publish it here.

Thanks you for your time reading this!

And yes, this is another Smart Chicken Door project :sweat_smile:

Just a couple of suggestions. Endstop cover would probably be a better way to call open or close. Turn up the logger to see if it gives you any insight to what’s happening.

Finally if you are not using the esp manufactures schematic, try to find it. Just to be sure there isn’t anything else going on, on the pins you’re using.

Hi @Mikefila

Thank you for your help (And sorry about the typos). I didn’t know about the endstop cover, I will check it out this weekend.

Are serial logs different from wifi logs? If they are the same, I didn´t see any weird on the (debug level) wifi logs.

And one final question: If they are different and I have enabled the I2C interface, can I retrieve serial logs? Or should I disable I2C to get them?

About the schematics, I have them. I had to access GPIO33 in order to avoid any straping pins :sweat_smile:

Here are the wifi logs:

Logs only show the first activation of the switch:
INFO ESPHome 2024.3.2
INFO Reading configuration /config/galineiro.yaml...
INFO Starting log output from 192.168.1.11 using esphome API
INFO Successfully connected to galineiro @ 192.168.1.11 in 0.027s
INFO Successful handshake with galineiro @ 192.168.1.11 in 0.088s
[14:20:20][I][app:102]: ESPHome version 2024.3.2 compiled on May 22 2024, 13:57:55
[14:20:20][C][wifi:580]: WiFi:
[14:20:21][C][wifi:408]: Local MAC: A0:B7:65:60:03:00
[14:20:21][C][wifi:413]: SSID: [redacted]
[14:20:21][C][wifi:416]: IP Address: 192.168.1.11
[14:20:21][C][wifi:420]: BSSID: [redacted]
[14:20:21][C][wifi:421]: Hostname: 'galineiro'
[14:20:21][C][wifi:423]: Signal strength: -27 dB ▂▄▆█
[14:20:21][C][wifi:427]: Channel: 11
[14:20:21][C][wifi:428]: Subnet: 255.255.255.0
[14:20:21][C][wifi:429]: Gateway: 192.168.1.1
[14:20:21][C][wifi:430]: DNS1: 192.168.1.1
[14:20:21][C][wifi:431]: DNS2: 8.8.4.4
[14:20:21][C][logger:166]: Logger:
[14:20:21][C][logger:167]: Level: DEBUG
[14:20:21][C][logger:169]: Log Baud Rate: 115200
[14:20:21][C][logger:170]: Hardware UART: UART0
[14:20:21][C][switch.gpio:068]: GPIO Switch 'Abrir galiñeiro'
[14:20:21][C][switch.gpio:091]: Restore Mode: always OFF
[14:20:21][C][switch.gpio:031]: Pin: GPIO13
[14:20:21][C][switch.gpio:068]: GPIO Switch 'Cerrar galiñeiro'
[14:20:21][C][switch.gpio:091]: Restore Mode: always OFF
[14:20:21][C][switch.gpio:031]: Pin: GPIO33
[14:20:21][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'Galiñeiro Aberto'
[14:20:21][C][gpio.binary_sensor:016]: Pin: GPIO14
[14:20:21][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'Galiñeiro Cerrado'
[14:20:21][C][gpio.binary_sensor:016]: Pin: GPIO4
[14:20:21][C][wifi_info:013]: WifiInfo Mac Address 'MAC'
[14:20:21][C][captive_portal:088]: Captive Portal:
[14:20:21][C][web_server:169]: Web Server:
[14:20:21][C][web_server:170]: Address: 192.168.1.11:80
[14:20:21][C][mdns:115]: mDNS:
[14:20:21][C][mdns:116]: Hostname: galineiro
[14:20:21][C][ota:096]: Over-The-Air Updates:
[14:20:21][C][ota:097]: Address: 192.168.1.11:3232
[14:20:21][C][ota:100]: Using Password.
[14:20:21][C][ota:103]: OTA version: 2.
[14:20:21][C][api:139]: API Server:
[14:20:21][C][api:140]: Address: 192.168.1.11:6053
[14:20:21][C][api:142]: Using noise encryption: YES
[14:20:21][C][wifi_info:011]: WifiInfo SSID 'Nome da rede'
[14:20:21][C][wifi_info:010]: WifiInfo Scan Results 'Redes Dispoñibles'
[14:20:21][C][wifi_info:009]: WifiInfo IPAddress 'Direccion IP'
[14:20:26][D][switch:012]: 'Cerrar galiñeiro' Turning ON.
And then it reboots

Thank you so much!

I dont see your cover or automations that stop the door at either endstop, I dont see your H-bridge configuration or any up/down/stop controls for the motor.

Is there a reason you only provided half of the relevant configuration? Dont you think a motor malfunctioning is an a good reason for including any and all config that are involved in the motor or door operation?

Would you take the motor out of your car before taking it to a mechanic and telling them the motor isnt working correctly?

Hi @Fallingaway24, you are right. On this YAML I don’t have any automation options about turning on and off the swithc components. But there is a reason.

In order to isolate the problem, I deleted all non-related components (I2C, wifi sensors, gpio interlocks and on-press actions…). I wanted to see if the problem comes from the “complex” components (templates/automations/actions) or if it comes from the “simple” ones (Binary sensor and switch).

So the Yaml I included only had those components (binary sensor and switch, and the minimum for integration with home assistant). It is like a “debug-incomplete” configuration.

Furthermore, the stroke of the motor is limited by the limit switch itself. Here is the shematic:

If you want to see the full YAML, here it goes:

esphome:
  name: galineiro
  friendly_name: Galiñeiro
  on_boot:
    then:
      # read the RTC time once when the system boots
      ds1307.read_time:

i2c:
  sda: 1
  scl: 3
  scan: true
  id: bus_a

time:
- platform: homeassistant
  id: hora_homeassistant
  timezone: "Europe/Madrid"
  on_time_sync:
      then:
        # ... and update the RTC when the synchronization was successful
        ds1307.write_time:
- platform: ds1307
  timezone: "Europe/Madrid"
    # repeated synchronization is not necessary unless the external RTC
    # is much more accurate than the internal clock
  update_interval: never      

esp32:
  board: esp32cam
  framework: 
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "XXXX"

ota:
  password: "XXXX"

wifi:
  #fast_connect: True #So vale cunha soa network
  networks:
  - ssid: !secret wifi_ssid2
    password: !secret wifi_password2
  - ssid: !secret wifi_ssid3
    password: !secret wifi_password3
  
  manual_ip:
    static_ip: 192.168.1.11
    gateway: 192.168.1.1
    subnet: 255.255.255.0
    dns1: 192.168.1.1
    dns2: 8.8.4.4

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Galineiro Fallback Hotspot"
    password: "XXXX"

captive_portal:

web_server:
  port: 80
 
text_sensor:
  - platform: wifi_info
    ip_address:
      name: Direccion IP
    ssid:
      name: Nome da rede
    mac_address:
      name: MAC
    scan_results:
      name: Redes Dispoñibles

sensor:
  - platform: sun
    type: elevation
    name: Elevación solar
    id: ElSol
   
#Controladores, cara o drv do motor. Pines 13 e 33
switch:
- platform: gpio
  pin: GPIO13 #12 #GPIO2
  name: "Abrir galiñeiro"
  id: abrir_gali
  #interlock: cerrar_gali
  #on_turn_on: 
   # then:
    #  - switch.turn_off: cerrar_gali

- platform: gpio
  pin: GPIO33 #15
  name: "Cerrar galiñeiro"
  id: cerrar_gali
  #interlock: abrir_gali
  #on_turn_on: 
   # then:
    #  - switch.turn_off: abrir_gali

# Sensores, desde o final de carrera NO. Cando a porta chega ao final de carrera, accionase, e desde o com chega unha señal que fai que pare. Ao mesmo tempo, o final de carrera desconecta o abrir.
#O gpio 2 non vai coa wifi
binary_sensor:
- platform: gpio
  pin: GPIO14 #1 #4 2 no va, 13 no va, 16 no carga. Quitar o led 
  name: Galiñeiro Aberto
  id: gali_aberto
  #filters:
  #- delayed_on: 100ms
  #- delayed_off: 100ms
  on_press:
    then:
      - switch.turn_off: abrir_gali

- platform: gpio
  pin: GPIO4
  name: Galiñeiro Cerrado
  id: gali_cerrado
  #filters:
  #- delayed_on: 100ms
  #- delayed_off: 100ms
  on_press:
    then:
      - switch.turn_off: cerrar_gali

sun:
  latitude: XXXX
  longitude: XXXX
  id: sol
  on_sunrise:
    - elevation: 0.5°    
      then:
        # - switch.turn_off: cerrar_gali
        - switch.turn_on: abrir_gali
        - logger.log: "Gali abrindo automatico"
  on_sunset:
    - elevation: -6°    
      then:
        # - switch.turn_off: abrir_gali
        - switch.turn_on: cerrar_gali
        - logger.log: "Gali cerrando automatico"

Plantilla da entidade porta do galiñeiro
cover:
  - platform: template
    name: "Porta Galiñeiro"
    id: porta_gali
    lambda: |-
      if (id(gali_aberto).state) {
        return COVER_OPEN;
      } else  if (id(gali_cerrado).state) {
        return COVER_CLOSED;
      } else {
        return {};
      }

    open_action:
      - switch.turn_on: abrir_gali
      - switch.turn_off: abrir_gali
    close_action:
      - switch.turn_on: cerrar_gali
      - switch.turn_off: cerrar_gali 
    stop_action:
      - switch.turn_off: abrir_gali
      - switch.turn_off: cerrar_gali
    optimistic: False

Sorry if I bother you, I was trying to avoid adding unnecessary complexity to my problem. Thank you for your time!

I was a little bothered just because its so common for people to only post the parts of configuration that they think are relevant to their question. I definitely presumed wrongly about you and ill own that mistake.

You are doing exactly what you should do and thats what I would suggest as well. Go through a process of elimination and start ruling out possibilities. Good work on that one!

Just to be clear, its still having the same problem, even with minimal configuration?

It so, tell me about what motor your using and how you are powering it.

Alao, another quick process of elimination id try is switch the GPIO pins that control Up/Down. See if it still acts up and causes the esp32 to reboot.

You could also add debugging. This will give you a text sensor that will tell you the cause for the last reset/reboot. It may be a useful clue for figuring out the problem.

debug:
  update_interval: 5s

text_sensor:
  - platform: debug
    device:
      name: "Device Info"
    reset_reason:
      name: "Reset Reason"


logger:
  level: debug

Thank you for your debug suggestion @Fallingaway24!

To make all as clear as possible:

Things that I tried:

  • Load the “minimal” YAML (Only with binary sensor and switch) → Reset
  • Return to original YAML, add endstop cover (as sugested by @Mikefila, this is much more apropiated) and try again. → Reset
  • Add loger and debug in vey_verbose mode → Reset
    Reset Reason: Software Reset CPU

Things that I haven’t tried (yet)

  • Switch GPIO numbering → I will try as soon as I can

The motor is a normal DC motor. I got it on Amazon, and as far as I tried with an independent power supply, it works properly. Here is the link:
https://www.amazon.es/gp/product/B07CXMMGF7/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
(Can I post Amazon links? Or is it against the rules?)

I am powering the assembly through a 5V 3A qualcom charger. In order to accelerate the motor, I added a booster that gives me 12 V.

I power the DRV8871 with this voltage, and I control IN1 and IN2 with the 3.3V from the ESP. To be honest, it is not a standallone DRV8871, it is the Adafruit version (or probably a clone):

Power consumption should not be a problem, as current is always below 2 A (Measured with the power supply).

This weekend I will investigate if switching GPIO fixes this weird behaviuor.

Thanks again!

PS: Here are two pictures of the electronics and the charger, just in case:

Well, in my opinion I strongly suspect its your power supply that is the problem. According to the data sheet, the motor’s normal operating current is 2a with a 3.5a peak capability. Between the esp current, booster current for operating and then wasted current from using an inefficient booster and finally the current the motor allone needs, its all to much for that little power supply.

It explains the symptoms of your esp32 having a power brown out and rebooting and that explains the stopping snd starting of the motor.

Those booster pcb modules arent very good to begin with and using it to drive a motor or for any inductive load isnt really what they meant to be used for and I’d suggest getting rid of it.

The normal way to do something like this is use a 12v power supply since the motor is your largest power need. The 12v can also be used to power the motor driver and then use a buck converter/step down module to reduce 12v down to 5v and power your esp32 which is also your device with the lowest power requirements.

1 Like

Hi again @Fallingaway24, you were completely right. It was a power supply problem.
I swithched to a 12 V, 4 A power supply, replaced the booster with a buck and now it works like a charm.

Thank you so much for your help!

PS: Should I publish the code and the bill of materials in order to contribute?

Sweet! Ya, i had a feeling and esp brown outs/reboots are classic power supply symptoms.

If you want to publish yoir project, go for it! Im sure others will find it helpful.

Great!! I published ir here

1 Like