The objective of this project is to design a secure automated lock for our smart home. We have taken the time and effort to do this as there are few 'off the shelf' solutions in the UK. There are many more options available in the USA but, none quite meets our needs.
This is not a 'stand alone' piece of hardware like many of the the 'smart' devices currently available on the market. Our solution is fully integrated into our smart home and all elements of it can be queried and controlled (like all of the other components in our smart home). This includes query and control via our AI engine, voice control and all of our remote interfaces. Our smart lock and all its attributes are part of the 'whole house' context used to make intelligent decisions and their resulting actions.
There is no intelligence within the 'smart lock' itself. It is essentially a 'dumb' (networked) device that sends events to our Home Control System (HCS), which makes the intelligence decisions and sends back control requests to the lock. This architectural approach with centralised, 'all seeing' intelligence is a core design principle of our smart home.
- The lock must be very secure and use encryption to prevent tampering and unauthorised access and use.
- It must very reliable (>99.99% availability like all the other elements of our smart home).
- It must track whether the associated door is open or closed and act accordingly, e.g. not try to lock an open door.
- It must provide a clear visual indication of its status (locked or unlocked) from within the house and this must not be visible from outside the house.
- It must provide a clear audible and visual indication to the person operating outside the house when the state changes from locked and unlocked.
- It must deliver messages to our Home Control System (HCS) for changes in state and any errors or issues.
- The lock must support manual locking and unlocking (manual over-ride) from inside the house, in such a way such that it can't be operated through the letter box, etc.
- It must support manual locking and unlocking (manual over-ride) from outside the house, using a physical key.
- It must generate an event for a physical key being inserted and also the key being removed.
- It must generate an event for any RFID tag being read, along with the tag ID.
- It must let a user know when a valid or invalid tag has been read.
- If the lock state remains neither locked or unlocked for more than one second, then an error event must be reported to the Home Control System (HCS).
- It must action requests to lock and unlock from our Home Control System (HCS).
- Our solution must support more than one smart lock being used in our home.
- We are assuming that our Home Control System (HCS) controls when the door is locked or unlocked (manual over-ride aside).
- We are assuming the smart lock is powered via a protected power supply (i.e. via our 12V Uninterruptible Power Supply (UPS)).
- We are assuming the smart lock events are used to trigger things like (drive) occupancy, security cameras, lighting, etc.
- The smart lock uses a wired network connection for maximum security and performance and all network elements are also powered via a protected power supply (i.e. via our 12V Uninterruptible Power Supply (UPS)).
- The lock cannot be used for occupancy as it can be operated from either side of the door or remotely. The key is on the outside of the door though and can be used for occupancy detection (of our driveway).
- We consider the key entry detection and the NFC/RFID key/tag reader to be modelled as a separate (but linked) object to the door lock.
This is the user experience we plan to deliver. All voice announcements will come from inside the house but will be loud enough to be heard when outside the front door.
A physical key enables the door to be unlocked and opened even in the unlikely event that the power to the door has failed. It is not expected to be used in normal use.
- The key insertion is detected and results in a security camera image being captured.
- Turning the key (assuming it is a valid one) will unlock the door.
- A voice announcement will then be heard from ('door unlocked').
- The door can also be locked from outside with a physical key in the same way.
- A voice announcement will then be heard ('door locked').
Note that there is no way to know if the door is locked or unlocked from outside the house. This is a deliberate design feature to improve security. The following user interaction is also designed to be as quick and efficient as possible.
All tags used to operate the lock have a unique ID and are associated with known users of the smart home and as such they are used to indicate presence.
- Touching a readable tag onto the tag reader will result in a voice announcement ('key accepted' or 'key rejected').
- The 'tag disabled' light will also light up for 3 seconds.
- If the tag was valid, the lock will change state and a voice announcement will be heard ('door unlocked' or 'door locked').
- The user will have to wait 3 seconds before they can use the tag again.
- When leaving the house, the user can touch a valid tag to the tag reader to lock the door.
- A voice announcement will be heard ('key accepted').
- The 'tag disabled' light will also light up for 3 seconds.
- The door will lock.
- A voice announcement will be heard ('door locked').
This lock is designed so that you don't need a key to unlock it from the inside.
From inside the house an LED on the lock provides a clear indication of the lock status (locked/unlocked). This is designed to be clearly visible from the far side of the room.
- The door can be locked or unlocked by twisting the lock mechanism by hand.
- A voice announcement will be heard ('door unlocked' or 'door locked').
The door lock is designed to be another object within our smart home and as such is fully controllable by all of the interfaces we use to expose it. This includes SMS, email, XMPP, web interfaces and voice control. Anyone with trusted access can lock or unlock the door remotely.
This means that our generic artificial intelligence (AI) engine can be used to set user specific notifications, e.g. "Let me know when Rob unlocks the front door" and a notification will be sent when Rob unlocks the front door. This could equally have been when 'someone' or 'anybody' opens the front door.
Remote communication with guests or visitors leading to remote smart lock operation is covered as part of a separate project.
The design has been created to enable the above user experience. The logical design looks like this:
The interface is a networked processor such as a Raspberry Pi or Arduino UNO. Given that we have already deployed a Raspberry Pi for our smart front door project it makes sense to reuse this slave HCS processor for this project and simply extend the functionality.
Models & Objects
As far as our Home Control System (HCS) is concerned this projects is actually a number of objects modelled within our smart home:
- The 'Front Door' of type 'Door'.
- The 'Front Door Lock' of type 'Lock' - has an associated 'Door' object.
- The 'Front Door Key' of type 'Key' - has an associated 'Door' object.
- The 'Front Door Light' of type 'Light'.
- The 'Front Door Safety Light' of type 'Light'.
- The 'Front Door UV Light' of type 'Light'.
- The 'Door Bell' of type 'Momentary'.
- The 'Letter Box' of type 'Contact'.
- The 'Front Door Panic Button' of type 'Panic'.
- The 'Front Door Voltage' of type 'Voltage'.
Things like speakers (for voice announcements) and cameras are also modelled as objects but are considered outside the scope of this project.
We want a clearly visible indication of the lock status from inside the house. We are using a bi-colour LED to indicate status, red for locked and green for unlocked. An unlit LED indicates a transition between these states or an unknown state or issue.
A 12V dc signal is fed via our sensors to the LEDs and the 'locked' and 'unlocked' inputs on our input board.
The interface receives lock and unlock events from the Home Control System (HCS) and translates them to short pulses on the 'lock' and 'unlock' outputs on the Raspberry Pi (control inputs to the physical lock module).
We are using an older Raspberry Pi B for our interface board as we have written most of the code for this over the years and it supports a wide range of features.
Because the original Raspberry Pi has a bespoke GPIO header, so we created this board to act as an interfacing 'brick', again exposing the pins in a standard way. This design has two 10-way PCB headers, each of which can be configured as input or output.
We developed this generic 8-channel optically-isolated input board to rapidly enable connection of digital sensors. It exposes a standard 4-way Single In-Line (SIL) connector which is common to other bricks. We are using this for prototyping but we will probably develop a simpler PCB for this project.
We developed this generic 8-channel high-power output board to enable control of 12V dc devices, lighting, sounders, etc. We are using this for prototyping but ultimately we will develop a bespoke circuit design and PCB for this project.
The only other connections to this module are for the 12V dc power supply and a wired IP network connection.
We have 8 digital inputs as part of this project and the wider 'smart front door':
- Front Door PIR
- Front Door
- Door Bell
- Letter Box
- Front Door Panic Button
- Front Door Key
- 'locked' - signal from lock mechanism
- 'unlocked' - signal from lock mechanism
- Front Door Light - porch lighting
- Front Door UV Light - used for security camera at night
- Front Door Safety Light - low level UPS protected safety lighting
- 'lock' - signal to lock mechanism
- 'unlock' - unlock signal to mechanism
- 'disabled' - the RFID/NFC reader is disabled
We are not trying to re-invent the physical lock hardware. We simply want to put an automation wrap around existing standard lock mechanisms. We are working with several different types at the moment to see what works best. We are ideally looking to support UPVC doors with multipoint locking systems but we are also testing with a standard deadbolt lock.
We are putting additional sensors on the lock mechanism though. We have sensors that detect when a key is inserted and when the lock mechanism is locked or unlocked. These detect the actual state of the lock mechanism regardless of how it has been operated. We are testing a range of sensors to achieve this including micro-switches and optical sensors.
As with all of our HCS, this project is written in Java and re-uses large parts of the code we have developed over the years. It runs as a multi-threaded process that monitors the digital inputs and controls devices connected to the digital outputs.
The Raspberry Pi used here uses our watchdog service and performance monitoring tools, so we can be sure the lock is up and running.
They physical key will drive events (on insertion, removal, locking and unlocking) via the interface and the timing of these is down to actual use in the real world. With the NFC/RFID reader the timing needs to be considered more carefully:
- The reading of an RFID/NFC tag will toggle lock status (between locked and unlocked) but there is some inherent latency in the tag reader. When the reader detects the presence of a tag an event is sent to the Home Control System (HCS).
- The HCS then decides whether to send an event to the lock interface module, to lock or unlock it (depending on its current state).
- This all happens very quickly but, there is still a chance that the tag may be read more than once by accident and we really don't want this to happen.
- To avoid stop annoying user experience issue occurring we indicate that a valid/invalid tag was read with an audio announcement and we also disable the tag reader for 3 seconds and light the tag 'disabled' LED for this duration.
This means basically implementing a 'debounce' feature in software, which provides a much better user experience. The 3 seconds delay also conveniently provides time for the voice announcements to fully play out.
Sounds & Voice Announcements
We have decided to use a common voice throughout our smart home. These can be made locally or throughout the whole house. This project uses the following local (pre-recorded) voice announcements:
The 'interface' part of this project is very quick and easy to do, using our existing code libraries and interfaces. Probably just a few hours work. That's why the focus is on the hardware aspects for now. We are currently investigating existing lock designs and plan to use 3D printing to encase an existing lock mechanism in a high quality enclosure.
Lock Internal Enclosure
We plan to use the existing lock hardware on the outside of the door, with no visible or obvious changes. The only external addition is our voice announcements.
On the inside of the door we are using a low profile (approximately 30mm deep) rounded rectangular 3D-printed case to enclose the motor, gearing and electronics, replacing the existing lock face plate.
The interface module is mounted remotely to the side of the door. Our plan is for this to be invisible and eventually mounted within the wall. This approach fits well with out wider 'smart front door' project.
The wires from the interface module are hidden inside the wall and enter the door frame. They run from the door frame to the rear edge of the door via an armour plated 'door loop'. The cables used are made from 'extra flexible' wiring, to ensure reliable operation over many years. This is all out of sight when the door is closed.
This project refers to a 'smart lock' but in reality it is a networked door lock, with the 'smart'-ness residing in our Home Control System (HCS). Because our HCS has 'whole house' context, it can make intelligent decisions as to when the door is locked and unlocked.
This includes situations that are not 'seen' by the door or lock, e.g. the front door may be unlocked if a fire is detected or a carbon monoxide (CO) alarm is activated. Our HCS also tracks devices on and off our home network and could use these events to decide to unlock the front door. It is equally possible to unlock the front door based on location tracking of family members.