[Nut-upsuser] TrippLite SmartPro UPS and nut-2.0.2

[Charles Lepple]

On 5/10/06, Nick Golder <nrg at timing.com> wrote:
> On 2006-05-09 17:00 -0400, Charles Lepple wrote:
> > >Detected a UPS: TRIPP LITE/  TRIPP LITE SMART3000RM2U
> >
> > This looks good.
>
> If I try to kill (ctrl+c) the above command I get the following:
> ^CUSB error: error reading from interrupt endpoint /dev/ugen0.1: Interrupted system call
> libusb_get_interrupt() returned -4 instead of 8
> Unknown battery voltage: 0x3038
> Unknown protocol (4)Attached to Tripp Lite TRIPP LITE SMART3000RM2U
> ^CUSB error: error reading from interrupt endpoint /dev/ugen0.1: Interrupted system call
> libusb_get_interrupt() returned -4 instead of 8
> Unknown value for s[2]: 0x34
> dstate_init: sock /var/db/nut/tripplite_usb-auto open on fd 6
> Signal 2: exiting
> Closing device
> usb_os_close: closing endpoint 5

You may have to increase the debug level (I think I used '-DDDDD' when
debugging that driver). I don't think I ever saw s[2] = 0x34; I think
it has something to do with the battery test status, and the batteries
on the 1500RM2U were toast.

Also, if you have a driver running as root, you can usually start
upsd, then run 'upsc name-of-ups at localhost' to list the variables that
the driver supports. It is less secure, however.

> > >No matching USB/HID UPS found
> > >Driver failed to start (exit status=1)
> >
> > You may have to check permissions on /dev/ugen0.
>
> # sudo usbdevs -d | grep -A 2 -B 1 uhub1
> addr 1: UHCI root hub, Intel
>   uhub1
>  addr 2: TRIPP LITE SMART3000RM2U, TRIPP LITE
>    ugen0
>
> # ls -lah /dev/ugen0
> crw-rw----  1 root  operator    0,  78 May 10 08:46 /dev/ugen0
>
> # ls -lah /dev/usb1
> crw-rw----  1 root  operator    0,  34 May 10 08:46 /dev/usb1
>
> What would be the proper way to attach the driver to a device in
> ups.conf under FreeBSD?

I will defer to the FreeBSD experts on this one, but I imagine that
NUT needs read permission on /dev/usb1 to find the UPS at /dev/ugen0
(where it would probably need read/write). You can probably get some
useful system call error information from strace/ktrace, too.

--
- Charles Lepple