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