Google Thread protocol vs. BLE Mesh

RE: Google Thread protocol vs. BLE Mesh

Sigurd Hellesvik — Thu, 15 Dec 2022 09:59:51 GMT

Hi Jeff,

See https://openthread.io/reference/group/api-commissioner

Regards,
Sigurd Hellesvik

RE: Google Thread protocol vs. BLE Mesh

Jeffery — Thu, 15 Dec 2022 09:19:55 GMT

Hi Sigurd

I found the root cause of the issue above was "Flash" at VS code worked abnormally.

I tried flashing hex files through Programmer apps at nrf connect for Desktop.

COAP client and server can communicate ok.

Commissioner and Joiner at you Github also can commission successfully.

Thanks.

Another question

At commissioner example,

it still needs to input string "ot commisioner start" and "ot commissioner joiner add * J01NU5"

at serial port.

How can I integrate "ot" cli commands at my application code?

EX: Start commissioning by Button1 of commissioner DK board, instead of keying "ot" strings at serial port.

Jeff

RE: Google Thread protocol vs. BLE Mesh

Sigurd Hellesvik — Mon, 12 Dec 2022 09:03:28 GMT

Hi Jeff,

[quote user="Jeffery"]Q1. Shall I send any "ot" command to joiner board? [/quote]

The joiner should be able to join automatically, so no.

[quote user="Jeffery"]Q2. How can I solve SDK2.2.0 build failed issue?[/quote]

Do your build log fore 2.2.0 include any more detailed error messages?
If you wish to insert the whole log, remember to use Insert->Code to keep DevZone tidy.

[quote user="Jeffery"]

Q3. If commissioning was successful, how to verify they are at same network? Only

by "ping"?

[/quote]

You can use "ot state" to see if the device is child or leader. One should be child and the other leader.
Then the leader can use "ot child table" to list the child.

[quote user="Jeffery"]

For SDK2.1.2 &2.2.0 Openthread COAP client and server samples, I flashed the code to two nrf52840 DK

boards. Recycle the power, and observed serial terminal. I found these two became Leader and cannot

communicate. I tried several time and result was same.

[/quote]

Can you do the following commands to both, and post it here in 2x Insert->Code?

ot state
ot panid
ot extpanid
ot channel
ot networkkey

Regards,
Sigurd Hellesvik

RE: Google Thread protocol vs. BLE Mesh

Jeffery — Fri, 09 Dec 2022 03:39:27 GMT

Hi Sigurd

For SDK2.1.2 &2.2.0 Openthread COAP client and server samples, I flashed the code to two nrf52840 DK

boards. Recycle the power, and observed serial terminal. I found these two became Leader and cannot

communicate. I tried several time and result was same.

Jeff

RE: Google Thread protocol vs. BLE Mesh

Jeffery — Fri, 09 Dec 2022 03:18:59 GMT

Hi Sigurd

I tried ur CoAP Client+Server with automatic commissioning samples.

Below was what I did

- Download ZIP of samples_for_nr_connect_sdk. Unzopped it amd extracted commissioner and joiner

folders to my local folder.

- At VS code, "Adding an existing application" for commissioner and joiner folders each.

- Then, build configuration was nrf52840dk_nrf52840.

At SDK v2.2.0 environment, Build failed for both projects. It showed "FATAL ERROR command status 1"

At SDK v2.1.2 and v1.9.1, build successfully.

- Then, flash commissioner and joiner to two DK boards. Open serial terminal for both.

- At commissioner, "ot commissioner start" and "ot commissioner joiner add * J01NU5 20"

DK returns "Done" without problem.

However, after 20 seconds timeout, it showed "joiner remove". The results were

same for v2.1.2 and v1.9.1.

Q1. Shall I send any "ot" command to joiner board?

Q2. How can I solve SDK2.2.0 build failed issue?

Q3. If commissioning was successful, how to verify they are at same network? Only

by "ping"?

Jeff

RE: Google Thread protocol vs. BLE Mesh

Sigurd Hellesvik — Thu, 08 Dec 2022 07:30:13 GMT

Thread devices with the same thread configurations will automatically connect yes.

But in the field, you likely want devices to use commissioning instead.
Here are some reasons to why:

Thread devices for smart homes often needs to work on other thread networks. If you hard-code Thread configs, devices can only work with your devices(as only they have the same config). You loose interoperability.
Security is a nice feature in Thread networks. If consumer A buys your thread device, consumer B can buy another of the same device and connect to Consumer A home network without Consumer A knowing.

So it is most often better to have thread networks with generated network configurations and use Commisioning.

Regards,
Sigurd Hellesvik

RE: Google Thread protocol vs. BLE Mesh

Jeffery — Wed, 07 Dec 2022 13:29:01 GMT

Thanks. So, actually, commissioning is not all necessary for thread communication. It just let both sides got same thread configurations, right?

RE: Google Thread protocol vs. BLE Mesh

Sigurd Hellesvik — Wed, 07 Dec 2022 13:01:44 GMT

Hi,

[quote user="Jeffery"]Did these two samples really run commissioning process before they can talk each orther?[/quote]

[quote user="Jeffery"]Or, they can talk because they have same thread parameters in advance,like panid and ,network key?[/quote]

Yes

However, I have a an unofficial sample which is CoAP Client+Server with automatic commissioning if you need that.
This sample is just a modified version of the official CoAP Client and Server samples in the nRF Connect SDK.

Regards,
Sigurd Hellesvik

RE: Google Thread protocol vs. BLE Mesh

Jeffery — Wed, 07 Dec 2022 12:45:26 GMT

Yes,thanks a lot. Max. 1280 bytes was enough for my project. Another question for COAP client and server samples. Did these two samples really run commissioning process before they can talk each orther? Or, they can talk because they have same thread parameters in advance,like panid and ,network key? I

RE: Google Thread protocol vs. BLE Mesh

Sigurd Hellesvik — Wed, 07 Dec 2022 09:55:20 GMT

Hi Jeff,

[quote user="Jeffery"]Another simple question. How many bytes at most for customer data a Thread packet?[/quote]

Does this thread in googles openthread forum answer your question?

Regards,
Sigurd Hellesvik

RE: Google Thread protocol vs. BLE Mesh

Jeffery — Wed, 07 Dec 2022 09:29:42 GMT

Hi Sigurd

Thanks for the detailed reply.

Another simple question. How many bytes at most for customer data a Thread packet?

Jeff

RE: Google Thread protocol vs. BLE Mesh

Sigurd Hellesvik — Thu, 01 Dec 2022 12:49:31 GMT

Hi Jeffery,

One of the big differences between Thread and Bluetooth Mesh is that Thread does not define an application layer.

Therefore you will have to use an application on top of Thread. This is commonly applications such as CoAP, MQTT or Matter(*).
(*) Matter is a lot more than just an application, but it used Thread for transporting data.

With this in mind, let's get to the questions:

[quote user=""]

Q1. Tested COAP client and COAP server, client can send multicast message to all FTDs/MEDs. Or, single paired between client and one server, client can send message

only to paired server. If we want group division same as BLE mesh, can Thead make it? Through which interface to manually configure it? As BLE mesh, user can configure group at

smartphone.

[/quote]

For some theory, see Openthread guide.

In Thread, nodes are configured with a PanID.
Simplified, only nodes with the same PanID connect to make a network.

If you want more separation between Thread nodes than this, I think you will have to do this on the application layer.

You mention "Server" and "Client". Thread does not have Servers and Clients. CoAP, the application layer has Servers and Clients.
These function similar to http, where you can make end-to-end connections.

As I understand it, for BLE mesh groups, you can publish to groups and them a device can be subscribed to one or more groups, right?
In that case, this sounds a lot like the MQTT application layer, which can do the same, but calls the Groups for Topics.
I should mention that MQTT is built on TCP, which might use more power than CoAP which uses UDP.

To sum this up: Thread does not have this group functionality in itself. You need to handle that in an Application.

[quote user=""]

Q2. If we selected COAP client and server samples at nrf SDK connect as a start point to develop our own project, it seems nothing to do for Thread network management, after reboot many

client and many server devices, they will form a Thread network automatically, including who was leader, who was assigned to commissioner, controlling router numbers (16~23), router

path and others. So, what we can do at a device is very simple to send or receive user message data after network was formed. Right?

[/quote]

Thread networks are formed if the devices have the same values for all these:

panid
extpanid
channel
networkkey

These are set to defaults for the CoAP Client and Server samples.
I recommend that you try to use the Thread CLI sample to test to set these manually. Then you test different values and see how the network connects.

In Thread you can use a process called Commisioning to add a device to a thread network by using only a password. The Commisioner is usually only active for a limited time.
If you want to test this, I have two examples based on the CoAP Server and Client that does commisioning at my git.

If you want to know more about which communication options you have with the CoAP Server and Client, look up the CoAP protocol.

[quote user=""]

Q3. For Q2, if there are two independent Thread networks at office A and B. Several COAP client and server devices in each office. How can I modify code or parameters in COAP samples

to prevent communication between office A and B?

[/quote]

Use different PanID for networks.

For more information see Network Discovery and Formation

[quote user=""]Q4. At COAP client and server samples, after commission done, did the network information store at flash memory?[/quote]

Yes. If you enable Thread, it generally saves network information persistently.
To test this, run the Thread CLI sample to connect to a network. Reset the CLI sample and check the panid etc.

[quote user=""]Q5. Did Thread define model spec. similar as BLE mesh?[/quote]

No. The model spec is an application layer feature.

Protocols built on top of thread might have such a model specification.
Matter for example has a specificaion for Clusters I think.

To learn more about Thread, see our documentation on the Thread Protocol as well as webinars on Introduction to Thread networking protocol and Developing Thread products with nRF Connect SDK.

Regards,
Sigurd Hellesvik