doc: Bluetooth: Mesh: Align wording for models instantiation req
According to https://github.com/zephyrproject-rtos/zephyr/pull/61886#issuecomment-1713302331 we need to use "must only" for models that spec states: `If supported, ... shall be supported by the primary element and shall not be supported by any secondary element`. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This commit is contained in:
parent
db52d27eb5
commit
422cfeeb1a
13 changed files with 24 additions and 23 deletions
|
@ -17,8 +17,8 @@ All configuration functions in the Configuration Client API have ``net_idx``
|
|||
and ``addr`` as their first parameters. These should be set to the network
|
||||
index and primary unicast address that the target node was provisioned with.
|
||||
|
||||
The Configuration Client model is optional, but should be instantiated on the
|
||||
first element if it is present in the composition data.
|
||||
The Configuration Client model is optional, and it must only be instantiated on the
|
||||
primary element if present in the Composition Data.
|
||||
|
||||
API reference
|
||||
*************
|
||||
|
|
|
@ -15,7 +15,7 @@ mesh node. It does not have an API of its own, but relies on a
|
|||
controlled through the :ref:`bluetooth_mesh_heartbeat` API.
|
||||
|
||||
The Configuration Server model is mandatory on all Bluetooth mesh nodes, and
|
||||
should be instantiated in the first element.
|
||||
must only be instantiated on the primary element.
|
||||
|
||||
API reference
|
||||
*************
|
||||
|
|
|
@ -12,9 +12,9 @@ used in this function call. The second parameter is the ``ctx`` or message
|
|||
context. Message context contains netkey index, appkey index and unicast
|
||||
address that the target node uses.
|
||||
|
||||
The Health Client model is optional, and may be instantiated in any element.
|
||||
However, if a Health Client model is instantiated in an element other than the
|
||||
first, an instance must also be present in the first element.
|
||||
The Health Client model is optional, and may be instantiated on any element.
|
||||
However, if a Health Client model is instantiated on an element other than the
|
||||
primary, an instance must also be present on the primary element.
|
||||
|
||||
See :ref:`bluetooth_mesh_health_faults` for a list of specification defined
|
||||
fault values.
|
||||
|
|
|
@ -7,6 +7,8 @@ The Health Server model provides attention callbacks and node diagnostics for
|
|||
:ref:`bluetooth_mesh_models_health_cli` models. It is primarily used to report
|
||||
faults in the mesh node and map the mesh nodes to their physical location.
|
||||
|
||||
If present, the Health Server model must be instantiated on the primary element.
|
||||
|
||||
Faults
|
||||
******
|
||||
|
||||
|
|
|
@ -13,6 +13,9 @@ how long a node will advertise Mesh Proxy Service with Private Network Identity
|
|||
The On-Demand Private Proxy Client model communicates with an On-Demand Private Proxy Server model
|
||||
using the device key of the node containing the target On-Demand Private Proxy Server model instance.
|
||||
|
||||
If present, the On-Demand Private Proxy Client model must only be instantiated on the primary
|
||||
element.
|
||||
|
||||
Configurations
|
||||
**************
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ The On-Demand Private Proxy Server does not have an API of its own, and relies o
|
|||
:ref:`bluetooth_mesh_od_cli` to control it. The On-Demand Private Proxy Server
|
||||
model only accepts messages encrypted with the node's device key.
|
||||
|
||||
If present, the On-Demand Private Proxy Server model must be instantiated on the primary
|
||||
If present, the On-Demand Private Proxy Server model must only be instantiated on the primary
|
||||
element.
|
||||
|
||||
API reference
|
||||
|
|
|
@ -13,11 +13,11 @@ a sequence of access layer messages to nodes supporting the :ref:`bluetooth_mesh
|
|||
The Opcodes Aggregator Client model communicates with an Opcodes Aggregator Server model
|
||||
using the device key of the target node or the application keys configured by the Configuration Client.
|
||||
|
||||
The Opcodes Aggregator Client model must only be instantiated on the primary
|
||||
element, and it is implicitly bound to the device key on initialization.
|
||||
If present, the Opcodes Aggregator Client model must only be instantiated on the primary element.
|
||||
|
||||
The Opcodes Aggregator Client model should be bound to the same application keys that the client models,
|
||||
used to produce the sequence of messages, are bound to.
|
||||
The Opcodes Aggregator Client model is implicitly bound to the device key on initialization. It
|
||||
should be bound to the same application keys as the client models that are used to produce the sequence of
|
||||
messages.
|
||||
|
||||
To be able to aggregate a message from a client model, it should support an asynchronous
|
||||
API, for example through callbacks.
|
||||
|
|
|
@ -13,8 +13,7 @@ a sequence of access layer messages.
|
|||
The Opcodes Aggregator Server model accepts messages encrypted with the node's device key
|
||||
or the application keys.
|
||||
|
||||
The Opcodes Aggregator Server model can only be instantiated on the
|
||||
node's primary element.
|
||||
If present, the Opcodes Aggregator Server model must only be instantiated on the primary element.
|
||||
|
||||
The targeted server models should be bound to the same application key that is used
|
||||
to encrypt the sequence of access layer messages sent to the Opcodes Aggregator Server.
|
||||
|
|
|
@ -25,8 +25,7 @@ All configuration functions in the Private Beacon Client API have ``net_idx``
|
|||
and ``addr`` as their first parameters. These should be set to the network
|
||||
index and the primary unicast address the target node was provisioned with.
|
||||
|
||||
The Private Beacon Client model is optional, and can be instantiated on any
|
||||
element.
|
||||
If present, the Private Beacon Client model must only be instantiated on the primary element.
|
||||
|
||||
API reference
|
||||
*************
|
||||
|
|
|
@ -28,8 +28,7 @@ Server model through the :c:struct:`bt_mesh_priv_beacon_srv` instance passed to
|
|||
changes to this configuration in the settings subsystem, the initial values may
|
||||
be overwritten upon loading.
|
||||
|
||||
The Private Beacon Server model is optional, and can only be instantiated in the
|
||||
node's primary element.
|
||||
If present, the Private Beacon Server model must only be instantiated on the primary element.
|
||||
|
||||
API reference
|
||||
*************
|
||||
|
|
|
@ -15,8 +15,7 @@ The Remote Provisioning Server does not have an API of its own, but relies on a
|
|||
:ref:`bluetooth_mesh_models_rpr_cli` to control it. The Remote Provisioning Server
|
||||
model only accepts messages encrypted with the node's device key.
|
||||
|
||||
If present, the Remote Provisioning Server model must be instantiated on the primary
|
||||
element.
|
||||
If present, the Remote Provisioning Server model must be instantiated on the primary element.
|
||||
|
||||
Note that after refreshing the device key, node address or Composition Data through a Node Provisioning Protocol
|
||||
Interface (NPPI) procedure, the :c:member:`bt_mesh_prov.reprovisioned` callback is triggered. See section
|
||||
|
|
|
@ -13,8 +13,8 @@ replay protection list (SRPL) of a node that supports the :ref:`bluetooth_mesh_s
|
|||
The Solicitation PDU RPL Configuration Client model communicates with a Solicitation PDU RPL Configuration Server model
|
||||
using the application keys configured by the Configuration Client.
|
||||
|
||||
If present, the Solicitation PDU RPL Configuration Client model must be instantiated on the primary
|
||||
element.
|
||||
If present, the Solicitation PDU RPL Configuration Client model must only be instantiated on the
|
||||
primary element.
|
||||
|
||||
Configurations
|
||||
**************
|
||||
|
|
|
@ -14,8 +14,8 @@ successfully processed by a node, the SSRC field and SSEQ field of the message a
|
|||
The Solicitation PDU RPL Configuration Server does not have an API of its own, and relies on a :ref:`bluetooth_mesh_srpl_cli` to control it.
|
||||
The model only accepts messages encrypted with an application key as configured by the Configuration Client.
|
||||
|
||||
If present, the Solicitation PDU RPL Configuration Server model must be instantiated on the primary
|
||||
element.
|
||||
If present, the Solicitation PDU RPL Configuration Server model must only be instantiated on the
|
||||
primary element.
|
||||
|
||||
Configurations
|
||||
**************
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue