• State Not Answered
  • Replies 3 replies
  • Subscribers 73 subscribers
  • Views 1520 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 220021
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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!

Parents
  • 0

    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

Reply
  • 0

    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

Children
Related
Terms of service