How to call thread_coap_clound_data_update(...) function

[tak-jp]

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 . 

[Jørgen Holmefjord]

Hi,

I was able to reproduce the issue when setting up the border router as well.

After talking with our Thread developers, we figured out the reason for this behavior. When Border Router delegates some prefixes, its up to application how to create IPv6 address out of it. In the current version of OpenThread, this is handled in the CLI module. If the CLI module is not needed, this needs to be handled by the application. In our SED example (nRF5_SDK_for_Thread_v0.11.0_84a130f\examples\thread\experimental\mtd_coap_client\main.c:167), it is shown how to handle this:

if (flags & OT_CHANGED_THREAD_NETDATA)
{
    /**
     * Whenever Thread Network Data is changed, it is necessary to check if generation of global
     * addresses is needed. This operation is performed internally by the OpenThread CLI module.
     * To lower power consumption, the examples that implement Thread Sleepy End Device role
     * don't use the OpenThread CLI module. Therefore otIp6SlaacUpdate util is used to create
     * IPv6 addresses.
     */
    otIp6SlaacUpdate(thread_ot_instance_get(), m_slaac_addresses,
                     sizeof(m_slaac_addresses) / sizeof(m_slaac_addresses[0]),
                     otIp6CreateRandomIid, NULL);
}

If you add this code to thread_state_changed_callback in your application, you would not need the call to thread_cli_init anymore. Make sure you also define m_slaac_addresses, as shown in the example.

We will look into other ways of implementing this in future releases, to make it less error prone.

Best regards,
Jørgen

[tak-jp]

Hi,

Adding above code to my application, I can see CoAP frames(?) on my sniffer without the call to thread_cli_init() function.

Thank you for helping me out.