NUT 2.8.1 when?

Gertjan

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.

keyser

@Gertjan First interesting info:

ugen1.2: <EATON 5S> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (20mA)

{
UE_CONTROL_OK : 8949
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 0
UE_INTERRUPT_OK : 0
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL : 0
UE_INTERRUPT_FAIL : 5604
}

Seems I have no successfull interrupts… wonder what that indicates ?

keyser

@Gertjan DEADTIME has no effect on the notifications about the unavailable UPS when the 5 sec USB disconnect/reconnect happens

keyser

@Gertjan Regardless what I do I cannot get usbdump to output any data. Even “usbdump -v” with no specifics does not output anything.

keyser

@Gertjan When the disconnect happens, I get the following in my firewall log:

2024-04-07 04:09:24.000
notify_monitor.php: Message sent to xxx@xxxxxxxxxx.xx OK
2024-04-07 04:08:54.000
Communications with UPS eaton5sc established
2024-04-07 04:08:52.000
UPS [eaton5sc] data is no longer stale
2024-04-07 04:08:52.000
notify_monitor.php: Message sent to xxx@xxxxxxxxxx.xx OK
2024-04-07 04:08:49.000
Communications with UPS eaton5sc lost
2024-04-07 04:08:49.000
Poll UPS [eaton5sc] failed - Data stale
2024-04-07 04:08:48.000
ugen1.2: <EATON 5S> at usbus1
2024-04-07 04:08:47.000
libusb1: Could not open any HID devices: no USB buses found
2024-04-07 04:08:46.000
ugen1.2: <EATON 5S> at usbus1 (disconnected)
2024-04-07 04:08:45.000
libusb1: Could not open any HID devices: insufficient permissions on everything
2024-04-07 04:08:45.000
Data for UPS [eaton5sc] is stale - check driver

dennypage

@keyser said in NUT 2.8.1 when?:

@Gertjan Regardless what I do I cannot get usbdump to output any data. Even “usbdump -v” with no specifics does not output anything.

I think a slight mistake. The output that shown for "usbconfig dump_stats" is actually the output for "usbconfig" (without dump_stats).

FWIW, since you are able re-connect almost immediately to the ups, I don't believe that you will be able to effectively capture the output of usbconfig by hand at the appropriate moment to provide meaningful information. And if you did, I suspect that it would boil down to "there is no usb ups device."

The command usbdump is a slightly different thing. This is something that you would want running before, and during, the time when the disconnect actually happens. Not sure that this is worth the effort though as the most likely outcome is again "there is no usb ups device."

You can certainly run usbdump, but it would probably be more productive to run the driver in debug mode (see later posts in the main 2.8.1 thread for examples). However based upon what you have posted, the most likely outcome is again "there is no usb ups device."

You might want to explore the Advanced section items I suggested a few posts above.