Hi Vikrant,

On Sat, May 12, 2018, vikrant8051 wrote:
> How to save (SIG or Vendor) Model states on SoC flash ? Is it going to be
> depend upon setting layer which is newly introduce concept or gonna
> completely independent as part of App layer ?

The currently implementation is purely based on settings, so you can
just register your own settings subpath to store app-specific
information. I'd advise to use something else than "bt/" however, since
that's what we use for stack-internal data and wouldn't want application
code to conflict with it (or different apps to confict with each other).

> There are 2 types of Persistent Data in context of #BluetoothMesh:
> 1) constant
>      (which is created & saved during provisioning & configuration )
>
> 2) non - constant
>   ( eg. Sequence no., Models states etc.)
>
> Is current implementation using same sector of flash for both ?

It all uses the same settings API, i.e. no attempt is currently made to
split things into different categories.

I think you might have a slightly wrong idea of the different categories
of data that mesh has. The only really constant values with Mesh 1.0 are
the unicast address and the device key. And even these will change if
you do a node reset and reprovision.

Everything else, including Network Key, Application Keys, etc can and
often will change during the lifetime of the mesh network. So if you
really want to try to categorize the data into two two categories it'd
be frequently changing data, and infrequently changing (but not
constant) data.

> If Node is receiving 100 messages a day in which destination address could
> be it's own or group address for which it has subscribed, then what will be
> life of that device  (assuming SoC flash supports 10K erase cycles) as per
> FCB based current implementation ?

It depends on how you've configured CONFIG_BT_MESH_SEQ_STORE_RATE. The
nice thing with the settings API is that we could use its "export"
callback together with settings_save() to support power-loss triggered
flash writing on boards that have a small backup power source and are
able to give an interrupt of some sorts when the main one gets lost.

> Is there any documentation which shows approximate life span of
> #BluetoothMesh NODE in different scenarios if we go ahead with #FCB ( or
> upcoming #NVS layer) ?

No, and as I said, it depends on your configuration and your hardware. I
welcome you to do these calculations for some reference implementation
(hardware included) and share your results with the Zephyr project
community!

> If we use #meshctl, then sometimes it complete provisioning but it fails
> after executing
>
> --> appkey-add 1
>
> & something constantly goes on #meshctl terminal. Is anyone observed same ?

I haven't. Btw, may I ask that you in the future split different topics
to different emails? Otherwise these unrelated things may get lost on
people.

> If provisioning or configuration fails & there is no hardware reset button
> to trigger bt_mesh_reset() in that case, how to push device into factory
> reset mode ? Any Idea ?

That depends on your hardware. If it doesn't have any buttons then you
need to reflash it, I suppose.

> My solution is to add vendor state (Let it be Foo) which will be set to "1"
> only after proper provisioning & configuration by provisioner App.
>
> On device side following logic will get execute after every reset
>
>    if(Foo == 0)
>    {
>         bt_mesh_reset( );
>    }

The problem with that is that it's not really generalizable, since
there's no standard way of detecting (on the configuration server side)
when the configuration phase is complete. The best that you might be
able to do in a generic way is to have some timer that's reset after
each received configuration message, and when it expipres assume that
the configuration phase is complete. This is e.g. what the Zephyr LPN
implementation already supports in order to determine when to reduce the
scanning duty cycle (see CONFIG_BT_MESH_LPN_AUTO_TIMEOUT).

Johan