What does it mean to "extend" a Bloetooth Mesh model

[Nebojsa_J]

Bluetooth Mesh specification uses the concept of composite models that "extend" other models. I am having trouble understanding the scope of this concept within the Mesh specification and how it relates (if at all) to the nrf Mesh SDK.

- For example the Mesh spec states that: "The Generic Power OnOff Server model extends the Generic OnOff Server model." Is this concept only there to make the spec more readable?        Basically, does extending a model just mean that your composite model will support all states/messages/opcodes as the model(s) it extends. 

- Or does this concept stretch further and there is a formal way of including a model in another model. If so, how is this done?

- As an example, how would you go about implementing the Generic Power OnOff Server model using the nrf Mesh SDK? Does it mean that you can somehow literally include (re-use) the (already existing in SDK) Generic OnOff Server model and just add any new states/messages etc? .... Or this kind of extending is not what they really intended and you just have to specify all opcodes/messages/etc from scratch when you develop the new composite model?

I appreciate your help!

[Edvin]

Hello,

I had not heard of "extending a Bluetooth Mesh Model" before, so I asked one of our Bluetooth Mesh developers, and forwarded your questions. These are his replies:

 

- For example the Mesh spec states that: "The Generic Power OnOff Server model extends the Generic OnOff Server model." Is this concept only there to make the spec more readable?        Basically, does extending a model just mean that your composite model will support all states/messages/opcodes as the model(s) it extends. 

 No, the concept does not exist to make the spec more readable. The concept of models defines the high level behavior of the end-device, which uses that model. A model is identified by the model ID. When the provisioner detects that a certain model ID is present on the device it understands what the device can do. Extending a model means exactly what you said, and in addition to that extended models can add its own set of behaviors/states/messages. Extended models also have their own model IDs.

- Or does this concept stretch further and there is a formal way of including a model in another model. If so, how is this done?

 This concept is similar to the concept of classes, where one class can extend another and inherit its properties and functions.

From an implementation perspective, it is up to the user to choose any suitable implementation. You do not need to physically include one model code into another, but instead do the hierarchical initialization of the models so that initializing the highest level model will also initialize the lower level instances of the model that it extends.

 

- As an example, how would you go about implementing the Generic Power OnOff Server model using the nrf Mesh SDK? Does it mean that you can somehow literally include (re-use) the (already existing in SDK) Generic OnOff Server model and just add any new states/messages etc? .... Or this kind of extending is not what they really intended and you just have to specify all opcodes/messages/etc from scratch when you develop the new composite model?

 You would use the existing generic on off server. Call the "generic_onoff_server_init(&p_server->server, element_index)" API from the extended model's initialization API. This extended model's init API can accept the callbacks for all the parent models and the extended model itself and you can implement your behavior in those callbacks.

This is what he wrote. So my understanding is that the model that you create, which is an extension of the on_off model, will call the initialization, and handle the callbacks for the model that it is extending.

Best regards,

Edvin

[david_owtschinnikow]

Thank you for the explanation. I have a question regarding implementation: When you finally implement the Generic Power OnOff Server, will the provisioner "detect" just one model (Gen. Power OnOff which "contains" the capabilities of the Gen. OnOff), or will it see 2 seperate models which share the subscription list (Gen. OnOff + Gen.Power OnOff)? 

Thank you very much

[Edvin]

I would assume that the provisioner only detects the model that you enable. So if you have an extended model it will recognize the model IDs of the device. I assume that if it is a light with only the on_off model, it will be considered as one model, but if it was a dimmable light, it would be seen as one element with several models. Please see this site from Bluetooth.

So one model is basically "one variable" that you can change. If an element has several variables, it will be divided in several models.