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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Indicates if the lock is currently able to (Enabled) or not able to (Disabled) process remote Lock, Unlock, or Unlock with Timeout commands.