NUT package (2.8.0 and below)

DaddyGo

NUT (2.7.4_20) with CyberPower RMCARD205 incorrect decimal point (0.1) vari.: battery.runtime

Problem with CyberPower RMCARD205 + NUT installations, maybe it's time to switch to 2.8 ( https://www.freshports.org/sysutils/nut ), as the "snmp-ups" driver does not include this type either.
The problem with this wrong value is that, the shutdown threshold slips by, say, from a few minute (20%) - to a few hour :) and thus, - the UPS protection does not work in real time.
(because it "thinks" there are 5 hours left in the batteries, but in fact there are only 5 minutes left)

I repeat, only with this network SNMP card which we use RMCARD205 and unfortunately with the old driver set "driver.list" - snmp-ups...

OLD "snmp-ups" file in pfS inst driver.list NUT.:

RMCARD205 web interface:

pfS NUT console:

According to new compatibility:

dennypage

@daddygo said in NUT package:

maybe it's time to switch to 2.8

Pending pull request and redmine issue.

DaddyGo

@dennypage

Hi Denny,

Super then we thought of one (2.8) and hope it will happen quickly as we have purchased 10 pcs. 1.5KVA UPS units with RMCARD205.
(I say softly - yeah, my fault for not checking the pfS NUT package and the RMACARD drivers first)

Anyway thanks for your sacrificial work with this package, I have been watching it for a while...

Viper_Rus

This post is deleted!

dennypage

@Viper_Rus i assume you found the answer to supporting Synology elsewhere in the thread.

mrsunfire

I‘m having the issue that I get a shutdown loop after the UPS battery is empty.

pfSense shutdown as expected. After power restores the UPD turns on and pfSense boots up. Couple of seconds later the UPS is doing battery check. This seems to trigger pfSense to shutdown again and turns of UPS aswell. This loop continues until I unplug communication to the UPS and wait that battery gets fully charged.

You can see here that the input power is available but the UPS is getting the signal from pfSense to not charge. After couple of seconds pfSense and UPS shutdown.

Screenshot 2022-12-11 103342.jpg

dennypage

@mrsunfire please post your config. And your UPS model.

mrsunfire

@dennypage Config is vanilla (no change). UPS is APC Backups Pro 550 via USB.

dennypage

@mrsunfire Hmm... I would have expected there to be some config change, either in the NUT package or in the UPS, as the UPS should not be bringing the load back on that quickly (0%). Nor would I expect it to show "On Line" and "Discharging" like that unless a calibration cycle were underway.

Speaking thereof, have you run a battery calibration recently? Perhaps the battery is dead...

Lastly, can you post the output of upsrw?

mrsunfire

@dennypage No calibration. I wo der why UPS switches back on battery the moment I connect pfSense.
Whats the command for that output?

dennypage

@mrsunfire How old it the UPS and battery?

Please post the output of upsrw. If you aren't familiar with that, you can find examples in this thread.

JonathanLee

@mrsunfire I was having weird issues in the last and it turned out to be a bad battery not the software.

mrsunfire

@jonathanlee Yes I already ordered new batteries before continue further testing.

I also did edit upsmon.conf and removed "SHUTDOWNCMD "/sbin/shutdown -h +0"". Unfortunately after reboot this setting is back there. How to proper edit that file? My goal in the first step was to not shutdown the pfSense at all.

Gertjan

@mrsunfire said in NUT package:

Unfortunately after reboot this setting is back there. How to proper edit that file? My goal in the first step was to not shutdown the pfSense at all.

Fast answer : you can't.
As the GUI states, this is what gets inserted in that file :

And this is what gets inserted upfront by the GUI interface, even when you leave that bloc empty :

/usr/local/pkg/nut/nut.inc line 250->252

( so, edit that file and do whatever you want ^^ )

dennypage

@mrsunfire said in NUT package:

I also did edit upsmon.conf and removed "SHUTDOWNCMD "/sbin/shutdown -h +0"". Unfortunately after reboot this setting is back there.

You can't. If you want to prevent NUT operation (shutdown and everything else), change the UPS Type to disabled until you replace the battery.

darkcorner

I have an APC Back-UPS BX2200MI connected and configured in pfSense.
Everything seems to work fine.
But how and where can I customize the shutdown delay?
I want it to turn off when the battery guarantees me no more than 10 minutes of electricity.
If within these 10 minutes the current returns, what happens?
What if pfSense has shut down in the meantime? The BIOS is configured for the PC to turn on when the power returns; is this enough?

dennypage

@darkcorner said in NUT package:

But how and where can I customize the shutdown delay?
I want it to turn off when the battery guarantees me no more than 10 minutes of electricity.

NUT will automatically shut the system down when the UPS declares a low battery situation. It is best to leave this alone and let the UPS and NUT do their jobs.

DannyBoy2k

@darkcorner If your UPS allows you to, you can configure battery.runtime.low to the amount of time you want the UPS to declare a critical condition. Unfortunately, a lot of UPSes don't allow you to configure this. If they do, you should be able to see and adjust the setting with the upsc command.
https://networkupstools.org/docs/man/upsc.html

darkcorner

@dennypage
@DannyBoy2k
Thanks for your answers.

The UPS USB cable is connected to pfSense, but it covers multiple PCs/servers that need to shut down automatically.
So, pfSense is the Master of NUT and on these PCs/Servers I'm installing tools configured as NUT Slave.

TrueNAS is configured as "Slave" in its NUT service, but it doesn't seem to notice the presence of the Master.
On a Win10 Pro PC I mounted WinNUT-Client and it gives me a login failure error for authentication.
(If it's not the right software, can you suggest me some other client?)

For all, the port is the standard one (3493).
In Windows10 I turned off its Windows Defender Firewall.
On pfSense there are two rules in LAN and DMZ for LAN-Net and DMZ-Net which allows any to any with any protocol.
In pfSense, with Diagnostic - Test Ports the port seems open, but from console telnet 127.0.0.1:3493 or (localhost:3493) reports the error "Name does not resolve".
On PC Win10 telnet LAN-NIC-Address:3493 reports error "Could not open connection to host. on port 23: Connection failed"

As NUT users I am using both admin and local-monitor with the password present in /usr/local/etc/nut/upsd.users.

Gertjan

@darkcorner said in NUT package:

On a Win10 Pro PC I mounted WinNUT-Client and it gives me a login failure error for authentication.

This one ?
I'm using several of them, pfSense being the NUT-master. It works.

pfSense side :

and

Note : my ups is called 'ups'.

On the Win NUT client side, a PC :

where password = "secret2" as this is "pcrecep1".

I've no particular firewall rules on my LAN, 19.168.1.1 - just one pass-all, so the client connects just fine.

@darkcorner said in NUT package:

In pfSense, with Diagnostic - Test Ports the port seems open, but from console telnet 127.0.0.1:3493 or (localhost:3493) reports the error "Name does not resolve".

You instructed NUT (pfSense) to listen on what interfaces ?
127.0.0.1 is not reachable from LAN. So
I want NUT to listen on my LAN so I told it to do so :

@darkcorner said in NUT package:

On PC Win10 telnet LAN-NIC-Address:3493 reports error "Could not open connection to host. on port 23: Connection failed"

telnet could be a good test.
But telnet uses TCP. Not sure if NUT uses UDP or TCP.

A better test : ask the system directly. I know the port, 3493, so :

[22.05-RELEASE][admin@pfSense.local.net]/root: sockstat | grep '3493'
root     upsd       21699 4  tcp6   2001:470:xxxx:5c0:2::1:3493 *:*
root     upsd       21699 5  tcp4   192.168.1.1:3493      *:*
root     upsd       21699 6  tcp6   ::1:3493              *:*
root     upsd       21699 7  tcp4   127.0.0.1:3493        *:*
root     upsd       21699 11 tcp6   ::1:3493              ::1:64823
root     upsd       21699 12 tcp4   192.168.1.1:3493      192.168.1.33:36453
root     upsd       21699 13 tcp4   192.168.1.1:3493      192.168.1.6:58694
root     upsd       21699 14 tcp4   192.168.1.1:3493      192.168.1.7:60690
root     upsmon     20768 4  tcp6   ::1:64823             ::1:3493

This tells you everything you need to know.
Nut listens on my LAN IPv6, and 192.168.1.1 all port 3493. Protocol is tcp.
PC's (clients) 192.168.1.6 and 192.168.1.7 have an established connection.
Like 192.168.1.33, my syno NAS, using 'monuser' and 'secret' as login ID.
Btw : ok, it listens also on localhost or 127.0.0.1 or ::1 on port 3493, tpc.

@darkcorner said in NUT package:

As NUT users I am using both admin and local-monitor with the password present in /usr/local/etc/nut/upsd.users.

True, this information :

will be placed into that file.
Do NOT edit that file yourself, use the GUI.

My "/usr/local/etc/nut/upsd.users" file has more info in it.
At the top, I find :

[admin]
password=be7b490cda2016c2a1fe
actions=set
instcmds=all
[local-monitor]
password=e90150cecfe29445f4a3
upsmon master

These are created when you install the package.
Not sure why I should use these. These [admin] and [local-monitor] are probably RTFM items.

edit :
By now, you have your clients up and connected.

So, bonus time :

The NOTIFYFLAG lines ask nut to spam logs, messages on the console, which can be seen if you are logged in console or SSH.

This one : "NOTIFYCMD /usr/local/sbin/upssched" is special.

You have to make your copy of this file : /usr/local/etc/nut/upssched.conf - take upssched.conf.sample as an example.
My /usr/local/etc/nut/upssched.conf :

CMDSCRIPT /root/upssched-cmd.sh
PIPEFN /var/db/nut/upssched.pipe
LOCKFN /var/db/nut/upssched.lock

AT ONBATT * START-TIMER onbatt 15
AT ONLINE * CANCEL-TIMER onbatt online
AT LOWBATT * EXECUTE lowbatt
AT COMMBAD * START-TIMER commbad 30
AT COMMOK * CANCEL-TIMER commbad commok
AT NOCOMM * EXECUTE commbad
AT FSD * EXECUTE powerdown
AT SHUTDOWN * EXECUTE powerdown

and before you ask : here is my home made /root/upssched-cmd.sh :

#!/bin/sh

UPS="ups"
STATUS=$( upsc $UPS ups.status )
CHARGE=$( upsc $UPS battery.charge )
CHMSG="[$STATUS]:$CHARGE%"

# upssched-cmd  --slave --
/usr/bin/logger -i -t upssched-cmd Calling upssched-cmd $1

case $1 in
    online) 
    MSG="$UPS, $CHMSG - power supply has been restored."
    ;;
    onbatt)
    MSG="$UPS, $CHMSG - power failure - save your work!"
    ;;
    lowbatt) 
    MSG="$UPS, $CHMSG - shutdown now!"
    ;;
    upsgone)
    MSG="$UPS, $CHMSG - UPS has been gone for awhile"
    ;;
    powerdown)
    MSG="$UPS, $CHMSG - Going powerdown"
    ;;
    commbad)
    /usr/bin/logger -i -t upssched-cmd "Communcation with UPS is lost"
    ;;
    *) 
    /usr/bin/logger -i -t upssched-cmd "Unkown arg: \"$1\", $CHMSG"
    exit 1
    ;;
esac
/usr/bin/logger -i -t upssched-cmd $MSG
/usr/local/pkg/nut/nut_email.php $MSG
exit 0

Make this file executable :

chmod +x /root/upssched-cmd.sh

and be careful for the file encoding. (Unix LF UTF-8, not some Windows format)

It's this file that takes care of the mail sending when power events happen.

Do not use this option :

as it hard codes a mail transmission, and blast away other possible settings.
=> Never ask a stupid GUI to do something that you can do yourself better ;)
The thing is : there can only be ONE CMDSCRIPT in /usr/local/etc/nut/upssched.conf.

Check the GUI 'mail me' option and that places the CMDSCRIPT. I wanted to have some more control of the process.
As you ca see, I use the NUT mail php script to mail : "/usr/local/pkg/nut/nut_email.php $MSG".

I'm using the settings and files as shown. I'm not saying they are perfect. I just want the systems to go down as soon as a power loss event arrives.

Btw : and yes, NUT is quiet big, and you can make it as complex as you want.
Testing is important, and you have to test a lot. No testing means : you have an UPS and you still have a no controlled power loss which might translate in data loss.