Sending messages to unicast addresses

RE: Sending messages to unicast addresses

jonappleseed — Fri, 14 Jun 2019 09:49:44 GMT

Solved!

static uint32_t set_model_publish_address(uint16_t publish_address, access_model_handle_t model_handle) 
{  
    uint32_t status = NRF_SUCCESS;
    dsm_handle_t publish_address_handle = DSM_HANDLE_INVALID;
    access_model_publish_address_get(model_handle, &publish_address_handle);
    NRF_MESH_ASSERT(dsm_address_publish_remove(publish_address_handle) == NRF_SUCCESS);
    status = dsm_address_publish_add(publish_address, &publish_address_handle); 
    if (status != NRF_SUCCESS) {
        return status;
    } 
    else {
        return access_model_publish_address_set(model_handle, publish_address_handle);
    }
}

I call this function like so:

set_model_publish_address(UNI_ADDR, m_clients[2].model_handle);

Credit: Hung Bui (https://devzone.nordicsemi.com/f/nordic-q-a/35931/multiple-server-on-one-client---light-switch-demo)

RE: Sending messages to unicast addresses

bart — Thu, 23 May 2019 09:37:29 GMT

Hey, I haven't actually tried it yet, as i first need to implement functionality before optimizing thing =] Didn't see that it takes a handle. I'd also say you need to call dsm_address_publish_add() for each unicast address then.

RE: Sending messages to unicast addresses

jonappleseed — Thu, 23 May 2019 08:44:17 GMT

Hi Bart, any luck on this? I tried using access_model_publish_address_set(), but it takes in a handle not an actual address. From my exploration of the code it appears that handles are determined at the configuration stage by the provisioner. There is also dsm_address_publish_add() which takes in a raw address, but I haven't had any luck with that either.

RE: Sending messages to unicast addresses

bart — Thu, 16 May 2019 07:45:38 GMT

Hi Bjørn,

I was also looking into sending unicast messages. It seems very silly to me to have a model instance for every possible node in the network, so I was wondering:

Is it out of spec if a node sends messages to unicast addresses it was not specifically told to publish to by a provisioner?

Can you call access_model_publish_address_set() before publishing a message, maybe multiple times per second. Or does that break some mesh code? Is this maybe different for reliable and unreliable messages?

RE: Sending messages to unicast addresses

jonappleseed — Tue, 26 Mar 2019 12:19:24 GMT

I've got it working now, though the code is not ideal, I have NODE_SETUP_CONFIG_APPKEY_BIND_ONOFF_CLIENT listed 31 (!) times in client_config_steps and NODE_SETUP_CONFIG_PUBLICATION_ONOFF_CLIENT2 listed 30 (!) times. Many thanks for the help.

RE: Sending messages to unicast addresses

jonappleseed — Tue, 26 Mar 2019 11:26:01 GMT

Hi Bjørn, thanks for the detailed response. I have implemented your suggestions in the provisioner. However, I have used a for loop inside NODE_SETUP_CONFIG_APPKEY_BIND_ONOFF_CLIENT rather than having it listed many times in the config steps. But, I am getting an NRF_BUSY_ERROR after the first time the loop is run. It's caused by client_in_wrong_state() in config_client.c :

static bool client_in_wrong_state(uint32_t * p_status)
{
    if (m_client.state == CONFIG_CLIENT_STATE_NONE)
    {        
        *p_status = NRF_ERROR_INVALID_STATE;
        return true;
    }
    else if (m_client.state == CONFIG_CLIENT_STATE_WAIT_REPLY)
    {
        *p_status = NRF_ERROR_BUSY;
        return true;
    }
    return false;
}

which is called by app_bind_unbind_send() which is in turn called by config_client_model_app_bind(). I cannot work out why this is.

RE: Sending messages to unicast addresses

Bjørn Kvaale — Tue, 26 Mar 2019 08:07:02 GMT

[quote user="jonappleseed"]Do I need to have a model for each server?[/quote]

No, you do not need to have a generic on off client model for each server. You could for example publish from one client to multiple servers via a group address. If you however want to publish messages via a unicast address from the client to one server & do this for multiple servers, I would suggest having one client model for each server model. Let's say you had 4 server nodes for example. You could then have four generic on off client models & each client model would publish to the unicast address of one of the server models. You could then use the four buttons on the DK to publish to each of the four server nodes.

[quote user="jonappleseed"]If I need a model for each server, how can I do this without having to write a separate NODE_SETUP_CONFIG_PUBLICATION_ONOFF_CLIENTx for each of them?[/quote]

You could have one NODE_SETUP_CONFIG_PUBLICATION_ONOFF_CLIENT case & then based on the m_current_node_addr, you know which client you are setting the publish address for. You could then have an if or switch statement & then set the publish address to the corresponding server unicast address (similar to how it is done with the if else statement in NODE_SETUP_CONFIG_SUBSCRIPTION_ONOFF_SERVER). In client_config_steps[], remember to have the same amount of NODE_SETUP_CONFIG_APPKEY_BIND_ONOFF_CLIENT calls as there are client models. In addition, you would need to call NODE_SETUP_CONFIG_PUBLICATION_ONOFF_CLIENT the same amount of times as the client models.

RE: Sending messages to unicast addresses

jonappleseed — Mon, 25 Mar 2019 10:10:50 GMT

Do I need to have a model for each server? When I use access_model_publish_address_set it just changes the publish address, which means that when I call generic_onoff_client_set it returns NRF_ERROR_BUSY because it's trying to run the same model. If I need a model for each server, how can I do this without having to write a separate NODE_SETUP_CONFIG_PUBLICATION_ONOFF_CLIENTx for each of them?

RE: Sending messages to unicast addresses

jonappleseed — Fri, 22 Mar 2019 09:48:53 GMT

I can send to just the first server, but I want to be able to send to all nodes individually. That's what my second bit of code is trying to achieve, but getting the error.

RE: Sending messages to unicast addresses

Bjørn Kvaale — Fri, 22 Mar 2019 07:37:55 GMT

If you want to provision via the provisioner light switch example, the only changes you would need to make are in the node_setup.c file like you mention above. Assuming you want the first client to publish to the first server address, you would need to find the element address of the server.

In the latest mesh sdk (i.e. v3.1.0), the check_network_state() function will configure the different nodes. The node_setup_start() function is then called, which then calls setup_select_steps(). This function will then go through the client configuration steps first before going through the server configuration steps. config_step_execute() then goes through all of the steps in order to configure the node.

If I were you, I would keep track of the element_address in each step. The steps are essentially hardcoded at the moment. If you go through the whole process, add a bit more logging info to the element address, you can predict the unicast element address of the server. That way, you can set the correct unicast publication address for the case NODE_SETUP_CONFIG_PUBLICATION_ONOFF_CLIENT1. The setup for setting the publication unicast address should be similar to the case NODE_SETUP_CONFIG_PUBLICATION_ONOFF_SERVER.

RE: Sending messages to unicast addresses

jonappleseed — Thu, 21 Mar 2019 12:28:14 GMT

I tried to use access_model_publish_address_set() to change the address the model uses:

         case 1:
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "-- Acknowledged unicast\n");
            (void)access_model_reliable_cancel(m_clients[0].model_handle);
            dsm_handle_t handle;
            (void)access_model_publish_address_get(m_clients[0].model_handle, &handle);
            for (int i = 0; i < SERVER_NODE_COUNT; i++) {
              status = access_model_publish_address_set(m_clients[0].model_handle, handle+i);
              __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "%u\n", status);
              status = generic_onoff_client_set(&m_clients[0], &set_params, &transition_params);
            }
            hal_led_pin_set(BSP_LED_0, set_params.on_off);
            break;

This causes the following to be true:

access_model_publish_address_set(...) {
...
else if (DSM_ADDR_MAX <= address_handle)
{
    return NRF_ERROR_INVALID_PARAM;
}

So I increased ACCESS_MODEL_COUNT to remove this error, and now I get the following when pressing button 1:

app_error_weak.c, 108, Mesh assert at 0x000340B6 (:0)

RE: Sending messages to unicast addresses

jonappleseed — Wed, 20 Mar 2019 10:35:43 GMT

Thanks, but I would like to do this without the app. I have a version of the very old SDK (alpha) in which the client could send to any individual board because m_clients was an array of the individual boards. In the new SDK however, there are only two models - one to send to even the other to odd. I would like to use one of the models for unicast sending but I cannot figure out how to.

RE: Sending messages to unicast addresses

Bjørn Kvaale — Wed, 20 Mar 2019 09:17:27 GMT

You can easily do this using the nRF Mesh smartphone app. The procedure is similar to the Youtube video shown here. What you will need to do is have one standard light switch client & one standard light switch server board. I tested with the mesh sdk v3.1.0. Then, provision both boards. On the client board in nRF Mesh, add the application key (under appkey binding, choose the first one) & set the publication address of the first generic on off client model to be the unicast address of the server board. If you click on the server board in nRF Mesh, you can see that the generic on off server is under element 0 with a unicast address (e.g. element 0. UNICAST: 0004). On the server board, you need to bind the same appkey to the generic on off server model. This way, both nodes will be able to communicate with each other over the access layer in the mesh sdk. Then, when you press button 1 & 2 on the client board, you will send an acknowledged set message to turn the server board either on or off. The procedure should be similar if you want to add multiple server boards.