SMART LOCK with MATTER & UWB

Recently I sought to replace my existing DIY WiFi Smart Lock with a more modern one, that is also capable to auto unlock my door when I am in a certain range close to the door and already supports the new Matter standard.

After doing my research on the market, I mainly found solutions based on Bluetooth Low Energy, WiFi and/or NFC/RFID - with rather "older" technology stacks, that also work, but did not match my intentions.

Nuki however, is slightly ahead of its competitors (IMHO), and recently published an interesting article about the first european Smart Lock prototype with Matter support (https://nuki.io/de/blog/nuki-news-de/nuki-matter/). This is great news - even though it is not yet available on the market.

Since I did not find the right solution for me on the market so far, I decided to have some fun during my holidays and do a modernization of my existing DIY WiFi Smart Lock.

So today, I do not present an article about europeans first prototype Smart Lock with Matter support (so did Nuki ;-)), but I would like to present an article about one of the first prototype Smart Lock's with Matter over Thread & UWB (Ultra-Wideband) support - my renewed DIY Smart Lock.

This article will mainly focus on the architecture side. So if you are interested into more software implementation details, just drop me a message.

Remark: this article is not meant to be a step by step tutorial to create a DIY Smart Lock with Matter and UWB support. Instead, it will provide some insights about the overall architecture and the beauty of Matter + UWB in combination.

Let's start with the overall architecture and the components used.

For the Matter over Thread part, to support basic smart home integrations, two main things are needed (beside the commissioner...):

(1) A Thread Border Router (in my case a Google Nest Hub Gen.2 - as it is quite affordable)

(2) A powerful SoM (Socket on Module) to handle the entire Matter stack. Here I have decided to use the "MGM240PB32VNA3" with 802.15.4 and BLE support from Silicon Labs.

To get the UWB world involved, to support the reliable auto-unlock functionality if I am near to my Smart Lock, two components are needed:

(1) A SoM to handle the UWB and BLE stack, in order to do the distance measurement (two-way-ranging). As already suggests by its name, two-way-ranging needs a second component to get the distance measurement working - in my case an (2) iPhone 12 with U1 chip is being used, that supports the UWB capability. The SoM I use here, is the "DWM3001C" from QORVO, as it is a certified module that is capable to work with Apples U1 chip.

To get all the development done smoothly and prevent any side-effects from existing development boards, I created two quick and dirty custom plain break-out boards, which also allows me to create more precise current measurements.

The Smart Lock itself is a DIY device, that includes a powerful MG996R motor in an already existing (albeit ugly) custom housing, that is capable to unlock my door by mechanically "turn the inserted key" (to put it simply...). It is a battery operated unit, that works with four CR123A 3V batteries. As of now, I do not have reliable data from the field about the battery life yet. An overall current measurement, with help of Nordic Semiconductor Power Profiler Kit II, has been done and a simple battery lifetime calculation states, it (MGM240P SoM + DWM3001C SoM + MG996R motor + components) can theoretically last for two months on batteries with an average usage of four control operations per day (not good, but also not that bad for a small prototype - still room for improvement ;-)).

Great! What about the software? Three different type of applications have been developed:

1. Matter App in C++ (runs on the MGM240P)
2. UWB Accessory App in C (runs on the DWM3001C)
3. User UWB App in Swift (runs on iPhone 12 with U1 chip) [not in scope of this article - basically all the magic is done with help of Apple Nearby Interaction APIs]

1.The Matter App (C++)

The Matter app - that runs on the MGM240PB32VNA3 - just supports the "Door Lock Cluster Node" (Endpoint 1 in my case) beside the default Root Node (Endpoint 0).

A good starting point for every software interested people would be:

GitHub - Silicon Labs / Matter / Lock App Example.

It is mainly responsible for two things: (1) manage all Matter relevant stuff (commissioning counter part, cluster control, etc..) and (2) handle the physical GPIO interface to the DWM3001C SoM to retrieve commands not only via Matter over Thread, but also directly via GPIO from the DWM3001C to support the auto unlock ranging use case.

One of the most important methods here is the setLockState method of my LockManager to handle the Matter DoorLock cluster commands (DoorLockServer::Instance().SetLockState) and to initiate the physical hardware interaction with the MG996R motor (HwLockLayer::Instance().SetLockState).

Additionally, the security layer expects a pin code to execute any DoorLock related cluster commands. The pin code itself can be set by an authorized user with help of the standard authorization pattern provided by Matter.

bool LockManager::setLockState(chip::EndpointId endpointId, DlLockState lockState, const Optional<chip::ByteSpan> & pin
                                   OperationErrorEnum & err)
{   
    chip::app::Clusters::DoorLock::Attributes::RequirePINforRemoteOperation::Get(endpointId, &requirePin);


    // If a pin code is not specified
    if (!pin.HasValue())
    {   
        ChipLogError(Zcl, "Pin code required, but not provided: [endpointId=%d]", endpointId);
        return false;
    }


    // Check the PIN code
    for (uint8_t i = 0; i < kMaxCredentials; i++)
    {
        if (mLockCredentials[i].credentialType != CredentialTypeEnum::kPin ||
            mLockCredentials[i].status == DlCredentialStatus::kAvailable)
        {
            continue;
        }


        if (mLockCredentials[i].credentialData.data_equal(pin.Value()))
        {
            ChipLogDetail(Zcl,
                            "Setting lock state to \"%s\" [endpointId=%d]",
                            lockStateToString(lockState), endpointId);


            // Hardware interaction with MG996R
            // If successful, set correct cluster state
            if (HwLockLayer::Instance().SetLockState(lockState) == true) {
                DoorLockServer::Instance().SetLockState(endpointId, lockState);
            }
            else {
                // TODO: Provide more detailed information about the failed attempt
                return false;
            }
        
            return true;
        }
    }


    ChipLogDetail(Zcl,
                    "Incorrect pin, ignoring command to set lock state to \"%s\" "
                    "[endpointId=%d]",
                    lockStateToString(lockState), endpointId);


    err = OperationErrorEnum::kInvalidCredential;
    return false;
}        

My implementation does not support OTA updates with help of the standard CSA Matter approach yet. So in this case, it is not fully connected to the test Distributed Compliance Ledger of the CSA.

Furthermore, it comes with static pre-created test device attestation certificates - since it is just my small development prototype, which will never leave my home or will be sold ;-).

The UWB Accessory App

The UWB Accessory App on the DWM3001C, or lets say the accessory itself, needs to be bonded to the iPhone 12 first, in order to let iOS use the DWM3001C accessory in background mode. This is a must have feature for me, otherwise the Smart Lock will not open automatically if I am within the allowed range close to the door. In addition to the basic features, a 1300 ms movement threshold has been introduced to prevent the Smart Lock to be opened by accident (...needs to be improved ;-)). It basically ensures, that you have to stand still in front of the door for at least 1300 ms, before the Smart Lock will be opened automatically.

The entire workflow is quite simple:

1. Bond UWB accessory to iPhone 12 (BLE)
2. Exchange UWB config data (BLE)
3. Start UWB on DWM3001C if iPhone is close to the accessory (a few meters) (BLE)
4. Exchange UWB messages for the Two-Way-Ranging (UWB)
5. Calculate ToF (Time of Flight) and distance with help of speed of light and initiate unlock sequence if thresholds have been met (see explanation below)
6. Stop UWB on DWM3001C if iPhone leaves range or auto exit after timeout reached

BLE and UWB are being used in combination. With this setup I can reach a BLE advertising current consumption of around 60uA (DWM3001C). If UWB is enabled, the current consumption will increase to 1.4mA (DWM3001C).

What is the magic here with ToF?

It is used in the UWB ranging calculation, which is a bit more ahead of standard BLE RSSI based calculations, that allows you to determine the distance between two accessories. BLE >= 5.1 also supports some cool new features such as *AoA calculations, that need special hardware, but can be used to achieve similar results.

Take a look at UWB two way ranging here, for more detailed information: FIRA consortium (two way ranging)

Basically, how it works (single side twr for illustration only):

ToF = (RTT - Reply Time) / 2
// RTT: round trip time from A to B to A in total
// Reply Time: time from B signal received + time from B signal left
        

Time of flight can be used to calculate the distance (A <-> B) by multiplying ToF with speed of light:

distance = ToF * speed of light        

Long story short:

If the distance between the accessories is within the allowed static range (<=75cm) and the user (the iPhone actually) has almost not moved for at least 1300 ms, the DWM3001C will trigger the MGM240P to initate the door unlock sequence.

So, what is the overall conclusion?

This particular Smart Lock can be controlled over standard Matter apps (such as Google Home) and on the same time it supports easy to use auto-unlock functionalties with help of paired UWB accessories.

One limitation, that comes with my overall architecture, is that if the paired iPhone is often too close to the Smart Lock, UWB gets enabled and consumes too much battery - therefore the 2 months battery life are probably just theoretically feasible.

Overall speaking, I have not achieved the high quality of Nukis prototype, but I was able to set up a working prototype with different modern technology stacks (such as Matter over Thread and UWB), that can work seamlessly together in harmony. Beside that, it is always good to gain further hands-on experience in new technologies and learn some cool new stuff in detail ;-). The next article will explain the software stacks a bit more in detail.

Cheers,

Lars