Here’s the code required for a quadrature (2-sensor) incremental optical encoder:
https://github.com/DavidAntliff/esp32-rotary-encoder-example
https://github.com/DavidAntliff/esp32-rotary-encoder
Surely a rotary encoder is easier, all that is done for you.
That is CERTAINLY a great combo sensor device, but just a wee bit pricey at 24,92€ if you buy three or more of them. And who really needs three or more?
I looked around for coiled/retractable USB power cords, but most are far too short to be useful.
Well I have 3 garage doors. But yes too expensive.
I saw a 3m retractable usb on aliexpress.
I think that these cables have some sort of “stop” function, so you’d have to remove that (if possible, since case is surely glued) or they will stuck when extended.
How about measuring time of travel? I’ve seen quite some electronics in my career with measuring time of travel and they were dong just fine. These devices many times had “bump to the end” as end stops, so they even didn’t have mechanical switches. Currently i have garage door opener which has “bump to the end” as stop switches (no mechanical ones). I didn’t explore too deeply if it has encoder, but after quick look i didn’t see one, so it’s possibly time measuring. Works perfectly.
So, end stops and time measuring. After all, you don’t need up to a millimeter precision… (or do you?)
On the inside of the dust cap, there is a cylindrical step that fits into the hub of the spindle which gave me a perfect guide to drill a 1/4" hole through the cap for the encoder. After some fit checks and measuring, I’ve ordered some 3/8" rubber bushings that will go down into the spindle. From there, I will have to cut a 1/4" hole in the center for the rotary encoder to fit in. Finally, the stem on the encoder is too long, so I’ll need to hit up a local hardware store to grab a 1/2" spacer.
I’ll grab some pictures in a bit…didn’t think to do it while I was poking around.
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.
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.
Small update:
After punching a hole through the spindle dust cap and putting the encoder through, I discovered that
- The walls of the spindle were protected by part of the dust cap
- 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.
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'
1 Like
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?
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!
1 Like
Me too! 
For the encoder, an integer might be more appropriate.
1 Like
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…
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.
1 Like
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…
2 Likes
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.
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.