State Aware Garage Door

[pocket (Rob)]

Ugh. I don’t know how to break this to you, but those encoders are made with moving mechanical contacts. They’re plenty good for changing a value, like setting the frequency of a radio. Driving them with a motor might not be good because of contact bounce (read the reviews) and the rate at which the shaft spins.

https://en.wikipedia.org/wiki/Incremental_encoder#Mechanical

Apologies for using US units. A good-quality Bourns part is rated for 30,000 rotations. Assuming a rotation equates to a foot of linear movement, and you used your opener twice a day, that would be less than 3 years of service. Moreover, there’s a 60 RPM maximum rating. There are other operating limitations on the spec sheet, like signal filtering. And if you have detents between positions, the feature could be problematic at higher rates.

https://cdn-shop.adafruit.com/datasheets/pec11.pdf

In contrast, optical sensors have no moving parts and don’t bounce unless there’s mechanically-induced relative motion between the interrupter and sensors.

[sparkydave (🇦🇺 Dave)]

I simple rotary encoder like this (you can get them everywhere) would be easy to mount above the motor such that it sits upside down and the shaft connects to the centre of the motor pulley. You could just use blue-tac or something to connect it so that if something goes wrong it can break free rather than get destroyed.

[Grunt]

@sparkydave

I simple rotary encoder like this (you can get them everywhere) would be easy to mount above the motor such that it sits upside down and the shaft connects to the centre of the motor pulley. You could just use blue-tac or something to connect it so that if something goes wrong it can break free rather than get destroyed.

That appears to be the exact same thing as what I have.

[Grunt]

Small update:

After punching a hole through the spindle dust cap and putting the encoder through, I discovered that

1. The walls of the spindle were protected by part of the dust cap
2. I needed a spacer to mount to the top of the dust cap for the encoder to sit on.

A few moments later…and issue #1 was resolved.

As for issue #2, after some measuring and a visit to the local hardware store, I had myself a 1/2" nylon spacer that I then threaded so that I could just screw the encoder into.

Next up is some sort of mounting solution to keep the PCB section of the encoder from spinning right along with the…stalk(?) of the encoder. I just happened to have a couple screws that fit the bill…sort of…

I had to create a slight counter-sink on the inside of the dust cap to keep the screw heads flush with the cap so it doesnt interfere with the spindle.

Ok…so I should probably cut those screws down just a bit…and I’m probably gonna order another dust cap and properly measure and drill out the holes so that everything is straight.

Regardless, I’ve come up with a workable integration of a rotary encoder with my garage door. In addition, I’ve completed the prototype configuration and validated that everything works properly on it.

  - platform: rotary_encoder
    name: "Garage Status"
    id: garage_status
    pin_a: GPIO18
    pin_b: GPIO19
    accuracy_decimals: 0

switch:
  - platform: gpio
    name: "Garage Door"
    id: garage_door
    pin: GPIO25
    on_turn_on:
    - delay: 100ms
    - switch.turn_off: garage_door

Cool…so the next issue I will have is converting however many rotations on the encoder from door being fully closed to fully open into a percentage. The current thought is that the front end will express the Garage Status as a percentage of open. Then I can setup a couple entities that will open the door 1/4 or halfway. Do HASS templates support some sort of math function?

As a side note, while screwing around doing all this, I noticed the steel belts inside the garage door belt were exposed in multiple places. Long story short, the belt is over 20 years old and was only warrantied for five…so I got a new one coming.

[pocket (Rob)]

@Grunt

Do HASS templates support some sort of math function?

Yes. Look for math functions on this page:

https://www.home-assistant.io/docs/configuration/templating/

Here’s a simple example for changing air pressure in millibars to inches of mercury.

dark_sky_alt_pressure: 
  value_template: >-
                   {{ (states('sensor.dark_sky_pressure') | float * 0.02953) | round(2) }}
  unit_of_measurement: 'inHg'

[Grunt]

@pocket

Here’s a simple example for changing air pressure in millibars to inches of mercury.

dark_sky_alt_pressure: 
  value_template: >-
                   {{ (states('sensor.dark_sky_pressure') | float * 0.02953) | round(2) }}
  unit_of_measurement: 'inHg'

Appears to be simple enough, just to double check I am understanding what’s going on…you’re grabbing the sensor state, converting it to a float, multiplying it by a tiny number and then rounding it to the 2nd decimal point?

[nickrout]

You got it, you have to convert to a float because all HA states are text, so convert to a float before performing maths.

PS I am keen to see how this works out!

[sparkydave (🇦🇺 Dave)]

@nickrout

I am keen to see how this works out!

Me too!

[pocket (Rob)]

@nickrout

You got it, you have to convert to a float because all HA states are text, so convert to a float before performing maths.

For the encoder, an integer might be more appropriate.

[Grunt]

First print of the case. I’m gonna have to move the cutout to be more in line with the ESP32, I was expecting a bit more flexibility from the power cable.

Unfortunately, I didn’t take the height of the standoffs into account and will also need to make it a bit taller…

[Grunt]

I went off on a tangent of doing many other things and have finally returned to getting this guy completed. I’ve taken some of the previously mentioned advice and prototyped a gear to connect the encoder to the belt.

At some point in the past, I reprinted the ESP32/Relay housing in a more durable material (PETG). The fit on the lid is a bit too snug, so that will need to be adjusted before finalizing.

I need to build a housing for the encoder and figure out how to mount it to the motor housing. I have some magnets laying around from a previous project that might work for this…

Look for more frequent updates on this in the coming days.

[Grunt]

So the magnet idea didn’t work out, too much vibration caused it to move around too much.

On to design 2!!..just gotta figure out a retention method for the gear as it wants to ride up off the encoder in one direction of travel…

[Protoncek (Pavel)]

Great work!
However, i’m really curious how long this encoder will work… i guess that they are not designed for so heavy work, so hoping for the best…
Better option would be optical encoder, but they are way more expensive, and bigger, too.

[Grunt]

Thanks, I think minimum order through amazon was 5 for like $10 bucks…so if they’re short lived, they’re cheap enough. If they’re too short lived, I’ll just have to go back to “dumb” smart garage door, lol.

[Hellis81]

EDIT: Nevermind, I see now this was posted earlier.

Another option is a mpu6050 on the door.
MPU6050 Accelerometer/Gyroscope Sensor — ESPHome

They are quite easy to work with, but they need a good connection or they won’t work at all.

It will report (or could report) the angle the door is in.

But this requires a power cable on the actual door.

[Grunt]

Came up with a simple two piece design to keep the gear on the encoder that works great. I think this part is design complete and I can print it off in its final material. The surface finish on the base wheel is a little jacked up because I tried a setting that caused the top surface to detach.

I may need to redesign the ESP32/relay housing due to space restrictions. I’ll probably be borrowing from this design I worked up on a separate project. It will require a little refactoring for the longer relay board, but shouldn’t be too bad.

[Grunt]

Final encoder housing all prettied up in PETG black and ready for showtime.

Redesigned ESP32/Relay housing prototyped out. The ESP32 section and lid mate up perfectly, had to refactor a couple things on the relay housing though. I was a little too tight on some cutouts and the board didn’t fit quite right. Should be dressed in black tomorrow.

The hole on the “front” of the housing is where the wires will come out and go to the garage door opener. The hole on the “side” is both access to the screws and where the wires from the encoder will come in…or at least that’s the idea that I have in my head at the moment.

[FredTheFrog (Keith)]

I’ll have to look for the post, but that’s exactly what I did a few months ago.

[pocket (Rob)]

@Grunt

On to design 2!!..just gotta figure out a retention method for the gear as it wants to ride up off the encoder in one direction of travel…

Something like this at the top of the shaft might work:

https://www.dubro.com/collections/collars/products/nickel-plated-dura-collars

[FredTheFrog (Keith)]

Or, file small grooves into the top of the shaft, and use an E-clip.