Sebastian Hosche
2015-Jan-22 14:53 UTC
[Nut-upsuser] CyberPower BR850ELCD ignores offdelay and turns itself back on while still on battery
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>
Charles Lepple
2015-Jan-27 03:24 UTC
[Nut-upsuser] CyberPower BR850ELCD ignores offdelay and turns itself back on while still on battery
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/input0This 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 connectedHmm, 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
Sebastian Hosche
2015-Jan-29 21:05 UTC
[Nut-upsuser] CyberPower BR850ELCD ignores offdelay and turns itself back on while still on battery
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/input0This 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 connectedHmm, 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>
Apparently Analagous Threads
- CyberPower BR850ELCD ignores offdelay and turns itself back on while still on battery
- CyberPower BR850ELCD ignores offdelay and turns itself back on while still on battery
- CyberPower BR850ELCD ignores offdelay and turns itself back on while still on battery
- Samba 4.2.14 Group Policy (GPO) sync error
- Samba 4.2.14 Group Policy (GPO) sync error