networkupstools
CyberPower CP1600EPFCLCD supported by usbhid-ups with issues
### lsusb output:
Bus 001 Device 005: ID 0764:0601 Cyber Power System, Inc. PR1500LCDRT2U UPS
### upsc output:
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 13300
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 27.2
battery.voltage.nominal: 24
device.mfr: CPS
device.model: CP1600EPFCLCD
device.serial: BHYNY2000333
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 15
driver.parameter.port: auto
driver.parameter.productid: 0601
driver.parameter.serial: BHYNY2000333
driver.parameter.synchronous: no
driver.parameter.vendorid: 0764
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 226.0
input.voltage.nominal: 230
output.voltage: 226.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 0
ups.mfr: CPS
ups.model: CP1600EPFCLCD
ups.productid: 0601
ups.realpower.nominal: 1000
ups.serial: BHYNY2000333
ups.status: OL
ups.test.result: No test initiated
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764
### upsrw output:
[battery.charge.low]
Remaining battery level when UPS switches to LB (percent)
Type: STRING
Maximum length: 10
Value: 10
[battery.runtime.low]
Remaining battery runtime when UPS switches to LB (seconds)
Type: STRING
Maximum length: 10
Value: 300
[ups.delay.shutdown]
Interval to wait after shutdown with delay command (seconds)
Type: STRING
Maximum length: 10
Value: 20
[ups.delay.start]
Interval to wait before (re)starting the load (seconds)
Type: STRING
Maximum length: 10
Value: 30
### upscmd output:
Instant commands supported on UPS [ups]:
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
Instant commands tested:
Working:
test.battery.start.quick
ups beeper.disable
ups beeper.enable
Wrong behaviour:
load.off.delay 30 : Switches off the system immediately
load.off.delay 300 : Switches off the system after approximately 1 min.
Failing: All the following commands are responded with "OK" but no reaction visible:
load.on.delay 30
load.on
shutdown.return
shutdown.stayoff
The instant commands with wrong behaviour or which are completely failing are bad for me.... did plan to use shutdown.return to realize a clean restart of the whole system
Is there any way to further debug and find root cause for this, or is this a purely USB-firmware issue ?
Hello, and thanks for your report.
One thing that comes to mind is https://github.com/networkupstools/nut/wiki/CyberPower-Systems-(CPS)-know-how bit that shutdown times in CPS firmware are often discretely floored down to whole minutes - so a 30 sec setting becoming a 0 for instant shutdown seems to match. 300 sec becoming one minute does not, however, so maybe there's something else at play.
For debugging suggestions there's https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity and please do generally note that your NUT v2.7.4 is a pretty old release (8 years now) so it is possible the current code base behaves better. Can't remember of any changes specifically about shutdown times though, but at least troubleshooting friendliness should be better :)
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests suggests how you can build current NUT to test new driver binary from the build workspace, then maybe install over your package-delivered NUT if testing results are satisfactory.
Thanks for the answer.... i do use NUT on a RaspberryPi and simply did run "sudo apt install nut nut-client nut-server" I did more or less follow these funny & entertaining but very useful instructions: https://technotim.live/posts/NUT-server-guide/ which is obviously being updated often (currently few days ago). So i am totally surprised, when you are saying i am running on old and outdated stuff !!!
What did i do wrong, and how can i get newest versions ?????
(Have just right now checked... i am still seeing 2.7.4 as latest available version (using apt policy nut-server))
Probably you are using an older distro, or one with stricter policy about updating packages from the version they originally shipped (fair enough, new code may mean new bugs). In Debian land, you'd need "sid" or "unstable" for recent-ish packages; I think Debian 12 should have shipped with NUT 2.8.0 at least.
You did not mention an OS running on the Raspberry though, but usually it is a Debian or Ubuntu derivative. Building your own NUT from current codebase should be simple, per wiki. Or a bit more complex if you endeavour to find the configure arguments used by your exact OS/distro release' package recipes and so produce a perfect replacement :)
Also note that Raspberries popped up fairly often in the past few years of issues, mostly in regard to connection stability issues. Maybe this just reflects popularity of the platform (more uses => more reports), but maybe some flakiness in its hardware. Hearsay goes that USB stability on Pi3 was problematic, Pi4 fixed it, Pi5 may have other issues again.
Running this here:
pi@raspberrypi01:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Well, while i'm fairly able to walk my way through installing packages, configuring and using them, and while i was able to find my way through setting up iobroker, mysql, grafana, vis, and some pieces of python code, i simply struggle to find my way into details of NUT. And i am wondering why. It is not the first time that i am told i am using very old stuff (using WinNut-Client V2.2.8719.24624) but with using your links above i do not really find instructions for doing that, it seems as if i find my way into source-code repositories, and i am asked to build and compile the stuff i need myself. Am i looking in the wrong areas or is this the truth? I really would like to get NUT running, and i would really be happy to support this community with information about the new CP1600EPFCLCD from Cyberpower, but i am failing.
Yes, those links to Wiki above (and further into NUT docs) are about building NUT from source - some detail which prerequisite packages you need to install on this or that OS, others outline the steps needed for actual compilation, testing from the build workspace, and possibly installation over whatever your OS packages delivered previously.
That's the best balance we could come up with for getting people able to run NUT everywhere vs. tracking all the hundreds of distros it can run on (and many of those we've never heard about until mention on the issue tracker) and trying to package it for everything ourselves. Distro maintainers do a better job at that, but often according to some policy which balances their workload and codebase stability of packages. Some deliberately take code, say, at least 3 months or 1 previous release old, so as to avoid being first to discover some baby errors.
Need to correct my first statement.... about functionality of instant commands. I did test
beeper.disable - Disable the UPS beeper
beeper.enable - Enable the UPS beeper
load.off.delay 30 - Turn off the load with a delay (seconds)
load.on.delay 30 - Turn on the load with a delay (seconds)
load.on - Turn on the load immediately
and from that point on i did get
usbhid-ups[5347]: libusb_get_interrupt: error sending control message: Operation not permitted
usbhid-ups[5347]: libusb_get_interrupt: error sending control message: Broken pipe
usbhid-ups[5347]: libusb_get_interrupt: error sending control message: Broken pipe
usbhid-ups[5347]: libusb_get_interrupt: error sending control message: Broken pipe
in syslog.
So the tests results may be wrong. Definitely wrong is my statement about
shutdown.return - Turn off the load and return when power is back
which i tested while the error messages were running in.
Tested it yesterday again at it works as expected.
- If power is available, then the system switches off immediately and switches back on after approximately 6 sec.
- If power is gone, then the system switches off immediately, goes to sleep after few seconds, seems as if it also stops communications on USB. Then, with power back on, it switches on after approximately 6 sec.
Also using Pi4 on USB with same UPS. With NUT Version 2.8.0, have not tested all commands but also note
Output for "battery.mfr.date : CPS " is reporting incorrectly in 2.80 & version reported here, same output. Not critical.
Thanks for the report! If possible, please check with current NUT now that 2.8.3 is finally released - 2.8.0 is 3 years old already...