<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Publishing MQTT messages from Thread device using NCS</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/87821/publishing-mqtt-messages-from-thread-device-using-ncs</link><description>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</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 16 May 2022 14:26:33 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/87821/publishing-mqtt-messages-from-thread-device-using-ncs" /><item><title>RE: Publishing MQTT messages from Thread device using NCS</title><link>https://devzone.nordicsemi.com/thread/368086?ContentTypeID=1</link><pubDate>Mon, 16 May 2022 14:26:33 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b5595094-5498-4822-b054-a3a9a6b4d417</guid><dc:creator>Sigurd Hellesvik</dc:creator><description>&lt;p&gt;This sounds reasonable.&lt;/p&gt;
&lt;p&gt;If we had a border router solution for the nRF9160, it might be an idea to use the same protocol for both. &lt;br /&gt;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.&lt;/p&gt;
&lt;p&gt;In summary, the two main reasons for using CoAP over MQTT is:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;CoAP use UDP, which likely use less power. (*)&lt;/li&gt;
&lt;li&gt;We do have &lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/nrf/samples/samples_thread.html"&gt;samples&lt;/a&gt; for CoAP in the nRF Connect SDK.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;(*) 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.&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Sigurd Hellesvik&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Publishing MQTT messages from Thread device using NCS</title><link>https://devzone.nordicsemi.com/thread/368079?ContentTypeID=1</link><pubDate>Mon, 16 May 2022 14:02:50 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b7b38f6b-a19c-4f2c-a412-341192f85f54</guid><dc:creator>Tristen</dc:creator><description>&lt;p&gt;&lt;a href="https://devzone.nordicsemi.com/members/sigurd-hellesvik"&gt;Sigurd Hellesvik&lt;/a&gt; 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?&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Publishing MQTT messages from Thread device using NCS</title><link>https://devzone.nordicsemi.com/thread/368022?ContentTypeID=1</link><pubDate>Mon, 16 May 2022 11:02:55 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5b9e5478-403b-48a9-956d-0a4c535ec4e6</guid><dc:creator>Sigurd Hellesvik</dc:creator><description>&lt;p&gt;Hi Tristen&lt;/p&gt;
&lt;p&gt;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.&lt;br /&gt;However, the official OpenThread Border Router (OTBR) is for the Raspberry Pi.&lt;br /&gt;Maybe you can find some LTE-based OTBR designs if you look around on the internet.&lt;br /&gt;Another solution to this is to use the Raspberry Pi OTBR, and have a LTE adapter for the Raspberry pi.&lt;br /&gt;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.&lt;/p&gt;
&lt;p&gt;We have no Thread solutions for MQTT, since it is build on TCP.&lt;br /&gt;While it is possible to get MQTT working for Thread on our devices, it is not officialy supported yet.&lt;/p&gt;
&lt;p&gt;However, the TCP protocol use more data and power than UDP. &lt;br /&gt;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.&lt;br /&gt;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.&lt;/p&gt;
&lt;p&gt;I likely have more suggestions and comments to your case, but I will leave it with this for now.&lt;br /&gt;Did my thoughts on the matter make sense to you? &lt;br /&gt;Let me know if you have more questions&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Sigurd Hellesvik&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Publishing MQTT messages from Thread device using NCS</title><link>https://devzone.nordicsemi.com/thread/367601?ContentTypeID=1</link><pubDate>Thu, 12 May 2022 12:18:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:482e615d-4124-49f9-9580-16f19bf31209</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;A collegue of mine will look into your question early next week at the latest.&lt;/p&gt;
&lt;p&gt;Kenneth&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>