Problem
Zaparoo Core needs to track serial paths that were probed but did not detect as PN532 devices, so it can skip repeat probes until the device file changes.
Today detection.DetectAll(ctx, opts) returns only detected DeviceInfo values. It does not expose the full set of candidate paths each detector tried. Core therefore has to call its own serial enumeration after DetectAll just to infer failed candidates.
Request
Expose candidate/tried paths from detection, either by:
- adding optional metadata/result type that includes tried candidate paths, or
- adding a helper/API for detector candidate enumeration, or
- adding a callback/hook in
detection.Options invoked when a candidate path is attempted.
Motivation
This would let callers avoid redundant enumeration and keep failed-probe tracking aligned with go-pn532 detector behavior.
Current workaround
Zaparoo Core calls DetectAll, then calls its own serial enumeration and compares detected paths to all serial paths. That works, but duplicates detector logic and can drift if detector candidate selection changes.
Problem
Zaparoo Core needs to track serial paths that were probed but did not detect as PN532 devices, so it can skip repeat probes until the device file changes.
Today
detection.DetectAll(ctx, opts)returns only detectedDeviceInfovalues. It does not expose the full set of candidate paths each detector tried. Core therefore has to call its own serial enumeration afterDetectAlljust to infer failed candidates.Request
Expose candidate/tried paths from detection, either by:
detection.Optionsinvoked when a candidate path is attempted.Motivation
This would let callers avoid redundant enumeration and keep failed-probe tracking aligned with go-pn532 detector behavior.
Current workaround
Zaparoo Core calls
DetectAll, then calls its own serial enumeration and compares detected paths to all serial paths. That works, but duplicates detector logic and can drift if detector candidate selection changes.