<div dir="ltr"><div>Hi,<br></div><div><br></div><div>>
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?
</div><div><br></div><div>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.</div><div><br></div><div>> ...Or present the user with close match options for user selection through some client UI?<div dir="auto"></div>
</div><div><br></div><div>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).<br></div><div><br></div><div>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...<br></div><div><br></div><div>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...<br></div><div><br></div><div>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.<br></div><div><br></div><div>> Maybe it could also be queried for a list of all know drivers to augment the list?
</div><div><br></div><div>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 :)</div><div><br></div><div>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).<br></div><div><br></div><div>Jim</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 18, 2023 at 6:27 PM Keven L. Ates <<a href="mailto:atescomp@gmail.com">atescomp@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">I've been out of NUT dev for some time, so apologies if this has already been covered. The responses seem to indicate not.</div><div dir="auto"><br></div>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?<div dir="auto"><br></div><div dir="auto">Or present the user with close match options for user selection through some client UI?</div><div dir="auto"><br></div><div dir="auto">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?).</div><div dir="auto"><br></div><div dir="auto">Maybe it could also be queried for a list of all know drivers to augment the list?</div><div dir="auto"><br></div><div dir="auto">So, response is { flag: bool, index: int | none, list: string | [ string, ... ] }</div><div dir="auto">Or some such.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 17, 2023, 6:36 PM Jim Klimov via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" target="_blank">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello all,<br><br></div><div> 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).</div><div><br></div><div> Finally, with <a href="https://github.com/networkupstools/nut/pull/2058" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/2058</a> (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.</div><div><br></div><div> 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.</div><div><br></div><div> 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 ;)</div><div><br></div><div> 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.</div><div><br></div><div> 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 <a href="https://github.com/networkupstools/nut-ddl/pull/38" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut-ddl/pull/38</a> and <a href="https://github.com/networkupstools/nut/pull/2059" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/2059</a> going from <a href="https://github.com/orgs/networkupstools/projects/3/views/1" rel="noreferrer" target="_blank">https://github.com/orgs/networkupstools/projects/3/views/1</a> ;)<br></div><div><br></div><div>Jim</div><div><br></div></div>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" rel="noreferrer" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>
</blockquote></div>