stefanos at karandreas.gr wrote:> > Do you have by any chance the CyberPower CP1300EPFCLCD? I would > personally be interested > in the variables it supports as I am thinking of buying that model to > replace an APC BX1400 > and I would like to know if it supports changing battery.charge.low etc. > > I have also read 1-2 reviews for the specific model that mention that it > loses USB > connectivity when switching to battery and back which would be > disastrous for NUT. > Any feedback you have on that or the CyberPower model(s) would be most > helpful!Hi, I have a CyberPower CP1500EPFCLCD. I live in a rural location and experience frequent power failures. I run a nut server on a FreeBSD host named "sherman". It has a USB connection to the CP1500EPFCLCD, using the usbhid-ups driver. I don't use nut clients, preferring to use one-shot root privileged ssh keys to execute remote commands (i.e. shutdown) on the "network peers" of the nut server. The CP1500EPFCLCD has firmware "issues", and I expect that there's a very good chance that the CP1300EPFCLCD is the same. The USB connection experiences a transient disconnect when power drops. Here is one of many identical examples from /var/log/messages. However, nut seems to handle the USB disconnects without problems: May 23 04:01:31 sherman squid[31854]: Squid Parent: (squid-1) process 31856 started May 23 10:12:31 sherman kernel: ugen2.2: <CPS CP1500EPFCLCD> at usbus2 (disconnected) May 23 10:12:32 sherman kernel: ugen2.2: <CPS CP1500EPFCLCD> at usbus2 May 23 10:12:38 sherman nut-notify[33055]: UPS cp1500 onbatt May 23 10:12:44 sherman nut-notify[33097]: UPS cp1500 five-minute-warning-timer May 23 10:16:43 sherman nut-notify[33141]: UPS cp1500 one-minute-warning-timer May 23 10:17:43 sherman nut-notify[33185]: UPS cp1500 shutdown-timer May 23 10:17:43 sherman upsmon[1225]: Executing automatic power-fail shutdown May 23 10:17:43 sherman upsmon[1225]: Auto logout and shutdown proceeding May 23 10:17:44 sherman nut-shutdown[33227]: nut power-fail network shutdown sequence commencing May 23 10:17:44 sherman nut-shutdownpeers[33237]: nut shutdown peers alert: shutting down strand May 23 10:17:47 sherman nut-shutdownpeers[33249]: nut shutdown peers alert: shutting down fable May 23 10:17:49 sherman nut-shutdownpeers[33259]: nut shutdown peers alert: shutting down mith May 23 10:17:58 sherman nut-shutdownpeers[33269]: nut shutdown peers alert: shutting down orac May 23 10:18:00 sherman nut-shutdownpeers[33279]: nut shutdown peers alert: shutting down pi3b May 23 10:18:02 sherman nut-shutdownpeers[33289]: nut shutdown peers alert: skipping pi4 (not up) May 23 10:18:03 sherman shutdown[33295]: power-down by root The major firmware issue I tripped over is with "ups.delay.start". See: https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-October/011253.html The nut manual says set ups.delay.start (default 30) as the interval to wait before restarting the load (seconds) [AFTER UPS power returns]. The CyberPower CP1500EPFCLCD UPS restarts ups.delay.start seconds after the UPS is shutdown REGARDLESS of the wall power status. i.e. regardless of mains status: - ondelay=0, UPS powers on the load when mains return - ondelay=-1, UPS never powers on the load, even when mains return - ondelay=xx, UPS powers on the load after xx (roughly) seconds after UPS shutdown is executed. I have reported this issues to CyberPower support, but got no satisfactory resolution. It's a serious problem... This bug makes using "battery.charge.low" pretty much impossible, because with a low battery you need to re-charge the battery AFTER wall power returns and BEFORE restarting the load to power up the clients -- lest you go into an infinite shutdown/reboot loop. The faulty handling of ups.delay.start prevents the battery from re-charging to a workable level after discharge (unless you set ondelay=-1, which means you can't power up automatically). To work around this problem, I run /usr/local/bin/nut-shutdown 5 minutes after wall power drops. It shuts down all the network peers using a one-shot ssh key. BIOS configurations allow everything to reboot when the UPS supplies power immediately the wall power returns. With my 300W load, the 5 minute delay ensures that the battery reserve is sufficient for a restart, and avoids bouncing around any battery low condition. I also regret not having an ability to delay load supply on each of the UPS power outputs, and will look for that feature next time I buy a UPS. The fact is that I really need to bring up my network, firewall, and DHCP server BEFORE the rest of the general computer systems, and the CP1500EPFCLCD can't do that. My small home network won't boot up properly unless the power is sequenced to requirements (I really do need the DHCP server up first). So I find myself writing rc scripts to delay booting on some clients after a power failure... ################################################################################ Here are the variables the CP1500EPFCLCD "supports": [sherman.136] $ upscmd -l cp1500 Instant commands supported on UPS [cp1500]: beeper.disable - Disable the UPS beeper beeper.enable - Enable the UPS beeper beeper.mute - Temporarily mute the UPS beeper beeper.off - Obsolete (use beeper.disable or beeper.mute) beeper.on - Obsolete (use beeper.enable) load.off - Turn off the load immediately load.off.delay - Turn off the load with a delay (seconds) load.on - Turn on the load immediately load.on.delay - Turn on the load with a delay (seconds) shutdown.return - Turn off the load and return when power is back shutdown.stayoff - Turn off the load and remain off shutdown.stop - Stop a shutdown in progress test.battery.start.deep - Start a deep battery test test.battery.start.quick - Start a quick battery test test.battery.stop - Stop the battery test [sherman.137] $ upsc cp1500 battery.charge: 100 battery.charge.low: 33 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 1560 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 24.0 battery.voltage.nominal: 24 device.mfr: CPS device.model: CP1500EPFCLCD device.serial: CTLKT2000131 device.type: ups driver.name: usbhid-ups driver.parameter.lowbatt: 33 driver.parameter.offdelay: 90 driver.parameter.ondelay: 0 driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.data: CyberPower HID 0.4 driver.version.internal: 0.41 input.transfer.high: 260 input.transfer.low: 170 input.voltage: 227.0 input.voltage.nominal: 230 output.voltage: 260.0 ups.beeper.status: enabled ups.delay.shutdown: 90 ups.delay.start: 0 ups.load: 32 ups.mfr: CPS ups.model: CP1500EPFCLCD ups.productid: 0501 ups.realpower.nominal: 900 ups.serial: CTLKT2000131 ups.status: OL ups.test.result: No test initiated ups.timer.shutdown: -60 ups.timer.start: -60 ups.vendorid: 0764 ################################################################################ I'm happy to publish the detailed configuration if anyone would like to see it. Cheers, -- Phil My life has a superb cast but I can't figure out the plot. -- Ashleigh Brilliant (1933--), U.S. writer
Thanks for posting all those details; they are interesting.
I think it would be helpful to publish the config, at least the nut
logic part, and the details of cyberpower actual vs documented behavior.
(nut github wiki if Jim thinks that makes sense?) Or maybe there is a
better place.
It seems that while how a UPS has to behave to reliably and safely
handle loss of power and restart, with all the possible sequencing, is
pretty well understood on this list, a lot of devices don't do it right.
So having documentation per model that enables buying something that
works seems key, and I don't find that.
Perhaps a warning not to buy cyberpower products would result in bug
fixes. Perhaps not.
It strikes me that it should be possible to express start delay as e.g.
wait until both are true:
power has been stable for 120s
battery is at least 80% charged
For your own situation, I wonder if this is a job for a microcontroller
and a bunch of relays, to patch up your UPS and make your power
sequencing do what you want. Or a tiny computer like an RPI, maybe with
its own extended battery, or hooked into your dhcp server. Maybe that's
a crazy idea, and I know it has a lot of downsides.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220605/7420433c/attachment.sig>
stefanos at karandreas.gr
2022-Jun-06 21:39 UTC
[Nut-upsuser] Info on Cyber Power CP1500AVRLCDa
On 2022-06-05 09:06, Phil Chadwick wrote:> > Hi, > > I have a CyberPower CP1500EPFCLCD. > > I live in a rural location and experience frequent power failures. > > I run a nut server on a FreeBSD host named "sherman". It has a USB > connection to the CP1500EPFCLCD, using the usbhid-ups driver. I don't > use > nut clients, preferring to use one-shot root privileged ssh keys to > execute > remote commands (i.e. shutdown) on the "network peers" of the nut > server. > > The CP1500EPFCLCD has firmware "issues", and I expect that there's a > very > good chance that the CP1300EPFCLCD is the same. > > The USB connection experiences a transient disconnect when power drops.If the connection loss lasts couple sec max I guess it's something I and NUT can live with, since as you mention it doesn't seem to affect how NUT operates. I received another reply from the list that mentioned that for the 900VA model there was no problem with the USB connection. I have to wonder whether that is a result of the ephemeral connection loss.> The major firmware issue I tripped over is with "ups.delay.start". > See: > > > https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-October/011253.html > > The nut manual says set ups.delay.start (default 30) as the interval to > wait > before restarting the load (seconds) [AFTER UPS power returns]. The > CyberPower CP1500EPFCLCD UPS restarts ups.delay.start seconds after the > UPS > is shutdown REGARDLESS of the wall power status. i.e. regardless of > mains > status: > > - ondelay=0, UPS powers on the load when mains return > - ondelay=-1, UPS never powers on the load, even when mains return > - ondelay=xx, UPS powers on the load after xx (roughly) seconds > after UPS shutdown is executed. > > I have reported this issues to CyberPower support, but got no > satisfactory > resolution. It's a serious problem... > > This bug makes using "battery.charge.low" pretty much impossible, > because > with a low battery you need to re-charge the battery AFTER wall power > returns and BEFORE restarting the load to power up the clients -- lest > you go into an infinite shutdown/reboot loop. The faulty handling of > ups.delay.start prevents the battery from re-charging to a workable > level > after discharge (unless you set ondelay=-1, which means you can't power > up automatically). >Can you share a link to where the manual describes ups.delay.start? I found some information but not the complete description you mention here. For ondelay=0 what happens? The load instantly returns on UPS shutdown or the bug doesn't trigger? Thanks, Stefanos