nut
nut copied to clipboard
networkupstools
Battery Runtime does not match the data from the UPS
The Battery Runtime data does not match the data from the APC UPS. This looks like some kind of variable limitation, since the upsc shows 65535, which is equal to 18 hours 12 minutes and 15 seconds. But in fact, the APC UPS shows the remaining time as 34 hours 1 min.
How can this be fixed?
upsc output:
root@ups:~# upsc internet@localhost
Init SSL without certificate database
battery.charge: 93
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2022/10/25
battery.runtime: 65535
battery.runtime.low: 1200
battery.temperature: 16.6
battery.type: PbAc
battery.voltage: 52.4
battery.voltage.nominal: 48.0
device.mfr: American Power Conversion
device.model: Smart-UPS 2200
device.serial: AS1250244567
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 10
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: APC HID 0.96
driver.version.internal: 0.41
input.sensitivity: medium
input.transfer.high: 253
input.transfer.low: 200
input.voltage: 0.0
output.current: 0.50
output.frequency: 50.0
output.voltage: 220.4
output.voltage.nominal: 220.0
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 654.19.I
ups.firmware.aux: 7.4
ups.load: 5.2
ups.mfr: American Power Conversion
ups.mfr.date: 2012/12/11
ups.model: Smart-UPS 2200
ups.productid: 0002
ups.serial: AS1250244567
ups.status: OB DISCHRG
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d
It does look like either max uint16 or a cast'ed "-1" int16, so indeed a likely limitation. Not at a computer now to investigate sources in more detail. Might even be a protocol limit if they post a 16-bit value in a report. In that case it might stay reported at 65535 sec until battery is depleted under the ~18 hours.
However if possible - please do try checking how current NUT (master or at least 2.8.0 release) behaves - there were quite a few fixes to usb support that could help or backfire...
Jim
On Fri, Dec 23, 2022, 16:55 man55 @.***> wrote:
The Battery Runtime data does not match the data from the APC UPS. This looks like some kind of variable limitation, since the upsc shows 65535, which is equal to 18 hours 12 minutes and 15 seconds. But in fact, the APC UPS shows the remaining time as 34 hours 1 min.
How can this be fixed?
upsc output:
@.:~# upsc @. Init SSL without certificate database battery.charge: 93 battery.charge.low: 10 battery.charge.warning: 50 battery.mfr.date: 2022/10/25 battery.runtime: 65535 battery.runtime.low: 1200 battery.temperature: 16.6 battery.type: PbAc battery.voltage: 52.4 battery.voltage.nominal: 48.0 device.mfr: American Power Conversion device.model: Smart-UPS 2200 device.serial: AS1250244567 device.type: upsdriver.name: usbhid-ups driver.parameter.pollfreq: 10 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.data: APC HID 0.96 driver.version.internal: 0.41 input.sensitivity: medium input.transfer.high: 253 input.transfer.low: 200 input.voltage: 0.0 output.current: 0.50 output.frequency: 50.0 output.voltage: 220.4 output.voltage.nominal: 220.0 ups.beeper.status: disabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.firmware: 654.19.I ups.firmware.aux: 7.4 ups.load: 5.2 ups.mfr: American Power Conversion ups.mfr.date: 2012/12/11 ups.model: Smart-UPS 2200 ups.productid: 0002 ups.serial: AS1250244567 ups.status: OB DISCHRG ups.test.result: No test initiated ups.timer.reboot: -1 ups.timer.shutdown: -1 ups.timer.start: -1 ups.vendorid: 051d
[image: Screenshot 2022-12-23 174738] https://user-images.githubusercontent.com/30772900/209363376-e90987d4-2ff8-4cdb-979a-8ea4e73ec9d7.png [image: Screenshot 2022-12-23 174707] https://user-images.githubusercontent.com/30772900/209363404-fc3cd06a-7088-4528-a361-64fb49765ede.png
— Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/1740, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFACREDLWQ2MCYLQDLTWOXDOPANCNFSM6AAAAAATH376LI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks for the quick response. I'm sorry, but I don't know how to update it. I installed with apt-get install nut nut-snmp on my raspberry pi 3. I don't see any updates right now.
root@ups:~# apt -V -s install nut
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
nut is already the newest version (2.7.4-13).
For a test, NUT is easy to build and run in-place to see how your device fares. Building a replacement for your package, if it does fare better, may be a bit more complicated - find distro recipes and their configure arguments.
FWIW NUT 2.8.0 is out for more than half a year, apparently distros need time to move forward...
Too complicated for me and nothing is clear. Couldn't find anything on google search. Need step by step instructions. I am not a programmer and not a sysadmin ( Thanks
Never late to become one ;)
I've posted the instructions a few times in the past year, should be in issues. Now in mountains, can't type another on phone.
Try the older and maybe easier overvoew at https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu
I should clarify that another UPS APC SUA1000 connected via snmp v1 and does not have this problem, Battery Runtime matches on UPS and NUT monitoring and equals 70680.00
root@ups:~# upsc kotel@localhost
Init SSL without certificate database
ambient.1.humidity.alarm.high: 89.00
ambient.1.humidity.alarm.low: 11.00
ambient.1.temperature.alarm.high: 59.00
ambient.1.temperature.alarm.low: 1.00
battery.charge: 93.00
battery.charge.restart: 0
battery.current: 0.00
battery.date: 12/01/22
battery.packs: 4.00
battery.packs.bad: -1.00
battery.runtime: 70680.00
battery.runtime.low: 120
battery.voltage: 25.60
battery.voltage.nominal: -1.00
device.mfr: APC
device.model: Smart-UPS 1000
device.serial: AS0802331853
device.type: ups
driver.name: snmp-ups
driver.parameter.pollfreq: 20
driver.parameter.pollinterval: 2
driver.parameter.port: 192.168.1.51
driver.parameter.snmp_retries: 10
driver.parameter.snmp_timeout: 5
driver.parameter.snmp_version: v1
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: apcc MIB 1.2
driver.version.internal: 0.97
input.frequency: 50.00
input.sensitivity: medium
input.transfer.high: 253
input.transfer.low: 200
input.transfer.reason: rateOfVoltageChange
input.voltage: 0.00
input.voltage.maximum: 0.00
input.voltage.minimum: 0.00
output.current: 0.40
output.frequency: 50.00
output.voltage: 220.40
output.voltage.nominal: 220
ups.delay.shutdown: 0
ups.delay.start: 0
ups.firmware: 652.18.I
ups.id: kotel
ups.load: 16.90
ups.mfr: APC
ups.mfr.date: 01/12/08
ups.model: Smart-UPS 1000
ups.serial: AS0802331853
ups.status: OB
ups.temperature: 33.30
ups.test.date: 12/11/2022
ups.test.result: Ok
Thanks for this data point - so at least not a limitation in NUT data structures. Might still be one in USB-HID protocols or APC's implementation (known buggy in certain other cases - some addressed for NUT v2.8.0 release and later codebase).
Never late to become one ;)
I've posted the instructions a few times in the past year, should be in issues. Now in mountains, can't type another on phone.
Try the older and maybe easier overvoew at https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu
I can't do anything. I did everything as per the link and the NUT broke completely. The driver was not updated and still showed the old version, but the UPS could no longer be found.
I re-formatted the SD card, then installed NUT from github according to the instructions in the link, everything compiled without errors, but something went wrong again. The system does not find the executable files, and the driver service cannot be restarted because it was not found either.
root@ups2:~# systemctl restart nut-driver.service
Failed to restart nut-driver.service: Unit nut-driver.service not found.
root@ups2:~# upsc
-bash: upsc: command not found
I can do something like this, that is, the files are in place .. but I don’t understand how to make NUT work.
root@ups2:~# /usr/local/ups/bin/upsc holodilnik@localhost
Error: Connection failure: Connection refused
That's odd - instructions had lots of paths in configure script arguments, so /usr/local/ups/... should not have happened.
That's odd - instructions had lots of paths in
configurescript arguments, so/usr/local/ups/...should not have happened.
After running the configuration, I see paths like this at the end:
there is /usr/local/ups/ And if I try to run the driver manually, I get a different path error:
root@ups:~# /usr/local/ups/sbin/upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0-Windows-239-g703788500
Network UPS Tools - Generic HID driver 0.49 (2.8.0-Windows-239-g703788500)
USB communication driver (libusb 0.1) 0.43
Can't chdir to /var/run/nut: No such file or directory
Driver failed to start (exit status=1)
I can't figure out what are the problems with the paths.
I've googled everything I can and all the instructions boil down to "apt-get install nut" (( Nobody compiles this on their own?
OK, I have create nut dir manualy (/var/run/nut), now got new error:
root@ups:~# /usr/local/ups/bin/nut-scanner - scan
Cannot load USB library (/usr/lib/arm-linux-gnueabihf/libusb.so) : file not found. USB search disabled.
No start IP, skipping SNMP
Scanning XML/HTTP bus.
No start IP, skipping NUT bus (old connect method)
Scanning IPMI bus.
but libusb.so is in place. hm....
So, i don't know why the nut-scanner is not working, but in general i got NUT to work. Everything turned out as usual, it refused to start automatically after a reboot, and I had to add the following lines to the /etc/rc.local
sleep 5
systemctl restart nut-server.service
sleep 3
/usr/local/ups/sbin/upsdrvctl start
Curious - is /usr/lib/arm-linux-gnueabihf/libusb.so exist named exactly so? Probably is a symlink to currently-default library version - does this link actually lead to an existing filename?
Thanks for the note about /usr/local/ups - that Wiki article apparently lacks a --prefix=/usr configure option.
Per other nuances, it may have been better relevant to older NUT releases that did not have advanced modern-OS integration out of the box. Primary docs are the hordes of text files in the source which try to march along with codebase changes.
As for /var/run/nut - it is in tmpfs and either old init-scripts or new systemd integration should normally create it (e.g. as a systemd-tmpfiles action) before starting the daemon units. I suppose complete packaging (post-install scripts) do this, as well as a reboot does it, but indeed a manual step may be needed to build and install from source.
I am surprised that the services did not start - NUT systemd unit files (services, targets and possibly paths) should have got installed - but maybe were not "enabled" effectively to create symlinks from under run-time /etc/systemd/... locations to cause auto-start-up (again, something that packaging normally does, and probably something I just did locally without a hind-thought). Since the 2.8.0 release there is a nut-driver-enumerator (script and units) that take care of automatic enablement and registration of NUT units, including service instances for each driver based on content of ups.conf and its changes (so there is less of a role for direct upsdrvctl).
Curious - is
/usr/lib/arm-linux-gnueabihf/libusb.soexist named exactly so? Probably is a symlink to currently-default library version - does this link actually lead to an existing filename?
As I see it, yes.
Since the 2.8.0 release there is a
nut-driver-enumerator(script and units) that take care of automatic enablement and registration of NUT units, including service instances for each driver based on content ofups.confand its changes (so there is less of a role for directupsdrvctl
root@ups:~# /usr/lib/nut/nut-driver-enumerator.sh --list-devices
=== The currently defined configurations in '/etc/nut/ups.conf' are:
holodilnik
root@ups:~# /usr/lib/nut/nut-driver-enumerator.sh --list-instances
Error reading the list of systemd service instances for UPS drivers, or none are defined - by user request
No service instances detected
root@ups:~# /usr/lib/nut/nut-driver-enumerator.sh
Error reading the list of systemd service instances for UPS drivers, or none are defined - before manipulations
Mon 2 Jan 10:49:38 UTC 2023 : Detected changes in global section of '/etc/nut/ups.conf', will restart all drivers
OK
Adding new systemd service instance for power device [holodilnik]...
Created symlink /etc/systemd/system/nut-driver.target.wants/[email protected] → /lib/systemd/system/[email protected].
Enabled instance: 'nut-driver@holodilnik' for NUT configuration section 'holodilnik'
Adding 'Wants'+After dependency for 'holodilnik' on 'systemd-udev.service systemd-udev-settle.service'...
OK
OK
Started instance: 'nut-driver@holodilnik' for NUT configuration section 'holodilnik'
=== The currently defined service instances are:
holodilnik
=== The currently defined configurations in '/etc/nut/ups.conf' are:
holodilnik
Restarting NUT data server to make sure it knows new configuration...
Mon 2 Jan 10:49:41 UTC 2023 : OK: No more changes to reconcile between systemd service instances and device configurations in '/etc/nut/ups.conf'
root@ups:~#
root@ups:~# /usr/lib/nut/nut-driver-enumerator.sh --list-instances
=== The currently defined service instances are:
holodilnik
But after reboot again
root@ups:~# /usr/lib/nut/nut-driver-enumerator.sh --list-instances
Error reading the list of systemd service instances for UPS drivers, or none are defined - by user request
No service instances detected
I needed to restart the nut-server.service manually and it worked. So I left the systemctl restart nut-server.service command in the /etc/rc.local. Works fine.
And I found out about the main problem of the topic - [Battery Runtime does not match the data from the UPS].
Nothing has changed in the new version. But I connected another APC UPS via USB and made sure that there is no limitation on battery runtime. Only on this APC SUA2200 there is such a limitation, but only when connected via USB, when it was connected via snmp, the runtime was displayed in full, but there was a problem with the correct display of other statuses.
I do not see the status "charging" on all the ups connected via snmp, instead the status "online" is visible.
We have several reports of such situation, often linked with Eaton branded or OEM USB-capable devices.
My guess is that there may be vendor-extension USB HID data points, but our drivers only look into a standard one that maxes out at 16 bits (and/or reports a -1 as error that it overflowed, or that the load is too small and any runtime guess is almost random)?
CC @arnaudquette-eaton @masterwishx
Here's a saved search for opened and closed issues that mention "65535" generally; got ~50 hits and some are about this situation: https://github.com/networkupstools/nut/issues?q=is%3Aissue+65535
Cross-linking to #731
We have several reports of such situation, often linked with Eaton branded or OEM USB-capable devices. My guess is that there may be vendor-extension USB HID data points, but our drivers only look into a standard one that maxes out at 16 bits (and/or reports a
-1as error that it overflowed, or that the load is too small and any runtime guess is almost random)? CC @arnaudquette-eaton @masterwishxHere's a saved search for opened and closed issues that mention "65535" generally; got ~50 hits and some are about this situation: https://github.com/networkupstools/nut/issues?q=is%3Aissue+65535
Cross-linking to #731
On Eaton 9E I have no problem with the time left, battery.runtime= 3834 =01:03:54 for now.
But seems I have same ups.status= OL instead of OL+CHRG when charging also. Needs more code investigate for statuses in usbhid-ups.c
