similar to: Sucess with Powerware 5115A over USB!

I have an FC5 system with a powerware 5110 usb ups. The system seems to find the UPS ------------------------------ [root@b1 src]# lsusb Bus 004 Device 001: ID 0000:0000 Bus 003 Device 002: ID 0592:0002 Powerware Corp. Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 005 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 ------------------------------- [root@b1

Ok, I installed the ups, and installed nut, and /proc/bus/usb/devices says this T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=06da ProdID=0002 Rev= 0.01 S: Manufacturer=POWERWARE S: Product=Powerware UPS C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 20mA I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00

Earlier this year, I added a patch to my local NUT tree to additionally print the value of usb_strerror() if usb_clear_halt() failed. (Ignore the commented-out goto.) Since these messages are at the LOG_ERR level, should we add usb_strerror() to all of the calls in nut_usb.c? diff --git a/drivers/nut_usb.c b/drivers/nut_usb.c index 494a1fa..4ca2691 100644 --- a/drivers/nut_usb.c +++

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

Hi, I recently downgraded my kernel to 2.4 series (2.4.32-rc2). Now I can't get nut running. It was fine with 2.6.14. It say's: --------------------- # ./bcmxcp_usb -uroot AUTO Network UPS Tools - BCMXCP UPS driver 0.10 (2.1.0) Can't reset POWERWARE USB endpoint Unable to find POWERWARE UPS device on USB bus ... --------------------- I've straced it in nut_usb.c

Author: ultrotter Date: 2006-02-19 18:38:10 +0000 (Sun, 19 Feb 2006) New Revision: 26 Added: trunk/debian/patches/30xenchangeset.dpatch Modified: trunk/debian/patches/00list trunk/debian/patches/10sysconfig.dpatch trunk/debian/rules Log: Add 10sysconfig.dpatch description Add 30xenchangeset.dpatch to make the xen changeset configurable Force the xen changeset to be the correct one

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a little patch for the drivers.list The "Cyber Power Systems Intelligent Series CP1500EAVRLCD" ups http://eu.cyberpowersystems.com/products/ups_systems/intelligent/cp1500eavrlcd.htm Got one here running (see: https://nut.stillbilde.net/cgi-bin/nut/upsstats.cgi?host=CyberPower at upsmonitor) Works flawlessly. Patch as follows:

These patches allow this device to function in nut.. diff --git a/trunk/drivers/tripplite-hid.c b/new/drivers/tripplite-hid.c index c36da98..dddd13c 100644 --- a/trunk/drivers/tripplite-hid.c +++ b/new/drivers/tripplite-hid.c @@ -71,6 +71,8 @@ static usb_device_id_t tripplite_usb_device_table[] = { { USB_DEVICE(TRIPPLITE_VENDORID, 0x2005), battery_scale_0dot1 }, /* e.g. TrippLite

Hi, seems there is one missing change in /trunk/scripts/udev/nut-usbups.rules.in BUS -> SUBSYSTEMS previous change [1] missed this. Now, the latest udev started to complain: > ... udevd[31526]: BUS= will be removed in a future udev version ... 098 udev version (from 2006) is required for this [2], but this is the same version as required for previous SYSFS -> ATTR change. I've

Hello, Control HP R1500 G2 with nut via USB. Ubuntu 14.04.5 LTS (GNU/Linux 4.4.0-72-generic x86_64) nut V2.7.1 installed from repository /etc/nut/ups.conf [HPR1500] driver=usbhid-ups port=auto After dealing hours with this, hope this will help some : rename udev rule to higher priority and move it to its right location, reload udev rules mv /lib/udev/rules.d/52-nut-usbups.rules

On Jan 30, 2015, at 4:22 PM, Melvin Call <melvincall979 at gmail.com> wrote: > At this point I unplugged the UPS and plugged it into a different USP port, but > that did not change the above. Figuring this was likely a udev problem, I > created the following /etc/udev/rules.d/52-nut-usbups.rules (based on an example > on our database server, and changing the vendor and product

Hi all, Here's a brief history of my adventure: I purchased a CyberPower 685 AVR and decided to connect it through USB to my Gentoo linux machine running kernel 2.6.22. While the device was detected properly and added to /dev, it was added with the wrong permissions (gid was set to 'usb' instead of 'nut', as it was expected to be according to the rules under

On 5/23/07, Kjell Claesson <keyson-guest at alioth.debian.org> wrote: > Author: keyson-guest > Date: Wed May 23 21:12:51 2007 > New Revision: 915 > > Log: > - Enabled requested Alarm function in bcmxcp.c > > Modified: > trunk/ChangeLog > trunk/drivers/bcmxcp.c Looks like this breaks when HAL is enabled. At the end of:

G'day, all! It's my second trouble with NUT. Latest nut-2.6.1.tar.gz installed from source on Xenserver 5.6 SP2, UPS is Powercom WOW--500U FW3.A4 (USB). Problem with setting permissions for udev (described in /etc/udev/rules.d/52-nut-usbups.rules file): ACTION!="add|change", GOTO="nut-usbups_rules_end" don't work for me. Only when I changed ACTION to:

Hello All, Sorry for the long post, I'm just trying to give as much info as I have about the problem(s) ... Recently I've tried to port NUT to the hardware router Asus WL-500g Deluxe (http://wiki.openwrt.org/OpenWrtDocs/Hardware/Asus/WL500GD), that runs OpenWRT Linux distribution (http://www.openwrt.org) based on Linux 2.4.30 kernel, in order to support my Powerware 5110 UPS (through USB

Kjell Claesson wrote: > Then i have a problem. My computer is down due to a > faulty mainboard, Youch. I hate it when that heppens. Hope it wasn't because you got a power spike ;-) Let me or Georg know if you want us to run any debug code. Feels like a bcmxcp_usb driver bug to me since the bcmcxp serial driver works fine and all my other USB devices work fine (wifi adapter, memory

Hi list- I'm having problems with TrippLite SMX1500LCD not being detected by NUT under FreeBSD 6.3-RC2. NUT 2.2.1 was installed from ports with the following options: WITH_USB=true WITH_SNMP=true WITHOUT_IPV6=true WITH_LIBUPSCLIENT=true WITH_CGI=true I use USB cable shipped with TrippLite and 'usbdevs -v' shows the following: ... Controller /dev/usb2: addr 1: full speed, self

Hello list, I am configuring NUT on a Dell workstation that is connected to an APC Back UPS Pro 1300, and I am running into an issue where starting everything manually seems to be successful, but fails when using the init.d scripts. The short story is that I get the following error when trying to check the status of the UPS: [root at mypc:/etc/nut]# upsc apc_pro1300 at localhost Error: