Multiple generic level models using same level_set_cb()

[DeveloperZ]

Hello,

I am using 15.2.0 SDK and 3.1.0 Mesh SDK.

I was trying to control two LED's on the nRF52DK using two generic level server models. I made following changes to the code for dimming_server:

Added an extra PWM module, initialized and enabled it to control different LED -

APP_PWM_INSTANCE(PWM1, 2);
app_pwm_config_t m_pwm1_config = APP_PWM_DEFAULT_CONFIG_1CH(1000, BSP_LED_1);
uint32_t status1 = app_pwm_init(&PWM1, &m_pwm1_config, NULL); APP_ERROR_CHECK(status1);
app_pwm_enable(&PWM1);

Then, created a new level server model -

APP_LEVEL_SERVER_DEF(m_level_server_1, APP_CONFIG_FORCE_SEGMENTATION, APP_CONFIG_MIC_SIZE, NULL, app_level_server_set_cb, app_level_server_get_cb);

Modified level_set_cb() as below differentiate between models using model handles -

static void app_level_server_set_cb(const app_level_server_t * p_server, int16_t present_level)
{
    /* Resolve the server instance here if required, this example uses only 1 instance. */
    m_pwm0_present_level = present_level;
    if(p_server->server.model_handle == m_level_server_0.server.model_handle)    
         (void) app_pwm_channel_duty_ticks_set(&PWM0, 0, scaled_pwm_ticks_get(m_pwm0_present_level));
    else if(p_server -> server.model_handle == m_level_server_1.server.model_handle)
         (void) app_pwm_channel_duty_ticks_set(&PWM1, 0, scaled_pwm_ticks_get(m_pwm0_present_level));   
}

And initiated both the generic level models in the app_model_init().

I provisioned the board and when I try to set the dimming level using the app, both the models control BSP_LED_0 whereas they are supposed to control different LED's.

Similar behavior is observed with generic_onoff models too.

I am using the model handle to differentiate between them which ain't working. Is there any other way to achieve the control over two LED's?

Thank you.  

[Hung Bui]

Hi,

Have you made sure you define the 2 models on 2 different elements ? 

By spec, on an element there should be only one model per one opcode. In your case my understanding is that the access layer will just call the call back for the first model and ignore the 2nd one. 

If you have the model bound to two different elements, you can simply use the different address of the element to control each server. You can find multiple same models bound to different elements in the light switch client example. 

[DeveloperZ]

Hi,

I think I found the issue but I am not completely sure. I was able to control two generic_level_servers using the nRF Mesh Android App. But, When I erase and flash the board with same code, I am unable to control them with the nRF Mesh iOS app. 

Would this be a glitch in the iOS app that it is unable to control whereas the Android app can control?

[Hung Bui]

Different from BLE service/characteristic, the mesh model handle is not transferred on mesh message, only the opcode and the address of the element. This is why you should avoid having two identical models (which use same opcode) on the same element. 

I'm not sure why it work on your Mesh Android App. The model handle is local on the nRF5 and is not distributed in the composition data. 

[DeveloperZ]

Hi,

Hung Bui said:

This is why you should avoid having two identical models (which use same opcode) on the same element. 

Yes, I did define them in different elements.

Hung Bui said:

I'm not sure why it work on your Mesh Android App. The model handle is local on the nRF5 and is not distributed in the composition data. 

I declared different functions for setting the levels on the servers rather than using the model handle to differentiate in a single function that I mentioned earlier i.e, I used different level_set_cb() functions for two models. That's how I was able to access models separately using Android App.  

That's why I think there is an issue in the iOS app.

[Hung Bui]

Please check and debug the message you receive from the app. You can start from the access layer, at mesh_msg_handle() in access.c 

You can add more information into the log in the function to print out the address of the element the message for. After that you can trace down to the access_incoming_handle() this is when the model handle is identified and then the call back for the opcode of the model will be called. 
Since the Android App works fine, it should be pretty easy to spot the difference between the message from Android and the one from iOS. 

I suspect a bug on iOS that only send the message for the first model in one node. 

[DeveloperZ]

Hi,

Hung Bui said:

I suspect a bug on iOS that only send the message for the first model in one node. 

I reported the bug to the iOS Mesh library on GitHub.

Thank you.