Mārtiņš Puķītis
2013-Jun-05 15:49 UTC
[Nut-upsuser] several problems with Powercom BNT-500AP
OS name and version: pi at raspberrypi ~ $ cat /etc/*release PRETTY_NAME="Debian GNU/Linux 7.0 (wheezy)" uname -a Linux raspberrypi 3.6.11+ #393 PREEMPT Fri Mar 8 16:36:28 GMT 2013 armv6l GNU/Linux exact NUT version pi at raspberrypi ~ $ dpkg -s nut Package: nut ... Version: 2.6.4-2.3 NUT installation method: package exact device name and related information: BNT-500AP http://pcmups.com.tw/eA/html/product/show.php?num=229 <http://pcmups.com.tw/eA/html/product/show.php?num=229&root=13&kind=113&page =1&keyword> &root=13&kind=113&page=1&keyword I have several problems with my UPS: 1. Wrong battery and UPS date reported. According to serial number 40438471204 UPS is manufactured on April 2012, but NUT reports: battery.date: 2010/12/20 ups.date: 2010/12/20 2. NUT occasionally (about once a day) reports that battery should be replaced, but I have tested it by removing the power and it can supply about 170 W for about 20 minutes, which, according to specifications, is OK. 3. NUT very frequently (about 10 times a day) goes on battery followed by immediate return to utility power, though there are no brownouts. My PC that isn?t connected to UPS doesn?t reboot. 4. This is the most bothering. I have seen it only once. NUT reported ?on battery? (actually there was no brownout) followed by immediate ?battery is low?, that triggered shutdown of pi. Broadcast Message from nut at rasp (somewhere) at 20:45 ... UPS BNT500AP at localhost on battery Broadcast Message from nut at rasp (somewhere) at 20:45 ... UPS BNT500AP at localhost battery is low Broadcast Message from nut at rasp (somewhere) at 20:45 ... Immediately after shutdown I turned the Raspberry pi on and checked the status. It showed: pi at raspberrypi ~ $ upsc BNT500AP at localhost battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 30 There is only pi and two low power embedded routers connected, so the total power consumption from UPS is < 50 W. Driver debug output attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20130605/6a708ac5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: nut_driver_debug2.zip Type: application/octet-stream Size: 4879 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20130605/6a708ac5/attachment.obj>
Charles Lepple
2013-Jun-08 03:06 UTC
[Nut-upsuser] several problems with Powercom BNT-500AP
On Jun 5, 2013, at 11:49 AM, M?rti?? Pu??tis wrote:> Driver debug output attached.The debug output looks normal (many devices do not implement the interrupt pipe; hence, the timeouts). Unfortunately, we might need the log over a longer period of time, including your observations as to when various events occurred (such as transitions to battery). -- Charles Lepple clepple at gmail
Mārtiņš Puķītis
2013-Jun-08 16:57 UTC
[Nut-upsuser] several problems with Powercom BNT-500AP
Thanks for the support. Here's list of when transition to battery with return to utility power within a few seconds occurred in last few days: Wednesday 1:41 11:48 11:54 12:59 13:42 14:42 18:13 18:14 Thursday 5:23 Friday 5:12 7:39 7:43 Saturday 7:34 Here's list of when messages that battery needs replacement occurred: Wednesday 20:34 Thursday 9:07 23:09 Friday 18:25 Saturday 7:32 19:47 I'll take a longer driver log. This page (http://www.networkupstools.org/support.html) says that to take a driver log NUT should be stopped, so I won't be able to tell when these events occurred within a driver log. -----Original Message----- From: Charles Lepple [mailto:clepple at gmail.com] Sent: Saturday, June 08, 2013 6:07 AM To: M?rti?? Pu??tis Cc: nut-upsuser lists.alioth.debian.org Subject: Re: [Nut-upsuser] several problems with Powercom BNT-500AP On Jun 5, 2013, at 11:49 AM, M?rti?? Pu??tis wrote:> Driver debug output attached.The debug output looks normal (many devices do not implement the interrupt pipe; hence, the timeouts). Unfortunately, we might need the log over a longer period of time, including your observations as to when various events occurred (such as transitions to battery). -- Charles Lepple clepple at gmail