[Door Lock App] Failure of basic lock/unlock

[tcarmelveilleux]

Problem

Found during smoke testing of SDK Master at Google, Jun 7 2022

Device EFR32, Controller Linux.

With the default door-lock app example, the "lock" and "unlock" now fail.

Executed from code state:

connectedhomeip/examples/lock-app/lock-common/lock-app.zap

Line 7847 in ae6e092

{

Command:

./out/chip-tool doorlock unlock-door $node_id 1 --timedInteractionTimeoutMs 1000
./out/chip-tool doorlock lock-door $node_id 1 --timedInteractionTimeoutMs 1000

Both fail with

[1654591433.194073][33215:33215] CHIP:TOO: Run command failure: IM Error 0x00000501: General error: 0x01 (FAILURE)

Execution log on EFR32:

• Jlinkrttc.log

Execution log for Lock on Linux:

• lock.log

Execution log for Unlock on Linux:

• unlock.log

When looking at the device log:

<detail> [EM] Found matching exchange: 16796r, Delegate: 0x2000a8d0
<detail> [EM] Rxd Ack; Removing MessageCounter:117370073 from Retrans Table on exchange 16796r
<detail> [EM] Removed CHIP MessageCounter:117370073 from RetransTable on exchange 16796r
<detail> [DMG] Timed following action arrived at 0x000000000000EE0D: handler 0x2000a8d0 exchange 16796r
<detail> [DMG] Handing timed invoke to IM engine: handler 0x2000a8d0 exchange 16796r
<detail> [DMG] Received command for Endpoint=1 Cluster=0x0000_0101 Command=0x0000_0000
<info  > [ZCL] Received command: LockDoor
<error > [ZCL] Failed to read DoorLock attribute: attribute=0x33, status=0x86
<detail> [DMG] ICR moving to [ Preparing]

Seems like there was an internal error to read DoorLock Attribute:

template <typename T>
bool DoorLockServer::GetAttribute(chip::EndpointId endpointId, chip::AttributeId attributeId,
                                  EmberAfStatus (*getFn)(chip::EndpointId endpointId, T * value), T & value)
{
    EmberAfStatus status = getFn(endpointId, &value);
    bool success         = (EMBER_ZCL_STATUS_SUCCESS == status);

    if (!success)
    {
        ChipLogError(Zcl, "Failed to read DoorLock attribute: attribute=0x%" PRIx32 ", status=0x%x", attributeId,
                     to_underlying(status));
    }
    return success;
}

Code path:

    else
    {
        // appclusters.pdf 5.3.4.1:
        // If the RequirePINforRemoteOperation attribute is True then PINCode field SHALL be provided and the door lock SHALL NOT
        // grant access if it is not provided.
        bool requirePin = false;
        VerifyOrExit(GetAttribute(endpoint, Attributes::RequirePINforRemoteOperation::Id,
                                  Attributes::RequirePINforRemoteOperation::Get, requirePin),
                     /* credentialsOk is false here */);
        credentialsOk = !requirePin;
    }

Upon inspection, feature is Upon further inspection, the featuremap is 0x0133 - 0b100110011 => bits 0, 1, 4, 5, 8 set, features PIN | RID |SCH | DPS | USR.

It looks like the code is checking for RequirePINforRemoteOperation but the conformance of this attribute is COTA & PIN

A recent change removed the attribute from ZAP due to COTA feature not enabled

However, the code is still trying to read an attribute that has now disappeared from the attribute store to affect an internal data dependency condition of the cluster.

Proposed Solution

Instead of VerifyOrExit(GetAttribute(endpoint, Attributes::RequirePINforRemoteOperation::Id, Attributes::RequirePINforRemoteOperation::Get, requirePin)

there should be code that checks for conformance and if the feature maps doesn't have COTA & PIN, or if the RequirePINforRemoteOperation is missing, then the code should assume that a PIN required is false and proceed with open.