This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Get temperature and heartbeat data after mesh provisioning

Hi dear Nordic engineers and enthusiasts,

I am currently testing and researching on the functionalities of Nordic Thingy 52 in Bluetooth Mesh. I have tested with the provided mesh provisioning demo:

https://github.com/NordicPlayground/thingy52-mesh-provisioning-demo

and it is indeed cool.

In the mesh demo, the client is able to send a message (button pressed), and then the server which subscribe will react eventually. It works well.

Now it comes to my question that is it possible for the servers (the lamps for instance, thingy in the case here) to send the pass the following messages on via (in) mesh network to a gateway (e.g. Raspberry Pi 3):

  • Message 1: their temperature data collected
  • Message 2: their heartbeat data, to tell how long their battery can still last

I had tried to understand the codes behind the mesh provisioning demo provided by Nordic. It seems that heartbeat.c publish heartbeat message, but I am still figuring the way to retrieve this message at the gateway. Besides, the temperature data should be able to be passed via the mesh network right?, beside the functionalities of button pressed, e.g. in the GPIOTE_IRQHandler.

I sincerely appreciate your time and effort looking into this concern. Thank you so much! I am looking ward to hearing from you.

Best regards,

Parents
  • Hi,

    In the provisioning demo, if you configure the publication address of the light bulb (the server), it will send a message to the publication address when the state is changed. You can make your own model to do similar thing to report the temperature. 

    I don't think you can add the battery status to the heartbeat. It meant to have only the initial TTL to know how far a node is to the other. 

    You can think of using health message instead. But it also has a limitation that the client has to subscribe to the server. Group address is not possible. 

    In your case I would think of making your own proprietary model to broadcast data about the battery. 

    Note that the demo was based on an old SDK: v2.2. The current SDK is v3.1 . I would suggest to start your development on a new SDK. 

  • Hi Hung Bui,

    Thank you for your kind reply and insights. I have some following questions:

    1. If GPIOTE_IRQHandler is responsible for handling the event generated by a button press, then which will it be for access to the temperature data? Do I have to generate UUID, or write on CCCD (Client Characteristic Configuration Descriptor), for forwarding the temperature sensor data? 
    2. Thanks for the correction. You are right, Heartbeat msg are for telling whether the node is still active and how far the recipient is from it. As you mentioned about health message, the health_server.c sends the attention about the faults of the node. What is of my concern is that whether is it possible that the node will forward its status of e.g. low battery, let's say less than 5% of battery, using the nodes in the mesh as hopping points to pass the data to the gateway. In the end, the low-battery-node (faulty node) could then be located and replaced before its operation stop.

    I appreciate your time Hung Bui. I hope to hear from you again.

Reply
  • Hi Hung Bui,

    Thank you for your kind reply and insights. I have some following questions:

    1. If GPIOTE_IRQHandler is responsible for handling the event generated by a button press, then which will it be for access to the temperature data? Do I have to generate UUID, or write on CCCD (Client Characteristic Configuration Descriptor), for forwarding the temperature sensor data? 
    2. Thanks for the correction. You are right, Heartbeat msg are for telling whether the node is still active and how far the recipient is from it. As you mentioned about health message, the health_server.c sends the attention about the faults of the node. What is of my concern is that whether is it possible that the node will forward its status of e.g. low battery, let's say less than 5% of battery, using the nodes in the mesh as hopping points to pass the data to the gateway. In the end, the low-battery-node (faulty node) could then be located and replaced before its operation stop.

    I appreciate your time Hung Bui. I hope to hear from you again.

Children
Related