This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to call thread_coap_clound_data_update(...) function

Tools in use, etc:

  1. nRF52840-PDK
  2. nRF5_SDK_for_Thread_v0.11.0_84a130f.zip
  3. Thread Border Router ... RaspPi_Thread_Border_Router_Demo_v0.11.0-1.alpha.zip
  4. Thread NCP Example
  5. Raspberry Pi connect through an Ethernet cable to my switch that provides IPv4 connectivity with the DHCP service.

I've made some change in cloud_coap_client sample to post temperature data to my intranet coap server. It works fine (I can get posted values within the coap server). For next step, I'm trying:

  1. continuous BLE scan to find target beacon,
  2. when the target beacon is found, post beacon-related data (rssi, etc) to my intranet coap server.

I've called thread_coap_utils_cloud_data_update(...) function that is part of the thread_coap_utils.c for posting the beacon-related data (For testing, I'm using hard-coded temperature data now), but it isn't operated as expected.

I put this code:

otIp6Address * addr;
addr = thread_coap_utils_peer_addr_get();
NRF_LOG_INFO("coap_peer_addr [0-3]: %x %x %x %x",
    addr->mFields.m16[0],
    addr->mFields.m16[1],
    addr->mFields.m16[2],
    addr->mFields.m16[3]);
NRF_LOG_INFO("coap_peer_addr [4-7]: %x %x %x %x",
    addr->mFields.m16[4],
    addr->mFields.m16[5],
    addr->mFields.m16[6],
    addr->mFields.m16[7]);
NRF_LOG_INFO("m_cloud_information: %s %s %s %d",
    m_cloud_information.p_cloud_hostname,
    m_cloud_information.p_cloud_uri_path,
    m_cloud_information.p_cloud_thing_resource,
    m_cloud_information.cloud_coap_content_format);

just before calling location of the thread_coap_utils_cloud_data_update(...) function. This is output of modified cloud_coap_client sample, that works fine:

<info> app: Thread version: OPENTHREAD/ga89eb88-dirty; NRF52840; Nov 17 2017 09:01:26

<info> app: Network name:   OpenThread

<info> app: Thread interface has been enabled.

<info> app: 802.15.4 Channel: 11

<info> app: 802.15.4 PAN ID:  0xABCD

<info> app: rx-on-when-idle:  enabled

<info> app: State changed! Flags: 0x0000133F Current role: 1

<info> app: State changed! Flags: 0x000010E4 Current role: 3

<info> app: State changed! Flags: 0x00000200 Current role: 3

<info> app: State changed! Flags: 0x00000001 Current role: 3

<info> app: coap_peer_addr [0-3]: FD 6400 2301 6745
<info> app: coap_peer_addr [4-7]: 0 0 1BAC 25C5
<info> app: m_cloud_information: coap.thethings.io storage temp 50
<info> app: coap_peer_addr [0-3]: FD 6400 2301 6745
<info> app: coap_peer_addr [4-7]: 0 0 1BAC 25C5
<info> app: m_cloud_information: coap.thethings.io storage temp 50
<info> app: coap_peer_addr [0-3]: FD 6400 2301 6745
<info> app: coap_peer_addr [4-7]: 0 0 1BAC 25C5
<info> app: m_cloud_information: coap.thethings.io storage temp 50

and, this is similar output of new application which isn't operated as expected (modified version of ble_app_blinky_c):

<info> app: Thread version: OPENTHREAD/ga89eb88-dirty; NRF52840; Nov 17 2017 09:01:26

<info> app: Network name:   OpenThread

<info> app: Thread interface has been enabled.

<info> app: 802.15.4 Channel: 11

<info> app: 802.15.4 PAN ID:  0xABCD

<info> app: rx-on-when-idle:  enabled

<info> app: Blinky example started.
<info> app: State changed! Flags: 0x0000133F Current role: 1

<info> app: State changed! Flags: 0x000010E4 Current role: 3

<info> app: State changed! Flags: 0x00000200 Current role: 3

<info> app: coap_peer_addr [0-3]: FD 6400 2301 6745
<info> app: coap_peer_addr [4-7]: 0 0 1BAC 25C5
<info> app: m_cloud_information: coap.thethings.io storage temp 50
<info> app: coap_peer_addr [0-3]: FD 6400 2301 6745
<info> app: coap_peer_addr [4-7]: 0 0 1BAC 25C5
<info> app: m_cloud_information: coap.thethings.io storage temp 50
<info> app: coap_peer_addr [0-3]: FD 6400 2301 6745
<info> app: coap_peer_addr [4-7]: 0 0 1BAC 25C5
<info> app: m_cloud_information: coap.thethings.io storage temp 50
<info> app: coap_peer_addr [0-3]: FD 6400 2301 6745
<info> app: coap_peer_addr [4-7]: 0 0 1BAC 25C5
<info> app: m_cloud_information: coap.thethings.io storage temp 50

As I mentioned, I'm using my intranet coap server to receive posted data, so that I think *p_cloud_hostname value is meaningless. I've set coap server IP-Address in my code directly (hard-coded for testing).

What am I missing? Can anyone help me?
Thank you.

EDIT: I've uploaded ble_app_scan_c_th.zip . 

Parents Reply Children
  • I've searched the calls to functions starting with otCli*, but can't find. I think I don't call otCli* function. I'd like to remove these strange behavior. I need ideas.

  • Could you upload your entire project for debugging this issue? It will be much easier to find your issue if we have your code available.

  • I've uploaded the project. I'm using <InstallFolder>\examples\ble_central\ble_app_scan_c_th\pca10056\s140\ses\ble_app_scan_c_th_pca10056_s140.emProject. This application must be used along with <InstallFolder>\examples\ble_peripheral\ble_app_blinky or something to provide BLE advertising. I'm sorry for many unused (ble_app_blinky_c) parts are remaining.

    Thank you.

  • I'm not able to see any different behavior in your application with and without thread_cli_init function. I have not tested with a border router, as I do not have access to your cloud account, but the node seems to be connecting to thread network as expected. Did you change anything else in your application? Is it not working if you remove call to thread_cli_init again? 

  • Thank you for inspecting my new application behavior. It isn't working if I remove call to thread_cli_init again. I think the node has been connected to thread network properly with and without thread_cli_init function (because I can see some "<info> app: State changed! ..." messages, etc in the Debug Terminal in either case). I think my problem is:
    In spite of the node has been connected to thread network and assigned role [1-4], the node doesn't publish CoAP POST request(?) when thread_coap_utils_cloud_data_update function is called without thread_cli_init function.

    Did you capture CoAP packet(?) by means of sniffer when thread_coap_utils_cloud_data_update function was called without thread_cli_init function? I think this tool doesn't need cloud server, etc.

    BTW, with some limitations, I'm using Windows7 32bit (and SEGGER Embedded Studio for ARM 3.34a). Can this be the cause of this problem? If so, could you tell me your evaluation environment? I'll try to duplicate your environment as much as possible and investigate the behavior.

Related