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