Hi,
How can I send message from servers other than 0x105 and 0x106 to client?
I receive status message in client from servers 0x105 and 0x106.
I can send message to client from the servers 0x105 and 0x106.
But I can't do this using other servers such as 0x107, 0x108, 0x109 etc.
How do I enable that?
Hi,
To understand why this is so, we must look at the particular example which in this case is the light switch example. You can use Figure 2 from the Quick Start Guide for the nRF5 SDK for Mesh as reference.
The nodes and elements: First there is the Provisioner (0x001). The Client (0x100) is set up with four simple on/off clients 0x101, 0x102, 0x103 and 0x104. Then there are a number of Servers that uses addresses 0x105, 0x106, 0x107, etc.
Element 0x101 (Button 1 on the Client) is configured to publish to 0x105 (Server 1), and it also subscribes to the same element (on 0x105). All addresses mentioned thus far have been unicast addresses, which means they are addresses for a single element. There is a one-to-one mapping between the simple on/off client in 0x101 and the simple on/off server in 0x105. The client tracks the state of the server, and the client can tell the server to change state.
Elements 0x102 (Button 2 on Client) and 0x106 (Server 2) works the same.
In addition to the unicast addresses, each Server is also assigned to a group. There is the Odd numbered group (0xC003) for servers 0x105, 0x107, 0x109, etc., and there is the Even group (0xC002) for servers 0x106, 0x108, 0x110, etc. On the client, 0x103 (Button 3) and 0x104 (Button 4) are set to publish to the Odd and Even group respectively.
Since all Servers listen to the Odd or Even group, this means you can change their state from the Client, by publishing to either the Odd or Even group. But since this is a group message, it does not make sense for each and every Server to acknowledge the update or to publish a state change back to the Client. So there is no message going from the Servers to Button 3 or Button 4.
I can imagine two setups that perhaps is what you ask for.
The first setup is to have a Client with more buttons, so that each button is connected to one Server, and each Server publishes a state change to the corresponding button.
The second setup is to use a Control Model, which is a separate node that act as simple on/off Server towards a Client, and that acts as on/off Client towards the Servers. Then that control node can have a state which is either "on" or "off", and the connected button will get updated on this state. And whenever the state is set it sends the appropriate message to the group of Servers.
Note that the second setup is very close to what the light switch example already does. In a sense, Buttons 3 and 4 on the client acts like the Control Model described, as the Client does maintain a status for the whole group of Servers by simply remembering what state change it requested last. A Control Model would only be required if multiple Clients should be able to toggle the state of the group, and those Clients needs to get an update whenever the state of the group toggles.
I highly recommend the Introducing Bluetooth Mesh Networking blog series on bluetooth.org for getting more familiar with the concepts of Bluetooth Mesh. It should provide you with the basic knowledge for designing Bluetooth Mesh solutions.
I also recommend using the latest nRF5 SDK for Mesh version, at the time of writing that is nRF5 SDK for Mesh v2.2.0.
Regards,
Terje
Hi,
To understand why this is so, we must look at the particular example which in this case is the light switch example. You can use Figure 2 from the Quick Start Guide for the nRF5 SDK for Mesh as reference.
The nodes and elements: First there is the Provisioner (0x001). The Client (0x100) is set up with four simple on/off clients 0x101, 0x102, 0x103 and 0x104. Then there are a number of Servers that uses addresses 0x105, 0x106, 0x107, etc.
Element 0x101 (Button 1 on the Client) is configured to publish to 0x105 (Server 1), and it also subscribes to the same element (on 0x105). All addresses mentioned thus far have been unicast addresses, which means they are addresses for a single element. There is a one-to-one mapping between the simple on/off client in 0x101 and the simple on/off server in 0x105. The client tracks the state of the server, and the client can tell the server to change state.
Elements 0x102 (Button 2 on Client) and 0x106 (Server 2) works the same.
In addition to the unicast addresses, each Server is also assigned to a group. There is the Odd numbered group (0xC003) for servers 0x105, 0x107, 0x109, etc., and there is the Even group (0xC002) for servers 0x106, 0x108, 0x110, etc. On the client, 0x103 (Button 3) and 0x104 (Button 4) are set to publish to the Odd and Even group respectively.
Since all Servers listen to the Odd or Even group, this means you can change their state from the Client, by publishing to either the Odd or Even group. But since this is a group message, it does not make sense for each and every Server to acknowledge the update or to publish a state change back to the Client. So there is no message going from the Servers to Button 3 or Button 4.
I can imagine two setups that perhaps is what you ask for.
The first setup is to have a Client with more buttons, so that each button is connected to one Server, and each Server publishes a state change to the corresponding button.
The second setup is to use a Control Model, which is a separate node that act as simple on/off Server towards a Client, and that acts as on/off Client towards the Servers. Then that control node can have a state which is either "on" or "off", and the connected button will get updated on this state. And whenever the state is set it sends the appropriate message to the group of Servers.
Note that the second setup is very close to what the light switch example already does. In a sense, Buttons 3 and 4 on the client acts like the Control Model described, as the Client does maintain a status for the whole group of Servers by simply remembering what state change it requested last. A Control Model would only be required if multiple Clients should be able to toggle the state of the group, and those Clients needs to get an update whenever the state of the group toggles.
I highly recommend the Introducing Bluetooth Mesh Networking blog series on bluetooth.org for getting more familiar with the concepts of Bluetooth Mesh. It should provide you with the basic knowledge for designing Bluetooth Mesh solutions.
I also recommend using the latest nRF5 SDK for Mesh version, at the time of writing that is nRF5 SDK for Mesh v2.2.0.
Regards,
Terje
