Confusion about Server count and Client count in BLE Mesh

[Mitch996]

In the example code, I found this:

#define SERVER_COUNT (3)
#define CLIENT_COUNT (SERVER_COUNT + 1)

I'm having 2 boards (maybe extremely problematic) and I want to have the 2 form a connection using the mesh advertising packets, I don't know if that's possible (i.e. should I get more boards? Like, 2 more? ), I don't know 100% what to do if 2 boards can work, but I'm really confused about the count.

As far as I know, server is more closely related to provisionee, while client is more related to provisioner, so in a mesh network, there should be more server than client. One provisioner can configure an entire network full of provisionees.

Yet these 2 macros clearly tell another story.

What did I get wrong?

Also, please tell me if 2 dev boards are enough to form a network? I want it for demonstration.

[bjorn-spockeli]

Hi Mitch,

I understand the confusion and I strongly recommend taking a look at the Bluetooth Mesh Profile Specification, specifically section 2.3 Architectural concepts. We have a condensed version here on our Infocenter.

I'll try to explain why the Client count is set the way it is.

Each node in a Bluetooth Mesh has at least one element , which is an addressable entity with the node. It is this address that other nodes in the mesh use when they want to send a message to that specific node. Within the element(s) you'll find the Models, which define the basic functionality of the node. There are three types of models

• Server model: A server model is composed of one or more states spanning one or more elements. The server model defines a set of mandatory messages that it can transmit or receive, the behavior required of the element when it transmits and receives such messages, and any additional behavior that occurs after messages are transmitted or received.

• Client model: A client model defines a set of messages (both mandatory and optional) that a client uses to request, change, or consume corresponding server states, as defined by a server model. The client model does not have state.

• Control model: A control model may contain client model functionality to communicate with other server models and server model functionality to communicate with other client models.

Each element may include multiple models, but an element is not allowed to contain multiple instances of models that use the same message.

So, the way the examples works is that each Light Control Server example sets up a single element that contains a Simple OnOff Server Model, which is used to turn on an off the light. Each element has a unicast address which is unique for that element, but it also has a group address, which is common for all three elements.

Since an element can only contain one instance of a Model ,the Light Control Client example sets up 4 elements, each containing a Simple OnOff Client Model. The three first are used to address each of the three servers individually, while the last element set up to use the group address so that you can turn on and off all the lights at simultaneously.

Hope this clarifies it.

If you want to demonstrate the Bluetooth Mesh, then I would recommend using at least 3 nodes and place the nodes so that they are not all in range of each other, i.e. Node A is in range of node B, node B is in range of node C, but node C is not in range of node A.

[Mitch996]

That clarifies it very well.

However, more questions arise:

1. So if I want to control 100 lights, I have to have 100 models in one element, with each and single model storing a set of information unique to its corresponding node? It sounds conservative and dogmatic?
2. I kinda have all 3 nodes stacked closely together on my desk... what's the worst that could happen? And I failed consistently to provision+configure them for the past 6 hours or so.

[Mitch996]

@Bjørn Spockeli BTW, if all 3 nodes were successfully prov-ed and config-ed, the program should enter provisioner_config_successful_cb and reach these lines:

 hal_led_blink_ms(LEDS_MASK, 100, 4);
    m_device_state = DEVICE_STATE_RUNNING;

Right?

[bjorn-spockeli]

Q1: If you want to control 100 lights individually you will have to add one element (each contains one model) per light on the Light Control Client side. On the Light Control Server side you only need one element with one model. This is how the BLE Mesh specification defines it, the element is the addressable entity of a mesh node. So if you had an element with two models both subscribing to the same ON/OFF message, then you would not know which model the message was intended for if you send it to the unicast address of the element.

Q2: That should not be an issue, my suggestion on having them apart was only to show that the nodes are relaying messages to the nodes that are not in range of the client.

Q3: Yes, the provisioner(i.e. the light control client) should enter the running state.