On Jan 6, 2015, at 3:44 PM, Steve Ballantyne <[email protected]> wrote:
> Does this snippet of a failure tell you anything? Is there something > I can do to tell the libusb to wait a little longer for the device to > come back? > > 3118.555755 libusb_get_interrupt: Connection timed out > 3118.557454 libusb_get_interrupt() returned 0 instead of 8 while > sending 3a 53 ac 0d 00 00 00 00 '.S......' These timeouts are controlled by some #defines at the beginning of the driver: https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L231 Here is the actual loop: https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L527 So it is trying ten times to send, and for each send attempt, it tries to receive ten times. These numbers are somewhat arbitrary, and are probably tuned more for the OMNIVS1000, but feel free to adjust them, and let me know what you find out. > 3128.241548 libusb_set_report() returned 0 instead of 8 > 3128.243292 Error reading 'V' value: Device detached? (error 0: > error sending control message: Broken pipe) > 3128.244404 Reconnect attempt #1 This one is different - "Broken pipe" does mean an actual disconnect signal, so there is no getting around this plus accompanying the "data stale" message. However, for the notifications, you could use "upssched" to only notify you if the UPS is disconnected for longer than the usual reconnection time. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
