light lightness model example app questions

[Richard R]

Hello,

I am trying to create an application that uses the mesh light lightness [client/server] model using the example application as a guide and I have a few questions

1. what is the intended use case of light_lightness_client_callbacks_t ? A client as I understand it, will send get/set request and not get queried?
for example, what entity will cause app_light_lightness_client_status_cb to be triggered? another model that is getting status from light lightness clients?

2. If all I want is the light_lightness client/server model (without generic on/off or generic level) is it okay to create a custom light_lightness_server_init() that does not try to initialize any generic models? Other that not being able to interact with a generic based clients is there any drawback to this? I realize that the bluetooth mesh spec mentions bindings with other models but is that mandatory or optional?

3. Are the model support in the nRF5-Mesh-SDK assumes that all bindings are present and callable? I don't want to bloat code with generic models if I don't have to and I still want to use the
APIs provided via /modes/model_spec/

Thanks for everyone's time,

Richard

[Hung Bui]

Hi Richard, 

1. You can always search in the whole project to find any usage of a function (Ctrl+Shift+F). 
For example if you do a full search for "lightness_status_cb" , you can find that it's called inside status_handle() in light_lightness_client.c 

This function status_handle() is called when handling opcode LIGHT_LIGHTNESS_OPCODE_STATUS (check m_opcode_handlers[]) This is the message to be sent back after you send the status get message. 

2. If you don't plan to allow 3rd party devices to connect to your mesh network you can define your own proprietary model and it's completely fine with that. We provide an example of simple_on_off model in models/proprietary folder. Regarding the requirement by the spec, please refer to the note in the spec to check if it's mandatory or not:

3. As far as I know to be able to qualify for a certain Bluetooth Sig Model you must have all the mandatory M that marked in the spec: 

Note that you don't need to qualify the model if you don't want to, you still can use Bluetooth Mesh without qualifying the Bluetooth Sig model. 

[Richard R]

Hi Hung,

@1: I understand the call sequence that ends with responding to LIGHT_LIGHTNESS_OPCODE_STATUS. What I am not clear is that why a client device need to respond at all. If you look at Section 6.6.1 in your reply, the client side messages are [O]ptional or [C]onditional. I am trying to understand from a usage perspective, what kind of a device would be sending messages to a light-lightness-client to get its status. Normally, one will get status from a server device, not a client device.

@2. I also want to understand that the nRF5-mesh-SDK does not have limitations if I want to just use light-lightness from the model (without creating instances or bindings of the generic models like the example code).

[Hung Bui]

HI Richard, 

1. Note that the LIGHT_LIGHTNESS_OPCODE_STATUS  is not a get opcode, it's the status message from the server send to the client, after the client send the LIGHT_LIGHTNESS_OPCODE_GET. If you have a look at the handle_get() function in the server, you can find that it will reply with LIGHT_LIGHTNESS_OPCODE_STATUS in status_actual_send().

2. I haven't tried myself but I don't see a problem if you simply only send LIGHT_LIGHTNESS_OPCODE_* opcode from the client. Note that in mesh the client doesn't need to know/discover the service of the server before it can communicate, not like in BLE. It's only the provisioner doing composition data to get the structure of the server. If you have control over the provisioner it should be fine. Or even if you don't have control over the provisioner, I don't think it would be a problem if the generic model is missing.