• Revision: v1.1

  • Revision Date: 2023-09-12

  • Prepared By: Mesh Working Group

Revision History

Revision Number

Date

Comments

v1.0

2017-07-13

Adopted by the Bluetooth SIG Board of Directors

v1.0.1

2019-01-21

Adopted by the Bluetooth SIG Board of Directors

v1.1

2023-09-12

Adopted by the Bluetooth SIG Board of Directors.

Version History

Versions

Changes

v1.0.0 to v1.0.1

Incorporated errata E9701, E9719, E9810, E9959, E9960, E9989, E9990, E10050, E10069, E10199, E10287, E10327, E10333, E10434, E10435, E10436, E10437, E10438, E10439, E10440, E10455, E10474, E10475, E10640, E10655, E10666, E10667, E10678, E10727, E10740, E10801, E10816, E10862, E10867, E10895, E10898, E11305

v1.0.1 to v1.1

Incorporated the Mesh Model Minor Enhancements CR.

Incorporated errata E10903, E10950, E10974, E11148, E11149, E11263, E11277, E11278, E11279, E11291, E11343, E11345, E11350, E11361, E11367, E11370, E11372, E11448, E11631, E11664, E11713, E11734, E11759, E11771, E11805, E11881, E11907, E11937, E11942, E11960, E11993, E12090, E12091, E12146, E12256, E12258, E12282, E12328, E12371, E12494, E12572, E12687, E12688, E12835, E12906, E12907, E13011, E13093, E13269, E13288, E13334, E13410, E13487, E13499, E13507, E13509, E13510, E13529, E13541, E13558, E13560, E14733, E14744, E14798, E14822, E14843, E14976, E14978, E15015, E15057, E15125, E15141, E15207, E15209, E15279, E15430, E15439, E15470, E15483, E15484, E15512, E15655, E15665, E15716, E15865, E15886, E15922, E15923, E16106, E16130, E16154, E16223, E16227, E16302, E16349, E16399, E16400, E16472, E16555, E16579, E16640, E16641, E16666, E16762, E16777, E16783, E16818, E16820, E16821, E16844, E16845, E16848, E16872, E16987, E17092, E17156, E17160, E17204, E17207, E17280, E17362, E17370, E17416, E17418, E17537, E17613, E17672, E17677, E17776, E17915, E17953, E18035, E18036, E18037, E18127, E18136, E18160, E19117, E19121, E19249, E20364, E20397, E20433, E20434, E20435, E22651, E22767, E22829, E22980, E22983, E23134, E23160

Acknowledgments

Name

Company

Robin Heydon

Cambridge Silicon Radio

Robin Heydon

Qualcomm Technologies International, Ltd.

Jonathan Tanner

Cambridge Silicon Radio

Jonathan Tanner

Qualcomm Technologies International, Ltd.

Victor Zhodzishsky

Broadcom Corporation

Wei Shen

Ericsson AB

Bogdan Alexandru

NXP Semiconductors N.V., formerly of Freescale Semiconductor, Inc.

Martin Turon

Google Inc.

Robert D. Hughes

Intel Corporation

Marcel Holtmann

Intel Corporation

Simon Slupik

Silvair, Inc.

Piotr Winiarczyk

Silvair, Inc.

Danilo Blasi

STMicroelectronics

Yao Wang

Barrot Technology Co., Ltd.

Rustam Kovyazin

Motorola Solutions

Elaine Mar

California Eastern Laboratories

Gerard Harbers

Xicato, Inc.

Clive Feather

Samsung Electronics Co., Ltd.

Omkar Kulkarni

Nordic Semiconductor ASA

Victor Zhodzishsky

Cypress Semiconductor Corporation

Hannu Mallat

Silicon Laboratories

Max Palumbo

Silicon Laboratories

Max Palumbo

Katerra Inc.

Luca Zappaterra

Signify Netherlands B.V.

Laurence Richardson

Qualcomm Technologies International, Ltd.

Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.

Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”

Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.

Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.

Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.

Copyright © 2015–2023. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.

1. Introduction

This Mesh Model specification defines models (along with their required states and messages) that are used to define basic functionality of nodes on a mesh network.

Terms, acronyms, and abbreviations that have a specific meaning in the context of this specification or the Bluetooth environment in general are defined or expanded upon on their first use. Defined terms that are used in this specification are listed in Section 1.6. Mathematical functions that are used in this specification are defined in Appendix B: Mathematical functions.

1.1. Conformance

Each capability of this specification shall be supported in the specified manner. This specification may provide options for design flexibility, because, for example, some products do not implement every portion of the specification. For each implementation option that is supported, it shall be supported as specified.

1.2. Bluetooth specification release compatibility

This specification is compatible with Mesh Protocol v1.1 [1].

1.3. Language

1.3.1. Language conventions

In the development of a specification, the Bluetooth SIG has established the following conventions for use of the terms “shall”, “shall not”, “should”, “should not”, “may”, “must”, and “can”. In this Bluetooth specification, the terms in Table 1.1 have the specific meanings given in that table, irrespective of other meanings that exist.

Term

Definition

shall

—used to express what is required by the specification and is to be implemented exactly as written without deviation

shall not

—used to express what is forbidden by the specification

should

—used to express what is recommended by the specification without forbidding anything

should not

—used to indicate that something is discouraged but not forbidden by the specification

may

—used to indicate something that is permissible within the limits of the specification

must

—used to indicate either:

  1. an indisputable statement of fact that is always true regardless of the circumstances

  2. an implication or natural consequence if a separately-stated requirement is followed

can

—used to express a statement of possibility or capability

Table 1.1. Language conventions terms and definitions

1.3.1.1. Implementation alternatives

When specification content indicates that there are multiple alternatives to satisfy specification requirements, if one alternative is explained or illustrated in an example it is not intended to limit other alternatives that the specification requirements permit.

1.3.1.2. Discrepancies

It is the goal of Bluetooth SIG that specifications are clear, unambiguous, and do not contain discrepancies. However, members can report any perceived discrepancy by filing an erratum and can request a test case waiver as appropriate.

1.3.2. Reserved for Future Use

Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.

Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.

When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.

The acronym RFU is equivalent to Reserved for Future Use.

1.3.3. Prohibited

When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.

Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.

“Prohibited” is never abbreviated.

1.4. Architectural concepts

This specification is based on the concepts of states, bindings, messages, elements, addresses, models, and the publish-subscribe paradigm for message exchange that are defined in the Mesh Protocol specification [1].

This specification in addition provides a detailed discussion of state transitions (see Section 1.4.1) and introduces the concept of a device property as it relates to mesh models (see Section 2).

1.4.1. State transitions

A state is a value that represents a condition of an element. An element exposing a state is referred to as a server. For example, the simplest server is a Generic OnOff Server (see Section 3.3.1), which represents that the state is either on or off. An element accessing a state is referred to as a client. For example, the simplest client is a Generic OnOff Client (a binary switch) that is able to control a Generic OnOff Server via messages accepted by the Generic OnOff Server model.

States can be changed as a result of any of the following:

  • A state-changing message that is received and processed by a server

  • An asynchronous event, such as a scheduler action being executed (see Section 5.1.4)

  • A local (non-network) event such as a press of a button located on a networked lamp

A change of state may be instantaneous (e.g., a state reported by a sensor) or may take some time (e.g., a lamp that dims gradually or a motor that moves a physical object). The time that it takes for a state to change from a present state to the target state (the state that the state server is changing to) is called the transition time.

States may support non-instantaneous change using either the Generic Default Transition Time (see Section 3.1.3) or the transition time specified as a field in the state-changing message.

Messages may support a Delay parameter that indicates a delay between receiving a message and executing a behavior for this message, such as starting the state transition. This helps when synchronizing actions of multiple receivers (such as lights) when senders retransmit messages multiple times. Each retransmitted message may indicate a different delay, compensating for the time elapsed since transmitting the first message.

When publishing a message which includes a Delay field, depending on a scenario, there are recommendations on calculating the value for the Delay field:

  1. When the message is published as a result of the configured Model Publication state (see Section 4.2.3 in [1]), and when the Publish Retransmit Count (see Section 4.2.3.6 in [1]) multiplied by the retransmission interval (see Section 4.2.3.7 in [1]) is not greater than 1275 milliseconds, then the value of the Delay field for the nth message in sequence, starting from n=1, should be calculated using the formula:

    Delay[n] = [Publish Retransmit Count + 1 - n] * (Publish Retransmit Interval Steps + 1) * 50

    The messages retransmitted in the series are considered the same published message despite the changing value of the Delay field.

  2. When a series of m messages are originated by an application (see Section 3.7.3.1 in [1]) over a Generic Attribute Profile (GATT) bearer configured with a connection interval i, then the value of the Delay field for the nth message in sequence, starting from n=1, should be calculated using the formula:

    Delay[n] = [m - n] * i

Some states have associated messages that are able to report the state in transition. Whenever a changing state is reported, the message is sent to report the value of the state that is present at the moment. There are also messages reporting both the present value of a state and the target value of the state, along with the remaining time, which is the time it will take from the moment the message is sent by the model to the end of the transition to the target state. This is illustrated in Figure 1.1.

State transition
Figure 1.1. State transition

During the transition time, when a new message that results in a new transition involving that state is received and processed, the new target state and the new transition time overwrite the existing target state and transition time for this state.

A model sends a response message after receiving an acknowledged state-change message. The response message contains information about the present state and optionally contains the target state and the remaining time to complete the state change. When sending the response message, the remaining time value in the response message is the time it will take the state to reach the end of the transition.

Note

Note: It is recommended that the state is changed linearly during the transition, when the transition is a result of processing a message directly changing that state. The bound states are changed according to the binding formulas.

States can have multiple dimensions. Such states are known as multidimensional states. For example, the Light HSL state (see Section 6.1.4) is a 3-dimensional state that combines the Light HSL Lightness (see Section 6.1.4.7), Light HSL Hue (see Section 6.1.4.1), and Light HSL Saturation (see Section 6.1.4.4) states.

State transitions in each dimension are independent. For a combined multidimensional state transition, the transition time and the remaining time represent the combined transition and remaining times of individual dimensions. This is illustrated by Figure 1.2.

Multidimensional state transition
Figure 1.2. Multidimensional state transition

1.4.1.1. Bound states

When a state is bound to another state, a change in one state results in a change in the other state. Bound states may be from different models, and may be in one or more elements.

For example, a common type of binding is between a ‘Level’ state and an ‘OnOff’ state, such as the Generic Power Level state (see Section 3.1.5) and the Generic OnOff state (see Section 3.1.1): changing the Level to zero changes the bound OnOff state to Off, and changing the Level to a non-zero value changes the bound OnOff state to On. Such binding is a unidirectional binding. Bindings also may be bidirectional such as changing the OnOff state to Off changes the bound Level state to zero, and changing the OnOff state to On changes the bound Level state to its last known non-zero value. The binding rules are defined explicitly in state definitions.

1.4.1.1.1. Subscription Lists on bound states

As defined in the Mesh Protocol specification [1], the Subscription List is a list of group addresses or virtual addresses that are assigned to a model. Each address in the list is considered a subscription filter for messages received. Models that operate on bound states share a single instance of a Subscription List per element.

For example, a Light HSL Server model (see Section 6.4.3.3.1), a Light Lightness Server model (see Section 6.4.1), and a Generic Power OnOff Server model (see Section 3.3.4) on a Light HSL main element share a single instance of a Subscription List. This means that subscribing one of the models (e.g., Light Lightness Server) to a group results in the other models (the Generic Power OnOff Server and the Light HSL Server) also subscribing to the same group.

1.4.1.2. Composite states

Multiple states can be grouped together as a shorthand notation referred to as a composite state. This allows a model to refer to this composite state instead of each of the individual grouped states. For example, the Light Lightness state (see Section 6.1.2) includes the following states:

  • Light Lightness Actual state

  • Light Lightness Last state

  • Light Lightness Default state

A model can refer to changes in the Light Lightness state instead of individually referencing each change to the Light Lightness Actual, Light Lightness Last, and Light Lightness Default states.

1.4.2. Messages

All communication within a mesh network is accomplished by sending messages. Messages operate on states. For each state, there is a defined set of messages that a server supports and that a client may use to request the value of a state or to change a state. A server may also transmit unsolicited messages that carry information about states and/or changing states.

A message is defined as having an opcode and associated parameters. For a description of the opcode and its parameters, see the Mesh Protocol specification [1], Section 3.7.3 Access payload.

1.4.2.1. Transactions

Messages may support transactions. A client can send a series of state-changing messages such as Set, Recall, or Clear within a single transaction. A transaction is considered unique in the context of a Transaction Identifier (if present in a message), a Source Address, a Destination Address, and an instance of a state. Specific behaviors for transactions are included in model behaviors.

If the Transaction Identifier is not present in a message, then the context of the response message can be determined by the value of a field containing a status code and/or the presence of optional and/or conditional fields in the response message.

1.4.3. Publication

Model publication is a method of transmitting an access message (see Section 3.7.4.1 of the Mesh Protocol specification [1]) controlled by states defined in Section 4.2.2 of the Mesh Protocol specification. It is the process of sending a message using the corresponding credentials stored in the Configuration Server model. Publication is an optional feature supported only by models that explicitly state support. Publication is also by default disabled; a Configuration Manager can enable publication by setting the publication credentials of the corresponding model in the Configuration Server Model Publication state. An application may also choose to send any message at any time by selecting the destination address, AppKey, and TTL; this does not require model publication.

Models configured for publication generally publish messages under the following scenarios:

  • A server model with an instance of a state publishes a single status corresponding to this state.

  • A server model with an instance of a composite state, where the included states in the composite state have corresponding status messages, only publishes a single status message indicating the value of the composite state.

    For example, the Light Lightness Server includes a Light Lightness composite state that includes the Light Lightness Actual state and the Light Lightness Linear state. When configured for publication, the Light Lightness Server publishes the Light Lightness Status message and does not publish the Light Lightness Linear status message regardless of the state within the composite state that initiated a state transition. Therefore, a Light Lightness Server configured for publication that receives a Light Lightness Linear Set Unacknowledged message will publish a Light Lightness Status message and not a Light Lightness Linear status message.

  • A server model can publish multiple status messages originating from different models if a transition on a bound state spanning multiple models is completed and the additional models are configured for publication.

    For example, a Light Lightness Set Unacknowledged message that changes the value of the Light Lightness Actual state from 0 to a non-zero value causes a state transition on the bound Generic OnOff state on the Generic OnOff Server model. The Light Lightness Server will publish the Light Lightness Status message, and the Generic OnOff Server (whose OnOff state is bound to the Light Lightness Actual state of the Light Lightness Server) will also publish the corresponding Generic OnOff Status message if configured for publication.

  • A server model that has publication configured receives an acknowledged message, and the acknowledged message acts upon a state that would result in publication of a status message upon completion of the state transition. The server model will send at least two status messages:

    • One status message is sent using the publication credentials, following the guidelines for model publication.

    • One status message is sent using the corresponding credentials of the acknowledged message that caused the state transition. This message is sent only to the client that originated the acknowledged message.

    Additional messages are sent if the state transition that completed was a bound state transition, and additional models in the state binding are also configured for publication.

    For example, a Light Lightness Server that receives a Light Lightness Linear Set message sends a Light Lightness Linear Status message (as the response to the acknowledged Set message) using the same credentials that were used for the Light Lightness Linear Set message and starts the transition on the Light Lightness state. When the state transition is complete, the Light Lightness Server publishes a Light Lightness Status message and any additional status messages from bound states that also completed the state transition.

  • A server model with publication configured receives a message that acts upon a state, causing a state transition. The message that caused the state transition has a transition time longer than 2 seconds. The server sends the same status message multiple times. The server might publish the first status message within 1 second of the start of the state transition, then publishes a subsequent status message periodically for the duration of the state transition and publishes a final status message when the state transition is complete.

  • A client model configured for publication sends messages chosen by the application.

1.4.4. Relationship between main, base, extending, and corresponding models

Models are grouped together in order to support functionalities (such as dimmable light or occupancy sensing).

Message dispatch from the access layer to the model layer is based on the destination address and the opcode of the message. Given that unicast addresses are assigned to each element on a node, an element cannot have instances of models with overlapping opcodes. Therefore, a functionality may require a set of models that must be located on different elements within a node, as required by the Mesh Protocol specification [1], Section 3.7.3.

For example, a Light CTL Server model extends the Generic Level Server model twice: once to allow control of the lightness level and once to allow control of the color temperature. The Generic Level Server model is instantiated on two elements. Therefore, when the device receives a Generic Level message destined for one of the elements, the device can determine whether the message is to control the lightness or to control the color temperature.

A node supports a functionality by instantiating the main model for that functionality, which may require a set of base, extending, and corresponding models:

  • A main model may require one or more base models. A node can include multiple instances of a main model to implement the same functionality multiple times. A main model may be instantiated on either the primary element or a secondary element of a node.

  • Base models must be instantiated with the extending models and corresponding models for a functionality and must be indicated in the Composition Data of a node, as required in Section 3.8.4 in [1].

A base model might be extended by multiple models if unambiguous message dispatch is preserved by this extension. For example, the Generic Power OnOff Server is a base model of the Light Lightness Server. The Light Lightness Server corresponds with the Light Lightness Setup Server, which extends the Generic Power OnOff Setup Server, which extends the Generic Power OnOff Server. In this case, a single instance of the Generic Power OnOff Server is a base model of both the Light Lightness Server and the Generic Power OnOff Setup Server, because a single instance of the Generic Power OnOff Server can provide unambiguous message dispatch to both extending models. Figure 1.3 illustrates this example.

Example model hierarchy
Figure 1.3. Example model hierarchy

To aid a Mesh Manager in parsing the node Composition Data:

  • All models are instantiated on elements by using the smallest number of elements to achieve the desired functionality (i.e., by using the smallest possible element index).

  • Corresponding models that cannot be instantiated on the same element as the main model as a result of message dispatch limitations are instantiated on an element with a larger element index.

  • Multiple instances of the same main model do not interleave their corresponding models on subsequent elements. All the corresponding models for the main model are instantiated before the next instance of the main model.

The values of namespace descriptors in the Loc field of Composition Data Page 0 are unrelated to the designation of a model as main or corresponding.

1.4.4.1. Example: Light with built-in controller and separate scene control for lightness and color temperature

This light controller and scene control example illustrates the application of the model relationship principles introduced in Section 1.4.4.

The device is a color temperature-selectable luminaire that has a built-in controller that automatically adjusts the dim level based on ambient light conditions. The device also supports scene-setting of the dim level and controller parameters separately from the color temperature (that is, using a scene to change the color temperature of the luminaire does not change the brightness or the controller parameters).

Figure 1.4 shows the Composition Data for a node implementing this functionality.

Example Composition Data showing the relationship between the states stored with each scene server and the instantiated functionalities distributed on the elements
Figure 1.4. Example Composition Data showing the relationship between the states stored with each scene server and the instantiated functionalities distributed on the elements

The Light Lightness Server model is a base model for both the Light LC Server model (the main model for light controller functionality) and the Light CTL Server model (the main model for tunable white functionality). However, the Light CTL Server model and the Light CTL Temperature Server model (the corresponding model) are stored with different scene servers to meet the device’s functional requirements.

This example illustrates a successful application of the model relationship principles, because:

  • The models are instantiated on the elements in a way that allows unambiguous message dispatch to be performed.

  • The corresponding models of the main models do not interleave with each other.

  • The models are instantiated by using the smallest number of elements to achieve the functionality.

It would be a mistake to move the first scene server from Element 0 to Element 2, and then instantiate a new element and move the second scene server and the Light CTL Temperature Server model to the new element (Element 3). That would be an unsuccessful application of the model relationship principles, because it is not necessary to place the scene server on its own element to achieve the desired functionality (i.e., the scene server can be instantiated on Element 0).

1.4.4.2. Example: Light with two color temperature-selectable outputs

This dual-channel tunable white luminaire example illustrates the application of the model relationship principles introduced in Section 1.4.4.

The device is a driver that has two output channels for color temperature-controllable luminaires.

Figure 1.5 shows the Composition Data for a node implementing this functionality.

Example Composition Data for a driver with two color temperature-selectable output channels
Figure 1.5. Example Composition Data for a driver with two color temperature-selectable output channels

This example illustrates a successful application of the model relationship principles, because:

  • The models are instantiated on the elements in a way that allows unambiguous message dispatch to be performed.

  • The corresponding models of the main models do not interleave with each other.

It would be a mistake to place the first instance of the Light CTL Server model on Element 0, the second instance of the Light CTL Server model on Element 1, and then the two instances of the Light CTL Temperature Server model on Element 3 and Element 4. Although this would allow for unambiguous message dispatch, this would be an unsuccessful application of the model relationship principles. These principles do not permit interleaving a new instance of a Light CTL Server model before instantiating the corresponding models of the initial Light CTL Server model.

1.5. Endianness and field ordering

All multiple-octet numeric values shall be little-endian.

Where data structures are made of multiple fields, the fields are listed in the tables from top to bottom, and they appear in the corresponding figures from left to right (i.e., the top row of the table corresponds to the left of the figure). Table 1.2 and Figure 1.6 show an example data structure made up of multiple fields.

Field

Size
(octets or bits)

Field Content Description

Field 0

1 or more

Start of this field is in Octet 0 (left most octet in corresponding figure)

Field n

1 or more

End of this field is in Octet m

Table 1.2. Field ordering example

Field ordering example
Figure 1.6. Field ordering example

In order to convert the data structure defined in a table into a series of octets the following procedure is used. The binary number with N unassigned bits is created. The number of bits N in the number is equal to the sum of the number of bits of every field in the table. The least significant bits (LSbs) of the number are set to the value of Field 0 (first row of the table), then the number’s unassigned LSbs are set to the value of Field 1. This procedure is continued for consecutive fields of the table and ends when the most significant bits (MSbs) of the number are set to the value of last field of the table. As a final step the number is transmitted in little-endian format (i.e., least significant octet first).

For example, the field 0 is 4 bits wide and has a value of 0x6, field 1 is 12 bits wide and has a value of 0x987, and field 2 is 16 bits wide and has a value of 0x1234. The value of the binary number is 0x12349876 and shall be transmitted as 0x76, 0x98, 0x34, 0x12.

1.6. Table conventions

This section describes conventions regarding the following:

  • Requirements that are in a table

  • Indicating a cell that has no value or content

1.6.1. Requirements that are in a table

Unless otherwise stated, requirements that are in a table in this specification can be defined as "Mandatory" (M), "Optional" (O), "Excluded" (X), or "Conditional" (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.

1.6.2. Indicating a cell that has no value or content

Where a cell in a table indicates an intended absence of a value or other content, the cell will contain “none” or a hyphen (i.e., a “minus” sign). Examples of this are:

  • In the “condition” column of the description of a finite state machine where a rule is unconditional

  • In the “action” column of the description of a finite state machine where a rule has no action

  • In a “restrictions” column where there are no applicable restrictions

  • In an interface description where there are no parameters of a specific type

An empty cell in a table indicates that there is no useful information that can be placed in that cell. Examples of this are:

  • In a “comments” column when there is no comment to make in a particular row

  • In a column specifying properties when the relevant item is reserved for future use (and therefore does not have any properties)

  • In a “units” column when the relevant item is unitless

1.7. Terminology

Table 1.3 lists all of the defined terms used in this specification.

Term

Definition Location

bidirectional binding

Section 1.4.1.1

device property

Section 2

multidimensional state

Section 1.4.1

multisensor

Section 4.1

present value

Section 1.4.1

scene

Section 5.1.3

sensor cadence

Section 4.1.3

TAI time

Appendix A.1

target value

Section 1.4.1

transaction

Section 1.4.2.1

unidirectional binding

Section 1.4.1.1

Table 1.3. Terminology

2. Device properties

A device property is a collection of one or more format descriptors that interpret data contained by a server state.

A device property is identified by a 16-bit assigned Property ID (see Section 2.1), which references GATT characteristics, and has a state called the Property Value (see Section 2.2).

2.1. Property ID

The Property ID is an assigned 16-bit number that identifies a device property that is associated with a defined characteristic [5].

2.2. Property Value

The Property Value is the value of the characteristic referenced by a device property. The value is not self-describing.

2.3. Interpretation of Device Property Values

The format of each characteristic referenced by a device property [5] determines how each Raw Value contained in a device property is formatted.

Characteristics referenced by device properties may represent scalar or non-scalar values. Interpretation of scalar values is defined in Section 2.3.1 and interpretation of non-scalar values is defined in Section 2.3.2.

2.3.1. Device property scalar value

For scalar values, the represented value is related to the Device Property Value by the following equation, where the M, d, and b coefficients are defined for each field of the characteristic:

R=C×M×10d×2b

Where:

R=represented value

M=multiplier

d=decimal exponent

b=binary exponent

2.3.1.1. Example decimal exponent

To represent a length in decimeters with a resolution of 1 decimeter within a characteristic value, the following values are used:

M=1, d=-1, b=0

2.3.1.2. Example binary exponent

To represent a duration in 256ths of a second with a precision of 1/256 of a second within a characteristic value, the following values are used:

M=1, d=0, b=-8

2.3.1.3. Example multiplier

To represent the horizontal dilution of precision with an accuracy of 1/5 with a precision of 1/5 within a characteristic value, the following values are used:

M=2, d=-1, b=0

2.3.2. Device property non-scalar value

For non-scalar data, the represented value is the Device Property Value as defined by the characteristic’s Format field.

2.4. Required device properties summary

Table 2.1 lists the device properties that are required by this specification. The device properties are defined in [5].

Device Property Name

Light Control Time Occupancy Delay

Light Control Time Fade On

Light Control Time Run On

Light Control Time Fade

Light Control Time Prolong

Light Control Time Fade Standby Auto

Light Control Time Fade Standby Manual

Light Control Lightness On

Light Control Lightness Prolong

Light Control Lightness Standby

Light Control Ambient LuxLevel On

Light Control Ambient LuxLevel Prolong

Light Control Ambient LuxLevel Standby

Light Control Regulator Kiu

Light Control Regulator Kid

Light Control Regulator Kpu

Light Control Regulator Kpd

Light Control Regulator Accuracy

Motion Sensed

Time Since Motion Sensed

People Count

Presence Detected

Present Ambient Light Level

Table 2.1. Summary of required device properties for mesh models

3. Generics

This section of the specification defines a number of generic states, messages and models that are explicitly defined to be non-specific in their functionality. For example, many devices can be turned on and off regardless of whether they are a fan, an air conditioning unit, a light, or a power socket. All of those devices would support the Generic OnOff states, messages, and models instead of having separate OnOff states, messages, and models for each type of device.

3.1. Generic states

3.1.1. Generic OnOff

The Generic OnOff state is a Boolean value that represents the state of an element. The values for the Generic OnOff state are defined in Table 3.1. The meaning of the state is determined by the model.

Value

Description

0x00

Off

0x01

On

0x02–0xFF

Prohibited

Table 3.1. Generic OnOff states

3.1.1.1. Binary state transitions

Because binary states cannot support transitions, when changing to 0x01 (On), the Generic OnOff state shall change immediately when the transition starts, and when changing to 0x00, the state shall change when the transition finishes.

Figure 3.1 illustrates the behavior for a Generic OnOff state bound to a Generic Power Actual state (see Section 3.1.5.1.2) when changing to 0x01 (On). Figure 3.2 illustrates the behavior for a Generic OnOff state bound to a Generic Power Actual state when changing to 0x00 (Off).

Binary state transitions from 0x00 to 0x01
Figure 3.1. Binary state transitions from 0x00 to 0x01

Binary state transitions from 0x01 to 0x00
Figure 3.2. Binary state transitions from 0x01 to 0x00

3.1.2. Generic Level

The Generic Level state is a 16-bit signed integer (2’s complement) representing the state of an element. The values are defined in Table 3.2. The meaning of the level is determined by a model.

Value

Description

0x8000–0x7FFF

The Generic Level state of an element, represented as a 16-bit signed integer (the complement of 2)

Table 3.2. Generic Level states

3.1.3. Generic Default Transition Time

The Generic Default Transition Time state determines how long an element shall take to transition from the present state to a new state (see Section 1.4.1.1). The Generic Default Transition Time state uses the Generic Transition Time format defined in Section 3.1.10. The Generic Default Transition Time consists of the Default Transition Step Resolution field and the Default Transition Number of Steps field.

Default values for the Generic Default Transition Step Resolution and the Default Transition Number of Steps are implementation specific and are defined by a device manufacturer.

3.1.3.1. Default Transition Step Resolution

The Default Transition Step Resolution field shall use the Transition Step Resolution format (see Section 3.1.10.1) of the Generic Default Transition Time.

3.1.3.2. Default Transition Number of Steps

The Default Transition Number of Steps field shall use the Transition Number of Steps format (see Section 3.1.10.2) of the Generic Transition Time.

Default Transition Number of Steps shall not be set to a value of 0x3F.

3.1.4. Generic OnPowerUp

The Generic OnPowerUp state is an enumeration representing the behavior of an element when powered up. The values for the state are defined in Table 3.3.

Value

Description

0x00

Off. After being powered up, the element is in an off state.

0x01

Default. After being powered up, the element is in an On state and uses default state values.

0x02

Restore. If a transition was in progress when powered down, the element restores the target state when powered up. Otherwise the element restores the state it was in when powered down.

0x03–0xFF

Prohibited

Table 3.3. Generic OnPowerUp states

3.1.5. Generic Power Level

The Generic Power Level state is a composite state that includes the following states:

3.1.5.1. Generic Power Actual

The Generic Power Actual state determines the linear percentage of the maximum power level of an element, representing a range from 0 percent through 100 percent. The value is derived using the following formula:

Represented power level [%]=100 [%]×Generic Power Actual÷65535

The state is bound to the Generic Level state (see Section 3.1.2) and the Generic OnOff state (see Section 3.1.1). The values for the Generic Power Actual state are defined in Table 3.4.

Value

Description

0x0000–0xFFFF

Represents the power level relative to the maximum power level

Table 3.4. Generic Power Actual states

An element that has the Generic Power Actual set to 0x0000 may continue to power the wireless communications and the microcontroller necessary to change the Generic Power Actual state back to a non-zero value.

Additional regulatory requirements may determine the maximum energy use when the element has the Generic Power Actual state set to 0x0000.

3.1.5.1.1. Binding with the Generic Level state

The Generic Power Actual state is bound to an instance of the Generic Level state (see Section 3.1.2), meaning that whenever the Generic Level state of an element changes, the following binding calculation steps shall be performed in the given order:

  1. If the transition is a GL Set transition (see Section 3.3.2.2.2), calculate:

    Generic Power Actual=Generic Level+32768

  2. If the transition is a GL Delta transaction (see Section 3.3.2.2.3) or a GL Move transition (see Section 3.3.2.2.4) and:

    • if the value of the Generic Power Actual state is non-zero at the beginning of the transition, calculate:

      Generic Power Actual=max(Generic Power Range Min, Generic Level+32768)

    • if the value of the Generic Power Actual state is zero at the beginning of the transition, calculate:

      Generic Power Actual=Generic Level+32768

  3. Modify the value of the calculated Generic Power Actual state using the binding defined in Section 3.1.5.1.4, if applicable.

  4. Calculate all other bindings and reverse bindings.

A reverse binding is also defined, meaning that whenever the Generic Power Actual state of an element changes, the following calculation shall be performed:

Generic Level=Generic Power Actual-32768

The Generic Power Actual state shall not wrap around (i.e., from 65535 to 0, or 0 to 65535) when it reaches the maximum or minimum value.

3.1.5.1.2. Binding with the Generic OnOff state

The Generic Power Actual state is bound to an instance of the Generic OnOff state (see Section 3.1.1), meaning that whenever the Generic OnOff state of an element is set, the following calculations shall be performed:

Generic Power Actual=0x0000

when the value of the Generic OnOff state is equal to 0x00, or

Generic Power Actual=Generic Power Last

when the value of the Generic OnOff state is equal to 0x01, when value of the Generic Power Default state is equal to 0x0000, or

Generic Power Actual=Generic Power Default

when the value of the Generic OnOff state is equal to 0x01 and the value of the Generic Power Default state is not equal to 0x0000.

A reverse binding is also defined, meaning that whenever the Generic Power Actual state of an element changes, the following calculations shall be performed:

Generic OnOff=0x00

when the value of the Generic Power Actual is equal to 0x0000, or

Generic OnOff=0x01

when the value of the Generic Power Actual is greater than 0x0000.

3.1.5.1.3. Binding with the Generic OnPowerUp state

The Generic Power Actual state is bound to an instance of the Generic OnPowerUp state (see Section 3.1.4), meaning that during a power-up sequence (when an element is physically powered up), the following calculations shall be performed:

Generic Power Actual=0

when the value of the Generic OnPowerUp state is equal to 0x00, or

Generic Power Actual=Generic Power Default

when the value of the Generic OnPowerUp state is equal to 0x01 and Generic Power Default is not equal to zero, or

Generic Power Actual=Generic Power Last (see Section 3.1.5.2)

when the value of the Generic OnPowerUp state is equal to 0x01 and Generic Power Default equal to zero, or

Generic Power Actual=last known value of the Generic Power Actual state before the node is powered down

when the value of the Generic OnPowerUp state is equal to 0x02.

3.1.5.1.4. Binding with the Generic Power Range state

The Generic Power Actual state is bound to an instance of the Generic Power Range state (see Section 3.1.5.4), meaning that whenever the Generic Power Actual state of an element changes, the following calculations shall be performed:

Generic Power Actual=Generic Power Range Min

when the non-zero values of the Generic Power Actual state are less than the value of the Generic Power Range Min state

Generic Power Actual=Generic Power Range Max

when the non-zero values of the Generic Power Actual state are greater than the value of the Generic Power Range Max state

3.1.5.2. Generic Power Last

The Generic Power Last state is a 16-bit value representing a percentage ranging from (1/65535) percent to 100 percent. The value is derived using the following formula:

Represented power level [%]=100 [%]×Generic Power Last÷65535

The purpose of the Generic Power Last state is to store the last known non-zero value of the Generic Power Actual state, which is a result of a completed transactional change of the state. Depending on the value of the Generic OnPowerUp state (see Section 3.1.4), It may also be used as a default value when an element is powered up.

Whenever the Generic Power Actual state is changed to a non-zero value as a result of a non-transactional message or a completed sequence of transactional messages, the value of the Generic Power Last state shall be set to the value of the Generic Power Actual state.

The values for the Generic Power Last state are defined in Table 3.5.

Value

Description

0x0000

Prohibited

0x0001–0xFFFF

Represents the power level relative to the maximum power level

Table 3.5. Generic Power Last states

3.1.5.3. Generic Power Default

The Generic Power Default state is a 16-bit value ranging from 0 through 65535. Values from 0x0001 through 0xFFFF represent the percentage of power level, derived using the following formula:

Represented power level [%]=100 [%]×Generic Power Default÷65535

Value 0x0000 has a special meaning defined: use the value of the Generic Power Last state as the default value. The purpose of the Generic Power Default state is to determine the power level of an element when the device is powered up and when the Generic OnPowerUp state (see Section 3.1.4) bound to the Generic Power Level state is set to 0x01 (Default).

The values for the Generic Power Default state are defined in Table 3.6.

Value

Description

0x0000

Use the Power Last value (see Section 3.1.5.1.1).

0x0001–0xFFFF

Represents the power level relative to the maximum power level.

Table 3.6. Generic Power Default states

3.1.5.4. Generic Power Range

The Generic Power Range state determines the minimum and maximum power levels of an element relative to the maximum power level an element can output. This is a pair of 16-bit unsigned integers: Generic Power Range Min and Generic Power Range Max.

The Generic Power Range Min state determines the minimum non-zero power level an element can be configured to. The Generic Power Range Max state determines the maximum power level an element can be configured to. The values for the states are defined in Table 3.7.

Value

Description

0x0000

Prohibited

0x0001–0xFFFF

Represents the power level relative to the maximum power level.

Table 3.7. Generic Power Min and Generic Power Max states

3.1.6. Generic Battery

The Generic Battery state is a set of four values representing the state of a battery: a charge level (Generic Battery Level), remaining time to complete discharging (Generic Battery Time to Discharge), remaining time to complete charging (Generic Battery Time to Charge), and a flags bit field (Generic Battery Flags).

3.1.6.1. Generic Battery Level

The Generic Battery Level state is a value ranging from 0 percent through 100 percent. The values for the state are defined in Table 3.8.

Value

Description

0x00–0x64

The percentage of the charge level. 100% represents fully charged. 0% represents fully discharged.

0x65–0xFE

Prohibited

0xFF

The percentage of the charge level is unknown.

Table 3.8. Generic Battery Level states

3.1.6.2. Generic Battery Time to Discharge

The Generic Battery Time to Discharge state is a 24-bit unsigned value ranging from 0 through 0xFFFFFF. The values for the state are defined in Table 3.9.

Value

Description

0x000000–0xFFFFFE

The remaining time (in minutes) of the discharging process

0xFFFFFF

The remaining time of the discharging process is not known.

Table 3.9. Generic Battery Time to Discharge states

3.1.6.3. Generic Battery Time to Charge

The Generic Battery Time to Charge state is a 24-bit unsigned value ranging from 0 through 0xFFFFFF. The values for the state are defined in Table 3.10.

Value

Description

0x000000–0xFFFFFE

The remaining time (in minutes) of the charging process

0xFFFFFF

The remaining time of the charging process is not known.

Table 3.10. Generic Battery Time to Charge states

3.1.6.4. Generic Battery Flags

As defined in Table 3.11, the Generic Battery Flags state is a concatenation of four 2-bit bit fields: Presence, Indicator, Charging, and Serviceability. The values for the state are defined in Table 3.11.

Bit

Definition

0–1

Generic Battery Flags Presence

2–3

Generic Battery Flags Indicator

4–5

Generic Battery Flags Charging

6–7

Generic Battery Flags Serviceability

Table 3.11. Generic Battery Flags states

3.1.6.4.1. Generic Battery Flags Presence

The Generic Battery Flags Presence state bit field indicates presence of a battery. The values for the state are defined in Table 3.12.

Value

Description

0b00

The battery is not present.

0b01

The battery is present and is removable.

0b10

The battery is present and is non-removable

0b11

The battery presence is unknown.

Table 3.12. Generic Battery Flags Presence states

3.1.6.4.2. Generic Battery Flags Indicator

The Generic Battery Flags Indicator state bit field indicates the charge level of a battery. The values for the state are defined in Table 3.13.

Value

Description

0b00

The battery charge is Critically Low Level.

0b01

The battery charge is Low Level.

0b10

The battery charge is Good Level.

0b11

The battery charge is unknown.

Table 3.13. Generic Battery Flags Indicator states

The implementation determines what represents a good, low, or critically low battery level.

3.1.6.4.3. Generic Battery Flags Charging

The Generic Battery Flags Charging state bit field indicates whether a battery is charging. The values for the state are defined in Table 3.14.

Value

Description

0b00

The battery is not chargeable.

0b01

The battery is chargeable and is not charging.

0b10

The battery is chargeable and is charging.

0b11

The battery charging state is unknown.

Table 3.14. Generic Battery Flags Charging states

3.1.6.4.4. Generic Battery Flags Serviceability

The Generic Battery Flags Serviceability state bit field indicates the serviceability of a battery. The values for the state are defined in Table 3.15.

Value

Description

0b00

Reserved for Future Use

0b01

The battery does not require service.

0b10

The battery requires service.

0b11

The battery serviceability is unknown.

Table 3.15. Generic Battery Flags Serviceability states

3.1.7. Generic Location

The Generic Location state defines location information of an element. The state is composed of the fields defined in Table 3.16.

Field

Size

(octets)

Description

Global Latitude

4

Global Coordinates (Latitude)

Global Longitude

4

Global Coordinates (Longitude)

Global Altitude

2

Global Altitude

Local North

2

Local Coordinates (North)

Local East

2

Local Coordinates (East)

Local Altitude

2

Local Altitude

Floor Number

1

Floor Number

Uncertainty

2

Uncertainty

Table 3.16. Generic Location state

3.1.7.1. Global Latitude

The Global Latitude field describes the global WGS84 North coordinate of the element. The format of the field is a signed integer of size 32 bits encoded as signed magnitude.

Note

Note: The global WGS84 North coordinate and latitude are based on the World Geodetic System 1984 datum (WGS84) [3].

The relationship between Latitude X in the range [-90°, 90°] and the encoded number N is derived using the following formula:

Equation 0. 
N=floor  X 90 2 31 1

where N is bounded to the range -231+1≤N≤231-1. If N exceeds the bounds, the closest value within the bounds shall be used.

The floor operation shall be performed according to IEEE standards.

Note

Note: The IEEE standards are described in [4].

The value 0x80000000 in the Global Latitude field indicates the Global Latitude is not configured.

3.1.7.2. Global Longitude

The Global Longitude field describes the global WGS84 East coordinate of the element. The format of the field is a signed integer of size 32 bits encoded as signed magnitude.

Note

Note: The global WGS84 East coordinate and longitude are based on the WGS84 datum [3].

Note: The global WGS84 East coordinate and longitude are based on the WGS84 datum [3].

The relationship between Longitude X in the range [-180°, 180°] and the encoded number N is derived using the following formula:

Equation 0. 
N=floor  X 180 2 31 1

where N is bounded to the range -231+1≤N≤231-1. If N exceeds the bounds, the closest value within the bounds shall be used.

The floor operation shall be performed according to IEEE standards.

Note

Note: The IEEE standards are described in [4].

The value 0x80000000 in the Global Latitude field indicates the Global Longitude is not configured.

3.1.7.3. Global Altitude

The Global Altitude field determines the altitude of the device above the WGS84 datum. It expresses the altitude beyond the WGS84 ellipsoid of the element that exposed its position. This is a 16-bit signed integer in meters.

Note

Note: The WGS84 ellipsoid is described in [3].

The values for the state are defined in Table 3.17.

Value

Meaning

0x7FFF

Global Altitude is not configured.

0x7FFE

Global Altitude is greater than or equal to 32766 meters.

0x8000–0x7FFD

Global Altitude is (field value) from -32768 meters through 32765 meters.

Table 3.17. Global Altitude field values

3.1.7.4. Local North

The Local North field describes the North coordinate of the device using a local coordinate system. It is relative to the north orientation on a predefined map. The format of the field is a signed integer of size 16 bits.

The Local North value is encoded in decimeters and has a range of -32767 decimeters through 32767 decimeters. The value 0x8000 means the Local North information is not configured.

3.1.7.5. Local East

The Local East field describes the East coordinate of the device using a local coordinate system. It is relative to the east orientation of a predefined map. The format of the field is a signed integer of size 16 bits.

The Local East value is encoded decimeters and it ranges from -32767 decimeters through 32767 decimeters. The value 0x8000 means the Local East information is not configured.

3.1.7.6. Local Altitude

The Local Altitude field determines the altitude of the device relative to the Generic Location Global Altitude. This is a 16-bit signed integer in decimeters.

The valid range is from -32768 decimeters through 32765 decimeters.

The values for the state are defined in Table 3.18.

Value

Meaning

0x7FFF

Local Altitude is not configured.

0x7FFE

Local Altitude is greater than or equal to 32766 decimeters.

0x8000–0x7FFD

Local Altitude is (field value) from -32768 decimeters through 32765 decimeters.

Table 3.18. Local Altitude field values

3.1.7.7. Floor Number

The Floor Number field describes the floor number where the element is installed.

The floor number, N, is encoded as X=N+20, where X is the encoded floor number.

Floor number=-20 (X=0) has a special meaning, indicating the floor -20, and also any floor below that.

Floor number=232 (X=252) has a special meaning, indicating the floor 232, and also any floor above that.

The values for the state are defined in Table 3.19.

Encoded Value X

Floor number N

0x00

Floor -20 or any floor below -20.

0x01–0xFB

Floor number N, encoded as X=N+20.

0xFC

Floor 232 or any floor above 232.

0xFD

Ground floor. Floor 0.

0xFE

Ground floor. Floor 1.

0xFF

Not configured

Table 3.19. Floor Number field values

Note

Note: The reason for having two definitions of ground floor (0 or 1) is to allow for different conventions applicable in different countries.

The format of the field is an unsigned integer of size 8 bits.

3.1.7.8. Uncertainty

The Uncertainty field is a 16-bit bit field that describes the uncertainty of the location information the element exposes. The field consists of several values. The meaning of each bit is described in Table 3.20.

Bits

Field

Description

0

Stationary

Stationary field indicates whether the device broadcasting the location information has a stationary location or is mobile.

1–7

RFU

Reserved for Future Use

8–11

Update Time

Update Time field indicates the time (t) elapsed since the last update of the device's position.

12–15

Precision

Precision field indicates a location precision.

Table 3.20. Uncertainty bit field values

The Stationary field indicates whether the device broadcasting the location information has a stationary location or is mobile. The values of the Stationary field are defined Table 3.21.

Value

Description

0

Stationary

1

Mobile

Table 3.21. Stationary field values

The Update Time field indicates the time (t) elapsed since the last update of the device's position, measured in seconds, using the following formula:

t=2x-3

The field value (x) is a 4-bit value ranging from 0 through 15. The represented Update Time value range is from 0.125 seconds through 4096 seconds.

If the Stationary field is set to the Stationary value, the Update Time field value can be ignored.

The Precision field indicates a location precision with the formula:

Precision=2y-3

The field value (y) is a 4-bit value ranging from 0 through 15. The represented Precision value range is from 0.125 meters through 4096 meters.

3.1.8. Generic Property states

Generic Property states are used to represent any value to be stored by an element. Generic Properties are organized in three categories with respect to access rights: Generic User Properties (see Section 3.1.8.1), Generic Admin Properties (see Section 3.1.8.2), and Generic Manufacturer Properties (see Section 3.1.8.3).

Generic Manufacturer Properties cannot be written, but a client that has access to the Generic Manufacturer Property Server (see Section 3.3.13) may decide if the device properties are accessible by clients via the Generic User Property Server (see Section 3.3.11).

Generic Admin Properties can be read or written, and a client that has access to the Generic Admin Property Server (see Section 3.3.12) may decide whether these device properties are accessible by clients via the Generic User Property Server (see Section 3.3.11) and whether this access is read-only, write-only, or read-write.

Figure 3.3 illustrates the hierarchy of Generic Property states.

Generic Property states hierarchy
Figure 3.3. Generic Property states hierarchy

3.1.8.1. Generic User Property

Generic User Property is a state representing a device property of an element. Depending on how the device property is defined, this may be a read-only state or a read-write state. The values for the state are defined in Table 3.22.

Field

Size
(octets)

Description

User Property ID

2

Defined in Section 3.1.8.1.1.

User Access

1

Defined in Section 3.1.8.1.2.

User Property Value

variable

Scalar or String value, defined in Section 3.1.8.1.3.

Table 3.22. Generic User Property states

3.1.8.1.1. User Property ID

The User Property ID field is a 2-octet Assigned Number value referencing a device property (see Section 2).

The values for the field are defined in Table 3.23.

Value

Meaning

0x0000

Prohibited

0x0001–0xFFFF

Identifier of a device property (see Section 2.1)

Table 3.23. User Property ID field values

3.1.8.1.2. User Access

The User Access field is an enumeration indicating whether the device property can be read or written as a Generic User Property. The values for the field are defined in Table 3.24.

Value

Meaning

0x00

Prohibited

0x01

The device property can be read.

0x02

The device property can be written.

0x03

The device property can be read and written.

0x04–0xFF

Prohibited

Table 3.24. User Access field values

3.1.8.1.3. User Property Value

The User Property Value field is a conditional field. Depending on the format defined by the characteristic that the device property references, the field contains a scalar value, as described in Section 2.3.1, or a string value, as described in Section 2.3.2.

3.1.8.2. Generic Admin Property

Generic Admin Property is a state representing a device property of an element that can be read or written. The values for the state are defined in Table 3.25.

Field

Size
(octets)

Description

Admin Property ID

2

Defined in Section 3.1.8.2.1.

Admin User Access

1

Defined in Section 3.1.8.2.2.

Admin Property Value

variable

Scalar or String value, defined in Section 3.1.8.2.3.

Table 3.25. Generic Admin Property states

3.1.8.2.1. Admin Property ID

The Admin Property ID field is a 2-octet Assigned Number value referencing a device property (see Section 2).

The values for the field are defined in Table 3.26.

Value

Meaning

0x0000

Prohibited

0x0001–0xFFFF

Identifier of a device property (see Section 2.1)

Table 3.26. Admin Property ID field values

3.1.8.2.2. Admin User Access

The Admin User Access field is an enumeration indicating whether the device property can be read or written as a Generic User Property. The values for the field are defined in Table 3.27.

Value

Meaning

0x00

The device property is not a Generic User Property.

0x01

The device property is a Generic User Property and can be read.

0x02

The device property is a Generic User Property and can be written.

0x03

The device property is a Generic User Property and can be read and written.

0x04–0xFF

Prohibited

Table 3.27. Admin User Access field values

3.1.8.2.3. Admin Property Value

The Admin Property Value field is a conditional field. Depending on the format defined by the characteristic that the device property references, the field contains either a scalar value, as described in Section 2.3.1, or a string value, as described in Section 2.3.2.

3.1.8.3. Generic Manufacturer Property

Generic Manufacturer Property is a state representing a device property of an element that is programmed by a manufacturer and can be read. The values for the state are defined in Table 3.28.

Field

Size
(octets)

Description

Manufacturer Property ID

2

Defined in Section 3.1.8.3.1.

Manufacturer User Access

1

Defined in Section 3.1.8.3.2.

Manufacturer Property Value

variable

Scalar or String value, defined in Section 3.1.8.3.3.

Table 3.28. Generic Manufacturer Property states

3.1.8.3.1. Manufacturer Property ID

The Manufacturer Property ID field is a 2-octet Assigned Number value that references a device property (see Section 2).

The values for the field are defined in Table 3.29.

Value

Meaning

0x0000

Prohibited

0x0001–0xFFFF

Identifier of a device property (see Section 2.1)

Table 3.29. Manufacturer Property ID field values

3.1.8.3.2. Manufacturer User Access

The Manufacturer User Access field is an enumeration indicating whether or not the device property can be read as a Generic User Property. The values for the field are defined in Table 3.30.

Value

Meaning

0x00

The device property is not a Generic User Property.

0x01

The device property is a Generic User Property and can be read.

0x02–0xFF

Prohibited

Table 3.30. Manufacturer User Access field values

3.1.8.3.3. Manufacturer Property Value

The Manufacturer Property Value field is a conditional field. Depending on the format defined by the characteristic that the device property references, the field contains either a scalar value, as described in Section 2.3.1, or a string value, as described in Section 2.3.2.

3.1.9. Generic Client Property

Generic Client Property is a read-only state representing a device property that an element supports. It is used by a client to indicate a device property that the client supports and is capable of consuming. The value for the state is described in Table 3.31.

Field

Size
(octets)

Description

Client Property ID

2

Defined in Section 3.1.9.1.

Table 3.31. Generic Client Property state

3.1.9.1. Client Property ID

The Client Property ID field is a 2-octet Assigned Number value that references a device property (see Section 2).

The values for the field are defined in Table 3.32.

Value

Meaning

0x0000

Prohibited

0x0001–0xFFFF

Identifier of a device property (see Section 2.1)

Table 3.32. Client Property ID field values

3.1.10. Generic Transition Time

Generic Transition Time is a 1-octet value that consists of two fields: a 2-bit bit field that determines the step resolution and a 6-bit bit field that determines the number of transition steps. The format of this state is defined in Table 3.33 and illustrated in Figure 3.4.

Field

Size (bits)

Definition

Transition Number of Steps

6

The number of steps

Transition Step Resolution

2

The resolution of the Default Transition Number of Steps field

Table 3.33. Generic Transition Time format

Figure 3.4 illustrates the Generic Transition Time format.

Generic Transition Time format
Figure 3.4. Generic Transition Time format

This format covers a wide range of times that may be required by different applications:

  • For 100-millisecond step resolution, the range is 0 to 6.2 seconds.

  • For 1-second step resolution, the range is 0 to 62 seconds.

  • For 10-second step resolution, the range is 0 to 620 seconds (10.5 minutes).

  • For 10-minute step resolution, the range is 0 to 620 minutes (10.5 hours).

The Generic Transition Time is calculated using the following formula:

Generic Transition Time=Transition Step Resolution * Transition Number of Steps

3.1.10.1. Transition Step Resolution

The Transition Step Resolution field is a 2-bit bit field that determines the resolution of the Generic Transition Time. The field values represent the states defined in Table 3.34.

Value

Description

0b00

The Transition Step Resolution is 100 milliseconds

0b01

The Transition Step Resolution is 1 second

0b10

The Transition Step Resolution is 10 seconds

0b11

The Transition Step Resolution is 10 minutes

Table 3.34. Transition Step Resolution values

3.1.10.2. Transition Number of Steps

The Transition Number of Steps field is a 6-bit value that determines the number of transition steps. The field values represent the states defined in Table 3.35.

Value

Description

0x00

The Generic Transition Time is immediate.

0x01–0x3E

The number of steps.

0x3F

Interpretation of this value is context specific.

Table 3.35. Transition Number of Steps values

3.2. Generic messages

Generic messages operate on Generic states (see Section 3.1).

3.2.1. Generic OnOff messages

3.2.1.1. Generic OnOff Get

Generic OnOff Get is an acknowledged message used to get the Generic OnOff state of an element (see Section 3.1.1).

The response to the Generic OnOff Get message is a Generic OnOff Status message.

The structure of the message is defined in Table 3.36.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.36. Generic OnOff Get message structure

The Opcode field shall contain the opcode value for the Generic OnOff Get message defined in the Assigned Numbers document [10].

3.2.1.2. Generic OnOff Set

Generic OnOff Set is an acknowledged message used to set the Generic OnOff state of an element (see Section 3.1.1).

The response to the Generic OnOff Set message is a Generic OnOff Status message.

The structure of the message is defined in Table 3.37.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

OnOff

1

The target value of the Generic OnOff state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps

C.1

Table 3.37. Generic OnOff Set message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic OnOff Set message defined in the Assigned Numbers document [10].

The OnOff field identifies the Generic OnOff state of the element (see Section 3.1.1).

The TID field is a transaction identifier indicating whether the message is a new message or a retransmission of a previously sent message, as described in Section 3.4.1.2.2.

If present, the Transition Time field identifies the time that an element will take to transition to the target state from the present state (see Section 1.4.1.1). The Transition Time field shall use the format defined in Section 3.2.9.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.1.3. Generic OnOff Set Unacknowledged

Generic OnOff Set Unacknowledged is an unacknowledged message used to set the Generic OnOff state of an element (see Section 3.1.1).

The structure of the message is defined in Table 3.38.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

OnOff

1

The target value of the Generic OnOff state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps

C.1

Table 3.38. Generic OnOff Set Unacknowledged message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic OnOff Set Unacknowledged message defined in the Assigned Numbers document [10].

The OnOff field identifies the Generic OnOff state of the element (see Section 3.1.1).

The TID field is a transaction identifier indicating whether the message is a new message or a retransmission of a previously sent message, as described in Section 3.4.1.2.2.

If present, the Transition Time field identifies the time that an element will take to transition to the target state from the present state (see Section 1.4.1.1). The Transition Time field shall use the format defined in Section 3.2.9.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.1.4. Generic OnOff Status

Generic OnOff Status is an unacknowledged message used to report the Generic OnOff state of an element (see Section 3.1.1).

The structure of the message is defined in Table 3.39.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Present OnOff

1

The present value of the Generic OnOff state.

M

Target OnOff

1

The target value of the Generic OnOff state.

O

Remaining Time

1

Format as defined in Section 3.2.10.

C.1

Table 3.39. Generic OnOff Status message structure

C.1:

If the Target OnOff field is present, the Remaining Time field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic OnOff Status message defined in the Assigned Numbers document [10].

The Present OnOff field identifies the present Generic OnOff state of the element (see Section 3.1.1).

If present, the Target OnOff field identifies the target Generic OnOff state that the element is to reach (see Section 3.1.1).

If present, the Remaining Time field identifies the time it will take the element to complete the transition to the target Generic OnOff state of the node (see Section 1.4.1.1 and 3.1.1).

3.2.2. Generic Level messages

3.2.2.1. Generic Level Get

Generic Level Get is an acknowledged message used to get the Generic Level state of an element (see Section 3.1.2).

The response to the Generic Level Get message is a Generic Level Status message.

The structure of the message is defined in Table 3.40.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.40. Generic Level Get message structure

The Opcode field shall contain the opcode value for the Generic Level Get message defined in the Assigned Numbers document [10].

3.2.2.2. Generic Level Set

Generic Level Set is an acknowledged message used to set the Generic Level state of an element (see Section 3.1.2) to a new absolute value.

The response to the Generic Level Set message is a Generic Level Status message.

The structure of the message is defined in Table 3.41.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Level

2

The target value of the Generic Level state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps

C.1

Table 3.41. Generic Level Set message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Level Set message defined in the Assigned Numbers document [10].

The Level field identifies the Generic Level state of the element (see Section 3.1.2).

The TID field is a transaction identifier indicating whether the message is a new message or a retransmission of a previously sent message, as described in Section 3.4.2.2.2.

If present, the Transition Time field identifies the time that an element will take to transition to the target state from the present state (see Section 1.4.1.1). The Transition Time field shall use the format defined in Section 3.2.9.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.2.3. Generic Level Set Unacknowledged

Generic Level Set Unacknowledged is an unacknowledged message used to set the Generic Level state of an element (see Section 3.1.2) to a new absolute value.

The structure of the message is defined in Table 3.42.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Level

2

The target value of the Generic Level state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps

C.1

Table 3.42. Generic Level Set Unacknowledged message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Level Set Unacknowledged message defined in the Assigned Numbers document [10].

The Level field identifies the Generic Level state of the element (see Section 3.1.2).

The TID field is a transaction identifier indicating whether the message is a new message or a retransmission of a previously sent message, as described in Section 3.4.2.2.2.

If present, the Transition Time field identifies the time that an element will take to transition to the target state from the present state (see Section 1.4.1.1). The Transition Time field shall use the format defined in Section 3.2.9.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.2.4. Generic Delta Set

Generic Delta Set is an acknowledged message used to set the Generic Level state of an element (see Section 3.1.2) by a relative value. The message is transactional – it supports changing the state by a cumulative value with a sequence of messages that are part of a transaction.

The response to the Generic Delta Set message is a Generic Level Status message.

The structure of the message is defined in Table 3.43.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Delta Level

4

The Delta change of the Generic Level state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps

C.1

Table 3.43. Generic Delta Set message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Delta Set message defined in the Assigned Numbers document [10].

The Delta Level field identifies the increase (when positive) or decrease (if negative) of the Generic Level state of the element (see Section 3.1.2).

The TID field is a transaction identifier and shall be used to logically group a series of Generic Delta Set and Generic Delta Set Unacknowledged messages. When starting a new transaction, TID should be assigned a least recently used value, as described in Section 3.4.2.2.3.

The Transition Time field identifies the time that an element will take to transition to the target state from the present state. The Transition Time field shall use the format defined in Section 3.2.9.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.2.5. Generic Delta Set Unacknowledged

Generic Delta Set Unacknowledged is an unacknowledged message used to set the Generic Level state of an element (see Section 3.1.2) by a relative value.

The structure of the message is defined in Table 3.44.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Delta Level

4

The Delta change of the Generic Level state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps

C.1

Table 3.44. Generic Delta Set Unacknowledged message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Delta Set Unacknowledged message defined in the Assigned Numbers document [10].

The Delta Level field identifies the increase (when positive) or decrease (if negative) of the Generic Level state of the element (see Section 3.1.2).

The TID field is a transaction identifier and shall be used to logically group a series of Generic Delta Set and Generic Delta Set Unacknowledged messages. When starting a new transaction, TID should be assigned a least recently used value, as described in Section 3.4.2.2.3.

If present, the Transition Time field identifies the time an element will take to transition to the target state from the present state. The Transition Time field shall use the format defined in Section 3.2.9.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.2.6. Generic Move Set

Generic Move Set is an acknowledged message used to start a process of changing the Generic Level state of an element (see Section 3.1.2) with a defined transition speed.

The response to the Generic Move Set message is a Generic Level Status message.

The structure of the message is defined in Table 3.45.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Delta Level

2

The Delta Level step to calculate Move speed for the Generic Level state.

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps.

C.1

Table 3.45. Generic Move Set message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Move Set message defined in the Assigned Numbers document [10].

The Delta Level field shall be used to calculate the speed of the transition of the Generic Level state.

The TID field is a transaction identifier indicating whether the message is a new message or a retransmission of a previously sent message, as described in Section 3.4.2.2.4.

If present, the Transition Time field shall be used to calculate the speed of the transition of the Generic Level state. The Transition Time field shall use the format defined in Section 3.2.9. If the resulting Transition Time is equal to 0 or is undefined, the Generic Move Set command will not initiate any Generic Level state change.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.2.7. Generic Move Set Unacknowledged

Generic Move Set Unacknowledged is an unacknowledged message used to start a process of changing the Generic Level state of an element (see Section 3.1.2) with a defined transition speed.

The structure of the message is defined in Table 3.46.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Delta Level

2

The Delta Level step to calculate Move speed for the Generic Level state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9..

O

Delay

1

Message execution delay in 5-millisecond steps.

C.1

Table 3.46. Generic Move Set Unacknowledged message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Move Set Unacknowledged message defined in the Assigned Numbers document [10].

The Delta Level field shall be used to calculate the speed of the transition of the Generic Level state.

The TID field is a transaction identifier indicating whether the message is a new message or a retransmission of a previously sent message, as described in Section 3.4.2.2.4.

If present, the Transition Time field shall be used to calculate the speed of the transition of the Generic Level state. The Transition Time field shall use the format defined in Section 3.2.9. If the resulting Transition Time is equal to 0 or undefined, the Generic Move Set command will not initiate any Generic Level state change.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.2.8. Generic Level Status

Generic Level Status is an unacknowledged message used to report the Generic Level state of an element (see Section 3.1.2).

The structure of the message is defined in Table 3.47.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Present Level

2

The present value of the Generic Level state.

M

Target Level

2

The target value of the Generic Level state.

O

Remaining Time

1

Format as defined in Section 3.2.10.

C.1

Table 3.47. Generic Level Status message structure

C.1:

If the Target Level field is present, the Remaining Time field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Level Status message defined in the Assigned Numbers document [10].

The Present Level field identifies the present Generic Level state of the element (see Section 3.1.2).

If present, the Target Level field identifies the target Generic Level state that the element is to reach (see Section 3.1.2).

If present, the Remaining Time field identifies the time that it will take the element to complete the transition to the target Generic Level state of the element (see Section 3.1.2).

3.2.3. Generic Default Transition Time messages

3.2.3.1. Generic Default Transition Time Get

Generic Default Transition Time Get is an acknowledged message used to get the Generic Default Transition Time state of an element (see Section 3.1.3).

The response to the Generic Default Transition Time Get message is a Generic Default Transition Time Status message.

The structure of the message is defined in Table 3.48.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.48. Generic Default Transition Time Get message structure

The Opcode field shall contain the opcode value for the Generic Default Transition Time Get message defined in the Assigned Numbers document [10].

3.2.3.2. Generic Default Transition Time Set

Generic Default Transition Time Set is an acknowledged message used to set the Generic Default Transition Time state of an element (see Section 3.1.3).

The response to the Generic Default Transition Time Set message is a Generic Default Transition Time Status message.

The structure of the message is defined in Table 3.49.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Transition Time

1

The value of the Generic Default Transition Time state.

M

Table 3.49. Generic Default Transition Time Set message structure

The Opcode field shall contain the opcode value for the Generic Default Transition Time Set message defined in the Assigned Numbers document [10].

The Transition Time field identifies the Generic Default Transition Time state of the element (see Section 3.1.3).

3.2.3.3. Generic Default Transition Time Set Unacknowledged

Generic Default Transition Time Set Unacknowledged is an unacknowledged message used to set the Generic Default Transition Time state of an element (see Section 3.1.3).

The structure of the message is defined in Table 3.50.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Transition Time

1

The value of the Generic Default Transition Time state.

M

Table 3.50. Generic Default Transition Time Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic Default Transition Time Set Unacknowledged message defined in the Assigned Numbers document [10].

The Transition Time field identifies the Generic Default Transition Time state of the element (see Section 3.1.3).

3.2.3.4. Generic Default Transition Time Status

Generic Default Transition Time Status is an unacknowledged message used to report the Generic Default Transition Time state of an element (see Section 3.1.3).

The structure of the message is defined in Table 3.51.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Transition Time

1

The value of the Generic Default Transition Time state.

M

Table 3.51. Generic Default Transition Time Status message structure

The Opcode field shall contain the opcode value for the Generic Default Transition Time Status message defined in the Assigned Numbers document [10].

The Transition Time field identifies the Generic Default Transition Time state of the element (see Section 3.1.3).

3.2.4. Generic OnPowerUp messages

3.2.4.1. Generic OnPowerUp Get

Generic OnPowerUp Get is an acknowledged message used to get the Generic OnPowerUp state of an element (see Section 3.1.4).

The response to the Generic OnPowerUp Get message is a Generic OnPowerUp Status message.

The structure of the message is defined in Table 3.52.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.52. Generic OnPowerUp Get message structure

The Opcode field shall contain the opcode value for the Generic OnPowerUp Get message defined in the Assigned Numbers document [10].

3.2.4.2. Generic OnPowerUp Set

Generic OnPowerUp Set is an acknowledged message used to set the Generic OnPowerUp state of an element (see Section 3.1.4).

The response to the Generic OnPowerUp Set message is a Generic OnPowerUp Status message.

The structure of the message is defined in Table 3.53.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

OnPowerUp

1

The value of the Generic OnPowerUp state.

M

Table 3.53. Generic OnPowerUp Set message structure

The Opcode field shall contain the opcode value for the Generic OnPowerUp Set message defined in the Assigned Numbers document [10].

The OnPowerUp field identifies the Generic OnPowerUp state of the element (see Section 3.1.4).

3.2.4.3. Generic OnPowerUp Set Unacknowledged

Generic OnPowerUp Set Unacknowledged is an unacknowledged message used to set the Generic OnPowerUp state of an element (see Section 3.1.4).

The structure of the message is defined in Table 3.54.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

OnPowerUp

1

The value of the Generic OnPowerUp state.

M

Table 3.54. Generic OnPowerUp Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic OnPowerUp Set Unacknowledged message defined in the Assigned Numbers document [10].

The OnPowerUp field identifies the Generic OnPowerUp state of the element (see Section 3.1.4).

3.2.4.4. Generic OnPowerUp Status

Generic OnPowerUp Status is an unacknowledged message used to report the Generic OnPowerUp state of an element (see Section 3.1.4).

The structure of the message is defined in Table 3.55.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

OnPowerUp

1

The value of the Generic OnPowerUp state.

M

Table 3.55. Generic OnPowerUp Status message structure

The Opcode field shall contain the opcode value for the Generic OnPowerUp Status message defined in the Assigned Numbers document [10].

The OnPowerUp field identifies the Generic OnPowerUp state of the element (see Section 3.1.4).

3.2.5. Generic Power Level messages

3.2.5.1. Generic Power Level Get

Generic Power Level Get message is an acknowledged message used to get the Generic Power Actual state of an element (see Section 3.1.5.1).

The response to the Generic Power Level Get message is a Generic Power Level Status message.

The structure of the message is defined in Table 3.56.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.56. Generic Power Level Get message structure

The Opcode field shall contain the opcode value for the Generic Power Level Get message defined in the Assigned Numbers document [10].

3.2.5.2. Generic Power Level Set

Generic Power Level Set is an acknowledged message used to set the Generic Power Actual state of an element (see Section 3.1.5.1).

The response to the Generic Power Level Set message is a Generic Power Level Status message.

The structure of the message is defined in Table 3.57.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Power

2

The target value of the Generic Power Actual state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps

C.1

Table 3.57. Generic Power Level Set message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Power Level Set message defined in the Assigned Numbers document [10].

The Power field identifies the target Generic Power Actual state of the element, as defined in Section 3.1.5.1.

The TID field is a transaction identifier indicating whether the message is a new message or a retransmission of a previously sent message, as described in Section 3.4.5.2.2.

If present, the Transition Time field identifies the time an element will take to transition to the target state from the present state (see Section 1.4.1.1). The Transition Time field shall use the format defined in Section 3.2.9.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.5.3. Generic Power Level Set Unacknowledged

Generic Power Level Set Unacknowledged is an unacknowledged message used to set the Generic Power Actual state of an element (see Section 3.1.5.1).

The structure of the message is defined in Table 3.58.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Power

2

The target value of the Generic Power Actual state

M

TID

1

Transaction Identifier

M

Transition Time

1

Format as defined in Section 3.2.9.

O

Delay

1

Message execution delay in 5-millisecond steps

C.1

Table 3.58. Generic Power Level Set Unacknowledged message structure

C.1:

If the Transition Time field is present, the Delay field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Power Level Set Unacknowledged message defined in the Assigned Numbers document [10].

The Power field identifies the target Generic Power Actual state of the element, as defined in Section 3.1.5.1.

The TID field is a transaction identifier indicating whether the message is a new message or a retransmission of a previously sent message, as described in Section 3.4.5.2.2.

If present, the Transition Time field identifies the time an element will take to transition to the target state from the present state (see Section 1.4.1.1). The Transition Time field shall use the format defined in Section 3.2.9.

If present, the Delay field identifies the message execution delay, representing a time interval between receiving the message by a model and executing the associated model behaviors.

3.2.5.4. Generic Power Level Status

Generic Power Level Status is an unacknowledged message used to report the Generic Power Actual state of an element (see Section 3.1.5.1).

The structure of the message is defined in Table 3.59.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Present Power

2

The present value of the Generic Power Actual state.

M

Target Power

2

The target value of the Generic Power Actual state.

O

Remaining Time

1

Format as defined in Section 3.2.10.

C.1

Table 3.59. Generic Power Level Status message structure

C.1:

If the Target Power field is present, the Remaining Time field shall also be present; otherwise these fields shall not be present.

The Opcode field shall contain the opcode value for the Generic Power Level Status message defined in the Assigned Numbers document [10].

The Present Power field identifies the Generic Power Actual state of the element, as defined in Section 3.1.5.1.

If present, the Target Power field identifies the target Generic Power Actual state that the element is to reach (see Section 3.1.5.1).

If present, the Remaining Time field identifies the time it will take the element to complete the transition to the target Generic Power Actual state of the element (see Section 1.4.1.1 and 3.1.5.1).

3.2.5.5. Generic Power Last Get

Generic Power Last Get is an acknowledged message used to get the Generic Power Last state of an element (see Section 3.1.5.1.1).

The response to a Generic Power Last Get message is a Generic Power Last Status message.

The structure of the message is defined in Table 3.60.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.60. Generic Power Last Get message structure

The Opcode field shall contain the opcode value for the Generic Power Last Get message defined in the Assigned Numbers document [10].

3.2.5.6. Generic Power Last Status

Generic Power Last Status is an unacknowledged message used to report the Generic Power Last state of an element (see Section 3.1.5.1.1).

The structure of the message is defined in Table 3.61.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Power

2

The value of the Generic Power Last state.

M

Table 3.61. Generic Power Last Status message structure

The Opcode field shall contain the opcode value for the Generic Power Last Status message defined in the Assigned Numbers document [10].

The Power field identifies the Generic Power Last state of the element, as defined in Section 3.1.5.1.1.

3.2.5.7. Generic Power Default Get

Generic Power Default Get is an acknowledged message used to get the Generic Power Default state of an element (see Section 3.1.5.3).

The response to a Generic Power Default Get message is a Generic Power Default Status message.

The structure of the message is defined in Table 3.62.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.62. Generic Power Default Get message structure

The Opcode field shall contain the opcode value for the Generic Power Default Get message defined in the Assigned Numbers document [10].

3.2.5.8. Generic Power Default Set

Generic Power Default Set is an acknowledged message used to set the Generic Power Default state of an element (see Section 3.1.5.3).

The response to the Generic Power Default Set message is a Generic Power Default Status message.

The structure of the message is defined in Table 3.63.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Power

2

The value of the Generic Power Default state.

M

Table 3.63. Generic Power Default Set message structure

The Opcode field shall contain the opcode value for the Generic Power Default Set message defined in the Assigned Numbers document [10].

The Power field identifies the Generic Power Default state of the element, as defined in Section 3.1.5.3.

3.2.5.9. Generic Power Default Set Unacknowledged

Generic Power Default Set Unacknowledged is an unacknowledged message used to set the Generic Power Default state of an element (see Section 3.1.5.3).

The structure of the message is defined in Table 3.64.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Power

2

The value of the Generic Power Default state.

M

Table 3.64. Generic Power Default Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic Power Default Set Unacknowledged message defined in the Assigned Numbers document [10].

The Power field identifies the Generic Power Default state of the element, as defined in Section 3.1.5.3.

3.2.5.10. Generic Power Default Status

Generic Power Default Status is an unacknowledged message used to report the Generic Power Default state of an element (see Section 3.1.5.3).

The structure of the message is defined in Table 3.65.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Power

2

The value of the Generic Power Default state.

M

Table 3.65. Generic Power Default Status message structure

The Opcode field shall contain the opcode value for the Generic Power Default Status message defined in the Assigned Numbers document [10].

The Power field identifies the Generic Power Default state of the element, as defined in Section 3.1.5.3.

3.2.5.11. Generic Power Range Get

Generic Power Range Get is an acknowledged message used to get the Generic Power Range state of an element (see Section 3.1.5.4).

The response to the Generic Power Range Get message is a Generic Power Range Status message.

The structure of the message is defined in Table 3.66.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.66. Generic Power Range Get message structure

The Opcode field shall contain the opcode value for the Generic Power Range Get message defined in the Assigned Numbers document [10].

3.2.5.12. Generic Power Range Set

Generic Power Range Set is an acknowledged message used to set the Generic Power Range state of an element (see Section 3.1.5.4).

The response to the Generic Power Range Set message is a Generic Power Range Status message.

The structure of the message is defined in Table 3.67.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Range Min

2

The value of the Generic Power Min field of the Generic Power Range state.

M

Range Max

2

The value of the Generic Power Range Max field of the Generic Power Range state.

M

Table 3.67. Generic Power Range Set message structure

The Opcode field shall contain the opcode value for the Generic Power Range Set message defined in the Assigned Numbers document [10].

The Range Min field identifies the Generic Power Range Min field of the Generic Power Range state of the element (see Section 3.1.5.4).

The Range Max field identifies the Generic Power Max field of the Generic Power Range state of the element (see Section 3.1.5.4).

The value of the Range Max field shall be greater or equal to the value of the Range Min field.

3.2.5.13. Generic Power Range Set Unacknowledged

Generic Power Range Set Unacknowledged is an unacknowledged message used to set the Generic Power Range state of an element (see Section 3.1.5.4).

The structure of the message is defined in Table 3.68.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Range Min

2

The value of the Generic Power Min field of the Generic Power Range state.

M

Range Max

2

The value of the Generic Power Range Max field of the Generic Power Range state.

M

Table 3.68. Generic Power Range Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic Power Range Set Unacknowledged message defined in the Assigned Numbers document [10].

The Range Min field identifies the Generic Power Range Min field of the Generic Power Range state of the element (see Section 3.1.5.4).

The Range Max field identifies the Generic Power Max field of the Generic Power Range state of the element (see Section 3.1.5.4).

The value of the Range Max field shall be greater or equal to the value of the Range Min field.

3.2.5.14. Generic Power Range Status

Generic Power Range Status is an unacknowledged message used to report the Generic Power Range state of an element (see Section 3.1.5.4).

The structure of the message is defined in Table 3.69.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Status Code

1

Status Code for the requesting message.

M

Range Min

2

The value of the Generic Power Range Min field of the Generic Power Range state.

M

Range Max

2

The value of the Generic Power Range Max field of the Generic Power Range state.

M

Table 3.69. Generic Power Range Status message structure

The Opcode field shall contain the opcode value for the Generic Power Range Status message defined in the Assigned Numbers document [10].

The Status Code field identifies the Status Code for the last operation on the Generic Power Range state. The allowed values for status codes and their meanings are documented in Section 7.2.

The Range Min field identifies the Generic Power Range Min field of the Generic Power Range state of the element (see Section 3.1.5.4).

The Range Max field identifies the Generic Power Range Max field of the Generic Power Range state of the element (see Section 3.1.5.4).

3.2.6. Generic Battery messages

3.2.6.1. Generic Battery Get

Generic Battery Get message is an acknowledged message used to get the Generic Battery state of an element (see Section 3.1.6).

The response to the Generic Battery Get message is a Generic Battery Status message.

The structure of the message is defined in Table 3.70.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.70. Generic Battery Get message structure

The Opcode field shall contain the opcode value for the Generic Battery Get message defined in the Assigned Numbers document [10].

3.2.6.2. Generic Battery Status

Generic Battery Status is an unacknowledged message used to report the Generic Battery state of an element (see Section 3.1.6).

The structure of the message is defined in Table 3.71.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Battery Level

1

The value of the Generic Battery Level state.

M

Time to Discharge

3

The value of the Generic Battery Time to Discharge state.

M

Time to Charge

3

The value of the Generic Battery Time to Charge state.

M

Flags

1

The value of the Generic Battery Flags state.

M

Table 3.71. Generic Battery Status message structure

The Opcode field shall contain the opcode value for the Generic Battery Status message defined in the Assigned Numbers document [10].

The Battery Level field identifies the Generic Battery Level state of the element, as defined in Section 3.1.6.1.

The Time to Discharge field identifies the Generic Battery Time to Discharge state of the element, as defined in Section 3.1.6.2.

The Time to Charge field identifies the Generic Battery Time to Charge state of the element, as defined in Section 3.1.6.3.

The Flags field identifies the Generic Battery Flags state of the element, as defined in Section 3.1.6.4.

3.2.7. Generic Location messages

3.2.7.1. Generic Location Global Get

Generic Location Global Get message is an acknowledged message used to get the selected fields of the Generic Location state of an element (see Section 3.1.7).

The response to the Generic Location Global Get message is a Generic Location Global Status message.

The structure of the message is defined in Table 3.72.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.72. Generic Location Global Get message structure

The Opcode field shall contain the opcode value for the Generic Location Global Get message defined in the Assigned Numbers document [10].

3.2.7.2. Generic Location Global Set

Generic Location Global Set is an acknowledged message used to set the selected fields of the Generic Location state of an element (see Section 3.1.7).

The response to the Generic Location Global Set message is a Generic Location Global Status message.

The structure of the message is defined in Table 3.73.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Global Latitude

4

Global Coordinates (Latitude)

M

Global Longitude

4

Global Coordinates (Longitude)

M

Global Altitude

2

Global Altitude

M

Table 3.73. Generic Location Global Set message structure

The Opcode field shall contain the opcode value for the Generic Location Global Set message defined in the Assigned Numbers document [10].

The Global Latitude field identifies the Generic Location Global Latitude state of the element, as defined in Section 3.1.7.1.

The Global Longitude field identifies the Generic Location Global Longitude state of the element, as defined in Section 3.1.7.2.

The Global Altitude field identifies the Generic Location Global Altitude state of the element, as defined in Section 3.1.7.6.

3.2.7.3. Generic Location Global Set Unacknowledged

Generic Location Global Set Unacknowledged is an unacknowledged message used to set the selected fields of the Generic Location state of an element (see Section 3.1.7).

The structure of the message is defined in Table 3.74.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Global Latitude

4

Global Coordinates (Latitude)

M

Global Longitude

4

Global Coordinates (Longitude)

M

Global Altitude

2

Global Altitude

M

Table 3.74. Generic Location Global Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic Location Global Set Unacknowledged message defined in the Assigned Numbers document [10].

The Global Latitude field identifies the Generic Location Global Latitude state of the element, as defined in Section 3.1.7.1.

The Global Longitude field identifies the Generic Location Global Longitude state of the element, as defined in Section 3.1.7.2.

The Global Altitude field identifies the Generic Location Global Altitude state of the element, as defined in Section 3.1.7.6.

3.2.7.4. Generic Location Global Status

Generic Location Global Status is an unacknowledged message used to report the selected fields of the Generic Location state of an element (see Section 3.1.7).

The structure of the message is defined in Table 3.75.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Global Latitude

4

Global Coordinates (Latitude)

M

Global Longitude

4

Global Coordinates (Longitude)

M

Global Altitude

2

Global Altitude

M

Table 3.75. Generic Location Global Status message structure

The Opcode field shall contain the opcode value for the Generic Location Global Status message defined in the Assigned Numbers document [10].

The Global Latitude field identifies the Generic Location Global Latitude state of the element, as defined in Section 3.1.7.1.

The Global Longitude field identifies the Generic Location Global Longitude state of the element, as defined in Section 3.1.7.2.

The Global Altitude field identifies the Generic Location Global Altitude state of the element, as defined in Section 3.1.7.6.

3.2.7.5. Generic Location Local Get

Generic Location Local Get message is an acknowledged message used to get the selected fields of the Generic Location state of an element (see Section 3.1.7).

The response to the Generic Location Local Get message is a Generic Location Local Status message.

The structure of the message is defined in Table 3.76.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.76. Generic Location Local Get message structure

The Opcode field shall contain the opcode value for the Generic Location Local Get message defined in the Assigned Numbers document [10].

3.2.7.6. Generic Location Local Set

Generic Location Local Set is an acknowledged message used to set the selected fields of the Generic Location state of an element (see Section 3.1.7).

The response to the Generic Location Local Set message is a Generic Location Local Status message.

The structure of the message is defined in Table 3.77.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Local North

2

Local Coordinates (North)

M

Local East

2

Local Coordinates (East)

M

Local Altitude

2

Local Altitude

M

Floor Number

1

Floor Number

M

Uncertainty

2

Uncertainty

M

Table 3.77. Generic Location Local Set message structure

The Opcode field shall contain the opcode value for the Generic Location Local Set message defined in the Assigned Numbers document [10].

The Local North field identifies the Generic Location Local North state of the element, as defined in Section 3.1.7.4.

The Local East field identifies the Generic Location Local East state of the element, as defined in Section 3.1.7.5.

The Local Altitude field identifies the Generic Location Local Altitude state of the element, as defined in Section 3.1.7.6.

The Floor Number field identifies the Generic Location Floor Number state of the element, as defined in Section 3.1.7.7.

The Uncertainty field identifies the Generic Location Uncertainty state of the element, as defined in Section 3.1.7.8.

3.2.7.7. Generic Location Local Set Unacknowledged

Generic Location Local Set Unacknowledged is an unacknowledged message used to set the selected fields of the Generic Location state of an element (see Section 3.1.7).

The structure of the message is defined in Table 3.78.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Local North

2

Local Coordinates (North)

M

Local East

2

Local Coordinates (East)

M

Local Altitude

2

Local Altitude

M

Floor Number

1

Floor Number

M

Uncertainty

2

Uncertainty

M

Table 3.78. Generic Location Local Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic Location Local Set Unacknowledged message defined in the Assigned Numbers document [10].

The Local North field identifies the Generic Location Local North state of the element, as defined in Section 3.1.7.4.

The Local East field identifies the Generic Location Local East state of the element, as defined in Section 3.1.7.5.

The Local Altitude field identifies the Generic Location Local Altitude state of the element, as defined in Section 3.1.7.6.

The Floor Number field identifies the Generic Location Floor Number state of the element, as defined in Section 3.1.7.7.

The Uncertainty field identifies the Generic Location Uncertainty state of the element, as defined in Section 3.1.7.8.

3.2.7.8. Generic Location Local Status

Generic Location Local Status is an unacknowledged message used to report the selected fields of the Generic Location state of an element (see Section 3.1.7).

The structure of the message is defined in Table 3.79.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Local North

2

Local Coordinates (North)

M

Local East

2

Local Coordinates (East)

M

Local Altitude

2

Local Altitude

M

Floor Number

1

Floor Number

M

Uncertainty

2

Uncertainty

M

Table 3.79. Generic Location Local Status message structure

The Opcode field shall contain the opcode value for the Generic Location Local Status message defined in the Assigned Numbers document [10].

The Local North field identifies the Generic Location Local North state of the element, as defined in Section 3.1.7.4.

The Local East field identifies the Generic Location Local East state of the element, as defined in Section 3.1.7.5.

The Local Altitude field identifies the Generic Location Local Altitude state of the element, as defined in Section 3.1.7.6.

The Floor Number field identifies the Generic Location Floor Number state of the element, as defined in Section 3.1.7.7.

The Uncertainty field identifies the Generic Location Uncertainty state of the element, as defined in Section 3.1.7.8.

3.2.8. Generic Property messages

3.2.8.1. Generic User Properties Get

Generic User Properties Get is an acknowledged message used to get the list of Generic User Property states of an element (see Section 3.1.8).

The response to the Generic User Properties Get message is a Generic User Properties Status message.

The structure of the message is defined in Table 3.80.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.80. Generic User Properties Get message structure

The Opcode field shall contain the opcode value for the Generic User Properties Get message defined in the Assigned Numbers document [10].

3.2.8.2. Generic User Properties Status

Generic User Properties Status is an unacknowledged message used to report a list of the Generic User Properties states of an element (see Section 3.1.8).

The message is sent as a response to the Generic User Properties Get message or may be sent as an unsolicited message.

The structure of the message is defined in Table 3.81.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

User Property IDs

2*N

A sequence of N User Property IDs present within an element, where N is the number of device property IDs included in the message.

M

Table 3.81. Generic User Properties Status message structure

The Opcode field shall contain the opcode value for the Generic User Properties Status message defined in the Assigned Numbers document [10].

The User Property IDs field contains a sequence of all Generic User Property ID states of an element (see Section 3.1.8).

3.2.8.3. Generic User Property Get

Generic User Property Get is an acknowledged message used to get the Generic User Property state of an element (see Section 3.1.8).

The response to the Generic User Property Get message is a Generic User Property Status message.

The structure of the message is defined in Table 3.82.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

User Property ID

2

Property ID identifying a Generic User Property

M

Table 3.82. Generic User Property Get message structure

The Opcode field shall contain the opcode value for the Generic User Property Get message defined in the Assigned Numbers document [10].

The User Property ID field identifies a Generic User Property ID state of an element (see Section 3.1.8).

3.2.8.4. Generic User Property Set

Generic User Property Set is an acknowledged message used to set the Generic User Property state of an element (see Section 3.1.8).

The response to the Generic User Property Set message is a Generic User Property Status message.

The structure of the message is defined in Table 3.83.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

User Property ID

2

Property ID identifying a Generic User Property

M

User Property Value

variable

Raw value for the User Property

M

Table 3.83. Generic User Property Set message structure

The Opcode field shall contain the opcode value for the Generic User Property Set message defined in the Assigned Numbers document [10].

The User Property ID field identifies a User Property ID state of an element (see Section 3.1.8.1.1).

The User Property Value field identifies a User Property Value state of an element (see Section 3.1.8.1.3).

3.2.8.5. Generic User Property Set Unacknowledged

Generic User Property Set Unacknowledged is an unacknowledged message used to set the Generic User Property state of an element (see Section 3.1.8).

The structure of the message is defined in Table 3.84.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

User Property ID

2

Property ID identifying a Generic User Property

M

User Property Value

variable

Raw value for the User Property

M

Table 3.84. Generic User Property Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic User Property Set Unacknowledged message defined in the Assigned Numbers document [10].

The User Property ID field identifies a User Property ID state of an element (see Section 3.1.8.1.1).

The User Property Value field identifies a User Property Value state of an element (see Section 3.1.8.1.3).

3.2.8.6. Generic User Property Status

Generic User Property Status is an unacknowledged message used to report the Generic User Property state of an element (see Section 3.1.8).

The message is sent as a response to the Generic User Property Get message and the Generic User Property Set message, or may be sent as an unsolicited message.

The structure of the message is defined in Table 3.85.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

User Property ID

2

Property ID identifying a Generic User Property.

M

User Access

1

Enumeration indicating user access

O

User Property Value

variable

Raw value for the User Property

C.1

Table 3.85. Generic User Property Status message structure

C.1:

If the User Access field is present, the User Property Value field shall also be present; otherwise this field shall not be present.

The Opcode field shall contain the opcode value for the Generic User Property Status message defined in the Assigned Numbers document [10].

The User Property ID field identifies a User Property ID state of an element (see Section 3.1.8.1.1).

The User Access field identifies a User Access state of an element (see Section 3.1.8.1.2).

The User Property Value field identifies a User Property Value state of an element (see Section 3.1.8.1.3).

3.2.8.7. Generic Admin Properties Get

Generic Admin Properties Get is an acknowledged message used to get the list of Generic Admin Property states of an element (see Section 3.1.8.2).

The response to the Generic Admin Properties Get message is a Generic Admin Properties Status message.

The structure of the message is defined in Table 3.86.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.86. Generic Admin Properties Get message structure

The Opcode field shall contain the opcode value for the Generic Admin Properties Get message defined in the Assigned Numbers document [10].

3.2.8.8. Generic Admin Properties Status

Generic Admin Properties Status is an unacknowledged message used to report a list of the Generic Admin Properties states of an element (see Section 3.1.8.2).

The message is sent as a response to the Generic Admin Properties Get message or may be sent as an unsolicited message.

The structure of the message is defined in Table 3.87.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Admin Property IDs

2*N

A sequence of N Admin Property IDs present within an element, where N is the number of device property IDs included in the message.

M

Table 3.87. Generic Admin Properties Status message structure

The Opcode field shall contain the opcode value for the Generic Admin Properties Status message defined in the Assigned Numbers document [10].

The Admin Property IDs field contains a sequence of all Generic Admin Property ID states of an element (see Section 3.1.8.2).

3.2.8.9. Generic Admin Property Get

Generic Admin Property Get is an acknowledged message used to get the Generic Admin Property state of an element (see Section 3.1.8.2).

The response to the Generic Admin Property Get message is a Generic Admin Property Status message.

The structure of the message is defined in Table 3.88.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Admin Property ID

2

Property ID identifying a Generic Admin Property.

M

Table 3.88. Generic Admin Property Get message structure

The Opcode field shall contain the opcode value for the Generic Admin Property Get message defined in the Assigned Numbers document [10].

The Admin Property ID field identifies an Admin Property ID state of an element (see Section 3.1.8.2.1).

3.2.8.10. Generic Admin Property Set

Generic Admin Property Set is an acknowledged message used to set the Generic Admin Property state of an element (see Section 3.1.8.2).

The response to the Generic Admin Property Set message is a Generic Admin Property Status message.

The structure of the message is defined in Table 3.89.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Admin Property ID

2

Property ID identifying a Generic Admin Property.

M

Admin User Access

1

Enumeration indicating user access.

M

Admin Property Value

variable

Raw value for the Admin Property

M

Table 3.89. Generic Admin Property Set message structure

The Opcode field shall contain the opcode value for the Generic Admin Property Set message defined in the Assigned Numbers document [10].

The Admin Property ID field identifies an Admin Property ID state of an element (see Section 3.1.8.2.1).

The Admin User Access field identifies an Admin User Access state of an element (see Section 3.1.8.2.2).

The Admin Property Value field identifies an Admin Property Value state of an element (see Section 3.1.8.2.3).

3.2.8.11. Generic Admin Property Set Unacknowledged

Generic Admin Property Set Unacknowledged is an unacknowledged message used to set the Generic Admin Property state of an element (see Section 3.1.8.2).

The structure of the message is defined in Table 3.90.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Admin Property ID

2

Property ID identifying a Generic Admin Property.

M

Admin User Access

1

Enumeration indicating user access.

M

Admin Property Value

variable

Raw value for the Admin Property.

M

Table 3.90. Generic Admin Property Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic Admin Property Set Unacknowledged message defined in the Assigned Numbers document [10].

The Admin Property ID field identifies an Admin Property ID state of an element (see Section 3.1.8.2.1).

The Admin User Access field identifies an Admin User Access state of an element (see Section 3.1.8.2.2).

The Admin Property Value field identifies an Admin Property Value state of an element (see Section 3.1.8.2.3).

3.2.8.12. Generic Admin Property Status

Generic Admin Property Status is an unacknowledged message used to report the Generic Admin Property state of an element (see Section 3.1.8.2).

The message is sent as a response to the Generic Admin Property Get message and the Generic Admin Property Set message, or may be sent as an unsolicited message.

The structure of the message is defined in Table 3.91.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Admin Property ID

2

Property ID identifying a Generic Admin Property

M

Admin User Access

1

Enumeration indicating user access

O

Admin Property Value

variable

Raw value for the Admin Property

C.1

Table 3.91. Generic Admin Property Status message structure

C.1:

If the Admin User Access field is present, the Admin Property Value field shall also be present; otherwise this field shall not be present.

The Opcode field shall contain the opcode value for the Generic Admin Property Status message defined in the Assigned Numbers document [10].

The Admin Property ID field identifies an Admin Property ID state of an element (see Section 3.1.8.2.1).

The Admin User Access field identifies an Admin User Access state of an element (see Section 3.1.8.2.2).

The Admin Property Value field identifies an Admin Property Value state of an element (see Section 3.1.8.2.3).

3.2.8.13. Generic Manufacturer Properties Get

Generic Manufacturer Properties Get is an acknowledged message used to get the list of Generic Manufacturer Property states of an element (see Section 3.1.8).

The response to the Generic Manufacturer Properties Get message is a Generic Manufacturer Properties Status message.

The structure of the message is defined in Table 3.92.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Table 3.92. Generic Manufacturer Properties Get message structure

The Opcode field shall contain the opcode value for the Generic Manufacturer Properties Get message defined in the Assigned Numbers document [10].

3.2.8.14. Generic Manufacturer Properties Status

Generic Manufacturer Properties Status is an unacknowledged message used to report a list of the Generic Manufacturer Properties states of an element (see Section 3.1.8).

The message is sent as a response to the Generic Manufacturer Properties Get message or may be sent as an unsolicited message.

The structure of the message is defined in Table 3.93.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Manufacturer Property IDs

2*N

A sequence of N Manufacturer Property IDs present within an element, where N is the number of device property IDs included in the message.

M

Table 3.93. Generic Manufacturer Properties Status message structure

The Opcode field shall contain the opcode value for the Generic Manufacturer Properties Status message defined in the Assigned Numbers document [10].

The Manufacturer Property IDs field contains a sequence of all Generic Manufacturer Property ID states of an element (see Section 3.1.8).

3.2.8.15. Generic Manufacturer Property Get

Generic Manufacturer Property Get is an acknowledged message used to get the Generic Manufacturer Property state of an element (see Section 3.1.8).

The response to the Generic Manufacturer Property Get message is a Generic Manufacturer Property Status message.

The structure of the message is defined in Table 3.94.

Field

Size
(octets)

Description

Req.

Opcode

2

The message opcode

M

Manufacturer Property ID

2

Property ID identifying a Generic Manufacturer Property

M

Table 3.94. Generic Manufacturer Property Get message structure

The Opcode field shall contain the opcode value for the Generic Manufacturer Property Get message defined in the Assigned Numbers document [10].

The Manufacturer Property ID field identifies a Manufacturer Property ID state of an element (see Section 3.1.8.3.1).

3.2.8.16. Generic Manufacturer Property Set

Generic Manufacturer Property Set is an acknowledged message used to set the Generic Manufacturer Property User Access state of an element (see Section 3.1.8.3.1).

The response to the Generic Manufacturer Property Set message is a Generic Manufacturer Property Status message.

The structure of the message is defined in Table 3.95.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Manufacturer Property ID

2

Property ID identifying a Generic Manufacturer Property

M

Manufacturer User Access

1

Enumeration indicating user access

M

Table 3.95. Generic Manufacturer Property Set message structure

The Opcode field shall contain the opcode value for the Generic Manufacturer Property Set message defined in the Assigned Numbers document [10].

The Manufacturer Property ID field identifies a Manufacturer Property ID state of an element (see Section 3.1.8.3.1).

The Manufacturer User Access field identifies a Manufacturer User Access state of an element (see Section 3.1.8.3.2).

3.2.8.17. Generic Manufacturer Property Set Unacknowledged

The Generic Manufacturer Property Set Unacknowledged is an unacknowledged message used to set the Generic Manufacturer Property User Access state of an element (see Section 3.1.8).

The structure of the message is defined in Table 3.96.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Manufacturer Property ID

2

Property ID identifying a Generic Manufacturer Property

M

Manufacturer User Access

1

Enumeration indicating user access

M

Table 3.96. Generic Manufacturer Property Set Unacknowledged message structure

The Opcode field shall contain the opcode value for the Generic Manufacturer Property Set Unacknowledged message defined in the Assigned Numbers document [10].

The Manufacturer Property ID field identifies a Manufacturer Property ID state of an element (see Section 3.1.8.3.1).

The Manufacturer User Access field identifies a Manufacturer User Access state of an element (see Section 3.1.8.3.2).

3.2.8.18. Generic Manufacturer Property Status

The Generic Manufacturer Property Status is an unacknowledged message used to report the Generic Manufacturer Property state of an element (see Section 3.1.8).

The message is sent as a response to the Generic Manufacturer Property Get and Generic Manufacturer Property Set messages or may be sent as an unsolicited message.

The structure of the message is defined in Table 3.97.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Manufacturer Property ID

2

Property ID identifying a Generic Manufacturer Property

M

Manufacturer User Access

1

Enumeration indicating user access

O

Manufacturer Property Value

variable

Raw value for the Manufacturer Property

C.1

Table 3.97. Generic Manufacturer Property Status message structure

C.1:

If the Manufacturer User Access field is present, the Manufacturer Property Value field shall also be present; otherwise this field shall not be present.

The Opcode field shall contain the opcode value for the Generic Manufacturer Property Status message defined in the Assigned Numbers document [10].

The Manufacturer Property ID field identifies a Manufacturer Property ID state of an element (see Section 3.1.8.3.1).

The Manufacturer User Access field identifies a Manufacturer User Access state of an element (see Section 3.1.8.3.2).

The Manufacturer Property Value field identifies a Manufacturer Property Value state of an element (see Section 3.1.8.3.3).

3.2.8.19. Generic Client Properties Get

Generic Client Properties Get is an acknowledged message used to get the list of Generic Client Property states of an element (see Section 3.1.9).

The response to the Generic Client Properties Get message is a Generic Client Properties Status message.

The structure of the message is defined in Table 3.98.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Client Property ID

2

A starting Client Property ID present within an element

M

Table 3.98. Generic Client Properties Get message structure

The Opcode field shall contain the opcode value for the Generic Client Properties Get message defined in the Assigned Numbers document [10].

The Client Property ID field contains the smallest Property ID the client is requesting (see Section 3.1.9).

3.2.8.20. Generic Client Properties Status

The Generic Client Properties Status is an unacknowledged message used to report a list of the Generic Client Properties states of an element (see Section 3.1.9).

The message is sent as a response to the Generic Client Properties Get message or may be sent as an unsolicited message.

The structure of the message is defined in Table 3.99.

Field

Size
(octets)

Description

Req.

Opcode

1

The message opcode

M

Client Property IDs

2*N

A sequence of N Client Property IDs present within an element, where N is the number of device property IDs included in the message.

M

Table 3.99. Generic Client Properties Status message structure

The Opcode field shall contain the opcode value for the Generic Client Properties Status message defined in the Assigned Numbers document [10].

The Client Property IDs field contains a sequence of all Generic Client Property ID states of an element (see Section 3.1.9).

3.2.9. Transition Time field format

The Transition Time field uses the Generic Transition Time format defined in Section 3.1.10. The Transition Time consists of the Transition Step Resolution field and the Transition Number of Steps field.

3.2.9.1. Transition Step Resolution

The Transition Step Resolution field shall use the Transition Step Resolution format (see Section 3.1.10.1) of the Generic Transition Time.

3.2.9.2. Transition Number of Steps

The Transition Number of Steps field shall use the Transition Number of Steps format (see Section 3.1.10.2) of the Generic Transition Time.

When the Transition Number of Steps field is set to a value of 0x3F and Generic Default Transition Time state is supported, the transition time is computed from the Generic Default Transition Time state. When the Transition Number of Steps field is set to a value of 0x3F and the Generic Default Transition Time state is not supported, the computed transition time is immediate.

3.2.9.3. Computation of transition time

When a Transition Time field is included in the message, the transition time shall be computed as follows:

  • If the Transition Time field is present in the message and the Transition Number of Steps field value is not equal to 0x3F, the Transition Time field value shall be used as the transition time.

  • If the Transition Time field is present in the message and the Transition Number of Steps field value is equal to 0x3F and the Generic Default Transition Time state is supported, the Generic Default Transition Time state value shall be used as the transition time.

  • If the Transition Time field is present in the message and the Transition Number of Steps field value is equal to 0x3F and the Generic Default Transition Time state is not supported, the transition time is 0 and the transition shall be instantaneous.

  • If the Transition Time field is not present in the message and the Generic Default Transition Time state is supported, the Generic Default Transition Time state shall be used as the transition time.

  • If the Transition Time field is not present in the message and the Generic Default Transition Time state is not supported, the transition time is 0 and the transition shall be instantaneous.

3.2.10. Remaining Time field format

The Remaining Time field uses the Generic Transition Time format defined in Section 3.1.10. The Remaining Time consists of the Transition Step Resolution field and the Transition Number of Steps field.

3.2.10.1. Transition Step Resolution

The Transition Step Resolution field shall use the Transition Step Resolution format (see Section 3.1.10.1) of the Generic Transition Time.

3.2.10.2. Transition Number of Steps

The Transition Number of Steps field shall use the Transition Number of Steps format (see Section 3.1.10.2) of the Generic Transition Time.

A value of 0x3F (unknown value) is used to indicate a transition time that requires a number of steps higher than 0x3E or that cannot be determined.

3.3. Generic server models

3.3.1. Generic OnOff Server

3.3.1.1. Description

The Generic OnOff Server model is used to support the control and reporting functionality of a node with a generic output that can be turned on or off.

The Generic OnOff Server is a root model and a main model that does not extend any other models.

This model shall support model publication, defined in Section 4.2.2 of the Mesh Protocol specification [1], and model subscription, defined in Section 4.2.3 of the Mesh Protocol specification. When configured for publication, the Generic OnOff Server shall publish Generic OnOff Status messages (see Section 3.3.1.2.3).

The Generic OnOff Server model defines the state instances listed in Table 3.100 and Table 3.101 and the messages listed in Table 3.102, and requires one element: the OnOff Main element. The OnOff Main element contains the Generic OnOff Server main model.

Table 3.100 defines whether the states from the Generic OnOff Server model are stored with a scene.

State

Stored with Scene

Generic OnOff

Yes

Table 3.100. Whether Generic OnOff Server states are stored with a scene

Table 3.101 illustrates the state bindings between the Generic OnOff Server model states and the states of the models that the Generic OnOff Server extends.

State

Bound State

Model

State

Generic OnOff

Table 3.101. Generic OnOff Server states and bindings

Table 3.102 lists the Generic OnOff Server model messages.

Element

Model Name

State

Message

Rx

Tx

OnOff Main

Generic OnOff Server

Generic OnOff (see Section 3.1.1)

Generic OnOff Get

M

Generic OnOff Set

M

Generic OnOff Set Unacknowledged

M

Generic OnOff Status

M

Table 3.102. Generic OnOff Server messages 

Table 3.103 illustrates an example structure of elements and states used by the Generic OnOff Server model (including the corresponding and base models).

Element Index

Model Name

State

X

Generic OnOff Server

Generic OnOff (see Section 3.1.1)

Table 3.103. Generic OnOff Server elements and states

3.3.1.2. Generic OnOff state behavior
3.3.1.2.1. Receiving a Generic OnOff Get message

When a Generic OnOff Server receives a Generic OnOff Get message, it shall respond with a Generic OnOff Status message (see Section 3.3.1.2.3).

3.3.1.2.2. Receiving a Generic OnOff Set / Generic OnOff Set Unacknowledged message

When a Generic OnOff Server receives a Generic OnOff Set message or a Generic OnOff Set Unacknowledged message, it shall set the Generic OnOff state to the OnOff field of the message, unless the message has the same value for the SRC, DST, and TID fields as the previous message received within the past 6 seconds.

Both messages may optionally include a Transition Time field that indicates the transition time to the target state. The transition time shall be computed as defined in Section 3.2.9.33.2.9.1.

If the Transition Time field is included, the Delay field is included and indicates a delay in 5-millisecond steps that the server shall wait before executing any state-changing behavior for this message.

If the received message is a Generic OnOff Set message, the Generic OnOff Server shall respond with a Generic OnOff Status message (see Section 3.3.1.2.3).

3.3.1.2.3. Sending a Generic OnOff Status message

A Generic OnOff Server shall send Generic OnOff Status messages in response to a Generic OnOff Get message (see Section 3.2.1.1), in response to a Generic OnOff Set message (see Section 3.2.1.2), or as an unsolicited message at any time.

When sending a Generic OnOff Status message, the Generic OnOff Server shall set the OnOff field to the present Generic OnOff state. If the Generic OnOff Server is in the process of changing the Generic OnOff state or is waiting for a delay to complete, it shall set the Target OnOff field to the target Generic OnOff state and shall set the Remaining Time field to the time it will take to complete the transition; otherwise, the Target OnOff and Remaining Time fields shall be omitted.

It is recommended to transmit a Generic OnOff Status message when the element has been physically turned on or off locally (as opposed to via the mesh network).

3.3.2. Generic Level Server

3.3.2.1. Description

The Generic Level Server model is used to support the control and reporting functionality of a node with a generic output that can be set to a range of levels.

The Generic Level Server is a root model and a main model that does not extend any other models.

This model shall support model publication, defined in Section 4.2.2 of the Mesh Protocol specification [1], and model subscription, defined in Section 4.2.3 of the Mesh Protocol specification. When configured for publication, the Generic Level Server shall publish Generic Level Status messages (see Section 3.3.2.2.5).

The Generic Level Server model defines the state instances listed in Table 3.104 and Table 3.105 and the messages listed in Table 3.106, and requires one element: the Level Main element. The Level Main element contains the Generic Level Server main model.

Table 3.104 defines whether the states from the Generic Level Server model are stored with a scene.

State

Stored with Scene

Generic Level

Yes

Table 3.104. Whether Generic Level Server states are stored with a scene

Table 3.105 illustrates the state bindings between the Generic Level Server model states and the states of the models that the Generic Level Server extends.

State

Bound State

Model

State

Generic Level

Table 3.105. Generic Level Server states and bindings

Table 3.106 lists the Generic Level Server model messages.

Element

Model Name

State

Message

Rx

Tx

Level Main

Generic Level Server

Generic Level (see Section 3.1.2)

Generic Level Get

M

Generic Level Set

M

Generic Level Set Unacknowledged

M

Generic Delta Set

M

Generic Delta Set Unacknowledged

M

Generic Move Set

M

Generic Move Set Unacknowledged

M

Generic Level Status

M

Table 3.106. Generic Level Server messages

Table 3.107 illustrates an example structure of elements and states used by the Generic Level Server model (including the corresponding and base models).

Element Index

Model Name

State

X

Generic Level Server

Generic Level (see Section 3.1.2)

Table 3.107. Generic Level Server elements and states

3.3.2.2. Generic Level state behavior
3.3.2.2.1. Receiving a Generic Level Get message

When a Generic Level Server receives a Generic Level Get message, the Generic Level Server shall respond with a Generic Level Status message (see Section 3.3.2.2.5).

3.3.2.2.2. Receiving Generic Level Set / Generic Level Set Unacknowledged messages

When a Generic Level Server receives a Generic Level Set message or a Generic Level Set Unacknowledged message, it shall set the Generic Level state to the Level field of the message, unless the message has the same values for the SRC, DST, and TID fields as the previous message received within the last 6 seconds. When the Generic Level state is transitioning to a new state, due to processing a Generic Level Set message, processing a Generic Level Set Unacknowledged message, or performing the Scene Recall operation (see Section 5.1.3.1.2), regardless of whether the transition is instantaneous, the transition is named GL Set.

If present, the Transition Time field value shall be used as the time for transition to the target state. The transition time shall be computed as defined in Section 3.2.9.3.

If the Transition Time field is included, the Delay field is included and indicates a delay 5-millisecond steps that the server shall wait before executing any state-changing behavior for this message.

If the target state is equal to the current state, the transition shall not be started and is considered complete.

If the received message is the Generic Level Set message, the Generic Level Server shall respond with a Generic Level Status message (see Section 3.3.2.2.5).

3.3.2.2.3. Receiving Generic Delta Set / Generic Delta Set Unacknowledged messages

The Generic Delta Set message and the Generic Delta Set Unacknowledged message support transactional control. A number of Generic Delta Set and Generic Delta Set Unacknowledged messages with the same transaction identifier set in the TID field may be sent.

Note

Note: The messages within a transaction carry the cumulative values of the Delta Level field. If one or more messages within a transaction are not received (e.g., because of radio collisions), the next received message will make up for the lost messages, carrying cumulative values of the Delta Level field.

A new transaction starts when the TID field value in the received message is different from the TID field value in the previously received message that was using the same source and destination addresses or different from the most recently received message with the same TID field value that was received 6 or more seconds earlier. The transaction is named GL Delta and may contain one or more transitions.

The Generic Level state value at the beginning of the first transition within a transaction is stored as the Initial Generic Level value for the transaction.

A Generic Level Server shall cancel a transaction upon receiving the message with a different source address, or with a different destination address, or with a new TID, or when the Generic Level state has been changed as a result of processing another message, or as a result of binding with other states, or as a result of a local action (as opposed to via the mesh network). When a transaction is canceled, the current transition (if any) is also canceled. Incoming messages within a canceled transaction shall not result in any state changes.

When a Generic Level Server receives a Generic Delta Set message or a Generic Delta Set Unacknowledged message, the Generic Level Server shall calculate a target value by adding the Delta Level field of the message to the Initial Generic Level value. A new transition shall start if the calculated target value or transition time is different from the current transition. If a new transition starts, the current transition is canceled. When the transition within a transaction is canceled or completed, all bindings and reverse bindings are computed, if applicable.

When the Generic Level state is not bound to any state, the overflow/underflow handling is implementation specific. Some Generic Level Servers may stop at their maximum or minimum level, and some may wrap around.

When the Generic Level state is bound to another state, the overflow/underflow handling shall be defined by the wrap-around behavior of the bound state.

If present, the Transition Time field value shall be used as the time for transition to the target state. The transition time shall be computed as defined in Section 3.2.9.3.

If the Transition Time field is included, the Delay field is included and indicates a delay 5-millisecond steps that the server shall wait before executing any state-changing behavior for this message.

If the target state is equal to the current state, the transition shall not be started and is considered complete.

It is recommended to set the value of the Transition Time field to the expected interval after which the next message will be sent. For example, if the messages are sent every 200 milliseconds, the Transition Time should be set to 200 milliseconds.

Upon receiving a Generic Delta Set message, the Generic Level Server shall respond with a Generic Level Status message (see Section 3.3.2.2.5).

3.3.2.2.4. Receiving Generic Move Set / Generic Move Set Unacknowledged messages

When a Generic Level Server receives a Generic Move Set message or a Generic Move Set Unacknowledged message, it shall start a process of changing the Generic Level state with a transition speed that is calculated by dividing the Delta Level by the Transition Time (i.e., it will be changing by a value of the Delta Level in time of the Transition Time), unless the message has the same values for the SRC, DST, and TID fields as the previous message received within the last 6 seconds. When the Generic Level state is transitioning to a new state, due to processing a Generic Move Set message or processing a Generic Move Set Unacknowledged message, regardless of whether the transition is instantaneous, the transition is named GL Move.

When the Generic Level state is not bound to another state, the overflow/underflow handling is implementation specific. Some Generic Level Servers may stop at their maximum or minimum levels, and some may wrap around.

When the Generic Level state is bound to another state, the overflow/underflow handling shall be defined by the wrap-around behavior of the bound state.

When a Generic Level Server receives the message with a value of the Delta Level field equal to 0, it shall stop changing the Generic Level state.

If present, the Transition Time field value shall be used as the time for calculating the transition speed. The transition time shall be computed as defined in Section 3.2.9.3. If the computed transition time equals 0, the Generic Move Set command shall not initiate any Generic Level state change.

If the resulting Transition Time is equal to 0, the Generic Move Set command will not initiate any Generic Level state change.

If the Transition Time field is included, the Delay field is included and indicates a delay 5-millisecond steps that the server shall wait before executing any state-changing behavior for this message.

Upon receiving a Generic Move Set message, the Generic Level Server shall respond with a Generic Level Status message (see Section 3.3.2.2.5). The target Generic Level state is the upper limit of the Generic Level state when the transition speed is positive, or the lower limit of the Generic Level state when the transition speed is negative.

<