mesh.checkConnection via parent not master

[TMRh20]

These changes tend to allow more nodes on a network, especially helping distant nodes (far from master node) with verifying connectivity as they only have to verify a connection with their parent node, instead of the master node. Tends to help with keeping the mesh together as nodes closer to the master node change their postition and/or address as the mesh changes physically or logically.

• Adjust mesh.checkConnection function to verify connectivity with parent only. Leave old functionality in place with a #define
• Suggestions in place per @2bndy5
• closes #249

Since this fundamentally changes behaviour of the mesh, I've tested the changes pretty well, and its looking good for these changes. I'm seeing greater connectivity, less packet loss, and a mesh that behaves a bit better.

Its not 5-9s, but its probably about as good as it gets after 1 day of testing with most nodes upgraded to this new functionality:

[github-actions[bot]]

Memory usage change @ 8c494aebb312c5725ac38004f320f658f0c4febe

Board	flash	%	RAM for global variables	%
arduino:avr:nano	:grey_question: -152 - +70	-0.49 - +0.23	0 - 0	0.0 - 0.0
arduino:samd:mkrzero	:small_red_triangle: 0 - +44	0.0 - +0.02	0 - 0	0.0 - 0.0

Click for full report table

Board|`examples/RF24Mesh_Example`
flash|%|`examples/RF24Mesh_Example`
RAM for global variables|%|`examples/RF24Mesh_Example_Master_Statics`
flash|%|`examples/RF24Mesh_Example_Master_Statics`
RAM for global variables|%|`examples/RF24Mesh_Example_Master_To_Nodes`
flash|%|`examples/RF24Mesh_Example_Master_To_Nodes`
RAM for global variables|%|`examples/RF24Mesh_Example_Node2Node`
flash|%|`examples/RF24Mesh_Example_Node2Node`
RAM for global variables|%|`examples/RF24Mesh_Example_Node2NodeExtra`
flash|%|`examples/RF24Mesh_Example_Node2NodeExtra`
RAM for global variables|%|`examples/RF24Mesh_SerialConfig`
flash|%|`examples/RF24Mesh_SerialConfig`
RAM for global variables|%|`examples/RF24Mesh_Example_Master`
flash|%|`examples/RF24Mesh_Example_Master`
RAM for global variables|% -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- `arduino:avr:nano`|-152|-0.49|0|0.0|0|0.0|0|0.0|0|0.0|0|0.0|64|0.21|0|0.0|70|0.23|0|0.0|0|0.0|0|0.0|0|0.0|0|0.0 `arduino:samd:mkrzero`|40|0.02|0|0.0|0|0.0|0|0.0|0|0.0|0|0.0|40|0.02|0|0.0|44|0.02|0|0.0|0|0.0|0|0.0|0|0.0|0|0.0

Click for full report CSV

``` Board,examples/RF24Mesh_Example
flash,%,examples/RF24Mesh_Example
RAM for global variables,%,examples/RF24Mesh_Example_Master_Statics
flash,%,examples/RF24Mesh_Example_Master_Statics
RAM for global variables,%,examples/RF24Mesh_Example_Master_To_Nodes
flash,%,examples/RF24Mesh_Example_Master_To_Nodes
RAM for global variables,%,examples/RF24Mesh_Example_Node2Node
flash,%,examples/RF24Mesh_Example_Node2Node
RAM for global variables,%,examples/RF24Mesh_Example_Node2NodeExtra
flash,%,examples/RF24Mesh_Example_Node2NodeExtra
RAM for global variables,%,examples/RF24Mesh_SerialConfig
flash,%,examples/RF24Mesh_SerialConfig
RAM for global variables,%,examples/RF24Mesh_Example_Master
flash,%,examples/RF24Mesh_Example_Master
RAM for global variables,% arduino:avr:nano,-152,-0.49,0,0.0,0,0.0,0,0.0,0,0.0,0,0.0,64,0.21,0,0.0,70,0.23,0,0.0,0,0.0,0,0.0,0,0.0,0,0.0 arduino:samd:mkrzero,40,0.02,0,0.0,0,0.0,0,0.0,0,0.0,0,0.0,40,0.02,0,0.0,44,0.02,0,0.0,0,0.0,0,0.0,0,0.0,0,0.0 ```

[2bndy5]

I also added the ability to use the old behavior in CMake builds: https://github.com/nRF24/RF24Mesh/blob/458e9648b414b31513f4f8a5f2ef973bbf79673a/CMakeLists.txt#L146-L149

cd RF24Mesh/build
cmake .. -DRF24MESH_CONN_CHECK_TYPE=RF24MESH_CONN_CHECK_MASTER
make

I haven't actually tested this yet. It might be more effective to add the CMake option to examples_RPi/CMakeLists.txt (instead of root/lib CMakeLists.txt).

[2bndy5]

It might be more effective to add the CMake option to examples_RPi/CMakeLists.txt (instead of root/lib CMakeLists.txt).

I think this would apply to any macro wrapped with #ifndef guards. This idea would be better suited to a different PR. For now, I'll leave it as is until I get around to investigating further. Currently, the Linux builds are working fine.

[2bndy5]

Would it make sense to return true if checkConnection() is called on a master node?

As long as the master node's radio is idling in RX, I think this would be interpreted as "connected to the mesh." Otherwise, user code written for both master and child nodes might end up calling renewAddress() on master node if their code doesn't understand that it is running the master node. I see no considerations in renewAddress() (& its helper requestAddress()) when the node ID is set to 0.

[TMRh20]

Damn, you've been busy @2bndy5

Would it make sense to return true if checkConnection() is called on a master node?

I was thinking the same thing.

Will have to look at your other comments tomorrow probably, but at a glance they all add up.

[TMRh20]

Thanks for making the necessary changes!

Been testing extensively and there are some drawbacks:

• Nodes tend to stay connected at one mesh location for longer. This can be good, but if nodes with somewhat spotty connections attach as direct child nodes of the master, they may hold their position for longer.
• Distant nodes with a spotty connection to master may also hold their position longer, even though they are having connectivity issues.
• These drawbacks can be somewhat mitigated by additional connection checking/renewal of addresses if connections are failing. For example, when using RF24Mesh directly, I just use a timer to verify connectivity every 10-30 seconds. It may also be beneficial to verify if writes/connections are failing and renew the address upon multiple failures. With RF24Ethernet, I've added a line to many of my nodes to always renew the address if unable to connect to MQTT.
• Nodes can get 'lost'. If an address is set to 0 or the mesh is quickly restarted, nodes may be able to verify their connectivity with their parent node, but have no bi-directional communication with the master node. Again it may be suitable to verify connectivity with the master node periodically, or leave the master node off for long enough so all nodes are in a state of renewal to work around this issue.

[2bndy5]

cherry picked to v1.x