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

[Charles Lepple]

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 <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 <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 <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 <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 <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 <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 <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/5dbd0b71/attachment.htm>