Hi Patrick, in February, you tried to post the below message to the nut-upsuser list, but the post was rejected because you were not subscribed to the list. Unfortunately, you did not subscribe and re-post it. Anyway, I have been working on Tripp-Lite support for newhidups recently, and I wonder if you have any feedback. Did you ever get this device to work?>From the information you sent, it looks like it quite might be aproper HID power class device (not serial-over-usb). If you could run (as root) newhidups -u root -DD -x generic -x vendorid=09ae auto we might be able to confirm whether this is the case. In case the above test succeeds, I might be able to add explicit support for this device to newhidups. It's the only device with device ID 09ae:1003 that I have seen so far. Thanks, -- Peter Forwarded message:> Date: Wed, 08 Feb 2006 15:01:43 -0800 > From: Patrick Nolan <Patrick.Nolan@stanford.edu> > To: nut-upsuser@lists.alioth.debian.org > CC: patrick.nolan@stanford.edu > Subject: Tripp-Lite AVR550U > > I have a Tripp-Lite AVR550U, which is USB only. I wonder if it will > be possible to use this with newhidups. As I have been learning from > the archives of this mailing list, there are different protocols for > different models. When I run newhidups -DDDDD(version 2.0.3) it says, > > Checking device (09AE/1003) (002/003) > - VendorID: 09ae > - ProductID: 1003 > - Manufacturer: unknown > - Product: unknown > - Serial Number: unknown > - Bus: 002 > Trying to match device > Device does not match - skipping > > Trying to find a protocol number, I ran lsusb. The output is below. > There doesn't seem to be a useful protocol number there. > > Bus 002 Device 003: ID 09ae:1003 Tripp Lite > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x09ae Tripp Lite > idProduct 0x1003 > bcdDevice 0.10 > iManufacturer 3 Tripp Lite > iProduct 1 TRIPP LITE UPS > iSerial 2 692186 A > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 34 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xa0 > Remote Wakeup > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 3 Human Interface Devices > bInterfaceSubClass 0 No Subclass > bInterfaceProtocol 0 None > iInterface 0 > HID Device Descriptor: > bLength 9 > bDescriptorType 33 > bcdHID 1.10 > bCountryCode 0 Not supported > bNumDescriptors 1 > bDescriptorType 34 Report > wDescriptorLength 459 > cannot get report descriptor > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type none > Usage Type Data > wMaxPacketSize 0x0008 bytes 8 once > bInterval 40 > Language IDs: (length=4) > 0409 English(US)
Patrick Nolan wrote:> > Peter Selinger wrote: > > Hi Patrick, > > > > in February, you tried to post the below message to the nut-upsuser > > list, but the post was rejected because you were not subscribed to the > > list. Unfortunately, you did not subscribe and re-post it. > > > > Anyway, I have been working on Tripp-Lite support for newhidups > > recently, and I wonder if you have any feedback. Did you ever get this > > device to work? > > It works ok under the old hidups driver. > The only annoyance is that when the machine is rebooted, the ownership > of /dev/hiddev1 reverts to root. I never got around to making an > automatic process to make sure which device it gets attached to > (although it always seems to be hiddev1). I could do that and put > it into the startup script, but so far I have been checking and > changing the ownership by hand.Right. This is perhaps a matter of setting up the correct hotplugging scripts, but I am not sure how to do it for the /dev/hiddev interface. In any case, the old hidups driver will be discontinued soon, and is not actively supported any more.> >>From the information you sent, it looks like it quite might be a > > proper HID power class device (not serial-over-usb). If you could run > > (as root) > > > > newhidups -u root -DD -x generic -x vendorid=09ae auto > > > My version of newhidups doesn't accept the -x generic argument.Drats, you're right. I though this feature was in 2.0.3, but actually it was introduced afterwards. If you get the current development sources from SVN, you would be able to run this. In any case, you would need the newest version for Tripp Lite support.> newhidups -u root -DD -x vendorid=09ae auto gives > > Checking device (09AE/1003) (002/003) > - VendorID: 09ae > - ProductID: 1003 > - Manufacturer: Tripp Lite > - Product: TRIPP LITE UPS > - Serial Number: 692186 A > - Bus: 002 > Trying to match device > Device does not match - skipping > > I don't know if this will help you.Not very much, unfortunately. In case you feel like experimenting with this, I am attaching a patch that *might* enable this device to be supported by the newhidups driver, when applied to the current development version from the SVN repository. Some fine-tuning will probably be required, for which the output of "newhidups -u root -DD -x generic -x vendorid=09ae auto" would still be useful. -- Peter
Peter Selinger wrote:> > In case you feel like experimenting with this, I am attaching a patchOops, here is the patch: Index: drivers/tripplite-hid.c ==================================================================--- drivers/tripplite-hid.c (revision 426) +++ drivers/tripplite-hid.c (working copy) @@ -202,6 +202,9 @@ if (hd->ProductID == TRIPPLITE_HID_PRODUCTID) { return 1; } + if (hd->ProductID == 0x1003) { + return 1; + } upsdebugx(1, "This particular Tripp Lite device (%04x/%04x) is not (or perhaps not\n"