[Nut-upsuser] Tripp Lite model number AVR900U didn't change, but USB product ID did

Mon May 10 03:19:09 BST 2021

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 <clepple at gmail.com> 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
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20210509/70a8380f/attachment.htm>