nut-scanner USB: disable some output results

[aquette]

Some additional fields, like 'device' (device number / path), may introduce more issues than solving. Hence disable these

[AppVeyorBot]

❌ Build nut 2.8.1.1246-master failed (commit f0cd2d5be4 by @aquette)

[jimklimov]

Cheers, just to be clear: the device_port is deemed problematic, but bus and bus_port are more physically oriented - so are not an issue?

For "bcd" - need to comment away the variable definition too, then (avoid unused variable). Or maybe add an option that the parser may/may-not use comments (or inject them in some other manner - also for alternative maybe suitable drivers, etc.). Or handle the bcd in driver args (even if ignoring in some cases) so it is just not an invalid string anymore.

[AppVeyorBot]

✅ Build nut 2.8.1.1248-master completed (commit 4029c402c2 by @jimklimov)

[desertwitch]

I might be barking up the wrong tree here, but would disabling some of those outputs (particularly physically-oriented ones regarding a device's location on the system such as device, bus or busport) not make it harder for a UPS driver to find that specific UPS device in more tricky environments? I'm talking systems where that particular UPS device is not easily or otherwise found "out of the box" with say driver usbhid-ups and port on auto?

I've had users who had their UPS not detected out of the box and exactly such a scenario was where nut-scanner came to the rescue by pointing the UPS driver exactly to the very location of that particular UPS via those physically-oriented outputs (even knowing where they fall short, such as making the UPS driver "blind" to just that particular device in that particular location)

Perhaps for sake of principle of least surprise an additional toggle could be implemented (something like --omit-physical-options) which would drop the specific physically-oriented outputs so that the configuration can become more flexible when considering reboots, changing device locations/IDs etc..? Entirely removing those outputs seems a bit extreme, although I agree they can be a bit of a mixed bag and do sometimes introduce more problems than they solve.

[jimklimov]

Seems this area needs a bit more of a holistic design than chopping stuff away :) So delaying until a later release (hoping to cut one soon to push existing bug fixes out).

• figure out passing "commented-away" entries (like bcdDevice) in a format-agnostic manner - this could be used for other entities like the device_port
• option to show or hide the USB physicalities, maybe with more levels about it (all three or certain ones?)

[aquette]

quite frankly, as long as the device reports its serial, it's good ;)

All the other means are just to be 400% sure we can keep up with cheaper units (reporting mfr 0000 or 0001 or such) in case there are multiple, and with all cases that may happen in the multiverse.
As for bcdDevice, I don't remember having seen this value moving in more than 2 decades...

Still, @desertwitch idea of a filter (more a minimal, with vendorid, productid and serial) is great!

For 2.8.2 Jim please. The current situation would cause regressions!

[jimklimov]

Ack on 2.8.2 - I hoped to issue one before NY to have a release out which includes some errata fixes over 2.8.1, but that window has sailed so might as well bundle a few more improvements like this one into the 2.8.2 when it appears.

[jimklimov]

Based on preceding discussions, I took a shot at updating this PR to allow enterprising users to still have the bus, busport and device values by passing several -U flags to nut-scanner, but to safely not have them by default.

Thought a bit about defaulting the flags based on amount of discovered devices and whether they have usable serial number values (all different, non-trivial, not repetitive characters like all-spaces or all-zeroes - logic for all that is present in nut-display.c sanity checker), or if all vendor/product IDs are different. E.g. if there are several detected devices and they seem similar, enable bus/busport/device(?) by default; for one device or several unique devices - keep these hidden.

Also extended libnutscan API to explicitly tag "suggested but not active" driver options, so they can be rendered as comments in some formats (ups.conf) and ignored in others (parsable; later maybe json/yaml/whatever).

@aquette : any ideas how to best register one text file source as the man page for several method names? There's gotta be a better way than to ship a renamed copy, right? :)

@aquette, @desertwitch : testing welcome, so far just developed in a VM to pass the build and spell-checker :)

[jimklimov]

Seems to work.

• For ups.conf formatted outputs, with comments where due:

root@pve:/usr/src/nut-pve# ./tools/nut-scanner/nut-scanner -U
Scanning USB bus.
[nutdev-usb1]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0463"
        productid = "FFFF"
        product = "Ellipse ECO"
        serial = "000000000"
        vendor = "EATON"
        # bus = "003"
        # device = "002"
        # busport = "002"

# WARNING: all-same character "serial" with 9 copies of '0' (0x30) reported in some devices: nutdev-serial1

root@pve:/usr/src/nut-pve# ./tools/nut-scanner/nut-scanner -UU
Scanning USB bus.
[nutdev-usb1]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0463"
        productid = "FFFF"
        product = "Ellipse ECO"
        serial = "000000000"
        vendor = "EATON"
        bus = "003"
        # device = "002"
        busport = "002"

# WARNING: all-same character "serial" with 9 copies of '0' (0x30) reported in some devices: nutdev-serial1

root@pve:/usr/src/nut-pve# ./tools/nut-scanner/nut-scanner -UUU
Scanning USB bus.
[nutdev-usb1]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0463"
        productid = "FFFF"
        product = "Ellipse ECO"
        serial = "000000000"
        vendor = "EATON"
        bus = "003"
        device = "002"
        busport = "002"

# WARNING: all-same character "serial" with 9 copies of '0' (0x30) reported in some devices: nutdev-serial1

root@pve:/usr/src/nut-pve# ./tools/nut-scanner/nut-scanner -UUUU
Scanning USB bus.
[nutdev-usb1]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0463"
        productid = "FFFF"
        product = "Ellipse ECO"
        serial = "000000000"
        vendor = "EATON"
        bus = "003"
        device = "002"
        busport = "002"
        ###NOTMATCHED-YET### bcdDevice = "0100"

# WARNING: all-same character "serial" with 9 copies of '0' (0x30) reported in some devices: nutdev-serial1

• And for parsable output (skipping comment-tagged entries):

root@pve:/usr/src/nut-pve# ./tools/nut-scanner/nut-scanner -UUUUP
Scanning USB bus.
USB:driver="usbhid-ups",port="auto",vendorid="0463",productid="FFFF",product="Ellipse ECO",serial="000000000",vendor="EATON",bus="003",device="002",busport="002"

root@pve:/usr/src/nut-pve# ./tools/nut-scanner/nut-scanner -UP
Scanning USB bus.
USB:driver="usbhid-ups",port="auto",vendorid="0463",productid="FFFF",product="Ellipse ECO",serial="000000000",vendor="EATON"

root@pve:/usr/src/nut-pve# ./tools/nut-scanner/nut-scanner -UPU
Scanning USB bus.
USB:driver="usbhid-ups",port="auto",vendorid="0463",productid="FFFF",product="Ellipse ECO",serial="000000000",vendor="EATON",bus="003",busport="002"

[desertwitch]

Seems to work in my testing too, also this is a beautiful solution to the problem - thanks to all. 💯

[aquette]

Privet @jimklimov, hi @desertwitch
Happy new year to all!
Thanks for completing the work Jim.

As for manpages aliasing, check malloc/calloc for ex, these use .Nm iirc to provide additional names (aliases).
Not sure for asciidoc then...

[jimklimov]

Uff, wrighting the wrongs of makefiles is oft more burdensome than dev'p'ment itself, if I may say so myself!

[jimklimov]

quite frankly, as long as the device reports its serial, it's good ;)

Ironically, Eaton's (Ellipse ECO at least) devices all report 000000000 so their serial value is useless to differentiate two connected UPSes ;)