1 of 1 people found this helpful
I believe those messages are handled by the mesh model libraries.
Smart Light can be used as a regular bulb or as a light controller. If it is working as a light controller then it should process occupancy sensor data.
You can use the light controller option in mesh client to test the light smart application.
(Select the light smart node - > light controller -> set/get)
That makes sense, and the light controller does work. However, for my application I want to override the default behavior that is executed when those messages are received. In particular, I want to process occupancy sensor messages in order to create custom behavior when occupancy is detected/not detected. In order to do that I think I need access to them in my message handler. Is this something that can be done from the user application or is there another way it has to be done, such as extending the model or creating a new model that can process these messages?
2 of 2 people found this helpful
In the current implementation, the over the air messages are processed by mesh model library. Application is notified only if HW needs to access, for example, if brightness of the bulb needs to be changed.
I guess there are multiple ways you can proceed. First you can completely bypass mesh_models library. See mesh_app_lib/mesh_application.c
// Application can set this handler to process if it implements models layer.
wiced_bt_mesh_core_received_msg_handler_t p_app_model_message_handler = NULL;
If you provide p_app_model_message_handler, you will have to process everything.
This is probably pretty big development, but you can do everything.
The second method is to hook into processing of the specific Opcode. When Mesh Core receives a message, it calls mesh_app_lib\mesh_application.c
wiced_bt_mesh_core_received_msg_handler_t get_msg_handler_callback(uint16_t company_id, uint16_t opcode, uint16_t *p_model_id, uint8_t *p_rpl_delay)
to return the message handler based on the opcode that has been received over the air. You can see the loop in the function that goes through all elements, and all models and it asks each model if this opcode is for this model. You can probably provide your callback for the situation if opcode is WICED_BT_MESH_OPCODE_SENSOR_STATUS. If you want your functionality in addition to the standard LC functionality, you can call
void light_lc_server_process_sensor_status(wiced_bt_mesh_event_t *p_event, mesh_light_lc_state_t *p_state, uint8_t *p_data, uint16_t data_len)
after your completed your processing.
Another method is to provide your callbacks in the device definition. For example, Light Smart application defines 2 elements
wiced_bt_mesh_core_config_model_t mesh_element1_models =
wiced_bt_mesh_core_config_model_t mesh_element2_models =
If you expand WICED_BT_MESH_MODEL_LIGHT_LC_SERVER you will see all the callbacks. You should be able to provide yours.