Jim Klimov

Just to be sure, this is orthogonal to rapid data stale-unstale sequences reported a few weeks ago (as #651 OTOH)?

Looking at this PR open for so long (and with useful discussion above), I think this particular change will not be merged due to reasons articulated above, but a similar...

Follow-up solution growing at #2847 and while it also modifies the behavior of `upscli_connect()`, it does so optionally (is blocking by default, unless the NUT client program code or certain...

Goal achieved via PR #2847

This is quite possible, also note that depending on Eaton model, several vendor-extended MIB mappings can apply to the same device and support sometimes not-overlapping data sets and/or represent same...

As noted before, currently the different drivers and even subdrivers (e.g. MIB mapping tables, several can apply to Eaton devices) are independent in the readings they provide. So depending on...

Please retry with higher debug verbosity, e.g.: ``` :; sudo nut-scanner -DDDDDD -C > /tmp/nutscan.log 2>&1 ``` There would be a huge wall of text about directories it looks into...

Also, just in case: how did you install NUT (packages? custom build?) and which version?

Yes, I wonder why one was not created in the first place (maybe devel packages deliver such a link, or some distro conventions had changed?) :\ At least, not directly...

Hm, yeah, the name without trailing numbers seems to come from development packages: ```` :; grep libusb-1.0.so /var/lib/dpkg/info/*.list /var/lib/dpkg/info/libusb-1.0-0-dev:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so /var/lib/dpkg/info/libusb-1.0-0:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0 /var/lib/dpkg/info/libusb-1.0-0:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0 ```` Wondering how nobody stumbled on that before. Did...