similar to: Tripp Lite AVR900U

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

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

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",

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:

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

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

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

"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:

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. >

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)

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

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

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

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. According to the supported list, I thought this UPS was supposed to use the USB 2010 protocol, but I guess that was an old version because now uses the 3024 protocol (perhaps it would be good to

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

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

Hi Patrick, in February, you tried to post the below message to the nut-upsuser list, but the post was rejected because you were not subscribed to the list. Unfortunately, you did not subscribe and re-post it. Anyway, I have been working on Tripp-Lite support for newhidups recently, and I wonder if you have any feedback. Did you ever get this device to work? >From the information you sent,

Hello, I am trying to get a SMART500RT1U working on CentOS and just receiving the following message when attempting to start the driver: Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.6.5) Warning: This is an experimental driver. Some features may not function correctly. Detected a UPS: Tripp Lite /TRIPP LITE SMART500RT1U Unknown input voltage range: 0x02 Unknown number of