<div dir="ltr"><div class="gmail_default"><font face="tahoma, sans-serif">​Increasing 'pollinterval' to 5s did not seem to work. I've attached the relevant portions of the upsdrvctl debug. I believe the message we're looking at is:</font><br><br><div class="gmail_default"><font face="tahoma, sans-serif">9528.632309<span class="gmail-Apple-tab-span" style="white-space:pre">   </span>libusb_get_report: error sending control message: Device or resource busy</font></div><div class="gmail_default"><font face="tahoma, sans-serif">9528.632318<span class="gmail-Apple-tab-span" style="white-space:pre">      </span>Can't retrieve Report 16: Device or resource busy</font></div><font face="tahoma, sans-serif">9528.632326<span class="gmail-Apple-tab-span" style="white-space:pre">     </span>Got disconnected by another driver: Device or resource busy​</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 8:35 AM, Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com" target="_blank">clepple@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Oct 12, 2016, at 9:07 AM, Lane Russell wrote:<br>
><br>
> Apologies, I did mean upsmon.conf. ups.conf "pollinterval" is not called out, so I assume it's using the default of 2s. "pollfreq" and "pollfreqalert" are both set to 10s in upsmon.conf at the moment. "deadtime" is set to 30s.<br>
<br>
No problem, the names are a bit confusing.<br>
<br>
> I've attached the output of "sudo /lib/nut/usbhid-ups -a ups -DDD".<br>
<br>
I forgot to mention, the list limits messages to ~40 KB, so for the next time, please compress the log ("gzip -9" or similar).<br>
<br>
However, we would need the log at the point where the UPS disconnects. (The beginning looks normal.) If the compressed log is still large, let me know and we can trim out the interesting part.<br>
<br>
> Forgive me, but I've never rebuilt a driver, and I'm not sure what the libusb branch is. Could you elaborate? Or perhaps this issue won't be related to that and we won't have to go down that path.<br>
<br>
There are still a few things to try before then, and they are somewhat related to what the log looks like at the point when the driver declares the data stale.<br>
<br>
Also, maybe I can get things set up again to build packages for an Ubuntu PPA.</blockquote></div><br></div>