Open 2bndy5 opened 3 weeks ago
I ended up implementing this in my CirPy port (https://github.com/nRF24/CircuitPython_nRF24L01/pull/59/commits/cb9b60b0300aa11321a2f514d1be240f6a3fb24c) because mesh nodes do not allow users to explicitly set the mesh_address
(node_address
in CirPy port) -- actually nothing is private in python, so users could monkey with internals (mesh_node._addr = 0
), but this is generally discouraged. According to the mesh bonding paradigm, the mesh_address
should be read-only in the public API since it is entirely dependent on the master node's management of address leases.
I also short-circuited renew_address()
if called on a master node (https://github.com/nRF24/CircuitPython_nRF24L01/commit/007e885c5b957d90df801ca8323508af15178078). Bear in mind that the CirPy port uses inheritance to implement MESH_NOMASTER
; the RF24Mesh
class derives from RF24MeshNoMaster
class.
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 inrenewAddress()
(& its helperrequestAddress()
) when the node ID is set to 0.Originally posted by @2bndy5 in https://github.com/nRF24/RF24Mesh/issues/250#issuecomment-2197727586