State Aware Garage Door

Not sure if this goes here or hardware…move as necessary.

I’ve currently got a Shelly 1 relay hooked up to make my garage door “smart” with a reed switch to give it open/close status. However, I don’t like that once I tell it to open in Home Assistant, I have no idea what’s going on until the door is all the way open and the reed switch closes and then it just says closed as soon as it starts closing.

So I had an idea, though I’m not sure if it will work. I have a spare ESP 32, SW-420, and a couple reed switches, I was thinking I could grab a 24v relay to include and then hook it all up to the garage door opener. I would have each reed switch setup give open/close confirmation states and then the sw-420 vibration sensor would provide opening/closing/error state.

The logic would go something like;

Door Closed
If Reed 1 closed set door state to closed

Door Opening
If Reed 1 previous state closed, reed 2 state open and sw-420 state detected, set door state to opening

Door Open
If Reed 2 state closed set door state to open

Door Closing
If Reed 2 previous state closed, reed 1 state open and sw-420 state detected, set door to closing

Door Partially Open (or Error state)
If Reed 1 open, Reed 2 open, and sw-420 state clear, set door to partially open

Here’s a super sweet MSPaint mock up

Certainly feasible. I was thinking a tilt sensor. 90 deg - closed. 0 deg open. Angle increasing - closing, angle decreasing - opening.

Well shit…I didn’t realize a tilt sensor was a thing…why all these guides out here using reed switches…

Actually a tilt sensor is binary, ie it switches at a particular angle. To get a continuous reading like I was imagining, you probably need an accelerometer.

I was seeing continuous reading inclinometer modules out there when I went looking. I’ll stick with using an sw-420 for now, just because when I had a need to buy one, the smallest quantity I could get was five.

sorry bro

my thinking is KISS it

I would add a helper (number) door_position

if Door Closed (reed 1) then door_position = 0

if Door open (reed 1) then door_position = 100

if reed1 open and reed2 open then door_position = 50

and I write 3 automation to set the door_position each time

once that done we now know it state base on door_position then we make more automation base on the door_position one and forget the open/close bit just read the door_position one

There’s other solution: motor pretty sure runs on 24V, right? Connect two relays parallel to the motor, in a series with a diode, also add a small electrolyte capacitor parallel to relays(to prevent relay from buzzing). Of course you connect them in opposite directions - so when open first relay will hold, when closing second one will hold. Then just connect relay outputs to esp and you have open/close signals.
I did similar to my garage doors, i just used two optocouplers instead…

I have a similar 3 state setup I put together using info gleaned from the forum.

My roller door has an upper and lower limit switches that are pulled high and go low when the door opens or closes. I added a buffer to those existing switches and connect that signal to the ESP. So no extra switches needed.

It uses a text sensor to do the states and works fine, the only issue is that I haven’t worked out how to get the icons in HA to change with a change of state.

I tried adding a device class to the text sensor but that is not allowed.

#Garage door sensor #6
# add WiFi RSSI

  name: garage_door
  platform: ESP8266
  board: nodemcu
  esp8266_restore_from_flash: true

  ssid: ""
  password: ""

  # Enable fallback hotspot (captive portal) in case wifi connection fails
    ssid: "Garage Door Fallback Hotspot"
    password: "t"


# Enable logging

# Enable Home Assistant API


# Door open relay
  - platform: gpio
    pin: D7
    name: "Garage Door Relay"
    id: garage_door_relay
    restore_mode: ALWAYS_OFF
  - platform: template
    name: "Garage Door switch"
    id: "trigger"
    - switch.turn_on: garage_door_relay
    - delay: 200ms
    - switch.turn_off: garage_door_relay

# Ultrasonic presence detector and VCC monitor
  - platform: ultrasonic
    trigger_pin: D6
    echo_pin: D5
    name: "Garage Ultrasonic Sensor"
    id: car_presence
    update_interval: 20sec
    timeout: 3.0m
  - platform: adc
    pin: VCC
    name: "Garage Node VCC"
  - platform: wifi_signal
    name: "Garage node WiFi"
    update_interval: 60s

# Limit switches
  - platform: gpio
      number: D1
      mode: INPUT_PULLUP
    name: "Garage is open"
    id: up_limit_sw
      - invert:
      - delayed_on: 20ms
  - platform: gpio
      number: D2
      mode: INPUT_PULLUP
    name: "Garage is closed"
    id: down_limit_sw
      - invert:
      - delayed_on: 20ms
  - platform: template
    name: "Car presence"
    device_class: presence
    lambda: |-
      if (id(car_presence).state < 1.2) {
        return true;        
      } else {
        return false;
# Door status text, Open, Closed and Between
  - platform: template
    name: "Garage Door Status"
    lambda: |-
      if ((id(up_limit_sw).state) == (id(down_limit_sw).state)) {
        return {"between"};
      } else if ((!id(up_limit_sw).state) && (id(down_limit_sw).state)) {
        return {"Closed"};
      } else {
        return {"Open"};
    update_interval: 5s


Just a rough idea:
Regarding the open/close/opening/closing sensor, would it be possible to use some Hall effect rotation sensor on maybe the motor or one of the gears that drives your chain/belt?

Some calibration would be need, yes, but should be similar to how smart roller/blind learn where your curtain/blind is, or how your bike computer learn the cadence / speed from your bicycle.

… right?

The ESPHome documentation makes it seem as though the Hall sensor on the ESP32 isn’t all that great to use. However, my garage door opener is belt driven…I wonder if I could use a rotary encoder. That would eliminate the need for everything else really.

Sounds good. You got a picture or video of the setup?

Same kind of build here, but for the sake of simplicity (i.e. the KISS principle mentioned earlier) I offer this question:
Do you really need a vibration sensor to tell you the door is in motion?

Consider: If it’s operating properly, the distance in time (for which you already have a built-in sensor) between one switch going from closed-to-open and the other switch closing-from-open (or even the original switch closing again if the door reverses itself due to blockage) tells you all you need to know. Either the door succeeded in its travel, or it has failed to reach either end, and is therefore stuck in-between (because neither switch re-closed within the alloted travel-time).

In my case, the biggest challenge came from trying to consider all the use-cases that arose at initial startup if, for example, neither switch was closed. But that too is just another couple states to calculate in the time-constrained state machine. If it doesn’t close one of the switches soon, then it must be immobile and partway open.

1 Like

I think the idea was for an external hall sensor.

1 Like

If you’re handy with electronic/electromechanical things, the limit switches within the opener itself may be something you can tap into.
I was able to do so on a Craftsman opener that’s about 10 years old, after finding that the drive system also moved a ground contact back and forth between two logic-level contacts inside the opener. By isolating my ESP from exterior ground and using the opener’s logic ground instead, I was able to safely wire these two contacts to ESP GPIO pins (via high-Z resistors, just to be even safer) and this has worked for a few years without problem. Or, you could use optoisolators and let the opener’s logic drive them.

I have way too many sensors on my garage door - I had them all hooked them all together, but blew away my HA instance and never rebuilt the maths.

Essentially I have

  1. Door/Window sensor at base of door, is closed when door is fully closed.
  2. Limit switch sensor that is, is open when door is fully open.
  3. 2 x vibration sensor on a couple of panels. These both have orientation sensors included as well so I used them to determine how open the door was.
  4. An input boolean that was used to determine the previous state and using the other sensors determine whether the door was in the opening or closing phase, or if stopped whether a single press would open, close or stop the door.

Do we really need home assistant :smiley:

I don’t like operating on assumptions and like to know what’s going on. Is it overkill, yup.

I am not…I’m coming from an IT infrastructure/security background so I’m comfortable with technology, but those base electronics/devices are all new to me. I’ll learn them because it interests me, but I’m not there yet.

Of what the garage door looks like or using a rotary encoder? I haven’t implemented anything but a Shelly 1 on my first pass, so nothing to look at. Here’s the business side of the garage door opener. There’s actually a dust cap that is screwed down over the gear.

You got a 3D printer? Something with teeth the size of the belt teeth and with a spline for a rotary encoder could work well. It’ll tell you direction of travel, and by the number of turns the distance travelled.

1 Like

Wouldn’t three magnets on the wheel there and a hall sensor work just as good?
Or even better since there is nothing that can break?

If you put one strong magnet and two weaker ones (or vice versa) then you will get readings like strong, weak, weak.
Or weak, weak, strong.
That way you know what direction it’s spinning.

You could mount a rotary encoder on a bracket such that the shaft of the encoder mates to the top of the motor spindle.