Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2bndy5 opened this issue Jun 30, 2024 · 1 comment

Comments

@2bndy5
Copy link
Member

2bndy5 commented Jun 30, 2024

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.

Originally posted by @2bndy5 in #250 (comment)

@2bndy5
Copy link
Member Author

2bndy5 commented Jun 30, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant