[Nut-upsdev] Constant "on battery" and "on line power" status changes

[Arjen de Korte]

[...]

> 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