[Nut-upsdev] usbhid-ups using wrong value for battery voltage for Pulsar Evolution 500?

[Arjen de Korte]

Charles Lepple wrote:

> I suspect that the battery is failing on my Pulsar Evolution 500 (it
> is several years old now) but I can't seem to get a valid battery
> voltage from the UPS.

What is the actual battery voltage you would expect? Something like 12 V?

> The following tests were done using NUT 2.2.1, but I first noticed
> this with the trunk, and reproduced it with the current
> branches/Testing as well.
> 
> The only two values I have seen for battery.voltage are 120.0 and 119.0, e.g.:
> 
> $ upsc evo | grep battery      # full upsc output attached.
> battery.voltage: 120.0
> battery.voltage.nominal: 120

I can't say that I'm really surprised here. My 'Evolution 650' will
report battery voltage (nominal 12 V) in 1 V increments. So the only
practical reported values are probably 12 and 13 V here. I was rather
shocked to find that it has such a lousy resolution.

> At first I wondered if there was a unit conversion error, but then I
> pulled the plug, and noticed that the voltage did not go down (even
> when the UPS shut off due to an apparently low battery - the charge
> was much higher than it should have been, and there was no OB+LB
> status, but that's another issue).

[...]

> Could this be related to the "Evolution 650" bug mentioned in
> mge-hid.c? (On the other hand, I suspect that if I added my model to
> that function, it would only fix the battery.voltage.nominal)

It might need a /10 conversion for *both* values here, or it is
reporting something completely different. Maybe Arnaud can tell?

I also noticed in the debug output you showed, that the device is reporting

Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature, ReportID:
0x29, Offset: 0, Size: 24, Value: -10.000000

The value '-10' looks odd here. I would not expect this to go lower than
'-1'. Maybe this has to do something with the "Set startup delay, in ten
seconds units for MGE". According to the HID PDC specification, the
values that are changed here are in one second units, so we may need
some conversion here too.

Best regards, Arjen