similar to: Nut-upsuser Digest, Vol 36, Issue 5

On Tuesday 10 June 2008 08:00:39 am nut-upsuser-request at lists.alioth.debian.org wrote: > Message: 2 > Date: Tue, 10 Jun 2008 10:58:11 +0200 (CEST) > From: "Arjen de Korte" <nut+users at de-korte.org> > Subject: Re: [Nut-upsuser] Nut-upsuser Digest, Vol 36, Issue 5 > To: "Alex Peyser" <a.peyser at umiami.edu> > Cc: nut-upsuser at

I'm setting up a cluster with multiple ups's using nut 2.2. The ups's are Belkin 1500 (ID 050d:0751) which don't appear to report a serial number. Is there any other way I can setup ups.conf with multiple of these ups over usb on Linux? If I just setup the vendor and product id's, every definition in ups.conf appears to match the first one, and therefore all of them but

Thought I would write some notes about how I got an APC BackUPS XS 1500 working with newhidups under Gentoo 2006.0. The specific issue here is the permissions on the device files used that libusb uses to access the USB hardware. I followed Peter Selinger's instructions at http://www.mscs.dal.ca/~selinger/ups/backups.html on getting newhidups going with an APC device. The sticking point for

Sorry about the noise guys. Below a significantly improved patch. The main difference is that all calls to usb_get_string_.. have been wrapped in a new function nut_usb_get_string()  that is implemented in libusb.c This was necessary in order to make the bufflen_fix available in libusb.c where usb_get_string() is called in libusb_open() This wrapper function mops up and hides all the work

Citeren Arnaud Quette <aquette op alioth.debian.org>: > Modified: trunk/drivers/tripplite-hid.c > ============================================================================== > --- trunk/drivers/tripplite-hid.c (original) > +++ trunk/drivers/tripplite-hid.c Sun Mar 1 19:56:31 2009 > @@ -84,6 +84,8 @@ > > /* HP R/T 2200 INTL (like SMART2200RMXL2U) */ > {

> ---------- Forwarded message ---------- > From: Arjen de Korte > To: nut-commits at lists.alioth.debian.org > Date: Mon, 27 Aug 2007 18:33:00 +0000 > Subject: svn commit r1076 - in trunk: . drivers > Author: adkorte-guest > Date: Mon Aug 27 18:33:00 2007 > New Revision: 1076 > > Log: > * drivers/libhid.[ch],libshut.[ch],libusb.[ch]: > - Cut the libshut and

Le 23/06/2011 14:00, nut-upsuser-request at lists.alioth.debian.org a ?crit : > Send Nut-upsuser mailing list submissions to > nut-upsuser at lists.alioth.debian.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser > or, via email, send a message with subject or body 'help' to >

THANKS, but the 'megatec' driver only works whith windows OS via USB, and i need it for red hat OS with USB-serial connection... Please, anybody can help me.... nut-upsuser-request@lists.alioth.debian.org escribi?: Send Nut-upsuser mailing list submissions to nut-upsuser@lists.alioth.debian.org To subscribe or unsubscribe via the World Wide Web, visit

---> On 15/03/2009 8:00 AM, nut-upsuser-request at lists.alioth.debian.org wrote: > Message: 1 > Date: Sat, 14 Mar 2009 21:47:08 +0100 > From: Arjen de Korte <nut+users at de-korte.org> > Subject: Re: [Nut-upsuser] Weird Load and Battery Temp Readings > To: nut-upsuser at lists.alioth.debian.org > Message-ID: <20090314214708.37122w00w79l6u9s at mail.de-korte.org>

On Dec 31, 2009, at 8:45 AM, Arjen de Korte wrote: > Author: adkorte-guest > Date: Thu Dec 31 13:45:16 2009 > New Revision: 2218 > > Log: > Add pkg-config as method to retrieve CFLAGS and LDFLAGS (but fall > back to libusb-config) > > Modified: > trunk/m4/nut_check_libusb.m4 Arjen, I'm not sure you want parentheses in the shell script fragments. Search for

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()

> Today's Topics: > > 1. Re: Possible support for Trust 1300VA LCD Management UPS? > (Charles Lepple) > Hmm, you have both libusb-compat and libusb-legacy. Unfortunately, > that alone doesn't tell us what NUT is linked against. > > What does "otool -L <path-to-drivers>/blazer_usb" show? Not sure what > that path would be for MacPorts, but

Citeren Charles Lepple <clepple at gmail.com>: >> Another thing, loosely related to this, is how we are going to deal with the >> 'generic' VID:PID combinations in some of the USB drivers, for example the >> megatec_usb and (new) blazer_usb drivers. At present, in the megatec_usb >> driver we have several VID:PID combinations for USB-to-serial converters

the USB access. That file is actually specifically for bcmxcp_usb.c, and applies only to Powerware devices. You should use the interface in libusb.c / libhid.c instead. See megatec_usb.c or tripplite_usb.c for how it is done. Thanks, -- Peter Peter van Valderen wrote: > > Hello Arjen, > > On 5/23/07, Arjen de Korte <nut+devel at de-korte.org> wrote: > > Never mind the

When I plug in a device, the kernel will not only tell me to which USB bus it is connected, but also the socket it is plugged into: > Aug 31 22:06:07 miffy kernel: usb 1-1: new low speed USB device using uhci_hcd and address 31 > Aug 31 22:06:08 miffy kernel: usb 1-1: new device found, idVendor=0463, idProduct=ffff > Aug 31 22:06:08 miffy kernel: usb 1-1: new device strings: Mfr=1,

Hi Vladimir, I have got 2.0.3 working on netBSD 3.0. To get it operational I needed to do the following (most of this is from memory...). 1). Recompile kernel with uhid removed. If uhid ataches to the device then libusb is not able to. Have to allow generic usb driver ugen to claim port. >From dmesg usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA Technologies UHCI root hub, class

On 2/27/07, A.Lizard <alizard@ecis.com> wrote: > terrarium:/home/alizard# /usr/local/ups/bin/newhidups -DDD -a belkin-ups > Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.0.5-pre2) > > debug level is '3' > Checking device (050D/0551) (002/006) the '002/006' part is "bus->dirname, dev->filename" in libusb.c. Does

Hi, Arjen; I am new to linux and not sure how to create the PowerCom-usb driver. So could you please compile powercom-usb file for me. I am happy to test it out with the USB PowerCom Ups. Thanks, Paul MCSE/MCSA/MCP ------------------------------ Message: 2 Date: Mon, 03 Sep 2007 11:13:32 +0200 From: Arjen de Korte <nut+users at de-korte.org> Subject: Re: [Nut-upsuser] Powercom USB UPS is

On Thu, Dec 4, 2008 at 4:51 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Author: adkorte-guest > Date: Thu Dec 4 21:51:28 2008 > New Revision: 1596 > > Log: > Added new richcomm_usb driver based on the lakeview_usb driver (using libusb). Sorry if I wasn't clear - I was advocating *renaming* the lakeview_usb driver to richcomm_usb. Is there another

On Mar 19, 2017, at 10:56 AM, Drew from Zhrodague <drewzhrodague at zhrodague.net> wrote: > > [] I've spoken with one of the developers, and he's offered to share some technical documentation with me. I'll report here with whatever I can. He's on vacation in China. Hopefully this documentation will lead to fewer surprises down the road. > [] I found this