similar to: NUT support for the new Tripp Lite AVR700U (USB 3024) under OpenWrt?

I think 3024 was added after NUT 2.7.4 release. On Thu, May 4, 2023, 18:20 Feliciano Chavez via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> wrote: > Dears, > > I'm trying to connect this new version of the AVR700U to nut - 2.7.4-27 > running over OpenWrt 22.03.5, installed from the stable release > repositories, for an ath79 USB2.0 gigabit WiFi router. >

That It may be right (I don't know), however, where could we confirm whether 3024 is already supported for 2.8.0 or newer? And let's suppose it is. Because current OpenWrt releases are built arround 2.7.4-27, what could I try to backport that (driver mod) to 2.7.4-27? ________________________________ De: Jim Klimov <jimklimov+nut at gmail.com> Enviado: s?bado, 6 de mayo de 2023 4:21

I'm mostly not online for a few more days, so can't check directly. The general answers to the two questions would be: 1) checking if it is there: * revise if it is mentioned in the NEWS file (in sources - release tarball or on github); * check issues on github; * search/grep for 3024 in current/release-tagged codebase... 2) getting it to your system: versioning looks debianish, some

For clarity, `upsd` is the networked data server for local or remote clients like `upsmon` or `upsc`. It talks to locally running NUT driver(s) which talk to actual devices with their media and protocols. It is the driver (like `usbhid-ups`) that would be annoyed by hardware reconnections. That said, I think there were some fixes to reconnection behavior, which might have landed even after 2.8.0

Thanks for your support, Jim. I found a workaround: logread showed some access-denied errors, and because I don't know exactly what it may be (except the lack of udev rules perhaps), I ran upsd as root and it connected with the UPS. Therefore I wonder whether a more elegant solution could be used for this part? But there are several things about the readings with the 2.7.4 usbhid-ups driver

I have a Tripp-lite AVR700U the website says it's supported but I keep getting the following error message type '-x productid=3024' option .... I'm not sure where to type '-x productid=3024' option at. user1 at user1-laptop:~$ sudo upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Generic HID driver 0.41 (2.7.4) USB communication driver

Hello! I am currently having issues monitoring a Tripp-Lite AVR900U. First, here are a few system details: > Manjaro Linux - kernel 5.4.30-1 > network-ups-tools 2.7.4-5 (built from Arch User Repository) > (lsusb output) Bus 003 Device 003: ID 09ae:3024 Tripp Lite AVR900U Contents of /etc/ups/ups.conf: > [tripplite] > driver =  usbhid-ups > port = auto Contents of

I have a brand new Tripp Lite Internet 600U UPS connected to my Raspberry Pi 4 running the latest Raspbian. I installed nut and tried to configure based on your HCL (which I did not check before buying...) Doesn't "just work" - help? this page says that my model is NOT on the HCL, but the drop downs on the search seemed to say otherwise? (see attachment)

If I installed and tested against Ubuntu, how useful would that be in general and in this specific case? I think we've seen a few reports of issues with the newer 3024 protocols and I'd like to help get them sorted out. Thank you, David Zomaya Tripp Lite ________________________________ From: Nut-upsuser <nut-upsuser-bounces+david_zomaya=tripplite.com at

Tested a Ubuntu 18.04 LTS virtual machine with NUT 2.7.4 and a 3024 protocol Tripp Lite UPS (mine is a INTERNET550U, but same protocol) :/etc/nut$ lsusb | grep Tripp Bus 002 Device 004: ID 09ae:3024 Tripp Lite I it got generally working (outputting reasonable responses to upsc, although there are some issues with variables like frequency) by adding productid=3024 to my ups.conf. Like this:

My thoughts for a test: * Just have MODE=standalone in nut.conf * Put [tripplite] driver = usbhid-ups port = auto productid=3024 desc = "Tripp Lite Internet600U" In ups.conf * Put LISTEN 127.0.0.1 3493 LISTEN ::1 3493 [tripplite] driver = usbhid-ups port = auto in upsd.conf That may be suboptimal but will probably work for a test. Side

I'm running Raspbian Buster, but given that the error seems to be "higher order" than a hardware issue - one of parsing the protocol?  I suspect that Ubuntu would be a decent "lookalike" to model the issue.  ---- On Tue, 19 May 2020 22:31:56 -0400 David Zomaya <David_Zomaya at tripplite.com> wrote ---- If I installed and tested against Ubuntu, how useful would

No, it's not. I'd defer to the list for tips on that one. First thing I'd try if no one else has ideas is checking lsusb and restarting the service. Thank you, David Zomaya Tripp Lite<http://www.tripplite.com/> ________________________________ From: Tom Cooper <tom at cooperfamily.xyz> Sent: Wednesday, May 20, 2020 7:00 PM To: David Zomaya Cc: nut-upsuser

Borrowing from our friends at Ask Ubuntu ( https://askubuntu.com/a/276637 ) there is. I've modified it for use with a Tripp Lite UPS and 3024 protocol below. Try disconnect/reconnect after and see what happens. :/etc/nut$ cat /etc/udev/rules.d/90-nut-ups.rules # /etc/udev/rules.d/90-nut-ups.rules ACTION=="add", \ SUBSYSTEM=="usb", \ ATTR{idVendor}=="09ae",

That would be great.  If there is something I can do to collect data or troubleshoot, please let me know. ---- On Wed, 20 May 2020 08:51:14 -0400 David Zomaya <David_Zomaya at tripplite.com> wrote ---- I'm still working remotely, but I should be able to get something set up soon. I'll reply all here once I have something to report. Thank you, David Zomaya Tripp

Wow - you're doing all the work for me! Thanks for the rule set.  I can't easily reboot that box just now, so I'm working on reloading the rules. When I try  udevadm control --reload-rules && udevadm trigger May 20 15:19:01 elmer systemd-udevd[3413]: Process '/sbin/crda' failed with exit code 234. May 20 15:19:01 elmer systemd-udevd[3413]: Using default

Glad to hear it's working, thanks Tom. Network UPS Tools team: is fixing this as simple as me telling you what new UPS protocols are HID-PDC compliant? Thank you, David Zomaya Tripp Lite<http://www.tripplite.com/> ________________________________ From: Tom Cooper <tom at cooperfamily.xyz> Sent: Wednesday, May 20, 2020 2:42 PM To: David Zomaya Cc: nut-upsuser Subject: Re:

"Can't claim USB device [09ae:3024]: could not detach kernel driver from interface 0: Operation not permitted" Is probably an issue with NUT grabbing the UPS... can you disconnect and reconnect the USB cable and try again? If that fails, maybe a udev rule will help. Thank you, David Zomaya Tripp Lite <http://www.tripplite.com/> ________________________________ From:

Did it stay stable this time? It looks like the restart of the service restored communication. If it reoccurs: >>> Bus 001 Device 011: ID 09ae:3024 Tripp Lite I wonder if this is the same device number after? Something to keep an eye on Thank you, David Zomaya ________________________________ This message is for the addressee's use only. It may contain confidential information. If

David, That's exciting - but I am not seeing similar results.  I *must* be doing something dumb - but I can't see it. I've got nut-2.7.4-8 installed on my pi Hope you can help. Tom pi at elmer:/home/macbackup $ lsusb | grep ipp Bus 001 Device 004: ID 09ae:3024 Tripp Lite pi at elmer:/home/macbackup $ sudo cat /etc/nut/nut.conf # Network UPS Tools: example nut.conf #