cannot receive message

RE: cannot receive message

Bjørn Kvaale — Fri, 11 May 2018 14:20:22 GMT

1) If I were you, I would definitely take a look at this devzone case. I agree with you that on first sight, it doesn't make sense why you should initialize the simple_on_off_client model more than once. What is happening though is that for each client & server, a single simple_on_off_client model is initialized on the client to enable the light switch functionality (i.e. turning on/off the lights on the server). Since you have one client & one server, two elements (i.e. controllable part of a node, e.g. an LED) will be initialized with one OnOffClient model each. The first element sets up communication to the server to turn on & off the server LED, while the second element will handle communication to the group address (to turn off the light on multiple servers).

2) If you take a look at the mesh sdk v1.0.1 light switch client code, you can see that the server node needs to be configured before access_model_publish_address_set() is called inside provisioner_config_successful_cb(). This could well be a reason why your code is not working.

3) You are correct that the unicast addresses are set in increments of one. Take a look at:

    provisioner_init();
    if (m_configured_devices < m_provisioned_devices)
    {
        provisioner_configure(UNPROV_START_ADDRESS + m_configured_devices);
    }
    else if (m_provisioned_devices < SERVER_COUNT)
    {
        provisioner_wait_for_unprov(UNPROV_START_ADDRESS + m_provisioned_devices);
    }

inside access_setup() of the light switch client example. The unicast address arguments (m_configured_devices & m_provisioned_devices) inside provisioner_configure() & provisioner_wait_for_unprov() get incremented inside provisioner_config_successful_cb() & provisioner_prov_complete_cb().

The Getting Started link in the Nordic Infocenter has some useful information for understanding the light switch example & the Mesh SDK better.

RE: cannot receive message

Patrik — Wed, 09 May 2018 12:45:53 GMT

oh yes, many things are hardcoded with the purpose to examine my understanding of bluetooh mesh speification. My mistake, in the future for better understanding I will post with using macros :)

1) change from i < client_count to i < 1 ..... - hardcoded part and I wanted to call the simple_on_off_client_init() just once because on node1 (as in the picture above) I have just one simple OnOff client model. In node 2 there is simple OnOff server model called with simple_on_off_server_init().

2) should I have declared - #define GROUP_CLIENT_INDEX (0) . In 1) in for loop I have declared just one (the for loop cycles just once with condition i < 1) simple_on_off_client_t structure, i.e. m_clients[0] and that structure contains the necessary parameters for controlling one server model in node2 which is subscribing to group address (it likely makes no sense to publish to group address to one server model which is subscribing to that group address, but in the future i want to add more server models to subscribe to that group address)

Yes I erased the function access_model_publish_address_set() from the callback function provisioner_config_successful_cb, because with this step I would change the publish address to the particular server model (and I am trying to publish to group address).

3) again hardcoded part. but it is the same in my case, PROVISIONER_ADDRESS + m_target_address - UNPROV_START_ADDRESS == PROVISIONER_ADDRESS + 1. From the picture above there you can see the exact addresses for my elements used in code, from there that PROVISIONER_ADDRESS + 1 (the address for element in which is OnOff client model - I also suppose that the function dsm_local_unicast_addresses_set() sets the addresses in increments of 1 beginning with the addres we declare in dsm_local_unicast_address_t structure)

RE: cannot receive message

Bjørn Kvaale — Wed, 09 May 2018 10:43:02 GMT

Why did you change the for loop in access_setup() from i < CLIENT_COUNT to:

    for (uint32_t i = 0; i < 1; ++i)
    {
        m_clients[i].status_cb = client_status_cb;
        ERROR_CHECK(simple_on_off_client_init(&m_clients[i], i+1));//i+1 because i dont want to have together
                                                                   //in element0 OnOff model with control model and health model
    }

From what I understand, you want to call the simple_on_off_client_init() function twice if you have one client & one server.

Also, in your access_setup() function, you changed these three functions from m_clients[GROUP_CLIENT_INDEX] to:

        ERROR_CHECK(access_model_application_bind(m_clients[0].model_handle, m_appkey_handle));
        ERROR_CHECK(access_model_publish_application_set(m_clients[0].model_handle, m_appkey_handle));
        ERROR_CHECK(access_model_publish_address_set(m_clients[0].model_handle, m_group_handle));

What was the reason for this? I believe the idea there is to set the publish address for the group address. The publish address for the configured server is set in the access_model_publish_address_set() function in provisioner_config_successful_cb() in the main.c file of the light switch client example.

Also, you changed the code in the PROV_STATE_CONFIG_PUBLICATION_ONOFF case inside do_config_step() from:

pubstate.publish_address.value = PROVISIONER_ADDRESS + m_target_address - UNPROV_START_ADDRESS;

to:

pubstate.publish_address.value = PROVISIONER_ADDRESS + 1;

What was the reason for this?