• State Not Answered
  • Replies 17 replies
  • Subscribers 64 subscribers
  • Views 2372 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 281427
Options

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! 

  • 0 in reply to Elfving

    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

  • 0 in reply to kyle goldsteins

    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

  • 0 in reply to Elfving

    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

  • 0 in reply to Elfving

    Hello,

    kyle goldsteins said:
    May I know where to find this?

    Here you are. 3.6.2.1 should be right there, '

    but maybe section 4.2.1 would be be more interesting. Especially figure 4.1.

    kyle goldsteins said:
    May I know where is the composition data held in the nRF52840?

    Yes, that seems to be set on line 159 in model_handler.c.

    I might be of better help if you could explain further why you would need this to be on only one node. There may be other ways to solve this, that are more in line with how Bluetooth mesh works. Eg: expanding the functionality of the models using op-codes and sub-opcodes.

    Best regards,

    Elfving

  • 0 in reply to Elfving

    Hello,

    kyle goldsteins said:
    May I know where to find this?

    Here you are. 3.6.2.1 should be right there,

    but maybe section 4.2.1 would be be more interesting. Especially figure 4.1.

    kyle goldsteins said:
    May I know where is the composition data held in the nRF52840?

    Yes, that seems to be set on line 159 in model_handler.c.

    I might be of better help if you could explain further why you would need this to be on only one node. There may be other ways to solve this, that are more in line with how Bluetooth mesh works. Eg: expanding the functionality of the models using op-codes and sub-opcodes.

    Best regards,

    Elfving

Related