Variable BaseConst

Type declaration

• Readonlyattributes: {
      actuatorEnabled: Attribute<boolean, any>;
      alarmMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
      autoRelockTime: OptionalWritableAttribute<number, any>;
      defaultConfigurationRegister: OptionalAttribute<TypeFromPartialBitSchema, any>;
      enableInsideStatusLed: OptionalWritableAttribute<boolean, any>;
      enableLocalProgramming: OptionalWritableAttribute<boolean, any>;
      enableOneTouchLocking: OptionalWritableAttribute<boolean, any>;
      enablePrivacyModeButton: OptionalWritableAttribute<boolean, any>;
      language: OptionalWritableAttribute<string, any>;
      ledSettings: OptionalWritableAttribute<DoorLock.LedSetting, any>;
      localProgrammingFeatures: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
      lockState: Attribute<DoorLock.LockState | null, any>;
      lockType: Attribute<DoorLock.LockType, any>;
      operatingMode: WritableAttribute<DoorLock.OperatingMode, any>;
      soundVolume: OptionalWritableAttribute<DoorLock.SoundVolume, any>;
      supportedOperatingModes: FixedAttribute<TypeFromPartialBitSchema, any>;
  }

  • ReadonlyactuatorEnabled: Attribute<boolean, any>

    Indicates if the lock is currently able to (Enabled) or not able to (Disabled) process remote Lock, Unlock, or Unlock with Timeout commands.

    See

    MatterSpecification.v13.Cluster § 5.2.9.4

  • ReadonlyalarmMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>

    This attribute is only supported if the Alarms cluster is on the same endpoint. The alarm mask is used to turn on/off alarms for particular functions. Alarms for an alarm group are enabled if the associated alarm mask bit is set. Each bit represents a group of alarms. Entire alarm groups can be turned on or off by setting or clearing the associated bit in the alarm mask.

    This mask DOES NOT apply to the Events mechanism of this cluster.

    See

    MatterSpecification.v13.Cluster § 5.2.9.40

  • ReadonlyautoRelockTime: OptionalWritableAttribute<number, any>

    Indicates the number of seconds to wait after unlocking a lock before it automatically locks again. 0=disabled. If set, unlock operations from any source will be timed. For one time unlock with timeout use the specific command.

    See

    MatterSpecification.v13.Cluster § 5.2.9.25

  • ReadonlydefaultConfigurationRegister: OptionalAttribute<TypeFromPartialBitSchema, any>

    Indicates the default configurations as they are physically set on the device (example: hardware dip switch setting, etc…) and represents the default setting for some of the attributes within this cluster (for example: LED, Auto Lock, Sound Volume, and Operating Mode attributes).

    This is a read-only attribute and is intended to allow clients to determine what changes may need to be made without having to query all the included attributes. It may be beneficial for the clients to know what the device’s original settings were in the event that the device needs to be restored to factory default settings.

    If the Client device would like to query and modify the door lock server’s operating settings, it SHOULD send read and write attribute requests to the specific attributes.

    For example, the Sound Volume attribute default value is Silent Mode. However, it is possible that the current Sound Volume is High Volume. Therefore, if the client wants to query/modify the current Sound Volume setting on the server, the client SHOULD read/write to the Sound Volume attribute.

    See

    MatterSpecification.v13.Cluster § 5.2.9.29

  • ReadonlyenableInsideStatusLed: OptionalWritableAttribute<boolean, any>

    This attribute shall enable/disable an inside LED that allows the user to see at a glance if the door is locked.

    See

    MatterSpecification.v13.Cluster § 5.2.9.32

  • ReadonlyenableLocalProgramming: OptionalWritableAttribute<boolean, any>

    This attribute shall enable/disable local programming on the door lock of certain features (see LocalProgrammingFeatures attribute). If this value is set to TRUE then local programming is enabled on the door lock for all features. If it is set to FALSE then local programming is disabled on the door lock for those features whose bit is set to 0 in the LocalProgrammingFeatures attribute. Local programming shall be enabled by default.

    See

    MatterSpecification.v13.Cluster § 5.2.9.30

  • ReadonlyenableOneTouchLocking: OptionalWritableAttribute<boolean, any>

    This attribute shall enable/disable the ability to lock the door lock with a single touch on the door lock.

    See

    MatterSpecification.v13.Cluster § 5.2.9.31

  • ReadonlyenablePrivacyModeButton: OptionalWritableAttribute<boolean, any>

    This attribute shall enable/disable a button inside the door that is used to put the lock into privacy mode. When the lock is in privacy mode it cannot be manipulated from the outside.

    See

    MatterSpecification.v13.Cluster § 5.2.9.33

  • Readonlylanguage: OptionalWritableAttribute<string, any>

    Indicates the language for the on-screen or audible user interface using a 2- byte language code from ISO-639-1.

    See

    MatterSpecification.v13.Cluster § 5.2.9.23

  • ReadonlyledSettings: OptionalWritableAttribute<DoorLock.LedSetting, any>

    Indicates the settings for the LED support, as defined by LEDSettingEnum.

    See

    MatterSpecification.v13.Cluster § 5.2.9.24

  • ReadonlylocalProgrammingFeatures: OptionalWritableAttribute<TypeFromPartialBitSchema, any>

    Indicates the local programming features that will be disabled when EnableLocalProgramming attribute is set to False. If a door lock doesn’t support disabling one aspect of local programming it shall return CONSTRAINT_ERROR during a write operation of this attribute. If the EnableLocalProgramming attribute is set to True then all local programming features shall be enabled regardless of the bits set to 0 in this attribute.

    The features that can be disabled from local programming are defined in LocalProgrammingFeaturesBitmap.

    See

    MatterSpecification.v13.Cluster § 5.2.9.34

  • ReadonlylockState: Attribute<DoorLock.LockState | null, any>

    This attribute may be NULL if the lock hardware does not currently know the status of the locking mechanism. For example, a lock may not know the LockState status after a power cycle until the first lock actuation is completed.

    The Not Fully Locked value is used by a lock to indicate that the state of the lock is somewhere between Locked and Unlocked so it is only partially secured. For example, a deadbolt could be partially extended and not in a dead latched state.

    See

    MatterSpecification.v13.Cluster § 5.2.9.2

  • ReadonlylockType: Attribute<DoorLock.LockType, any>

    Indicates the type of door lock as defined in LockTypeEnum.

    See

    MatterSpecification.v13.Cluster § 5.2.9.3

  • ReadonlyoperatingMode: WritableAttribute<DoorLock.OperatingMode, any>

    Indicates the current operating mode of the lock as defined in OperatingModeEnum.

    See

    MatterSpecification.v13.Cluster § 5.2.9.27

  • ReadonlysoundVolume: OptionalWritableAttribute<DoorLock.SoundVolume, any>

    Indicates the sound volume on a door lock as defined by SoundVolumeEnum.

    See

    MatterSpecification.v13.Cluster § 5.2.9.26

  • ReadonlysupportedOperatingModes: FixedAttribute<TypeFromPartialBitSchema, any>

    This attribute shall contain a bitmap with all operating bits of the OperatingMode attribute supported by the lock. All operating modes NOT supported by a lock shall be set to one. The value of the OperatingMode enumeration defines the related bit to be set.

    See

    MatterSpecification.v13.Cluster § 5.2.9.28

• Readonlycommands: {
      lockDoor: Command<TypeFromFields, void, any>;
      unlockDoor: Command<TypeFromFields, void, any>;
      unlockWithTimeout: OptionalCommand<TypeFromFields, void, any>;
  }

  • ReadonlylockDoor: Command<TypeFromFields, void, any>

    This command causes the lock device to lock the door. This command includes an optional code for the lock. The door lock may require a PIN depending on the value of the RequirePINForRemoteOperation attribute.

    † The PIN/RFID Code is an obsolete field name, use PINCode instead.

    See

    MatterSpecification.v13.Cluster § 5.2.10.1

  • ReadonlyunlockDoor: Command<TypeFromFields, void, any>

    This command causes the lock device to unlock the door. This command includes an optional code for the lock. The door lock may require a code depending on the value of the RequirePINForRemoteOperation attribute.

    NOTE

    If the attribute AutoRelockTime is supported the lock will transition to the locked state when the auto relock time has expired.

    † The PIN/RFID Code is an obsolete field name, use PINCode instead.

    See

    MatterSpecification.v13.Cluster § 5.2.10.2

  • ReadonlyunlockWithTimeout: OptionalCommand<TypeFromFields, void, any>

    This command causes the lock device to unlock the door with a timeout parameter. After the time in seconds specified in the timeout field, the lock device will relock itself automatically. This timeout parameter is only temporary for this message transition and overrides the default relock time

    as specified in the AutoRelockTime attribute. If the door lock device is not capable of or does not want to support temporary Relock Timeout, it SHOULD NOT support this optional command.

    † The PIN/RFID Code is an obsolete field name, use PINCode instead.

    See

    MatterSpecification.v13.Cluster § 5.2.10.3

• Readonlyevents: {
      doorLockAlarm: Event<TypeFromFields, any>;
      lockOperation: Event<TypeFromFields, any>;
      lockOperationError: Event<TypeFromFields, any>;
  }

  • ReadonlydoorLockAlarm: Event<TypeFromFields, any>

    The door lock server provides several alarms which can be sent when there is a critical state on the door lock. The alarms available for the door lock server are listed in AlarmCodeEnum.

    See

    MatterSpecification.v13.Cluster § 5.2.11.1

  • ReadonlylockOperation: Event<TypeFromFields, any>

    The door lock server sends out a LockOperation event when the event is triggered by the various lock operation sources.

    • If the door lock server supports the Unbolt Door command, it shall generate a LockOperation event with LockOperationType set to Unlock after an Unbolt Door command succeeds.

    • If the door lock server supports the Unbolting feature and an Unlock Door command is performed, it shall generate a LockOperation event with LockOperationType set to Unlatch when the unlatched state is reached and a LockOperation event with LockOperationType set to Unlock when the lock successfully completes the unlock → hold latch → release latch and return to unlock state operation.

    • If the command fails during holding or releasing the latch but after passing the unlocked state, the door lock server shall generate a LockOperationError event with LockOperationType set to Unlatch and a LockOperation event with LockOperationType set to Unlock.

    ◦ If it fails before reaching the unlocked state, the door lock server shall generate only a
      LockOperationError event with LockOperationType set to Unlock.
    

    • Upon manual actuation, a door lock server that supports the Unbolting feature:

    ◦ shall generate a LockOperation event of LockOperationType Unlatch when it is actuated from the
      outside.
    
    ◦ may generate a LockOperation event of LockOperationType Unlatch when it is actuated from the
      inside.
    

    See

    MatterSpecification.v13.Cluster § 5.2.11.3

  • ReadonlylockOperationError: Event<TypeFromFields, any>

    The door lock server sends out a LockOperationError event when a lock operation fails for various reasons.

    See

    MatterSpecification.v13.Cluster § 5.2.11.4

• Readonlyextensions: readonly [{
      component: {
          attributes: {
              doorClosedEvents: OptionalWritableAttribute<number, any>;
              doorOpenEvents: OptionalWritableAttribute<number, any>;
              doorState: Attribute<DoorLock.DoorState | null, any>;
              openPeriod: OptionalWritableAttribute<number, any>;
          };
          events: {
              doorStateChange: Event<TypeFromFields, any>;
          };
      };
      flags: {
          doorPositionSensor: true;
      };
  }, {
      component: {
          attributes: {
              enableLogging: WritableAttribute<boolean, any>;
              numberOfLogRecordsSupported: FixedAttribute<number, any>;
          };
          commands: {
              getLogRecord: Command<TypeFromFields, TypeFromFields, any>;
          };
      };
      flags: {
          logging: true;
      };
  }, {
      component: {
          attributes: {
              credentialRulesSupport: FixedAttribute<TypeFromPartialBitSchema, any>;
              expiringUserTimeout: OptionalWritableAttribute<number, any>;
              numberOfCredentialsSupportedPerUser: FixedAttribute<number, any>;
              numberOfTotalUsersSupported: FixedAttribute<number, any>;
          };
          commands: {
              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>;
          };
          events: {
              lockUserChange: Event<TypeFromFields, any>;
          };
      };
      flags: {
          user: true;
      };
  }, {
      component: {
          attributes: {
              maxPinCodeLength: FixedAttribute<number, any>;
              minPinCodeLength: FixedAttribute<number, any>;
              numberOfPinUsersSupported: FixedAttribute<number, any>;
          };
      };
      flags: {
          pinCredential: true;
      };
  }, {
      component: {
          attributes: {
              maxRfidCodeLength: FixedAttribute<number, any>;
              minRfidCodeLength: FixedAttribute<number, any>;
              numberOfRfidUsersSupported: FixedAttribute<number, any>;
          };
      };
      flags: {
          rfidCredential: true;
      };
  }, {
      component: {
          attributes: {
              numberOfWeekDaySchedulesSupportedPerUser: FixedAttribute<number, any>;
          };
          commands: {
              clearWeekDaySchedule: Command<TypeFromFields, void, any>;
              getWeekDaySchedule: Command<TypeFromFields, TypeFromFields, any>;
              setWeekDaySchedule: Command<TypeFromFields, void, any>;
          };
      };
      flags: {
          weekDayAccessSchedules: true;
      };
  }, {
      component: {
          attributes: {
              numberOfYearDaySchedulesSupportedPerUser: FixedAttribute<number, any>;
          };
          commands: {
              clearYearDaySchedule: Command<TypeFromFields, void, any>;
              getYearDaySchedule: Command<TypeFromFields, TypeFromFields, any>;
              setYearDaySchedule: Command<TypeFromFields, void, any>;
          };
      };
      flags: {
          yearDayAccessSchedules: true;
      };
  }, {
      component: {
          attributes: {
              numberOfHolidaySchedulesSupported: FixedAttribute<number, any>;
          };
          commands: {
              clearHolidaySchedule: Command<TypeFromFields, void, any>;
              getHolidaySchedule: Command<TypeFromFields, TypeFromFields, any>;
              setHolidaySchedule: Command<TypeFromFields, void, any>;
          };
      };
      flags: {
          holidaySchedules: true;
      };
  }, {
      component: {
          attributes: {
              userCodeTemporaryDisableTime: WritableAttribute<number, any>;
              wrongCodeEntryLimit: WritableAttribute<number, any>;
          };
      };
      flags: {
          pinCredential: true;
      };
  }, {
      component: {
          attributes: {
              userCodeTemporaryDisableTime: WritableAttribute<number, any>;
              wrongCodeEntryLimit: WritableAttribute<number, any>;
          };
      };
      flags: {
          rfidCredential: true;
      };
  }, {
      component: {
          attributes: {
              sendPinOverTheAir: OptionalWritableAttribute<boolean, any>;
          };
          commands: {
              clearAllPinCodes: Command<void, void, any>;
              clearPinCode: Command<TypeFromFields, void, any>;
              getPinCode: Command<TypeFromFields, TypeFromFields, any>;
              setPinCode: Command<TypeFromFields, void, any>;
          };
      };
      flags: {
          pinCredential: true;
          user: false;
      };
  }, {
      component: {
          attributes: {
              requirePinForRemoteOperation: WritableAttribute<boolean, any>;
          };
      };
      flags: {
          credentialOverTheAirAccess: true;
          pinCredential: true;
      };
  }, {
      component: {
          attributes: {
              keypadOperationEventMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
              keypadProgrammingEventMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
          };
      };
      flags: {
          notification: true;
          pinCredential: true;
      };
  }, {
      component: {
          attributes: {
              manualOperationEventMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
              remoteOperationEventMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
              remoteProgrammingEventMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
          };
      };
      flags: {
          notification: true;
      };
  }, {
      component: {
          attributes: {
              rfidOperationEventMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
              rfidProgrammingEventMask: OptionalWritableAttribute<TypeFromPartialBitSchema, any>;
          };
      };
      flags: {
          notification: true;
          rfidCredential: true;
      };
  }, {
      component: {
          commands: {
              getUserStatus: OptionalCommand<TypeFromFields, TypeFromFields, any>;
              getUserType: OptionalCommand<TypeFromFields, TypeFromFields, any>;
              setUserStatus: OptionalCommand<TypeFromFields, void, any>;
              setUserType: OptionalCommand<TypeFromFields, void, any>;
          };
      };
      flags: {
          fingerCredentials: true;
          pinCredential: true;
          rfidCredential: true;
          user: false;
      };
  }, {
      component: {};
      flags: {
          user: false;
      };
  }, {
      component: {
          commands: {
              clearAllRfidCodes: Command<void, void, any>;
              clearRfidCode: Command<TypeFromFields, void, any>;
              getRfidCode: Command<TypeFromFields, TypeFromFields, any>;
              setRfidCode: Command<TypeFromFields, void, any>;
          };
      };
      flags: {
          rfidCredential: true;
          user: false;
      };
  }, {
      component: {
          commands: {
              unboltDoor: Command<TypeFromFields, void, any>;
          };
      };
      flags: {
          unbolting: true;
      };
  }, {
      component: false;
      flags: {
          faceCredentials: true;
          fingerCredentials: true;
          pinCredential: true;
          rfidCredential: true;
          user: true;
      };
  }]

  This metadata controls which DoorLockCluster elements matter.js activates for specific feature combinations.

• Readonlyfeatures: {
      credentialOverTheAirAccess: BitFlag;
      doorPositionSensor: BitFlag;
      faceCredentials: BitFlag;
      fingerCredentials: BitFlag;
      holidaySchedules: BitFlag;
      logging: BitFlag;
      notification: BitFlag;
      pinCredential: BitFlag;
      rfidCredential: BitFlag;
      unbolting: BitFlag;
      user: BitFlag;
      weekDayAccessSchedules: BitFlag;
      yearDayAccessSchedules: BitFlag;
  }

  • ReadonlycredentialOverTheAirAccess: BitFlag

    CredentialOverTheAirAccess

    If this feature is supported then the lock supports the ability to verify a credential provided in a lock/unlock command. Currently the cluster only supports providing the PIN credential to the lock/unlock commands. If this feature is supported then the PIN Credential feature shall also be supported.

    See

    MatterSpecification.v13.Cluster § 5.2.4.8

  • ReadonlydoorPositionSensor: BitFlag

    DoorPositionSensor

    If this feature is supported this indicates that the lock has the ability to determine the position of the door which is separate from the state of the lock.

    See

    MatterSpecification.v13.Cluster § 5.2.4.6

  • ReadonlyfaceCredentials: BitFlag

    FaceCredentials

    Currently the cluster only defines the metadata format for notifications when a face recognition, iris, or retina credential is used to access the lock and doesn’t describe how to create face recognition, iris, or retina credentials. If the Users feature is also supported then the User that a face recognition, iris, or retina credential is associated with can also have its UserType, UserStatus and Schedule modified.

    A lock may support multiple credential types so if the User feature is supported the UserType, UserStatus and Schedules are all associated with a User and not directly with a credential.

    See

    MatterSpecification.v13.Cluster § 5.2.4.7

  • ReadonlyfingerCredentials: BitFlag

    FingerCredentials

    Currently the cluster only defines the metadata format for notifications when a fingerprint/ finger vein credential is used to access the lock and doesn’t describe how to create fingerprint/finger vein credentials. If the Users feature is also supported then the User that a fingerprint/finger vein is associated with can also have its UserType, UserStatus and Schedule modified.

    A lock may support multiple credential types so if the User feature is supported the UserType, UserStatus and Schedules are all associated with a User index and not directly with a Finger index. A User Index may have several credentials associated with it.

    See

    MatterSpecification.v13.Cluster § 5.2.4.3

  • ReadonlyholidaySchedules: BitFlag

    HolidaySchedules

    This feature is used to setup Holiday Schedule in the lock device. A Holiday Schedule sets a start and stop end date/time for the lock to use the specified operating mode set by the Holiday Schedule.

    See

    MatterSpecification.v13.Cluster § 5.2.4.12

  • Readonlylogging: BitFlag

    Logging

    If Events are not supported the logging feature shall replace the Event reporting structure. If Events are supported the logging feature shall NOT be supported.

    See

    MatterSpecification.v13.Cluster § 5.2.4.4

  • Readonlynotification: BitFlag

    Notification

    This is a feature used before support of events. This feature supports notification commands and masks used to filter these notifications.

    See

    MatterSpecification.v13.Cluster § 5.2.4.10

  • ReadonlypinCredential: BitFlag

    PinCredential

    If the User Feature is also supported then any PIN Code stored in the lock shall be associated with a User.

    A lock may support multiple credential types so if the User feature is supported the UserType, UserStatus and Schedules are all associated with a User index and not directly with a PIN index. A User index may have several credentials associated with it.

    See

    MatterSpecification.v13.Cluster § 5.2.4.1

  • ReadonlyrfidCredential: BitFlag

    RfidCredential

    If the User Feature is also supported then any RFID credential stored in the lock shall be associated with a User.

    A lock may support multiple credential types so if the User feature is supported the UserType, UserStatus and Schedules are all associated with a User index and not directly with a RFID index. A User

    Index may have several credentials associated with it.

    See

    MatterSpecification.v13.Cluster § 5.2.4.2

  • Readonlyunbolting: BitFlag

    Unbolting

    Locks that support this feature differentiate between unbolting and unlocking. The Unbolt Door command retracts the bolt without pulling the latch. The Unlock Door command fully unlocks the door by retracting the bolt and briefly pulling the latch. While the latch is pulled, the lock state changes to Unlatched. Locks without unbolting support don’t differentiate between unbolting and unlocking and perform the same operation for both commands.

    See

    MatterSpecification.v13.Cluster § 5.2.4.13

  • Readonlyuser: BitFlag

    User

    If the User Feature is supported then a lock employs a User database. A User within the User database is used to associate credentials and schedules to single user record within the lock. This also means the UserType and UserStatus fields are associated with a User and not a credential.

    See

    MatterSpecification.v13.Cluster § 5.2.4.9

  • ReadonlyweekDayAccessSchedules: BitFlag

    WeekDayAccessSchedules

    If the User feature is supported then Week Day Schedules are applied to a User and not a credential.

    Week Day Schedules are used to restrict access to a specified time window on certain days of the week. The schedule is repeated each week. When a schedule is cleared this clears the access restrictions and grants unrestricted access to the user. The lock may automatically adjust the UserType when a schedule is created or cleared.

    See

    MatterSpecification.v13.Cluster § 5.2.4.5

  • ReadonlyyearDayAccessSchedules: BitFlag

    YearDayAccessSchedules

    If the User feature is supported then Year Day Schedules are applied to a User and not a credential.

    Year Day Schedules are used to restrict access to a specified date and time window. When a schedule is cleared this clears the access restrictions and grants unrestricted access to the user. The lock may automatically adjust the UserType when a schedule is created or cleared.

    See

    MatterSpecification.v13.Cluster § 5.2.4.11

• Readonlyid: 257

• Readonlyname: "DoorLock"

• Readonlyrevision: 7