NUT 2.8.1 when?

Gertjan

Here NUT Package (2.8.1 and above) : grab a copy and join the test group.

dennypage

@keyser, The ng folk have requested testing of the new package prior to a general release. It would be very beneficial if you would be able to help test. Thanks!

keyser

@dennypage Sorry about the late reply. I justed wanted to confirm that 23.09 and the NUT 2.8.0.2 package still would loose connection to my eaton UPS intermittently (and then not come back). It just did now, so I’ll upgrade to the Aarch64 build of your package now and keep this post updated if anything unexpected happens.

dennypage

@keyser The problems originate from NUT itself rather than FreeBSD, so you would expect 2.8.0_2 to behave the same regardless of 23.05/23.09.

The new package build cannot be installed in 23.05.1 as it depends upon newer libraries that are only present in 23.09+ like OpenSSL 3.

keyser

@dennypage Noted - I installed your package, and for now it works fine. I’ll post back if it looses UPS status permanently whenever the short USB disconnects happen.

dennypage

@keyser Appreciate it if you would update me either way. Thanks.

keyser

@dennypage Just had my first USB disconnect to the UPS, and the new package stayed up and are still reporting all the UPS settings after the UPS came back. So everything seems to work as it should now (apart from the USB disconnects).

Is there any way to set a threshold delay on “lost communications” notifications from pfsense/nut, so I don’t get notified every time a USB disconnect happens?
It’s back within 5 sec, so if a 10 sec threshold could be configured everything would be peachy :-)

keyser

@keyser Had a couple of disconnects the last few days, but the NUT package with the Devel usbhid works as intented.
My memory and CPU usage telemetry relveals no increase or anomalies in usage, so everything seems to work as intended.

I hope you can figure some kind of workaround threshold setting to notifications on USB disconnects?
Obviously I want the notification if the UPS really goes bye bye, but if it could be configured to require the new state to persist for more than 10 sec before sending a notification, everything would be great.

dennypage

The new pfSense NUT package is out for 23.09 and 2.7.1. We had a little oops at the end, and the published version of the pfSense package itself shows as 2.8.2, but the underlying NUT package is the same as the test version.

dennypage

@keyser said in NUT 2.8.1 when?:

Had a couple of disconnects the last few days, but the NUT package with the Devel usbhid works as intented.

Questions:

Is this a CyberPower, or a different manufacturer?
What Extra Arguments to driver do you have (if any)?
Have you tried different USB cables? Different USB ports?
Have you tried the interruptonly option?

keyser

@dennypage Its a Eaton 500S and I have tried several new cables. I cannot test another USB port as it is a SG-2100.
But the UPS does not have the same issue connected directly to my Windows machine or a Raspberry Pi.
The interrupt only option probably works, but I have not tested it.
Since it only disconnects about once or twice a day on average I have lived with it so far. (typically it goes for days without issues and then suddenly have 3-8 disconnects during one day).

The only extra arguments are on and offdelay. They have no impact on the disconnects.

dennypage

@keyser said in NUT 2.8.1 when?:

Its a Eaton 500S and I have tried several new cables. I cannot test another USB port as it is a SG-2100.
But the UPS does not have the same issue connected directly to my Windows machine or a Raspberry Pi.

FWIW, another test you can do is to put a USB hub between the host and the UPS. This sometimes helps when signal levels are marginal.

keyser

@dennypage Hi - We got a subgroup for UPS tools now on the forum - whoot whoot ;-)

Have you given any more consideration to creating a “notification delay” threshold in your UPS package? It would solve a lot of issues for people with “needless” notifications about USB disconnect/reconnect that seems to happen on quite a few different UPS models/vendors.

A simple cofigurable “timer” in seconds on how long a disconnect must persist before a notification is triggered would be great.

dennypage

@keyser said in NUT 2.8.1 when?:

Have you given any more consideration to creating a “notification delay” threshold in your UPS package? It would solve a lot of issues for people with “needless” notifications about USB disconnect/reconnect that seems to happen on quite a few different UPS models/vendors.

A simple cofigurable “timer” in seconds on how long a disconnect must persist before a notification is triggered would be great.

I haven't really. I think communication issues, such as disconnect and reconnect tries, are better handled in the NUT driver itself. Most of the commonly used drivers have provision for this.

What driver and UPS are you using that you are having issue with?

keyser

@dennypage Yeah, I kind'a agree. It just seems there are lots of users with different UPS's and pfSense boxes than me that has the same problem. So I was thinking perhaps FreeBSD has about the same quality USB implementation as it does WiFi and LTE.. I have a USB disconnect on average once a day. tried everything (new cables, and so forth).
I have a SG-2100 Netgate box and:

Variable Value
battery.charge 100
battery.charge.low 20
battery.runtime 3698
device.mfr EATON
device.model 5S 550
device.type ups
driver.debug 0
driver.flag.allow_killpower 0
driver.name usbhid-ups
driver.parameter.offdelay 60
driver.parameter.ondelay 120
driver.parameter.pollfreq 30
driver.parameter.pollinterval 2
driver.parameter.port auto
driver.parameter.synchronous auto
driver.state updateinfo
driver.version 2.8.0.1
driver.version.data MGE HID 1.46
driver.version.internal 0.52
driver.version.usb libusb-1.0.0 (API: 0x1000102)
input.frequency 50.0
input.voltage 232.0
outlet.1.desc PowerShare Outlet 1
outlet.1.id 2
outlet.1.status on
outlet.desc Main Outlet
outlet.id 1
output.frequency 50.0
output.voltage 230.0
ups.beeper.status enabled
ups.delay.shutdown 20
ups.delay.start 30
ups.firmware 01.14.0019
ups.load 5
ups.mfr EATON
ups.model 5S 550
ups.power.nominal 550
ups.productid ffff
ups.realpower 22
ups.status OL
ups.timer.shutdown -1
ups.timer.start -1
ups.vendorid 0463

Edit: The UPS works fine on other boxes, and NUT also reconnects the UPS within 5 sec of a disconnect. So everything works fine. It just the annoying notification that would be great to get rid of.

Gertjan

@keyser said in NUT 2.8.1 when?:

The UPS works fine on other boxes

And it would probably work even better on the device for which is was meant to be used : your PC.
Not that it will behave any better, but the default 'Windows 11' UPS driver doesn't signal any temporary USB failures so you think : it works great.

Lets put upfront also this : an UPS is not created to protect our devices. Its a device that is made so the constructor can make money. UPSs are not all made the same. As soon as the "will do for a PC" is reached it's good enough, they will sell them.
And what do we do , We hook them up to a trigger happy device called pfSense +NUT that will signal any disruption over the USB connection. And who said an USB connection is that stable ?Is the cable well electrically isolated ? Are the contacts that good ?

For myself, I've always used 'network' UPS from APC. Which means that the average UPS costs hundreds of €, not '99 $'. Some of my UPS don't have a USB connector, and if there is one, it's for upgrading the firmware. They is snmp and have a serial connection, as speed isn't an thing, but a liable connection physical electrical and information transmission IS a thing.

I've been using several USB UPS APC and 'never' had issues with them.
I don't have any experiences with any other brand ....

All this is IMHO of course ^^

keyser

@Gertjan I do not disagree and understand the issues. I'm just asking if it is worth implementing that feature in NUT since it seems its a widespread issue with many UPSs

Gertjan

@keyser

Add DEADTIME : https://networkupstools.org/docs/man/upsmon.conf.html
upsmon.conf : the first "Additional configuration lines for upsmon.conf"

I presume you use the "usbhid-ups" default USB driver. https://networkupstools.org/docs/man/usbhid-ups.html : I couldn't find useful tips there.

[24.03-BETA][root@pfSense.bhf.tld]/root: usbconfig dump_stats
ugen0.1: <Intel XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)

.....

ugen0.2: <American Power Conversion Back-UPS XS 700U FW:924.Z5 .I USB FW:Z5> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (24mA)

{
UE_CONTROL_OK : 538423
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 0
UE_INTERRUPT_OK : 81522
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL : 0
UE_INTERRUPT_FAIL : 0
}

This shows me (I think) the number of correct USB packets.

If your UPS is on "usbus0.2" (see above) :

usbdump -v usbus0.2

this will log the packets - and show info about the connection.
Now, log to a file, and wait until the driver looses contact, and see what happened ....

edit :

And the title of the thread became deprocated.
Its now : NUT 2.8.2 when?

keyser

@Gertjan Hmm, I’ll test the DEADTIME parameter, but I assume the notification is not coming from UPSMON client but rather from the UPSD server that runs and controls the UPS. But I could be mistaken.
I’ll also take a look at your USB suggestions to see If I can get some additional valuable info.

I’ll post back once I know more.

dennypage

@keyser said in NUT 2.8.1 when?:

Yeah, I kind'a agree. It just seems there are lots of users with different UPS's and pfSense boxes than me that has the same problem.

FWIW, I think most of the "I have disconnect issues" were the result of the various USB bugs introduced in NUT 2.8.0.

In your specific case, on the software side the first thing I would try is setting the reconnect time:

waitbeforereconnect=5. This goes would go in the Extra Arguments to driver section. You can experiment with larger or smaller values (1-15). The default is 0.

I would also relax the pollinterval value:

pollinterval=5. This goes into the "Additional configuration lines for upsmon.conf" section. You can experiment with larger values. The default is 2.

If you increase the pollinterval significantly, say 10 or more, you should also increase pollfreq:

pollfreq=60. This goes would go in the Extra Arguments to driver section. The default is 30.

Last resort, I would also try setting the pollonly flag:

pollonly. This goes would go in the Extra Arguments to driver section. The default is disabled.

On the hardware side, you can try introducing a USB hub in-between the host and the UPS. This often masks questionable USB implementations. A powered hub is usually better.