nRF5 SDK for Thread and Zigbee v1.0.0
Thread MQTT-SN Sleepy Nodes Example

The Thread MQTT-SN sleepy nodes example demonstrates interaction between sleeping nodes with the use of OpenThread and built-in MQTT-SN protocol.

The purpose of this example is to toggle the LED on the subscriber board by publishing LED_ON and LED_OFF commands from the publisher board with the use of MQTT-SN sleepy client support. Since MQTT-SN network topology demands a gateway, which serves as a translator between MQTT-SN clients and MQTT broker, a third-party MQTT-SN gateway has been used. It has been taken from the Eclipse Paho project. For additional information on the gateway used, see Eclipse Paho MQTT-SN C/C++ client for Embedded platforms.

Description

Both client nodes indicate their Thread network state on BSP_LED_0. When the device is not connected to the network, the LED blinks at a 100 ms period. Once the device connects to a network, the LED stops blinking and remains turned on. On startup, nodes automatically enter the Thread network with default parameters. The sleepy subscriber and sleepy publisher nodes both start as MED (Minimal End Device) and switch to SED (Sleepy End Device) after establishing connection with the MQTT broker. The MQTT-SN gateway becomes a Leader of the network.

Clients' MQTT-SN network state is indicated on BSP_LED_3. When the device is not connected to the network, the LED is off. Once the device connects to a network, the LED is turned on.

As the MQTT-SN network in this example runs on Thread, the MQTT-SN Gateway plays the role of a Thread Border Router, which means it is a gateway between the Internet and the Thread Network. It can be run on a Raspberry Pi with Raspbian-based firmware. To connect the MQTT-SN Gateway to the Thread network, you need Nordic's nRF52840 Development Kit running the Network Co-Processor (NCP). For details on how to set up a Thread Border Router and run MQTT-SN Gateway, refer to the Thread Border Router documentation.

Sleepy subscriber

The subscriber node is controlled by specific actions triggered by pressing the buttons:

When an MQTT-SN client subscribes to a topic, every message published by other nodes on that topic is forwarded to the subscribing client. However, when a client is in Asleep state, all incoming messages are buffered by the MQTT-SN gateway and forwarded to the subscribing client when it is in Awake state. In this example, the client's sleep period is set to 10 seconds. Therefore, the sleepy subscriber node receives data once every 10 seconds. As the client serves as Thread SED (Sleepy End Device), it can only receive messages through a parent-polling mechanism. When it receives sleep permission from the gateway, the sleepy subscriber changes its polling time to a bigger value to save energy. In order to improve responsiveness, the polling time is decreased significantly upon changing the client's MQTT-SN state to Awake.

Subscriber LED assignments

Subscriber button assignments

Sleepy publisher

The publisher node is controlled by specific actions triggered by pressing the buttons:

The publisher node also serves a Thread SED role and changes its polling time to switch between low energy consumption and improved responsiveness. It does not sleep on MQTT-SN layer though - the client's state is connected and it does not change. According to the MQTT-SN protocol specification, to send a message a node has to be in Connected state. If the client slept on MQTT-SN, it would have to change its state from Asleep to Connected and back. In order to change the state, the sleepy publisher would then have to send CONNECT and DISCONNECT messages every time it would publish data. As it has no subscriptions and the MQTT-SN gateway message-buffering feature is not needed, it would be additional, unnecessary data to send.

Note
The publisher node sends LED_ON and LED_OFF commands alternately, irrespectively of the state of BSP_LED_2 on the subscriber board. It might happen that the state of BSP_LED_3 on the subscriber board and the published command are the same. Pressing BSP_BUTTON_3 on the publisher board would have no effect on the state of BSP_LED_2 on the subscriber board then, despite fully functional and working network. Pressing BSP_BUTTON_3 on the publisher board again would change the command and the publisher would toggle the BSP_LED_2 state.

Publisher LED assignments

Publisher button assignments

Setup

You can find the source code and the makefiles in the following folders:

Testing

  1. Build the example according to the instructions in Building examples.
  2. Turn the MQTT-SN gateway on according to the instructions in Thread Border Router.
  3. Program a development board with the MQTT-SN Sleepy Subscriber application.
  4. Program another development board with the MQTT-SN Sleepy Publisher application.
  5. Let the clients find the MQTT-SN gateway by pressing BSP_BUTTON_1 on both boards.
  6. Connect the clients to the gateway by pressing BSP_BUTTON_2 on both boards.
  7. Subscribe by pressing BSP_BUTTON_3 on the subscriber client board. The subscriber board is in Asleep state now. Note that BSP_LED_3 is off.
  8. Try toggling BSP_LED_2 on the subscriber by pressing BSP_BUTTON_3 on the publisher board. To see the LED toggle, you must wait for the subscriber board to go into Awake state, which by default happens every 10 seconds.
  9. When the subscriber client board goes into Awake state (it sends a PINGREQ message to the gateway), the LED toggles.
Documentation feedback | Developer Zone | Subscribe | Updated