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!

[Elfving]

Hello again!

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.

Would you mind expanding a bit on how you see this restriction in the app? The composition data size restrictions should restrict the amount of elements on a node, didn't think it also restricted the amount of elements registered on the app.

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. 

Have you considered using virtual addresses? You dont have to always use unicast.

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?

I believe you might have misunderstood how that works.. or maybe I am misunderstanding you. Nodes contain elements which contain models which contain states. That is simply the hierarchy it uses, no matter how you configure it. Think of nodes as a physical entity. The element simply has an address, and passes the message on to the model that uses it. How the server handles the message is up to the server, and you can modify that as you please.

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?

If you want to automate some of the messages and respond to commands using the terminal, then I would recommend having a look at the Mesh Chat example and see how that is implemented. Maybe use that as a starting point.

Best regards,

Elfving

[kyle goldsteins]

Hi! Thanks for the reply! 

Elfving said:

Would you mind expanding a bit on how you see this restriction in the app? The composition data size restrictions should restrict the amount of elements on a node, didn't think it also restricted the amount of elements registered on the app.

Sure. As of now, the maximum number of elements that I have managed to get is 44 (modified in nrf_mesh_config_app). Anything above 44 and the node is unable to be provisioned. I have found out that the composition data should not exceed the access_message_length_max which is 380. Is it possible to properly increase this number so that I could have more elements? I have tried changing from 380 to a larger number and the code did not produce any error, but despite this the node could not be provisioned when I tried to configure it in the nRF Mesh app. If this number can be increased then the composition data size would not exceed the access_message_length_max.

Elfving said:

Have you considered using virtual addresses? You dont have to always use unicast.

What do you mean by using virtual addresses? Can the virtual address be used to control the lights on the terminal?

Elfving said:

I believe you might have misunderstood how that works.. or maybe I am misunderstanding you. Nodes contain elements which contain models which contain states. That is simply the hierarchy it uses, no matter how you configure it. Think of nodes as a physical entity. The element simply has an address, and passes the message on to the model that uses it. How the server handles the message is up to the server, and you can modify that as you please.

Regarding this. Yes I am aware about the hierarchy. Lets say I have 2 servers and I subscribe them to a model under the same element in Light lightness client. This means that in the J-link, if I were to send a command that corresponds to that element to activate the lights, both servers will receive the command. What I hope to achieve is that the 2 servers can be controlled individually even though they are subscribed in the same element. I know that the easier way would be to place these 2 servers in separate models under separate elements. However, as I am facing the issue of the composition data size, I am unable to get more than 44 elements. 

Therefore, I was thinking that if increasing the number of elements is not possible, then controlling servers individually (even in the same model under the same element) would be the alternative to my problem.

[kyle goldsteins]

Hi, just an update

I managed to increase the element count to 60. I commented out the NRF_MESH_STATIC_ASSERT in config_server.c for the composition data size. However, I am unable to go above 60 when trying to provision the client. The code is able to build and run, but when configuring the client, it gets stuck at 'sending composition data get'