Confusion about Server count and Client count in BLE Mesh

RE: Confusion about Server count and Client count in BLE Mesh

bjorn-spockeli — Mon, 18 Sep 2017 06:52:27 GMT

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.

RE: Confusion about Server count and Client count in BLE Mesh

Mitch996 — Tue, 12 Sep 2017 08:32:09 GMT

@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?

RE: Confusion about Server count and Client count in BLE Mesh

Mitch996 — Tue, 12 Sep 2017 08:19:24 GMT

That clarifies it very well.

However, more questions arise:

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?
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.

RE: Confusion about Server count and Client count in BLE Mesh

bjorn-spockeli — Fri, 08 Sep 2017 13:44:14 GMT

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.