Controlling Servers using unicast address

RE: Controlling Servers using unicast address

Elfving — Mon, 24 Jan 2022 08:41:04 GMT

Hello,

[quote user="kyle goldsteins"] I want to control all these servers from one client alone from a central location[/quote][quote user="kyle goldsteins"]I would like to be able to control these servers individually and not by group addresses.[/quote]

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.

[quote user="kyle goldsteins"](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)[/quote]

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.

[quote user="kyle goldsteins"]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 [/quote]

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.

[quote user="kyle goldsteins"]However, if I have lots of servers, this process can be quite tedious and I would have to keep changing it. [/quote]

Why wouldn't group addresses fix this for you?

[quote user="kyle goldsteins"]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.[/quote]

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

RE: Controlling Servers using unicast address

kyle goldsteins — Fri, 21 Jan 2022 01:51:58 GMT

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

RE: Controlling Servers using unicast address

Elfving — Thu, 20 Jan 2022 11:02:30 GMT

Hello,

[quote user="kyle goldsteins"]May I know where to find this?[/quote]

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.

[quote user="kyle goldsteins"]May I know where is the composition data held in the nRF52840?[/quote]

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

RE: Controlling Servers using unicast address

Elfving — Thu, 20 Jan 2022 11:02:29 GMT

Hello,

[quote user="kyle goldsteins"]May I know where to find this?[/quote]

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.

[quote user="kyle goldsteins"]May I know where is the composition data held in the nRF52840?[/quote]

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

Best regards,

Elfving

RE: Controlling Servers using unicast address

kyle goldsteins — Thu, 20 Jan 2022 01:31:38 GMT

Hi Elfving,

Thank you for your reply.

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/347939#347939"]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.[/quote]

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.

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/347939#347939"]it will probably result in even more issues for you.[/quote]

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

RE: Controlling Servers using unicast address

Elfving — Mon, 17 Jan 2022 08:33:31 GMT

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.

[quote user="kyle goldsteins"]Any idea for this?[/quote]

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

RE: Controlling Servers using unicast address

kyle goldsteins — Sun, 16 Jan 2022 06:22:00 GMT

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

RE: Controlling Servers using unicast address

Elfving — Fri, 14 Jan 2022 07:27:07 GMT

Hello Kyle,

[quote user="kyle goldsteins"]What I plan on doing is implement a lighting system on a small scale building (about 100 lights) using the client/server system.[/quote]

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

RE: Controlling Servers using unicast address

kyle goldsteins — Fri, 14 Jan 2022 01:46:07 GMT

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.

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/347316#347316"]Then you might want as many elements as physical bulbs, since you want to control them independently.[/quote]

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

RE: Controlling Servers using unicast address

Elfving — Wed, 12 Jan 2022 09:01:44 GMT

Hey Kyle,

[quote user="kyle goldsteins"]

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

[/quote]

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

RE: Controlling Servers using unicast address

kyle goldsteins — Wed, 12 Jan 2022 01:45:03 GMT

Hi Elfving!

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/347169#347169"]but all of these elements are in fact on the same node that you are struggling with provisioning?[/quote]

Yes that is correct!

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/347169#347169"]As you are left with 44 elements I assume you have 2 models per element.[/quote]

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

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/347169#347169"]Though could you expand a bit on why would need all these elements?[/quote]

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

RE: Controlling Servers using unicast address

Elfving — Tue, 11 Jan 2022 13:12:52 GMT

Hello Kyle!

[quote user="kyle goldsteins"]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[/quote]

Yes, now it seems that we are on the same page. I thought you were dealing with a 44th node, but all of these elements are in fact on the same node that you are struggling with provisioning?

Due to the max transport PDU size of 350 octets, the node is limited by the composition data size restrictions. This has little to do with the provisioner and the app itself though.

Out of this possible 380, 10 bytes are taken by some meta data. Then, each element consumes 4 bytes and 2 octets per SIG model and 4 octets per Vendor model. If you have 1 element with just SIG models, it gives you a maximum of 183 models. As you are left with 44 elements I assume you have 2 models per element.

[quote user="kyle goldsteins"]Is it possible to properly increase this number so that I could have more elements? [/quote]

No, that would go against the Mesh spec. The list of elements and their models is sent as Composition Page 0, and this has to be a single message.

[quote user="kyle goldsteins"]What do you mean by using virtual addresses? Can the virtual address be used to control the lights on the terminal?[/quote]

Sorry, I meant group addresses. Though there are unicast addresses, virtual addresses and group addresses. Each node has a unicast address, the virtual addresses use a UUID to I identify a node (independent of configuration in network), and the group addresses are configurable to include several elements. If you wanted to include several elements in one address then a group address might be what you are looking for.

[quote user="kyle goldsteins"]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.[/quote]

This issue is referred to as "model overlap". According to the spec: "An element is not allowed to contain multiple instances of models that use the same message in the same way (for example, receive an “On” message)". To fix it put the other model in another element. There is no other way that is according to the spec.

To summarize everything, you should get more nodes in your network to handle all your models and elements. Though could you expand a bit on why would need all these elements?

Best regards,

Elfving

RE: Controlling Servers using unicast address

kyle goldsteins — Tue, 11 Jan 2022 03:01:15 GMT

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'

RE: Controlling Servers using unicast address

kyle goldsteins — Mon, 10 Jan 2022 02:06:23 GMT

Hi! Thanks for the reply!

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/346278#346278"]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.[/quote]

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.

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/346278#346278"]Have you considered using virtual addresses? You dont have to always use unicast.[/quote]

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

[quote userid="103347" url="~/f/nordic-q-a/82886/controlling-servers-using-unicast-address/346278#346278"]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.[/quote]

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.

RE: Controlling Servers using unicast address

Elfving — Wed, 05 Jan 2022 16:05:17 GMT

Hello again!

[quote user=""]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.[/quote]

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.

[quote user=""]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. [/quote]

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

[quote user=""]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?[/quote]

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.

[quote user=""]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?[/quote]

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

RE: Controlling Servers using unicast address

kyle goldsteins — Sun, 02 Jan 2022 13:40:15 GMT

Sure, no problem!

RE: Controlling Servers using unicast address

Elfving — Wed, 22 Dec 2021 15:38:28 GMT

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