With mesh client, lower element count to just 1

RE: With mesh client, lower element count to just 1

Edvin — Tue, 07 Feb 2023 12:54:57 GMT

Hello,

[quote user="aross11"]the best example for these requirements[/quote]

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

RE: With mesh client, lower element count to just 1

Alex Ross — Mon, 06 Feb 2023 14:00:35 GMT

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)

RE: With mesh client, lower element count to just 1

Edvin — Tue, 31 Jan 2023 14:31:46 GMT

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