[Nut-upsuser] Newer APC Back-UPS spurious events

[Andy Smith]

Hi,

[ There is also a github issue about this here:
  https://github.com/networkupstools/nut/issues/2347 ]

I have an APC Back-UPS BX1600MI purchased in January, attached by
its supplied USB cable to a Debian 10 machine. Initially using the
nut packaged in Debian 10 (2.7.4-8) this was unusable as the
usbhid-ups driver kept disconnecting every few seconds.

I upgraded to the git HEAD of nut and communication is now stable,
but spurious events come in every so often (once or twice an hour at
the moment). The events are most often "low battery" and "replace
battery" but also sometimes "battery detach" and then "battery
re-attach". When I call a notify script that just calls upsc at the
time of those spurious events, I can see that the ups.status does
bear that out, but other values do not. Example:

battery.charge: 100
battery.charge.low: 10
battery.mfr.date: 2001/01/01
battery.runtime: 659
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 27.3
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Back-UPS BX1600MI
device.serial: 9B2339A15993
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: usbhid-ups
driver.parameter.poll freq: 30
driver.parameter.poll interval: 2
driver.parameter.port : auto
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.1-884-gf2fc47067
driver.version.data: APC HID 0.100
driver.version.internal: 0.52
driver.version.usb: libusb-1.0.22 (API: 0x1000106)
input.sensitivity: medium
input.transfer.high: 295
input.transfer.low: 145
input.voltage: 234.0
input.voltage.nominal: 230
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.load: 30
ups.mfr: American Power Conversion
ups.mfr.date: 2023/10/05
ups.model: Back-UPS BX1600MI
ups.productid: 0002
ups.realpower.nominal: 900
ups.serial: 9B2339A15993
ups.status: OL LB RB
ups.test.result: Done and passed
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

As you can see, the status does include LB and RB, but the charge is
still 100 and the runtime is as expected. The bad status lasts less
than 2 seconds before returning to simply OL. So far this has always
been the case: the strange status only appears for usually less than
1 second, occasionally a little more but never yet more than 2
seconds.

I went to the effort of installing a Windows VM, passing USB through
to it and trying APC's own Powerchute Serial Shutdown software in
there. This software does not report any spurious events. Both
Powerchute and nut do report true events that I induce. A self-test
of the device passed. I am unable to demonstrate any behaviour that
APC consider incorrect, because they are only interested in what
Powerchute reports.

Someone suggested running a USB sniffer under Windows to see if the
spurious events still come in (that Powerchute would then presumably
ignore or not notice due to short duration). I have not yet done
this as it's completely outside my experience but I can look into
that if it would be useful.

I returned the UPS to the supplier as faulty and they sent a
replacement. The replacement behaves the same.

I installed apcupsd just to see how it behaved. It maintained a
connection but its rate of spurious events was even worse: every
couple of minutes. Another apcupsd user reports the same symptoms as
me:

https://sourceforge.net/p/apcupsd/mailman/message/58740970/

Notably, they report having a BX1600MI working fine with apcupsd,
replaced it with another BX1600MI and now they see what I see,
implying that newer models of Back-UPS have something different
about them even though they are the same model number.

There is also another comment on the GitHub issue from someone with
a BX1200MI experiencing the same thing. They were able to include a
debug log from the driver, which I have not done yet, but can if it
would help.

Is there any way to work around this sort of thing? It's almost like
I need a way to not believe such statuses unless they persist for at
least 5 seconds, or something.

I suppose in the worst case I can make my notify script handle that
logic and key off of reported remaining runtime as the decider for
doing a shutdown, but the alarming syslog messages 15+ times a day
are not great.

Thanks,
Andy