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

BLE mesh flash manager

D Yuen

Hi,

I have developed BLE mesh by using nRF52832 with Mesh SDK v5.0.0. Now I am trying to implement the light switch client example.

In order to reduce the current consumption of the client node, I have tried the LPN friendship function but it is quite complicated for my design. Then I have tried to force the client to sleep if there is no need to send any message from client to server. I can success if there is only one server within the group. But when there is more than one server within the group, some servers may miss the message. Please help to answer:

a.  Can the client get the information about how many servers within the group?

b.  Since provisioner have all information about the BLE mesh network including the number of server within the group, can I embed the provisioner role inside the client program?

Thanks and Regards,

D. Yuen

Parents
  • 0

    Hi,

    a. No, there is no information about how many servers there are in the group. The closest you would get to knowing the number would be at the provisioner, although there will not be perfect information there, for several reasons:

    1. Some nodes might not be part of the network, either because they are powered off, out of network reach, or because they have left the network entirely.
    2. If there are multiple provisioners on the network, you would need updated information from all of them.
    3. It is possible to configure nodes not only from a provisioner, but from any other node (as long as that other node has the device ID of the device being configured.)

    b. While this can be done, it may or may not be a good idea, depending on the use case. If for instance you have a Bluetooth mesh network that is set up and controlled from a single smartphone app on a single smartphone, then it can work. If you intend your product to work on a common network with other Bluetooth mesh devices, then it may work badly or not work at all. Also, keep in mind the aspects from my answer to a.

    In general, your approach of "turning off the device" when it does not need to send anything, is exactly what Low Power Node does. In addition to getting turned off, it also has a Friend Node which stores incoming messages for it. Storing incoming messages can be important, or else the node may miss some of the events happening on the network. In general it is much better to work within the features specified in Bluetooth mesh, than to try to do anything non-standard. You risk breaking the qualification and/or getting poor operation if using your own solutions, especially for things that are already in the specification such as Low Power Nodes.

    Regards,
    Terje

Reply
  • 0

    Hi,

    a. No, there is no information about how many servers there are in the group. The closest you would get to knowing the number would be at the provisioner, although there will not be perfect information there, for several reasons:

    1. Some nodes might not be part of the network, either because they are powered off, out of network reach, or because they have left the network entirely.
    2. If there are multiple provisioners on the network, you would need updated information from all of them.
    3. It is possible to configure nodes not only from a provisioner, but from any other node (as long as that other node has the device ID of the device being configured.)

    b. While this can be done, it may or may not be a good idea, depending on the use case. If for instance you have a Bluetooth mesh network that is set up and controlled from a single smartphone app on a single smartphone, then it can work. If you intend your product to work on a common network with other Bluetooth mesh devices, then it may work badly or not work at all. Also, keep in mind the aspects from my answer to a.

    In general, your approach of "turning off the device" when it does not need to send anything, is exactly what Low Power Node does. In addition to getting turned off, it also has a Friend Node which stores incoming messages for it. Storing incoming messages can be important, or else the node may miss some of the events happening on the network. In general it is much better to work within the features specified in Bluetooth mesh, than to try to do anything non-standard. You risk breaking the qualification and/or getting poor operation if using your own solutions, especially for things that are already in the specification such as Low Power Nodes.

    Regards,
    Terje

Children
No Data
Related
Terms of service