How can I integrate OpenThread into my appliction?

122 views
Skip to first unread message

Alfie Douglas

unread,
Jan 8, 2021, 9:15:24 AM1/8/21
to openthread-users
I have bought a few Nordic nRF52840 DKs and have managed to get OpenThread up and running on them nicely with Zephyr.

My problem is however I am unsure how I can integrate this into my current use case. I am trying to make a IoT smart home appliance prototype which requires a GUI app. My current plan is to write an app in Flutter and have it running on Ubuntu Lite on a Raspberry Pi with a small touch screen and then use the nRF52840 DKs for each of the IoT devices to communicate with each other.

My current approach of how to do this is to use UART for the raspberry pi to communicate with the nRF and I have got this working and it can send very basic messages from one raspberry pi to another raspberry pi via the nRF DKs using OpenThread.

However this has been very cumbersome and does not seem a viable approach as I have to encode all the data to binary and add headers and error check etc. prior to sending it via UART and then decode the other side. I worry as messages will get more complex and larger that this will scale out of control and become extremely difficult.

I wanted to know if I had missed something here and if there was an easier way I could use OpenThread in my current app running on raspberry pis? Are there any libraries that can do this for me?

Really appreciate any suggestions and help you can offer, thanks for reading :)

Gustavo

unread,
Jan 8, 2021, 12:13:34 PM1/8/21
to Alfie Douglas, openthread-users
You can use an nrf52 as a RCP (or NCP) for the raspberry, and then communicate with the thread devices through the IPv6 network, using any protocol you prefer (posix sockets, MQTT, UDP, etc etc). The raspberry will have it's own IPv6 address, and the same for each thread device, so it's pretty much standard network communication.

Some useful resources:

Cheers!

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/d05bb912-db54-425c-af38-ffa46aa357fcn%40googlegroups.com.

Alfie Douglas

unread,
Jan 11, 2021, 11:15:31 AM1/11/21
to openthread-users
That's great, thank you very much! I can't seem to understand what the difference is here between an NCP and RCP? And what would one would be the most applicable in my case.

Thanks!

Jonathan Hui

unread,
Jan 11, 2021, 11:17:52 AM1/11/21
to Alfie Douglas, openthread-users
You can find more information about different platform architectures at https://openthread.io/platforms.

--
Jonathan Hui



Gustavo

unread,
Jan 11, 2021, 1:06:39 PM1/11/21
to Alfie Douglas, openthread-users
Using the nrf52 as a NCP makes sense for what you described, and there are already example projects for NCP in the nrf-sdk (for zephyr) and also the deprecated nrf-sdk-for-thread-and-zigbee.

Nordic has excellent material to get started with thread development: https://webinars.nordicsemi.com/developing-thread-products-with-nrf-1

Also take a look at this pre-configured raspberry pi image for you to use with the NCP. You can find it in the downloads section of this page: 
This image is a bit old, and many things have changed since then, but it's a good starting point to get things running.

Cheers!

Alfie Douglas

unread,
Jan 12, 2021, 6:00:51 AM1/12/21
to openthread-users
They look like fantastic starting point! Really appreciate sharing them!

I've an NCP all up and running with wpantund. My next steps are to now implement this into my application. I've had a look at pyspinel but this seems to just provide a CLI  however I've just come across this automating testing: https://github.com/openthread/openthread/tree/master/tests/toranj, which contains the wpan.py file which seems like a really good interface for wpantund. However I'm quite new to all this and am not sure if it has all the functionality of wpantund and if it would be suitable to use in my application to interface with the NCP and send messages across the OpenThread network?

Thanks again!

Gustavo

unread,
Jan 12, 2021, 6:40:14 AM1/12/21
to Alfie Douglas, openthread-users
One important detail is that wpantund is deprecated and won't support thread 1.2 onwards. I don't know what will be (or if there will be) a replacement for wpantund, but maybe somebody else in this group has an answer. 
I would not worry much about this at first, as you will always be able to use an equivalent configuration to get the pi in the openthread network (through ot-daemon or something else).

Once your devices are commissioned and are all connected to the openthread network, you should use standard IPv6 networking to communicate with them, or any application protocol you prefer.
For example, if you don't want to bother with individual device addressing, you could use MQTT and just use pub/sub for everything. Take a look at the MQTTSN examples from nordic:

Cheers!

Alfie Douglas

unread,
Jan 14, 2021, 4:39:52 AM1/14/21
to openthread-users
I've been looking into MQTT and it seem perfect for this application, so many thanks for that suggestion!

Just to check I have the correct idea, I can run an MQTT server on the border router which then can be accessed by other devices by using the network interface created by the RCP?

And to do this, does the machine hosting the MQTT server need to be connected to a border router or can it be just a normal RCP? As I do not require other Thread devices to access the internet only my LAN (which is where the MQTT server will be hosted).


Sorry for all of this questions, I am just feeling a little confused of how I can piece all of this together. Thanks a bunch!

Gustavo

unread,
Jan 14, 2021, 8:03:02 AM1/14/21
to openthread-users
Just to check I have the correct idea, I can run an MQTT server on the border router which then can be accessed by other devices by using the network interface created by the RCP?
Short answer: yes. The RCP enables your pi to be part of the thread IPv6 mesh network, so the pi can communicate with any thread device and vice-versa, using IPv6 addressing.

And to do this, does the machine hosting the MQTT server need to be connected to a border router or can it be just a normal RCP? As I do not require other Thread devices to access the internet only my LAN (which is where the MQTT server will be hosted).
 
In the simplest scenario, to communicate with the MQTT server directly from a thread device, the MQTT server needs to be running in the same IPv6 network as the thread devices. That means it can run in the raspberry or any other device that the raspberry can route to in the same IPv6 network.
The nordic border router image comes with a service called Tayga that does NAT for IPv6 <-> IPv4 (NAT64). This way you can bridge the IPv4 network from your pi to the thread IPv6 network, and your thread devices can reach the pi's IPv4 network "directly" using IPv4 over IPv6 addressing (it will be routed through the pi, but the pi would behave just as a network router). This way the MQTT server doesn't even need to be running in the pi, it could be running anywhere in your local IPv4 network, or even somewhere else in the IPv4 internet. The other way around is also true: Hosts in your IPv4 network (or even over the internet) can communicate with the thread devices directly (through NAT64).

I have also come across this repository https://github.com/eclipse/paho.mqtt-sn.embedded-c/tree/master/MQTTSNGateway, which is what the RaspberryPi image in the nordic example you linked uses, would I also need to use this to allow access of the MQTT server through the thread network?
 
The MQTTSNGateway simplifies things a lot, as you won't even need to care about IP addresses from your thread devices to use MQTT. The thread devices will look for a MQTTSN gateway, and if they find one, they will publish/subscribe to topics through it, without caring about where the actual MQTT server is running. The MQTTSNGateway has a configuration file where you set which MQTT server to use. Thread device <-> MQTTSNGateway <-> MQTT Server.

Sorry for all of this questions, I am just feeling a little confused of how I can piece all of this together. Thanks a bunch!
 
You are welcome! Most of the stuff I mentioned above already comes configured by default in the nordic pi border router image, but I gave more details to help you get a better picture of how things can work together, and to be able to reproduce it without using the nordic border router pi image.

Cheers!

Alfie Douglas

unread,
Jan 15, 2021, 8:32:37 AM1/15/21
to openthread-users
You've really cleared a lot of stuff up for me, thanks a lot!! I really appreciate your help :)
Reply all
Reply to author
Forward
0 new messages