Most homes already have a reliable mechanical lock, so replacing the whole door mechanism would add cost and installation work. The better product was a retrofit: keep the existing lock and physical key, then add a motor and electronics that can turn the same mechanism. The difficult part was not simply making the motor move. It was making the lock respond quickly, run for a long time on batteries, recognize authorized users, handle a jam safely, and still work when the internet is unavailable.
03 / Connected hardware · Embedded firmware · Access control
Battery-Powered Retrofit Smart Lock
Product development for Shree Export
A battery-powered retrofit lock with phone, fingerprint, PIN, and card access that preserves the existing mechanical lock and physical-key backup.
Design battery use, access security, and motor feedback as one system. The processor sleeps when the lock is idle, wakes only for a real interaction, checks permission locally, drives the motor for the shortest safe time, and confirms movement before the app reports success.
A working retrofit mechanism, custom KiCad PCB designs, embedded firmware, secure phone control, fingerprint enrollment, motor calibration, battery monitoring, persistent settings, and web and mobile product flows.
Sensitive security and circuit details are kept private. Longer household trials are still needed to measure battery life and reliability across different doors.
01
User and problem
Who needed this product, and why.
The product is for households that want convenient keyless entry without losing the familiarity and emergency backup of a physical key. The owner can set up the lock from a phone, add or remove people, choose how they enter, review activity, and calibrate the motor for the actual door.
The prototype turns a real mortise lock in both directions, opens from a phone or fingerprint without needing the internet, and keeps the original key usable. I designed the electronics in KiCad, wrote the embedded firmware, and built the phone and web experiences. I also managed the physical development: sourcing specialist components, ordering PCB runs, testing motors and fingerprint sensors, improving the mortise with a local lock manufacturer, and using 3D-printed enclosures to check fit and assembly.
02
Important decisions
Decision 01
Treat battery life as a product feature
- Why it mattered
- A door lock spends almost all of its time waiting, but it must wake quickly and supply a short burst of high current when the motor turns. A processor, radio, or firmware stack that wastes power while idle can make an otherwise good lock frustrating to own.
- What I did
- Compare processors by sleep current, wake speed, Bluetooth efficiency, memory, security support, toolchain quality, radio approval, cost, and long-term supply. Structure the firmware around sleep, event-driven wake-up, short radio sessions, battery checks under load, and safe state saving before power becomes unreliable.
- What it required
- This required comparing many candidate processors, reading their power and radio specifications, testing sleep behavior on real boards, and accepting a higher component cost when it reduced battery changes and firmware risk.
- The result
- Battery management became an architecture decision that shaped the processor, power circuit, radio behavior, firmware, motor timing, low-battery warning, and recovery from a weak battery.
Decision 02
Make security fast enough for a real door
- Why it mattered
- Low-power processors have limited memory and mathematical performance. A cryptographic method that is elegant on a laptop can create an unacceptable pause on a small embedded device, while a plain reusable unlock message can be recorded and replayed.
- What I did
- Use a standard challenge-and-response design suited to the processor. For every request, the lock creates a fresh one-time challenge. The phone proves that it has the correct secret without sending that secret, and a recorded response cannot be reused. Each person has an independent credential, so one person can be removed without resetting everyone.
- What it required
- The credential must be protected on both the lock and the phone. Owner-only administration, individual revocation, safe reset behavior, and checks that take the same amount of time for correct and incorrect responses all become part of the product rather than hidden implementation details.
- The result
- The lock can verify access locally and respond immediately without depending on the cloud. Fingerprint, PIN, and card inputs identify the person, but the protected lock electronics still make the final access decision before the motor can move.
Decision 03
Measure the lock instead of trusting the command
- Why it mattered
- A motor command only says what the software wanted to happen. A stiff door, weak battery, poor alignment, or obstruction can stop the bolt before it reaches the end.
- What I did
- Measure motor current while it turns. The firmware learns the normal movement of each installed door, stops when the mechanism reaches its end, and distinguishes normal completion from a jam, timeout, or unexpected load.
- What it required
- This adds current sensing, calibration, noise filtering, safety limits, and recovery logic, but it prevents the product from treating a sent command as proof that the door is locked.
- The result
- The working hardware turns the real mortise in both directions, calibrates to the door, stops safely, and reports the strongest state the mechanism can actually support.
Decision 04
Turn the prototype into custom electronics
- Why it mattered
- Development boards proved the concept but were too large and left important product questions unresolved: battery regulation, motor noise, radio placement near metal, connectors, sensing, service access, and manufacturability.
- What I did
- Design the product electronics in KiCad, from schematics and component selection through custom symbols and footprints, PCB placement, copper routing, grounding, antenna clearance, design-rule checks, 3D review, BOM work, and fabrication planning.
- What it required
- Custom electronics require datasheet work, repeated layout decisions, careful power and signal separation, soldering and board bring-up skills, and more disciplined testing than a development-board prototype.
- The result
- The project produced compact control-board and entry-interface designs that combine wireless communication, power management, motor control, sensing, timekeeping, keypad, contactless card, fingerprint, lighting, and audio functions.
Decision 05
Build the supply and fabrication network around the product
- Why it mattered
- A working smart lock cannot be completed in software or by ordering one ready-made module. The electronics, motor, mortise, enclosure, sensing, and physical fit all affect one another.
- What I did
- Source specialist components and processor samples, import electronic parts from LCSC, and work closely with the JLCPCB fabrication team to turn KiCad files into manufactured PCB iterations and feed production constraints into later revisions. Procure a geared motor suited to door-lock movement, evaluate several fingerprint sensors, and collaborate with a local lock manufacturer to refine the mortise and mechanical fit. Use 3D-printed enclosures and brackets to test each physical iteration quickly.
- What it required
- Coordinating suppliers and specialists adds lead times, minimum quantities, shipping, customs, communication, and revision management. It also exposes problems that are invisible in a CAD model or datasheet.
- The result
- Electronics, firmware, motor behavior, mortise geometry, calibration, and enclosure fit were developed together as one product instead of as disconnected parts.
03
What I built
What the product includes and how it works.
- A retrofit motor mechanism that turns an existing mortise lock while preserving physical-key operation
- Low-power Bluetooth firmware for setup, lock and unlock, user management, calibration, and device settings
- Fresh challenge-based authentication with separate revocable credentials for the owner and other users
- Motor-current sensing, per-door calibration, jam protection, timeout handling, and battery monitoring
- Fingerprint, touch-keypad, and contactless-card entry integrated into the product design
- Custom KiCad schematics, PCB layouts, component footprints, 3D board reviews, BOMs, and fabrication files
- Components, processor samples, and several PCB runs sourced and tested, with fabrication feedback carried into later KiCad revisions
- A geared motor calibrated on the real mortise, several fingerprint sensors compared, and the mechanism refined with a local lock manufacturer
- 3D-printed enclosures, motor mounts, couplers, and brackets used to test fit and assembly quickly
- Web and mobile experiences for claiming a lock, local control, people, invitations, activity, settings, diagnostics, and offline use
- Ownership, user, calibration, and configuration data preserved through power loss and firmware updates
How it works. The processor stays in a very low-power sleep state until a keypad press, fingerprint, or nearby phone wakes it. It checks permission locally, drives the motor while measuring current to detect the end of travel or a jam, stores the observed lock state in memory that survives power loss, and only then reports the result. Ownership, user access, and calibration settings remain available after battery changes and firmware updates.
Visual
Product evidence
What the product looks like in practice.
04
What exists today
A working prototype connects the lock, motor, custom electronics, firmware, and user apps
The complete system was assembled and tested as one product.The lock monitors its battery and saves important settings through power loss
The firmware also handles weak-power recovery safely.Phone access, user management, and fingerprint enrollment work on the prototype
Access is checked locally, so normal entry does not depend on the internet.The motor turns a real mortise lock and detects when it reaches the end or becomes jammed
Each installation can be calibrated for the movement of its door.The product went through PCB fabrication, motor and fingerprint trials, mortise refinement, and 3D-printed enclosure iterations
Suppliers, fabricators, and a local lock manufacturer contributed to the physical development.Security keys, circuit values, and detailed component choices are kept private
The case explains the security model and hardware behavior without publishing secrets or copyable design details.05
Reflection
What I learned, and what I would test next.
- For battery-powered hardware, processor selection and firmware design can determine whether the product is pleasant or annoying to own.
- The right embedded processor is chosen from the whole product constraint set: power, wake time, radio, cryptography, memory, SDK quality, certification, supply, and cost.
- Security must fit the available hardware without making the user wait, and a cloud connection should not be required for normal local entry.
- A physical product should report what it observed, not what software asked it to do.
- KiCad work is not only drawing a PCB. It connects electronics architecture, mechanical fit, radio behavior, power integrity, manufacturability, sourcing, and testing.
- Hardware collaboration works best when suppliers, fabricators, firmware, and mechanical partners iterate around the same physical tests rather than handing work off in isolation.
Let’s discuss the product problem.