-
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:
|
can |
—used to express a statement of possibility or capability |
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:
-
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.
-
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.
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.
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.
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.
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.
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 |
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 |
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 |
|
device property |
|
multidimensional state |
|
multisensor |
|
present value |
|
scene |
|
sensor cadence |
|
TAI time |
|
target value |
|
transaction |
|
unidirectional binding |
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 |
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 |
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).
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) |
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 |
3.1.5. Generic Power Level
The Generic Power Level state is a composite state that includes the following states:
-
Generic Power Actual state (see Section 3.1.5.1)
-
Generic Power Last state (see Section 3.1.5.2)
-
Generic Power Default state (see Section 3.1.5.3)
-
Generic Power Range state (see Section 3.1.5.4)
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 |
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:
-
If the transition is a GL Set transition (see Section 3.3.2.2.2), calculate:
Generic Power Actual=Generic Level+32768
-
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
-
-
Modify the value of the calculated Generic Power Actual state using the binding defined in Section 3.1.5.1.4, if applicable.
-
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 |
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. |
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. |
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. |
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. |
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. |
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 |
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. |
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. |
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. |
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. |
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 |
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:
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:
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. |
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. |
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 |
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. |
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 |
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.
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 |
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. |
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) |
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 |
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 |
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. |
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) |
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 |
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 |
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. |
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) |
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 |
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 |
Description |
---|---|---|
Client Property ID |
2 |
Defined in Section 3.1.9.1. |
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) |
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 |
Figure 3.4 illustrates the 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 |
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. |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
- 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 |
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 |
- 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 |
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 |
- 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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
- 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 |
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 |
- 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 |
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 |
- 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 |
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 |
- 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 |
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 |
- 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 |
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 |
- 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 |
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 |
- 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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Transition Time |
1 |
The value of the Generic Default Transition Time state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Transition Time |
1 |
The value of the Generic Default Transition Time state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Transition Time |
1 |
The value of the Generic Default Transition Time state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
OnPowerUp |
1 |
The value of the Generic OnPowerUp state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
OnPowerUp |
1 |
The value of the Generic OnPowerUp state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
OnPowerUp |
1 |
The value of the Generic OnPowerUp state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
- 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 |
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 |
- 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 |
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 |
- 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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Power |
2 |
The value of the Generic Power Last state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Power |
2 |
The value of the Generic Power Default state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Power |
2 |
The value of the Generic Power Default state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Power |
2 |
The value of the Generic Power Default state. |
M |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
User Property ID |
2 |
Property ID identifying a Generic User Property |
M |
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 |
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 |
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 |
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 |
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 |
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 |
- 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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Admin Property ID |
2 |
Property ID identifying a Generic Admin Property. |
M |
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 |
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 |
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 |
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 |
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 |
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 |
- 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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
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 |
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 |
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 |
Description |
Req. |
---|---|---|---|
Opcode |
2 |
The message opcode |
M |
Manufacturer Property ID |
2 |
Property ID identifying a Generic Manufacturer Property |
M |
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 |
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 |
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 |
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 |
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 |
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 |
- 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 |
Description |
Req. |
---|---|---|---|
Opcode |
1 |
The message opcode |
M |
Client Property ID |
2 |
A starting Client Property ID present within an element |
M |
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 |
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 |
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.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.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.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) |
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.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.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.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) |
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.
<