NUT 2.8.1 when?

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.

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.