Adding nRF52 DK to gitHub mesh demo for thingys

[Michael_K]

Hello everyone, 

I`ve 4 thingys and ran the https://github.com/NordicPlayground/Nordic-Thingy52-mesh-demo. That works well. 

Now I`m trying to add the nRF52 DK as a Node to the bluetooth mesh network in order for it to receive the periodic messages sent by the sensor nodes. 

As a first step, I was trying to program the light_switch_example_server_nrf52832_xxAA_s132_3_1_0 from the nRF5 SDK for Mesh v1.0.1 onto the Chip (using SEGGER Embedded Studio) to see whether it is being provisioned by the bridge. Unfortunately it is not. 

My question is: Why doesn`t the nRF5 DK get provisioned by the bridge? And what do I have to change to add it to the mesh and to receive the messages of the thingys? 

Best regards, 

Michael

[Jui-Chou (Rick) Chung]

Hello Michael,

Great to hear that the Thingy mesh demo works well.

The reason why the nRF52-DK with "light switch server" cannot work with "Thingy bridge" correctly is that:

1. The "Thingy bridge" will do provision for the unprovisioned device and then do the configuration
2. During the configuration, Thingy bridge will try to bind the AppKey to the "simple Thingy server model" (the code is in here)
3. However, the "light switch server" is using the "simple on off server", which is different
4. So the configuration will fail

Basically, if you want your nRF52-DK works with "Thingy mesh demo", you have to add the "simple Thingy server model" into your project which running on nRF52-DK.

Also, since "Thingy mesh demo" is quite old (using nRF5 Mesh SDK v1.0.1), I would like to suggest you try the project "Thingy mesh provisioning demo"  which made by Hung :)

Best regards,

Rick

[Michael_K]

Thank you very much for your fast response, Rick!

I`m not sure what adding simple thingy server model in detail means. I added simple_thingy_server.c and ...server.h to the light_switch_project and additionally added the include directories for the preprocessor, which means building the project works fine now. 

Furthermore I have initialized the simple_thingy_server and bound it to an element. What else do I have to do to get my nRF52 DK provisioned?

[Jui-Chou (Rick) Chung]

Hello Michael,

If you have done the server initialization like here correctly, then your nRF52-DK should possible been provisioned and configured. Since "Thingy bridge" will provision the nearby unprovisioned device and configure it. You can add log in the provisioner.c in "Thingy bridge" to tracking the provisioning and configuration process.

Or you can modify the "Thingy bridge" project with removing all the "Thingy" hardware related code (like I2C I/O expander, LED driver and so on) for fitting the nRF52-DK.

Since your goal is trying to collect the sensor information from Thingys, and in the Thingy mesh demo, the "Thingy bridge" is not only a provisioner, but also all the sensor information will send to "simple Thingy client" in the "Thingy bridge".

[wangshuai]

Hello Michael,

I also encountered the same problem with you now. If you have time, you can send your configured demo to my reference learning? Thank you very much.

[Michael_K]

Hello 

Jui-Chou (Rick) Chung: Thank you for your advice. I`m still working on the initialization. Unfortunately the link you were referring to doesn`t work. Would you mind sending it again?

wangshuai I`m trying to add the initialization of the simple_thingy_server-model to nrf_mesh_node_config.c. Unfortunately I also have some exams coming up but I will post my results asap. 

[Jui-Chou (Rick) Chung]

Hello Michael,

Would you please check the link again? Since the link should work now

And please let me to add some comments:

In the "Thingy mesh demo" project, there are ten "simple Thingy client" in the "Thingy bridge"., and each one has been configured to publish the message to the corresponded "simple Thingy server" in those ten Thingy node. Once if one of the Thiny node got the "read sensor back" command, it will send the sensor information to the corresponded "simpleThingy client" in the "Thingy server", and the callback function will send the sensor data to through Nordic UART Service to the mobile device (this is the old design).
According to the upon information, it would be better to turn your DK as a Thingy bridge

But I would like to suggest you to use our latest Mesh SDK, and check here to create the model for your application. 

Hope the upon information can do help.

[Michael_K]

Hello Rick 

yes, the link works now. But that`s exactly how I initialized the model. Unfortunately it still doesn`t work. 

/* Copyright (c) 2010 - 2017, Nordic Semiconductor ASA
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 * list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 *
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 *
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 *
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 *
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#include <stdint.h>
#include <string.h>
#include "simple_thingy_server.h"
#include "ble_uis.h"

/* HAL */
#include "nrf.h"
#include "boards.h"
#include "nrf_mesh_sdk.h"
#include "nrf_delay.h"
#include "simple_hal.h"

/* Core */
#include "nrf_mesh.h"
#include "nrf_mesh_events.h"
#include "log.h"

#include "access.h"
#include "access_config.h"
#include "device_state_manager.h"
#include "nrf_mesh_node_config.h"

#include "simple_on_off_server.h"

#include "light_switch_example_common.h"

/*****************************************************************************
 * Definitions
 *****************************************************************************/

#define LED_PIN_NUMBER (BSP_LED_0)
#define LED_PIN_MASK   (1u << LED_PIN_NUMBER)

/*****************************************************************************
 * Static data
 *****************************************************************************/

//static simple_on_off_server_t m_server;
static simple_thingy_server_t m_server; 

/* Forward declaration */
static bool get_cb(const simple_on_off_server_t * p_server);
static bool set_cb(const simple_on_off_server_t * p_server, bool value);

static ble_uis_led_t led_get_cb(); 
static ble_uis_led_t led_set_cb(const simple_thingy_server_t * server, ble_uis_led_t led_config);
static void sensor_set_cb(const simple_thingy_server_t * server, sensor_config_t sensor_cfg);


/*****************************************************************************
 * Static utility functions
 *****************************************************************************/

static void configuration_setup(void * p_unused)
{
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Initializing and adding models\n");
//    m_server.get_cb = get_cb;
//    m_server.set_cb = set_cb;
    m_server.led_get_cb = led_get_cb; 
    m_server.led_set_cb = led_set_cb; 
    m_server.sensor_set_cb = sensor_set_cb; 
//    ERROR_CHECK(simple_on_off_server_init(&m_server, 0));
    ERROR_CHECK(simple_thingy_server_init(&m_server,0));
    ERROR_CHECK(access_model_subscription_list_alloc(m_server.model_handle));
   
   // hal_led_mask_set(LEDS_MASK, true);
}

static void provisioning_complete(void * p_unused)
{
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Successfully provisioned\n");
    hal_led_mask_set(LEDS_MASK, false);
    hal_led_blink_ms(LED_PIN_MASK, 200, 4);

}

/*****************************************************************************
 * Simple OnOff Callbacks/ Simple Thingy Callbacks
 *****************************************************************************/

//static bool get_cb(const simple_on_off_server_t * p_server)
//{
//    return hal_led_pin_get(LED_PIN_NUMBER);
//}

static ble_uis_led_t led_get_cb()
{
    // Dummy method just to get simple thingy model initialized and nRF5 DK provisioned
    ble_uis_led_t led_cmd;
    led_cmd.mode = BLE_UIS_LED_MODE_CONST;
    led_cmd.data.mode_const.r = 0x0f;
    led_cmd.data.mode_const.g = 0x0f;
    led_cmd.data.mode_const.b = 0x0f;
    return led_cmd; 
}

static ble_uis_led_t led_set_cb(const simple_thingy_server_t * server, ble_uis_led_t led_config)
{
    // Dummy method just to get simple thingy model initialized and nRF5 DK provisioned
    return led_config; 
}

static void sensor_set_cb(const simple_thingy_server_t * server, sensor_config_t sensor_cfg)
{
  // Dummy method just to get simple thingy model initialized and nRF5 DK provisioned
   __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "----- sensor set callback -----\n");
  
}
//static bool set_cb(const simple_on_off_server_t * p_server, bool value)
//{
//    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Got SET command to %u\n", value);
//    hal_led_pin_set(LED_PIN_NUMBER, value);
//    return value;
//}

void mesh_stack_init(void)    // von Thingy_node kopiert, um gleiches Setup des provisionees zu gewährleisten
{
    static const uint8_t static_auth_data[NRF_MESH_KEY_SIZE] = STATIC_AUTH_DATA;
    static nrf_mesh_node_config_params_t config_params;
    config_params.prov_caps.num_elements = ACCESS_ELEMENT_COUNT;
    config_params.prov_caps.algorithms = NRF_MESH_PROV_ALGORITHM_FIPS_P256EC;
    config_params.prov_caps.oob_static_types = NRF_MESH_PROV_OOB_STATIC_TYPE_SUPPORTED;
    config_params.p_static_data = static_auth_data;
    config_params.complete_callback = provisioning_complete;
    config_params.setup_callback = configuration_setup;
    config_params.irq_priority = NRF_MESH_IRQ_PRIORITY_LOWEST;
    config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
    config_params.lf_clk_cfg.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM;
    nrf_mesh_node_config(&config_params);
}

int main(void)
{
    __LOG_INIT(LOG_SRC_APP | LOG_SRC_ACCESS, LOG_LEVEL_INFO, LOG_CALLBACK_DEFAULT);
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "----- BLE Mesh Light Switch Server Demo -----\n");

    hal_leds_init();

//   static const uint8_t static_auth_data[NRF_MESH_KEY_SIZE] = STATIC_AUTH_DATA;
//    static nrf_mesh_node_config_params_t config_params =
//        {.prov_caps = NRF_MESH_PROV_OOB_CAPS_DEFAULT(ACCESS_ELEMENT_COUNT)};
//    config_params.p_static_data = static_auth_data;
//    config_params.complete_callback = provisioning_complete;
//    config_params.setup_callback = configuration_setup;
//    config_params.irq_priority = NRF_MESH_IRQ_PRIORITY_LOWEST;
//
//#if defined(S110)
//    config_params.lf_clk_cfg = NRF_CLOCK_LFCLKSRC_XTAL_20_PPM;
//#elif SD_BLE_API_VERSION >= 5
//    config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
//    config_params.lf_clk_cfg.accuracy = NRF_CLOCK_LF_ACCURACY_20_PPM;
//#else
//    config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
//    config_params.lf_clk_cfg.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM;
//#endif

 //   ERROR_CHECK(nrf_mesh_node_config(&config_params));

    mesh_stack_init(); 
    hal_led_mask_set(LEDS_MASK, true);
    while (true)
    {
        (void)sd_app_evt_wait();
    }
}

I posted my new code for reference. 

Might there be any problem with the bearer? While checking the code I realized, that there is a difference between the bearer of the light_switch_example and the one of the thingy_mesh_demo. 

Other than that I don`t have an idea whatsoever. 

Jui-Chou (Rick) Chung: Implementing the DK as the bridge makes more sense indeed, but I would like to first solve the provisioning problem before I change the architecture and have to start over again. 

Best regards, 

Michael

[Jui-Chou (Rick) Chung]

Hello Michael,

Have you seen any error log from the provisioner or the server node itself?

Since there's no error log, so I cannot give more help on this.

And the reason why we should use "bridge" node as a reference is that the bridge contains with "simple_thingy_client", which has the sensor_status_cb() for handling the sensor information

[Michael_K]

Hello Rick, 

This is the log I get by debugging the thingy with the bridge software while I have a thingy with node and the development kit with my modified code ( which can be seen in my previous response). 

This is the log I get from the thingy node: 

And this is what the debugging of the dk with the simple_thingy_server results in: 

Both the thingy server and the dk server initialize the simple_thingy_server-model, however, only the one implemented in the thingy is provisioned. Say you were right and the problem would be during the configuration process, shouldn`t then the provisioning process be successful and the following configuration process report an error? 

Since the provisioning process doesn`t even start (at least in the log I cannot see that it starts) I think the problem is already located in the provisioning process.

I then checked the configuration parameters used to configure the node with nrf_mesh_node_config() and they are similar as well. (Same authentication key and static, same setup_callback() etc.). I finally realized that during the initialization of the provisionee model different bearer types are used. Might that be the reason, why the bridge doesn`t even seem to recognize the dk?

Regards Michael