good afternoon. I'm not certain the mailing list got my response, so I'll try again.
I tested extensively with usbhid-ups, and NUT explicitly told me that I needed to be using tripplite_usb. the model of UPS is one of these three - I'm not yet sure which... OMNIVS800, OMNIVS1000 & OMNIVS1500XL On Wed, Sep 23, 2026 at 10:44 AM Jim Klimov <[email protected]> wrote: > Cheers, > > The `###NOTMATCHED-YET###bcdDevice = "000A"` part is basically what it > says on the tin: while some drivers (MGE/Eaton IIRC) might care about the > number for internal decisions, and we can see it in device identification, > no drivers have a configuration option to match it. > > Another aspect is `bus`/`device`/`busport` values - they are > enumeration-dependent, so cable re-plugs or device resets can change them - > and they would no longer match. In some cases this is the lesser evil, in > most you do not want to bolt them down in the configuration, so newer > nut-scanner releases also offer them commented-away. > > Just in case, did you try with other USB-capable drivers to check if > their protocols are supported by the device (primarily usbhid-ups)? > > Jim > > > On Wed, Sep 23, 2026 at 6:26 PM Jeff Hood via Nut-upsuser < > [email protected]> wrote: > >> Hello. >> Setting up a PC will be very difficult, as this is in the top of an >> elevator. I will try to get in to reset the UPS, but if a reset is a common >> problem, I will need to look at other options to monitor the health of this >> UPS. >> >> I'll crawl in the elevator later today to see if I can find model >> information. >> >> $ lsusb >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub >> Bus 001 Device 003: ID 09ae:0001 Tripp Lite TRIPP LITE UPS >> >> $ sudo nut-scanner -U >> Cannot load SNMP library (libnetsnmp.so.40) : file not found. SNMP search >> disabled. >> Cannot load XML library (libneon.so.27) : file not found. XML search >> disabled. >> Cannot load AVAHI library (libavahi-client.so.3) : file not found. AVAHI >> search disabled. >> Cannot load IPMI library (libfreeipmi.so.17) : file not found. IPMI >> search disabled. >> Scanning USB bus. >> [nutdev1] >> driver = "tripplite_usb" >> port = "auto" >> vendorid = "09AE" >> productid = "0001" >> product = "TRIPP LITE UPS" >> vendor = "Tripp Lite" >> bus = "001" >> device = "003" >> busport = "003" >> ###NOTMATCHED-YET###bcdDevice = "000A" >> >> >> On Tue, Sep 22, 2026 at 5:28 AM Charles Lepple <[email protected]> wrote: >> >>> On Sep 21, 2026, at 11:01 PM, Jeff Hood via Nut-upsuser < >>> [email protected]> wrote: >>> >>> Hi everyone, >>> >>> I'm running Network UPS Tools (NUT) version *2.8.1* on a Debian system >>> (aarch64), trying to connect an older Tripp Lite UPS via the >>> tripplite_usb driver. >>> >>> While nut-scanner -U successfully identifies the hardware, it flags the >>> device's firmware revision with a ###NOTMATCHED-YET### notice: >>> >>> I don't use nut-scanner, but I think it will do that for any USB device: >>> https://github.com/networkupstools/nut/blob/v2.8.1/tools/nut-scanner/scan_usb.c#L590 >>> >>> When the driver service attempts to start, it successfully claims the >>> USB endpoint but falls into an endless retry loop during the command >>> handshake: >>> libusb_get_interrupt() returned 0 instead of 8 while sending 3a 55 aa 0d >>> 00 00 00 00 '.U......' >>> >>> >>> I'd check several things: >>> >>> 1) Are there any other communication ports connected to the UPS? There >>> is the obvious serial port, but also check for a network card - under the >>> hood, most older Tripp-Lite UPSes seem to only have a single serial path to >>> the controller, so you can't use more than one port at a time (and the USB >>> port is just a USB-to-serial converter inside). >>> >>> 2) Does the problem go away if you reset the UPS? It probably needs a >>> hard power-down, where you remove line power for a minute or so. >>> >>> 3) Does this work on a PC? I realize that setting up a PC can be a bit >>> of a pain, but maybe a Live CD would be sufficient. I developed the >>> tripplite_usb code on an early 2000's x86 home PC, and when Tripp-Lite came >>> out with 3016 protocol devices, they were not reliable with higher-end >>> server chipsets that supported USB 2.0. (That problem even manifested >>> itself with non-NUT software like lsusb, but it was more evident in NUT >>> since lsusb runs briefly and exits.) I'm concerned that the aarch64 USB >>> support may be different yet. >>> >>> It would be interesting to know more about the specific Tripp-Lite model >>> in question. >>> >>> -- >>> Charles Lepple >>> clepple@gmail >>> >> _______________________________________________ >> Nut-upsuser mailing list >> [email protected] >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >> >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
