Variable UserComponentConst

Type declaration

• Readonlyattributes: {
      credentialRulesSupport: FixedAttribute<TypeFromPartialBitSchema, any>;
      expiringUserTimeout: OptionalWritableAttribute<number, any>;
      numberOfCredentialsSupportedPerUser: FixedAttribute<number, any>;
      numberOfTotalUsersSupported: FixedAttribute<number, any>;
  }

  • ReadonlycredentialRulesSupport: FixedAttribute<TypeFromPartialBitSchema, any>

    This attribute shall contain a bitmap with the bits set for the values of CredentialRuleEnum supported on this device.

    See

    MatterSpecification.v13.Cluster § 5.2.9.20

  • ReadonlyexpiringUserTimeout: OptionalWritableAttribute<number, any>

    Indicates the number of minutes a PIN, RFID, Fingerprint, or other credential associated with a user of type ExpiringUser shall remain valid after its first use before expiring. When the credential expires the UserStatus for the corresponding user record shall be set to OccupiedDisabled.

    See

    MatterSpecification.v13.Cluster § 5.2.9.39

  • ReadonlynumberOfCredentialsSupportedPerUser: FixedAttribute<number, any>

    Indicates the number of credentials that could be assigned for each user.

    Depending on the value of NumberOfRFIDUsersSupported and NumberOfPINUsersSupported it may not be possible to assign that number of credentials for a user.

    For example, if the device supports only PIN and RFID credential types, NumberOfCredentialsSupportedPerUser is set to 10, NumberOfPINUsersSupported is set to 5 and NumberOfRFIDUsersSupported is set to 3, it will not be possible to actually assign 10 credentials for a user because maximum number of credentials in the database is 8.

    See

    MatterSpecification.v13.Cluster § 5.2.9.21

  • ReadonlynumberOfTotalUsersSupported: FixedAttribute<number, any>

    Indicates the number of total users supported by the lock.

    See

    MatterSpecification.v13.Cluster § 5.2.9.10

• Readonlycommands: {
      clearCredential: Command<TypeFromFields, void, any>;
      clearUser: Command<TypeFromFields, void, any>;
      getCredentialStatus: Command<TypeFromFields, TypeFromFields, any>;
      getUser: Command<TypeFromFields, TypeFromFields, any>;
      setCredential: Command<TypeFromFields, TypeFromFields, any>;
      setUser: Command<TypeFromFields, void, any>;
  }

  • ReadonlyclearCredential: Command<TypeFromFields, void, any>

    Clear one, one type, or all credentials except ProgrammingPIN credential.

    Fields used for different use cases:

    For each credential cleared whose user doesn’t have another valid credential, the corresponding user record shall be reset back to default values and its UserStatus value shall be set to Available and UserType value shall be set to UnrestrictedUser and all schedules shall be cleared. In

    this case a LockUserChange event shall be generated for the user being cleared. Return status shall be one of the following values:

    See

    MatterSpecification.v13.Cluster § 5.2.10.44

  • ReadonlyclearUser: Command<TypeFromFields, void, any>

    Clears a user or all Users.

    For each user to clear, all associated credentials (e.g. PIN, RFID, fingerprint, etc.) shall be cleared and the user entry values shall be reset to their default values (e.g. UserStatus shall be Available, UserType shall be UnrestrictedUser) and all associated schedules shall be cleared.

    A LockUserChange event with the provided UserIndex shall be generated after successfully clearing users.

    See

    MatterSpecification.v13.Cluster § 5.2.10.37

  • ReadonlygetCredentialStatus: Command<TypeFromFields, TypeFromFields, any>

    Retrieve the status of a particular credential (e.g. PIN, RFID, Fingerprint, etc.) by index.

    An InvokeResponse command shall be sent with an appropriate error (e.g. FAILURE, INVALID_COMMAND, etc.) as needed otherwise the GetCredentialStatusResponse command shall be sent implying a status of SUCCESS.

    See

    MatterSpecification.v13.Cluster § 5.2.10.42

  • ReadonlygetUser: Command<TypeFromFields, TypeFromFields, any>

    Retrieve user.

    An InvokeResponse command shall be sent with an appropriate error

    COMMAND, etc.) as needed otherwise the GetUserResponse Command shall be sent implying a status of SUCCESS.

    See

    MatterSpecification.v13.Cluster § 5.2.10.35

  • ReadonlysetCredential: Command<TypeFromFields, TypeFromFields, any>

    Set a credential (e.g. PIN, RFID, Fingerprint, etc.) into the lock for a new user, existing user, or ProgrammingUser.

    Fields used for different use cases:

    See

    MatterSpecification.v13.Cluster § 5.2.10.40

  • ReadonlysetUser: Command<TypeFromFields, void, any>

    Set user into the lock.

    Fields used for different use cases:

    Return status is a global status code or a cluster-specific status code from the Status Codes table and

    shall be one of the following values:

    • SUCCESS, if setting User was successful.

    • FAILURE, if some unexpected internal error occurred setting User.

    • OCCUPIED, if OperationType is Add and UserIndex points to an occupied slot.

    • INVALID_COMMAND, if one or more fields violate constraints or are invalid or if OperationType is Modify and UserIndex points to an available slot.

    See

    MatterSpecification.v13.Cluster § 5.2.10.34

• Readonlyevents: {
      lockUserChange: Event<TypeFromFields, any>;
  }

  • ReadonlylockUserChange: Event<TypeFromFields, any>

    The door lock server sends out a LockUserChange event when a lock user, schedule, or credential change has occurred.

    See

    MatterSpecification.v13.Cluster § 5.2.11.5