similar to: TrippLite HID 0.82: libusb_get_interrupt: Function not implemented

On 5/13/2017 10:20 AM, Charles Lepple wrote: > On May 12, 2017, at 10:06 AM, Mike <the.lists at mgm51.com> wrote: >> >> >> OpenBSD 6.1/amd64 >> nut-2.7.4p0 (from OpenBSD package) >> UPS: Tripp-Lite OMNI1500LCDT >> >> I cannot get the driver for the UPS to load without error. >> >> Here are the commands, with the output, and the config

On May 12, 2017, at 10:06 AM, Mike <the.lists at mgm51.com> wrote: > > > OpenBSD 6.1/amd64 > nut-2.7.4p0 (from OpenBSD package) > UPS: Tripp-Lite OMNI1500LCDT > > I cannot get the driver for the UPS to load without error. > > Here are the commands, with the output, and the config files: > > ======================================================= > #

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

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:

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

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

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:

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

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

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've used NUT successfully for monitoring many different brands of UPS, but this one has me stumped. It has the same manufacturer ID and Product ID as older supported MGE-type Eaton UPS's, but has trouble talking. I tried Ubuntu's repo NUT, and it logs a Connecting to UPS message every few seconds forever, but never really succeeds (or says it fails). Different failure mode after

Hello, We have a Tripplite SMART1500RMXL2U and nut-2.2.0-6.el5 installed on Centos 5.3. I've been unsuccessful on getting upsmon to work. usdrvctl seems to start despite some warnings/errors: # upsdrvctl start smart1500 Network UPS Tools - UPS driver controller 2.2.0- Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.11.1 (2.2.0-) Warning: This is an experimental driver. Some

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

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

Hey 2015-04-09 1:46 GMT+02:00 Charles Lepple <clepple at gmail.com>: > On Apr 8, 2015, at 2:04 PM, Eric Cobb <Eric_Cobb at tripplite.com> wrote: > > Charles and list, > > If I leave the driver alone it does not eventually start. It continues to > report that it is unable to connect. I have to perform a upsdrvctl stop ; > upsdrvctl start (I actually just perform

Hello, I am try to get my "new" UPS running with NUT on my OpenMediaVault device but only receive error meassages on several configurations I try. Your support is really appreciated for getting it solved. Best Regards, Olaf *lsusb* Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID

I haven't tried it on RaspberryPi, but if there's some specific Tripp Lite information I can help with, let me know. David Zomaya Tripp Lite ________________________________ From: Nut-upsuser <nut-upsuser-bounces+david_zomaya=tripplite.com at alioth-lists.debian.net> on behalf of Charles Lepple <clepple at gmail.com> Sent: Sunday, December 8, 2019 8:36 PM To: Layne Fowler