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

nRF Mesh Client URI

Development Software:

nRF5 SDK for Mesh v3.1.0

SEGGER Embedded Studio for ARM v3.50

SoftDevice S140 v6.1.0

 

Computer Platform:

Windows 10 Professional

 

Hardware: 

Two nRF52840 DK's

 

What I'm trying to do: 

 I've read this part of the Mesh documentation:

and it seems that the provisioner connects to a client via a URI. I've traced the m_nw_state variable all throughout main.c in the light_switch_provisioner_nrf52840_xxAA_s140_6.1.0 example, as it seems that m_nw_state.p_client_uri is the URI passed to the following function:

static const char * server_uri_index_select(const char * p_client_uri)
{
    if (strcmp(p_client_uri, EX_URI_LS_CLIENT) == 0 || strcmp(p_client_uri, EX_URI_ENOCEAN) == 0)
    {
        return EX_URI_LS_SERVER;
    }
    else if (strcmp(p_client_uri, EX_URI_DM_CLIENT) == 0)
    {
        return EX_URI_DM_SERVER;
    } 
    // RengTech RGB URI's
    else if (strcmp(p_client_uri, RGB_CLIENT_URI) == 0)
    {
        return RGB_SERVER_URI;
    }

    __LOG(LOG_SRC_APP, LOG_LEVEL_ASSERT, "Invalid client URI index.\n");
    NRF_MESH_ASSERT(false);

    return NULL;
}

As you can see in the function below, m_nw_state.p_client_uri is passed to the above function, which generates the server URI:

static void app_config_successful_cb(void)
{
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Configuration of device %u successful\n", m_nw_state.configured_devices);

    hal_led_pin_set(APP_CONFIGURATION_LED, 0);

    m_nw_state.configured_devices++;
    access_flash_config_store();
    ERROR_CHECK(store_app_data());

    if (m_nw_state.configured_devices < (SERVER_NODE_COUNT + CLIENT_NODE_COUNT))
    {
        static const char * uri_list[1];
        uri_list[0] = server_uri_index_select(m_nw_state.p_client_uri);
        prov_helper_provision_next_device(PROVISIONER_RETRY_COUNT, m_nw_state.next_device_address,
                                           uri_list, ARRAY_SIZE(uri_list));
        prov_helper_scan_start();

        hal_led_pin_set(APP_PROVISIONING_LED, 1);
    }
    else
    {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "All servers provisioned\n");

        hal_led_blink_ms(LEDS_MASK, LED_BLINK_INTERVAL_MS, LED_BLINK_CNT_PROV);
    }
}

However, I'm not able to find where m_nw_state.p_client_uri is assigned. I've added my custom URI's, RGB_SERVER_URI and RGB_CLIENT_URI to example_common.h as follows:

#define EX_URI_BEACON       URI_SCHEME_EXAMPLE "URI for Beacon example"
#define EX_URI_DFU          URI_SCHEME_EXAMPLE "URI for DFU example"
#define EX_URI_ENOCEAN      URI_SCHEME_EXAMPLE "URI for Enocean example"
#define EX_URI_DM_CLIENT    URI_SCHEME_EXAMPLE "URI for Dimming Client example"
#define EX_URI_DM_SERVER    URI_SCHEME_EXAMPLE "URI for Dimming Server example"
#define EX_URI_LPN          URI_SCHEME_EXAMPLE "URI for LPN example"
#define EX_URI_LS_CLIENT    URI_SCHEME_EXAMPLE "URI for LS Client example"
#define EX_URI_LS_SERVER    URI_SCHEME_EXAMPLE "URI for LS Server example"
#define RGB_CLIENT_URI      URI_SCHEME_EXAMPLE "URI for RGB Client example"
#define RGB_SERVER_URI      URI_SCHEME_EXAMPLE "URI for RGB Server example"
#define EX_URI_PBR_CLIENT   URI_SCHEME_EXAMPLE "URI for PB Remote Client example"
#define EX_URI_PBR_SERVER   URI_SCHEME_EXAMPLE "URI for PB Remote Server example"
#define EX_URI_SERIAL       URI_SCHEME_EXAMPLE "URI for Serial example"

My question ultimately is, how does the client URI get set? And where in the code/example does this happen? I'd like to set it to my custom URI and have the provisioner provision my custom example.

Parents
  • Hello.

    If you take a look at the Release Notes for nRF5 SDK for Mesh, one of the changes is that we have implemented the URI Hash usage in this version of the SDK.
    All examples will now advertise the URI Hash in the unprovisioned device beacon, and the static provisioner example uses this URI hash during the provisioning process.

    If  you take a look at the Light Switch Client, in the main.c at line 251;

    mesh_provisionee_start_params_t prov_start_params =
    {
        .p_static_data    = static_auth_data,
        .prov_complete_cb = provisioning_complete_cb,
        .prov_device_identification_start_cb = device_identification_start_cb,
        .prov_device_identification_stop_cb = NULL,
        .prov_abort_cb = provisioning_aborted_cb,
        .p_device_uri = EX_URI_LS_CLIENT
    };

    The device URI, EX_URI_LS_CLIENT is assigned.

    The Uniform Resource Identifiers  for the examples can found in example_common.h
    Quote;
     * @note Replace the example URI strings with the desired URIs for the end products. The URI strings
     * should be coded as specified in the Bluetooth Core Specification Supplement v6, section 1.18.

    Best regards,
    Joakim

Reply
  • Hello.

    If you take a look at the Release Notes for nRF5 SDK for Mesh, one of the changes is that we have implemented the URI Hash usage in this version of the SDK.
    All examples will now advertise the URI Hash in the unprovisioned device beacon, and the static provisioner example uses this URI hash during the provisioning process.

    If  you take a look at the Light Switch Client, in the main.c at line 251;

    mesh_provisionee_start_params_t prov_start_params =
    {
        .p_static_data    = static_auth_data,
        .prov_complete_cb = provisioning_complete_cb,
        .prov_device_identification_start_cb = device_identification_start_cb,
        .prov_device_identification_stop_cb = NULL,
        .prov_abort_cb = provisioning_aborted_cb,
        .p_device_uri = EX_URI_LS_CLIENT
    };

    The device URI, EX_URI_LS_CLIENT is assigned.

    The Uniform Resource Identifiers  for the examples can found in example_common.h
    Quote;
     * @note Replace the example URI strings with the desired URIs for the end products. The URI strings
     * should be coded as specified in the Bluetooth Core Specification Supplement v6, section 1.18.

    Best regards,
    Joakim

Children
No Data
Related