Missing RNode at startup causes RNS/NN termination

[whitecd]

If a defined RNode is not present at RNS/NN startup, the RNS/NN will terminate with an error: [Error] The contained exception was: [Errno 2] could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0' It would be advantageous if the USB port could be treated as a plug device, such that RNodes could be plug-n-play at startup, similar to their behavior after startup with "panic_on_interface_error = No".

I can foresee situations where one or more RNodes could be added to a running RNS node on an AD-HOC manner, i.e., to expand the transport node's capability to support another frequency. Essentially a "bring-your-own-radio" scenario. This would be especially useful if RNS could be configured to use the pre-configured RNode radio characteristics. I thought this was the case, but when I comment out the radio configuration in the 'config'. I get these terminal errors: [2022-07-27 11:17:30] [Error] The interface "RNode LoRa Interface" could not be created. Check your configuration file for errors! [2022-07-27 11:17:30] [Error] The contained exception was: '<' not supported between instances of 'NoneType' and 'int'

Thanks for your time and efforts.

[markqvist]

This behaviour was actually the intention originally, but I agree that it needs to be made a bit more intelligent at this point. The v2 RNode firmware will behave more like this by default. Lets work out a sensible way for this to behave once I am back on the grid ;)

[markqvist]

I guess the best approach to this would simply be for RNS to keep trying to connect to the RNode at some interval, and report the interface as down in rnstatus until it is able to open and configure it.

[whitecd]

I found that there is support for USB hotplug/udev in Python3. Given the underlying OS support for hotplug/udev they may give you a level of OS abstraction and be more interrupt driven than polling. But either would work. I do something similar in OpenWRT (linux) to support ad-hoc addition of additional WAN devices- USB dongles, tethered iPhones and Androids, WiFi APs, etc. Thus, autonomous auto-configuration on site. In the case of 'bring-your-own-radio', you would want might want the option to inherit the non-volatile RF configuration. Also, could have a config variable to control the response of not having a RNode present (as designed) or operated under a hotplug/udev approach. Thank you for considering the enhancement.

[markqvist]

This is interesting, I did not know. That would improve things considerably. This will not be back-portable to the V1 branch of the firmware, but should probably be the way to go on V2. Also, the way things work currently in V2 is that the RNode itself has the RF configuration in non-volatile memory, and that RNS will use that by default, unless something else has been specified in the RNS config to override it (and the RNode config allows that).