Controlling Servers using unicast address

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! 

Parents
  • Hi Elfving,

    The reason why I want all the servers to be on one node is because I want to control all these servers from one client alone from a central location. In addition, I would like to be able to control these servers individually and not by group addresses. (Hence, looking at increasing elements so that each server is subscribed to their own respective element. No server will be subscribed in the same element)

    I am aware that you can allow all the servers to be subscribed to a single element and make the client publish to a specific unicast address if you want to talk to a specific server . However, if I have lots of servers, this process can be quite tedious and I would have to keep changing it. 

    I hope this clears things up as to what I am trying to achieve. Do let me know your thoughts and if there are any more questions on my project. Thanks for your help a lot !

    EDIT: Also you mentioned that the composition data is held in the model_handler.c. I can't seem to find it. I am using Mesh v4.2.0 light lightness example. Perhaps it is defined in another file?

    Best Regards,

    Kyle

  • Hello,

    kyle goldsteins said:
    I want to control all these servers from one client alone from a central location
    kyle goldsteins said:
    I would like to be able to control these servers individually and not by group addresses.

    Any particular reason why you do not want to control the servers using group addresses? You know, you could control them using both group addresses and unicast. You dont have to use just one of the two.

    kyle goldsteins said:
    (Hence, looking at increasing elements so that each server is subscribed to their own respective element. No server will be subscribed in the same element)

    This is only necessary when the servers handle the same types of messages. If the servers you are referring to here are more than just lights, then you could have them in the same element.

    And I don't know if I follow your reasoning here. The amount of elements have nothing to do with whether or not group addresses are used. The spec simply doesn't allow similar models in an element (as that wouldn't allow them to be "identified"/addressed), it isnt an option for situations where one wouldn't need them individually addressed.

    I think the use of the word subscribe might confuse you, maybe "contain" would be better. Elements contain models.

    kyle goldsteins said:
    I am aware that you can allow all the servers to be subscribed to a single element and make the client publish to a specific unicast address if you want to talk to a specific server

    As two individual statements I could agree with this, but the way you described it makes me think you've misunderstood.  The servers aren't addressable, the elements are. A unicast address isn't the address to a server per se, but the address to an element that could contain a server.

    kyle goldsteins said:
    However, if I have lots of servers, this process can be quite tedious and I would have to keep changing it. 

    Why wouldn't group addresses fix this for you?

    kyle goldsteins said:
    EDIT: Also you mentioned that the composition data is held in the model_handler.c. I can't seem to find it. I am using Mesh v4.2.0 light lightness example.

    Ah right. I thought you were using nRF Connect SDK for a second. I'll get back to you with the info for nRF5 SDK for Mesh.

    Best regards,

    Elfving

Reply
  • Hello,

    kyle goldsteins said:
    I want to control all these servers from one client alone from a central location
    kyle goldsteins said:
    I would like to be able to control these servers individually and not by group addresses.

    Any particular reason why you do not want to control the servers using group addresses? You know, you could control them using both group addresses and unicast. You dont have to use just one of the two.

    kyle goldsteins said:
    (Hence, looking at increasing elements so that each server is subscribed to their own respective element. No server will be subscribed in the same element)

    This is only necessary when the servers handle the same types of messages. If the servers you are referring to here are more than just lights, then you could have them in the same element.

    And I don't know if I follow your reasoning here. The amount of elements have nothing to do with whether or not group addresses are used. The spec simply doesn't allow similar models in an element (as that wouldn't allow them to be "identified"/addressed), it isnt an option for situations where one wouldn't need them individually addressed.

    I think the use of the word subscribe might confuse you, maybe "contain" would be better. Elements contain models.

    kyle goldsteins said:
    I am aware that you can allow all the servers to be subscribed to a single element and make the client publish to a specific unicast address if you want to talk to a specific server

    As two individual statements I could agree with this, but the way you described it makes me think you've misunderstood.  The servers aren't addressable, the elements are. A unicast address isn't the address to a server per se, but the address to an element that could contain a server.

    kyle goldsteins said:
    However, if I have lots of servers, this process can be quite tedious and I would have to keep changing it. 

    Why wouldn't group addresses fix this for you?

    kyle goldsteins said:
    EDIT: Also you mentioned that the composition data is held in the model_handler.c. I can't seem to find it. I am using Mesh v4.2.0 light lightness example.

    Ah right. I thought you were using nRF Connect SDK for a second. I'll get back to you with the info for nRF5 SDK for Mesh.

    Best regards,

    Elfving

Children
No Data
Related