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.
This MR imposes some determinism in the mapping rule order in the output
file. For each section, the archives are arranged alphabetically
(ascending), and the mapping rules in each archive are arranged by
increasing specificity then alphabetically (ascending). The default
rules remain the very first rule for each section.
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.
This was quite obviously a bad suggestion, and it seems that some
users have actually read the docs attentively enough to have followed
it. Replace be recommendation to create an alias.
Closes https://github.com/espressif/esp-idf/issues/3889
It was observed that after sending credentials, if the first
Wi-Fi conection attempt fails, the Wi-Fi provisioning managager
ignores subsequent Wi-Fi events. So, even if the device eventually
connects to the AP, the provisioning stays on indefinitely.
Changing a check so that subsequent events are also captured and
provisioning finishes successfully.
esp_mqtt_abort_connection: Fixed an issue which could result in a race condition and subsequent crash
esp_mqtt: Change an error print to use ESP_LOGE instead of ESP_LOGI
Move Sending MQTT connect message log from Info to Debug level
docs: Makes clear that publish API could block
Change the message printed after MQTT connection failure
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.
The replay protection list of Provisioner should be at least equal
to the number of nodes with the precondition that each node contains
only one element.
The help information of replay protection list is updated, and the
maximum number of nodes for Provisioner is adjusted based on the
replay protection list size.
