similar to: USB comms dropout not detected

[was: Re: [Nut-upsuser] FreeBSD rc.d scripts or shutdown howto?] On 8/22/07, Daniel O'Connor <doconnor at gsoft.com.au> wrote: > On Wed, 22 Aug 2007, Bryan wrote: > > The trouble I'm now having is that UPS communication just stops for > > no apparent reason. Data goes stale and I get the broadcasts about > > the UPS being unavailable. upsc tells of a similar

Hi all, I’m new to NUT and have some trouble getting my new UPS to work. Since the HCL listed Powercom UHID models as „green“ I thought buying a Roline (German rebranded Powercom) model would be a good idea. The OS is FreeBSD: FreeBSD freenas-pmh.local 11.2-STABLE FreeBSD 11.2-STABLE #0 r325575+6aad246318c(HEAD): Mon Jun 24 17:25:47 UTC 2019 root at

Hi, I have a customer who just bought an APC Back-UPS XS 1300 LCD and I thought I'd try the latest NUT with it (on an old-ish FreeBSD 6.x system). It sees the UPS but I can't actually query it for data, in the usbhid-ups debug output I see.. 30.840512 HIDGetEvents: failed to buffer report: Result too large 30.840600 Got -34 HID objects... 30.840681 Quick update...

Hallo, Following the tips found at https://calomel.org/nut_ups.html I was trying to make NUT operate "APC Back UPS CS-350". The device introduces itself as: #v+ ugen0 at uhub0 port 1 "American Power Conversion Back-UPS CS 350 FW:807.q7.I USB FW:q7" rev 1.10/0.06 addr 2 #v- My config: #v+ [apc] driver = usbhid-ups port = /dev/ugen0.00 pollfreq =

Hallo, Following the tips found at https://calomel.org/nut_ups.html I was trying to make NUT operate "APC Back UPS CS-350". The device introduces itself as: #v+ ugen0 at uhub0 port 1 "American Power Conversion Back-UPS CS 350 FW:807.q7.I USB FW:q7" rev 1.10/0.06 addr 2 #v- My config: #v+ [apc] driver = usbhid-ups port = /dev/ugen0.00 pollfreq =

OK, from this build I get the following: # /usr/local/ups/bin/usbhid-ups -a ups -DDDD Network UPS Tools - Generic HID driver 0.53 (v2.7.4-603-gb14c3b42.7.4.1) USB communication driver 0.37 0.000000 [D1] debug level is '4' 0.001299 [D1] upsdrv_initups... 0.001450 [D2] nut_libusb_open: checking device 1 of 1. 0.033333 [D2] nut_libusb_open: - VendorID: 09ae.

Attached are config.log and usbhid-ups output with -u root (gzipped). Now driver output looks a lot like the one from port build. On Mon, Aug 20, 2018 at 1:42 PM, Charles Lepple <clepple at gmail.com> wrote: > On Aug 20, 2018, at 1:03 AM, Valentin Merkulov <schnobel at ickis.net> wrote: >> >> 0.033412 [D3] nut_usb_claim_interface: failed to claim USB >>

Hi all, I'm currently trying to install a APC Back-UPS ES 700 on FreeBSD. This UPS has a usb connection to the PC and is recognized as: ugen0: APC Back-UPS ES 700 FW:829.D2 .I USB FWD2 rev 1.10/1.06, addr 2 my ups.conf looks like: [back-ups] driver = usbhid-ups port = auto desc = "server" When I now run /usr/local/libexec/nut/upsdrvctl start the output is: Network UPS Tools

Hi all, After some research I've found that this device should run with the blazer_usb driver. Jun 3 16:15:38 pegasus kernel: ugen0.4: <vendor 0x0001> at usbus0 Jun 3 16:15:38 pegasus kernel: uhid0: <vendor 0x0001 product 0x0000, class 0/0, rev 1.00/1.00, addr 4> on usbus0 However, even after shoehorning it; [crees at pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor

Hi, Have anybody tried Cyberpower Value 600E (USB) under FreeBSD? usbhid-ups from nut 2.4.1 does not recognize (find) the device on my machine. [root at substance /usr/local/libexec/nut]# uname -a FreeBSD substance.dyndns.org 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 root at walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [root at substance

I was doing some testing with the 2.6.0-1 beta Windows installer and a Cyber Power CP1350PFCLCD UPS, and ran into an infinite loop in the usbhid-ups driver if the UPS is lost on the UPS bus. This is on a Windows XP SP3 system. USB device access is via libusb 1.2.4.0 (driver mode, not filter) in case that matters. Everything seems to work just fine so far while the UPS is connected (so kudos,

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

On Sep 15, 2015, at 9:31 PM, Charles Lepple <clepple at gmail.com> wrote: > >> Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem? > > You're right, both the -compat and real libusb

I've added a pull request with changes to drivers/libusb and drivers/usbhid-ups mainly. They are to resolve issues I encountered when setting up a Tripp Lite SMART1500LCDT, but I think they're generally useful to the community. Here is the pull request comment I sent: https://github.com/networkupstools/nut/pull/122 Had trouble getting nut to work for my new Tripp Lite SMART1500LCDT. So

Ladies and Gentlemen, I have been trying to sort out a nasty kernel oops for which I would like to ask for some advice. I don't actually think that this is a nut problem, although it is triggered by upsdrvctl or usbhid-ups. I rather suspect the USB library or the associated kernel code. Here is the configuration information: * system: Centos-5.5 * kernel: 2.6.18-194.32.1.el5, latest vanilla

I recently installed NUT 2.4.3 and found that the USB drivers were logging an insane amount of data to syslog: usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 |

Hi Stephen, It's been a little busy at home, so I haven't had a chance to go over the pull request in depth, but I didn't want you to think it hadn't been considered. On Apr 19, 2014, at 1:23 AM, Stephen J. Butler wrote: > I've added a pull request with changes to drivers/libusb and drivers/usbhid-ups mainly. They are to resolve issues I encountered when setting up a

# ldd /lib64/nut/usbhid-ups linux-vdso.so.1 (0x00007ffdfe3e3000) libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f98526e6000) <-- from libusbp-compat-0.1.5-r2 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f98524ca000) libc.so.6 => /lib64/libc.so.6 (0x00007f985212f000) libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f9851f17000) <--

Thank you for responding to my problem I have no problem building in Debian 8 , the problem is with Cygwin64 I see that the two lines from Cygwin64 >> gcc -g -O2 -Wall -Wsign-compare usbhid-ups.c -o usbhid-ups In file included from usbhid-ups.c:32:0: And Debian>>> make[1]: Entering directory '/home/walter/nut/drivers' depbase=`echo usbhid-ups.o | sed

On Sep 8, 2015, at 4:48 PM, Rob Groner <rgroner at RTD.com> wrote: > > 0.005927 Device matches > 0.005940 failed to claim USB device: Device or resource busy > 0.005954 failed to detach kernel driver from USB device: No such file or directory Rob, this is a bit of a tough one to track down. The "Device or resource busy" message can either come from a kernel