Thank you for the response, Charles (and David). I'm not sure how, but I don't think I'd actually gotten productid into my ups.conf, even though it was in my notes. Putting that in along with the 62-nut-usbups.rules entry got the systemd service working successfully for me.
I also got nut-cgi working, and can see the voltage and frequencies are off as you described. That's OK for me for now; I don't think I want to try compiling and installing from source code at this time. I'll keep an eye out for that "data stale" error. Thanks again for the help, Charles. I wish you luck on getting the 302x product ID's added to the code base, David. ~ Paul Nickerson On Sun, May 9, 2021 at 12:48 PM Charles Lepple <[email protected]> wrote: > On May 8, 2021, at 11:46 PM, Paul Nickerson via Nut-upsuser wrote: > > > I'm running Raspbian GNU/Linux 10 (buster) on a Raspberry Pi 4. > I have nut-client and nut-server version 2.7.4-8 armhf installed from the > Raspbian Buster main apt repository. > I have a Tripp Lite AVR900U series AG-0309 connected via USB to the Pi. > The USB vendor ID is 09ae as expected, but the product ID is 3024. The > compatibility page at > https://networkupstools.org/ddl/Tripp_Lite/AVR900U.html says the product > ID is expected to be 2010. > > > I think we need some better background text on the DDL pages to explain > this, but the way to look at it is that the 2010 product ID is the last > "known good" version of the AVR900U model. I don't remember offhand when we > started to see the under-the-hood change to 30xx product IDs, but this was > discussed about a year ago: > > > https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-May/thread.html#11840 > > Towards the end was discussion of the "data stale" error, which is a > higher-level symptom of the driver (usbhid-ups, in your case) not being > able to stay connected to the UPS. (I have an UPS with product ID 3016 > which does the same thing on Linux with newer motherboards. It seems to be > a combination of hardware issues with a lack of error handling for this > particular fault in the Linux USB driver.) > > There's no manufacturing date printed on the UPS or box, but I bought it > from Amazon.com this week. > > > I thought we had more info on how to interpret serial numbers, but all I > can find is this: > > https://www.tripplite.com/support/identify-products > > so the first four digits are the "date code", which do seem to be pretty > close to the one mentioned in the May 2020 thread. > > I have these settings: > > /etc/nut/ups.conf > [tripplite] > driver = usbhid-ups > port = auto > desc = "Tripp Lite AVR900U" > vendorid = 09ae > productid = 3024 > > > ^ The last line tells upsdrvctl to add "-x productid = 3024" to the > command line, so you should be set with this config. > > To get usbhid-ups to try communicating with the UPS anyways, I added this > udev rule and then unplugged and plugged back in the USB cord: > > /lib/udev/rules.d/62-nut-usbups.rules > ATTR{idVendor}=="09ae", ATTR{idProduct}=="3024", MODE="664", GROUP="nut" > > > This udev rule is necessary until 3024 is added to NUT, yes. > > It looks like forcing usbhid-ups to communicate works, maybe? I'm not sure > what's expected here: > > > At this point, if you restart with "productid = 3024" in ups.conf, things > should work. > > 0.023703 Path: UPS.PowerSummary.Input.Voltage, Type: Feature, ReportID: > 0x31, Offset: 0, Size: 16, Value: 0.001254 > > > We have a couple of hacks in the driver to handle cases like this > (Input.Voltage is being reported with 100,000x too low): > > > https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite-hid.c#L59 > > It looks like one of these was merged for 3024 recently: > > https://github.com/networkupstools/nut/issues/962 > > You might also want to check other issues labeled Tripp Lite in GitHub: > https://github.com/networkupstools/nut/labels/Tripp%20Lite > > 0.043213 Path: UPS.PowerConverter.Input.Frequency, Type: Feature, > ReportID: 0x19, Offset: 0, Size: 16, Value: 6020 > > > Similar issue with frequency (x100) > > Should I run this without -x explore? Is there a way to get upsdrvctl to > send the option -x productid=3024 to usbhid-ups? Would that be a good idea? > > > Correct, "-x explore" is only useful when adding support for a new UPS. It > doesn't send anything to upsd. > > It sounds like you will need a newer build of NUT than 2.7.4 to get the > fix for Issue 962 mentioned above (which still doesn't address the "data > stale" issue). I don't have a lot of time to work on the NUT codebase these > days, though. Hopefully some other folks on the list can help out. We also > have some tips on rebuilding NUT on the GitHub wiki: > https://github.com/networkupstools/nut/wiki > > > ~ Paul Nickerson > _______________________________________________ > 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
