-
Hi, I'm running a Cyberpower UPS, and getting random email notifications saying LOWBATT, I have NUT running as the master on my pfsense box, with the UPS connected directly via USB. I'm sitting at 100% battery charged and UPS load around 65%. I verified this is reported from the actual LCD screen on the UPS, and uspsc command. Why is NUT thinking the BATT is low, when its not even on BATT, and its reporting 100% charged?
-
Do you have confidence in the USB chipset on the mother board? Is it a recent MB? I don't see it's identification in the usb dump. It's not an external hub is it?
Also, how old is the UPS? If it's not recent, have you tried the tripplite driver?I do not have confidence in the USB chipset the box is a Leonovo M90 3246-A2U from 2010 and I was able to find it uses Platform Controller Hub (PCH) for PCI, ethernet and USB. I've also switched between the USB 2 and USB 3 ports, different cables. I can only get usbconfig to show TRIPP LITE UPS Tripp Lite.
No external USB hub (eww)
I just purchased the UPS July 2017
I do plan to get new hardware in the next year or possibly sooner, I dont know if it would be worth it to try and get a PCI\PCIe usb card with a better chipset.
-
Hi, I'm running a Cyberpower UPS, and getting random email notifications saying LOWBATT
I've had a couple of Cyberpowers. I found them to be a bit flakey, particularly when the battery needs replacing. It could be happening when the unit does its short self test. I would perform a self test, followed by a runtime calibration to check the battery.
-
I do not have confidence in the USB chipset the box is a Leonovo M90 3246-A2U from 2010 and I was able to find it uses Platform Controller Hub (PCH) for PCI, ethernet and USB. I've also switched between the USB 2 and USB 3 ports, different cables. I can only get usbconfig to show TRIPP LITE UPS Tripp Lite.
No external USB hub (eww)
Normally I would recommend against an external hub, but in this case it's worth a try to test with an external (powered) hub because it will be a different bridge chip.
-
Normally I would recommend against an external hub, but in this case it's worth a try to test with an external (powered) hub because it will be a different bridge chip.
Thanks, is there a certain bridge chip manufacture I should try or avoid ?
-
Thanks, is there a certain bridge chip manufacture I should try or avoid ?
Sorry, I'm not knowledgeable enough to make a recommendation.
-
I do not have confidence in the USB chipset the box is a Leonovo M90 3246-A2U from 2010 and I was able to find it uses Platform Controller Hub (PCH) for PCI, ethernet and USB. I've also switched between the USB 2 and USB 3 ports, different cables. I can only get usbconfig to show TRIPP LITE UPS Tripp Lite.
No external USB hub (eww)
Normally I would recommend against an external hub, but in this case it's worth a try to test with an external (powered) hub because it will be a different bridge chip.
I'm trying to figure out how to do this? Its connected directly to pfSense with just NUT. Is there a upsc command to imitate a selftest? The units not even a year old =(
-
You use "upscmd" to do self tests and the like. A list of the potential commands is available here.
This command
upscmd -l <upsname>will provide a list of available commands for the specific UPS.</upsname>
-
So i ran a deep battery test, and it passes every time. Is there anything diagnostic wise i could do to see what's going on at the time it reports LOWBATT, because as far as i can tell its never low. This just started happening after I upgraded pfSense to the latest version 2.4.4, If i remember, i was on 2.3.2. Something has changed in the way pfsense is handling this across these versions.
-
This just started happening after I upgraded pfSense to the latest version 2.4.4, If i remember, i was on 2.3.2. Something has changed in the way pfsense is handling this across these versions.
Can you clarify the version information please? The latest version of pfSense is 2.3.4. Version 2.4 of pfSense is still in development (beta). The latest version of the nut package is 2.7.4_4, which uses underlying nut version 2.7.4_1. Thanks.
Btw, unless you were previously running pfSense 2.2.X or below, I'm guessing that the "something changed with nut" may be coincidental. This stuff hasn't changed much in the last year. The underlying release of nut for pfSense, version 2.7.4, was introduced in pfSense 2.3.0. The current generation of the nut package, version 2.7.4, was introduced shortly thereafter. Note that the prior generation nut package, 2.3.X, didn't have the ability to send email notifications so you would have only noticed LOWBATT messages if you scanned the system log.
-
This just started happening after I upgraded pfSense to the latest version 2.4.4, If i remember, i was on 2.3.2. Something has changed in the way pfsense is handling this across these versions.
Can you clarify the version information please? The latest version of pfSense is 2.3.4. Version 2.4 of pfSense is still in development (beta). The latest version of the nut package is 2.7.4_4, which uses underlying nut version 2.7.4_1. Thanks.
Btw, unless you were previously running pfSense 2.2.X or below, I'm guessing that the "something changed with nut" may be coincidental. This stuff hasn't changed much in the last year. The underlying release of nut for pfSense, version 2.7.4, was introduced in pfSense 2.3.0. The current generation of the nut package, version 2.7.4, was introduced shortly thereafter. Note that the prior generation nut package, 2.3.X, didn't have the ability to send email notifications so you would have only noticed LOWBATT messages if you scanned the system log.
Ok sorry, let me clear that up, I'm on the latest version now of 2.3.4. Previously on 2.3.2, never had a single LOWBATT alert. Back checked email, July 9th I upgrade to 2.3.4, alerts start rolling in since, randomly. Is something polling differently now?
-
Btw, unless you were previously running pfSense 2.2.X or below, I'm guessing that the "something changed with nut" may be coincidental. This stuff hasn't changed much in the last year. The underlying release of nut for pfSense, version 2.7.4, was introduced in pfSense 2.3.0. The current generation of the nut package, version 2.7.4, was introduced shortly thereafter. Note that the prior generation nut package, 2.3.X, didn't have the ability to send email notifications so you would have only noticed LOWBATT messages if you scanned the system log.
Ok sorry, let me clear that up, I'm on the latest version now of 2.3.4. Previously on 2.3.2, never had a single LOWBATT alert. Back checked email, July 9th I upgrade to 2.3.4, alerts start rolling in since, randomly. Is something polling differently now?
The only scenario I can think of would be having an earlier version of pfSense and the nut package installed, then installing 2.3.2 and not reinstalling the packages until the upgrade to 2.3.4.
If this was the case, there would have been two changes. First would have been the underlying nut version going from 2.7.3 to 2.7.4. Second would have been the nut package going from 2.3.X to 2.7.4. If this happened, it should have been pretty obvious because the nut package would have put up a banner about settings migration and forced the migrated settings to be explicitly saved before it would start. Nut email notifications are also off by default, so at some point they had to be explicitly enabled as well.
For nut, the release notes are here. Nothing in particular jumps out at me, but I'm not a nut developer. For the nut package, there hasn't been much since the introduction of 2.7.4, which is when the ability to configure email was introduced. Overall, my best guess is that the LOWBATT thing has been happening all along and it wasn't noticed in the system logs until email notifications were enabled because it didn't impair operation.
So I guess the key questions to think about are: Was there a nut configuration migration performed? If so, when? And when were email notifications enabled?
-
Btw, unless you were previously running pfSense 2.2.X or below, I'm guessing that the "something changed with nut" may be coincidental. This stuff hasn't changed much in the last year. The underlying release of nut for pfSense, version 2.7.4, was introduced in pfSense 2.3.0. The current generation of the nut package, version 2.7.4, was introduced shortly thereafter. Note that the prior generation nut package, 2.3.X, didn't have the ability to send email notifications so you would have only noticed LOWBATT messages if you scanned the system log.
Ok sorry, let me clear that up, I'm on the latest version now of 2.3.4. Previously on 2.3.2, never had a single LOWBATT alert. Back checked email, July 9th I upgrade to 2.3.4, alerts start rolling in since, randomly. Is something polling differently now?
The only scenario I can think of would be having an earlier version of pfSense and the nut package installed, then installing 2.3.2 and not reinstalling the packages until the upgrade to 2.3.4.
If this was the case, there would have been two changes. First would have been the underlying nut version going from 2.7.3 to 2.7.4. Second would have been the nut package going from 2.3.X to 2.7.4. If this happened, it should have been pretty obvious because the nut package would have put up a banner about settings migration and forced the migrated settings to be explicitly saved before it would start. Nut email notifications are also off by default, so at some point they had to be explicitly enabled as well.
For nut, the release notes are here. Nothing in particular jumps out at me, but I'm not a nut developer. For the nut package, there hasn't been much since the introduction of 2.7.4, which is when the ability to configure email was introduced. Overall, my best guess is that the LOWBATT thing has been happening all along and it wasn't noticed in the system logs until email notifications were enabled because it didn't impair operation.
So I guess the key questions to think about are: Was there a nut configuration migration performed? If so, when? And when were email notifications enabled?
Email notifications have been on all along, I'd get OL and OB notifications during switches, but never random LOWBATTs until after the upgrade, nut package has been on 2.7.4. I just don't see why its sending LOWBATT, when it never comes off 100%, LOWBATT shouldn't even come out until past 70% or so and if it was actually discharging, it sure wouldn't come back to 100% that quick. I'm going to try moving NUT master servers and see if it continues, before trying a rollback as another experiment.
-
Do you have another UPS to test with by chance?
-
Email notifications have been on all along, I'd get OL and OB notifications during switches, but never random LOWBATTs until after the upgrade, nut package has been on 2.7.4. I just don't see why its sending LOWBATT, when it never comes off 100%, LOWBATT shouldn't even come out until past 70% or so and if it was actually discharging, it sure wouldn't come back to 100% that quick.
Okay, so no changes in the nut version or the nut package. Presuming the same UPS the entire time.
Just for completeness, can you post output from the following two commands?
upsc <upsname>upsrw <upsname>Thanks</upsname></upsname>
-
Email notifications have been on all along, I'd get OL and OB notifications during switches, but never random LOWBATTs until after the upgrade, nut package has been on 2.7.4. I just don't see why its sending LOWBATT, when it never comes off 100%, LOWBATT shouldn't even come out until past 70% or so and if it was actually discharging, it sure wouldn't come back to 100% that quick.
Okay, so no changes in the nut version or the nut package. Presuming the same UPS the entire time.
Just for completeness, can you post output from the following two commands?
upsc <upsname>upsrw <upsname>Thanks</upsname></upsname>
battery.charge: 100
battery.charge.low: 50
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 960
battery.runtime.low: 600
battery.type: PbAcid
battery.voltage: 24.0
battery.voltage.nominal: 24
device.mfr: CPS
device.model: OR1500PFCRT2U
device.type: ups
driver.flag.ignorelb: enabled
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ugen0.6
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.transfer.high: 139
input.transfer.low: 88
input.voltage: 118.0
input.voltage.nominal: 120
output.voltage: 118.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 58
ups.mfr: CPS
ups.model: OR1500PFCRT2U
ups.productid: 0601
ups.realpower.nominal: 900
ups.status: OL
ups.test.result: Done and passed
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764[input.transfer.high]
High voltage transfer point (V)
Type: STRING
Maximum length: 10
Value: 139[input.transfer.low]
Low voltage transfer point (V)
Type: STRING
Maximum length: 10
Value: 88[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 -
battery.charge.low: 50
battery.charge.warning: 20I didn't look at all the variables, but this one is an issue: battery.charge.warning should be higher than battery.charge.low.
What is being set in the Extra Arguments to driver section? Anything in the Advanced section?
-
battery.charge.low: 50
battery.charge.warning: 20I didn't look at all the variables, but this one is an issue: battery.charge.warning should be higher than battery.charge.low.
What is being set in the Extra Arguments to driver section? Anything in the Advanced section?
Driver Extra Args:
port = /dev/ugen0.6
ignorelb
override.battery.charge.low = 50
override.battery.runtime.low = 600upsmon.conf
RUN_AS_USER root
upsd.conf
LISTEN 10.10.0.1
upsd.users
[monitor]
password = *************
upsmon slave -
Hello,
Is it possible to have the NUT daemon monitor and manage two UPSes?
I have a CyberPower1500 and a CyberPower1350 in my set-up and the pfSense firewall is the only bare-metal box (everything else is an ESXi server). I want to have each of the other systems query the NUT daemon on the pfSense for the status of the UPS that host is connected to. (the UPSes are on different circuits so there are scenarios where one goes down but not both)
What I don't know is how to set these configurations. I see there are a number of advanced options in the UI, I'm a little lost as to where to start. Has anyone done this before? I'd like to do it via the pfSense UI so my configs will survive upgrades and reinstalls, rather than being hidden down in config files.
To make this work I figure I need to pass options for additional configurations here so that the port of each UPS is listed explicitly:
[2.3.4-RELEASE][admin@pfsense.thirtynineohsix]/root: cat /usr/local/etc/nut/ups.conf [CyberPower1500] driver=usbhid-ups port=auto…and here so that each UPS has an explicit TCP port for communication with the remote servers.:
[2.3.4-RELEASE][admin@pfsense.thirtynineohsix]/root: cat /usr/local/etc/nut/upsd.conf LISTEN 127.0.0.1 LISTEN ::1… I'm really not sure what I need to do or what will happen automatically here:
[2.3.4-RELEASE][admin@pfsense.thirtynineohsix]/root: cat /usr/local/etc/nut/upsmon.conf MONITOR CyberPower1500 1 monuser f0e07165bec481f09a93 master SHUTDOWNCMD "/sbin/shutdown -p +0" POWERDOWNFLAG /etc/killpower NOTIFYCMD /usr/local/pkg/nut/nut_email.php NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC NOTIFYFLAG NOPARENT SYSLOG+WALL+EXECHere's the USB information .. the difference I can see is the "ugen1.[2|3]" but everything else is the same? How do I identify/label the port?
[2.3.4-RELEASE][admin@pfsense.thirtynineohsix]/root: usbconfig dump_device_desc ugen0.1: <uhci root="" hub="" intel="">at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) [ details from four root hubs elided ] ugen1.2: <cp 1500c="" cps="">at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (50mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 <probed by="" interface="" class="">bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x0764 idProduct = 0x0501 bcdDevice = 0x0001 iManufacturer = 0x0003 <cps>iProduct = 0x0001 < CP 1500C> iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001 ugen1.3: <cp 1350c="" cps="">at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (50mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 <probed by="" interface="" class="">bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x0764 idProduct = 0x0501 bcdDevice = 0x0001 iManufacturer = 0x0003 <cps>iProduct = 0x0001 < CP 1350C> iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001</no></cps></probed></cp></no></cps></probed></cp></uhci>I'm okay if only one shows up in the UPS widget, it's more important that the respective machines know how to validate their power source.
Thanks for any insights …
--jg3
-
Driver Extra Args:
port = /dev/ugen0.6
ignorelb
override.battery.charge.low = 50
override.battery.runtime.low = 600The ups is at 58% load, or approximately 610 watts. Expected runtime of 14-15 min according to Cyber. So the shutdown should be triggered approximately 5 min after mains go offline.
One of the notes in the nut documentation on ignorelb is that some UPSs generate a LB indication almost immediately after loss of mains. In the context of general Cyberpower flakiness, I can see this happening either from loss of mains, high/low transfer, or maybe even a UPS initiated self test. Even though it would not initiate a shutdown with your configuration, nut would still generate a notification if the UPS sent a LB alert. Is it possible this is happening?
In terms of timing, did the load level change around the time of the upgrade? Or Driver Extra arguments?
