[Nut-upsdev] Re: CyberPower 685AVR and newhidups

[Scott Alfter]

Peter Selinger wrote:
> Scott Alfter wrote:
>>Peter Selinger wrote:
>> > It would be great if you could post the output of
>>
>>>"upsc upsname at localhost" back to the list. 
>>
>>driver.name: newhidups
>>driver.parameter.generic: 1
>>driver.parameter.port: /dev/usb/hiddev0
>>driver.parameter.vendorid: 0764
>>driver.version: 2.1.0
>>driver.version.data: GENERIC HID 0.1
>>driver.version.internal: 0.28
>>ups.mfr: CPS
>>ups.model: UPS BF700
> 
> 
> This list is incomplete, because you ran the driver with the "-x
> generic" option when you produced it (the line
> "driver.parameter.generic: 1" gives it away!). Please run without this
> option, and a lot more variables should be listed, included
> (hopefully) all the ones that I was asking about.

That was an error on my part in /etc/nut/ups.conf...it still had
"generic=1" as an option.  Taking that out produced (among other things):

ups.power.nominal=552 (close enough to 550 for government work)
ups.delay.shutdown=-1 (what you said it should be)
ups.test.result=Done and passed

Is there a reason why it should return 550 VA?  The specs for this UPS
say it should be good for 685 VA.  (390 W is also specified for it,
which is what you were getting earlier.)

Battery voltage seems a bit high: 21.0V.  I'd think it'd be closer to
14V while charging (thinking that it'd charge the same way as a car
battery, given that they're both lead-acid).  It stayed at 21V when I
unplugged the UPS (though status changed from "OL" to "OB DISCHRG").  I
suppose one way to see if this is correct would be to try getting a
voltmeter across the battery terminals while it's powered up.  That
would be a bit of a pain, but if you need me to do that, I can give it a
shot.  If this seemingly-high charging voltage is typical, though, I'll
let it go at that.

The rest of it looks reasonable: switch to battery at <90V or >140V,
lead-acid battery type, input and output currently 121V.  Load is
currently 0, but all I have plugged in is a WAP.  With a 60W
incandescent lightbulb plugged in, the load is indicated as 12.0 and the
battery runtime is decreased (from 4800 to 2310...seconds, I'm guessing).

Here's the complete dump:

battery.charge: 120
battery.charge.low: 10
battery.charge.warning: 20
battery.runtime: 2310
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 21.0
battery.voltage.nominal: 12.0
driver.name: newhidups
driver.parameter.port: /dev/usb/hiddev0
driver.parameter.vendorid: 0764
driver.version: 2.1.0
driver.version.data: APC/CyberPower HID 0.9
driver.version.internal: 0.28
input.transfer.high: 140
input.transfer.low: 90
input.voltage: 121.0
input.voltage.nominal: 120
output.voltage: 121.0
ups.beeper.status: enabled
ups.delay.shutdown: -1
ups.load: 12.0
ups.mfr: CPS
ups.model: UPS BF700
ups.power.nominal: 552
ups.status: OL
ups.test.result: Done and passed

(With the subsequent tests complete and the UPS supplying power to the
server again, the load is indicated as 53.0.  This is for a 1.0-GHz
Athlon (Thunderbird core) with two hard drives (one 10-krpm SCSI and one
7200-rpm IDE) and a 14" or 15" CRT (not sure which).  I suspect that the
load isn't scaled properly.  Runtime is down to 690.)

>>>Please also test the following instant commands (again, disconnect
>>>your equipment from the UPS before testing):

(I still have the light plugged into the UPS at this point.)

>>>load.off

With power applied to the UPS, the light briefly switches off, then
switches back on.  It's off for maybe a second.

With power disconnected, the light switches off and stays off.  The
server started shutting itself down shortly after the UPS switched off.
 (I must've had upsmon started as well as the driver.  It should've
lasted longer than a few seconds, though, as the battery would've been
nowhere near dead.)

>>>load.on

Whether the UPS is on wall power or not, this appears to have no effect.

>>>shutdown.return

"Instant command failed: Instant command not supported"

upscmd -l ups at localhost returns the following:

Instant commands supported on UPS [ups at localhost]:

load.off - Turn off the load immediately
load.on - Turn on the load immediately
shutdown.stop - Stop a shutdown in progress
beeper.on - Enable the UPS beeper
beeper.off - Disable the UPS beeper

>>>shutdown.stop

This appears to have no effect.

>>>beeper.on
>>>beeper.off
>>>
>>>(the latter two will only work properly during a "beeper" event, i.e.,
>>>when there is a power failure).

I unplugged the UPS and tried these.  At first, I thought these commands
had no effect and that the beeper appeared to not be working.  It turns
out that it sounds off only occasionally instead of continuously...maybe
once every 30 seconds.  beeper.off does shut off the beeper, and
beeper.on turns it back on.

>>>Finally, it would be great if you could test the -k flag, to see if it
>>>shuts down the power. 
>>>
>>>drivers/newhidups -DD -u root -x vendorid=0764 auto -k

This appears to do nothing while the UPS is on wall power or on battery.

>>One other bit of weirdness I've noticed is that in order to switch
>>back to the hidups driver, I have to unload and reload usbhid.ko.
>>When newhidups loads up, /dev/usb/hiddev0 goes away.
> 
> Yes, this is normal. Newhidups uses the /proc/bus/usb/... interface,
> and the kernel does not allow this and /dev/usb/hiddev0 to be used at
> the same time. The kernel actually removes /dev/usb/hiddev0 in this
> situation.  Unplugging and re-plugging the USB device should have the
> same effect as reloading the kernel driver.

Got it.  I have the newhidups driver running the show now, so that
shouldn't be a problem from here on out.

Scott Alfter
scott at alfter.us