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

[Arjen de Korte]

>>  Can you post a full listing of the driver running in debug level 2?
> I think that's here... should I do something different than what was
> in the 2nd attachment in the message below?

Ooops. I forgot that you already did. Never mind. From the HID paths that
indicate a voltage, only the following two are candidates for the battery
voltage:

> Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x27,
Offset: 0, Size: 16, Value: 120.000000
> Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x2b, Offset:
16, Size: 16, Value: 119.000000

The other four are clearly *not* indicating a battery voltage:

> Path: UPS.Flow.[1].ConfigVoltage, Type: Feature, ReportID: 0x13, Offset:
16, Size: 16, Value: 120.000000
> Path: UPS.Flow.[4].ConfigVoltage, Type: Feature, ReportID: 0x15, Offset:
0, Size: 16, Value: 120.000000
> Path: UPS.PowerConverter.Input.[1].Voltage, Type: Feature, ReportID:
0x19, Offset: 24, Size: 16, Value: 0.000000
> Path: UPS.PowerConverter.Output.Voltage, Type: Feature, ReportID: 0x1c,
Offset: 48, Size: 16, Value: 120.000000

The first two (Flow.[1] and Flow.[4]) are the input- and output
respectively and the last two specifically mention that they are
*.Input.Voltage and *.Output.Voltage. Since we also know that the UPS was
without input power at the time you ran this report, there is no
ambiguity. These are not the battery voltage.

This leaves the two possibilities for "UPS.PowerSummary.ConfigVoltage" and
"UPS.PowerSummary.Voltage":

1) They have indeed nothing to do with the battery on your UPS, which
means that yours probably has no means of indicating the battery voltage.
In this case, we should override these values (in a similar way as we
already do for the Evolution 650) or mask them out completely.

2) They actually *do* report the (nominal) battery voltage, just the
multiplier is off by a factor of 10. In that case, we need a conversion
function that modifies these values.

For reasons I already mentioned in an earlier post, changing the meaning
of these HID paths (as Arnaud suggested) is not an option, we'll have to
deal with this on a model specific basis.

Best regards, Arjen