Hello. It's been a while since I started this topic. I've finally tested it on Linux desktop PC. Nut version 2.6.4-2.3 Basically the behavior is the same as on raspberry pi. It reports "battery needs to be replaced" regularly and I got "on battery" message
114107.780504 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x0a, Offset: 2, Size: 1, Value: 0 (on line nr. 1044540 in log) after ~ 31 hours of testing along with immediate "low battery (critical)" not sure, but probably because of 114107.780620 Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Input, ReportID: 0x0a, Offset: 4, Size: 1, Value: 1 (on line nr. 1044544 in log) message. Full zipped log (5,8 MB) with -DDD driver debug level available at http://wikisend.com/download/396966/upsdebug.zip As before, no power failure was present at the time this happened. The UPS at the time I bought it (in June) was capable of supplying backup power for PC for more than 15 minutes. Martins Pukitis. -----Original Message----- From: Charles Lepple [mailto:[email protected]] Sent: Tuesday, June 11, 2013 4:27 PM To: Mārtiņš Puķītis Cc: nut-upsuser lists.alioth.debian.org; [email protected] Subject: Re: [Nut-upsuser] several problems with Powercom BNT-500AP [I am CC'ing Alexey from Powercom in case he has seen any of these issues with the Raspberry Pi hardware.] On Jun 10, 2013, at 1:05 PM, Mārtiņš Puķītis wrote: > I took the log. Here's what happened. > Broadcast Message from nut@rasp > (somewhere) at 16:18 ... > UPS BNT500AP@localhost battery needs to be replaced > > occurred when for the first time value "1" was read as > "UPS.PowerSummary.PresentStatus.NeedReplacement", on this line: > 6409.240690 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: > Input, ReportID: 0x0a, Offset: 6, Size: 1, Value: 1 > It happened for 9 times, but the message appeared only on first. Correct, upsmon throttles the REPLBATT event: http://www.networkupstools.org/docs/man/upsmon.conf.html (search for RBWARNTIME) > Broadcast Message from nut@rasp > (somewhere) at 17:33 ... > > UPS BNT500AP@localhost on battery > occurred when UPS.PowerSummary.PresentStatus.ACPresent turned to 0 on this > line: > 10921.069403 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, > ReportID: 0x0a, Offset: 2, Size: 1, Value: 0 If you turn up the debugging level from 2 to 3, the driver will do a hex dump of the report buffer. Offset and size are bits, so if the ACPresent bit is 0, that's what the driver reports. > Here I also see a suspisious frequency value 70. How is this possible? > 43194.046966 Path: UPS.Input.Frequency, Type: Feature, ReportID: 0x1e, > Offset: 0, Size: 8, Value: 70 Similar situation to ACPresent - if those are the bits coming in, that's what the driver reports. Granted, there are cases where usbhid-ups might be misinterpreting those bits, but as you can imagine, it is hard to test all of the corner cases. We should be getting an error message from usbhid-ups if the USB reply is not long enough. > At 2:58: > 44790.984549 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, > ReportID: 0x0a, Offset: 2, Size: 1, Value: 0 > Here all voltages and frequencies are OK, so I don't understand why ACPresent > is 0. usbhid-ups does not look at voltage and frequency to determine whether AC is present. Voltage and frequency values can be averages over time (with the averaging being performed in the UPS microprocessor), so the driver simply trusts the ACPresent bit returned by the UPS. I'm starting to wonder if the USB controller or driver in the Raspberry Pi is flaky. We have seen odd issues with other ARM/Linux boards, and none of the symptoms are the same as on x86 PCs. Do you have a desktop or laptop Linux system where you can test this? -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
