Lines Matching full:model

13 The functionality of a mesh node is represented by models. A model implements
17 model. Conventionally, each element represents a single aspect of the mesh
23 The node's element and model structure is specified in the node composition
27 behavior in the `Bluetooth Mesh Model Specification
39 The opcode list contains all message opcodes the model can receive, as well as
42 model in each element.
44 The full opcode list must be passed to the model structure in the composition
54 The AppKey list contains all the application keys the model can receive
56 will be passed to the model.
58 The maximum number of supported application keys each model can hold is
66 A model will process all messages addressed to the unicast address of their
68 list). Additionally, the model will process packets addressed to any group or
72 The maximum number of supported addresses in the Subscription list each model
77 Model publication
87 When publishing messages with :c:func:`bt_mesh_model_publish`, the model
90 unprompted model messages, as it passes the responsibility of selecting
94 To support publishing with the publication parameters, the model must allocate
97 publication for the publication message. To support this, the model must
100 message is published, allowing the model to change the payload to reflect its
103 By setting :c:member:`bt_mesh_model_pub.retr_update` to 1, the model can
117 When a model extends another, it inherits that model's functionality, and
119 leveraging the existing model functionality to avoid defining new opcodes.
120 Models may extend any number of models, from any element. When one model
128 Model extensions are done by calling :c:func:`bt_mesh_model_extend` during
129 initialization. A model can only be extended by one other model, and
131 relationships between the models must be defined by the model implementations.
133 The model extension concept adds some overhead in the access layer packet
137 Model data storage
140 Mesh models may have data associated with each model instance that needs to be
142 data, leveraging the internal model instance encoding scheme. Models can store
145 next time the device reboots, the model's
147 callback gets called when model specific data is found in the persistent
148 storage. The model can retrieve the data by calling the ``read_cb`` passed as
152 When model data changes frequently, storing it on every change may lead to
153 increased wear of flash. To reduce the wear, the model can postpone storing of
158 callback for every model that has requested storing of data. The model can
164 while model data is being stored. It is recommended to use this option and the
176 may use the :ref:`bluetooth_mesh_models_cfg_srv` model or, if supported,
177 the :ref:`bluetooth_mesh_lcd_srv` model.
183 is mandatory for all mesh devices. It contains the element and model composition,
190 and is mandatory for all mesh devices. A model may extend and/or correspond to one
191 or more models. A model can extend another model by calling :c:func:`bt_mesh_model_extend`,
192 or correspond to another model by calling :c:func:`bt_mesh_model_correspond`.
193 :kconfig:option:`CONFIG_BT_MESH_MODEL_EXTENSION_LIST_SIZE` specifies how many model
222 messages that are transmitted by a model in a response to a received message, also called
250    When a model sends several messages in a row, it may happen that the messages are not sent in
255    when a set of messages originated by the same model needs to be sent in a certain order.
268 Kconfig option. When enabled, each model can enable or disable the delayable publication by setting