Any time schedule data for a Target (distinct combination of Target CC and Target ID) is queried by a controlling node, it MUST follow the process defined in Figure 6.2:
Nodes controlling this command class MUST also control at least one (1) of the supported Target Command Classes, at the listed version or higher, that are listed in Table 6.1:
Table 6.1 Active Schedule Command Class::Supported Target CCs¶
If the supporting node is in the locked state and runs in restricted mode, the end user MUST be able send an unlock command. When the end user performs this action, the issued command MUST comply with Table 6.2.
If the supporting node is in the locked state and runs in restricted mode, the controlling node MUST have a UI allowing the end user to see that the supporting node is restricted and that the supporting node requires unlocking to use the full functionality.
\requirement{CL:007E.01.43.01.1}{0}
A controlling node MAY display the information provided in [26] for the reported Z-Wave Alliance locking entity ID.
A node controlling this command class SHOULD also control the Notification Command Class.
A node controlling this command class SHOULD activate all supported subsystems by default.
A controlling node MAY have a UI allowing the end user to see the following properties:
Last known state (On or Off)
\requirement{CL:0020.01.42.01.1}{0}
A controlling node SHOULD NOT assume that the last state is as defined in the last Set Command and SHOULD issue a subsequent Basic Get Command even if receiving a Supervision SUCCESS status after issuing a Basic Set Command.
A controlling node MUST NOT use the Basic Command Class for controlling nor showing status (receiving report) of a node (or endpoint) if the controlling node controls at least one actuator command class supported by a node (or endpoint). The actuator command classes are defined in Application Command Classes.
A node controlling this command class MAY skip the AGI Interview (refer to
Section 6.3.2)
if the supporting node is a Z-Wave Plus node and the controlling
node has estalished a Lifeline Association.
There is no minimum end user functionalities associated with the control of this Command Class.
\requirement{CL:005B.01.32.01.1}{0}
A controlling node SHOULD allow the user to define which other nodes to actuate when receiving a Central Scene Notification from a given node with a given key attribute and SceneID.
A node controlling this command class MUST also control:
Association Command Class, version 2
Association Group Information, version 3
\requirement{CL:005B.01.51.02.1}{0}
A controlling node MUST associate itself to a group issuing Central Scene Notification Commands in order to provide end user functionalities.
\requirement{CL:005B.01.51.03.1}{0}
A controlling node MUST NOT remove associations in order to associate itself to an association group issuing Central Scene Notification Commands.
\requirement{CL:005B.01.53.01.1}{0}
It is OPTIONAL for a controlling node to provide end user functionalities and node properties if it cannot associate itself to an association group sending Central Scene Notification Commands. (e.g. all Association Groups sending the relevant command are full)
When the end user performs this action, the issued command MUST comply with Table 6.10 for parameters numbers smaller than 256 and Table 6.11 for parameter numbers greater or equal to 256.
Table 6.10 Configuration::Set a (normal) configuration parameter value¶
Field
Value
Command
CONFIGURATION_SET
Parameter number
For version 2 or older: User defined
For version 3 or newer: User defined among supported parameter numbers.
Size
For version 2 or older: User defined among 1, 2 and 4.
For version 3 or newer: Automatically determined from configuration parameter number properties
Default
User defined or 0x00
For version 3 or older: this field SHOULD NOT be set to 1.
Command
For version 2 or older: User defined.
For version 3 or newer: User defined among supported values
Table 6.11 Configuration::Set an extended range configuration parameter value¶
Field
Value
Command (v2)
CONFIGURATION_BULK_SET
Parameter offset (v2)
For version 2: User defined among any value (256..65535).
For version 3 or newer: User defined among supported parameter numbers.
Number of Parameters (v2)
User defined or 0x01.
Size (v2)
For version 2: User defined among 1, 2 and 4.
For version 3 or newer: Automatically determined from configuration parameter number properties
Default (v2)
User defined or 0x00
For version 3 or older: this field SHOULD NOT be set to 1.
Handshake (v2)
0x00
Configuration Value (v2)
For version 2: User defined.
For version 3 or newer: User defined among supported values
6.2.8.2.2. Reset all configuration parameter values to default¶
\requirement{CL:0070.04.31.01.1}{0}
When the end user performs this action, the issued command MUST comply with Table 6.12.
Table 6.12 Configuration::Reset all configuration parameter values to default¶
If nodes are version 3, the controlling node MUST have a UI allowing the end user to see supported parameter numbers, their current value, their allowed value range and their default value.
Values MUST be presented according to the Format advertised in the Configuration Properties Report Command.
\requirement{CL:0070.01.41.01.1}{0}
If nodes are version 1 or 2, the controlling node MUST have a UI showing the known parameters that have been set by the end user and their current value.
If nodes are version 4, a node controlling this command class MUST NOT issue a Bulk Set Command supporting nodes advertising “No Bulk support” in the Configuration Properties Report Commands.
\requirement{CL:0070.04.51.02.1}{0}
If nodes are version 4, a node controlling this command class MUST NOT allow an end user to issue a Configuration Set or a Bulk Set Command for parameters advertised as “read-only” in the Configuration Properties Report Command.
A node controlling this Command Class MUST perform a supporting node interview
according to Figure 6.11.
Figure 6.11 Entry Control Command Class interview¶
\requirement{CL:006F.01.23.01.1}{0}
A node controlling this command class MAY skip the AGI Interview (refer to
Section 6.3.2)
if the supporting node is a Z-Wave Plus node and the controlling
node has estalished a Lifeline Association.
A node controlling this command class MUST also control:
Association Command Class, version 2
Association Group Information, version 3
\requirement{CL:006F.01.51.02.1}{0}
A controlling node MUST associate itself to a group issuing Entry Control Notification Commands before performing a supporting node interview and providing end user functionalities.
\requirement{CL:006F.01.51.03.1}{0}
A controlling node MUST NOT remove associations in order to associate itself to an association group issuing Entry Control Notification Commands.
\requirement{CL:006F.01.52.01.1}{0}
A controlling node SHOULD NOT provide end user functionalities if it cannot associate itself to an association group sending Entry Control Notification Commands. (e.g. all Association Groups sending the relevant command are full)
\requirement{CL:006F.01.52.02.1}{0}
A controlling node SHOULD have a UI allowing the end user to define what actions to take based on received Entry Control Notifications.
\requirement{CL:006F.01.52.03.1}{0}
A controlling node SHOULD also control Door Lock Command Class and Barrier Operator Command Class. It SHOULD also allow the user to set the door mode or initiate opening/closing of a given node based on received Entry Control Notifications.
This action MUST be available to the end user if both nodes implement version 2 or newer and the supporting node indicates that meter reset is supported.
\requirement{CL:0032.02.31.03.1}{0}
When the end user performs this action, the issued command MUST comply with Table 6.21.
A controlling node MUST have a UI allowing the end user to see the last readings for each supported scale and all cumulated values. For version 1 supporting nodes, the scale reported in the Meter Report MUST be accessible to the end user.
\requirement{CL:0032.01.41.02.1}{0}
A controlling node MUST always show the value even if the Type and/or Scale are unknown.
\requirement{CL:0032.01.42.01.1}{0}
A controlling node SHOULD implement the capability to update its list of Meter Type and Scales, so that new Meter Types and scales added in more recent versions are not presented as unknown.
\requirement{CL:0032.01.41.03.1}{0}
If a controlling node receives an unknown Meter Type or Scale, it MUST allow the end user to identify the Meter reading and MAY allow the user to assign a free-text description to that Meter reading
Unless unsolicited Meter Report Commands are received, a controlling node MUST:
Probe the current meter readings for each supported scale (and rate type if v4 nodes) at least every 6 hours for listening nodes.
Probe the current meter readings for each supported scale (and rate type if v4 nodes) when the supporting node issues a Wake Up Notification Command for sleeping nodes.
6.2.13. Multilevel Sensor Command Class, version 1-11¶
A controlling node MUST allow the end user to see the received readings for every Sensor types
\requirement{CL:0031.01.41.02.1}{0}
A controlling node MUST always show the sensor reading values even if the Sensor Type and/or Scale are unknown.
\requirement{CL:0031.01.42.01.1}{0}
A controlling node SHOULD implement the capability to update its list of Sensor Type and Scales, so that new Sensor Types and Scales added in [28] are not presented as unknown.
\requirement{CL:0031.01.41.03.2}{0}
If a controlling node receives an unknown Sensor Type or Scale, it MUST allow the end user to identify the Sensor reading and MAY allow the end user to assign a free-text description to the sensor reading.
Unless unsolicited Multilevel Sensor Report Commands are received, a controlling node MUST:
Probe the current reading for each supported sensor type at least every 6 hours for listening nodes.
Probe the current reading for each supported sensor type when the supporting node issues a Wake Up Notification Command for sleeping nodes.
\requirement{CL:0031.01.52.01.1}{0}
A node controlling this command class SHOULD also control:
Association Command Class, version 2
Association Group Information, version 3
\requirement{CL:0031.01.52.02.1}{0}
A controlling node SHOULD associate itself to an association group issuing Multilevel Report Commands after performing a supporting node interview and providing end user functionalities.
\requirement{CL:0031.01.51.02.1}{0}
A controlling node MUST NOT remove associations in order to associate itself to an association group issuing Multilevel Report Commands.
\requirement{CL:0031.01.52.03.1}{0}
Controller SHOULD have a UI allowing the end user to define rules or commands based on received readings.
6.2.14. Multilevel Switch Command Class, version 1-4¶
A node controlling this Command Class MUST perform a supporting node interview
according to Figure 6.15. It is
OPTIONAL to issue the Multilevel Switch Supported Get Command
if a controlling node does not use this information for its UI.
Figure 6.15 Multilevel Switch Command Class interview¶
The step denoted as “1. Read Notification Type Status” in
Figure 6.16 MAY be replaced by Notification
Set commands for each Notification Type,
with the Status field set to 0x00 or 0xFF.
\requirement{CL:0071.02.23.02.1}{0}
A node controlling this command class MAY skip the AGI Interview (refer to
Section 6.3.2)
if the supporting node is a Z-Wave Plus node and the controlling
node has estalished a Lifeline Association.
A controlling node MUST probe state/event notifications from pull nodes
at least every 6 hours for listenting nodes.
when the supporting node issues a Wake up Notification Command for sleeping nodes.
\requirement{CL:0071.01.51.02.1}{0}
A node controlling this command class MUST also control:
Association Command Class, version 2
Association Group Information, version 3
\requirement{CL:0071.01.51.03.1}{0}
For Push supporting nodes, a controlling node MUST associate itself to a group issuing Notification Report Commands before performing a supporting node interview and providing end user functionalities.
\requirement{CL:0071.01.53.01.1}{0}
For Push supporting nodes, it is OPTIONAL for a controlling node to provide end user functionalities and node properties if it cannot associate itself to an association group sending Notification Report Commands. (e.g. all Association Groups sending the relevant command are full)
\requirement{CL:0071.01.51.04.1}{0}
A controlling node MUST NOT remove associations in order to associate itself to an association group issuing Notification Report Commands.
\requirement{CL:0071.01.52.01.1}{0}
Controller SHOULD have a UI allowing the end user to define rules or commands based on received notifications events/states.
\requirement{CL:0071.01.52.02.1}{0}
A controlling node SHOULD implement the capability to update its Notifications list, so that new Notifications added in [37] are not presented as unknown.
\requirement{CL:0071.01.51.05.2}{0}
If a controlling node receives an unknown Notification (a Notification advertised by the supporting node, but that has no description in the controlling node software), it MUST allow the end user to identify this notification and MAY allow the end user to assign a free-text description to that Notification.
This section presents guidelines for controlling legacy sensors nodes supporting the Notification Command Class, version 3-8.
Alarm Command Class version 2 supporting nodes operate in Push mode only. The guidelines presented in Section 6.2.15.4.1.6 Controlling Pull Mode Sensors can also be used for controlling Alarm CC version 2 supporting nodes.
The following sections present discovery methods for sensor properties,
such as Push/Pull mode or the use of state idle notifications. Some sensor properties (e.g. configuration parameters, Association group properties, state variables dependencies) cannot always be discovered.
\requirement{CL:0071.01.52.03.1}{0}
If a controlling node has a database of known certified Notification sensors, it SHOULD be consulted first before attempting to interview the Notification Command Class of a supporting node. If the supporting node is present in the database, a controlling node SHOULD read the sensor properties from the database and skip any discovery.
A supporting node does not advertise whether it operates in Push or Pull mode. Therefore a controlling node MUST discover what mode a supporting node implements.
\requirement{CL:0071.01.52.04.1}{0}
The RECOMMENDED discovery steps for a controlling node are the following:
If the supporting node does not support the Association Command Class, it may be concluded that the supporting node implements Pull Mode and discovery may be aborted.
If the supporting node supports the AGI Command Class, probe the AGI table in the following way or read the already probed AGI table:
Discover how many Association groups the supporting node (and its eventual End Points) implements by issuing an Association Supported Groupings Get Command.
For each association group, issue an Association Group Command List Get for the grouping identifier. Inspect the returned Association Group Command List Report and look for the following pair: {Command Class x = COMMAND_CLASS_NOTIFICATION, Command x = NOTIFICATION_REPORT}. If a match is found, conclude that the supporting node implements Push Mode and stop the discovery process.
If no match is found at the end of the AGI test, conclude that the supporting node implements Pull Mode. The AGI test is illustrated in Figure 6.17.
A controlling node receiving a “State idle” Notification for an event or state of which the “State idle” Notification does not apply (e.g. the “heartbeat” event) SHOULD ignore the Notification. Refer to [37] for state variables to which the “State idle” notification applies.
It is not mandatory for nodes supporting Notification Command Class, version 7 or older to send a “State idle” Notification for returning a state variable to idle. Thus, there is a risk that a “State idle” is never sent. A controlling node SHOULD NOT use timeouts to consider a state variable to be idle for example 5 minutes after the last received Notification for v8 or newer supporting nodes. It MAY allow the end user to mark states variables as idle.
A node implementing version 5 or older MAY use the following parameter encapsulation format: (User ID, User Code Report Command) instead of (User Code Report Command).
\requirement{CL:0071.01.52.08.1}{0}
A controlling node SHOULD accept the end user Code Report Event Parameter with a User ID byte prefixed at the beginning of the Notification Event Parameter for backwards compatibility. A controlling node can detect the beginning of the end user Code Report by finding the following consecutive bytes: {byte x= COMMAND_CLASS_USER_CODE, byte x+1 = USER_CODE_REPORT}.
This command is used to retrieve the next Notification from the receiving node’s queue. Below are recommendations for what values controlling nodes should set in the fields of this command.
Notification Type (8 bits)
\requirement{CL:0071.01.52.09.1}{0}
A controlling node SHOULD set the Notification Type field to 0xFF.
Earlier specification text suggested that Pull nodes must not ignore this command if the Notification Type is set to a supported type; rather than 0xFF. Therefore, Pull sensors may respond to a Notification Get for a supported Notification type by retrieving the next notification in the queue matching the specified Notification Type.
Notification Event /State (8 bits)
\requirement{CL:0071.01.52.0A.1}{0}
A controlling node SHOULD set this field to 0x00.
A receiving node will have an unpredictable behavior if this field is set to a supported Event.
6.2.15.4.1.6.2. Detecting and clearing persistent notifications¶
It is optional for Pull nodes to specify a sequence number in notifications.
\requirement{CL:0071.01.52.0B.1}{0}
A controlling node receiving twice the same Notification with identical sequence number SHOULD consider the Notification as persistent. An example is given in Figure 6.19.
Figure 6.19 Detecting and Clearing Persistent Notifications, identical sequence numbers¶
\requirement{CL:0071.01.52.0C.1}{4}
Due to unclear specification text, sensors may issue persistent Notifications without a sequence number field or with a new sequence number every time. Therefore, a controlling node SHOULD consider a notification to be persistent if it receives the same Notification (type and event/state) 5 times or more. An example is given in Figure 6.20.
Figure 6.20 Detecting and clearing persistent notifications with incremental sequence numbers¶
A controlling node SHOULD stop issuing Notification Get Commands when receiving a Queue empty notification (0xFE). Illustration is given in Figure 6.21.
\requirement{CL:0071.01.53.04.1}{0}
All fields following the Status field MAY be omitted in the Notification Report if it advertises a Status of 0xFE (queue empty).
Figure 6.21 Pull node event retrieval until receiving queue empty¶
6.2.16. Simple AV Control Command Class, version 1-4¶
The end user MUST be able to configure the volume and default tone at the supporting node. When the end user performs this action, the issued command MUST comply with Table 6.24.
Table 6.24 Sound Switch::Configure the sound switch¶
The end user MUST be able to play the default tone, play a selected tone or stop playing a tone. When the end user performs this action, the issued command MUST comply with Table 6.25.
Table 6.25 Sound Switch::Play/stop a selected or default tone¶
Field
Value
Command
SOUND_SWITCH_TONE_PLAY_SET
Tone identifier
User defined among supported tones, 0x00 and 0xFF.
The end user MUST be able to select between all supported modes by the supporting node, even if the controlling node does not know what a given mode represents.
A node controlling this command class MUST perform a supporting node interview according to Figure 6.26.
Figure 6.26 Thermostat Setpoint Command Class interview¶
It has been found that early implementations of this Command Class applied two non-interoperable interpretations of the bit mask advertising the support for specific Setpoint Types in the Thermostat Setpoint Supported Report Command.
Refer to the Thermostat Setpoint Command Class definition (Section 2.2.116, Section 2.2.117) for the possible bitmask interpretations.
\requirement{CL:0043.01.22.01.1}{0}
A controlling node SHOULD determine the supported Setpoint Types of a version 1 and version 2 supporting node by sending one Thermostat Setpoint Get Command at a time while incrementing the requested Setpoint Type.
\requirement{CL:0043.01.21.03.1}{0}
If the same Setpoint Type is advertised in the returned Thermostat Setpoint Report Command, the controlling node MUST conclude that the actual Setpoint Type is supported.
\requirement{CL:0043.01.21.04.1}{4}
If the Setpoint Type 0x00 (type N/A) is advertised in the returned Thermostat Setpoint Report Command, the controlling node MUST conclude that the actual Setpoint Type is not supported.
When the end user performs this action, the issued command MUST comply with Table 6.28.
Table 6.28 Thermostat Setpoint::Change setpoint for a supported type¶
Field
Value
Command
THERMOSTAT_SETPOINT_SET
Setpoint Type
User defined among supported
Setpoint Value
If nodes are version 3 or newer: User defined among supported values
If nodes are version 1 or 2: User defined.
Precision
Controller defined
Scale
Controller defined
Size
Controller defined
\requirement{CL:0043.01.31.03.1}{0}
If controlling a version 1 or 2 supporting node, the controlling node MUST allow the user to define the Setpoint Value freely. The controlling node MUST read back the value with a Thermostat Mode Get(Setpoint type) or use Supervision Get encapsulation and indicate to the end user if the operation was successful.
\requirement{CL:0043.01.31.04.1}{0}
The end user MUST be able to set the setpoint for any setpoint type, even if the controlling node does not know what a given type represents.
\requirement{CL:0043.01.31.05.1}{0}
The Precision, Scale and Size field values MUST be identical to one of the combinations received in a Thermostat Setpoint Report or Thermostat Setpoint Capabilities Report for the actual Setpoint Type, either during the node interview or later.
\requirement{CL:0043.01.31.06.1}{0}
Setpoint values that cannot be represented using a supported combination of Precision and Size MUST be rounded to match.
\requirement{CL:0043.01.42.01.1}{0}
The controlling node SHOULD let the user define the Setpoint Value in their preferred scale but MUST convert the value into the supporting node’s scale for issuing the Z-Wave Command.
It is OPTIONAL to send an Extended User Code Get Command
for every User Identifier to a node supporting version 2 or newer if:
The controlling node requested the checksum and it is set to 0, or
The controlling node issues an Extended User Code Set Command
(User ID = 0, User ID Status = 0) to delete all user codes, or
The supporting node reports that no more User Identifiers are set in the
Extended User Code Report Command with the
Next User Identifier field.
It is OPTIONAL to send a User Code Get Command for every
User Identifier to a node supporting version 1 if the controlling node issues
a User Code Set Command (User ID = 0, User ID Status = 0)
to delete all user codes.
\requirement{CL:0063.01.21.03.1}{0}
For a node controlling version 1:
It is OPTIONAL to send a User Code Get Command for every
User Identifier to any supporting node if the controlling node issues a
User Code Set Command (User ID = 0, User ID Status = 0)
to delete the user codes below User ID 256.
\requirement{CL:0063.01.22.01.1}{0}
A controlling node SHOULD NOT automatically delete any user code unless it is
the initial interview right after having included the supporting node in the
network.
User defined or controlling node defined among supported User Identifiers.
User ID Status
User defined among 0x01 and 0x02
0x02 must be used to set a reserved/forbidden user code.
User Code
User defined among 0x30..0x39 with a length in the range 4..10 bytes.
A forbidden or reserved User Code is a User Code that cannot be used at the supporting node and cannot be allocated to a new user, for example if User Code can also be updated locally via a user interface.
This action MUST be available to the end user if nodes are v2 or newer and the supporting node supports more than one keypad mode. When the end user performs this action, the issued command MUST comply with Table 6.33.
This action MUST be available to the end user if nodes are v2 or newer and the
supporting node supports the Admin Code functionality.
When the end user performs this action, the issued command MUST
comply with Table 6.34.
It has been found that some version 1 nodes wrongfully report obfuscated User Codes in the User Code Report (e.g. ‘******’).
\requirement{CL:0063.01.52.01.1}{0}
A controlling node SHOULD understand that a code has been set correctly but cannot be read back with such nodes.
\requirement{CL:0063.01.52.02.1}{0}
If nodes are version 2 or newer, a controlling node SHOULD verify the User Code checksum (if supported) periodically (e.g. once a day) to ensure that User Code databases are synchronized.
6.2.22. User Credential Command Class, version 1-2¶
are cumulatively referred to as the User Management Command Classes.
While they are related in purpose, they differ drastically in scope and implementation and can be challenging to securely operate together on a supporting node.
Nodes that advertise support for both of these command classes for backwards compatibility purposes can opt to support both simultaneously so that their Users, Credentials and User Codes
coexist in a shared database, or they can opt to migrate support from User Credentials to User Codes, and vice versa, based on the capabilities of the controlling node.
If a controlling node controls both the User Credential Command Class and the User Code Command Class, and a supporting node advertises support for both as well, then the following apply:
\requirement{CL:0083.01.21.00.2}{0}
The controlling node MUST only use ONE of the User Management Command Classes to control a supporting node, and cache which User Management CC is used for each node.
\requirement{CL:0083.01.23.00.3}{0}
The Command Class used is node-specific - a controlling node MAY use User Code CC to control one node on the network and User Credential to control another.
\requirement{CL:0083.01.21.00.4}{0}
The controlling node MUST use User Credential Command Class, version 1 to control a supporting node unless the supporting node reports that (0) Users are supported.
Figure 6.28 User Management Interview::User Credential¶
At this point, if there are User slots available on the supporting node (signified with at least one (1) supported User in the Credential Capabilities Report Command),
then the controlling node stops the interview here, skips User Code, and moves on to the next CC to interview.
However, certain nodes may currently be storing User Codes and will require migration of those User Codes to Users and PIN codes - for example, when the supporting node had already been included in the network and the original interviewing node ONLY supports User Code CC.
This is signified to any interviewing node by reporting a ‘0’ for the number of supported Users in the User Capabilities Report Command.
\requirement{CL:0083.01.21.00.6}{0}
A controlling node MUST NOT control the User Code on a supporting node that otherwise supports User Credential unless no Users are currently supported on the supporting node.
If a supporting node only supports one User Management CC, then the controlling node need only interview the CC using the process described in the ‘Mandatory Interview’ section of that CC’s control specification.
If the supporting node does not support the All Users Checksum Get Command,
or if it does and the All Users Checksum field of the All Users Checksum Report Command
is non-zero, the controlling node SHOULD perform an interview of the existing Users and Credentials (and schedules, if User Schedules are supported by the node)
according to Figure 6.31.
Figure 6.31 User Credential Command Class optional interview¶
Controlling node defined as Add (0x00) or Modify (0x01).
User Unique Identifier
User defined or controlling node defined among supported User Identifiers in the range of
what was specified as supported in the User Capabilities Report Command.
User defined or controlling node defined among the Supported Credential Rules as specified
in the User Capabilities Report Command.
Expiring Timeout Minutes
User defined or controlling node defined. This MUST be non-zero if the User Type is
Expiring User (0x07) and MUST be zero if the User Type is not Expiring User (0x07).
Controlling node defined based on the length of the User Name.
User Name
User defined or controlling node defined among supported User Name Encoding characters and
User Name Length.
\requirement{CL:0083.01.33.06.1}{0}
\requirement{CL:0083.01.32.07.1}{4}
\requirement{CL:0083.01.31.08.1}{8}
A controlling node MAY offer the User Types under different names. If they are renamed they SHOULD
be accompanied by a description, and the name mapping MUST be noted in the product documentation.
\requirement{CL:0083.01.31.09.1}{0}
If a controlling node does not offer all User Types, it MUST make note of which User Types are not
controlled in the product documentation.
\requirement{CL:0083.01.31.10.1}{0}
If a controlling node does not offer all Credential Rules, it MUST make note of which Credential
Rules are not controlled in the product documentation.
User defined or controlling node defined among supported User Identifiers in the range of
what was specified as supported in the User Capabilities Report Command.
User Type
Omitted or controlling node defined as the default value.
User Active State
Omitted or controlling node defined as the default value.
Credential Rule
Omitted or controlling node defined as the default value.
Expiring Timeout Minutes
Omitted or controlling node defined as the default value.
User Name Encoding
Omitted or controlling node defined as the default value.
User Name Length
Omitted or controlling node defined as the default value.
User Name
Omitted or controlling node defined as the default value.
\requirement{CL:0083.01.33.12.1}{0}
\requirement{CL:0083.01.31.13.1}{4}
A controlling node MAY allow the end user to erase all Users and their associated Credentials and
schedules at once. In this case, the User Unique Identifier field MUST be set to 0x0000.
\requirement{CL:0083.01.31.33.1}{0}
If Schedules are supported by the node, all of the User’s Schedule slots MUST be cleared when the User is deleted.
When the end user performs this action, the issued command MUST comply with Table 6.37.
Table 6.37 User Credential::Add/Modify a Credential¶
Field
Value
Command
CREDENTIAL_SET (0x0A)
User Unique Identifier
User defined or controlling node defined among supported User Identifiers in the range of
what was specified as supported in the User Capabilities Report Command.
User defined or controlling node defined in the range of one to the Number of Supported
Credential Slots for the given Credential Type in the Credential Capabilities Report Command.
Operation Type
Controlling node defined as Add (0x00) or Modify (0x01).
Credential Length
Controlling node defined based on the length of the Credential Data. MUST not be less than
the Min Length of Credential Data for the specific Credential Type specified in the Credential Capabilities Report Command
and MUST not be more than the Max Length of Credential Data for the specific Credential Type
specified in the Credential Capabilities Report Command.
Credential Data
User defined.
\requirement{CL:0083.01.33.15.1}{0}
A controlling node MAY infer the Credential Type from the Credential Data provided by the end user.
\requirement{CL:0083.01.31.16.1}{0}
If a controlling node does not offer all Credential Types, it MUST make note of which Credential
Types are not controlled in the product documentation.
User defined or controlling node defined among supported User Identifiers in the range of
what was specified as supported in the User Capabilities Report Command.
User defined or controlling node defined in the range of one to the Number of Supported
Credential Slots for the given Credential Type in the Credential Capabilities Report Command.
Operation Type
Controlling node defined as Delete (0x02).
Credential Length
Zero or controlling node defined.
Credential Data
Omitted or User defined.
\requirement{CL:0083.01.33.18.1}{0}
\requirement{CL:0083.01.31.19.1}{4}
A controlling node MAY allow the end user to erase all Credentials of a Credential Type for a User
Unique Identifier at once. In this case, the User Unique Identifier and Credential Type MUST be
non-zero and the Credential Slot MUST be 0x0000.
\requirement{CL:0083.01.33.20.1}{0}
\requirement{CL:0083.01.31.21.1}{4}
A controlling node MAY allow the end user to erase all Credentials of all Credential Types for a
User Unique Identifier at once. In this case, the User Unique Identifier MUST be non-zero and the
Credential Type MUST be 0x00.
\requirement{CL:0083.01.33.22.1}{0}
\requirement{CL:0083.01.31.23.1}{4}
A controlling node MAY allow the end user to erase all Credentials for all Users at once. In this
case, the User Unique Identifier MUST be 0x0000.
\requirement{CL:0083.01.33.24.1}{0}
\requirement{CL:0083.01.31.25.1}{4}
A controlling node MAY allow the end user to erase all Credentials for a Credential Type at once.
In this case, the User Unique Identifier and Credential Slot MUST be 0x0000 and the Credential Type
MUST be non-zero.
This action MUST be available to the end user if the supporting
node supports the Admin PIN Code functionality.
When the end user performs this action, the issued command MUST
comply with Table 6.39.
Table 6.39 User Credential::Set the Admin PIN Code¶
Field
Value
Command
ADMIN_PIN_CODE_SET (0x1A)
Admin PIN Code Length
0 for Admin PIN Code deactivation, else in accordance with the Min..Max Credential Length of Credential Type PIN Code.
It MUST be possible to de-activate the Admin PIN Code if the supporting node
supports Admin Code Deactivation.
Admin PIN Code
User defined among supported ASCII characters (digits 0..9) with a length in the range 4..10 bytes.
Zero length if deactivating the Admin PIN Code.
Controlling node defined as Add (0x00) or Modify (0x01). See Table 2.570.
Entry Length
A value in the range of ‘Min. Length of Entry Data’ to ‘Max. Length of Entry Data’ for the given Entry Type, inclusive (see Key Locker Capabilities Report Command).
A controlling node MUST have a UI allowing the end user to see the following properties:
The list of Users and their basic properties:
The User Name
The User Active State
The Credentials assigned to a User and their basic properties:
The Credential Type
If Scheduling is supported by the node:
Whether Schedules for the User are active or inactive
\requirement{CL:0083.01.42.27.1}{0}
A controlling node SHOULD have a UI allowing the end user to see the following properties:
The number of supported User Unique Identifiers
The supported Credential Rules (Single, Dual, Triple)
The supported Credential Types
The list of Users and their additional properties:
The User Unique Identifier
The User Type
The Credential Rule
The Expiring Timeout Minutes, if the User Type is Expiring User (0x07)
The Credentials assigned to a User and their additional properties:
The Credential Slot
The Credential Data
If Scheduling is supported by the node:
Which Schedule slots are in use for the User
the Schedule data for each occupied slot
If the node supports User Credential Command Class, version 2:
The supported Key Locker Entry Types
The number of Key Locker Entry Slots
The minimum and maximum length of Key Locker Entry data
The list of Key Locker Entries
The Entry Report Type
The Entry Type
The Entry Slot
Whether the Entry Slot contains data or is empty
\requirement{CL:0083.01.41.28.1}{0}
A node controlling this command class MUST also control the Notification Command Class, version 8 or newer and have a
UI allowing the end user to see Notification Reports with the following Notification Types.
Notification Type “Access Control” (0x06)
“Credential lock/close operation” (0x23)
“Credential unlock/open operation” (0x24)
“Valid credential access denied due to User Active State being set to Occupied Disabled” (0x2F)
“Valid credential access denied due to the User’s schedule being inactive” (0x30)
“User access denied due to not enough credentials entered for the User’s Credential Rule” (0x31)
“Invalid credential used to access the node” (0x32)
“Non-Access credential entered via local interface” (0x33)
If the supporting node supports the All Users Checksum Report Command,
the controlling node SHOULD verify the All Users Checksum periodically (e.g. once a day) to ensure
that the Users and Credentials are synchronized between the supporting and controlling nodes.
This action MUST be available to the end user for parameters ID with known positions (odd parameters IDs). When the end user performs this action, the issued command MUST comply with Table 6.42.
This action MUST be available to the end user for all supported parameters ID. When the end user performs this action, the issued command MUST comply with Table 6.43.
Table 6.43 Window Covering::Start Level Change Up or Down¶
This action MUST be available to the end user for all supported parameters ID. When the end user performs this action, the issued command MUST comply with Table 6.44.
A controlling node MUST NOT interview and provide controlling functionalities for the Multilevel Switch Command Class for a node (or endpoint) supporting this Command Class, as it is a fully redundant and less precise application functionality.
