Troubleshooting eventual disconnections (Data stale)

There are numerous reports in the issue tracker, mailing list, and internet discussions about various vendors' USB devices losing connection over time. CyberPower (CPS) brand is mentioned maybe more often that others, but is certainly not alone.

Discussions at:

• https://wiki.archlinux.org/title/Network_UPS_Tools#CyberPower_UPS_keeps_disconnecting/reconnecting
• https://raspberrypi.stackexchange.com/questions/66611/nut-cyberpower-data-stale
• https://nmaggioni.xyz/2017/03/14/NUT-CyberPower-UPS/
• https://serverfault.com/questions/994338/how-can-i-fix-my-ups-repeatedly-disconnecting-and-reconnecting/995122#995122
• https://github.com/networkupstools/nut/issues/475
• https://github.com/networkupstools/nut/issues/786
• https://github.com/networkupstools/nut/issues/1029
• https://forum.netgate.com/topic/4220/trouble-with-nut-and-backups-xs-1500-via-usb/4?lang=en-US

...and countless others suggest that certain controllers may disconnect (often via USB reset) if there was no interaction for more than some time, e.g. 20 sec, while others may be overwhelmed by interactions too frequent and intense, causing the UPS controller to stall or reboot.

Such situations may need to balance pollinterval (max delay between data gathering cycles, default 2s) to be frequent enough to keep the connection alive with their model, and modest enough to not outstay the welcome. Note there is also pollfreq for usbhid-ups (full vs. partial updates, default 30s); see manpages about equivalent settings for other drivers where available.

• CPS devices can benefit from the pollonly flag in usbhid-ups

There was some work in the lead-up to NUT v2.8.0 release and/or soon after it, which should have improved the drivers' own ability to detect a connection loss/freeze and try to reconnect, e.g. PR #1335, PR #1430, PR #1632, and possibly others.

Also note that on some platforms it is possible to programmatically command the USB hardware (hubs, ports) to reset.

• Linux: in current NUT source tree there is a contributed usb_resetter instruction for the third-party script: https://github.com/networkupstools/nut/blob/master/scripts/usb_resetter/README.md
  • ...or conjure up something of that sort with usbutils package and its usbreset tool, see https://wiki.ubuntuusers.de/usbreset/
• Solaris/illumos: see an example use of cfgadm (as part of script to detect a hung driver and recycle the connection) in https://github.com/networkupstools/nut/blob/master/docs/solaris-usb.txt

Per https://github.com/networkupstools/nut/issues/2347#issuecomment-2035312831, if you regularly see messages like:

Apr  3 19:38:58 Tower usbhid-ups[13220]: nut_libusb_get_report: Input/Output Error
Apr  3 19:39:00 Tower usbhid-ups[13220]: Reconnecting. If you saw
    "nut_libusb_get_interrupt: Input/Output Error" or similar message in the log
    above, try setting "pollonly" flag in "ups.conf" options section for this driver!

...these messages are often caused by powertop --auto-tune (on Linux, but equivalents exist for other platforms) which is known to modify the USB power management settings and cause such input/output errors due to hibernating of USB-connected UPS devices at times when they should communicate with NUT. Consider setting up the power management manually, with the ports used for UPS communications being exempt from power-saving.

A different situation may concern MGE/Eaton devices specifically with USB ID 0463 and certain range of Linux kernel versions (and possibly other platforms) which introduced an "USB quirk" which helped with some devices and broke communications with others. For more details, see:

• https://github.com/networkupstools/nut/issues/630
• https://github.com/networkupstools/nut/commit/a6b29f36fbc6acc8d2e2221dbf7c1053392232b5