detection of several events - often a ZB/XBee join event. In your situation, likely the join takes place BEFORE the Python system is booted far enough to catch it.
periodic checking for new devices. This is likely what you call the ‘second search’. Unfortunately, it places a traffic load on the system so should not occur too rapidly, plus in theory it has little value after all steady-state nodes have been detected.
There are no magic pills here. The join-event is an XBee feature and there’s no way to delay the ‘event’ which may occur long before the gateway’s C++ BIOS/core code is active enough to know there an XBee installed.
Your poblem sounds more like a development issue seen only when the gateway reboots frequently, so something which won’t be normal in the field. It is a bad idea to sub-optimize an operational system to make abnormal development better and normal field operation worse.
For development, I usually confirm that the autoeneum works, but just MANUALLY configure my nodes to avoid these issues.
It is a pain during development having to wait for the autoenum, but not a big deal.
It is prodution, that I am mainly concerned about. My system will be deployed by non-technical people and having them wait 10 minutes to have the devices found and then how to remedy it if they aren’t.
If the intial boot misses the node join, then how come when the Dia driver always finds one device on boot? I would expect no devices found until the next autoenum probe.