With mesh client, lower element count to just 1

[Alex Ross]

Hello,

We're trying to do the mesh client using the node address sequentially. E.g. in our app we want to have "Device 1, device 2, device 3, etc." currently because of the second element we have to go 2, 4, 6, etc. (The highest number we typically get to is 250 devices)

We have no need for the health/configuration server from what we can tell so maybe we could remove them? Or we could change the node address of the second. 

When I try to set the element count to 1 I get mesh assert crashes, it seems like a lot of changes to make.

Is there away to set the unicast address for the health/config (element 1) to have a different unicast address? Or even the same unicast address?

We really only care about the generic on off client unicast address. One thought we'd have is to have an offset for the unused addresses.

Say offset = 300

generic on off 1: unicast address 1

health/config: unicast address 301

generic on off 2: unicast address 2

health/config: unicast address 302

etc.

The server side is exactly how we want it. All of the models are in one element, therefore we can easily get server 1, server 2, etc. This is ideally how'd we have our clients.

I'm using mesh 5.0.0 and sdk 17.0.2

Thanks!

[Edvin]

Hello,

I am not sure forcing a specific unicast address is the way to go. These are typically set by the provisioner, and is not something that you can set from the node itself. Why do you need them to be exactly 1, 2, 3, ... and so on? Is it not better to just use whatever address that is assigned? What if you in the future want to add a different kind of node, that has more models? This may change the order of your nodes (not if it is already set up, but if you set up a new network with that new node). I don't know, it seems like a lot of work just to get a solution that doesn't seem very robust. 

Or perhaps it is better to use group addresses? Although the name says group address, you have quite a lot of these addresses, and you can assign one to each node. At least to me, this sounds like a better option, instead of putting a lot of work into a flaky solution. 

Best regards,

Edvin

[Alex Ross]

The reason why is because we have an app that we're building the provisioning process around- the node IDs then become what the user can identify them as and that number is tied into a variety of different use cases that has limits up to 250 devices. If we lose half of them it becomes a lot more nuanced in our setup.

I (begrudingly) am now trying to wrap my head around NCS, and I'm wondering if you could maybe point me in the best example for these requirements (I'm trying to pick an example that lines up with my starting point the best)

-Supports LPN 

-Low power in general
-Allows transmit messages up to 8 bytes
-Allow for group messages or individual messages
-Easy to setup with a server NUS 

I was able to do this with the generic on/off service and some size updates but I'm curious if there's a starting point good for this with NCS. (I am a bit overwhelmed from the SDKs to NCS) 

 

[Edvin]

Hello,

Alex Ross said:

the best example for these requirements

I am not that familiar with our Mesh samples in NCS, but did you look into the ble_peripheral_lbs_coex, which looks like it has both BLE and mesh already set up. It should be a quick swap to exchange the LBS with NUS. For the messages up to 8 bytes, you can look into the chat sample. Both of these are found in ncs\nrf\samples\bluetooth\mesh. 

So regarding the question about your address question. Do you want to fix the nodes' unicast address to be 1, 2, 3, ...? In that case, what is your provisioner?

Either way, it sounds like you need to dig into the provisioner's application to figure out where it is set, and then override it. But again, I still think it sounds "cleaner" to use group addresses instead of the unicast addresses for this. 

Best regards,

Edvin