[Nut-upsuser] Liebert PSP

[Charles Lepple]

On Fri, Sep 17, 2010 at 7:10 AM, Will Cooke <will at whizzy.org> wrote:
> I've got a couple of LiebertPSP's connected to my equipment and I'd
> like to use NUT to keep an eye on them.  As things stands they
> piggyback on the Belkin USB HID drivers but this don't seem to support
> the "OB"/"OL" status which is rather important.
[...]
>   0.578005     Report[buf]: (2 bytes) => 07 0d
>   0.578016     Path: UPS.PowerSummary.PresentStatus.NeedReplacement,
> Type: Input, ReportID: 0x07, Offset: 7, Size: 1, Value: 0.000000
>
>
> I can tell you that the "07 0d" appears when the UPS is powered, and
> when the power is taken away this changes to 07 0a.  It is my current
> belief that the first bit indicates AC power, so I tried to write a
> conversion function for "AC Present" to act on this bit but the value
> that gets passed to the function always seems to be zero.

What would be interesting is to compare this with the corresponding
initialization message from the driver which says how the driver
interprets that bit. Can you post a log starting from when the driver
is launched, and ending once it starts printing messages like the ones
quoted above? (I'd suggest gzipping the log in case it gets big.)

The HID Report Descriptor (that the usbhid-ups driver reads at
startup) contains the mapping between the ReportID and its bitfields,
and the symbolic "Path" that the rest of the driver uses. In theory,
the UPS provides all the information needed to find out which bit
controls OL/OB, but in practice it seems that most manufacturers don't
do interoperability testing, and they just make sure their UPS works
with their software. If possible, we would like to find a general
correction, rather than hardcoding a specific bit to mean something.

Also, if you want to include the output of "diff -u" (or "svn diff")
from your changes, we can take a look at that. You're probably close,
but the HID parsing code is pretty complex.

-- 
- Charles Lepple