[Nut-upsdev] CyberPower CP825AVR-G battery scale

[Charles Lepple]

On Dec 28, 2011, at 9:16 AM, Ariel wrote:

> On Wed, 28 Dec 2011, Charles Lepple wrote:
> 
>> On Dec 28, 2011, at 3:48 AM, Ariel wrote:
[...]
>>>  0.022302     Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x09, Offset: 0, Size: 8, Value: 24.000000
>>>  0.022332     Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x0a, Offset: 0, Size: 8, Value: 24.000000
> 
>> Is it possible that UPS.PowerSummary.Voltage is really an output voltage divided by 10? (This has happened on other devices.)
> 
> Well, I have two 12 volt batteries, so 24 volts makes sense, 240 doesn't.

I meant AC output voltage, not DC. There are many interpretations of the HID PDC spec in various UPSes, and most of them are incorrect (or at least, not self-consistent).

>> What might be useful (and this applies to your other feature requests as well) is to verify that the values change as expected during a deep discharge cycle.
> 
> Yes, I intend to do that, once I get everything installed fully so I can test everything end to end. (Although I won't be able to test the buck/boost till the summer when my voltage drops a lot.)

The code will definitely need to be tested. Let us know when you're ready to do that.

>> I have a feeling that we may need to develop a more generic scaling capability in some of these drivers. On the other hand, we probably should make it obvious that certain values are being modified before being reported.
> 
> I agree - I think the scaling should be configured in ups.conf, and be general for any field. To make it very easy support +-*/ without precedence - operations are done strictly left to right. Perhaps 3 fields: operation, min, max (min/max are applied after scaling, not before).

We will need to think about this a bit more to bound the scaling/offset problem. Min and max have traditionally either been reported directly from the UPS (the onboard microcontroller often tracks this), or have been handled by higher-level reporting tools such as RRD (which might miss short transients).

Logged in Alioth's feature request tracker:
https://alioth.debian.org/tracker/?func=browse&group_id=30602&atid=411545

>> Also, what version of NUT are you using? I seem to remember that we fixed the debug output so that it didn't always print values in fixed-point notation.
> 
> I'm using 2.4.3 (debian stable - you'll be getting a lot of reports for that version for the next year or two). I was thinking of installing 2.6.2 if it had any features I needed.

Fortunately, the interface between drivers and upsd hasn't changed much, so it should be possible to configure 2.6.x or a SVN/git checkout to build a driver that will neatly overlay the one from the 2.4.x package.

> lsusb -vvv -d 0764:0501 (I find it interesting that this appears to include all the values the UPS sends, I didn't know the kernel tracks that.)

Technically, lsusb is only using the kernel to pass USB requests down to the device - it does not see what the kernel has stored. What usually happens is that the kernel usbhid driver has exclusive access to the HID interface on the USB device, and lsusb can't retrieve the HID report descriptor:

        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     387
         Report Descriptors: 
           ** UNAVAILABLE **

If you run lsusb with appropriate write permissions (usually as root) *after* NUT's usbhid-ups driver has connected to the device, the kernel usbhid driver will be detached, and lsusb will show the additional information.

> Bus 002 Device 007: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
> Device Descriptor:
>  bLength                18
>  bDescriptorType         1
>  bcdUSB               2.00
>  bDeviceClass            0 (Defined at Interface level)
>  bDeviceSubClass         0
>  bDeviceProtocol         0
>  bMaxPacketSize0        64
>  idVendor           0x0764 Cyber Power System, Inc.
>  idProduct          0x0501 CP1500 AVR UPS
>  bcdDevice            0.01
>  iManufacturer           1 CP1350PFCLCD
>  iProduct                2 CRCA102-3I1
>  iSerial                 3 CPS

It looks like the manufacturer, product and serial strings have been permuted. I think we can match on iManufacturer here once we figure out what the scaling should be.

-- 
Charles Lepple
clepple at gmail