Home
| pfodApps/pfodDevices
| WebStringTemplates
| Java/J2EE
| Unix
| Torches
| Superannuation
|
| About
Us
|
Auto Garage Door Lock
|
by Matthew Ford 22nd October 2022 (original 22nd
October 2022)
© Forward Computing and Control Pty. Ltd. NSW
Australia
All rights reserved.
This project was completed by George using a
servo controlled and monitored by pfodApp
to auto lock the door. George chose pfodApp
to control and monitor the
auto lock because he
“thought
the interfacing of the phone to the processor would be the most
challenging aspect (and I dreaded it!), but pfodDesigner
made producing the graphical menu on the phone simple, and also
produced all the working code necessary – all with no help from
me.”
Basically, the aim of this Project was to be able to remotely control locks (one at the top, and the other at the bottom) on a garage side door via my mobile phone and also via a push button on the inside beside the door. Obviously, it would need to be able to open & close the locks, but it was also required to monitor (and show) both the lock and door real-time status (locked/unlocked & open/shut etc.). It also needed to be able to open the locks when commanded, and keep them unlocked until the door was opened and shut again, then shut the locks automatically after a few seconds. However, since that’s not always desirable, this aspect needed to be disabled when not required. (See the video)
(Click the images for the full size versions)
The free pfodDesigner app was used to build the menu for the phone, with the code it produced being fed into the Arduino IDE, tinkered about with a bit, then uploaded into the control processor (an ESP8266 WeMos D1 Mini in this case). Once up and running, commands were sent from the phone via pfodApp to the processor which in turn activated two servos mounted on the door, which in turn opened or closed the bolts. Feedback was then sent back to pfodApp to update the various menu items.
I thought the interfacing of the phone to the processor would be the most challenging aspect (and I dreaded it!), but pfodDesigner made producing the graphical menu on the phone simple, and also produced all the working code necessary – all with no help from me. I’ve no idea how it manages, but it does to it perfectly! To be honest, I don’t understand a lot of that side of it, and it’s not really necessary to change any of it, but it turned out to be straightforward to tweak it a bit here and there to personalise the output more to my liking – even with my very limited C++ coding ability. Lots of kudus to pfod. The Project would never even have started without it.
The completed sketch is Garage_Door_Lock_pfod_v1.ino
For a list of the main parts see Components.pdf Here is the manual for servo used.
The IR sensor lets the processor know if the door is open or closed (so it won’t close the bolts when the door is open), and there’s a switch on the control unit that tells the processor whether or not to make ‘Auto-Close’ active – c/w a couple of LEDs to highlight the current status.
A push button beside the door gives a signal to the processor and provides local control without having to fumble for my mobile phone. The servo 0⁰ & 180⁰ positions are calibrated in the code, and the menu button command tells them to go to one or other of these positions. Other LEDs at the locks illuminate to show when the servos are powered up. They’re not strictly necessary, but they’re nice and easy to see from the other side of the garage when you can’t make out the bolt tabs moving & position.
System power is supplied via a Sonoff WiFi switch (so it can be totally isolated remotely, and not do anything ‘surprising’ while unattended!). A 5VDC brick supplies DC to the processor and peripherals.
During testing, it was noticed that the servos grumbled, complained and glitched in an unpredictable manner when not actually being fed a control signal. Maybe this was down to floating voltages or processor quirks, I’m not sure, but either way, the solution for me was to only power the servos when they were actually being used (via the relay board). This eliminated the need to supply them with constant signals (and wasting power for that matter), however, it also meant that when powered down, they also lost their ‘static holding torque’. That said, in this case, that wasn’t a problem – the mechanical layout is such that no force applied to the outside of the door in any direction could cause the servo to turn (look up pin-jointed structure & vector forces if you’re not sure why!).
Once closed, the two 9mm stainless bolts are buried 30mm into 10mm metal lined holes in the door stop surround thereby providing adequate security without overkill. Attempted forced entry would just result in the outside handle being pulled off (the door opens outwards) since the handle’s only held on by tiny screws (intentionally!). Heavy duty he-man attempts would eventually break the door itself, but even then, the door stops and bolts would survive.
AndroidTM is a trademark of Google Inc. For use of the Arduino name see http://arduino.cc/en/Main/FAQ
The General Purpose Android/Arduino Control App.
pfodDevice™ and pfodApp™ are trade marks of Forward Computing and Control Pty. Ltd.
Contact Forward Computing and Control by
©Copyright 1996-2020 Forward Computing and Control Pty. Ltd.
ACN 003 669 994