Publishing MQTT messages from Thread device using NCS

[Tristen]

I have a system that consists of a sensor (nRF52840), hub (nRF5340), and gateway (nRF9160). The high level end goal is to be able to publish a MQTT message from the sensor, and have it travel to a device that can forward it a the cellular network. One concept was to the publish the MQTT message from the sensor, route the data to the hub via OpenThread, and from there route the data to the gateway via PPP. The gateway will then be responsible for sending the data over the cellular network to the MQTT broker. Is this possible? I have been hard pressed to find examples or documentation to support this. A good start would have been a MQTT over Thread demo for NCS which does not exist. 

[Kenneth]

Hello,

A collegue of mine will look into your question early next week at the latest.

Kenneth

[Sigurd Hellesvik]

Hi Tristen

Thread devices are able to communicate with the internet if a Border Router is connected to the network. I would say that this is the build-in/intended/cleanest way to send data from a Thread network over the internet.
However, the official OpenThread Border Router (OTBR) is for the Raspberry Pi.
Maybe you can find some LTE-based OTBR designs if you look around on the internet.
Another solution to this is to use the Raspberry Pi OTBR, and have a LTE adapter for the Raspberry pi.
These solutions would likely require the hub to be connected to a permanent power source. But Thread routers must always be on and listen/forward, so they usually need to be connected to permanent power sources anyhow.

We have no Thread solutions for MQTT, since it is build on TCP.
While it is possible to get MQTT working for Thread on our devices, it is not officialy supported yet.

However, the TCP protocol use more data and power than UDP.
The CoAP application layer is built on UDP, and is therefore more commonly used for Thread networks, and is why we have samples for this.
In this sense, I would recommend that you use CoAP instead of MQTT, as these two protocols are usually able to solve the same use-cases.

I likely have more suggestions and comments to your case, but I will leave it with this for now.
Did my thoughts on the matter make sense to you?
Let me know if you have more questions

Regards,
Sigurd Hellesvik

[Tristen]

Sigurd Hellesvik The hub is connected to a permanent power source. Your thoughts do make sense, especially your point on TCP and power. The goal for this project is to replace the existing BLE solution with a Thread solution. This solution must use MQTT, however, since we can get data from the Thread sensors to the hub BLE chip using CoAP, we can get the data over to the nRF9160 via UART and publish the MQTT message from there. Does that seem reasonable? 

[Sigurd Hellesvik]

This sounds reasonable.

If we had a border router solution for the nRF9160, it might be an idea to use the same protocol for both.
But since we do not have such a thing, I can see not see any reason to use the same protocol for both Thread and LTE.

In summary, the two main reasons for using CoAP over MQTT is:

• CoAP use UDP, which likely use less power. (*)
• We do have samples for CoAP in the nRF Connect SDK.

(*) I have not actually tested the power consumption of CoAP vs MQTT for Thread, but it makes sense that a heavier protocol(TCP vs UDP) will use more resources and therefore more power. My colleague agrees on this.

Regards,
Sigurd Hellesvik