[Nut-upsuser] CyberPower BR850ELCD ignores offdelay and turns itself back on while still on battery

Thu Jan 22 14:53:40 UTC 2015

Hi Charles,

Thanks so much for your quick and detailed reply! I've added my answers 
and details inline.

On 22.1.2015 04:46, Charles Lepple wrote:
> On Jan 21, 2015, at 9:15 AM, Sebastian Hosche <sebastian.hosche at web.de> 
> wrote:
> 
>> First issue: whatever I set as the offdelay, seems to be ignored and 
>> the UPS just cuts the power about 2sec after receiving the shutdown 
>> command.
> 
> What values have you tried? I wonder if it is rounding down to 0 
> seconds.
Great idea! I did some testing and it appears anything lower than 60 for 
offdelay simply gets ignored. In fact, setting offdelay to 60sec also 
fixes the second issue. Even with no device plugged into the UPS, it 
stays off while still on battery power!
> 
>> Second issue: When the UPS is on battery power and I issue the 
>> shutdown, it goes off, but after about 15sec it comes back on even 
>> while still on battery power. I tried setting ondelay to -1 and while 
>> that keeps the USV off, when the power comes back, the USV appears to 
>> turn on, but there is no power on its outlets. Only the additional 3 
>> outlets that are not covered by the battery, do have power. The only 
>> fix is to turn off the USV and turn it back on.
>> For this issue, I attached three driver debug logs:
> 
> USV == UPS, correct? Or is there another module involved?

Yes, USV is the German acronym for UPS, which I accidentally slipped in.

> I know this sounds off-topic, but in the logs, the PercentLoad is
> always 0. Is this actually the case, or is this a measurement error?

That's a measurement error on the UPS. As a test I had a 40W lamp 
plugged into it and in later testing, I looked at its display, it was 
also showing a 0% load. It's rated for a max of 510W and I guess isn't 
very sensitive in the lower 2 digit watts.
I plugged in another 50W lamp and then it finally started showing a 19% 
load. The equipment I intend to run via the UPS usually shouldn't 
consume more than 30W, so I guess the load indicator won't be of any 
use, but since the increasing offdelay fixed both issues, I'm hoping no 
long term issues creep up in the future.

> 2) the PercentLoad variable is being scaled incorrectly. In this case,
> the values for offdelay and ondelay might also be similarly affect.
> 
> Case #2 is also likely because after 2.6.4 was released, we patched
> drivers/cps-hid.c to scale the battery voltage.
> 
> Unfortunately, 2.6.4 is old enough that it does not print fractional
> values, so we would need to infer scale problems from the HID Report
> Descriptor.

Even though this doesn't appear to be the issue, I still included the 
debug_DDD.txt for you in case there's an useful info in it.

>> Before cutting the power, you can see the "OB DISCHARG" status in 
>> 2)))) as I would expect it for when the UPS is on battery power.
>> That changes into "OB CHRG" in 3)))) after I issued the shutdown 
>> command. What does that mean? on battery + charge doesn't make any 
>> sense to me.
> 
> Doesn't make any sense to me either, but it's definitely what the UPS
> is reporting:
> 
> Ordinarily, I would check to see if the OB and CHRG bits are coming
> from different reports, but they are from the same byte of Report
> 0x22.

No worries - likely just some quirk of the device.

>> 4)))) is then shortly before the UPS turns power back on (while still 
>> on battery) - the "ups.timer.shutdown" variable is back to the 
>> default.
>> 5)))) is after the UPS turned the power back on (still running on 
>> battery) - The status changed to "OB DISCHARG" and the 
>> "ups.timer.start" is also back to default.
> 
> This is also confusing, but I'll have to look at the code again to see
> what should be happening.

Thanks, but I think there's no need to investigate this further as I 
don't see it influencing any functionality. If you still would like to 
take a closer look and need any further details from me, let me know.

there's one additional issues I came across - on boot, the driver fails 
to load. Here's a syslog snippet:
Jan  1 02:00:13 beagle kernel: [    5.932402] usb 1-3.2: New USB device 
found, idVendor=0764, idProduct=0501
Jan  1 02:00:13 beagle kernel: [    5.935372] usb 1-3.2: New USB device 
strings: Mfr=3, Product=1, SerialNumber=0
Jan  1 02:00:13 beagle kernel: [    5.942662] usb 1-3.2: Product: 
BR850ELCD
Jan  1 02:00:13 beagle kernel: [    5.946589] usb 1-3.2: Manufacturer: 
CPS

between the USB device detected and upsd failing to start, there are 
about 50 more lines in the syslog, including the following services - 
acpid, ntpd, networkmanager, dbus
Then follows:

Jan  1 02:00:13 beagle kernel: [   10.406794] hid-generic 
0003:0764:0501.0003: hiddev0,hidraw2: USB HID v1.10 Device [CPS 
BR850ELCD] on usb-s5p-ehci-3.2/input0

following this, are multiple lines from the modemananger service and 
another USB device getting recognized. Only then, upsd is loaded and 
fails:
Jan  1 02:00:14 beagle upsd[2744]: listening on 127.0.0.1 port 3493
Jan  1 02:00:14 beagle upsd[2744]: listening on ::1 port 3493
Jan  1 02:00:14 beagle upsd[2744]: Can't connect to UPS [cyberdyne] 
(usbhid-ups-cyberdyne): No such file or directory
Jan  1 02:00:14 beagle upsd[2754]: Startup successful
Jan  1 02:00:14 beagle upsmon[2803]: Startup successful
Jan  1 02:00:14 beagle upsd[2754]: User upsmaster at 127.0.0.1 logged into 
UPS [cyberdyne]
Jan  1 02:00:14 beagle upsmon[2805]: Poll UPS [cyberdyne at localhost] 
failed - Driver not connected
Jan  1 02:00:14 beagle upsmon[2805]: Communications with UPS 
cyberdyne at localhost lost
Jan  1 02:02:04 beagle upsmon[3125]: Poll UPS [cyberdyne at localhost] 
failed - Driver not connected

I've worked around the issue by preventing nut-server and nut-client 
from starting directly and adding a script to rc.local that waits for 15 
sec before starting up nut-server and then 15sec later starting 
nut-client. That does seem to do the trick, but it is kind of hacky.

Is there a way to start up nut-server on boot in some debug mode to have 
it add more details to the log?

All the best,
Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug_log.zip
Type: application/zip
Size: 4409 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150122/2c5f7cac/attachment.zip>