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

[Paul Nickerson via Nut-upsuser]

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  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@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
>

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

[David Zomaya via Nut-upsuser]

>> 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 can confirm we changed many of our old 20xx protocols to 302x.

I put in this request a while back:
https://alioth-lists.debian.net/pipermail/nut-upsdev/2020-June/007473.html
But I think I need to do a better job collaborating with those on the 
development side of the project.

Generally, productid=3024 in the ups.conf does the trick.



Thank you,
David Zomaya
Tripp Lite








From: Nut-upsuser 
 on 
behalf of Paul Nickerson via Nut-upsuser 
Sent: Saturday, May 8, 2021 10:46 PM
To: nut-upsu...@lists.alioth.debian.org
Subject: [EXTERNAL] [Nut-upsuser] Tripp Lite model number AVR900U didn't 
change, but USB product ID did

This is an EXTERNAL email. Please take a moment and think before clicking any 
links or opening any attachments from this email. If suspicious, please forward 
to ishelpd...@tripplite.com for review.
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.

There's no manufacturing date printed on the UPS or box, but I bought it from 
Amazon.com this week.


I have these settings:

/etc/nut/ups.conf
[tripplite]
driver = usbhid-ups
port = auto
desc = "Tripp Lite AVR900U"
vendorid = 09ae
productid = 3024

/etc/nut/nut.conf
MODE=standalone


Starting from the beginning, this fails:
systemctl restart nut-driver.service
I see that it tries to run:
/sbin/upsdrvctl start
This also fails. I added debug flags, and discovered that it's running this:
/lib/nut/usbhid-ups -a tripplite
Which also fails. I added debug flags to that, and got useful output, which 
I'll show you now.


root@raspberrypi4:~# /lib/nut/usbhid-ups -a tripplite -DD
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
   0.00 debug level is '6'
   0.000830 upsdrv_initups...
...
   0.002583 Checking device (09AE/3024) (001/004)
   0.002638 - VendorID: 09ae
   0.002660 - ProductID: 3024
   0.002679 - Manufacturer: unknown
   0.002700 - Product: unknown
   0.002724 - Serial Number: unknown
   0.002746 - Bus: 001
   0.002770 - Device release number: 0002
   0.002790 Trying to match device
   0.002814 This TrippLite device (09ae:3024) is not (or perhaps not yet) 
supported
by usbhid-ups. Please make sure you have an up-to-date version of NUT. If
this does not fix the problem, try running the driver with the
'-x productid=3024' option. Please report your results to the NUT user's
mailing list .

   0.002854 Device does not match - skipping
...
   0.003689 No appropriate HID device found
   0.003714 No matching HID UPS found


I'm not sure if USB info would be useful for you, but if it is, here it is:

root@raspberrypi4:~# lsusb --verbose
Bus 001 Device 004: ID 09ae:3024 Tripp Lite
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x09ae Tripp Lite
  idProduct  0x3024
  bcdDevice0.02
  iManufacturer   3 Tripp Lite
  iProduct1 AVR900U
  iSerial 5 3050BV4OM882300258
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0022
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.11
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 885
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval 255
can't get device qualifier: Resource temporarily unavailable
can't get 

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

[Charles Lepple via Nut-upsuser]

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@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

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

[Paul Nickerson via Nut-upsuser]

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.
There's no manufacturing date printed on the UPS or box, but I bought it
from Amazon.com this week.


I have these settings:

/etc/nut/ups.conf
[tripplite]
driver = usbhid-ups
port = auto
desc = "Tripp Lite AVR900U"
vendorid = 09ae
productid = 3024

/etc/nut/nut.conf
MODE=standalone


Starting from the beginning, this fails:
systemctl restart nut-driver.service
I see that it tries to run:
/sbin/upsdrvctl start
This also fails. I added debug flags, and discovered that it's running this:
/lib/nut/usbhid-ups -a tripplite
Which also fails. I added debug flags to that, and got useful output, which
I'll show you now.


root@raspberrypi4:~# /lib/nut/usbhid-ups -a tripplite -DD
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
   0.00 debug level is '6'
   0.000830 upsdrv_initups...
...
   0.002583 Checking device (09AE/3024) (001/004)
   0.002638 - VendorID: 09ae
   0.002660 - ProductID: 3024
   0.002679 - Manufacturer: unknown
   0.002700 - Product: unknown
   0.002724 - Serial Number: unknown
   0.002746 - Bus: 001
   0.002770 - Device release number: 0002
   0.002790 Trying to match device
   0.002814 This TrippLite device (09ae:3024) is not (or perhaps not yet)
supported
by usbhid-ups. Please make sure you have an up-to-date version of NUT. If
this does not fix the problem, try running the driver with the
'-x productid=3024' option. Please report your results to the NUT user's
mailing list .

   0.002854 Device does not match - skipping
...
   0.003689 No appropriate HID device found
   0.003714 No matching HID UPS found


I'm not sure if USB info would be useful for you, but if it is, here it is:

root@raspberrypi4:~# lsusb --verbose
Bus 001 Device 004: ID 09ae:3024 Tripp Lite
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x09ae Tripp Lite
  idProduct  0x3024
  bcdDevice0.02
  iManufacturer   3 Tripp Lite
  iProduct1 AVR900U
  iSerial 5 3050BV4OM882300258
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0022
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.11
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 885
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval 255
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0002
  (Bus Powered)
  Remote Wakeup Enabled


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"


It looks like forcing usbhid-ups to communicate works, maybe? I'm not sure
what's expected here:

root@raspberrypi4:~# /lib/nut/usbhid-ups -a tripplite -DD -x productid=3024
-x explore
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
   0.00 debug level is '2'
   0.002081 upsdrv_initups...
...
   0.005719 Checking device (09AE/3024) (001/009)
   0.011434 - VendorID: 09ae
   0.011499 - ProductID: 3024
   0.011541 - Manufacturer: Tripp Lite
   0.011587 -