light lightness model example app questions

RE: light lightness model example app questions

Hung Bui — Tue, 23 Feb 2021 15:43:50 GMT

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.

RE: light lightness model example app questions

Richard R — Mon, 22 Feb 2021 15:55:30 GMT

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).

RE: light lightness model example app questions

Hung Bui — Mon, 22 Feb 2021 15:43:09 GMT

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.