similar to: Belkin and newhidups

Peter, Apparently, some Belkin UPSes still have problems with this. When we receive this report through the interrupt pipeline it is ignored (the special case in usbhid-ups.c) and even after that it looks like there are still some problems with it: http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-July/003014.html Wouldn't it be an option to just to ignore this completely and

Arjen de Korte wrote: > > Author: adkorte-guest > Date: Fri Aug 10 20:23:27 2007 > New Revision: 1041 > > Log: > * drivers/usbhid.[ch]: > - Moved the struct & data for ups.status processing to usbhid.c, since this is only used in there. Subdrivers report the status through text messages, they don't set the status bits directly. > - Rewrote (flattened) the

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,

I recently upgraded from nut-2.4.1 to 2.4.3 and my UPS stopped working. usbhid-ups now fails two communicate with the UPS: With 2.4.1: # /sbin/usbhid-ups -D -a auto Network UPS Tools - Generic HID driver 0.34 (2.4.1) USB communication driver 0.31 debug level is '1' upsdrv_initups... Using subdriver: Belkin HID 0.12 Path: UPS.BELKINConfig.BELKINConfigVoltage, Type: Feature, ReportID: 0x01,

On Jan 2, 2008 3:34 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Author: adkorte-guest > Date: Wed Jan 2 20:34:26 2008 > New Revision: 1210 > > Log: > Parsing continues if the HID path for a report ends in 0x00000000 (these will not be made available). Commonly used as placeholders. > > It looks like (but correct me if I'm wrong) that reports

Hello, I'm using the stable amd64 port of Debian Linux. I installed (the latest) nut-2.0.1-4 and nut-usb packages for utilizing an APC Smart-UPS 1500 USB. I tried "apcupsd" first but "nut" makes an even more sophisticated impression on me and has more security options. I had problems with the newhidups driver. It didn't find a device with matching VendorID. And

On Jan 8, 2015, at 11:43 PM, Graham Menhennitt <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 minutes) messages logged "battery is low" but I don't understand why. I don't think it's for the reason

Oops... changing that to --with-user=nut solved one problem. I have the driver, upsd and upsmon running now. Thank you! Now I'm back to another issue, every 2 seconds I get in the logs: May 3 13:45:23 myhost upsd[2587]: Connected to UPS [eaton]: usbhid-ups-eaton It seems happy to do this forever. On Tue, May 3, 2016 at 8:17 AM, Charles Lepple <clepple at gmail.com> wrote: > On

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

On Apr 5, 2014, at 7:18 AM, Mick wrote: > $ upsrw -s "ups.delay.shutdown"="30" iDowell at localhost > Username (suzy): admin > Password: > OK This command is sending the value to the UPS (via the usbhid-ups driver). > $ upsc iDowell at localhost ups.delay.shutdown > 30 And this command ends up reading the value back from the UPS. > However, following

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

Hi All, I'm using an iDowell UPS with the usbhid-ups driver: $ upsc iDowell at localhost battery.charge: 100 battery.charge.low: 15 battery.runtime: 650 battery.type: Pb acc device.mfr: iDowell device.model: iBox device.serial: 00000001 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto

This took a long time because I had problems with my system. After I reloaded my operating system several times I found I had a bad memory module. Here is the output from newhidups for my Geek Squad GS1285U. It just kept repeating until I hit ctl-z. I think that this means nut will work for this ups. My computer is not powered by the ups yet. I did not want it to be powered down by accident.

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

I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12. I originally tried the hidups driver which seemed to work, but produced a large amount of unhandled events. Then I tried the newhidups which told me my ups wasn't supported. When I try using tripplite_usb -u root -DDDD /proc/bus/usb/002/002 I get that there isn't a match. But when I try using tripplite_usb -DDDD

I've acquired and installed NUT 2.4.1 on a D-Link DNS323 NAS. With exception of Load and Battery Temp readings all works well. A upsc ups at localhost command returns; battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 50 battery.date: 2001/09/25 battery.mfr.date: 2008/06/05 battery.runtime: 2122 battery.runtime.low: 120 battery.temperature: 3022999999999998800 battery.type:

> On Thu, 8 Sep 2016, Jeff Bowman wrote: > > > (Note: running > > 'upsc ups at localhost' echoes only a blank line to the screen, as do > > both 'upsmon' and 'upsd.') > > Something is wrong here. Is the daemon upsd running? On a Unix/Linux > system, the command ps aux | grep ups gives the report > > upsd 3196 0.0 0.0 13228

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

Peter Selinger wrote: > Hm. I need more information, as NUT seems to garble the values even > before I can see them. I am not so worried about the date and > temperatures (although, strangely, the battery replacement date > appears to be Sept 25, 2001, which makes no sense). But the voltage is > definitely important. > > [...] > Thanks Peter - I'll send the new

On Jun 8, 2015, at 8:23 PM, Greg Hersch <hersch.greg at gmail.com> wrote: > Hi Charles. I patched, reconfigured, remake'd, remake install'd - but > no change. however, some more likely helpful information below for > you. Thank you Odd. Are you sure that the new version of usbhid-ups got installed to the same path you are running? Also, there is no protection against