toggle quoted messageShow quoted text
Thanks for the reply. Would it not be simpler to allow access to the
bt_mesh structure by moving the definition from net.h to
include/bluetooth/mesh.h. Would this allow access to all data (keys,
sequence, ...) ? Maybe the data is a bit hidden in the structure.
Regarding the JSON format, I think this is a good idea.
2017-09-27 15:55 GMT+02:00 Johan Hedberg <johan.hedberg@...>:
On Wed, Sep 27, 2017, Laczen JMS wrote:
I would like to add persistent storage to my mesh nodes. AfterThere are different ways we could go about this. One option is to extend
provisioning and configuration values would be stored to flash (to
keep it simple a task would be scheduled to see if there are any
changes to the provisioning/configuration data and store if required).
I would like to do this with only minimal changes to the bluetooth
For the model I can get all data in my main routine using calls like:
comp.elem.addr, comp.elem.models.pub->addr, ...
For the mesh data I cannot find a way like this, is there a
possibility to get the netkey, iv_index, sequence, ... ? I would like
to store these values so that bt_mesh_provision() can be used to do
the provisioning when stored provisioning data is found.
our bt_storage API and make write() calls from within the mesh code to
store keys and other values. If we do that then the question is should
the code also perform read() calls upon init, essentially making
bt_mesh_provision() unnecessary. There are some things that anyway need
to be done separate from bt_mesh_provision(), such as application keys
and non-primary network keys.
Another idea (IMO quite nice one) would to be able to use the
Provisioning Database JSON format that should be coming out as a
whitepaper from the SIG. It looks like it's not yet public, so
unfortunately we can't really put any related code upstream for now.
AFAIK Zephyr has a JSON library, so this might not be too much work to