how many device

RE: how many device

tesc — Fri, 13 Apr 2018 16:16:14 GMT

No problem, I know.

It was not for you, but for other people reading this thread in the future. (=

RE: how many device

pca10056 — Thu, 12 Apr 2018 13:55:02 GMT

no it also me that asked that question. just too be sure that someone could answer, but stille thanks

RE: how many device

tesc — Tue, 10 Apr 2018 16:24:51 GMT

Hi,

For anyone still looking for the answer. You will find it in this thread: change time on how often health server send out

Regards,
Terje

RE: how many device

pca10056 — Mon, 09 Apr 2018 06:36:05 GMT

hello

do you know where you can change how often the health server model should send out

and if yes, where do I do it

RE: how many device

pca10056 — Thu, 05 Apr 2018 08:49:48 GMT

thanks again, just as just one last thing that's how do I make a counter / a timestamp so i now when i last a health status message

RE: how many device

leonwj — Thu, 05 Apr 2018 07:29:36 GMT

hello,

If you look at the latest v1.0.1 version of the mesh lightswitch demo, you will see that Nordic have implemented the Health client/server model. So every 10 seconds (although this is configurable) the provisioned/configured servers will publish a health status message back to the client.

If the client fails to get a health status in any timeframe from a specific server node then you could determine that the server node is not ready or functional and base your firmware logic off that.

Let us know if you need any additional clarification.

Regards,

RE: how many device

pca10056 — Thu, 05 Apr 2018 06:59:42 GMT

thanks, do not know if you can help with this too, but is there a way the client can detect that the node is turned off for a while, so the client not write to node, before the node is ready

RE: how many device

leonwj — Thu, 05 Apr 2018 04:08:17 GMT

hello pca10056,

Within Bluetooth Mesh, only the Provisioner device is aware of which devices have been configured into the mesh network and as such it is the sole arbiter of the make up of any single mesh network. It is also (via whatever persistent storage mechanism you choose) the only device within the mesh network that knows the mesh unicast addresses of all the nodes (along with other vital pieces of information).

The current (v1.0) Mesh specification does not specify the format in which this mesh network meta-data is held or how an implementer should either backup that data or provide resilience/failover. I believe that there are moves afoot to establish a JSON type format for provisioning data which can be stored/accessed/restored etc.

Within the Nordic stack, if you look at the light-switch demo, the client (which also acts as the provisioner) stores this data in persistent storage (flash). Look for the dsm_* for the persistent storage functions and specifically the provisioned_device_handles_load(void) function (in main.c) (see snippet below...) which determines the number of nodes that the light-switch client has provisioned/configured into its mesh..

/**
 * Retrieves stored device state manager configuration.
 * The number of provisioned devices is calculated from the number of device keys stored. The device
 * key for each server is stored on provisioning complete in the `provisioner_prov_complete_cb()`.
 *
 * @returns Number of provisioned devices.
 */
static uint16_t provisioned_device_handles_load(void)
{
    uint16_t provisioned_devices = 0;

Regards,