I have NUT running on a couple of Pi's and it crashed today, wouldn't restart w/out a reboot of the Pi. Anyone else seen any issues like this w/NUT running on a Pi?
A no isn’t too helpful, but no I’m not having any issues, moved NUT over to this pi about 6 months ago and it has been fine.
Maybe the Pi’s SD card is starting to fail and showing strange symptoms? Only thing that occurs to me.
Thanks - hopefully that isn't it (SD card!). 
The card is pretty new, but these things happen, of course. Reminds me it's time to take a backup of the card...thanks.
Was it producing an error when it failed to start back up?
I was too busy to check. I got a text notification from NUT that the UPS was disconnected when I was away from home, so I quickly logged into my home VPN to confirm that the house hadn't lost power, and then tried to get a current status from the Pi.
Tried sudo upsc pi-ups, sudo service nut-server restart, and sudo service nut-client and all did nothing - cursor sitting there blinking, so I just told the Pi to reboot.
1 Like
To answer this more directly, it was odd and I haven't seen this before on a Pi. When I hit enter after any of the three commands above, the cursor moved down to the next line and just sat there blinking. Nothing happened, let it sit for a couple minutes. Hadn't seen that before.
Definitely sounds like commands were hanging for some reason. Would require some troubleshooting at the time: what does the output of top show, any cpu spikes, any iowait, anything in /var/log/syslog look amiss, etc.
Probably something to keep an eye on, could still be a failing SD card, but hard to say one way or the other.
1 Like
Yeah, I'm going to be a little more suspicious about how that Pi behaves, and am taking a backup tonight on it.
1 Like
Oh man I have seen this so many times with NUT on Pi. My solution was to turn off UPS events and just go with polling. But it all depends on what UPS's you are connecting. I have resolved this on my home Pi and the Pi at my mom's house with this configuration in ups.conf:
[ups]
driver = usbhid-ups
port = auto
desc = "CyberPower AVRG750U"
serial = "QGJHY2002371"
pollfreq = 1
pollonly
Just for your info I manually added the desc and serial values just for documentation purposes. Her PI has been up for over 90 days since my last update and running great. Here is the output of the upsc command:
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 6810
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 24.0
battery.voltage.nominal: 24
device.mfr: CPS
device.model: AVRG750U
device.serial: QGJHY2002371
device.type: ups
driver.flag.pollonly: enabled
driver.name: usbhid-ups
driver.parameter.pollfreq: 1
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.serial: QGJHY2002371
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 122.0
input.voltage.nominal: 120
output.voltage: 130.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 5
ups.mfr: CPS
ups.model: AVRG750U
ups.productid: 0501
ups.realpower.nominal: 450
ups.serial: QGJHY2002371
ups.status: OL
ups.test.result: No test initiated
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764
1 Like
Thanks for sharing your experiences w/NUT, very good to know.
The UPS connected to the Pi is a CyberPower SX650OU.
I didn't see the "pollfreq" and "pollonly" attributes documented in the ups.conf file, didn't know those were an option, thanks for letting me know about them.
Did you ever play around w/the "synchronous" setting? That also looks interesting in this context:
synchronous: optional. The driver work by default in asynchronous
97 # mode (i.e *synchronous=no*). This means that all data
98 # are pushed by the driver on the communication socket to
99 # upsd (Unix socket on Unix, Named pipe on Windows) without
100 # waiting for these data to be actually consumed. With
101 # some HW, such as ePDUs, that can produce a lot of data,
102 # asynchronous mode may cause some congestion, resulting in
103 # the socket to be full, and the driver to appear as not
104 # connected. By enabling the 'synchronous' flag
105 # (value = 'yes'), the driver will wait for data to be
106 # consumed by upsd, prior to publishing more. This can be
107 # enabled either globally or per driver.
108 #
109 # The default is 'no' (i.e. asynchronous mode) for backward
110 # compatibility of the driver behavior.
111 #
Haven't looked into but that could solve some flow issues. I tend to think in queuing from a socket perspective that the messages would always be consumed by monitor. With these small UPS's unless some line event happens there shouldn't be a massive amount of updates to the socket. The Pi has "limited" cycles and the USB interfaces aren't always the most debugged so it's possible this is happening.
1 Like
If you want to get deep read this document:
1 Like
I'll take a look, but I'm more of a children's pool kinda guy.... 
Forgot to ask, have you found/used any GUI NUT clients to run on your Pi along w/NUT? Ideally w/a local browser interface, but if necessary accesible via VNC.
Found this (https://github.com/gawindx/WinNUT-Client) but don't have any Windows devices that are running 24/7. Basically would like to have something like the dashboard that this Win client provides:
The only thing I am using UPS data for in the Hubitat is for shutting the hub down after being on battery for about 5 minutes. There was some graphics apps that could use the data to provide charts. Looking at the Hubitat Package Manager:
Thanks, I'll add that to my (never ending) list of things to investigate. So much for my wife's to-do list!
