<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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:463810132;
mso-list-type:hybrid;
mso-list-template-ids:-1028086776 446202942 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:%1-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:684357640;
mso-list-type:hybrid;
mso-list-template-ids:-399589962 -2087964966 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:%1-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:701830507;
mso-list-type:hybrid;
mso-list-template-ids:-747475742 1495012814 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-text:%1-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="MsoPlainText"><span style="color:#5B9BD5">Thanks for the inputs.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:#5B9BD5">I’ll get CentOS 7.6 installed on a physical machine this week and follow up.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:#5B9BD5"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="color:#5B9BD5">Few responses and notes below in the interim.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:#5B9BD5"><o:p> </o:p></span></p>
<pre>”The log format looks okay, but I may not have been clear that I was looking for the log at the same time as when the kernel errors occur. So without the udev rules would be good.”<o:p></o:p></pre>
<pre><span style="color:#5B9BD5">Ah, sorry. Attached are these two files:<o:p></o:p></span></pre>
<pre><span style="color:#5B9BD5"><o:p> </o:p></span></pre>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo3"><![if !supportLists]><span style="color:#5B9BD5"><span style="mso-list:Ignore">1-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><b><span style="color:#5B9BD5">norules.log.gz</span></b><span style="color:#5B9BD5"> -Neither 62-nut-usbups.rules or 42-usb-hid-pm.rules at /etc/udev/rules.d/ or /usr/lib/udev/rules.d/. This really just left me with “permission
denied”. I assume this is because 62-nut-usbups.rules is needed and #2 is the relevant file.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#5B9BD5"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#5B9BD5"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo3"><![if !supportLists]><span style="color:#5B9BD5"><span style="mso-list:Ignore">2-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><b><span style="color:#5B9BD5">norule42.log.gz</span></b><span style="color:#5B9BD5">- 62-nut-usbups.rules at /lib/udev/rules.d/ and no “pollinterval = 1” value set in ups.conf. This yielded better results. I also included the
output from /var/log/messages, lsusb –v, uname –r, and cat /etc/os-release. In the /var/log/messages output, you can see a few of the drops we are trying to prevent.
<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"">“I think you mentioned the CentOS version - which kernel version does that run? ("uname -r" is probably sufficient)”</span><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><span style="color:#5B9BD5">3.10.0-957.el7.x86_64<o:p></o:p></span></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<pre><o:p> </o:p></pre>
<pre>“I moved my SMART1500LCDT off of the always-on system, so I don't have continuous data for it. I don't think it worked on Raspbian stretch the last time I tried. Others have rigged up scripts to reset a USB hub to simulate re-plugging the UPS USB connection.”<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal"><span style="color:#5B9BD5">Ok, if issues come up going forward and I can help, feel free to reach out (same for any new Tripp Lite issues).</span><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<pre>“I think that a lot of the content of the protocol docs would end up in the logic of the source code. Trying to write open-source code based on a document that can't be shared seems risky to me.”<o:p></o:p></pre>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#5B9BD5">That’s fair. I’d like to see us do something to help though. Let me see where this goes internally and follow up.
<o:p></o:p></span></p>
<p class="MsoPlainText"><o:p> </o:p></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"">“I think a range of IDs (even with a few exceptions for the older units) would be sufficient. The ideal scenario is that the range is somewhat future-proof, so a version of NUT from
this year can properly identify next year's UPS. If not, we still have manual ways for users to add their idProduct to ups.conf and the udev files, but as you can imagine, that is frustrating for a new user.”<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="MsoPlainText"><span style="color:#5B9BD5">Almost everything we make now is PDC compliant, so we should at least be able to do this. We’re looking into something easy to identify in the output of lsusb –v though since that could help with legacy support.
<o:p></o:p></span></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><span style="color:#5B9BD5">Note:<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:#5B9BD5">Interestingly, I did some tinkering with openSUSE 15.1 Leap on a physical box and saw the same drops there, but was able to get them to stop after installing NUT and just doing the “standard” configuration.
However, I ran into some connection refused messages, e.g.:<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:.5in"><span style="color:#5B9BD5"><br>
user@linux-nxmm:/dev/bus> sudo upsc -l<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:.5in"><span style="color:#5B9BD5">Error: Connection failure: Connection refused<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:.5in"><span style="color:#5B9BD5"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="color:#5B9BD5">When trying to pull data from the UPS, so I was clearly doing something wrong. But, the UPS stopped dropping (i.e. retained Device # in lsusb and no messages in /var/log/messages) . I did NOT have to make
the changes to “42-hd-audio-pm.rules” to make the drops stop in this case. Given the different kernel (4.12.14-lp151.27-default) and newer version of (NUT 2.7.4) this may not be apples to apples though. I hope that I will be able to provide better data once
I get to test further later this week. Topically, this has me thinking at the least I need to confirm the reproducibility of the fix I mentioned on a physical box. I will follow up by close of business Friday.
<o:p></o:p></span></p>
<p class="MsoPlainText"><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">Tripp Lite<o:p></o:p></p>
<p class="MsoPlainText">1111 W. 35th Street | Chicago, IL 60609 USA<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: Tuesday, June 18, 2019 10:00 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: Re: [EXTERNAL] Re: [Nut-upsdev] Fixing Drops With SMART1500LCDXL & USB-HID Driver</p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On Jun 18, 2019, at 1:47 PM, David Zomaya wrote:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Charles and Wolfy,<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Thanks for the replies.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> I added some responses below.<o:p></o:p></p>
<p class="MsoPlainText">> I think I got the driver debugging right, but let me know if it is off.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> I should note:<o:p></o:p></p>
<p class="MsoPlainText">> 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></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">> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I think we saw a similar problem with APC UPSes not having string descriptors when attached to a VM, so that is worth checking on a physical box. If so, I apologize for jumping to the conclusion that the UPS was not providing the serial
number.<o:p></o:p></p>
<p class="MsoPlainText"><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">> Attached. This is with the settings and udev rules mentioned in the earlier. I can remove and redo if useful.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The log format looks okay, but I may not have been clear that I was looking for the log at the same time as when the kernel errors occur. So without the udev rules would be good.<o:p></o:p></p>
<p class="MsoPlainText"><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).”<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">We've reworked some of the documentation for the next release, but the short answer is that USB HID drivers poll the essential status bits every `pollinterval` seconds ("Quick update..." in the log), and then grab the rest every `pollfreq`
seconds ("Full update").<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> “Do you know how frequently the Windows software polls the UPS?”
<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 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></p>
<p class="MsoPlainText"><o:p></o:p></p>
<p class="MsoPlainText">Thanks, that is useful to know.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> “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">> 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></p>
<p class="MsoPlainText"><o:p></o:p></p>
<p class="MsoPlainText">(By "protocol" I am just referring to the idProduct field, rather than the protocol itself, since that is what the driver would eventually use to enable any special cases.)<o:p></o:p></p>
<p class="MsoPlainText"><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">> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">This is starting to make sense, though. The link would be helpful, but no worries if you can't find it.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I think you mentioned the CentOS version - which kernel version does that run? ("uname -r" is probably sufficient)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I will try to read up on the USB power management settings that the udev file is changing.<o:p></o:p></p>
<p class="MsoPlainText"><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">> Wolfy nailed this one, I just installed whatever the repository gave me. Should I test with 2.7.4?<o:p></o:p></p>
<p class="MsoPlainText"><o:p></o:p></p>
<p class="MsoPlainText">Might not be necessary.<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
<o:p></o:p></p>
<p class="MsoPlainText">>> OMNI1500LCDT) sometimes don't even stay on USB long enough to read a
<o:p></o:p></p>
<p class="MsoPlainText">>> USB descriptor, and this does seem correlated with newer
<o:p></o:p></p>
<p class="MsoPlainText">>> motherboards. Example: <o:p></o:p></p>
<p class="MsoPlainText">>> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netwo">
<span style="color:windowtext;text-decoration:none">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netwo</span></a><o:p></o:p></p>
<p class="MsoPlainText">>> rkupstools_nut_issues_577&d=DwIFaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4a<o:p></o:p></p>
<p class="MsoPlainText">>> u5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=6vPDH1sqJhcwwVRECtQO7H6Tzh-L4I<o:p></o:p></p>
<p class="MsoPlainText">>> Yo9Ryzpa4A9IE&s=oV3u25jYPtbrcgAWLEAQujFDFzyrf1zXc7KsMK_XDaQ&e=<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">> Interesting threads. Are you still seeing issues with LCDTs or have they subsided?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I moved my SMART1500LCDT off of the always-on system, so I don't have continuous data for it. I don't think it worked on Raspbian stretch the last time I tried. Others have rigged up scripts to reset a USB hub to simulate re-plugging
the UPS USB connection.<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">> Our serial numbers break down like this:<o:p></o:p></p>
<p class="MsoPlainText">> <a href="https://www.tripplite.com/support/identify-products">
<span style="color:windowtext;text-decoration:none">https://www.tripplite.com/support/identify-products</span></a><o:p></o:p></p>
<p class="MsoPlainText">> 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></p>
<p class="MsoPlainText">> Does this help at all?<o:p></o:p></p>
<p class="MsoPlainText"><o:p></o:p></p>
<p class="MsoPlainText">Very useful, thanks!<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">> Does publicly available protocol = needs to be accessible to anyone Or
<o:p></o:p></p>
<p class="MsoPlainText">> We provide you with protocol docs if you agree not to share?<o:p></o:p></p>
<p class="MsoPlainText">> I can look into the latter. I feel like we should be able to help here.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I think that a lot of the content of the protocol docs would end up in the logic of the source code. Trying to write open-source code based on a document that can't be shared seems risky to me.<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">> 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></p>
<p class="MsoPlainText">> Topically the problem I can think of is determining if this holds for older units (I’ll dig into this).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I think a range of IDs (even with a few exceptions for the older units) would be sufficient. The ideal scenario is that the range is somewhat future-proof, so a version of NUT from this year can properly identify next year's UPS. If
not, we still have manual ways for users to add their idProduct to ups.conf and the udev files, but as you can imagine, that is frustrating for a new user.<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>