Device identification in a Openthread network

RE: Device identification in a Openthread network

Amanda Hsieh — Wed, 08 Nov 2023 16:55:32 GMT

Hi,

You can use the settings subsystem in Zephyr to store the address. Or just NVM, or UICR if it is a one-time variable storage.

-Amanda H.

RE: Device identification in a Openthread network

Vincent124 — Wed, 08 Nov 2023 06:52:07 GMT

Sure sorry, that's my fault.

By establish a Link I mean a direct IP-Connection. So one device can (if he wants to) send a single UDP Package directly to one other device. This IP is the ML-EID and the receiving device saves this in a gobal variable. Problem is now that this variable logically does not get saved after the runtime stops and the "Link" gets lost as soon as the device e.g. reboots/crashes for whatever reason.

Regards,

Vincent

RE: Device identification in a Openthread network

Amanda Hsieh — Tue, 07 Nov 2023 15:24:41 GMT

Hi,

It is not clear to us what you mean by "establishes a Link". Could you provide more details on exactly how the "link" is created, which address you use, and how the address is stored on the node?

-Amanda H.

RE: Device identification in a Openthread network

Vincent124 — Tue, 07 Nov 2023 07:05:11 GMT

Hi,
Thanks again. Your information is really helping me but I keep running into problems.

I have now implemented a function that establishes a Link between two devices. But these links don't get permanently saved, which I expected. How do I reestablish a link between two deices after one e.g. loses connection? Do I send some kind of ACK package every few seconds to try to reestablish the link or is there another way?

Regards,

Vincent

RE: Device identification in a Openthread network

Amanda Hsieh — Fri, 03 Nov 2023 21:04:05 GMT

Hi,

The easy solution is to push a button on the device that is being paired, this is how it works in the CoAP samples (push the button to enable pairing mode, press the button on other devices to send pairing request, only the device in pairing mode will respond).

Of course, you can do it other ways, e.g. include the HWID/SN of the device that will be paired in the multicast packet, etc. This is something they need to decide on, not part of the Thread protocol itself.

-Amanda H.

RE: Device identification in a Openthread network

Vincent124 — Thu, 02 Nov 2023 13:28:56 GMT

Hello Amanda,

I've looked into the information you provided and it already helped me. But I'm still not sure about one thing:

For example let's say I would like to build a Smart Home. I have one switch that joins the Network and is expected to operate a specific lamp A. But there are more Lamps in the Network for exaple a lamp B.

I now send the ML-EID of the new joined switch via CoAP to all lamps with multicast. How does the lamp A know that this is the switch he has been waiting for. And how does B know that it isn't? Don't I need some kind of Hardware-bound address/value that identifies this new joined board which I can send together with the ML-EID?

Regards,

Vincent

RE: Device identification in a Openthread network

Amanda Hsieh — Mon, 30 Oct 2023 14:33:22 GMT

Hi,

We do not think it is the LLA address you want, that is only usable for communication between neighbor devices (Link-local, see scopes). What you should use to address a specific node is the ML-EID address.

Sending a multicast message to all nodes, asking the nodes to send its address in return is one common way of acquiring the address. We do this in the coap_server and coap_client samples, where one client node is provisioned to control the LED of the server:

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/openthread/coap_client/src/coap_client_utils.c#L183-L185

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/openthread/coap_server/src/ot_coap_utils.c#L78-L81

Regards,
Amanda H.