[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol

[Peter Selinger]

Lance Thomas wrote:
> 
> I tried the newhidups with the command:
> newhidups -u root -DDDD -x vendorid=09ae -x productid=3012 auto 
> 
> and it goes through finds the ups and tells me that this particular
> Tripp Lite device (09ae/3012) is not supported.  And then to try the
> tripplite_usb.  

And then it asks you to report the results to the mailing list, which
you have hereby done :)

There are two things to do:

(1) try the --explore option that Charles was talking about. This will
    not make the driver work, but it will generate sufficient debugging
    info for us to make the driver work. Please use -DD and not -DDDD,
    as the latter generates too much useless information. Please post
    the output. 

(2) If you can upgrade from 2.0.5 to a current SVN version of NUT
    (compiled from sources), then the driver might work directly.

-- Peter

> I forgot to mention that when we got this tripplite we took the standard
> NEMA 5-20P input plug off and are using the NEMA 5-15P plug instead.  I
> don't think that would make a difference, but I thought I'd mention it
> just in case.
> 
> ----
> Lance sent me the output of "lsusb -vvv" for this device off-list, and
> here is the key portion of that:
> 
>         HID Device Descriptor:
>           bLength                 9
>           bDescriptorType        33
>           bcdHID               1.10
>           bCountryCode            0 Not supported
>           bNumDescriptors         1
>           bDescriptorType        34 Report
>           wDescriptorLength    1121
>           Report Descriptor: (length is 1121)
>             Item(Global): Usage Page, data= [ 0x84 ] 132
>                             Power Device Page
>             Item(Local ): Usage, data= [ 0x04 ] 4
>                             UPS
>             Item(Main  ): Collection, data= [ 0x01 ] 1
>                             Application
>             Item(Local ): Usage, data= [ 0x24 ] 36
>                             Power Summary
>             Item(Main  ): Collection, data= [ 0x00 ] 0
>                             Physical
>             Item(Global): Usage Page, data= [ 0x84 ] 132
>                             Power Device Page
> 
> As Kjell mentioned, this looks like another one of those cases where
> the innards of the UPS got an overhaul, but they kept the model name.
> 
> Lance: I forget, did you try the newhidups driver as well? That's the
> one that should eventually support this UPS (tripplite_usb only
> handles the older serial-protocol-over-USB models).
> 
> You may have to pass the manufacturer and model options to newhidups
> as well, since we were not aware of this alternate vendor/product ID
> for this model of UPS.
> 
> On 5/11/07, Lance Thomas <Lance.Thomas at fammed.wisc.edu> wrote:
> > I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12.
> > I originally tried the hidups driver which seemed to work, but
> produced
> > a large amount of unhandled events.  Then I tried the newhidups which
> > told me my ups wasn't supported.  When I try using
> >
> > tripplite_usb -u root -DDDD /proc/bus/usb/002/002
> >
> > I get that there isn't a match.  But when I try using
> >
> > tripplite_usb -DDDD -a tripplite1
> >
> > with the following ups.conf:
> > [tripplite1]
> >         driver = tripplite_usb
> >         port = /proc/bus/usb/002/002
> >         productid = 3012
> >         bus = 002
> >         desc = "top ups"
> >
> > I get it to run and find the HID, but it returns the following errors
> > before quitting:
> > Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U
> > send_cmd(msg_len=3, type='W')
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > send_cmd: send_try = 3, recv_try = 3
> >
> > Could not reset watchdog. Please send model information to nut-upsdev
> > mailing list
> > send_cmd(msg_len=2, type='
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > libusb_get_interrupt() returned 4 instead of 8
> > send_cmd: send_try = 3, recv_try = 3
> >
> > Error reading protocol
> >
> >
> > Any suggestions?
> > ____________________________________________________________________
> >
> > This email and any attachments may contain confidential information
> and is
> > solely for the intended recipient(s).  Email communications are not
> considered
> > secure.  If you are not the intended recipient(s) of this email you
> are expected
> > to disregard the content, delete the message and notify the original
> sender.
> >
> > --University of Wisconsin, Department of Family Medicine--
> > ____________________________________________________________________
> >
> > **UW DFM**
> >
> >
> > _______________________________________________
> > Nut-upsdev mailing list
> > Nut-upsdev at lists.alioth.debian.org
> > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
> >
> 
> 
> -- 
> - Charles Lepple
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
> 
> 
> 
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>