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
107 When a model extends another, it inherits that model's functionality, and
109 leveraging the existing model functionality to avoid defining new opcodes.
110 Models may extend any number of models, from any element. When one model
118 Model extensions are done by calling :c:func:`bt_mesh_model_extend` during
119 initialization. A model can only be extended by one other model, and
121 relationships between the models must be defined by the model implementations.
123 The model extension concept adds some overhead in the access layer packet
127 Model data storage
130 Mesh models may have data associated with each model instance that needs to be
132 data, leveraging the internal model instance encoding scheme. Models can store
135 next time the device reboots, the model's
137 callback gets called when model specific data is found in the persistent
138 storage. The model can retrieve the data by calling the ``read_cb`` passed as