If I can directly remove nodes on the Coordinator’s node_table instead of just resetting the radio, I could actively monitor and remove any nodes not whitelisted. Also would not require storing a whitelist of 30-35 nodes on the Coordinator (~150B of memory.) This way, I could:
1.) perform node id dump on Coordinator
2.) scan the list and send commands to the Coordinator to remove unauthorized nodes
3.) if no unauthorized, send command to Coordinator to no longer accept/add new nodes.
I know in the node_discovery callback that I am calling node_add() but beyond this, what happens behind the scenes?
The Digi Mesh protocol is a true peer to peer network. You can’t just remove modules from its neighbor table. If you do not want the nodes in its network, then you need to change the channel or pan ID on either one so they are not the same.
I agree. I’m just trying to better apply this protocol to this topology in a dynamic way. My router node configuration is not known ahead of time, and new router nodes come and go from these job sites. It’s not possible to say that “node X needs to be set to PAN A and node Y needs to be set to PAN B” but rather reconfigured onsite (usually just one time.)
Yeah, I think that is going to be the way to go here. I’ll have the programmable XBee send a request to an external system that knows the allowed list and if it’s a No or a Timeout then I won’t add the node ID when the discovery handler detects it.
I still don’t know yet if there’s a way to directly delete a node from the node table in any of the existing SDK libraries. Otherwise I’ll just write my own in nodetable.c