2bndy5
commented
1 year ago I detailed the connection process in the topology doc for the pyRF24 pkg (uses same C++ code under the hood); maybe that could help understanding the address assignment process (if not I'd like to know how/where I can improve the doc).
You can only set static addresses to mesh IDs from the master node using setAddress(), but I think that function was really meant to allow RF24Network nodes to be associated with a mesh ID number.
As for keeping track of which addresses are statically assigned, I think that is better served in the application code. Much like using static IP addresses in a (W)LAN, the network administrator must devise their own way of knowing which address is assigned to which device.
Am I right in thinking that if a node gets to a point where it needs to request a new address, it's almost certain that it'll be asking for that address from a node other than the one it previously routed through
It depends on the context.
- The connecting node could use the same immediate routing node if said routing node recently had a new address assigned and proximity between the two hasn't changed.
- The connecting node might also use an entirely different node to route the address request to master. This is much more likely in a network of frequently moving mesh nodes.
Remember how the network levels are structured; child nodes are also at the mercy of their parents' connection, not just their own connection to the parent.
Isn't there a race as to which mechanism claims an address first?
Yes... The mesh master node doesn't impose a time limit on assigned addresses, and you can't assign all your static addresses before calling mesh.begin() since the addrList array is allocated in RF24Mesh::begin(). Although, @TMRh20 it would be possible to allocate the addrList array in the c'tor (instead of RF24Mesh::begin()) to give priority to static address assignment. EDIT: You can assign the static addresses after calling RF24Mesh::begin() and before any call to RF24Mesh::update().
If your mesh master node is running on Linux, then loadDHCP() (also invoked by RF24Mesh::begin()) can be used to load statically assigned addresses from the binary file named dhcplist.txt located in the same directory as your app's executable. Note that the binary data structure in dhcplist.txt uses four bytes per element in addrList, not three (I can explain that more if needed).
TMRh20
svdasein
In (1) I'm pretty sure what's going on there is the master is replying directly to the node. In (2) it's replying through another node. In the act of short circuiting the address logic, I'm specifically choosing to NOT use the from_node as part of the address I want the inquring node to use -- I want to tell it that regardless of where this address response is coming back from, THIS is the address (and route) I want you to use. 
Avamander
Hi - love these libraries!
I've been puzzling hard on this and I keep hitting walls. I know that you've said in the past that mesh address assignment is dynamic and there's no logic to keep that from happening. You've also said it's possible to construct a hybrid network with both statically and dynamically assigned addresses.
Would you please explain how one would do this?
I've been toying around with the notion of having a isStatic property to the addrListStruct and somehow having that guide address assignment logic, but I'm beginning to think that I'm grossly misunderstanding how mesh address assignment works. Am I right in thinking that if a node gets to a point where it needs to request a new address, it's almost certain that it'll be asking for that address from a node other than the one it previously routed through. Which got me thinking that maybe what you're talking about is having some nodes that just set up an address when they start. But if that's the case, how can mesh and non-mesh co-exist? Isn't there a race as to which mechanism claims an address first?