NUT package (2.8.0 and below)

Mr. Jingles · Jun 23, 2017, 8:26 PM

@Mr.:

Although you asked Gertjan this question, it triggered me, and yes, I had bonding on the Synology. I deleted the bond, and I think the problem is gone. I am looking, but sofar no more emails about connection lost and established.

Yep, I addressed the wrong person. Sorry about that.

Anyway, it makes sense. You have a disagreement between the link aggregation group configuration on the Synology and the switch.

The benefit of understanding networking. Thank you for your message :-*

Mr. Jingles · Jun 23, 2017, 9:59 PM

Too good to be true: I just got two :-[

[quote]
Fri, 23 Jun 2017 23:33:30 +0200
Communications with UPS lost

Fri, 23 Jun 2017 23:33:35 +0200
Communications with UPS established

dennypage · Jun 23, 2017, 11:51 PM

Suggest that you disable all lag/bonding for both pfSense and the Synology (don't forget to disable lag/lacp on the switch ports) and disconnect all but one cable to each system. Then check ping in both directions and confirm that there is no loss.

f34rinc · Jul 15, 2017, 5:17 AM

Hello, I have a Tripp Lite Smart1500LCDT that I'm trying to use with NUT. I have seen NUT connect to the UPS briefly a handful of times and will cycle between online \ offline.

I have tried using the usbhid driver without any extra arguments and with settings found http://networkupstools.org/ddl/Tripp_Lite/SMART1500LCDT.html

[2.3.4-RELEASE][root@pfSense]/root:  cat /usr/local/etc/nut/ups.conf
user=root
[SMART1500LCDT]
driver=usbhid-ups
port=auto
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 30
battery.runtime:  10800
battery.type:  PbAC
battery.voltage: 0.0
battery.voltage.nominal: 24.0
device.mfr:  Tripp Lite
device.model:  TRIPP LITE UPS
device.type:  ups
driver.name:  usbhid-ups
driver.parameter.pollfreq:  30
driver.parameter.pollinterval:  2
driver.parameter.port:  auto
driver.parameter.productid: 3016
driver.version: 2.6.3
driver.version.data: TrippLite HID 0.6
driver.version.internal: 0.35
input.frequency: 5990.0
input.transfer.high: 150.0
input.transfer.low: 92.0
input.voltage: 0.0
input.voltage.nominal: 120
output.current: 0.00
output.frequency: 5990.0
output.frequency.nominal: 60
output.voltage: 0.0
output.voltage.nominal: 120
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 0
ups.mfr: Tripp Lite
ups.model: TRIPP LITE UPS
ups.power: 0.0
ups.power.nominal: 1500
ups.productid: 3016
ups.status: OL
ups.timer.reboot: 65535
ups.timer.shutdown: 65535
ups.timer.start: 65535
ups.vendorid: 09ae
ups.watchdog.status: 0
#CMD:beeper.disable
#CMD:beeper.enable
#CMD:beeper.mute
#CMD:beeper.off
#CMD:beeper.on
#CMD:load.off
#CMD:load.off.delay
#CMD:load.on
#CMD:load.on.delay
#CMD:reset.watchdog
#CMD:shutdown.reboot
#CMD:shutdown.return
#CMD:shutdown.stayoff
#CMD:shutdown.stop
#RW:battery.charge.low:STRING
#RW:input.transfer.high:STRING
#RW:input.transfer.low:STRING
#RW:ups.delay.shutdown:STRING
#RW:ups.delay.start:STRING

[2.3.4-RELEASE][root@pfSense]/root: cat /usr/local/etc/nut/upsd.conf
LISTEN 127.0.0.1
LISTEN ::1

[2.3.4-RELEASE][root@pfSense]/root: cat /usr/local/etc/nut/upsmon.conf
MONITOR SMART1500LCDT 1 monuser 3b3e3a783e68ff21be0b master
SHUTDOWNCMD "/sbin/shutdown -p +0"
POWERDOWNFLAG /etc/killpower

[2.3.4-RELEASE][root@pfsense]/root: usbconfig dump_device_desc
ugen0.1: <ehci root="" hub="" intel="">at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0009  <hub>bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0001
  bMaxPacketSize0 = 0x0040
  idVendor = 0x0000
  idProduct = 0x0000
  bcdDevice = 0x0100
  iManufacturer = 0x0001  <intel>iProduct = 0x0002  <ehci root="" hub="">iSerialNumber = 0x0000  <no string="">bNumConfigurations = 0x0001

ugen1.1: <ehci root="" hub="" intel="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0009  <hub>bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0001
  bMaxPacketSize0 = 0x0040
  idVendor = 0x0000
  idProduct = 0x0000
  bcdDevice = 0x0100
  iManufacturer = 0x0001  <intel>iProduct = 0x0002  <ehci root="" hub="">iSerialNumber = 0x0000  <no string="">bNumConfigurations = 0x0001

ugen0.2: <product 0x0020="" vendor="" 0x8087="">at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0009  <hub>bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0001
  bMaxPacketSize0 = 0x0040
  idVendor = 0x8087
  idProduct = 0x0020
  bcdDevice = 0x0000
  iManufacturer = 0x0000  <no string="">iProduct = 0x0000  <no string="">iSerialNumber = 0x0000  <no string="">bNumConfigurations = 0x0001

ugen1.2: <product 0x0020="" vendor="" 0x8087="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0009  <hub>bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0001
  bMaxPacketSize0 = 0x0040
  idVendor = 0x8087
  idProduct = 0x0020
  bcdDevice = 0x0000
  iManufacturer = 0x0000  <no string="">iProduct = 0x0000  <no string="">iSerialNumber = 0x0000  <no string="">bNumConfigurations = 0x0001

ugen1.3: <tripp lite="" ups="" tripp="">at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0110
  bDeviceClass = 0x0000  <probed by="" interface="" class="">bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0008
  idVendor = 0x09ae
  idProduct = 0x3016
  bcdDevice = 0x0002
  iManufacturer = 0x0003  <tripp lite="">iProduct = 0x0001  <tripp lite="" ups="">iSerialNumber = 0x0005  <retrieving string="" failed="">bNumConfigurations = 0x0001</retrieving></tripp></tripp></probed></tripp></no></no></no></hub></product></no></no></no></hub></product></no></ehci></intel></hub></ehci></no></ehci></intel></hub></ehci>

[2.3.4-RELEASE][root@pfsense]/root: service devd restart
Stopping devd.
Waiting for PIDS: 9885.
Starting devd.
[2.3.4-RELEASE][root@pfsense]/root: /usr/local/etc/rc.d/nut.sh restart
stopping NUT
starting NUT
Network UPS Tools upsmon 2.7.4
kill: No such process
UPS: SMART1500LCDT (master) (power value 1)
Using power down flag file /etc/killpower
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Network UPS Tools upsd 2.7.4
fopen /var/db/nut/upsd.pid: No such file or directory
listening on ::1 port 3493
listening on 127.0.0.1 port 3493
Can't connect to UPS [SMART1500LCDT] (usbhid-ups-SMART1500LCDT): No such file or directory

Broadcast Message from root@pfsense
        (no tty) at 0:56 EDT...

Communications with UPS SMART1500LCDT lost

No matching HID UPS found
Driver failed to start (exit status=1)

Broadcast Message from root@pfsense
        (no tty) at 0:56 EDT...

UPS SMART1500LCDT is unavailable

Jul 15 00:57:28 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:57:23 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:57:18 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:57:13 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:57:08 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:57:03 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:58 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:53 	upsmon 	13730 	UPS SMART1500LCDT is unavailable
Jul 15 00:56:53 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:48 	upsmon 	13730 	Communications with UPS SMART1500LCDT lost
Jul 15 00:56:48 	upsmon 	13730 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:48 	upsd 	14571 	User monuser@::1 logged into UPS [SMART1500LCDT]
Jul 15 00:56:46 	upsd 	14571 	Startup successful
Jul 15 00:56:46 	upsd 	14312 	Can't connect to UPS [SMART1500LCDT] (usbhid-ups-SMART1500LCDT): No such file or directory
Jul 15 00:56:46 	upsd 	14312 	listening on 127.0.0.1 port 3493
Jul 15 00:56:46 	upsd 	14312 	listening on ::1 port 3493
Jul 15 00:56:45 	upsmon 	13178 	Startup successful
Jul 15 00:56:45 	upsd 	76083 	Signal 15: exiting
Jul 15 00:56:45 	upsd 	76083 	mainloop: Interrupted system call
Jul 15 00:56:45 	upsd 	76083 	User monuser@::1 logged out from UPS [SMART1500LCDT]
Jul 15 00:56:45 	upsmon 	75446 	Signal 15: exiting
Jul 15 00:56:45 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:40 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:35 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:30 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:25 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:20 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:15 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:10 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:05 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:56:00 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:55 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:50 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:45 	upsmon 	75446 	UPS SMART1500LCDT is unavailable
Jul 15 00:55:45 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:40 	upsmon 	75446 	Communications with UPS SMART1500LCDT lost
Jul 15 00:55:40 	upsmon 	75446 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:40 	upsd 	76083 	User monuser@::1 logged into UPS [SMART1500LCDT]
Jul 15 00:55:38 	upsd 	76083 	Startup successful
Jul 15 00:55:38 	upsd 	75783 	Can't connect to UPS [SMART1500LCDT] (usbhid-ups-SMART1500LCDT): No such file or directory
Jul 15 00:55:38 	upsd 	75783 	listening on 127.0.0.1 port 3493
Jul 15 00:55:38 	upsd 	75783 	listening on ::1 port 3493
Jul 15 00:55:37 	upsmon 	74829 	Startup successful
Jul 15 00:55:35 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:30 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:25 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:19 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:14 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:13 	kernel 		device_attach: uhid0 attach returned 12
Jul 15 00:55:13 	kernel 		uhid0: no report descriptor
Jul 15 00:55:09 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:55:08 	kernel 		uhid0: <tripp 0="" 3="" lite="" tripp="" ups,="" class="" 0,="" rev="" 1.10="" 0.02,="" addr="">on usbus1
Jul 15 00:55:04 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:54:59 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:54:54 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected
Jul 15 00:54:49 	upsmon 	4012 	Poll UPS [SMART1500LCDT] failed - Driver not connected</tripp>

dennypage · Jul 15, 2017, 7:10 AM

@f34rinc:

Hello, I have a Tripp Lite Smart1500LCDT that I'm trying to use with NUT. I have seen NUT connect to the UPS briefly a handful of times and will cycle between online \ offline.

I have tried using the usbhid driver without any extra arguments and with settings found http://networkupstools.org/ddl/Tripp_Lite/SMART1500LCDT.html

Hey f34rinc , seems like you've done some homework. Thanks!

Going forward, the first thing I would recommend for testing is to get rid of everything in the advanced section, and ensure that you have rebooted before continuing diagnosis.

Do you have confidence in the USB chipset on the mother board? Is it a recent MB? It appears that the UPS is on the other side of a bridge chip (expected), but 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?

bulldog5 · Jul 15, 2017, 8:27 AM

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?

f34rinc · Jul 15, 2017, 3:59 PM

@dennypage:

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.

dennypage · Jul 16, 2017, 3:40 PM

@bulldog5:

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.

dennypage · Jul 16, 2017, 3:47 PM

@f34rinc:

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.

f34rinc · Jul 16, 2017, 4:21 PM

@dennypage:

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 ?

dennypage · Jul 16, 2017, 8:07 PM

@f34rinc:

Thanks, is there a certain bridge chip manufacture I should try or avoid ?

Sorry, I'm not knowledgeable enough to make a recommendation.

bulldog5 · Jul 16, 2017, 10:43 PM

@dennypage:

@f34rinc:

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 =(

dennypage · Jul 16, 2017, 11:37 PM

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>

bulldog5 · Jul 17, 2017, 10:49 PM

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.

dennypage · Jul 18, 2017, 12:36 AM

@bulldog5:

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.

bulldog5 · Jul 18, 2017, 1:15 AM

@dennypage:

@bulldog5:

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?

dennypage · Jul 18, 2017, 2:57 AM

@bulldog5:

@dennypage:

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?

bulldog5 · Jul 18, 2017, 5:05 AM

@dennypage:

@bulldog5:

@dennypage:

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.

dennypage · Jul 18, 2017, 5:21 AM

Do you have another UPS to test with by chance?

dennypage · Jul 18, 2017, 4:43 PM

@bulldog5:

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>