Best method to determine a mesh node is able to communicate with other node

RE: Best method to determine a mesh node is able to communicate with other node

Mttrinh — Wed, 05 Aug 2020 15:04:47 GMT

Hi,

Sorry for the late reply. Most of our staff have been away on holiday and I just got back from vacation, hence the delay in response.

From our developer regarding this:

This will not work all the time. First, it is not advisable to modify core stack modules. Secondly, even if customer implements this idea, he will still miss the checking of online status if the node receives a packet, but the packet does not reach the access layer (for example, friendship packets, or packets that are only relayed but not consumed).

The better idea to check if the node is receiving any packet or not, is to use "internal_event.c" module, and observe the "INTERNAL_EVENT_NET_PACKET_RECEIVED". To use this module, set `INTERNAL_EVT_ENABLE` to `1` in the `nrf_mesh_config_app.h` file, and call `internal_event_init()` API from the `main.c` file.

RE: Best method to determine a mesh node is able to communicate with other node

choehyunho — Fri, 10 Jul 2020 06:24:28 GMT

I have added simple public API function to check online status from application side like below.

I assumed that if the message is arrived in access_incoming_handle(), it means that this node is on-line, i.e. can receive or send to other nodes.

Can you check whether my assumption is valid?

Index: /trunk/nRF5_SDK_for_Mesh/mesh/access/src/access.c
===================================================================
--- /trunk/nRF5_SDK_for_Mesh/mesh/access/src/access.c	(revision 113)
+++ /trunk/nRF5_SDK_for_Mesh/mesh/access/src/access.c	(revision 114)
@@ -72,4 +72,5 @@
     uint8_t is_load_failed : 1;
     uint8_t is_restoring_ended : 1;
+    uint8_t is_online : 1;
 } local_access_status_t;
 
@@ -953,4 +954,5 @@
     m_status.is_metadata_stored = 0;
     m_status.is_load_failed = 0;
+    m_status.is_online = 0;
 
     mesh_config_file_clear(MESH_OPT_ACCESS_FILE_ID);
@@ -1008,4 +1010,7 @@
 {
     const nrf_mesh_address_t * p_dst = &p_message->meta_data.dst;
+
+    /* If there is a incoming message whether it is for relay or not, it means onlined. */
+    m_status.is_online = 1;
 
     if (nrf_mesh_is_address_rx(p_dst))
@@ -1091,4 +1096,5 @@
     m_status.is_load_failed = 0;
     m_status.is_restoring_ended = 0;
+    m_status.is_online = 0;
 }
 
@@ -1986,2 +1992,12 @@
     return NRF_SUCCESS;
 }
+
+bool nrf_mesh_is_device_online(void)
+{
+    if (nrf_mesh_is_device_provisioned() && m_status.is_online)
+    {
+        m_status.is_online = 0;
+        return true;
+    }
+    return false;
+}
Index: /trunk/nRF5_SDK_for_Mesh/mesh/core/api/nrf_mesh_externs.h
===================================================================
--- /trunk/nRF5_SDK_for_Mesh/mesh/core/api/nrf_mesh_externs.h	(revision 113)
+++ /trunk/nRF5_SDK_for_Mesh/mesh/core/api/nrf_mesh_externs.h	(revision 114)
@@ -226,4 +226,14 @@
 extern bool nrf_mesh_is_device_provisioned(void);
 
+/**
+ * Checks if the device is online.
+ *
+ * @note The result is reset every time after it was read.
+ *
+ * @retval true   The device is online.
+ * @retval false  The device is not online.
+ */
+extern bool nrf_mesh_is_device_online(void);
+
 /** @} end of NRF_MESH_EXTERNS */
 
Index: /trunk/nRF5_SDK_for_Mesh/mesh/stack/api/mesh_stack.h
===================================================================
--- /trunk/nRF5_SDK_for_Mesh/mesh/stack/api/mesh_stack.h	(revision 113)
+++ /trunk/nRF5_SDK_for_Mesh/mesh/stack/api/mesh_stack.h	(revision 114)
@@ -214,4 +214,14 @@
 
 /**
+ * Check if the device is online.
+ *
+ * @note The result is reset every time after it was read.
+ *
+ * @retval true   The device is online.
+ * @retval false  The device is not online.
+ */
+bool mesh_stack_is_device_online(void);
+
+/**
  * Resets the device.
  *
Index: /trunk/nRF5_SDK_for_Mesh/mesh/stack/src/mesh_stack.c
===================================================================
--- /trunk/nRF5_SDK_for_Mesh/mesh/stack/src/mesh_stack.c	(revision 113)
+++ /trunk/nRF5_SDK_for_Mesh/mesh/stack/src/mesh_stack.c	(revision 114)
@@ -214,4 +214,9 @@
 }
 
+bool mesh_stack_is_device_online(void)
+{
+    return nrf_mesh_is_device_online();
+}
+
 #if PERSISTENT_STORAGE
 static void mesh_evt_handler(const nrf_mesh_evt_t * p_evt)

RE: Best method to determine a mesh node is able to communicate with other node

Mttrinh — Mon, 22 Jun 2020 14:32:25 GMT

The health server attention callback has a very specific function. This callback is triggered after receiving a Health Server Attention Set message. So, you may, for example, blink an LED in this callback after receiving a message. This way you can get a visual indication that there is a connectivity between two nodes.

RE: Best method to determine a mesh node is able to communicate with other node

choehyunho — Mon, 15 Jun 2020 07:46:36 GMT

Hi, Mttrinh.

Thank you for your answer. I was quite dedicated to another task and still haven't enough time to this subject.

But, while reviewing some features in the Mesh SDK, I think Mesh health server/client model can be useful for this purpose.

Is it possible that I assign health_server_attention_cb in my main procedure and get some information about this node is linked with other nodes or not?

Because I just wonder about the whole node status, not the specific model, this may be better for my purpose.

RE: Best method to determine a mesh node is able to communicate with other node

Mttrinh — Tue, 02 Jun 2020 09:11:37 GMT

Hi,

Sorry for the late response.

I would suggest making use of the available mechanisms. I see two ways to implement this:

Method 1:
For desired received model messages, you can intercept the "access_message_rx_meta_t" data which contains the RSSI value, and use this value to drive LEDs as per your choice.

This is bit hacky and it will require intercepting this information either in `app_*.c` modules, or in `access.c` module in `access_incoming_handle()` function.

Method 2:
This is more elaborate but more powerful. You can implement and make use of the RSSI monitor models in the combination of health server and client models (that can publish health status messages periodically). The RSSI models are described here:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v4.1.0/md_models_vendor_rssi_monitor_README.html?cp=7_2_2_4_5_2