Nut upsdev - Dec 2007 - Constant "on battery" and "on line power" status changes

Good afternoon all,

I have a Tripp-Lite SmartOnline SU1500RTXL2ua UPS that I had previously tried 
to get up and running with NUT earlier this year. Peter Selinger had been 
working with this, but he had to devote time to more important things, and I 
did too, so it got pushed to the back burner. I saw in the release 
announcement of 2.2 that the UPS is now supported and decided I would try 
once again. Unfortunately, I think there are still problems trying to support 
this UPS, at least via USB.

I believe I have everything set up and (apparently) communicating correctly, 
but the UPS status constantly flips from "on battery" to "on line
power", and
upsmon reports a steady stream of these messages. I can also see the changes 
in the ups.status reported by upsc. I did some reading on the lists, and the 
only thing I found that sounded like it might help was adding "pollfreq =
5"
and "pollinterval = 10" to the ups.conf file. However, this just seems
to
have decreased the frequency of the alerts.

I am fairly sure neither the UPS nor the input power are at fault. For one 
thing, when the status shows as OB, the UPS input values are exactly the same 
as when the status shows OL. In addition, switching from USB to serial 
eliminates all instances of OB status, unless the power is switched off. 
Finally, putting a different hard drive into the PC and running Tripp-Lite's
PowerAlert SW on Server 2003 shows no problems over the USB interface (not 
sure if this is relevant or not).

I have attached three NUT debugging ouputs. The first two are via the USB 
interface using usbhid-ups, and the third is from the serial interface using 
tripplitesu. The difference between the first and the second is that the 
second one was taken after adding "pollfreq = 5" and
"pollinterval = 10" to
the ups.conf file. The three commands used to generate the output were:
/usr/local/ups/bin/usbhid-ups -DDD -a su1500
/usr/local/ups/bin/usbhid-ups -DDD -a su1500 [with poll settings added]
/usr/local/ups/bin/tripplitesu -DDD -a su1500 [on /dev/ttyS0]

Additional info:
System is a Debian test system that was just put together three days ago (27 
Dec, 2007). Kernel is 2.6.18-5-686.
NUT is the latest stable download, 2.2.1, downloaded yesterday morning (29 
Dec, 2007).
The upscmd instant commands seem to function correctly on the serial interface 
(a word of advice - if you ssh into the NUT server, make sure your switch is 
not plugged into the UPS when you do the load off test!)
The debugging outputs contain the ups.conf settings used at that time.

Obviously I will be happy to provide any further information to help resolve 
this problem. Just tell me what you need. I can go serial, but I really want 
to go USB if possible.

Thanks,
Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serial_output1.gz
Type: application/x-gzip
Size: 596 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20071230/6734023c/attachment-0003.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usb_output1.gz
Type: application/x-gzip
Size: 5213 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20071230/6734023c/attachment-0004.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usb_output2.gz
Type: application/x-gzip
Size: 4350 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20071230/6734023c/attachment-0005.bin

[...]
> I believe I have everything set up and (apparently) communicating
> correctly,
> but the UPS status constantly flips from "on battery" to "on
line power",
> and
> upsmon reports a steady stream of these messages. I can also see the
> changes
> in the ups.status reported by upsc. I did some reading on the lists, and
> the
> only thing I found that sounded like it might help was adding
"pollfreq > 5"
> and "pollinterval = 10" to the ups.conf file. However, this just
seems to
> have decreased the frequency of the alerts.
>
> I am fairly sure neither the UPS nor the input power are at fault.
Unfortunately, the UPS *is* at fault. It is the same problem as we've seen
in Belkin UPS'es before and which was fixed in the 'belkin-hid'
subdriver
and which probably must be solved in a different way for the
'tripplite-hid' subdriver.

The debug output you provided conclusively tells this is a problem in the
UPS. It is reporting two different values for report 32h, the one that
contains the status bit that tells (amongst other info) whether or not AC
is present. Unfortunately, it tells two different stories, depending on
how we receive this report:

    Report[get]: (4 bytes) => 32 00 00 09
    Report[int]: (4 bytes) => 32 64 00 00

The first [get] is the one we receive when we explicitly ask the UPS for
report 32h and this is the one that yields correct information. The second
[int] is the one that is sent by the UPS over the interrupt pipeline (and
that will be initiated by the UPS). Apparently, the UPS messes this up
badly internally. Most likely with report 34h that is sent just before
that one:

    Report[int]: (2 bytes) => 34 64

This violates the USB HID specification, these reports should be the same.
The reason that this isn't a problem for the USB driver provided by
Tripplite is most likely that they ignore the reports received over the
interrupt pipeline, so they will only use the polling mechanism (and those
reports aren't broken).

The good news is, that we can definitly work around this problem. The bad
news is, that I'll have to modify the driver for that, there is no quick
workaround for that (we can't tell the UPS to not sent interrupt reports).
I'll let you know when I've had the time to fix this, probably somewhere
by the end of this week.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57