• State Verified Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 1319 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 236233
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Reasons of having Models and elements in Nrf Mesh Protocol

bivay

I have one doubt that why there is elements or models in Bluetooth, it can be simple as sending messages and then translate them into useful work, in this single element and model needed, no need to worry about future expansion in code side if it provisioned or not.

I searched many time for this reason but didn't get answer. I asked Bluettoth SIG about it, but didn't get response from there.

How models are better than one single model with only trans receive of messages and then use message as need.

I didn't means that Models are wrong or anything else, and I know if it is standard, then there must be reason for it. I want to know that reason.

Please if anybody have knowledge about logic behind models, then please explain.

Thank You

Bivay

Parents
  • +1

    Hi,

    Models provide a framework for modeling the data that you want to send and receive. It fills the same role as GATT Services do in Bluetooth Low Energy (BLE). As with any communication protocol, you need a way to pack your payload into units that are understood in both ends, and for Bluetooth mesh this is done through the Mesh models.

    There is a set of models that are specified by the Bluetooth SIG. One of the goals of defining those models is to ensure compatibility between devices from different vendors.

    In addition to the Bluetooth SIG models, you are free to make your own (vendor specific) models covering your needs. This gives you the flexibility to implement whatever you want, when you do not need the compatibility of the SIG models.

    Messages from SIG models and vendor specific models are treated equally over the network, as the lower stack levels are agnostic to what model a message belongs to.

    In our nRF5 SDK we have made a "UART over BLE" Service for providing a general two-way byte stream between two BLE devices. You could do something similar for Bluetooth mesh. Note however that throughput in Bluetooth mesh is low compared to BLE.

    Regarding the reason why Bluetooth mesh is made this way, I think in huge part it boils down to the fact that GATT Services has been a success in BLE (and still is.)

    Regards,
    Terje

  • 0 in reply to tesc

    GATT Service is success I agree with you.

    I doesn't think that compatibility of device between two different manufacture is big issue, if one can send message then he/she also can use this message. So compatibility between different vendor is due to Mesh Protocol, not by Models, i think. as there are no fixed defined format of models to be used .

    Yes I created my own model of transmission of messages only, and it is successful. No issue in communication, one time easy to config system.

    But When I see everywhere people uses light dim on off like models instead of single message type model.

    So I have doubt on me if I am going in wrong direction. So, I asked this question.

  • 0 in reply to bivay

    Hi,

    Compatibility is important for instance if you make switches, or if you make light bulbs. In order for the switch to toggle the light bulb, they must both understand the same messages. The concept of "Models" ensures this. It lets the provisioner configure devices from different manufacturers, so that they communicate with each other (using the same model).

    On the one hand, making your own protocol on top of a simple model should be OK. It means you add an extra "abstraction layer" on top of what is described in the Bluetooth mesh specification, but there is nothing preventing you from doing so.

    On the other hand, implementing what you need directly as models would be more idiomatic use of Bluetooth mesh, and you would likely avoid some overhead.

    In the end, the choice is yours.

    Regards,
    Terje

Reply
  • 0 in reply to bivay

    Hi,

    Compatibility is important for instance if you make switches, or if you make light bulbs. In order for the switch to toggle the light bulb, they must both understand the same messages. The concept of "Models" ensures this. It lets the provisioner configure devices from different manufacturers, so that they communicate with each other (using the same model).

    On the one hand, making your own protocol on top of a simple model should be OK. It means you add an extra "abstraction layer" on top of what is described in the Bluetooth mesh specification, but there is nothing preventing you from doing so.

    On the other hand, implementing what you need directly as models would be more idiomatic use of Bluetooth mesh, and you would likely avoid some overhead.

    In the end, the choice is yours.

    Regards,
    Terje

Children
Related