Assigned Addresses lost?

eduardomarcos commented 2 years ago

Hi! First, thank you!, I've been using this lib for a long time (and still learning how to better use it). I would like to comment a strange behaviour I'm facing... to make it simple I would just use the minimum setup scenario:

One gateway (running on an ESP32)
One sensor node (running on ATMega328)
Default radio settings (channel, level, etc.) Sensor node just sends message every 5 seconds to the gateway, and gateway prints the message and also the Assgined addresses. So far so good! Here it comes the weird thing: If for some reason, I 'reset' the gateway within the 5 seconds delay that the node waits (no sleep for now, just a delay without releasing the address), when the gateway is back, the messages from node are working, but when the gateway prints the assigned addresses, there is no one. And it won't be any, unless I reset the node, or unless I reset the gateway when the node is trying to communicate with it (so the renew address happens). When this happens, the gateway will fail trying to publish a message to the node. I think in an ideal scenario it won't be a problem, because the node won't do a delay, but a sleep with a previous release address...but, if I have another 'repeater' node, it might happen I guess. So, questions:
Is this normal? Or I might be doing something wrong?
Maybe the gateway should check the assigned addresses every time I message is received?

To reproduce this, is just enough with the example sketch sending messages to a master node with a 5 seconds delay, and let the master node to print the assigned addresses. And reset it just after receiving a message so the slave node is not aware of the reset (so no renew address)

Thanks in advance!

2bndy5 commented 2 years ago

Not sure if this is relevant to reproducing, but we modified the examples in #205 to better demonstrate proper usage of renew_address(). The example changes haven't been released to the Arduino Lib manager yet...

TMRh20 commented 2 years ago

How are you managing the renewal of addresses? Are you calling checkConnection after a write fails or on a timer?

This is one scenario where there is a bit of a gap in the process. If you are only calling checkConnection when a write fails, then the node will not renew its address until there is a communication failure. If you are calling checkConnection on a timer, say every 15-30 seconds, then the node should renew its address after 15-30 seconds of this behaviour.

I guess I would recommend using both methods to ensure nodes stay online and registered with the master node.

The other option would be to just leave the master node offline longer, and the node should go into address renewal.

eduardomarcos commented 2 years ago

Hi both! Thanks for the quick response.

So I was coding the radio behaviour as you mentioned. I was just checking the connection if the write fails. I just changed that and now I checked after a priod of time and it works perfectly. I'm going to play a bit around that workaround to check I implement it correctly.

Just a thought... would it make sense for a master node to check the assigned address when a message is received? That way some slave nodes might not need to run a check connection/ renew address

If it is ok I will close this 'issue' / question as it's been solved :D

2bndy5 commented 2 years ago

would it make sense for a master node to check the assigned address when a message is received?

Depends on what you mean here. The RF24Network::update() handles incoming messages based on the logical address in the payload's header (RF24NetworkHeader::to_node). I think it would slow down the execution time on master node if the node address (and corresponding mesh ID which is only transmitted during handshake) is checked for presence in the DHCP list (which is specific to RF24Mesh) upon any reception. Furthermore, the assigned address is not un-allocated in the DHCP list unless the child node calls releaseAddress() successfully (or when the mesh node ID is re-assigned a new logical address in renewAddress()). Remember that the DHCP list is persistent on Linux devices (contrary to your experience using the ESP32 as a mesh master node).

If it is ok I will close this 'issue' / question as it's been solved :D

That's fine. The thread won't be locked, so the dialogue can continue as needed.

TMRh20 commented 2 years ago

“ Just a thought... would it make sense for a master node to check the assigned address when a message is received?”

Not really, there is no way to force the nodes to renew their address from the master, it’s up to the nodes to manage their own address.

On Jun 6, 2022, at 12:28 PM, Eduardo Marcos @.***> wrote:

Just a thought... would it make sense for a master node to check the assigned address when a message is received?

eduardomarcos commented 2 years ago

Thanks for both responses! Still playing with the changes, but looks promising. I've been always checking connection when the message transfer failed from an slave node. That was a bit annoying because I added a feature to the master node to 'print' via MQTT the assigned nodes, and for obvious reasons the result was not always the expected one :D. I'm sure with this updates it will be quite more 'reliable'

nRF24 / RF24Mesh

Assigned Addresses lost? #208