Controlling Servers using unicast address

[kyle goldsteins]

Hi everyone, I am looking into controlling servers using light_lightness server in 17.0.2 

As far as I know, you can control the the publishing from client side by changing publishing address to the specific unicast address.  Since I want to control quite a number of servers, having too many elements in the NRF mesh app is not possible due to composition data size restrictions. Hence, using unicast address to control individual servers will be an alternative. 

What I would like to know is that if its possible to send commands via J-link to control specific servers using their unicast address instead? The process of changing unicast address on nrf mesh app can be quite troublesome as you would have to keep changing it. 

I am aware that you can subscribe the servers into an element so you can control them all at once. But is it possible to control them individually despite being in the same group? For instance, using unicast address on J-link as a command and not changing unicast address on the nrf mesh app. If its possible, how should I go about achieving this?

Thanks for your help in advance! 

[Elfving]

Hey Kyle! Sorry about the delay.

I will have to get back to you on this. Unfortunately, due to the holidays you might have to expect both limited help and slower responses on DevZone.

Best regards,

Elfving

[kyle goldsteins]

Sure, no problem!

[kyle goldsteins]

Hi Elfving!

Elfving said:

but all of these elements are in fact on the same node that you are struggling with provisioning?

Yes that is correct!

Elfving said:

As you are left with 44 elements I assume you have 2 models per element.

I have checked on the nRF mesh app. Currently, there is only one model per element called 'Light Lightness Client'.

Elfving said:

Though could you expand a bit on why would need all these elements?

This is because I am looking at controlling the servers individually from the client node. Group addresses isn't what I am looking for as that would mean one command would be sent to all the servers.. Hence, it would be most ideal if I was able to have more elements so that I can control more servers individually.

I have managed to increase the number of elements to 60 in my previous reply, please take a look at it and let me know how to solve the ' sending composition data get' issue if its possible

Best regards,

Kyle

[Elfving]

Hey Kyle,

kyle goldsteins said:

This is because I am looking at controlling the servers individually from the client node.

You should already be able to do that as long as all the models are different/ handle different messages. So the questions is why you would need this many models of the same kind on the same node?

A typical situation where this is considered, is if you are making a lamp with multiple physical bulbs/LEDs. Then you might want as many elements as physical bulbs, since you want to control them independently. Needing more than 44 of them however is a bit surprising.

Best regards,

Elfving

[kyle goldsteins]

Hi Elfving,

What I plan on doing is implement a lighting system on a small scale building (about 100 lights) using the client/server system.

Elfving said:

Then you might want as many elements as physical bulbs, since you want to control them independently.

Yes, I want to be able to control these lights individually so the number of elements would be the same as the number of physical light bulbs. In this case, that would mean 100 physical light bulbs for my system.

Best regards,

Kyle

[Elfving]

Hello Kyle,

kyle goldsteins said:

What I plan on doing is implement a lighting system on a small scale building (about 100 lights) using the client/server system.

Sounds great!

In that case I assume the 100 lights would be somewhat spread out physically, and be different nodes. You might even only need one element per node, and maybe two servers. That would be far less than what the composition data size restrictions are limiting you to (the restrictions only count for one node). Additionally the light servers would all be on different elements, so they are controllable individually (each node has its own elements).

Does that sound like a plan, or do you need all the lights to be on the same node?

Best regards,

Elfving

[kyle goldsteins]

Hi Elfving,

Thank you for your suggestion! However, what I am looking at is for all the lights to be on the same node? Any idea for this?

Best Regards,

Kyle

[Elfving]

Hey Kyle,

I am still having trouble understanding why you would want this, but at least now I know this actually is what you want.

kyle goldsteins said:

Any idea for this?

No. This will go against the composition data size restrictions of the node, and the Mesh spec. For more info on why this is a restriction you can take a look at section 3.6.2.1 in the Mesh Profile spec.

You could create a proprietary Mesh solution however, and go against the spec. This isn't something I can recommend however, and it will probably result in even more issues for you. If this is what you want to do, then I wouldn't rely too much on the examples and such however - as breaking the composition data size restrictions won't be the only massive change you're going to make.

Though if you want all the models to be on the same node, I assume the Bluetooth part of Mesh isn't that important to you?

Best regards,

Elfving

[kyle goldsteins]

Hi Elfving,

Thank you for your reply.

Elfving said:

For more info on why this is a restriction you can take a look at section 3.6.2.1 in the Mesh Profile spec.

May I know where to find this? I have tried looking it up at the Mesh Profile (MESH) document but there isn't a 3.6.2.1 section.

Elfving said:

it will probably result in even more issues for you.

As I have mentioned, the issue when increasing the number of elements will cause the node to be stuck at "sending composition data get" in the nRF mesh app when provisioning. May I know where is the composition data held in the nRF52840?

Best Regards,

Kyle