Currently NUT drivers require an USB device which matches all configured criteria for detection. Unfortunately data points like bus or device may change over time (e.g. upon re-plugging), and VID:PID may be not unique if somebody monitors several closely related devices (from the same OEM or vendor, likely same model) while serial fields are not populated.

• NOTE: At least in libusb-0.1 model, the OS-provided (possibly end-user tailored) device node paths are not a consulted data point, as far as is known/assumed, so a dummy port = auto is typically used (some port value is required for generic NUT driver config syntax). Related issue Extend NUT USB drivers with libusb-1 to not ignore "port" setting #1565 explores this direction.

If several drivers are started and may only realistically match e.g. VID:PID (same for several devices), currently one driver would get access and others would be denied with LIBUSB_ERROR_BUSY, at least if libusb returns the list of enumerated devices always in same order.

As discussed in #1744 this issue proposes to add an option to allow proceeding with device enumeration until all candidates from libusb have been looked at, instead of aborting at LIBUSB_ERROR_BUSY. Note that this inherently makes the device discovery non-deterministic - we have no practical way of saying which of the two identically looking devices is "A" and which is "B" - but in some cases we do not care (e.g. as long as one PSU of several is powered by whoever, we are satisfied).