Sample description

The Bluetooth® Mesh chat sample demonstrates how the mesh network can be used to facilitate communication between nodes by text, using the Chat Client model.


The sample supports the following development kits:

Hardware platforms


Board name

Board target

nRF54L15 PDK




nRF52 DK




nRF52840 DK




nRF21540 DK




The sample also requires a smartphone with Nordic Semiconductor’s nRF Mesh mobile app installed in one of the following versions:


By means of the mesh network, the clients as mesh nodes can communicate with each other without the need of a server. The mesh chat sample is mainly designed for group communication, but it also supports one-on-one communication, as well as sharing the nodes presence.

This sample is used in Creating a new model as an example of how to implement a vendor model for the Bluetooth Mesh in nRF Connect SDK.

The clients are nodes with a provisionee role in a mesh network. Provisioning is performed using the nRF Mesh mobile app. This mobile application is also used to configure key bindings, and publication and subscription settings of the Bluetooth Mesh model instances in the sample. After provisioning and configuring the mesh models supported by the sample in the nRF Mesh mobile app, you can communicate with other mesh nodes by sending text messages and obtaining their presence using the shell module.


The provisioning is handled by the Bluetooth Mesh provisioning handler for Nordic DKs. It supports four types of out-of-band (OOB) authentication methods, and uses the Hardware Information driver to generate a deterministic UUID to uniquely represent the device.


The following table shows the Bluetooth Mesh chat composition data for this sample:

Element 1

Config Server

Health Server

Chat Client

The models are used for the following purposes:

  • The Chat Client model instance in the first element is used to communicate with the other Chat Client models instantiated on the other mesh nodes.

  • Config Server allows configurator devices to configure the node remotely.

  • Health Server provides attention callbacks that are used during provisioning to call your attention to the device. These callbacks trigger blinking of the LEDs.

The model handling is implemented in src/model_handler.c.

User interface


Can be used to input the OOB authentication value during provisioning. All buttons have the same functionality during this procedure.


Show the OOB authentication value during provisioning if the “Push button” OOB method is used.

Terminal emulator:

Used for the interaction with the sample.


See Configuring and building an application for information about how to permanently or temporarily change the configuration.

Source file setup

This sample is split into the following source files:

  • A main.c file to handle initialization.

  • A file for handling the Chat Client model, chat_cli.c.

  • A file for handling Bluetooth Mesh models and communication with the shell module, model_handler.c.

FEM support

You can add support for the nRF21540 front-end module to this sample by using one of the following options, depending on your hardware:

  • Build the sample for one board that contains the nRF21540 FEM, such as nrf21540dk/nrf52840.

  • Manually create a devicetree overlay file that describes how FEM is connected to the nRF5 SoC in your device. See Set devicetree overlays for different ways of adding the overlay file.

  • Provide nRF21540 FEM capabilities by using a shield, for example the Developing with the nRF21540 EK shield that is available in the nRF Connect SDK. In this case, build the project for a board connected to the shield you are using with an appropriate variable included in the build command, for example SHIELD=nrf21540ek. This variable instructs the build system to append the appropriate devicetree overlay file.

    To build the sample in the nRF Connect for VS Code IDE for an nRF52840 DK with the nRF21540 EK attached, add the shield variable in the build configuration’s Extra CMake arguments and rebuild the build configuration. For example: -DSHIELD=nrf21540ek.

    See nRF Connect for VS Code extension pack documentation for more information.

    See Programming nRF21540 EK for information about how to program when you are using a board with a network core, for example nRF5340 DK.

Each of these options adds the description of the nRF21540 FEM to the devicetree. See Developing with Front-End Modules for more information about FEM in the nRF Connect SDK.

To add support for other front-end modules, add the respective devicetree file entries to the board devicetree file or the devicetree overlay file.

Building and running

This sample can be found under samples/bluetooth/mesh/chat in the nRF Connect SDK folder structure.

To build the sample, follow the instructions in Configuring and building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.


In the nRF repositories, building with sysbuild is enabled by default.


After programming the sample to your development kit, you can test it by using a smartphone with nRF Mesh mobile app installed. Testing consists of provisioning the device and configuring it for communication with other nodes.

After configuring the device, you can interact with the sample using the terminal emulator.

Provisioning the device

The provisioning assigns an address range to the device, and adds it to the mesh network. Complete the following steps in the nRF Mesh app:

  1. Tap Add node to start scanning for unprovisioned mesh devices.

  2. Select the Mesh Chat device to connect to it.

  3. Tap Identify, and then Provision, to provision the device.

  4. When prompted, select an OOB method and follow the instructions in the app.

Once the provisioning is complete, the app returns to the Network screen.

Configuring models

See Configuring mesh models using the nRF Mesh mobile app for details on how to configure the mesh models with the nRF Mesh mobile app.

Create a new group and name it Chat Channel, then configure the Vendor model on the Mesh Chat node:

  • Bind the model to Application Key 1.

  • Set the publication parameters:

    • Destination/publish address: Select the created group Chat Channel.

    • Publication interval: Set the interval to recommended value of 10 seconds.

    • Retransmit count: Change the count as preferred.

  • Set the subscription parameters: Select the created group Chat Channel.

Interacting with the sample

  1. Connect the development kit to the computer using a USB cable. The development kit is assigned a COM port (Windows), ttyACM device (Linux) or tty.usbmodem (MacOS).

  2. Connect to the kit that runs this sample with a terminal emulator that supports VT100/ANSI escape characters (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.

  3. Enable local echo in the terminal to see the text you are typing.

After completing the steps above, a command can be sent to the sample. The sample supports the following commands:

chat --help

Prints help message together with the list of supported commands.

chat presence set <presence>

Sets presence of the current client. The following values are supported: available, away, dnd, inactive.

chat presence get <node>

Gets presence of a specified chat client.

chat private <node> <message>

Sends a private text message to a specified chat client. Remember to wrap the message in double quotes if it has 2 or more words.

chat msg <message>

Sends a text message to the chat. Remember to wrap the message in double quotes if it has 2 or more words.

Whenever the node changes its presence, or the local node receives another model’s presence the first time, you will see the following message:

<0x0002> is now available

When the model receives a message from another node, together with the message you will see the address of the element of the node that sent the message:

<0x0002>: Hi there!

The messages posted by the local node will have <you> instead of the address of the element:

<you>: Hello, 0x0002!
<you> are now away

Private messages can be identified by the address of the element of the node that posted the message (enclosed in asterisks):

<you>: *0x0004* See you!
<0x0004>: *you* Bye!

When the reply is received, you will see the following:

<0x0004> received the message

Note that private messages are only seen by those the messages are addressed to.


This sample uses the following nRF Connect SDK libraries:

In addition, it uses the following Zephyr libraries: