similar to: PowerWare USB debug messages

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

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

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

Hi, I'm having a hard time configuring a Mustek Powermust 600VA ups to work via USB with nut. I read somewhere that nut works OK via the rs232 cable, but unfortunately I don't have a COM port in my computer. The kernel detects the ups as an Xbox pad :) and loads the xpad module. I tried running /lib/nut/megatec with different /dev/ttySx but it displays megatec protocol UPS was not

THE GOOD: NUT is able to communicate with my Powerware 5115A over USB using the bcmxcp_usb driver: ambient.temperature: 38 battery.charge: 99 battery.runtime: 9000 battery.voltage: 27.07 driver.name: bcmxcp_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.2.1 driver.version.internal: 0.13 input.frequency: 50.34 input.voltage: 235 output.current: 0.0

Oi, quando abri a minha caixa adsl e vi o famoso Octal, assustei-me logo, no entanto, depois de ler o teu artigo, fiquei descansado, mas os problemas vieram a seguir... segui o howto por completo, instalei tudo, mas quando vou compilar o amedyn é reportado o seguinte erro : [root@portatil paulo]# cd amedyn [root@portatil amedyn]# make cd init && make clean make[1]: Entering directory

I doesn't fix any problems but I think it is nicer code. :-) I don't think we want to call usb_detach_kernel_driver_np unless we claimed the device. $ diff -uw libusb.c.bak libusb.c.new --- libusb.c.bak 2010-05-11 09:35:39.000000000 -0400 +++ libusb.c.new 2010-05-11 09:32:44.000000000 -0400 @@ -206,18 +206,21 @@ upsdebugx(2, "failed to

I'm attempting to get a HP R1500 G2 UPS working with Solaris 10 connected via USB. Thanks to Arnaud's patch to drivers/tripplite-hid.c found at http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-February/005887.html things mostly work. upsc ups01 shows a couple of things that don't look quite right. [....] battery.temperature: -234.1 [....] ups.alarm: No battery installed!

Hello, I 'm trying to set up an Eaton PW5110 using nut-2.4.1 in OpenBSD, my ups.conf follows : [myups] driver = bcmxcp_usb port = auto desc = "Eaton PW 5110 (1500VA)" My first attempt to run upsdrvctl ended up complaining about unimplemented usb_clear_halt() in libusb. I patched libusb-0.1.12 with the following patch :

Joel Peshkin wrote: > > I hacked in the following additonal changes... > > Index: newhidups.c > =================================================================== > RCS file: /cvsroot/nut/nut/drivers/newhidups.c,v > retrieving revision 1.1.1.1.8.6.2.21 > diff -u -r1.1.1.1.8.6.2.21 newhidups.c > --- newhidups.c 7 Nov 2005 22:14:20 -0000 1.1.1.1.8.6.2.21 > +++

This looks like the commit that triggered the following FreeBSD build failure: http://buildbot.ghz.cc/public/nut/FreeBSD-i686/builds/53 One thing that stands out is that ETIME is not negated like the other error codes. What returns it? - Charles On Jan 13, 2010, at 8:04 AM, Arjen de Korte wrote: > Author: adkorte-guest > Date: Wed Jan 13 13:04:42 2010 > New Revision: 2243 >

Good evening, I tried getting this to work a couple years back but didn't have enough time to do all the debugging that was needed (apologies to the devs who tried to help at that time). It's working much better now, but I'm still not able to get an answer from upsc. Can anyone help me work out why I'm getting the error when querying with upsc: Error: Data stale My

Good evening, I tried getting this to work a couple years back but didn't have enough time to do all the debugging that was needed (apologies to the devs who tried to help at that time). It's working much better now, but I'm still not able to get an answer from upsc. Can anyone help me work out why I'm getting the error when querying with upsc: Error: Data stale My

I just upgraded the FreeBSD buildbot machine from 6.4 to 8.0, and I ran across some interesting differences. The libusb API that we use (0.1) is available in /usr/include/usb.h and /usr/lib/libusb.* as before, but it seems to be the compatibility layer from libusb 1.0. However, it doesn't include the libusb-config binary. This is from the 'ports' Makefile for NUT: ########## - -

Hi, I've been checking out NUT with an OpenUPS board over the last couple of weekends, and have noticed that it doesn't seem to report sensible values. This lead me to investigate usbhid-ups and delve into various issues. As mentioned in a github issue, one of the problems is with the report descriptor - dumping this from the usbhid-ups debug output and picking through it reveals that

Hi Peter, I've forwarded your mail to upsdev as it will be of interest for several people that are working on it. As I'm also on vacation (again) for a week and 1/2 as of this evening, I don't think I'll have the time for it before I get back.... I've not yet audited the patches, but these are queued on the Alioth tracker:

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

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: