6.3. Management Command Class Control Definitions¶
6.3.1. Association Command Class, version 1-4¶
6.3.1.1. Mandatory Node interview¶
\requirement{CL:0085.01.21.01.1}{0}
A node controlling this command class MUST perform a supporting node interview according to Figure 6.33.
Figure 6.33 Association Command Class interview¶
6.3.1.2. Minimum End User functionalities¶
No minimum end user functionality is required for this Command Class.
\requirement{CL:0085.01.31.01.1}{4}
A controlling node implementing a UI that allows an end user to establish association between nodes MUST NOT restrict the end user from establishing associations that are allowed. Refer to Section 6.3.1.4 for allowed associations.
6.3.1.3. Node properties¶
No node property is required to be made available to the end user for this Command Class.
6.3.1.4. Additional Control requirements¶
\requirement{CL:0085.01.51.01.1}{4}
If the supporting node also supports Multi Channel Association and the controlling node controls Multi Channel Association, the controlling node MUST interview and control the Multi Channel Association Command Class instead of this Command Class.
\requirement{CL:0085.01.51.02.1}{0}
A controlling node MUST use the Association Group Information (AGI) Command Class to probe the commands that a given association group will be sending before creating associations towards other nodes.
If an association group in a Node A sends one or more controlling commands:
\requirement{CL:0085.01.51.03.3}{0}
A controlling node MUST NOT associate Node A to a Node B destination that does not support the Command Class that the Node A will be controlling.
\requirement{CL:0085.01.53.01.3}{0}
A controlling node MAY create an association to a destination supporting an actuator Command Class if the actual association group sends Basic Control Command Class.
For Association version 1 and version 2:
\requirement{CL:0085.01.51.04.3}{0}
A controlling node MUST NOT associate Node A to a Node B destination if Node A and Node B’s highest Security Class are not identical.
For Association version 3 or newer:
\requirement{CL:0085.03.51.01.1}{0}
A controlling node MUST NOT associate Node A to a Node B destination if Node A was not granted Node B’s highest Security Class.
If an association group in Node A sends only supporting commands:
\requirement{CL:0085.01.53.02.3}{0}
A controlling node MAY create an association to any Node B destination if the actual association group sends commands reflecting the support of a Command Class by the sending Node/End Point. Refer to [26] for supporting/controlling commands.
\requirement{CL:0085.01.51.06.1}{0}
A controlling node MUST NOT associate Node A to a Node B destination if Node B was not granted Node A’s highest Security Class.
6.3.1.4.1. Removing associations¶
\requirement{CL:0085.01.51.05.1}{0}
A controlling node MUST NOT remove already associated nodes to a destination Group to associate themselves, unless:
The destination NodeID/Endpoint has left the network (i.e. SIS has received a Device Reset Locally Notification)
The destination of a group has changed capabilities and does not support the command received via the association group (also if a Multi Channel End Point is removed).
An end user has actively confirmed to remove associations
The lifeline group is full and the controlling node has the SIS Role.
6.3.2. Association Group Information (AGI) Command Class, version 1-3¶
6.3.2.1. Mandatory node interview¶
\requirement{CL:0059.01.21.01.1}{0}
A node controlling this command class MUST perform a supporting node interview according to Figure 6.34.
Figure 6.34 Association Group Information (AGI) Command Class interview¶
\requirement{CL:0059.01.23.01.1}{0}
A controlling node MAY issue a single Association Group Info Get Command by using the List Mode flag.
6.3.2.2. Minimum end user functionalities¶
No minimum end user functionality is required for this Command Class.
6.3.2.3. Node properties¶
No node property is required to be made available to the end user for this Command Class.
6.3.3. Battery Command Class, version 1¶
6.3.3.1. Mandatory node interview¶
\requirement{CL:0080.01.21.01.1}{0}
A node controlling this command class MUST perform a supporting node interview according to Figure 6.35
Figure 6.35 Battery Command Class interview¶
6.3.3.2. Minimum end user functionalities¶
No minimum end user functionality is required for this Command Class.
6.3.3.3. Node properties¶
\requirement{CL:0080.01.41.01.1}{0}
A controlling node MUST allow the end user to see the last known battery level.
6.3.3.4. Additional control requirements¶
\requirement{CL:0080.01.52.01.1}{0}
Unless unsolicited Battery Report Commands are received, a controlling node SHOULD Probe the current battery level at least every month
\requirement{CL:0080.01.51.02.1}{0}
A controlling node MUST indicate to the end user that the battery needs to be replaced or reloaded when the supporting node issues a Battery Report with the Battery Level field set to 0xFF.
6.3.4. Device Reset Locally Command Class, version 1¶
6.3.4.1. Mandatory node interview¶
No mandatory node interview is required for this Command Class.
6.3.4.2. Minimum end user functionalities¶
No minimum end user functionality is required for this Command Class.
6.3.4.3. Node properties¶
No node property is required to be made available to the end user for this Command Class.
6.3.4.4. Additional control requirements¶
\requirement{CL:005A.01.52.01.1}{0}
A controlling node receiving the Device Reset Locally Notification Command SHOULD consider the sending node to be a failing node and accordingly perform relevant maintenance operations like removing failing nodes, removing associations to failing nodes, etc.
\requirement{CL:005A.01.51.01.1}{0}
A controlling node receiving the Device Reset Locally Notification Command MUST indicate to the end user that the node has been reset and left the Z-Wave network.
6.3.5. Firmware Update Meta Data Command Class, version 1-6¶
6.3.5.1. Mandatory node interview¶
\requirement{CL:007A.01.21.01.1}{0}
A node controlling this command class MUST perform a supporting node interview according to Figure 6.36.
Figure 6.36 Firmware Update Meta Data Command Class interview¶
6.3.5.2. Minimum end user functionalities¶
6.3.5.2.1. Firmware update¶
\requirement{CL:007A.01.32.01.1}{0}
A controlling node SHOULD provide a method for updating the firmware of a supporting node. The end user SHOULD be able to select a firmware file or ask the controller to look for updates automatically.
\requirement{CL:007A.01.31.01.1}{0}
If this functionality is available, the issued commands MUST comply with Figure 6.37 when the end user performs this action.
\requirement{CL:007A.01.33.01.1}{0}
A controlling node MAY use additional commands such as Firmware Update Activation Set Command for the firmware update.
Figure 6.37 Firmware Update Meta Data::Firmware Update¶
\requirement{CL:007A.01.32.02.1}{0}
If a controlling node allows the end user to interrupt an ongoing firmware update transfer, it SHOULD issue a FIRMWARE_UPDATE_MD_REPORT Command with the Last field set to 1 prematurely.
6.3.5.3. Node properties¶
No node property is required to be made available to the end user for this Command Class.
\requirement{CL:007A.01.42.01.1}{0}
A controlling node SHOULD have a UI allowing the end user to see the Firmware version of a supporting node.
6.3.5.4. Additional control requirements¶
\requirement{CL:007A.01.52.01.1}{4}
If the supporting node supports Battery Command Class and the controlling node controls Battery Command Class, the controlling node SHOULD issue a Battery Get and read the battery level before initiating a Firmware Update.
\requirement{CL:007A.01.52.02.1}{0}
A controlling node SHOULD NOT initiate a Firmware Update if the supporting node Battery level is less than 50%.
\requirement{CL:007A.01.51.01.1}{0}
A controlling node MUST perform a full interview of a node after performing a firmware update.
6.3.6. Indicator Command Class, version 1-3¶
6.3.6.1. Mandatory node interview¶
\requirement{CL:0087.01.21.01.1}{0}
A node controlling this Command Class MUST perform a supporting node interview according to Figure 6.38.
Figure 6.38 Indicator Command Class interview¶
6.3.6.2. Minimum end user functionalities¶
\requirement{CL:0087.01.31.01.1}{0}
A node controlling this command class MUST allow the end user to perform the actions described below.
6.3.6.2.1. Identify¶
\requirement{CL:0087.01.31.02.1}{0}
If the supporting and controlling nodes are version 3 or newer, the end user MUST be able to instruct the node to identify itself. When the end user performs this action, the issued command MUST comply with Table 6.45.
Field |
Value |
|---|---|
Command |
INDICATOR_SET |
Indicator 0 Value |
0x00 |
Indicator object count |
0x03 |
Indicator ID 1 |
0x50 |
Property ID 1 |
0x03 |
Value 1 |
0x08 |
Indicator ID 2 |
0x50 |
Property ID 2 |
0x04 |
Value 2 |
0x03 |
Indicator ID 3 |
0x50 |
Property ID 3 |
0x05 |
Value 3 |
0x06 |
The supporting node will be switched on 600ms and switched off 200ms three times.
\requirement{CL:0087.01.33.01.1}{0}
A controlling node MAY hide this functionality away from the end user if the supporting node also supports the Wake Up Command Class.
6.3.6.3. Node properties¶
\requirement{CL:0087.01.42.01.1}{0}
The controlling node SHOULD have a UI allowing the end user to see/access the following properties:
Last known Indicators’ state/value (ON/OFF or x%), if any
6.3.6.4. Additional control requirements¶
\requirement{CL:0087.01.51.01.1}{0}
A node controlling this command class MUST NOT reuse the identify command for any other purpose than a node identification application.
\requirement{CL:0087.01.52.01.3}{0}
A node controlling this Command Class SHOULD NOT make a supporting node blink 3 times for any indication (except when using the Identify Indicator for the Identify purpose).
\requirement{CL:0087.01.52.02.1}{0}
A node controlling this Command Class SHOULD allow the end user to actuate additional indicating resources.
6.3.7. Multi Channel Association Command Class, version 2-5¶
6.3.7.1. Mandatory node interview¶
\requirement{CL:008E.01.21.01.1}{0}
A node controlling this command class MUST perform a supporting node interview according to Figure 6.39.
Figure 6.39 Multi Channel Association Command Class interview¶
\requirement{CL:008E.01.21.02.2}{0}
The lifeline association MUST be an End Point Association (controller NodeID after the MULTI_CHANNEL_ASSOCIATION_SET_MARKER) if:
Both nodes implement Multi Channel Association, version 3 or newer.
The supporting node also supports the Multi Channel Command Class.
\requirement{CL:008E.01.22.01.1}{0}
The lifeline association SHOULD be a NodeID association in any other case.
6.3.7.2. Minimum end user functionalities¶
No minimum end user functionality is required for this Command Class.
\requirement{CL:008E.01.31.01.1}{0}
A controlling node implementing a UI which allows an end user to establish association between nodes MUST NOT restrict the end user from establishing associations that are allowed. Refer to Section 6.3.7.4 for allowed associations.
6.3.7.3. Node properties¶
No node property is required to be made available to the end user for this Command Class.
6.3.7.4. Additional control requirements¶
\requirement{CL:008E.01.51.01.1}{4}
If the supporting node also supports Association and the controlling node controls Association, the controlling node MUST NOT interview and control the Association Command Class.
\requirement{CL:008E.01.51.02.1}{0}
A controlling node MUST use the Association Group Information (AGI) Command Class to probe the commands that a given association group will be sending before creating associations towards other nodes.
If an association group in a Node A sends one or more controlling commands:
\requirement{CL:008E.01.51.03.3}{0}
A controlling node MUST NOT associate Node A to a Node B destination that does not support the Command Class that the Node A will be controlling.
\requirement{CL:008E.01.53.01.3}{0}
A controlling node MAY create an association to a destination supporting an actuator Command Class if the actual association group sends Basic Control Command Class.
For Multi Channel Association version 2 and version 3:
\requirement{CL:008E.02.51.01.1}{0}
A controlling node MUST NOT associate Node A to a Node B destination if Node A and Node B’s highest Security Class are not identical.
For Multi Channel Association version 4 or newer:
\requirement{CL:008E.04.51.01.1}{0}
A controlling node MUST NOT associate Node A to a Node B destination if Node A was not granted Node B’s highest Security Class.
If an association group sends only supporting commands:
\requirement{CL:008E.01.53.02.2}{0}
A controlling node MAY create an association to any destination if the actual association group sends commands reflecting the support of a Command Class by the sending Node/End Point. Refer to [26] for supporting/controlling commands.
\requirement{CL:008E.01.51.06.1}{0}
A controlling node MUST NOT associate Node A to a Node B destination if Node B was not granted Node A’s highest Security Class.
6.3.7.4.1. Removing associations¶
\requirement{CL:008E.01.51.05.1}{0}
A controlling node MUST NOT remove already associated nodes to a destination Group to associate themselves, unless:
The destination NodeID/Endpoint has left the network (i.e. SIS has received a Device Reset Locally Notification)
The destination has changed capabilities and does not support the command received via the association group (also if a Multi Channel End Point is removed).
An end user has actively confirmed to remove associations
The lifeline group is full and the controlling node has the SIS Role.
6.3.8. Time Command Class, version 1-3¶
6.3.8.1. Mandatory node interview¶
\requirement{CL:008A.01.21.01.2}{0}
A node controlling this command class is RECOMMENDED to perform a supporting node interview for any node using Version 3 of Time Command Class to identify the Time Source field.
6.3.8.2. Minimum end user functionalities¶
No minimum end user functionality is required for this Command Class.
6.3.8.3. Node properties¶
No node property is required to be made available to the end user for this Command Class.
6.3.8.4. Additional control requirements¶
\requirement{CL:008A.01.52.01.1}{0} \requirement{CL:008A.01.52.02.1}{4} \requirement{CL:008A.01.52.03.1}{8}
Time Command Class end devices SHOULD request the current local time upon initial inclusion into a network and SHOULD repeatedly request the time based on the stability of their real-time-clock hardware. Typically this will be once per day. A controlling node with access to a localized time source (typically the primary controller) SHOULD send a Time Report to any end device that has not requested the time in the last day or two and at any daylight savings time changes.
6.3.9. Version Command Class, version 1-4¶
6.3.9.1. Mandatory node interview¶
\requirement{CL:0086.01.21.01.2}{0}
A node controlling this command class MUST perform a supporting node interview according to Figure 6.40.
Figure 6.40 Version Command Class interview¶
\requirement{CL:0086.01.21.02.1}{0}
The interview part starting from the Version Capabilities Get Command is optional. The Controlling node MUST interview the Version Capability Get Command before issuing the Version Z-Wave Software Get Command if the Controlling node has the intent of using the Z-Wave software version.
If a node supports Version Command Class, version 4:
\requirement{CL:0086.01.21.03.1}{0}
After the mandatory interview, and if Migration is advertised as supported in the Version Capabilities Report, the controlling node MUST also query the migration capabilities of the node according to Figure 6.41.
Figure 6.41 Version Migration Capabilities interview¶
6.3.9.2. Minimum end user functionalities¶
No minimum end user functionality is required for this Command Class.
6.3.9.3. Node properties¶
No node property is required to be made available to the end user for this Command Class.
6.3.9.4. Additional control requirements¶
\requirement{CL:0086.01.51.01.1}{0}
A controlling node interviewing a Multi Channel End Point MUST request the End Point’s Command Class version from the Root Device if the End Point does not advertise support for the Version Command Class.
6.3.10. Wake-Up Command Class, version 1-2¶
6.3.10.1. Mandatory node interview¶
\requirement{CL:0084.01.23.01.1}{0} \requirement{CL:0084.01.21.01.2}{4}
If the controlling node has the inclusion controller or secondary controller role in a network, it MAY skip the node interview. In any case, it MUST NOT issue a Wake-Up Interval Set to a supporting node.
\requirement{CL:0084.01.21.02.1}{0}
If the controlling node has the SIS or primary controller role in a network, it MUST perform a supporting node interview according to Figure 6.42.
Figure 6.42 Wake Up Command Class interview¶
\requirement{CL:0084.01.21.03.1}{0}
A controlling node MUST set a supported Wake Up Interval time value when commissioning a version 2 supporting node.
\requirement{CL:0084.01.21.04.1}{0}
A controlling node MUST set its own NodeID as the Wake-Up destination.
6.3.10.2. Minimum end user functionalities¶
No minimum end user functionality is required for this Command Class.
6.3.10.3. Node properties¶
No node property is required to be made available to the end user for this Command Class.
\requirement{CL:0084.01.42.01.1}{0}
A controlling node queuing commands for a Wake-Up node SHOULD indicate to the end user that the commands will be transmitted when the destination wakes up again.
\requirement{CL:0084.01.43.01.1}{0}
A controlling node MAY show to the end user the expected time until the next Wake Up, except when the Wake Up Interval is set to zero (i.e. the node will not wake up regularly).
6.3.10.4. Additional control requirements¶
\requirement{CL:0084.01.52.01.1}{0}
A controlling node SHOULD verify that the Wake Up Interval Set Command executed successfully by either using Supervision encapsulation or reading back the Wake Up Interval settings.
\requirement{CL:0084.01.52.02.1}{0}
If the Wake Up Interval Set Command was ignored by a version 1 supporting node, the controlling node SHOULD try again using the currently defined interval at the supporting node and its NodeID.
\requirement{CL:0084.01.52.03.1}{0}
A controlling node SHOULD read the Wake Up Interval of a supporting node when the delays between Wake Up periods are larger than what was last set at the supporting node. This does not apply when the Wake Up Interval has been set to zero (i.e. the supporting node will not wake up regularly).
