<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#0070C0">Charles and Wolfy,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">Thanks for the replies.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">I added some responses below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">I think I got the driver debugging right, but let me know if it is off.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">I should note:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">The CentOS 7.6 machine I have been testing with is a virtual machine (running on VMware ESXi 7.6). At least 1 customer and I have seen the same issue on VMs and physical boxes, so I don’t think that matters,
but if it does let me know.<o:p></o:p></span></p>
<div style="mso-element:para-border-div;border:none;border-bottom:dotted windowtext 3.0pt;padding:0in 0in 1.0pt 0in">
<p class="MsoPlainText" style="border:none;padding:0in"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">“This is a little off-topic, but I would like to point out that not including a machine-readable serial number in the USB device descriptor makes it difficult for people to reliably
use two or more UPSes on a single *nix system. Due to some complications with the way that USB devices are opened in libusb, there is no easy way to "open the next unused USB device", so we recommend that people match against the serial number.”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">Noted. I’ll kick this around internally and follow up. I know other units we make report the serial number. Maybe it’s a 2012 thing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<pre>“It would be interesting to see the debug log from usbhid-ups as well. It would give a little more context to the kernel errors. I haven't used a physical CentOS or RedHat system in a while, so I am not sure of the specifics needed to just stop the usbhid-ups driver, but then you can restart it with a few "-D" flags (3 should be sufficient for this kind of problem) and "-a TrippLiteUPS" to match this configuration. Please compress any log files (gzip preferred; zip works).”<o:p></o:p></pre>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#0070C0">Attached. This is with the settings and udev rules mentioned in the earlier. I can remove and redo if useful.<o:p></o:p></span></p>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>“pollinterval defaults to 2, and to be honest, for most other UPSes, we suggest that people raise the value (since many UPSes do not update their filtered values more frequently than that anyway).”<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal"><span style="color:#0070C0">Good to know on the default “2”. Reading upsmon.conf, I thought it was related to “POLLFREQ” which defaults to 30.
<o:p></o:p></span></p>
<pre><o:p> </o:p></pre>
<pre> “Do you know how frequently the Windows software polls the UPS?” <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal"><span style="color:#0070C0">For our PowerAlert Local software, generally we do half a second for USB (I’d need to check if that holds for all protocols, but I cannot think of any exceptions off the top of my head). In this particular case
we’ve just been testing with baked-in Windows Power Options as a reference point here, so I’ll need to look into how frequently Windows polls.<o:p></o:p></span></p>
<pre><o:p> </o:p></pre>
<pre>“Should this be applied to other models as well, or just protocol 2012?”<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal"><span style="color:#0070C0">I’ll dig into that and confirm. I’m not entirely convinced it is a protocol issue, but it very well could be.<o:p></o:p></span></p>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>“The 62-nut-usbups.rules file looks pretty standard. Do you know if the changes to 42-usb-hd-pm.rules are needed? It seems like none of the USB devices would have the right permissions if 62-nut-usbups.rules isn't sufficient (though this happened in Debian once).”<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal"><span style="color:#0070C0">My means of testing wasn’t the most rigorous, but I did try to use variable isolation with these changes and some other changes. I could not make the drops stop without having all 3 of these changes present.
I believe a web search lead me to this udev rule so I’ll dig up the link for context.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<pre><span style="color:#0070C0">“</span>Note that NUT 2.7.4 has been out for some time now.”<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal"><span style="color:#0070C0">Wolfy nailed this one, I just installed whatever the repository gave me. Should I test with 2.7.4?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<pre><o:p> </o:p></pre>
<pre>“Each USB vendor ID generally gets their own source file, so we could add a special case to drivers/tripplite-hid.c. As mentioned earlier, if you know that this will be a problem across all protocol 2012 UPSes, we can check for that ID.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I will say that there is a bit of a logjam in the release pipeline, due to some (unnecessary, IMHO) deprecation of libusb-0.1: <a href="https://github.com/networkupstools/nut/issues/300">https://github.com/networkupstools/nut/issues/300</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>So it's unclear when a code change will get to users. The configuration file changes should work in the mean time.”<o:p></o:p></pre>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#0070C0">Cool, action item me to follow up with confirmation of the protocol as a valid means of identifying where this is needed.<o:p></o:p></span></p>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>“I thought we did, but maybe I am confusing it with protocol 3016 devices. We actually added a lot of the protocol 2012 devices to the hardware compatibility list based on the test results that Eric provided, so I assume they worked then (about six years ago).<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The protocol 3016 devices (in particular, the SMART1500LCDT and OMNI1500LCDT) sometimes don't even stay on USB long enough to read a USB descriptor, and this does seem correlated with newer motherboards. Example: <a href="https://github.com/networkupstools/nut/issues/577">https://github.com/networkupstools/nut/issues/577</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>From where I stand, there really shouldn't be anything that a user-space program (like a NUT driver) can do that should be able to cause a USB device to disconnect during normal polling. (Aside from firmware updates, which we don't attempt.) That said, I recognize that USB Phy layer problems can be hard to diagnose, and power management can compound the issue.”<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal"><span style="color:#0070C0">Interesting threads. Are you still seeing issues with LCDTs or have they subsided?
<o:p></o:p></span></p>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>“Some users prefer not to post the entire serial numbers from their UPS when reporting issues. Is there a convention for the serial number digits such that we can ask for just the first few digits, and get an idea as to whether the problem is limited to a given hardware or firmware revision? There seems to be a firmware revision buried in the HID descriptor for some models, but I don't know how to interpret it, and some of these connection problems present themselves before the UPS can return that HID report.”<o:p></o:p></pre>
<pre><span style="color:#0070C0"><o:p> </o:p></span></pre>
<p class="MsoNormal"><span style="color:#0070C0">Our serial numbers break down like this:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><a href="https://www.tripplite.com/support/identify-products"><span style="color:#0070C0">https://www.tripplite.com/support/identify-products</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">If they give you the first 13 characters of the serial number, you’d know the SKU and the datecode without having the full serial number. Firmware isn’t inherently baked into that though. i.e. you could have
the same firmware on different SKUs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">Does this help at all?<o:p></o:p></span></p>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>“Although these models are not as common, we still hear from users with non-HID-PDC-based USB devices (and some serial UPSes as well). Publicly-available protocol documents would help us write better drivers for those devices. If not, a better way to identify models with proprietary protocols would be useful.” <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal"><span style="color:#0070C0">Does publicly available protocol = needs to be accessible to anyone
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">Or<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">We provide you with protocol docs if you agree not to share?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">I can look into the latter. I feel like we should be able to help here.<o:p></o:p></span></p>
<pre><o:p> </o:p></pre>
<pre>“Another thing is considering how users get started with NUT. Sometimes a user inherits an UPS on a given system, and they want to set up NUT to monitor it. Ideally, we'd like to have a way for them to quickly triage whether a particular UPS model will work, and before they have NUT installed, they will likely have "lsusb" or similar tools to enumerate devices. Other times, a user is replacing another UPS, and they want to know which models are supported by NUT before purchasing one. In both of those cases, more information about how USB IDs map to models can help smooth out those processes. At the moment, we manually add each protocol number to the usbhid-ups driver when a user tries an UPS that isn't listed already. If there were a convention that all USB idDevice values in a certain range were going to be HID PDC compliant, we could change the default from opt-in to enabled-by-default (but we wouldn't want the UPS driver to try to control a USB hub).”<o:p></o:p></pre>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">Let me kick this around. If we were able to say: USB UPSes with IDs from “09ae:XXXX” to 09ae:YYYY” are PDC compliant, would that be enough?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">Topically the problem I can think of is determining if this holds for older units (I’ll dig into this).
<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Thank you,<o:p></o:p></p>
<p class="MsoPlainText">David Zomaya<o:p></o:p></p>
<p class="MsoPlainText">1111 W. 35th Street | Chicago, IL 60609 USA<o:p></o:p></p>
<p class="MsoPlainText">david_zomaya@tripplite.com<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: Charles Lepple <clepple@gmail.com> <br>
Sent: Monday, June 17, 2019 9:28 PM<br>
To: David Zomaya <David_Zomaya@tripplite.com><br>
Cc: nut-upsdev@alioth-lists.debian.net; Jonathan Manzanilla <Jonathan_Manzanilla@tripplite.com>; Eric Cobb <Eric_Cobb@tripplite.com><br>
Subject: [EXTERNAL] Re: [Nut-upsdev] Fixing Drops With SMART1500LCDXL & USB-HID Driver</p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">This is an EXTERNAL email. Please take a moment and think before clicking any links or opening any attachments from this email. If suspicious, please forward to
<a href="mailto:ishelpdesk@tripplite.com"><span style="color:windowtext;text-decoration:none">ishelpdesk@tripplite.com</span></a> for review.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">______________________________________________________________________<o:p></o:p></p>
<p class="MsoPlainText">On Jun 17, 2019, at 3:00 PM, David Zomaya <<a href="mailto:David_Zomaya@tripplite.com"><span style="color:windowtext;text-decoration:none">David_Zomaya@tripplite.com</span></a>> wrote:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Hi Network UPS Tools Support,<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> I’m not sure if this is a question for the “user group” or the developer group”.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The config files will be useful for -users, but I'd say the development list is probably better for discussing potential changes.<o:p></o:p></p>
<p class="MsoPlainText"><o:p></o:p></p>
<p class="MsoPlainText">> My name is David Zomaya and I work at Tripp Lite in our technical support department. Copied on this email are Eric Cobb from our Product Management group & Jonathan Manzanilla tech support subject matter expert for our single phase
UPS product lines. <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I recognize Eric's name from a few years ago - he emailed some detailed test results with NUT connecting to various Tripp-Lite models. Hi, Eric!<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> Recently, we received a complaint about our SMART1500LCDXL dropping and reconnecting in different Linux Operating Systems.A fter some in-house testing, the behavior seems to be reproducible on a number of different *nix operating systems
(Windows seems fine). Here’s an example of the drops in /var/log/messages (I’ll use CentOS 7.6 as my reference point throughout this email):<o:p></o:p></p>
<p class="MsoPlainText">> May 29 19:25:27 localhost kernel: usb 2-2.1: new low-speed USB device
<o:p></o:p></p>
<p class="MsoPlainText">> number 6 using uhci_hcd May 29 19:25:27 localhost kernel: usb 2-2.1:
<o:p></o:p></p>
<p class="MsoPlainText">> New USB device found, idVendor=09ae, idProduct=2012 May 29 19:25:27
<o:p></o:p></p>
<p class="MsoPlainText">> localhost kernel: usb 2-2.1: New USB device strings: Mfr=1, Product=2,
<o:p></o:p></p>
<p class="MsoPlainText">> SerialNumber=0<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">This is a little off-topic, but I would like to point out that not including a machine-readable serial number in the USB device descriptor makes it difficult for people to reliably use two or more UPSes on a single *nix system. Due to
some complications with the way that USB devices are opened in libusb, there is no easy way to "open the next unused USB device", so we recommend that people match against the serial number.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> May 29 19:25:27 localhost kernel: usb 2-2.1: Product: Tripp Lite UPS
<o:p></o:p></p>
<p class="MsoPlainText">> May 29 19:25:27 localhost kernel: usb 2-2.1: Manufacturer: Tripp Lite
<o:p></o:p></p>
<p class="MsoPlainText">> May 29 19:25:27 localhost kernel: hid-generic 0003:09AE:2012.0004:
<o:p></o:p></p>
<p class="MsoPlainText">> hiddev0,hidraw1: USB HID v1.10 Device [Tripp Lite Tripp Lite UPS ] on
<o:p></o:p></p>
<p class="MsoPlainText">> usb-0000:02:02.0-2.1/input0 May 29 19:25:29 localhost upsd[6287]: UPS
<o:p></o:p></p>
<p class="MsoPlainText">> [TrippLiteUPS] data is no longer stale May 29 19:25:29 localhost upsd:
<o:p></o:p></p>
<p class="MsoPlainText">> UPS [TrippLiteUPS] data is no longer stale May 29 19:25:45 localhost
<o:p></o:p></p>
<p class="MsoPlainText">> kernel: usb 2-2.1: USB disconnect, device number 6<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">It would be interesting to see the debug log from usbhid-ups as well. It would give a little more context to the kernel errors. I haven't used a physical CentOS or RedHat system in a while, so I am not sure of the specifics needed to
just stop the usbhid-ups driver, but then you can restart it with a few "-D" flags (3 should be sufficient for this kind of problem) and "-a TrippLiteUPS" to match this configuration. Please compress any log files (gzip preferred; zip works).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> As a result, this impacted the user’s ability use NUT software on their Linux hosts. After some trial and error (and a lot of search engine use), I was able to find that the following configuration changes/settings stop the drops and
stabilize performance:<o:p></o:p></p>
<p class="MsoPlainText">> 1) This in the ups.conf file<o:p></o:p></p>
<p class="MsoPlainText">> pollinterval = 1<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">pollinterval defaults to 2, and to be honest, for most other UPSes, we suggest that people raise the value (since many UPSes do not update their filtered values more frequently than that anyway). Do you know how frequently the Windows
software polls the UPS? Should this be applied to other models as well, or just protocol 2012?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> [TrippLiteUPS]<o:p></o:p></p>
<p class="MsoPlainText">> driver = usbhid-ups<o:p></o:p></p>
<p class="MsoPlainText">> port = auto<o:p></o:p></p>
<p class="MsoPlainText">> desc = "SMART1500LCD"<o:p></o:p></p>
<p class="MsoPlainText">> 2) The attached 62-nut-usbups.rules file at /etc/udev/rules.d/<o:p></o:p></p>
<p class="MsoPlainText">> 3) The attached 42-usb-hid-pm.rules /usr/lib/udev/rules.d/<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The 62-nut-usbups.rules file looks pretty standard. Do you know if the changes to 42-usb-hd-pm.rules are needed? It seems like none of the USB devices would have the right permissions if 62-nut-usbups.rules isn't sufficient (though this
happened in Debian once).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Below is some other information that may be relevant regarding my testing.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> · I installed using the command “yum install nut.x86_64”<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> · Operating system version:<o:p></o:p></p>
<p class="MsoPlainText">> CentOS Linux release 7.6.1810 (Core)<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> · Network UPS Tools version<o:p></o:p></p>
<p class="MsoPlainText">> Network UPS Tools upsd 2.7.2<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Note that NUT 2.7.4 has been out for some time now.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> I’m not the most well-versed in Network UPS Tools, so I am not sure how “good” of a solution this is. I can however, get you more information on our product and testing if that helps.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> The questions I have are:<o:p></o:p></p>
<p class="MsoPlainText">> 1) Does the above seem like a “good” way to address this problem? (given that the drops are something we need to look into on our end)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I can't argue with the results, though I would like to narrow it down a little (there may be other issues at play with the permissions in the udev files) and make sure that it is not coincidence.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> 2) Is there a good way to get this fix implemented in the driver?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Each USB vendor ID generally gets their own source file, so we could add a special case to drivers/tripplite-hid.c. As mentioned earlier, if you know that this will be a problem across all protocol 2012 UPSes, we can check for that ID.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I will say that there is a bit of a logjam in the release pipeline, due to some (unnecessary, IMHO) deprecation of libusb-0.1:
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_networkupstools_nut_issues_300&d=DwIFaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=TPFi7L4qzFl2kKkxVqafWA8kCGJbKJ25kIE31_dlUCA&s=FqKD29hKePQDc-0jwXa-ZvNuu0VdPPmBJ0lBzJIeTYo&e">
<span style="color:windowtext;text-decoration:none">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_networkupstools_nut_issues_300&d=DwIFaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=TPFi7L4qzFl2kKkxVqafWA8kCGJbKJ25kIE31_dlUCA&s=FqKD29hKePQDc-0jwXa-ZvNuu0VdPPmBJ0lBzJIeTYo&e</span></a>=
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">So it's unclear when a code change will get to users. The configuration file changes should work in the mean time.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> 3) Have you had any reports of similar issues?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I thought we did, but maybe I am confusing it with protocol 3016 devices. We actually added a lot of the protocol 2012 devices to the hardware compatibility list based on the test results that Eric provided, so I assume they worked then
(about six years ago).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The protocol 3016 devices (in particular, the SMART1500LCDT and OMNI1500LCDT) sometimes don't even stay on USB long enough to read a USB descriptor, and this does seem correlated with newer motherboards. Example:
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_networkupstools_nut_issues_577&d=DwIFaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=TPFi7L4qzFl2kKkxVqafWA8kCGJbKJ25kIE31_dlUCA&s=KPe1NUkiOITUahTmJHr-PyCQRiWn2JLcU74O_RqQ_WI&e">
<span style="color:windowtext;text-decoration:none">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_networkupstools_nut_issues_577&d=DwIFaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=TPFi7L4qzFl2kKkxVqafWA8kCGJbKJ25kIE31_dlUCA&s=KPe1NUkiOITUahTmJHr-PyCQRiWn2JLcU74O_RqQ_WI&e</span></a>=
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">From where I stand, there really shouldn't be anything that a user-space program (like a NUT driver) can do that should be able to cause a USB device to disconnect during normal polling. (Aside from firmware updates, which we don't attempt.)
That said, I recognize that USB Phy layer problems can be hard to diagnose, and power management can compound the issue.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> 4) While we are communicating, are there any other open Tripp Lite items I could help your team(s) with? No promises, but if I can help I’d like to.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Aside from those two USB issues, just a few other thoughts:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Some users prefer not to post the entire serial numbers from their UPS when reporting issues. Is there a convention for the serial number digits such that we can ask for just the first few digits, and get an idea as to whether the problem
is limited to a given hardware or firmware revision? There seems to be a firmware revision buried in the HID descriptor for some models, but I don't know how to interpret it, and some of these connection problems present themselves before the UPS can return
that HID report.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Although these models are not as common, we still hear from users with non-HID-PDC-based USB devices (and some serial UPSes as well). Publicly-available protocol documents would help us write better drivers for those devices. If not,
a better way to identify models with proprietary protocols would be useful.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Another thing is considering how users get started with NUT. Sometimes a user inherits an UPS on a given system, and they want to set up NUT to monitor it. Ideally, we'd like to have a way for them to quickly triage whether a particular
UPS model will work, and before they have NUT installed, they will likely have "lsusb" or similar tools to enumerate devices. Other times, a user is replacing another UPS, and they want to know which models are supported by NUT before purchasing one. In both
of those cases, more information about how USB IDs map to models can help smooth out those processes. At the moment, we manually add each protocol number to the usbhid-ups driver when a user tries an UPS that isn't listed already. If there were a convention
that all USB idDevice values in a certain range were going to be HID PDC compliant, we could change the default from opt-in to enabled-by-default (but we wouldn't want the UPS driver to try to control a USB hub).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> Thanks for your time. <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">No problem, thanks for reaching out!<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> _______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">> Nut-upsdev mailing list<o:p></o:p></p>
<p class="MsoPlainText">> <a href="mailto:Nut-upsdev@alioth-lists.debian.net"><span style="color:windowtext;text-decoration:none">Nut-upsdev@alioth-lists.debian.net</span></a><o:p></o:p></p>
<p class="MsoPlainText">> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.de">
<span style="color:windowtext;text-decoration:none">https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.de</span></a><o:p></o:p></p>
<p class="MsoPlainText">> bian.net_cgi-2Dbin_mailman_listinfo_nut-2Dupsdev&d=DwIFaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=TPFi7L4qzFl2kKkxVqafWA8kCGJbKJ25kIE31_dlUCA&s=O5M-Y8sKtux0JI-KsFfjhFPlq3nUqeMZ43wyk5yQMe8&e=<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
</div>
<hr>
<font color="grey" face="calibri">This message is for the addressee's use only. It may contain confidential information. If you receive this message in error, please delete it and notify the sender. Tripp Lite disclaims all warranties and liabilities, and assumes
no responsibility for viruses which may infect an email sent to you from Tripp Lite and which damage your electronic systems or information. It is your responsibility to maintain virus detection systems to prevent damage to your electronic systems and information.
</font>
</body>
</html>