<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On May 8, 2021, at 11:46 PM, Paul Nickerson via Nut-upsuser wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I'm running Raspbian GNU/Linux 10 (buster) on a Raspberry Pi 4.<br class="">I have nut-client and nut-server version 2.7.4-8 armhf installed from the Raspbian Buster main apt repository.<br class="">I have a Tripp Lite AVR900U series AG-0309 connected via USB to the Pi. The USB vendor ID is 09ae as expected, but the product ID is 3024. The compatibility page at <a href="https://networkupstools.org/ddl/Tripp_Lite/AVR900U.html" class="">https://networkupstools.org/ddl/Tripp_Lite/AVR900U.html</a> says the product ID is expected to be 2010.</div></div></blockquote><div><br class=""></div><div>I think we need some better background text on the DDL pages to explain this, but the way to look at it is that the 2010 product ID is the last "known good" version of the AVR900U model. I don't remember offhand when we started to see the under-the-hood change to 30xx product IDs, but this was discussed about a year ago:</div><div><br class=""></div><div><a href="https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-May/thread.html#11840" class="">https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-May/thread.html#11840</a></div><div><br class=""></div><div>Towards the end was discussion of the "data stale" error, which is a higher-level symptom of the driver (usbhid-ups, in your case) not being able to stay connected to the UPS. (I have an UPS with product ID 3016 which does the same thing on Linux with newer motherboards. It seems to be a combination of hardware issues with a lack of error handling for this particular fault in the Linux USB driver.)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">There's no manufacturing date printed on the UPS or box, but I bought it from <a href="http://Amazon.com" class="">Amazon.com</a> this week.<br class=""></div></div></div></blockquote><div><br class=""></div>I thought we had more info on how to interpret serial numbers, but all I can find is this:</div><div><br class=""></div><div><a href="https://www.tripplite.com/support/identify-products" class="">https://www.tripplite.com/support/identify-products</a></div><div><br class=""></div><div>so the first four digits are the "date code", which do seem to be pretty close to the one mentioned in the May 2020 thread.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I have these settings:<br class=""><br class="">/etc/nut/ups.conf<br class="">[tripplite]<br class=""> driver = usbhid-ups<br class=""> port = auto<br class=""> desc = "Tripp Lite AVR900U"<br class=""> vendorid = 09ae<br class=""> productid = 3024<br class=""></div></div></div></blockquote><div><br class=""></div><div>^ The last line tells upsdrvctl to add "-x productid = 3024" to the command line, so you should be set with this config.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">To get usbhid-ups to try communicating with the UPS anyways, I added this udev rule and then unplugged and plugged back in the USB cord:<br class=""><br class="">/lib/udev/rules.d/62-nut-usbups.rules<br class="">ATTR{idVendor}=="09ae", ATTR{idProduct}=="3024", MODE="664", GROUP="nut"<br class=""></div></div></div></blockquote><div><br class=""></div>This udev rule is necessary until 3024 is added to NUT, yes.<br class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">It looks like forcing usbhid-ups to communicate works, maybe? I'm not sure what's expected here:<br class=""></div></div></div></blockquote><div><br class=""></div><div>At this point, if you restart with "productid = 3024" in ups.conf, things should work.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> 0.023703 Path: UPS.PowerSummary.Input.Voltage, Type: Feature, ReportID: 0x31, Offset: 0, Size: 16, Value: 0.001254<br class=""></div></div></div></blockquote><div><br class=""></div><div>We have a couple of hacks in the driver to handle cases like this (Input.Voltage is being reported with 100,000x too low):</div><div><br class=""></div><div><a href="https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite-hid.c#L59" class="">https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite-hid.c#L59</a></div><div><br class=""></div><div>It looks like one of these was merged for 3024 recently:</div><div><br class=""></div><div><a href="https://github.com/networkupstools/nut/issues/962" class="">https://github.com/networkupstools/nut/issues/962</a></div><div><br class=""></div><div>You might also want to check other issues labeled Tripp Lite in GitHub: <a href="https://github.com/networkupstools/nut/labels/Tripp Lite" class="">https://github.com/networkupstools/nut/labels/Tripp%20Lite</a></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> 0.043213 Path: UPS.PowerConverter.Input.Frequency, Type: Feature, ReportID: 0x19, Offset: 0, Size: 16, Value: 6020<br class=""></div></div></div></blockquote><div><br class=""></div>Similar issue with frequency (x100)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Should I run this without -x explore? Is there a way to get upsdrvctl to send the option -x productid=3024 to usbhid-ups? Would that be a good idea?<br clear="all" class=""></div></div></div></blockquote><div><br class=""></div><div>Correct, "-x explore" is only useful when adding support for a new UPS. It doesn't send anything to upsd.</div><div><br class=""></div><div>It sounds like you will need a newer build of NUT than 2.7.4 to get the fix for Issue 962 mentioned above (which still doesn't address the "data stale" issue). I don't have a lot of time to work on the NUT codebase these days, though. Hopefully some other folks on the list can help out. We also have some tips on rebuilding NUT on the GitHub wiki: <a href="https://github.com/networkupstools/nut/wiki" class="">https://github.com/networkupstools/nut/wiki</a></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div class=""><br class=""></div> ~ Paul Nickerson</div></div></div></div>
_______________________________________________<br class="">Nut-upsuser mailing list<br class=""><a href="mailto:Nut-upsuser@alioth-lists.debian.net" class="">Nut-upsuser@alioth-lists.debian.net</a><br class="">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser<br class=""></div></blockquote></div><br class=""></body></html>