• State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 66 subscribers
  • Views 4019 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 201640
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to make multiple sensor node that takes data from sensor and send to single relay node in Ble mesh networking?

Pooja

I have build the light switch demo, it works properly. But I want to make multiple sensor node that takes data from sensor and send to single relay node. I am little confused regarding client and server model. There are few questions as follows:

1. Is it sensor node act as client node?

2. Is it relay node act as a server node?

3. How i can configure border node that receives data from relay node and send it to cloud?

4. how we extend the light switch example to send sensor data over mesh to relay node?

Please give me example code and related tutorials.

Thanks in advance.

Parents
  • 0

    Hello Pooja,

    Hopefully, the following explains things a little further...

    1. Is it sensor node act as client node?

    As you are aware, Bluetooth Mesh consists of Client and Server models (there are also Control and Root models but we can put those to one side for the moment). You should note that a mesh node/device can be both a client and server at the same time (it really depends on the functionality implemented on the device).

    The Server model exposes the state(s) of a device, so in the traditional sense a light-bulb is either on or off, whilst a dimmable light-bulb can be on/off or at some brightness level (on/off/brightness level are all possible states for a dimmable light-bulb)

    The Client model sends messages to the Server model in order for the server to either change or report back its state. So a light-switch (Client) would send a message to the light-bulb (Server) to either turn itself on/off or report back its status. Alternatively, a light-switch (with the right controls) could send a dimmable light-bulb a message to set itself on/off or set its brightness level state to x% brightness. You could also imagine a more complete product implementation being one where a light-bulb (which has just come back online after a power outage) asking its designated light-switch, "hey, are you in the on or off position/or what brightness level are you set at" so that it can set itself accordingly. In this latter case, the light-bulb now becomes (the Client) and the light-switch (the Server), so both the light-bulb and light-switch would implement Client and Server models in their functionality. So as I mentioned above, this shows that there are cases where mesh nodes can be both a Client and Server simultaneously.

    In the case of a simple sensor, it would need to implement (at the very least) a server model (since it just needs to serve up/report the value of whatever it's sensing). However, there are more complex sensors that may expose sampling rates/sampling units/cadence etc. and these would need to implement a more complex server model.

    2. Is it relay node act as a server node?

    No, a relay node does not act as a server. Relaying is simply a feature that can be added to a device/node to allow it to re-transmit messages within a mesh network. For example, take the light-bulb that we discussed above, the vendor may have had the foresight (since light-bulbs generally have a powered source) to add the relay feature into their firmware thereby allowing it to re-transmit mesh messages. If they didn't however, then you'd either have to go with a different vendor or install your own devices/nodes with relay capabilities if you wanted to build out your mesh network. In short, relaying and client/server models are different features.

    3. How i can configure border node that receives data from relay node and send it to cloud?

    In short, Bluetooth Mesh doesn't define a role for a border node (unlike say the OpenThread protocol). You'd need to look at implementing your own design (e.g. the nrf52840 SoC supports both Thread and Bluetooth Mesh) and/or possibly look at the nrfCloud service offered by Nordic.

    4. how we extend the light switch example to send sensor data over mesh to relay node?

    In order to fully incorporate sensors within a Bluetooth Mesh network you really should look to implement the Bluetooth SIG defined sensor model (see: section 4 - pg #105) of the Mesh Model Specification v1.0. This will ensure that your solution is inter-operable and compliant.

    Please give me example code and related tutorials

    Based upon your question, I would recommend (reading or re-reading) the following:

    1. https://blog.bluetooth.com/an-intro-to-bluetooth-mesh-part1

    2. https://blog.bluetooth.com/the-fundamental-concepts-of-bluetooth-mesh-networking-part-1

    3. https://blog.bluetooth.com/the-fundamental-concepts-of-bluetooth-mesh-networking-part-2

    4. http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v1.0.1/md_doc_introduction_basic_concepts.html?cp=4_1_0_0_0

    5. http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v1.0.1/md_doc_getting_started_how_to_models.html?cp=4_1_0_3_4

    Regards,

Reply
  • 0

    Hello Pooja,

    Hopefully, the following explains things a little further...

    1. Is it sensor node act as client node?

    As you are aware, Bluetooth Mesh consists of Client and Server models (there are also Control and Root models but we can put those to one side for the moment). You should note that a mesh node/device can be both a client and server at the same time (it really depends on the functionality implemented on the device).

    The Server model exposes the state(s) of a device, so in the traditional sense a light-bulb is either on or off, whilst a dimmable light-bulb can be on/off or at some brightness level (on/off/brightness level are all possible states for a dimmable light-bulb)

    The Client model sends messages to the Server model in order for the server to either change or report back its state. So a light-switch (Client) would send a message to the light-bulb (Server) to either turn itself on/off or report back its status. Alternatively, a light-switch (with the right controls) could send a dimmable light-bulb a message to set itself on/off or set its brightness level state to x% brightness. You could also imagine a more complete product implementation being one where a light-bulb (which has just come back online after a power outage) asking its designated light-switch, "hey, are you in the on or off position/or what brightness level are you set at" so that it can set itself accordingly. In this latter case, the light-bulb now becomes (the Client) and the light-switch (the Server), so both the light-bulb and light-switch would implement Client and Server models in their functionality. So as I mentioned above, this shows that there are cases where mesh nodes can be both a Client and Server simultaneously.

    In the case of a simple sensor, it would need to implement (at the very least) a server model (since it just needs to serve up/report the value of whatever it's sensing). However, there are more complex sensors that may expose sampling rates/sampling units/cadence etc. and these would need to implement a more complex server model.

    2. Is it relay node act as a server node?

    No, a relay node does not act as a server. Relaying is simply a feature that can be added to a device/node to allow it to re-transmit messages within a mesh network. For example, take the light-bulb that we discussed above, the vendor may have had the foresight (since light-bulbs generally have a powered source) to add the relay feature into their firmware thereby allowing it to re-transmit mesh messages. If they didn't however, then you'd either have to go with a different vendor or install your own devices/nodes with relay capabilities if you wanted to build out your mesh network. In short, relaying and client/server models are different features.

    3. How i can configure border node that receives data from relay node and send it to cloud?

    In short, Bluetooth Mesh doesn't define a role for a border node (unlike say the OpenThread protocol). You'd need to look at implementing your own design (e.g. the nrf52840 SoC supports both Thread and Bluetooth Mesh) and/or possibly look at the nrfCloud service offered by Nordic.

    4. how we extend the light switch example to send sensor data over mesh to relay node?

    In order to fully incorporate sensors within a Bluetooth Mesh network you really should look to implement the Bluetooth SIG defined sensor model (see: section 4 - pg #105) of the Mesh Model Specification v1.0. This will ensure that your solution is inter-operable and compliant.

    Please give me example code and related tutorials

    Based upon your question, I would recommend (reading or re-reading) the following:

    1. https://blog.bluetooth.com/an-intro-to-bluetooth-mesh-part1

    2. https://blog.bluetooth.com/the-fundamental-concepts-of-bluetooth-mesh-networking-part-1

    3. https://blog.bluetooth.com/the-fundamental-concepts-of-bluetooth-mesh-networking-part-2

    4. http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v1.0.1/md_doc_introduction_basic_concepts.html?cp=4_1_0_0_0

    5. http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v1.0.1/md_doc_getting_started_how_to_models.html?cp=4_1_0_3_4

    Regards,

Children
No Data
Related