similar to: No subject

Peter, Looking through the usbhid-ups subdrivers, I came across the following function in apc-hid.c, presumably added by you about two years ago (if not, my apologies): 41 /* returns statically allocated string - must not use it again before 42 done with result! */ 43 static char *watts_to_av_conversion_fun(long value) { 44 static char buf[20]; 45 46 snprintf(buf,

Hi all, greetings and a happy new year! I am writing as a user, rather than as an ex-developer. Usbhid-ups contains a fatal bug that was apparently introduced in r1210 (I did a binary search to find the exact revision). Arjen, you wrote "correct me if I'm wrong", so it seems that's what I am doing. ------------------------------------------------------------------------ r1210

Dear Sirs, We appreciate your support and cooperation. Can you please kindly add our new USB-controller with productID 0X04 to NUT compatible list. Updated USB-controller compatible with previous version which is supported by your usbhid-ups driver. Detailed information regarding new POWERCOM communication protocol you could download via link

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 >

> ---------- 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

Dear Artem and Alexey, 2014-09-16 13:20 GMT+02:00 Khokhlov Artem <khokhlov.a at pcm.ru>: > Dear Sirs, > > > > We appreciate your support and cooperation. > > Unfortunately we lost contacts with NUT team, because of retirement of Mr. > Arjen de Korte. > NOTE: Arjen de Korte is retired from the project for some years now. Please do not contact him anymore about

(Arjen - I apologize if you get two copies, I sent the first one to the old de-korte.org address) Arjen, all, I've run into a usbhid-ups problem with nut on Arch Linux with the new 2.6.35 kernels. (latest is 2.6.35.4-1) For some reason when you get to the udev events on boot and it tries to load the usbhid-ups driver, it hangs until the 120 sec timeout occurs and then boot continues but

Arjen, All, I need help unwrapping my head from around the problem of getting nut running on the same machine it runs fine with on another drive!! Sound easy -- not here :) I have network-ups-tools 2.4.1-2 on two servers. On one server I had a raid drive fail (which I'm still booting from and running nut on just fine). I bought a second pair of drives to establish a new array in the

---> 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>

'belkin-hid.c' and 'tripplite-hid.c' subdrivers, the only thing that happens when the shutdown functions are run is sending DelayBeforeShutdow= n (if that's available, which it probably always is). According to the HID Power Devices specification, it will do just that and is effectively the same as 'shutdown.stayoff'. If there is mains power at that time, the output

Looking at the above sources, it looks like the device_path is configured twice: 509 device_path = xstrdup("auto"); /*getenv ("HAL_PROP_HIDDEV_DEVICE"); */ 626 device_path = xstrdup(argv[0]); Other than the fact that we leak a few bytes of memory here by using xstrdup() twice without free'ing in between, I don't think this is what we intended to do. It looks to me

Just installed version 2.2.1 and have the same problem reported in this chain. I have Mandriva Linux 2008.1 with a Tripplite USB 500 no break. When I start the upsdrvctl I get the "Startup timer elapsed, continuing..." message and then a upsd can't connect error. I copied the file usbhid-ups from version 2.2.0 from another Mandriva system and everything works fine now. Its not

Hi! After some problems doing the automatic shutdown of the UPS on Debian, I have found this Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293401 Now I fixed it calling always ups-monitor from the halt script despite being halt'ed' or powered off (and relying on the POWERDOWNFLAG be set). Which is the correct aproach or best solution to workarround this bug? And now my

please tell me how i can use the hyperterminal to calibiration of my ups sua 1000VA. nut-upsdev-request@lists.alioth.debian.org wrote: Send Nut-upsdev mailing list submissions to nut-upsdev@lists.alioth.debian.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev or, via email, send a message with subject or body

> Author: aquette > Date: Thu Jun 21 07:43:46 2007 > New Revision: 971 > > Log: > fix communication lost status handling > > Modified: > trunk/ChangeLog > trunk/drivers/usbhid-ups.c > > Modified: trunk/ChangeLog > ============================================================================== > --- trunk/ChangeLog (original) > +++ trunk/ChangeLog

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()

Folks, I have been working on a problem with the usbhid-ups driver and the MGE / Eaton Ellipse series UPS. There seems to be light at the end of the tunnel. For whatever reason, these devices seem to trigger error 'EPIPE' randomly. So far, the response to this of the usbhid-ups (and previously, newhidups) driver is to reconnect. Most of the time this will succeed on the first

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

Dear Sirs, First of all I would like to thank you for support PCM product in your project. Kindly please be informed that POWERCOM launch new USB-controller with productID 0X04. Updated USB-controller compatible with previous version which supported by your usbhid-ups driver. There is added some command and changed idProduct. Vendor ID stay the same 0X0d9f without changes. Detailed information

To people with APC, CyberPower, Belkin and TrippLite UPS'es and using the 'usbhid-ups' driver. There are some concerns that the usbhid-ups driver is not acting as it is supposed to do. Could you run the following command (as root and with the mains plugged) and check if the UPS powers back on automatically? upsmon -c fsd I think we should *not* release nut-2.2.1 if we're not