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 Access System
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. Before building, I ran a market study of about 250 pages of working research on Indian smart locks, and after building, I attacked my own lock with 13 penetration-test scripts.
02
Important decisions
Decision 01
Find the gap the market leaves open: security
- Why it mattered
- Fewer than 0.3% of Indian homes have an electronic lock, in a market of roughly Rs 400 to 1,000 crore growing 30 to 40% a year. About 75 to 90% of locks sold are Chinese hardware under an Indian label. Every lock examined under Rs 15,000 shipped access cards of a type broken since 2008 that can be copied in about a minute, and the common clutch mechanism appears to be openable from outside with a USB power bank.
- What I did
- Ten research passes covered market size, brands and pricing, Indian manufacturing, import duties, channels, features, security teardowns, customer complaints, and regulation. A separate review pass attacked every claim. The product then competes on a mechanism that is not energised on the outside of the door, and on secure DESFire cards instead of cloneable ones.
- What it required
- Secure cards and the safer mechanism add Rs 500 to 800 to each lock, about Rs 5 to 8 lakh at a thousand units. The review pass also softened claims from "is bypassable" to "appears to be bypassable" until competitor units are opened and tested.
- The result
- A clear market position backed by evidence: local assembly avoids the 22% non-recoverable duty on imported finished locks, and security becomes the reason to choose the product rather than a hidden cost.
Decision 02
Attack my own lock before anyone else does
- Why it mattered
- Strong cryptography on paper does not prove that a battery-powered radio device survives a hostile person standing outside the door.
- What I did
- Write 13 attack scripts covering reconnaissance, write fuzzing, replay, brute force, timing analysis, unauthenticated actions, connection flooding, man-in-the-middle relay, and passive sniffing, then run them against the real lock and write up every finding with a severity and a fix.
- What it required
- The test found 8 issues, including a critical one: a flood of radio writes could freeze the lock until its battery was pulled. Fixing them meant rate limiting, a watchdog, idle-connection timeouts, and protocol changes before any further feature work.
- The result
- The HMAC-SHA256 challenge-response held up: no command could be forged or replayed. The availability and radio-level weaknesses were found and documented by me first, with a prioritised fix list.
Decision 03
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 04
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 05
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 06
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 07
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 overseas distributors, and work closely with a PCB fabrication partner 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. A vetted shortlist of overseas motor-module manufacturers with a standard sample-request process, 16 fingerprint samples across six types, and a move to a cheaper radio processor cut the controller cost 3-4x.
03
What I built
What the product includes and how it works.
- A market study of about 250 pages of working research covering market size, brands, pricing, duties, channels, security weaknesses, customer complaints, and regulation, written up as a report for management
- A self-run penetration test: 13 attack scripts and a report of 8 findings, each with a severity and a fix
- A comparison of Indian and overseas PCB fabrication including the 30% anti-dumping duty on Chinese boards
- 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 market study combining ten research passes and an adversarial review
Market size and growth, import share, duty structure, price bands, and security weaknesses, with each claim given a confidence level.13 penetration-test scripts run against the real lock found 8 issues, and the authentication itself held
No forged or replayed command succeeded. The findings were availability and radio-level weaknesses, each documented with a fix.Real battery life has not been measured yet
The low-power design is in place, but runtime figures are manufacturer claims until household trials finish.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.