[Nut-upsuser] [HCL] Cyber Power Systems CP1500AVRLCDa supported by usbhid-ups

[Charles Lepple]

On Jun 3, 2017, at 2:21 PM, Mike <the.lists at mgm51.com> wrote:
> 
> On 5/30/2017 10:47 PM, Charles Lepple wrote:
>> On May 22, 2017, at 11:13 AM, Mike <the.lists at mgm51.com> wrote:
>>> 
>>> On 5/21/2017 10:39 AM, Charles Lepple wrote:
> [snip]
> 
>> Even though the CPS sub-driver has been written already, I would like to take a look at the raw "explore" mode output:
>> 
>> http://new.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_writing_a_subdriver
> 
> 
> When I ran:
> 
> drivers/usbhid-ups -DD -u root -x explore -x vendorid=0764 auto
> 
> it balked at "auto":
> 
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
>   0.000000     Error: too many non-option arguments. Try -h for help.
> 
> 
> so I added a -a parameter to point to the ups name configured in
> ups.conf, and that worked.  The output from that command is zipped and
> attached.

Heh, that's embarrassing that the "-a" has been missing for so long. Noted.

> 
> [snip]
>> 
>> If it were the input voltage, I would recommend experimenting with a variac, but you are probably not going to see much of a range on the output before the buck/boost circuits kick in. So it's still an option, but it might not be worth the trouble for an UPS in service (or if you don't have a variac handy).
> 
> 
> Here's the results of the varying voltage tests:
> 
> input   output       UPS        output.voltage  input.voltage
> to UPS  from UPS     display
> 119.9   120.4        119            136.0          120.0
> 115.2   115.6        114            138.0          114.0
> 127.3   128.0        127            136.0          127.0
> 135.5   136.4        135            136.0          135.0
> 100.4   100.5        100            140.0          100.0
> 94.9   105.1         95            137.0           96.0
> 120.7   121.1        120            142.0          118.0
> 140.8   122.8        139            136.0          139.0
> 121.7   122.1        121            136.0          120.0

This is starting to come back to me - I think we saw this with several other CPS devices.

Here's an excerpt from the CP1500AVRLCDa HID descriptor:

Collection(Physical)
    Report ID(16)
        Usage(LowVoltageTransfer)
        Logical Minimum(97)
        Logical Maximum(103)
        Feature(Data,Variable,Absolute)

        Usage(LowVoltageTransfer)
        Input(Constant,Variable,Absolute)

        Usage(HighVoltageTransfer)
        Logical Minimum(136)
        Logical Maximum(142)
        Feature(Data,Variable,Absolute)

        Usage(HighVoltageTransfer)
        Input(Constant,Variable,Absolute)

    Report ID(18)
        Usage(Voltage)
        Feature(Constant,Variable,Absolute)

        Report Size(8)
        Logical Minimum(0)
        Logical Maximum(255)
        Unit(SI Linear: ...)
        Unit Exponent(0)

Basically, it is saying that you can set each of LowVoltageTransfer and HighVoltageTransfer to a number between 97--103 and 136--142, respectively (per the Feature). You can also read back the value (Input). Both of these are set in Report 16.

The HID descriptor uses a stateful parser to keep track of things that don't change between each Input, Feature or Output element. So the HighVoltageTransfer Input has the same range as the HighVoltageTransfer Feature.

However, I don't believe that parser should be completely reset between each Report ID. So the Voltage Feature inherits the last range (136-142) from the HighVoltageTransfer Input. This confuses the NUT HID parser, which is only expecting an integer between 0 and 6, inclusive. I suppose we should have a range check for that.

Progress has been slow on patching the HID descriptors: https://github.com/networkupstools/nut/issues/169

On the other hand, since Report ID 16 doesn't look as broken as ID 18, adjusting the high and low transfer voltages might not be hard: https://github.com/networkupstools/nut/issues/438

> 4) when I went down to 95 volts, the "AVR" kicked in to boost the
> voltage without going to battery.  This was indicated by a "click" from
> the UPS and an indication on the UPS display.

In non-explore mode, does the driver report the AVR status? (No need to set things back up if you have torn it down already, just curious.)

Regarding the battery.mfr.date thing, I should have checked on the source code earlier. It is just retrieving a number from UPS.PowerSummary.iOEMInformation, and using that as a USB string index. Looks like a typo - none of the other DDL entries for CPS show anything that looks like a date. The CPS HID code was forked from the APC HID code, and APC has their own algorithm for encoding battery dates (which is what I thought I was remembering).

Does OpenBSD have something like FreeBSD's usbconfig? You could try retrieving other string descriptors to see if this is something that got moved (and iOEMInformation happened to point to the right string), or if it is just a mistake in the source code.

   usbconfig -u	0 -a 1 dump_string 3