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

[Sebastian Hosche]

Hi Charles,No worries about the delay. I hadn't had a chance to look into it until today. I pointed the upsdrvctl output to a log file and restarted, but the issue didn't occur this time. Maybe it fixed itself with a recent security update or it doesn't happen each time. Since I don't need modem-manager, I just removed it and I'm also keeping the log enabled in case the driver fails to load again on boot. 
Thanks again for your help. 
Sebastian 

On Jan 22, 2015, at 9:53 AM, Sebastian Hosche <sebastian.hosche at web.de> wrote: 
 
> Hi Charles, 
>  
> Thanks so much for your quick and detailed reply! I've added my answers and details inline. 
 
Sorry this reply wasn't as quick. 
 
> 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! 
 
Ah, glad that worked. I will add some notes to the documentation about the offdelay setting. 
 
> Yes, USV is the German acronym for UPS, which I accidentally slipped in. 
 
That's good to know. 
 
> 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. 
 
Thanks. Nothing looks strange, but it is good to have that for reference. 
 
> 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 
 
This is normal, although NUT detaches the hiddev/hidraw drivers, and goes directly through libusb to the generic USB kernel driver. 
 
> following this, are multiple lines from the modemananger service and another USB device getting recognized. 
 
If you don't need modemmanager, I would recommend disabling it. Here's a potentially related modemmanager bug in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1176548 
 
> 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 
 
Hmm, no errors logged by usbhid-ups? Although they log errors later, upsd and upsmon have started successfully. (The driver can be started separately after that.) 
 
> 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? 
 
Not sure where the logs will go at boot, but when I am testing init scripts from the command line, I usually change "#!/bin/sh" to "#!/bin/sh -x". 
 
Also, it looks like the output of upsdrvctl is being redirected to /dev/null (line 78). You could point that to a file. 
 
--  
Charles Lepple 
clepple at gmail 
 
 
 
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150129/60c2f1f5/attachment.html>