You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I ended up implementing this in my CirPy port (nRF24/CircuitPython_nRF24L01@cb9b60b) 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 (nRF24/CircuitPython_nRF24L01@007e885). 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 #250 (comment)
The text was updated successfully, but these errors were encountered: