Nut upsuser - Nov 2013 - several problems with Powercom BNT-500AP

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:clepple at gmail.com] 
Sent: Tuesday, June 11, 2013 4:27 PM
To: M?rti?? Pu??tis
Cc: nut-upsuser lists.alioth.debian.org; morozov at pcm.ru
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 at rasp
>        (somewhere) at 16:18 ...
> UPS BNT500AP at 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 at rasp
>        (somewhere) at 17:33 ...
> 
> UPS BNT500AP at 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 at gmail