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 the 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.
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 or nRF52833 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.
Both client nodes indicate their Thread network state on LED1. 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.
The MQTT-SN network state of the clients is indicated on LED4. 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.
You can find the source code and the makefiles in the following folders:
<InstallFolder>\examples\thread\mqttsn_sleepy_publisher
<InstallFolder>\examples\thread\mqttsn_sleepy_subscriber
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 the Asleep state, all incoming messages are buffered by the MQTT-SN gateway and forwarded to the subscribing client when it is in the 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. To improve responsiveness, the polling time is decreased significantly upon changing the client's MQTT-SN state to Awake.
The subscriber node is controlled by specific actions triggered by pressing the buttons. The effect of pressing the buttons is reflected on the LED state.
The following buttons reserved for user application purposes are assigned in this example:
The sleepy subscriber uses LED assignments as described in Thread BSP LED and button reference for the following LEDs:
The following LED reserved for user application purposes are assigned in this example on sleepy subscriber:
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 the Connected state. If the client slept on MQTT-SN, it will have to change its state from Asleep to Connected and back. To change the state, the sleepy publisher will then have to send CONNECT and DISCONNECT messages every time it will publish data. As it has no subscriptions and the MQTT-SN gateway message-buffering feature is not needed, this will be an additional, unnecessary data to send.
The publisher node is controlled by specific actions triggered by pressing the buttons. The effect of pressing the buttons is reflected on the LED state.
The button assignments are identical to Sleepy subscriber button assignments, with the exception of the following button:
The sleepy publisher uses LED assignments as described in Thread BSP LED and button reference for the following LEDs:
The following LED reserved for user application purposes are assigned in this example on sleepy publisher: