Until now the choice of reliable sending (segmented messages with
acks) was implicitly dependent on the size of the payload. Add a new
member to the bt_mesh_model_pub to force using segment acks even when
the payload would fit a single unsegmented message.
When PB-GATT support has been enabled the provisioning code "borrows"
the buffer from the proxy code. However, the way that initialization
was happening the proxy buffers were initialized only after
provisioning initialization, resulting in a corrupted buffer with
buf->data pointing to NULL. Reorder the initialization calls so that
proxy is done first and provisioning only after it.
Allow models to skip a periodic publish interval by returning an error
from the publish update callback.
Previously, an error return from publish update would cancel periodic
publishing. This can't be recovered from, and as such, no valid model
implementation could return an error from this callback, and there was
no way to skip a periodic publish.
The function bt_mesh_ctl_send() used to support maximum length of
11 bytes. The segmentation complies with the BLE Mesh Standard.
The ack is disabled in case of non unicast address.
When fast provisioning is enabled, Provisioner shall not
ignore messages from the nodes whose addresses are not in
the provisioning database. Because other nodes which are
not provisioned by the Primary Provisioner will send node
address messages to the Primary Provisioner.
Previously only mesh node info is supported to be stored
in flash. So when trying to reset the node, we only need
to judge if the BLE_MESH_VALID flag is set.
Currently we support storing both node & Provisioner info
in flash, when trying to erase the node info from flash,
the BLE_MESH_NODE flag will be checked. So we need to set
bt_mesh.flags to 0 when all the erase operations are done.
During BLE Mesh Provisioner initialization, the stack will restore
the nodes information if settings storage is enabled.
Previously when a failure happens (e.g. found the same uuid) during
the restore procedure, the information of the following nodes will
not be restored and error will be directly returned.
But this will introduce some problem with user experience, because
some newly provisioned nodes information will not be restored and
Provisioner will not be able to control those nodes.
So we change the operation here, when a failure happens during the
restore procedure, Provisioner will only ignore the information of
the current node and continue restoring other nodes information.
With this change, if a Provisioner has provisioned the maximum
number of nodes, it can still report the unprovisioned device
beacon from other nodes to the application layer. And this will
be more reasonable compared with the previous implementation.
Previously when the node array of Provisioner is full, no beacon
from unprovisioned devices will be reported, only some warning
logs will be given.
Previously only check the node address when it is assigned by the
application layer. Here we also check the address when the address
is allocated internally. And this will be useful when some mesh
internal tests are performed.
Previously the BLE_MESH_MAX_STORED_NODES option is added for
internal mesh test, which will be a little confusing for the
users to understand.
Here we remove this option, instead the BLE_MESH_MAX_PROV_NODES
will be used for all the cases. For mesh internal test, when
the test function is called to add some nodes info, the info
will be stored in the array of provisioned nodes directly.
Using the ble mesh white list test functions, a node can choose to
only receive mesh messages from a specific node and relay the
messages for it. Messages from other nodes will be ignored.
1. BLE Mesh Core
* Provisioning: Node Role
* PB-ADV and PB-GATT
* Authentication OOB
* Provisioning: Provisioner Role
* PB-ADV and PB-GATT
* Authentication OOB
* Networking
* Relay
* Segmentation and Reassembly
* Key Refresh
* IV Update
* Proxy Support
* Multiple Client Models Run Simultaneously
* Support multiple client models send packets to different nodes simultaneously
* No blocking between client model and server
* NVS Storage
* Store BLE Mesh node related information in flash
* Store BLE Mesh Provisioner related information in flash
2. BLE Mesh Models
* Foundation Models
* Configuration Server Model
* Configuration Client Model
* Health Server Model
* Health Client Model
* Generic
* Generic OnOff Server
* Generic OnOff Client
* Generic Level Server
* Generic Level Client
* Generic Default Transition Time Server
* Generic Default Transition Time Client
* Generic Power OnOff Server
* Generic Power OnOff Setup Server
* Generic Power OnOff Client
* Generic Power Level Server
* Generic Power Level Setup Server
* Generic Power Level Client
* Generic Battery Server
* Generic Battery Client
* Generic Location Server
* Generic Location Setup Server
* Generic Location Client
* Generic Admin Property Server
* Generic Manufacturer Property Server
* Generic User Property Server
* Generic Client Property Server
* Generic Property Client
* Sensor Server Model
* Sensor Server
* Sensor Setup Server
* Sensor Client
* Time and Scenes
* Time Server
* Time Setup Server
* Time Client
* Scene Server
* Scene Setup Server
* Scene Client
* Scheduler Server
* Scheduler Setup Server
* Scheduler Client
* Lighting
* Light Lightness Server
* Light Lightness Setup Server
* Light Lightness Client
* Light CTL Server
* Light CTL Setup Server
* Light CTL Client
* Light CTL Temperature Server
* Light HSL Server
* Light HSL Setup Server
* Light HSL Client
* Light HSL Hue Server
* Light HSL Saturation Server
* Light xyL Server
* Light xyL Setup Server
* Light xyL Client
* Light LC Server
* Light LC Setup Server
* Light LC Client
3. BLE Mesh Applications
* BLE Mesh Node
* OnOff Client Example
* OnOff Server Example
* BLE Mesh Provisioner
* Example
* Fast Provisioning
* Vendor Fast Prov Server Model
* Vendor Fast Prov Client Model
* Examples
* Wi-Fi & BLE Mesh Coexistence
* Example
* BLE Mesh Console Commands
* Examples
