Openthread COAP Client Server device reconnection failure

[McGregor]

Hello,

I am having hard time using openthread NCS examples. Recently I was handed over a project based on NCS COAP client server example to resolve a issue but I am not able solve the issue.

Issue: We have 2 FTD device one running COAP client example which is basically reading data from sensor and sending values to COAP server. The sensor update is basically automated using zephyr kwork with delay so we don't have to press button instead it will submit kwork at fixed intervals. Now COAP server is just receiving data and printing data on terminal. 

That's it. Nothing new has been done if I compare with Nordic demo examples. At the start everything works fine. Both server and client are able to communicate with eachother but after say nealry 30-35 hours my COAP client device gets disconnected and not able to reconnect to my COAP server. And if I restart my COAP client device it gets connected. So what's really the issue here ? When I ask the same question on Google Open Thread group they advised me this could be possible issue with radio drivers. So I would like to know what's really the issue here ? And how to resolve this issue ?

When we started developing at my company, we decided to select openthread as mesh communication protocols because of it's benefits over other protocols and Nordic SOC because of it's production ready examples. But it's seems both selection are letting me down.

Also I would like to ask in COAP examples I have seen this lights, provisioning on which we are COAP client is sending turn on off commands. So in this examples does this light act as topic or what ? Also suppose if I have 2 COAP Clients interfaced with different sensors, now if I have to send data to server should I use 2 different topics (something like light1, light2 or sensor 1 and sensor2) instead of sending data on the same light services ? 

[Charlie]

Hi McGregor,

Sorry to hear you struggling. As a support engineer, I face different kinds of problems every day. The truth is that there is no perfect product, even a product released on the market can have problems. If your expectation is too high, you mostly will feel disappointed. The infinite loop is that customer repots issues and feedback, we work together to make products better and better, but never perfect. Please take a deep breath and let's work together to find and solve this issue. Nordic team will try our best to help.

So what's really the issue here ? When I ask the same question on Google Open Thread group they advised me this could be possible issue with radio drivers. So I would like to know what's really the issue here ? And how to resolve this issue ?

 We didn't get the same report from other customers before. I need to repeat this test in order to confirm this issue. You cannot solve an issue if you never catch it. 

Also I would like to ask in COAP examples I have seen this lights, provisioning on which we are COAP client is sending turn on off commands. So in this examples does this light act as topic or what ? Also suppose if I have 2 COAP Clients interfaced with different sensors, now if I have to send data to server should I use 2 different topics (something like light1, light2 or sensor 1 and sensor2) instead of sending data on the same light services ? 

CoAP has no definition on this, you are free to create URI for server resources as long as they follow the CoAP URI Scheme. For example, the clients can send commands to server resources defined as /lights/light1 or just light1, the server can parse URI and decide which action to take. The coap_server example only has one light resource to control LED4, so the parse function ot_coap_utils.c->light_request_handler only needs to verify the command and take action.

LwM2M on top of CoAP defines IDs for Objects and Resources, which is similar to your services. They use Instance ID to identify instances under the same Object.

Best regards,

Charlie

[Charlie]

Hi McGregor,

Issue1:

30-35 hours my COAP client device gets disconnected and not able to reconnect to my COAP server

 Currently, I have a setup running around 48 hours now, and there is no issue so I do not know your problem. I can share my codes with you so you can check if there is anything different or repeat the experiment.

This coap_client_repeat example is modified from the original coap_client example, it will multicast every 1 second to send out server led toggle message. I use RTT viewer to log the experiment logging message, you can find it from the attachments. It split into two parts due to I closed the RTT viewer by mistake, but the firmware keeps running.

8623.coap_clinet_repeat.log

1602.coap_clinet_repeat2.log

4745.coap_client_repeat.zip

Issue2: 

McGregor said:

multiple resources on COAP servers

 I try to assembly all the information related together, but I feel lost since they are so many. Just correct me If I have a miss understanding. Please try to keep one ticket focusing on only one issue, list and describe your problem use as few words as possible.

Here is my understanding:

1. Client1 runs coap_client, it has Sensor1, Sensor1 control resource Led1 on Server1 to turn on and off.

2. Client2 runs coap_client, it has Sensor2, Sensor2, control resource Led2 on Server1 to turn on and off.

3. Server1 runs coap_server, it has Led1 and Led2 as resources. 

but your codes above show one coap_client contains two sensors and there are no other coap_client. The adding codes on coap_client_utils.c also have logic problem. Anyway, the codes shows you have an understanding on how to use coap URI now, so the next step on this issue for you is to correct my understanding of you application, and tell me what you want me to guide?

Best regards,

Charlie

[Charlie]

Hi McGregor,

McGregor said:

But before we proceed forward, i just want to once again make sure whether i should use single URI path for different sensor nodes/devices or multiple URI paths (one for each sensor node/devices).

 As I mentioned before, you have the freedom to define your communication protocol on top of CoAP. I think both of them are OK. I would prefer Scenario 1 as it can separate topics and values/commands properly, but this is only my personal taste. You can choose any of them that can solve your needs.

Best regards,
Charlie

[Charlie]

Hi McGregor,

Please contact our local FAE to get efficient support. I need their cooperation before giving you further help.

Best regards,

Charlie