NUT package (2.8.0 and below)
-
@dennypage Solved it by adding user=root in ups.conf section. But this is rather a workaround than a solution. Anyway, this seems to be a problem of nut / file / dev permissions.
-
@tnowak said in NUT package:
Solved it by adding user=root in ups.conf section. But this is rather a workaround than a solution. Anyway, this seems to be a problem of nut / file / dev permissions.
I expect that you are actually in the same situation as the new gen APC listed above: No quirk covering your UPS device (I actually don't see anything from Ever in the table at all).
To confirm, use these steps:
- disable nut (Services / UPS / Settings) and save the config
- unplug the usb connection to the ups and wait 5 seconds
- re-plug the usb connection to the ups
- run "usbconfig -d ugen0.2 show_ifdrv"
and post the result. My expectation is that you will see two lines, similar to this:
ugen0.2: <American Power Conversion Smart-UPS1000 FW:UPS 16.0 / ID1047> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (10mA) ugen0.2.0: uhid0: <American Power Conversion Smart-UPS1000 FW:UPS 16.0 / ID1047, class 0/0, rev 2.00/0.01, addr 1>
-
Hi @dennypage - thanks again for all your help looking into the signal 10/11 issue with CyberPower UPS units. I'm fine to continue running mine with the
interruptonly
flag workaround for now even if fewer variables are monitored. After a couple days of running this way, things appear to be stable. If it this setup ends up crashing at some point, I'll probably give the updated usbhid-ups driver a try. Also, if you do end up releasing a nut-devel package at some point that includes fixes post 2.8.0, I'd be happy to try that out as well. -
@dennypage You are amazing I appreciate all you do. Again, thanks for taking the time to look into this issue reported within this discussion. It seems to be a problem with many other users now and you already have a solid solution for it.
-
@dennypage said in NUT package:
@tnowak said in NUT package:
Solved it by adding user=root in ups.conf section. But this is rather a workaround than a solution. Anyway, this seems to be a problem of nut / file / dev permissions.
I expect that you are actually in the same situation as the new gen APC listed above: No quirk covering your UPS device (I actually don't see anything from Ever in the table at all).
To confirm, use these steps:
- disable nut (Services / UPS / Settings) and save the config
- unplug the usb connection to the ups and wait 5 seconds
- re-plug the usb connection to the ups
- run "usbconfig -d ugen0.2 show_ifdrv"
and post the result. My expectation is that you will see two lines, similar to this:
ugen0.2: <American Power Conversion Smart-UPS1000 FW:UPS 16.0 / ID1047> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (10mA) ugen0.2.0: uhid0: <American Power Conversion Smart-UPS1000 FW:UPS 16.0 / ID1047, class 0/0, rev 2.00/0.01, addr 1>
Result:
ugen0.2: <EVER ECO PRO AVR CDS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.2.0: uhid0: <EVER ECO PRO AVR CDS, class 0/0, rev 2.00/1.00, addr 2>
PS. I've also noticed a problem with nut loosing connection to this UPS even with user=root after some time. Then when I restart nut it shows up again.
-
@tnowak said in NUT package:
Result:
ugen0.2: <EVER ECO PRO AVR CDS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.2.0: uhid0: <EVER ECO PRO AVR CDS, class 0/0, rev 2.00/1.00, addr 2>PS. I've also noticed a problem with nut loosing connection to this UPS even with user=root after some time. Then when I restart nut it shows up again.
Yep, that shows a kernel driver attached to the device. Same situation as the new series APC devices. Not too surprising, because I don't find any Ever devices defined in the usb table.
You can either use the user=root approach, or you can develop a quirk setting for /boot/loader.conf.local. Based on your prior post, I believe that the correct value would be this:
hw.usb.quirk.0="0x2e51 0x0002 0x0000 0xffff UQ_HID_IGNORE"
You can test this in advance by running this:
usbconfig add_dev_quirk_vplh 0x2e51 0x0002 0x0000 0xffff UQ_HID_IGNORE
followed by unplugging and replugging the usb cable to your ups. If the values are correct, when you run "usbconfig -d ugen0.2 show_ifdrv" again, you should only see one line of output like so:
ugen0.2: <EVER ECO PRO AVR CDS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
The ugen0.2.0 should be gone.
If this test works then you can add the line to your /boot/loader.conf.local file.
As to loosing communication after a time, I would still need to see the output from usbhid-ups, either from the system log or from the command line. There seem to be a few issues that do not produce entries in the system log, so I would recommend using the command line as previously discussed.
-
@dennypage said in NUT package:
hw.usb.quirk.0="0x2e51 0x0002 0x0000 0xffff UQ_HID_IGNORE"
You can test this in advance by running this:
usbconfig add_dev_quirk_vlph 0x2e51 0x0002 0x0000 0xffff UQ_HID_IGNORE
followed by unplugging and replugging the usb cable to your ups. If the values are correct, when you run "usbconfig -d ugen0.2 show_ifdrv" again, you should only see one line of output like so:
ugen0.2: <EVER ECO PRO AVR CDS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
The ugen0.2.0 should be gone.
Thanks, this was very helpfull. I had to modifiy command a bit, as I've noticed its add_dev_quirk_vplh not vlph and I changed pid (product id) to 0x0000. Now the second line is gone:
Now NUT starts without user=root just fine:
Feb 23 22:27:05 upsmon 20539 Communications with UPS ever established Feb 23 22:27:05 upsd 23193 User local-monitor@127.0.0.1 logged into UPS [ever] Feb 23 22:27:01 php 16832 /usr/local/sbin/acbupload.php: End of configuration backup to https://acb.netgate.com/save (success). Feb 23 22:27:01 upsd 23193 Startup successful Feb 23 22:27:01 upsd 23193 Connected to UPS [ever]: usbhid-ups-ever Feb 23 22:27:01 upsd 23193 listening on 127.0.0.1 port 3493 Feb 23 22:27:01 upsd 23193 listening on ::1 port 3493 Feb 23 22:27:00 usbhid-ups 21611 Startup successful
But soon after one minute or so:
Feb 23 22:28:15 upsmon 20539 Poll UPS [ever] failed - Driver not connected Feb 23 22:28:10 upsmon 20539 Communications with UPS ever lost Feb 23 22:28:10 upsmon 20539 Poll UPS [ever] failed - Driver not connected Feb 23 22:28:08 kernel pid 21611 (usbhid-ups), jid 0, uid 66: exited on signal 10 Feb 23 22:28:08 upsd 23193 Can't connect to UPS [ever] (usbhid-ups-ever): Connection refused
-
@tnowak said in NUT package:
I had to modifiy command a bit, as I've noticed its add_dev_quirk_vplh not vlph
Sorry, typo. I corrected the original post.
But soon after one minute or so:
Feb 23 22:28:08 kernel pid 21611 (usbhid-ups), jid 0, uid 66: exited on signal 10Congratulations, you are a double winner.
The post above regarding the CyberPower UPS units applies to you as well. -
@dennypage said in NUT package:
Congratulations, you are a double winner.
Wow, amazing! I deployed that workaround for the time being and it works reliably now! Looking forward for future nut package releases that solves this issue.
You're the man @dennypage! Thank you VERY much for your support that is extremely competent and helpful.
-
the "usbhid-ups" binary built from the FreeBSD nut-devel port you provided earlier this week to test looks to have solved the problem for me (or at least for those that have CyberPower UPSs). As of this morning eastern time, it's been running for over 72 hours with no more "exit on signal 10" errors in my system log file. Thanks for all your help in identifying the issue and that its already been fixed in the newer version of nut.
-
@shaffergr is this available form package manager now?
-
No. Denny provided me a build from nut-devel branch so that we could validate if the signal 10 issue was fix or not.
-
-
-
@dennypage I've been seeing logs like this:
Feb 25 19:37:13 gatekeeper kernel: pid 29800 (usbhid-ups), jid 0, uid 0: exited on signal 10 Feb 25 19:37:15 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected Feb 25 19:37:15 gatekeeper upsmon[28298]: Communications with UPS tripplite lost Feb 25 19:37:20 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected Feb 25 19:37:25 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected Feb 25 19:37:30 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected Feb 25 19:37:35 gatekeeper upsmon[28298]: Poll UPS [tripplite] failed - Driver not connected <goes on the same until manually restarted.>
setting
interruptonly
appears to have mitigated it. UPS is a Tripp Lite SMART1500LCD rack mount unit. It seemed to work fine prior to the last update. -
@jpp-0 I sent you the dev build of usbhid-ups. Please let me know if it works for you.
-
@dennypage Thanks sending the dev version, it looks to be working, it's been running for over 8 hours with all the extra config (
interruptonly
anduser=root
etc) removed. No crashes. It correctly detected power loss and power restored. If it fails laster I'll post and update but I'm not expecting it to as it would fine within minutes before. -
@dennypage can confirm
interruptonly
does the job as a workaround with my Cyberpower UPS. Many thanks. -
@jpp-0 I couldn't get the Smart1500 LCD I had to work if my life depended on it. I must have had a defective unit. I ended up returning it and getting a APC BGM1500B which worked right out of the box.
I couldn't get
offdelay=60
andondelay=90
to hold. It would hold the settings for 20 mins max then revert to default values.To top that off the UPS would run down until the battery died and never send shutdown command to my Netgate box.
Can you screen shot or post your settings. I'm interested to find out what actually works with that UPS. I killed myself for weeks until my return window was about to close before my autism would allow me to give up.
-
@whoami-tm right now I just have the defaults set on pfsense. My setup is a bit odd in that it should never get to shutdown becasue the generator / automatic transfer kicks in after 25 seconds and I have about a week's worth of propane on site.
I have by proxmox servers (the very originally named pxoxie and moxie, both nut clients) set to shutdown after 10 mins if for some reason the generator fails.
The pfsense box is not configured to shutdown. I'm running ram disk filesystems so I'm less worried about disk corruption and want to keep it running as long as possible.
I blew away all the config I had on pfSense trying to debug the crashes, I may add some complexity back but not for a while.
Lastly I would not buy Tripplite again it completely fails to give a decent runtime estimate (best guess is the power factor on modife sine wave is different enough from tru sine on the grid that it just get's confused).
-
This post is deleted! -
@whoami-tm have you tried this
[23.01-RELEASE][root@gatekeeper]/root: upsrw -s ups.delay.shutdown tripplite Username (root): admin Password: Enter new value for ups.delay.shutdown: 59 OK
sub in your ups name and get the password for
admin
from/usr/local/etc/nut/upsd.users
ups.delay.shutdown
seems to be the only value you can program but if I'm reading it correctly it should let you make it wait longer before powering off. -
I'm using a CyberPower UPS, and I'm experiencing the same signal 10 error. I've found the interruptonly setting to work until the USB issue is resolved.
If there is anything I can do to help/test a fix then let me know :-)
Anecdotally I've noticed my firewall's processor is running hotter than it used to, I don't think the CPU is idling properly not sure if anyone else is noticing a similar problem and if it is related in some way.
-
@dennypage I just wanted to thank you again sincerely for this post and for finding my erroneous post. This research has made the upgrade to pfSense+ 23.01 stable.
-
@lamaz You're welcome. Glad it's working for you.
-
-
-
-
Thanks for the work everyone has put into this so far.
Decided to upgrade from 2.6 CE to plus 23.01 today. Having the same issues as others are too. Looks to be with the usb driver. Started happening shortly after updrade completed.
I am getting the same results after adding root as a user.
Mar 8 21:53:35 pfSense upsd[9141]: Can't connect to UPS [eaton9130rm] (usbhid-ups-eaton9130rm): Connection refused Mar 8 21:53:35 pfSense kernel: pid 8842 (usbhid-ups), jid 0, uid 0: exited on signal 10 Mar 8 21:53:39 pfSense upsmon[1672]: Poll UPS [eaton9130rm] failed - Driver not connected Mar 8 21:53:39 pfSense upsmon[1672]: Communications with UPS eaton9130rm lost Mar 8 21:53:45 pfSense upsmon[1672]: Poll UPS [eaton9130rm] failed - Driver not connected Mar 8 21:53:50 pfSense upsmon[1672]: Poll UPS [eaton9130rm] failed - Driver not connected Mar 8 21:53:55 pfSense upsmon[1672]: Poll UPS [eaton9130rm] failed - Driver not connected
-
@trentk10 said in NUT package:
Mar 8 21:53:35 pfSense kernel: pid 8842 (usbhid-ups), jid 0, uid 0: exited on signal 10
Unfortunately, this is being hit by a lot of people with NUT 8.0. See this post for information.
-
-
@dennypage I seem to have a similar but possibly different problem.
My UPS is an Eaton Eclipse ECO 650 connected by USB to my Netgate-3100 running 23.01-RELEASE (arm) with NUT 2.8.0_2.
Note: the setup worked perfectly before my update to 23.01 and 2.8.0 for over 6 months, there have been no powercuts/surges or hardware changes.
As with others I am seeing repeated log entries from upsmon.
Mar 12 09:57:09 upsmon 80760 Poll UPS [EatonUPS] failed - Driver not connected Mar 12 09:57:04 upsmon 80760 Poll UPS [EatonUPS] failed - Driver not connected
If I filter my logs to upshid-ups I only see the following:
Mar 9 22:26:16 usbhid-ups 91631 Startup successful Mar 9 22:26:09 usbhid-ups 70838 Signal 15: exiting Mar 9 22:20:46 usbhid-ups 70838 Startup successful Mar 9 22:20:41 usbhid-ups 47718 Signal 15: exiting Mar 9 22:13:14 usbhid-ups 47718 Startup successful Mar 9 22:10:05 usbhid-ups 75991 Signal 15: exiting Mar 9 21:57:06 usbhid-ups 75991 Startup successful
If I filter the logs to upsd I see:
Mar 12 09:07:25 upsd 82791 Can't connect to UPS [EatonUPS] (usbhid-ups-EatonUPS): Connection refused Mar 12 09:02:25 upsd 82791 Can't connect to UPS [EatonUPS] (usbhid-ups-EatonUPS): Connection refused Mar 12 08:57:25 upsd 82791 Can't connect to UPS [EatonUPS] (usbhid-ups-EatonUPS): Connection refused Mar 12 08:52:25 upsd 82791 Can't connect to UPS [EatonUPS] (usbhid-ups-EatonUPS): Connection refused Mar 9 22:26:16 upsd 82791 Connected to UPS [EatonUPS]: usbhid-ups-EatonUPS Mar 9 22:26:14 upsd 82791 User local-monitor@::1 logged into UPS [EatonUPS] Mar 9 22:26:10 upsd 82791 Startup successful Mar 9 22:26:10 upsd 82791 Can't connect to UPS [EatonUPS] (usbhid-ups-EatonUPS): No such file or directory Mar 9 22:26:10 upsd 82791 not listening on 127.0.0.1 port 3493 Mar 9 22:26:10 upsd 82791 listening on ::1 port 3493 Mar 9 22:26:10 upsd 82791 listening on 127.0.0.1 port 3493 Mar 9 22:26:10 upsd 82791 not listening on 192.168.200.254 port 3493 Mar 9 22:26:10 upsd 82791 listening on pfsense.{internaldomainname} port 3493 Mar 9 22:26:09 upsd 62680 Signal 15: exiting Mar 9 22:26:09 upsd 62680 mainloop: Interrupted system call Mar 9 22:26:09 upsd 62680 User local-monitor@::1 logged out from UPS [EatonUPS]
This morning the failure occurred at 08:52 (from notification email):
8:52:27 UPS Notification from pfSense.irwazu.co.uk - Sun, 12 Mar 2023 08:52:27 +0000 Communications with UPS EatonUPS lost
My configuration is extra arguments to driver:
pollfreq=90
Additional configuration lines for upsmon.conf
RUN_AS_USER root
Additional configuration lines for ups.conf
user=root pollinterval=15
Other than using the "interruptonly" option is there anything I can do to resolve or help debug the cause? Is this likely the same issue as for CyberPower UPSs you've already identified?
Full logs of a restart of the UPS service are as follows:
Mar 12 10:05:19 upsmon 69168 Communications with UPS EatonUPS established Mar 12 10:05:16 upsd 70834 Connected to UPS [EatonUPS]: usbhid-ups-EatonUPS Mar 12 10:05:15 usbhid-ups 80232 Startup successful Mar 12 10:05:14 upsmon 69168 UPS EatonUPS is unavailable Mar 12 10:05:14 upsmon 69168 Poll UPS [EatonUPS] failed - Driver not connected Mar 12 10:05:14 upsd 70834 User local-monitor@::1 logged into UPS [EatonUPS] Mar 12 10:05:10 upsd 70834 Startup successful Mar 12 10:05:10 upsd 70834 Can't connect to UPS [EatonUPS] (usbhid-ups-EatonUPS): Connection refused Mar 12 10:05:10 upsd 70834 not listening on 127.0.0.1 port 3493 Mar 12 10:05:10 upsd 70834 listening on ::1 port 3493 Mar 12 10:05:10 upsd 70834 listening on 127.0.0.1 port 3493 Mar 12 10:05:10 upsd 70834 not listening on 192.168.200.254 port 3493 Mar 12 10:05:10 upsd 70834 listening on pfsense.irwazu.co.uk port 3493 Mar 12 10:05:09 upsmon 69168 Communications with UPS EatonUPS lost Mar 12 10:05:09 upsmon 69168 UPS [EatonUPS]: connect failed: Connection failure: Connection refused Mar 12 10:05:09 upsmon 69168 Startup successful Mar 12 10:05:08 upsd 82791 Signal 15: exiting Mar 12 10:05:08 upsd 82791 mainloop: Interrupted system call Mar 12 10:05:08 upsd 82791 User local-monitor@::1 logged out from UPS [EatonUPS] Mar 12 10:05:08 upsmon 80760 Signal 15: exiting Mar 12 10:05:07 upsmon 80760 Poll UPS [EatonUPS] failed - Driver not connected
-
@davidir Your log messages do not show anything particularly unusual. Signal 15 indicates that the usbhid-ups process was terminated via a kill signal. This is usually triggered by a package restart such was when your DHCP WAN address changes.
Btw, not sure what you are intending to do with the poll interval settings. Given that you are using a usb connection, there is a good reason to be setting these, particularly pollinterval in ups.conf which may negatively affect your shutdown. Unless you have a very concrete problem that you are fixing, I would recommend that you remove both of them. As well as the RUN_AS_USER setting in upsmon.conf.
-
I've received several requests for the dev build of usbhid-ups, so I thought I would upload the file here.
For reference, the shasum and sha256sum checksums of the unzipped file are:
49ce9131502bfb8b789ee97b7fb3fc81fc9f8fff usbhid-ups 999a2653559dbc50ecc8ba592a67587b1e307a1495f6e8ebbd3d8e90e3967133 usbhid-ups
If you use the file, please post and let me know if it resolves an issue for you.
-
@dennypage thank you very much for this. I loaded it up today and so far, it has continued to run for about 5 hours. I'll report back tomorrow to let you know if it hangs up overnight.
For other folks' information, I put the file Denny shared into /usr/local/libexec/nut replacing the file already there. (Be sure to make a copy of the original in case this doesn't work for you.) Make sure that the permissions are set to rwxr-xr-x (0755). Also I had to include "user=root" in the ups.conf section in pfSense.
Thanks again Denny.
-
-
Update - No issues overnight still running fine and serving my network as a NUT Server. Updated to the latest 2.7.0 Devel build this morning and UPS service started up without a hiccup. Very pleased.
FYI, I have a CyberPower CP1500PFCLCD and it is connected to my pfSense box via the supplied USB cable.
-
@dennypage said in NUT package:
I've received several requests for the dev build of usbhid-ups, so I thought I would upload the file here.
For reference, the shasum and sha256sum checksums of the unzipped file are:
49ce9131502bfb8b789ee97b7fb3fc81fc9f8fff usbhid-ups 999a2653559dbc50ecc8ba592a67587b1e307a1495f6e8ebbd3d8e90e3967133 usbhid-ups
If you use the file, please post and let me know if it resolves an issue for you.
So far so good for me with a Trip Lite SMART1500LCD! It's only been an hour, but it has stayed connected and my logs are no longer getting spammed by disconnects/connects.
-
-
-
@offstageroller said in NUT package:
@dennypage said in NUT package:
I've received several requests for the dev build of usbhid-ups, so I thought I would upload the file here.
For reference, the shasum and sha256sum checksums of the unzipped file are:
49ce9131502bfb8b789ee97b7fb3fc81fc9f8fff usbhid-ups 999a2653559dbc50ecc8ba592a67587b1e307a1495f6e8ebbd3d8e90e3967133 usbhid-ups
If you use the file, please post and let me know if it resolves an issue for you.
So far so good for me with a Trip Lite SMART1500LCD! It's only been an hour, but it has stayed connected and my logs are no longer getting spammed by disconnects/connects.
I'm at about 8 hours now, with no issues to report. All is well again with my USB connection to my UPS!
-
Hey guys. Mind if I join the party?
I upgraded from from 2.6 CE to 23.01 plus today, to get support for the 2.5Gbps nics in my firewall.
Unfortunately after the upgrade, NUT started failing because it couldn't claim the USB device:
Can't claim USB device [051d:0003]@0/0: Other error
UPS is a APC Smart-UPS 1500.
Did a little searching, found it was a permission error, and eventually found this thread.
Looks like I found the right place.
I've gone back through this thread about a month and started reading.
Adding
user=root
to ups.conf got things going again. However, I'd call that a workaround. If I read right, looks like I need to wait for the next release of NUT for a real fix.At the moment I am not using @dennypage's custom usbhid-ups. If my UPS does not stay online, I'll apply it and post results.
I'll be keeping an eye on this thread for new information.
-
@knight-of-ni said in NUT package:
Adding user=root to ups.conf got things going again. However, I'd call that a workaround. If I read right, looks like I need to wait for the next release of NUT for a real fix.
While the next release of nut is expected to address the CyberPower issue, it will not address the APC issue. The APC issue is a usb quirk issue, and this requires a new version of the kernel in pfSense to permanently resolve. I don't expect that to happen soon.
See here for further details of the APC issue. I recommend using the /boot/loader.conf.local solution if you can take a reboot.
-
-
@dennypage said in NUT package:
If you use the file, please post and let me know if it resolves an issue for you.
Your version of
usbhid-ups
has been working fine with my CyberPower for 48 hours now. Thanks. -
@dennypage said in NUT package:
If you use the file, please post and let me know if it resolves an issue for you.
I was experiencing the same issue and using this version of
usbhid-ups
has resolved the issue. Many thanks, that was driving me NUTS (pun intended) -
@dennypage Quick question: is the NUT package somehow dependent on other services or is integrated into a service hook since 23.01? After upgrading I have NUT alert messages all over the place for things that are completely unrealted to the UPS.
E.g. resetting or reconfiguring a gateway, doing configurations on WAN or VPNs if the interface is assigned etc. all seem to trigger "problems" with NUT loosing and regaining connection to the UPS. UPS attached is an APC BackUPS via USB that ran well before without being trigger happy with notifications when interface/gateway/routing things are happening. Now just touching some of those things seem to trigger a connection loss from NUT. Really confusing
Cheers
\jens -
@jegr said in NUT package:
E.g. resetting or reconfiguring a gateway, doing configurations on WAN or VPNs if the interface is assigned etc. all seem to trigger "problems" with NUT loosing and regaining connection to the UPS.
pfSense restarts package services when WAN interfaces disconnect or reconnect. Yes, this is unnecessary for some services, such as NUT with a USB connection, but there is no way for pfSense to know which services actually need to be restarted. It's always been this way.
What you would expect to see is NUT restart once when the interface goes down, and once again when the interface comes back up. Whether or not you see NUT reporting a lost connection or not depends upon the order and speed of shutting down the various processes involved (usbhid-ups, upsd, upsmon).
-
@dennypage said in NUT package:
pfSense restarts package services when WAN interfaces disconnect or reconnect. Yes, this is unnecessary for some services, such as NUT with a USB connection, but there is no way for pfSense to know which services actually need to be restarted. It's always been this way.
That may very well be, but before 23.01 there were no problems with NUT overactively reporting down/ups at those times whereas now they pop up almost every time when someone is editing something on interfaces, routing gateways etc.
Just wanting to check if there's anything that has changed while converting stuff to PHP 8.1 or anything. Wouldn't be the first :)