[Nut-upsdev] 2.0.3-pre2: Spurious UPS UPS@localhost battery is

[Peter Selinger]

Gordon Rowell wrote:
> 
> Peter Selinger wrote:
> > [...]
> > Here is what I need:
> > 
> > 1) the output of "./newhidups -u root -DD -a UPS auto 2>&1 | grep
> > Path" again, but with the attached patch applied, and
> > 
> > 2) the output of "get_descriptor 005 003 1 0 0 128 0x22 0" (or
> > equivalent, substitute own bus and device number instead of 005/003), 
> > from the attached program. 
> 
> Attached, to avoid folding.
> [...]

Dear Gordon,

attached is a patch that might solve your problems, or it might at
least be progress towards a solution. I found:

1) voltage: the NUT conversion code for extracting values and
converting them to physical scales had many bugs (some of them marked
as "fixme" items). This included commands such as "Data->Value |=
~Data->PhyMax" (to sign-extend a value; makes no sense if Data->PhyMax
is e.g. 100). 

In your particular instance, the UPS is partially at fault: it
declares the voltage a 32-bit value, with legal range 0x0-0xffff in
units of 0.1V, but then apparently sends 0xffffffff80080a00 as the
voltage. It apparently expects the driver to truncate this value to
0x0a00, a behavior that is not exactly envisioned by the HID
specification. 

I basically rewrote the entire conversion subsystem; I hope it now
works correctly for all the expected cases and most unexpected ones.
However, there is a danger that these changes break something that
previously worked (I tested it successfully on an APC Back-UPS ES
650).

2) temperature: your device reported a temperature of 302.0. This is
actually correct; the device specifies the units as Kelvin (NUT
mistakenly assumed it was in Celsius). This corresponds to 29 Celsius,
or about 84 Fahrenheit. I have added a conversion that should convert
this to Celsius (as is standard for NUT). I had never seen a device
before that actually reported a temperature, so this may be why this
is the first time we noticed this.

3) date: I have extended the patch I made for Charlie to cover this
variable too. Why it gives a battery replacement date in 2001 is
beyond me. Seems strange for a device that was manufactured in 2005.
But given the data and our experience with APC, the date 599297
translated unambigously to 2001/09/25. 

Please try the attached patch, and let me know what's okay and what's
not.

Oh, the patch is against the latest Development version from CVS, by
the way.

Thanks, -- Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch1-diff
Type: application/octet-stream
Size: 18433 bytes
Desc: ascii text
Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20060209/01133e1c/patch1-diff-0001.obj