Ensuring Rapid Recovery in Mesh Networks After Power Outages of Nodes

[Creativityinengineering]

I have the following scenario: My mesh network consists of approximately 25 nodes that have successfully synchronized and can reliably communicate with the constantly powered master. In the event of a brief power outage (only nodes) lasting a few milliseconds, some nodes or all nodes may reboot. However, before shutting down, these nodes have enough energy to store their functioning network address in the EEPROM. Is it possible for such a node to rejoin the network at startup by loading the saved address from the EEPROM? The node should not remain static afterward but should also be able to move dynamically within the mesh. It is important that the network becomes operational again as quickly as possible.

[TMRh20]

Hmm, I think this would work, but the master node would need to save its address list to file as well. Depending on your configuration, this can be an SD card, Internal file system etc.

The following code on the master node could be modified to write the address list to file, instead of printing via Serial:

    for (int i = 0; i < mesh.addrListTop; i++) {
      Serial.print("NodeID: ");
      Serial.print(mesh.addrList[i].nodeID);
      Serial.print(" RF24Network Address: 0");
      Serial.println(mesh.addrList[i].address, OCT);
    }

Then when the nodes come back online, instead of having them renew their address, have them wait a short period for the master to boot up, then verify their address:

if(millis() < 10000){
    if (!mesh.checkConnection()) {
         //Do something...
    }
}else{
    if (!mesh.checkConnection()) {
        if (mesh.renewAddress() == MESH_DEFAULT_ADDRESS) {
            mesh.begin();
        }
   }
}

You may want to check the connection over a period of time, instead of just once, giving the master time to boot up.

[2bndy5]

I thought the master node would automatically keep a backup of the DHCP list when running on Linux.

I'm also under the impression that a child node booting with a cached assigned address must also restore it with mesh.mesh_address before mesh.begin(). I suppose it is also worth noting that the child's nodeID (set via mesh.setNodeID()) must remain consistent between uptime sessions.

[TMRh20]

In thinking about it a bit more, the child nodes also want to do the following on startup:

  mesh.setNodeID(253);                  // Set the NodeID
  mesh.begin(62, RF24_1MBPS, 0);  // This sets the channel to 62, datarate to 1MBPS and timeout to 0
  mesh.mesh_address = 011;          // Set to whatever the current address is
  network.begin(mesh_address);

@2bndy5 Op didn't say they are running Linux unless I missed it. I think they can do the above, setting the address after mesh.begin.

[TMRh20]

For even faster startup - 10ms of nodes, you could attempt the following:

1. On the nodes only, not master, In RF24Mesh_config.h un-comment

 // un-comment for non-master nodes not running on ATTiny MCUs
//#define MESH_NOMASTER

2. Use the following code on startup instead of my previous post:

  mesh.setNodeID(0);                      // Set the NodeID to that of a master node, so we can skip mesh renewal in mesh.begin()
  mesh.begin(62, RF24_1MBPS, 0);  // This sets the channel to 62, datarate to 1MBPS and timeout to 0
  mesh.setNodeID(253);                  // Set our valid mesh nodeID here
  mesh.mesh_address = 011;          // Set to whatever the current address is
  network.begin(mesh_address);

[Creativityinengineering]

Thank you for the quick response! Ill try that as soon as possible.

In my project, which you can find at https://www.youtube.com/watch?v=WhO5Ml7WMoo, I have developed a feedback system for model trains based on this fascinating mesh library. Currently, there are 25 nodes installed under the tracks, powered by the track voltage. When a train passes over a detector, the train address is sent to the master node connected to a computer.

My goal is to integrate as many nodes as possible. The data transfer is minimal since only the train address is transmitted briefly when a train passes a block detector.

One issue I am facing is that when the track voltage is turned on, all nodes attempt to connect to the master simultaneously, which can take 10 to 20 seconds. During this time, the trains cannot be reliably detected. The master node remains stable and retains its DHCP information; however, local nodes may temporarily lose power due to occasional short circuits caused by the locomotives. I want to ensure that the nodes quickly regain their previous state after a disruption without having to re-register, provided that the network was stable beforehand.

[TMRh20]

There isn't a good way currently to prevent the 10 to 20 second delay on the very first startup, unless you use static nodes and RF24Network directly. If you can save the addresses on both the master and individual nodes, you may be able to do it, but you will need some sort of time-buffer to ensure all nodes are online before they attempt to verify their connection etc.

For the other scenario, with nodes failing individually, the above startup code in either of the last two posts should work, although I haven't tested it fully.

[Creativityinengineering]

Thank you very much! I'll test it and share my results.

[Avamander]

I recall trying this maybe even a decade ago by now.

If I remember correctly the biggest issue was avoiding address conflicts in very long-running setups. I ended up implementing something IPv4 conflict detection like, but very primitive. Each node restored its ID and address, then announced itself to the master alongside an unique ID. The master checked if the unique ID already had a live address/ID entry in a table, if it did, it didn't respond to the announce. So when the node ended up unroutable or with a conflict, the node cleaned things up and tried anew.