similar to: nut-usb fink version

Hello. So as my english is not so good, i'll try to write my story in bash commands :o) miwa@zork3$ uname -mrs FreeBSD 5.5-STABLE i386 miwa@zork3$ su root@zork3# cd /usr/ports/sysutils/nat root@zork3# make && make install root@zork3# cd ../nut-usb root@zork3# make && make install root@zork3# cd /usr/local/etc/nut root@zork3# cat ups.conf user=root [MGE-Ellipse]

Gentlemen, Please note that what follows pre-dates the latest changes from Arnaud (just thought someone might want to look at these before I can test the latest!). When running newhidups with -D -D -D I saw messages that looked like errors, and it took me a while to understand that they were not really errors. I therefore added two new entries in apc-hid.h, and I modified a couple of diagnistic

Does the following error message have a specific meaning: usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 2 ret -75 I get two of these messages every time I run the following: /lib/nut/usbhid-ups -u root -DDD -a trippy The following is the output from the above command: debug level is '3' Checking device (0000/0000) (004/001) - VendorID: 0000 - ProductID:

I am having an issue running NUT and using an TrippLite OMNI900LCD. When I run ./upsdrvctl start I get : [player@V0002-S002 bin]$./upsdrvctl start Network UPS Tools - UPS driver controller 2.1.0 Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) Detected a UPS: Tripp Lite /TRIPP LITE UPS Using subdriver: TrippLite HID 0.1 (experimental) dstate_setflags: base variable

Hi everybody, If we let the feature running, it appears that the driver gets unbound after a while ( variable from quarter of hour to 6 hours ) and cannot reconnect. This behavior appear with both MGE Ellipse ASR and non-ASR models with connection to an UHCI and OHCI controllers. The USB core is from 2.4.28 kernel. We use nut-2.0.3. Start, powerfail and recovery detections, UPS shutdown work

Gentlemen, I have a new HID USB device, that seems to be quite similar to the currently supported APC HID UPS. I append the dump-tree output, and would much appreciate advice on how to proceed. Certain entries for the current device are not available, but maybe there are some replacements that could be used. This may of course require a new table in apc-hid.h, and I would prefer not to do this

On 10/01/2015 00:45, Charles Lepple wrote: > On Jan 8, 2015, at 11:43 PM, Graham Menhennitt > <graham at menhennitt.com.au <mailto:graham at menhennitt.com.au>> wrote: > >> Hello Nutters, >> >> I'm running nut 2.7.2 on FreeBSD 10-stable (via the FreeBSD port) >> with an APC Back-UPS CS 350 connected via USB. I get persistent >> (every few

Hello all, About a month ago Peter and Charles were kind enough to try to help me with getting a Tripp Lite USB UPS to work with NUT. I reported quite a bit of initial success, and then other things here fell apart. Between work, fence building and a week-long out of town business trip, I have had to drop this from my list of things to do lately. I am back at it, and I believe I will have

Hello, I've recently bought Ippon Smart Winner 3000 New (note the "New" in the model name) and I can't make NUT to work with it. Linux gateway 3.17.8-gentoo-r1 #1 SMP Mon Feb 16 13:46:11 MSK 2015 x86_64 Intel(R) Celeron(R) CPU 1037U @ 1.80GHz GenuineIntel GNU/Linux Network UPS Tools 2.7.2 1) USB connection partially works using usbhid-ups driver, the problem is that I

On May 28, 2014, at 8:59 PM, Daniel O'Connor wrote: > On 28 May 2014, at 21:59, Charles Lepple <clepple at gmail.com> wrote: >>> What would log it? >> >> The driver. > > OK. > >>> I could try running the driver with debugging and see if that shows anything of interest. >> >> That should help. Unfortunately for non-debug

Arnaud, > first, even if your battery is full, and your ups is online, there is a > small amount of power drawn. So having always is CHRG status is normal. > In fact, these complementary status are more interesting for higher end > UPSs. > > second, these status need not to be handled like LB, as each one clears the > other. While LB had no pending event (!LB) before... >

I tested your fix (newhidups -DDD /dev/null) using both and APC Back-UPS 350 an APC Smart-UPS RT 2000 XL. No more segmentation fault due to the fixed-size array. ~Jacob -----Original Message----- From: nut-upsdev-bounces@lists.alioth.debian.org [mailto:nut-upsdev-bounces@lists.alioth.debian.org] On Behalf Of Peter Selinger Sent: Monday, October 16, 2006 12:12 PM To: Schmier, Jacob Cc: NUT

Greetings everyone, Firstly, sorry for the huge length of this message. The support page said send debug traces, and so debug traces shall be sent. OS name and version - Arch Linux - updated today. exact NUT version - 2.7.4 (Network UPS Tools - Generic HID driver 0.41 (2.7.4) USB communication driver 0.33) NUT installation method - Arch User Repository build script updated to use latest NUT

Hello all, I think I've found the "regression" in Belkin/Liebert USB HID support which worked for NUT v2.7.4 and reports zero voltages in 2.8.0 -- it was actually caused by a bug fix: practically the only functional difference per `git diff v2.7.4..v2.8.0 drivers/belkin-hid.c` is a change from `abs()` to `fabs()` in order-of-magnitude comparisons like `if( abs(value - 1e-7) <

Hello all, I think I've found the "regression" in Belkin/Liebert USB HID support which worked for NUT v2.7.4 and reports zero voltages in 2.8.0 -- it was actually caused by a bug fix: practically the only functional difference per `git diff v2.7.4..v2.8.0 drivers/belkin-hid.c` is a change from `abs()` to `fabs()` in order-of-magnitude comparisons like `if( abs(value - 1e-7) <

Hello Nutters, I'm running nut 2.7.2 on FreeBSD 10-stable (via the FreeBSD port) with an APC Back-UPS CS 350 connected via USB. I get persistent (every few minutes) messages logged "battery is low" but I don't understand why. I don't think it's for the reason described in the FAQ (but I'm not 100% sure). In the trace output I can see that

Hi all, I attached a driver for MiniBox openUPS device ( http://www.mini-box.com/OpenUPS) and a dump of the hid usages. I had the possibility to make a few adjustments to the device firmware for HID usages, and although I haven't managed to produce a good structure many issues from previous firmware were at least fixed and new information added. ATM the driver only shows pertaining

I wrote a while back about the inability to kill the following command with anything but "kill -9" and the apparent high speed polling rate. # /lib/nut/usbhid-ups -u root -DDD -a trippy The setup I have worked on a previous version of nut, but I have forgotten at what point it stopped working. (I believe it was around Nov, 2007 that I noticed things were not working correctly.) I

Apologies for resurrecting an old thread and likely poor formatting - I wasn't subscribed to the list at the time and have copied it out of the archives (http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-July/006104.html). I've been unable to locate any further progress on this UPS (Liebert 10af:0001) - a thread from 2009

Charles Lepple wrote: > > would you mind forwarding (to either me, or the list) the .txt file > showing the hidparser bug? I am trying to revamp libhid's hidparser, > and it would be helpful to have the descriptor. The text file is contained in the tarball on the patch tracker, at