Nut upsdev - Sep 2023 - Heads-up: now it will be possible to manually select `subdriver` in `usbhid-ups`, and... looking at a release!

Hi,
> Since NUT is guessing, is there a way to make it list likely drivers back
to the user when they are a close match and check validity for each one
until it gets a good connection?  Part of auto select?

What NUT currently does in `usbhid-ups` (some other drivers may handle
similar stuff differently), is it goes through a list of subdrivers built
into the binary and calls those subdrivers' `claim()` methods to see if
they report the device is deemed known to that subdriver. Primarily this
goes by USB VendorID:ProductID matching, in some cases also clues like
manufacturer string (e.g. "mge" and "phoenixtec/liebert"
have different
sets of data points, but the devices for them have the same basic
identifiers). It does have shades (not supported, possibly supported, and
assumed supported) but mostly the iteration goes until a certain match or
bails out if nobody claimed the device. These details can be seen in the
driver's debug log if verbosity is tuned up.
> ...Or present the user with close match options for user selection
through some client UI?

NUT as such does not really have much in the way of UIs currently,
especially not for initial configuration (PRs welcome). There are some
interactive text-mode tools however, as well as debug logs from drivers
that you can set loose on your device (sometimes at your own risk, see
below).

There is a `nut-scanner` tool which follows a similar algorithm to propose
an `ups.conf` section text that users can copy-paste into their `ups.conf`
file. It currently has relatively static information sources about drivers
that may be detectable with SNMP, NetXML, other NUT servers via native
protocol or exposed by Avahi/mDNS, some USB and Serial based protocols...
Structurally it is extendable for more protocols, connection media and
third-party libraries involved (we have also Modbus, GPIO, i2c, IPMI, etc.
to think about)... with a caveat that some dumber devices may go crazy or
even bricked when random data comes into their serial or usb ports (an
unsupported protocol is being evaluated). At least the warnings say so...

There was also a configuration CLI tool in a fork, but it was not yet
imported into NUT upstream, and I haven't used it so far. Hoped to get to
it after a release or two...

There is also a logged issue, to remember to think about some "lock-picking
mode" eventually. But so far there are no really good ideas around this.
> Maybe it could also be queried for a list of all know drivers to augment
the list?

As for the listing, thanks for the reminder: I realized I wanted to add it
to driver usage text (like there is for `nutdrv_qx --help`) or handle a
special value for the report like with `snmp-ups ... -x mibs=--list`, but
forgot to follow up with either :)

Generally a "list of known drivers" is unlikely, since anyone can
write and
bundle their own program that talks to a device on one side, and to `upsd`
via local socket protocol on another, without NUT really knowing about it
if it's not currently running and talking. Subdrivers of standard drivers
are another matter, and mostly handled by now, I think (some with this PR
discussed here).

Jim


On Mon, Sep 18, 2023 at 6:27?PM Keven L. Ates <atescomp at gmail.com>
wrote:
> I've been out of NUT dev for some time, so apologies if this has
already
> been covered.  The responses seem to indicate not.
>
> Since NUT is guessing, is there a way to make it list likely drivers back
> to the user when they are a close match and check validity for each one
> until it gets a good connection?  Part of auto select?
>
> Or present the user with close match options for user selection through
> some client UI?
>
> It could send back the driver list and a valid connection flag.  For a
> single driver (only one match) in the list, the flag would indicate a good
> connection or not.  If not, the it's just what it "thinks"
was a match.  On
> more that one driver (class of subdrivers), the flag would indicate what it
> thinks is a good connection (first in list? Or index) with a list of
> alternatives.  On not, then a list of possible matches (or all or none?).
>
> Maybe it could also be queried for a list of all know drivers to augment
> the list?
>
> So, response is { flag: bool, index: int | none, list: string | [ string,
> ... ] }
> Or some such.
>
> On Sun, Sep 17, 2023, 6:36 PM Jim Klimov via Nut-upsdev <
> nut-upsdev at alioth-lists.debian.net> wrote:
>
>> Hello all,
>>
>>   Over the past years there have been several cases where I wished we
>> could specify an USB HID subdriver as easily as a subdriver/protocol
combo
>> in nutdrv_qx or blazer drivers, or a MIB in snmp-ups driver. But never
got
>> around to implementing that (nor convinced somebody else to do it).
>>
>>   Finally, with https://github.com/networkupstools/nut/pull/2058
>> (currently in CI testing), this ability should appear. In particular,
it
>> can help with a sore point of "phoenixtec/liebert" and
"mge" mappings which
>> respond to the same VID:PID identification and try to guess if some
other
>> clues about the device fit the particular subdriver. Some reported
>> regressions of NUT v2.8.0 vs. v2.7.4 were about changes to this
guesswork.
>>
>>   On a grander scale, I think this is among the last large
>> NUT-development blockers I had burdening my conscience before
unleashing a
>> new release (lack of which, in turn, makes many people sad about not
>> receiving long-completed bug fixes). Quite a few others were merged
during
>> recent weeks, and hopefully packages based on current code would be
easier
>> for end-users to deploy and for us as a community to remotely debug,
than
>> with earlier releases.
>>
>>   I think I'll wait a while for currently active PRs to complete,
if they
>> would do so soon, but it seems prudent to ask the greater NUT user and
>> developer community to test custom builds of master branch with their
>> devices and use-cases, to help ensure no new bugs get delivered this
time ;)
>>
>>   Take a look at NEWS.adoc for the whole feature change set since the
>> previous release, and UPGRADING.adoc for highlights of the changes that
are
>> expected to impact existing deployments and/or packaging recipes.
>>
>>   On my side, I still have plans for some documentation changes,
>> including the tracking of HCL/DDL reports which are not yet formally
>> logged, but this is a chore that may spill over into the next release
and
>> should not be a blocker. Help is welcome, though - example chores
>> summarized at https://github.com/networkupstools/nut-ddl/pull/38 and
>> https://github.com/networkupstools/nut/pull/2059 going from
>> https://github.com/orgs/networkupstools/projects/3/views/1 ;)
>>
>> Jim
>>
>> _______________________________________________
>> Nut-upsdev mailing list
>> Nut-upsdev at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230918/68623440/attachment.htm>