danielb7390

Hi, This might seem a very stupid request, but the docker actions like start ALL, stop ALL, should require a confirmation. I just had a small misclick while focusing the browser window, right on the stop all button, it wasn't a fun time 🤣

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 😆

/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...

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?

Sorry, forgot. nut-debug-20240717113624.zip

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.

Hey! Thanks for the quick fix!

Hi, First of all, thanks for maintaining this plugin! Unfortunately i had 2 power cuts in the last week that lasted more than the normal few seconds, and some weird stuff happened, and i cant figure out exactly whats wrong. In attachment, debug zip, and print screens. Sequence of events: The settings are set to power off when battery.runtime < 300. UPS battery is quite new, and seems to be reporting accurate runtime. 21:30 The power failed 21:26 NUT script decided it was time to shutdown the server. But runtime at that time was >900s left (check last image) (Somehow the server started back up, unrelated to NUT, i have to check my BIOS settings... i guess wake by USB or something is causing this) At 21:29, it was back up, and battery runtime was 822. At 21:39 NUT script decided it was time to shutdown, this time with the correct runtime left. Not sure how to debug this at all. I took a look at the scripts and all looks great, the only way i see to this fail is if the upsc command fails, making grep/awk fail causing the -gt comparison to fail somehow (nut-notify@L72), I'm probably way off on this, my bash script skills are 0 to none 🤣 nut-debug-20240315085147.zip

I'm trying to find a way to avoid hitting 100% HDD usage when copying files from the downloads folder to their destination, and found this in the docker documentation, searched this forum and only found this thread with no real solution. Tried —-device-write-bps /dev/sdd:1mb But didn't work. Anyone knows how to do this?

Thanks for the plugin. I even started a thread requesting this as a feature.. and another user pointed me here. Does everything i wanted! Thanks!

Hi, Why the default has replication activated to a file? Is there a reason? How can i disabled it? Tried to override log_bin to OFF/0 in custom.cnf but didn't work..

same here also