Topics

#BluetoothMesh persistent storage for provisioning data #bluetoothmesh


Kai Ren
 

Hello,

I noticed that zephyr start to support persistent storage for provisioning data like:
{ "Net", net_set },
{ "IV", iv_set },
{ "Seq", seq_set },
{ "RPL", rpl_set },
{ "NetKey", net_key_set },
{ "AppKey", app_key_set },

And I know that it's already added in the sample of ./sample/bluetooth/mesh/, I know that this sample need a provisioner to provision it. I'm curious that does the persistent storage function can be used by the sample of ./sample/bluetooth/mesh_demo/ because this sample is an example of self-provisioning.
Thanks.

Regards,
Kai


Johan Hedberg
 

Hi Kai,

On Fri, May 11, 2018, Kai Ren wrote:
I noticed that zephyr start to support persistent storage for
provisioning data like:
{ "Net", net_set },
{ "IV", iv_set },
{ "Seq", seq_set },
{ "RPL", rpl_set },
{ "NetKey", net_key_set },
{ "AppKey", app_key_set },
Also note that the remaining state storing is coming as part of the
following PR:

https://github.com/zephyrproject-rtos/zephyr/pull/7428

Essentially everything is in place there now, but I still need to think
a little about how to handle IV Update - we may need to store in some
circumstances information about how many hours the node has been in a
certain state.

And I know that it's already added in the sample of
./sample/bluetooth/mesh/, I know that this sample need a provisioner
to provision it. I'm curious that does the persistent storage function
can be used by the sample of ./sample/bluetooth/mesh_demo/ because
this sample is an example of self-provisioning.
I think there might be some conflicts, or at least interesting
artifacts, since mesh_demo calls itself bt_mesh_provision() and
restoring values from flash does essentially the same thing. That said,
I'm not sure what the benefit would be? Perhaps to restore the Seq and
RPL? You could try it, but be sure to call settings_load() only after
bt_mesh_provision() so that stored values overwrite the ones hard-coded
in the app. Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.

Johan


Kai Ren
 

Thanks for the reply!

The problem I suffered is that: when I run mesh_demo on microbit, I can't restore SEQ after a reset, when means that if a GenericOnOff client reset unexpected, I need to make this client catch up the SEQ on GenericOnOff server. 

I saw that there are two functions which seem to be store and restore SEQ,

void board_seq_update(u32_t seq);

static u32_t get_seq(void);

but get_seq() is called in board initial, but I don't find any piece about board_seq_update().

I agree with you, mesh_demo doesn't need persistent storage because its netkey, devkey and appkey are already in flash memory, but one thing need to be solved is SEQ. 
Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.
What does it mean? 

Kai




Johan Hedberg
 

Hi Kai,

Please check the PR I referenced earlier. I've added a patch there to
convert mesh_demo to use settings. It was actually the other way around
that it made sense to do the calls: first settings_load() and then
bt_mesh_provision(). That way we can catch an -EALREADY return from
bt_mesh_provision() which tells us that calling configure() should not
be done.

Johan

On Fri, May 11, 2018, Kai Ren wrote:
Thanks for the reply!

The problem I suffered is that: when I run mesh_demo on microbit, I can't restore SEQ after a reset, when means that if a GenericOnOff client reset unexpected, I need to make this client catch up the SEQ on GenericOnOff server. 

I saw that there are two functions which seem to be store and restore SEQ,

void board_seq_update( u32_t seq);

static u32_t get_seq( void );

but get_seq() is called in board initial, but I don't find any piece about board_seq_update().

I agree with you, mesh_demo doesn't need persistent storage because its netkey, devkey and appkey are already in flash memory, but one thing need to be solved is SEQ. 


Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.
What does it mean? 

Kai


Kai Ren
 

Hi Johan,

Following your suggestion, I just did a test on it after git fetch 7428.
After compiling and running "mesh_demo", at least, sequence number store and restore work well on my side. I use micro:bit as the platform. : 
But I have a question: when sequence number reach to 0x1A, I reset the board, after restoring, then I pressed button to send message, sequence number start at 0x89, what is the consideration on this? 

Kai


Johan Hedberg
 

Hi Kai,

On Fri, May 11, 2018, Kai Ren wrote:
Following your suggestion, I just did a test on it after git fetch
7428. After compiling and running "mesh_demo", at least, sequence
number store and restore work well on my side. I use micro:bit as the
platform. :  But I have a question: when sequence number reach to
0x1A, I reset the board, after restoring, then I pressed button to
send message, sequence number start at 0x89, what is the consideration
on this? 
The idea is to avoid excessive flash writes (or worse, flash erases).
There's a variable that's set with CONFIG_BT_MESH_SEQ_STORE_RATE. It
controls that only the Nth sequence number increment gets stored. Since
only the Nth sequence gets stored, we have to add N upon bootup to the
stored value to ensure that we start with something that's guaranteed to
be higher than the last sent message when the board was powered off.

Btw, the PR is already merged to master, so you can just the master
branch from now on.

Johan