Sam Varshavchik <mrsam at courier-mta.com> writes:> I lost power for about 40 seconds. From what I can see NUT quickly > shut down the system and boot it back up when power was restored. That > also worked. Everything worked as designed, except I would expect such > a brief shutdown to be survivable.It's really odd to lose power for 40 seconds in my experience. I wonder roughly where you are (looks like NA due to 120V, state?) and if you understand the mechanism for how it came back so fast. I would look in the logs and see if you can find that nut logged something about "low battery" or "forced shutdown". It is possible your batteries are tired, and it's possible that things are not configured right. You left out what the load on the UPS is. And battery type. I'm guessing 2 x 12V 7Ah size, perhaps labeled by marketing types as 9Ah. You left out the manufacture data / when you bought this. If it's 4 or 5 years old, sick batteries would not be surprising. If it's 1-2, they would be. But I don't have experience with CPS and if they treat the batteries better they may go longer.> The only question mark in my mind is that the battery should've been > enough to last those measly 40 seconds. Output of upsc is below. This > is about an hour after the power was restored, and I see that > battery.charge is only 29, and it is slowly increasing.There are a bunch of things in that output that don't really make sense to me. I think you need to understand all the settings and then pull the UPS from the computer, put a light bulb or two on it, and do a test. But if you figure out that settings were odd and fix them, you are probably ok.> So, I think is that my batteries are due for a replacement. I would've > wanted to see what was logged during the outage, but I can't find > anything in journalctl for nut-monitor or nut-server. This is Ubuntu > 24. Should there be something logged, somewhere?I use a script running upsc and reporting via mqtt logging in home assistant, and thus have data for outages. But 40s is crazy.> battery.charge: 29 > battery.charge.low: 10 > battery.charge.warning: 2010 for low seems a bit low but not crazy. 29 is super low for having experience a 40s outage. I would see where it is after 48h.> battery.mfr.date: CPS > battery.runtime: 2939 > battery.runtime.low: 3002939s is a very good runtime, and 300s is a reasoable "when runtime is below this value, start shutdown".> battery.type: PbAcid > battery.voltage: 27.3 > battery.voltage.nominal: 24 > device.mfr: CPS > device.model: CP1500AVRLCDa > device.serial: BHQLW7002402 > device.type: ups > driver.debug: 0> driver.flag.allow_killpower: 0This seems off; the OS should be able to stop the inverter.> driver.name: usbhid-ups > driver.parameter.pollfreq: 30 > driver.parameter.pollinterval: 10 > driver.parameter.port: auto > driver.parameter.synchronous: autoI'm unclear on these. Did you get a log entry when power failed?> driver.state: quiet > driver.version: 2.8.1That's old. Update to the latest release. I know you're using Ubuntu and they are behind. Update anyway.> driver.version.data: CyberPower HID 0.8 > driver.version.internal: 0.52 > driver.version.usb: libusb-1.0.27 (API: 0x100010a) > input.voltage: 120.0 > input.voltage.nominal: 120 > output.voltage: 120.0 > ups.beeper.status: enabledThat all seems ok.> ups.delay.shutdown: 20 > ups.delay.start: 30These are suspicious. Look up what they mean, and if ups.delay.shutdown is "after the killpower is sent, wait 20s before disabling the inverter" or if it means "start shutdown after 20s without power". I bet it's the first, but there are docs and there is source code.> ups.load: 6I'm guessing this is 6% of 1500 VA, or 90 VA. So you should with good batteries **and correct config** get much more than 40s, more like 30 minutes.> ups.mfr: CPS > ups.model: CP1500AVRLCDa > ups.productid: 0501 > ups.realpower.nominal: 900 > ups.serial: BHQLW7002402 > ups.status: OL CHRG > ups.test.result: No test initiated> ups.timer.shutdown: -60 > ups.timer.start: -60These are interesting too, and strange. Figure these out too.> ups.vendorid: 0764The other suggestion is write a script that does (this is pseudocode not testedd!!0 while true; do output=`choose an output file name from some counter` upsc foo > $output sleep 1 done and then leave that running while you turn off the breaker or power strip for 15 seconds. Then analyze/think and report back. Do not unplug; that disconnects ground. The other thing you could do is disasemble, extract batteries, charge each of them up and do a controlled load test at C/20h to 10.5V logging everything, but I suspect you aren't set up for that.
> The other thing you could do is disasemble, extract batteries, charge > each of them up and do a controlled load test at C/20h to 10.5V logging > everything, but I suspect you aren't set up for that.Thanks, that reminds me to drill holes in my APC Smart 2000 for connectors for discharge tests to calculate internal resistances. Un-stacking & un-bolting has been a too time consuming deterent to testing. Cheers, -- Julian Stacey http://berklix.org/jhs/mail/ @gmail blocks replies. Arm Ukraine. Contraception V. global warming. Israel starves Gaza. No digital ID Cards https://petition.parliament.uk/petitions/730194
Greg Troxel writes:> Sam Varshavchik <mrsam at courier-mta.com> writes: > > > I lost power for about 40 seconds. From what I can see NUT quickly > > shut down the system and boot it back up when power was restored. That > > also worked. Everything worked as designed, except I would expect such > > a brief shutdown to be survivable. > > It's really odd to lose power for 40 seconds in my experience. I wonder > roughly where you are (looks like NA due to 120V, state?) and if you > understand the mechanism for how it came back so fast.Yes, New Jersey. I'm fairly certain that it was local maintenance. The power grid here is pretty robust and redundant. This was early Saturday morning, I'm pretty sure it's weekend maintenance, they cut off a portion of a grid, and then quickly cut it in somewhere else.> I would look in the logs and see if you can find that nut logged > something about "low battery" or "forced shutdown".Well, that's what I'm asking. Where do I find these logs. I poked around with journalctl, and found just startup and shutdown messages.> It is possible your > batteries are tired, and it's possible that things are not configured > right.I'm fairly certain this is the case and I'll swap them. I was only wondering where the logs are, of nut doing its thing, I couldn't see anything in journalctl aside from routine startup messages.> I use a script running upsc and reporting via mqtt logging in home > assistant, and thus have data for outages. But 40s is crazy. > > > battery.charge: 29 > > battery.charge.low: 10 > > battery.charge.warning: 20 > > 10 for low seems a bit low but not crazy. 29 is super low for having > experience a 40s outage. I would see where it is after 48h.It's now: battery.charge: 100 I didn't monitor it closely enough to know when it finished charging. The 40s is my best estimate based on my security alarm's messages to my phone. It's an independent system with its own built-in backup, and it barks at my phone when it loses and regains power. As far as the low/warning levels these are apparently the defaults. I did not override anything in ups.conf: [nutdev1] driver = "usbhid-ups" port = "auto" pollinterval = 10 That's it, that's all I've got.> > battery.mfr.date: CPS > > battery.runtime: 2939 > > battery.runtime.low: 300 > > 2939s is a very good runtime, and 300s is a reasoable "when runtime is > below this value, start shutdown".I surmise that battery.runtime is calculated. This looks to me like it might be based on a healthy battery's capacity, but when push comes to shove, the UPS sees how fast the voltage is really dropping, and ?oh crap? ter.> > > driver.name: usbhid-ups > > driver.parameter.pollfreq: 30 > > driver.parameter.pollinterval: 10 > > driver.parameter.port: auto > > driver.parameter.synchronous: auto > > I'm unclear on these. Did you get a log entry when power failed?I dunno, that's what I'm asking. I don't see anything useful logged anywhere I looked. I found three things in systemctl, nut-monitor, nut-server, and a "nut-driver at nutdev1", and journalctl didn't show anything useful for these. Oh, they had something, but it was just the stock startup messages. Nothing was actually logged, for power events.> > driver.state: quiet > > driver.version: 2.8.1 > > That's old. Update to the latest release. I know you're using Ubuntu > and they are behind. Update anyway.I'm almost there, as far as motivation goes, to do that. Off-topic: I have the same Ubuntu/Debian general complaint: for the longest time Debian packaged ancient versions of my packages. Like decades ancient. I should say now that a volunteer has stepped out and is making progress; but I eventually solved that problem by figuring out how to package my tarballs so that they can be cookie-cuttered into installable .deb-s, similar to how rpm- aware tarballs can be compiled into binary packages without even extracting them. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251004/147189a7/attachment.sig>