Jump to content

[Plugin] NUT v2 - Network UPS Tools

dmacias

By dmacias
in Plugin Support

Recommended Posts

Recommended

Posted by Rysz,

Please install Network UPS Tools (NUT) for UNRAID by Rysz from Community Applications. The older plugins (including the one in the first post of this topic) are deprecated/now unsupported.

Please read before installing NUT

Recommended by Rysz

0 reactions

Go to this post
Recommended

Posted by Rysz,

If you are using "powertop", this is known to cause instabilities with some UPS (changing the auto-hibernation of USB devices). If not, continue reading...   USB connectivity problems (data staleness, timeouts, ...) are incredibly hard if not impossible to diagnose remotely. They can stem from a multitude of factors because of the many parts involved in the equation (USB cable, port, bus, driver, implementation, ...). Common reasons have included broken USB cables (could attempt new US

USB connection instabilities, timeouts and staleness

Recommended by Rysz

0 reactions

Go to this post
  • Replies 1.6k
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

dmacias
dmacias

NUT plugin v2 for unRAID 6.1+   NUT - Network UPS Tools - http://www.networkupstools.org/   Based on the original NUT plugin by macester Original thread https://forums.lime-technology.com/topic/

SimonF
SimonF

I am stopping updates for my version of the plugin. Update to the latest version 2023.09.17 and then you can remove my version and install Rysz's from CA and it will retain your configs.   T

SimonF
SimonF

Released 2023.07.26, @ich777 is creating a new package for me to use, and I want to look to move to 2.8 as the default version but will need to check upgrade path works ok.

Posted Images

Rysz Enthusiast

Rysz

Posted
Posted (edited)
24 minutes ago, KillianMelsen said:

Might be very simple, but how do I enabled beeping? I found:

 but I cannot find the mentioned username/password anywhere...

 

It's inside the upsd.users configuration file (see below - admin/adminpass):

grafik.png.110bde7380c261542e19324adabd04a8.png

As outlined in the linked post it can be done using upscmd, if your UPS supports this. Otherwise it can usually be easier set directly on the UPS, either via physical button or LCD panel (check manual about this for your UPS).

 

Edited by Rysz
Link to comment
danielb7390 Noob

danielb7390

Posted
Posted

Hi,

I'm back after a few months 😆

Had a power cut 2 days ago and weird stuff happened again... since the last time, i added a old raspberry pi to manage the UPS separately so i wouldn't be blind if my server went off.

If i have my settings correct (attached print), the server should wait till it only has 300s/5min of battery left to initiate shutdown,.

Also attached the logging for the UPS.

The server decided to shut down at around 11:45:50, at that time it had around ~1000s left of runtime...

Not sure if I'm doing something wrong, or there's still some bug around 😅
I was getting into a theory that it initiated shutdown after 300s, but the math doesn't add up very well, assuming the worst case that it switched to OB at 11:43:02, since it powered off at 11:45:50... that would be at most 3min/180s 🤔
Any ideas? I can try to debug stuff if needed starting on 28th of july.

 

ups_log.png.0fc9c625c5e20335e52d3d556c3b1c89.pngups_settings.thumb.png.bce79d7f0c22078222f221afcfca8f14.png

 

 

Link to comment
Rysz Enthusiast

Rysz

Posted
Posted
2 hours ago, danielb7390 said:

Hi,

I'm back after a few months 😆

Had a power cut 2 days ago and weird stuff happened again... since the last time, i added a old raspberry pi to manage the UPS separately so i wouldn't be blind if my server went off.

If i have my settings correct (attached print), the server should wait till it only has 300s/5min of battery left to initiate shutdown,.

Also attached the logging for the UPS.

The server decided to shut down at around 11:45:50, at that time it had around ~1000s left of runtime...

Not sure if I'm doing something wrong, or there's still some bug around 😅
I was getting into a theory that it initiated shutdown after 300s, but the math doesn't add up very well, assuming the worst case that it switched to OB at 11:43:02, since it powered off at 11:45:50... that would be at most 3min/180s 🤔
Any ideas? I can try to debug stuff if needed starting on 28th of july.

 

ups_log.png.0fc9c625c5e20335e52d3d556c3b1c89.pngups_settings.thumb.png.bce79d7f0c22078222f221afcfca8f14.png

 

 

 

Please post the NUT Debug Package that can be found on NUT Settings page.

Link to comment
Rysz Enthusiast

Rysz

Posted
Posted
2 minutes ago, danielb7390 said:

Sorry, forgot.

nut-debug-20240717113624.zip 112.73 kB · 0 downloads

 

Thanks, unfortunately there's no pre-shutdown logfiles anymore - so it's hard to say what happened exactly. In NUT slave mode it's however also dependent on the NUT master's shutdown criteria, because if the NUT master is configured any different and starts a shutdown, that will also take down the NUT slaves (even if the criteria on the slaves has not been met yet). Are there any different shutdown criteria set on the NUT master (the RPi) that would explain why a shutdown could have been initiated? Also, was it an unclean shutdown that triggered a parity check after booting up again or just a "regular" graceful shutdown as it should normally have been triggered by NUT (just it had been triggered prematurely)? The only real chance at finding the culprit would be that you set up the SYSLOG server so that the pre-shutdown logs do not get lost. Then we can work with those logs and will see messages from NUT saying why it decided to shutdown, everything else is just guesswork I'm afraid.

Link to comment
danielb7390 Noob

danielb7390

Posted
Posted

Just checked the Rpi dmesg, if I'm not mistaken nut prints stuff in here right?

Just found this... that might be a bit worrying too, but the timestamps don't seem to match with the power off time. 


[Mon Jul 15 11:48:54 2024] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
[Mon Jul 15 11:48:55 2024] usb 1-1.3: USB disconnect, device number 10
[Mon Jul 15 11:48:55 2024] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
[Mon Jul 15 11:48:56 2024] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
[Mon Jul 15 11:48:56 2024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Mon Jul 15 11:48:56 2024] usb 1-1.3: Product: 5E
[Mon Jul 15 11:48:56 2024] usb 1-1.3: Manufacturer: EATON
[Mon Jul 15 11:48:58 2024] hid-generic 0003:0463:FFFF.0008: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
[Mon Jul 15 12:06:08 2024] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
[Mon Jul 15 12:06:09 2024] usb 1-1.3: USB disconnect, device number 11
[Mon Jul 15 12:06:10 2024] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
[Mon Jul 15 12:06:10 2024] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
[Mon Jul 15 12:06:10 2024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Mon Jul 15 12:06:10 2024] usb 1-1.3: Product: 5E
[Mon Jul 15 12:06:10 2024] usb 1-1.3: Manufacturer: EATON
[Mon Jul 15 12:06:12 2024] hid-generic 0003:0463:FFFF.0009: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0

 

Rpi nut services 

service --status-all | grep nut
 [ - ]  nut-client
 [ + ]  nut-server

 

Rpi Cfgs 


# /etc/nut/nut.conf
MODE=netserver

# /etc/nut/ups.conf
maxretry = 3
[ups]
  driver = usbhid-ups
  port = auto

# /etc/nut/upsd.conf
LISTEN 0.0.0.0 3493

# /etc/nut/upsd.users

# /etc/nut/upsmon.conf
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

# /etc/nut/upssched.conf
CMDSCRIPT /bin/upssched-cmd

 

Do you see anything clearly wrong here?
Does the plugin have any way to enable debug or something and prevent shutdown?

Link to comment
Rysz Enthusiast

Rysz

Posted
Posted (edited)
8 minutes ago, danielb7390 said:

Just checked the Rpi dmesg, if I'm not mistaken nut prints stuff in here right?

Just found this... that might be a bit worrying too, but the timestamps don't seem to match with the power off time. 


[Mon Jul 15 11:48:54 2024] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
[Mon Jul 15 11:48:55 2024] usb 1-1.3: USB disconnect, device number 10
[Mon Jul 15 11:48:55 2024] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
[Mon Jul 15 11:48:56 2024] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
[Mon Jul 15 11:48:56 2024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Mon Jul 15 11:48:56 2024] usb 1-1.3: Product: 5E
[Mon Jul 15 11:48:56 2024] usb 1-1.3: Manufacturer: EATON
[Mon Jul 15 11:48:58 2024] hid-generic 0003:0463:FFFF.0008: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
[Mon Jul 15 12:06:08 2024] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
[Mon Jul 15 12:06:09 2024] usb 1-1.3: USB disconnect, device number 11
[Mon Jul 15 12:06:10 2024] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
[Mon Jul 15 12:06:10 2024] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
[Mon Jul 15 12:06:10 2024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Mon Jul 15 12:06:10 2024] usb 1-1.3: Product: 5E
[Mon Jul 15 12:06:10 2024] usb 1-1.3: Manufacturer: EATON
[Mon Jul 15 12:06:12 2024] hid-generic 0003:0463:FFFF.0009: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0

 

Rpi nut services 

service --status-all | grep nut
 [ - ]  nut-client
 [ + ]  nut-server

 

Rpi Cfgs 


# /etc/nut/nut.conf
MODE=netserver

# /etc/nut/ups.conf
maxretry = 3
[ups]
  driver = usbhid-ups
  port = auto

# /etc/nut/upsd.conf
LISTEN 0.0.0.0 3493

# /etc/nut/upsd.users

# /etc/nut/upsmon.conf
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

# /etc/nut/upssched.conf
CMDSCRIPT /bin/upssched-cmd

 

Do you see anything clearly wrong here?
Does the plugin have any way to enable debug or something and prevent shutdown?

 

dmesg is just the kernel ring buffer, you won't find NUT's messages in there (just device-related ones).
These connection messages are not worrying in particular, just some minor hiccups which are common.

 

NUT would output the messages to /var/log/syslog - both on Unraid and the RPi.

Can you check if the RPi has any NUT-related messages in /var/log/syslog from that time?

On Unraid itself you'd need to turn on the SYSLOG server to preserve these messages over reboot.

 

Edited by Rysz
Link to comment
danielb7390 Noob

danielb7390

Posted
Posted
2 minutes ago, Rysz said:

 

dmesg is just the kernel ring buffer, you won't find NUT's messages in there (just device-related ones).

 

NUT would output the messages to /var/log/syslog - both on Unraid and the RPi.

Can you check if the RPi has any NUT-related messages in /var/log/syslog from that time?

 

On Unraid itself you'd need to turn on the SYSLOG server to preserve these messages over reboot.

/var/log/syslog from the Rpi 

Jul 15 12:45:09 pvznut kernel: [5610659.453738] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
Jul 15 12:45:10 pvznut kernel: [5610660.485979] usb 1-1.3: USB disconnect, device number 10
Jul 15 12:45:10 pvznut kernel: [5610660.893728] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
Jul 15 12:45:11 pvznut usbhid-ups[361]: libusb_get_interrupt: error submitting URB: No such device
Jul 15 12:45:11 pvznut kernel: [5610661.641961] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
Jul 15 12:45:11 pvznut kernel: [5610661.642025] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 15 12:45:11 pvznut kernel: [5610661.642050] usb 1-1.3: Product: 5E
Jul 15 12:45:11 pvznut kernel: [5610661.642068] usb 1-1.3: Manufacturer: EATON
Jul 15 12:45:13 pvznut upsd[363]: Data for UPS [ups] is stale - check driver
Jul 15 12:45:13 pvznut kernel: [5610663.624947] hid-generic 0003:0463:FFFF.0008: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
Jul 15 12:45:13 pvznut mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 12:45:13 pvznut mtp-probe: bus: 1, device: 11 was not an MTP device
Jul 15 12:45:13 pvznut mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 12:45:13 pvznut mtp-probe: bus: 1, device: 11 was not an MTP device
Jul 15 12:45:16 pvznut upsd[363]: UPS [ups] data is no longer stale
Jul 15 13:02:23 pvznut kernel: [5611693.655502] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
Jul 15 13:02:24 pvznut kernel: [5611694.729648] usb 1-1.3: USB disconnect, device number 11
Jul 15 13:02:24 pvznut kernel: [5611695.085298] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
Jul 15 13:02:25 pvznut usbhid-ups[361]: libusb_get_interrupt: error submitting URB: No such device
Jul 15 13:02:25 pvznut kernel: [5611695.833970] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
Jul 15 13:02:25 pvznut kernel: [5611695.834035] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 15 13:02:25 pvznut kernel: [5611695.834061] usb 1-1.3: Product: 5E
Jul 15 13:02:25 pvznut kernel: [5611695.834080] usb 1-1.3: Manufacturer: EATON
Jul 15 13:02:27 pvznut upsd[363]: Data for UPS [ups] is stale - check driver
Jul 15 13:02:27 pvznut kernel: [5611697.816452] hid-generic 0003:0463:FFFF.0009: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
Jul 15 13:02:27 pvznut mtp-probe: checking bus 1, device 12: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 13:02:27 pvznut mtp-probe: bus: 1, device: 12 was not an MTP device
Jul 15 13:02:28 pvznut mtp-probe: checking bus 1, device 12: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 13:02:28 pvznut mtp-probe: bus: 1, device: 12 was not an MTP device
Jul 15 13:02:30 pvznut upsd[363]: UPS [ups] data is no longer stale

 

Thanks for the help, even tho this can possibly be outside of the scope of the plugin.
Probably of no help tho, will have to set the syslog next week and test with a simulated power outage to get some data...

Link to comment
Rysz Enthusiast

Rysz

Posted
Posted
2 minutes ago, danielb7390 said:

/var/log/syslog from the Rpi 

Jul 15 12:45:09 pvznut kernel: [5610659.453738] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
Jul 15 12:45:10 pvznut kernel: [5610660.485979] usb 1-1.3: USB disconnect, device number 10
Jul 15 12:45:10 pvznut kernel: [5610660.893728] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
Jul 15 12:45:11 pvznut usbhid-ups[361]: libusb_get_interrupt: error submitting URB: No such device
Jul 15 12:45:11 pvznut kernel: [5610661.641961] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
Jul 15 12:45:11 pvznut kernel: [5610661.642025] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 15 12:45:11 pvznut kernel: [5610661.642050] usb 1-1.3: Product: 5E
Jul 15 12:45:11 pvznut kernel: [5610661.642068] usb 1-1.3: Manufacturer: EATON
Jul 15 12:45:13 pvznut upsd[363]: Data for UPS [ups] is stale - check driver
Jul 15 12:45:13 pvznut kernel: [5610663.624947] hid-generic 0003:0463:FFFF.0008: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
Jul 15 12:45:13 pvznut mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 12:45:13 pvznut mtp-probe: bus: 1, device: 11 was not an MTP device
Jul 15 12:45:13 pvznut mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 12:45:13 pvznut mtp-probe: bus: 1, device: 11 was not an MTP device
Jul 15 12:45:16 pvznut upsd[363]: UPS [ups] data is no longer stale
Jul 15 13:02:23 pvznut kernel: [5611693.655502] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
Jul 15 13:02:24 pvznut kernel: [5611694.729648] usb 1-1.3: USB disconnect, device number 11
Jul 15 13:02:24 pvznut kernel: [5611695.085298] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
Jul 15 13:02:25 pvznut usbhid-ups[361]: libusb_get_interrupt: error submitting URB: No such device
Jul 15 13:02:25 pvznut kernel: [5611695.833970] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
Jul 15 13:02:25 pvznut kernel: [5611695.834035] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 15 13:02:25 pvznut kernel: [5611695.834061] usb 1-1.3: Product: 5E
Jul 15 13:02:25 pvznut kernel: [5611695.834080] usb 1-1.3: Manufacturer: EATON
Jul 15 13:02:27 pvznut upsd[363]: Data for UPS [ups] is stale - check driver
Jul 15 13:02:27 pvznut kernel: [5611697.816452] hid-generic 0003:0463:FFFF.0009: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
Jul 15 13:02:27 pvznut mtp-probe: checking bus 1, device 12: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 13:02:27 pvznut mtp-probe: bus: 1, device: 12 was not an MTP device
Jul 15 13:02:28 pvznut mtp-probe: checking bus 1, device 12: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 13:02:28 pvznut mtp-probe: bus: 1, device: 12 was not an MTP device
Jul 15 13:02:30 pvznut upsd[363]: UPS [ups] data is no longer stale

 

Thanks for the help, even tho this can possibly be outside of the scope of the plugin.
Probably of no help tho, will have to set the syslog next week and test with a simulated power outage to get some data...

 

Nothing there that says a shutdown was in fact triggered by anything. USB disconnects and related data staleness seems to occur relatively frequently but was recovered from within a few seconds in these visible cases. Longer lasting data staleness can cause either the NUT master or NUT slaves to consider a UPS as non-communicating and critical (resulting in a shutdown), but I'm not seeing that in the logs here either. We'll have to try with the SYSLOG server on Unraid to get more clarity on what is happening during such OB situations, unless you see anything in the RPi logs from around that time regarding NUT status changes or any shutdowns being initiated. NUT is usually very talkative, so it would write any such major events in the logs.

  • Like 1
Link to comment
Rysz Enthusiast

Rysz

Posted
Posted (edited)
46 minutes ago, danielb7390 said:

Well, had another power failure one today, and this time it correctly powered off when there was 5 minutes remaining.

So, it seems it's going to be one of those annoying bugs that happen only when nobody is looking 😆

 

That being said, "Runtime Left" is the least reliable of the three shutdown modes. The runtime reported by the UPS and the actual possible battery runtime can fluctuate and vary a lot depending on both the battery health and the implementation of the calculation mechanism in the UPS. I generally recommend to use "Time on Battery" or "Battery Level" as more reliable mechanisms. My UPS - for example - are set to shutdown after 2 minutes on battery, as by that time usually a recovery of the mains power is no longer to be expected (if it doesn't recover within 2 minutes it's usually down for a lot longer than the UPS could cover).

 

Edited by Rysz
  • Like 2
Link to comment
knights_of_pine Rookie

knights_of_pine

Posted
Posted
On 7/14/2024 at 10:05 PM, Rysz said:

Hello!

 

This is unfortunately the result of minor driver connection instabilities, nothing we can do about it.

It's good that everything else works normally though, so you can just filter out these SYSLOG messages.

 

1) Put these lines at the end of xnut-nospam.conf using NUT Configuration Editor in GUI: 

:msg, regex, "nut_libusb_get.*Input/Output Error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*Input/Output Error" stop

 

2) So it will look like this - click "Save":

grafik.thumb.png.0847c79453e896e7eb188f400255d641.png

 

3) Set "Enable Rule-Based Syslog Filters:" to "Yes" in NUT Settings:

grafik.png.f9a1b11e3bd5a9e3f51f55bf1ed93471.png

 

4) Click "Apply" and these messages should now no longer appear in your SYSLOG.

Please note this will only be applied to new messages, the old ones will still be visible in SYSLOG.

 

Please let me know if that worked for you! 🙂 

 

 

Hello,

I had the same issue and tried your above fix but this did not stop the error messages.  do you have another idea or maybe why it wouldnt work for me?  thank you!

Link to comment
Rysz Enthusiast

Rysz

Posted
Posted
13 hours ago, knights_of_pine said:

 

 

Hello,

I had the same issue and tried your above fix but this did not stop the error messages.  do you have another idea or maybe why it wouldnt work for me?  thank you!

 

Please post the NUT Debug Package that can be found in NUT Settings.

Link to comment
bnbg Noob

bnbg

Posted
Posted

Hi,

The plugin has "On Battery" status for me and is not showing any values. When using the built-in UPS option I do see it connected correctly and do see the values, however, the USB connection was being lost after a day or so each time. I have switched the cable and used a different port but still getting the same result. I have attached the debug. Any advice? Thanks

nut-debug-20240723182403.zip

Link to comment
Rysz Enthusiast

Rysz

Posted
Posted
2 hours ago, bnbg said:

Hi,

The plugin has "On Battery" status for me and is not showing any values. When using the built-in UPS option I do see it connected correctly and do see the values, however, the USB connection was being lost after a day or so each time. I have switched the cable and used a different port but still getting the same result. I have attached the debug. Any advice? Thanks

nut-debug-20240723182403.zip 203.03 kB · 0 downloads


Your UPS is not listed as compatible to NUT, however you can try "Auto Config" if that improves anything.

Otherwise you can try opening a ticket here: https://github.com/networkupstools/nut/issues

But I haven't found anyone on the internet who's used your UPS in combination with NUT so far.

Link to comment
bnbg Noob

bnbg

Posted
Posted
54 minutes ago, Rysz said:


Your UPS is not listed as compatible to NUT, however you can try "Auto Config" if that improves anything.

Otherwise you can try opening a ticket here: https://github.com/networkupstools/nut/issues

But I haven't found anyone on the internet who's used your UPS in combination with NUT so far.

I tried auto config but still no joy, unfortunately.

I will log a ticket there. Is there anything else I can do to help get it compatible/supported? 

Link to comment
Rysz Enthusiast

Rysz

Posted
Posted
2 hours ago, knights_of_pine said:

please see attached.  thank you!

nut-debug-20240725192957.zip 313.18 kB · 1 download

 

Change your xnut-nospam.conf via GUI configuration editor (in NUT Settings) so it looks like this: 

#
# DO NOT CHANGE THIS FILE IF YOU DO NOT KNOW WHAT YOU ARE DOING
# CHANGING THIS FILE CAN BREAK YOUR ENTIRE SYSTEM LOGGING CAPABILITIES
# MAKING IT ALMOST IMPOSSIBLE FOR OTHERS TO HELP YOU IN CASE OF PROBLEMS
#
# NUT Rule-Based Repetitive Message Filtering (SYSLOG Anti-Spam Module)
# https://www.rsyslog.com/doc/configuration/filters.html
# https://www.rsyslog.com/doc/configuration/actions.html
#
# When adding new rules, be as specific as possible and filter as little
# as just possible in order not to discard important diagnostic information
# from both the SYSLOG itself and any otherwise generated diagnostic packages
#

:msg, regex, "UPS.*data is no longer stale" -/var/log/nut-spam
:msg, regex, "UPS.*Data stale" -/var/log/nut-spam
:msg, regex, "Communications with UPS.*lost" -/var/log/nut-spam
:msg, regex, "Communications with UPS.*established" -/var/log/nut-spam
:msg, regex, "UPS.*data is no longer stale" stop
:msg, regex, "UPS.*Data stale" stop
:msg, regex, "Communications with UPS.*lost" stop
:msg, regex, "Communications with UPS.*established" stop

:msg, regex, "nut_libusb_get.*Error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*Error" stop
:msg, regex, "nut_libusb_get.*error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*error" stop

Then restart NUT and the spam lines in log should disappear, can you confirm?

 

Link to comment
knights_of_pine Rookie

knights_of_pine

Posted
Posted
On 7/25/2024 at 10:08 PM, Rysz said:

 

Change your xnut-nospam.conf via GUI configuration editor (in NUT Settings) so it looks like this: 

#
# DO NOT CHANGE THIS FILE IF YOU DO NOT KNOW WHAT YOU ARE DOING
# CHANGING THIS FILE CAN BREAK YOUR ENTIRE SYSTEM LOGGING CAPABILITIES
# MAKING IT ALMOST IMPOSSIBLE FOR OTHERS TO HELP YOU IN CASE OF PROBLEMS
#
# NUT Rule-Based Repetitive Message Filtering (SYSLOG Anti-Spam Module)
# https://www.rsyslog.com/doc/configuration/filters.html
# https://www.rsyslog.com/doc/configuration/actions.html
#
# When adding new rules, be as specific as possible and filter as little
# as just possible in order not to discard important diagnostic information
# from both the SYSLOG itself and any otherwise generated diagnostic packages
#

:msg, regex, "UPS.*data is no longer stale" -/var/log/nut-spam
:msg, regex, "UPS.*Data stale" -/var/log/nut-spam
:msg, regex, "Communications with UPS.*lost" -/var/log/nut-spam
:msg, regex, "Communications with UPS.*established" -/var/log/nut-spam
:msg, regex, "UPS.*data is no longer stale" stop
:msg, regex, "UPS.*Data stale" stop
:msg, regex, "Communications with UPS.*lost" stop
:msg, regex, "Communications with UPS.*established" stop

:msg, regex, "nut_libusb_get.*Error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*Error" stop
:msg, regex, "nut_libusb_get.*error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*error" stop

Then restart NUT and the spam lines in log should disappear, can you confirm?

 

i tried and unfortunately still getting the errors in the log...

image.png.daf6cc855c4aa60223d9f5b276596596.png

image.png.cb4cadf75839c86fd03d9fbd493f100e.png

 

Link to comment
Rysz Enthusiast

Rysz

Posted
Posted
12 minutes ago, knights_of_pine said:

i tried and unfortunately still getting the errors in the log...

image.png.daf6cc855c4aa60223d9f5b276596596.png

image.png.cb4cadf75839c86fd03d9fbd493f100e.png

 

 

That's really odd, did you enable the "Rule-based Syslog Filters" in NUT Settings and restart NUT?

If you did, please try restarting NUT again and also run this command if that still doesn't work: 

/etc/rc.d/rc.rsyslogd restart

 

Link to comment
knights_of_pine Rookie

knights_of_pine

Posted
Posted
25 minutes ago, Rysz said:

 

That's really odd, did you enable the "Rule-based Syslog Filters" in NUT Settings and restart NUT?

If you did, please try restarting NUT again and also run this command if that still doesn't work: 

/etc/rc.d/rc.rsyslogd restart

 

unfortunately, no change...

image.png.b9de984c5bc1361135985f2e16c279f5.png

image.png.0b78339109a39bd46c25f0be1031e1c2.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Go to topic listing
×
×
  • Create New...