search for: low_batteri

Displaying 5 results from an estimated 5 matches for "low_batteri".

Did you mean: low_battery
2007 May 19
1
Powerware Prestige 1000VA
Hi all, I've more-or-less got NUT 2.0.4 working with my Powerware Prestige 1000VA UPS (serial), but unfortunately NUT is flagging LOW_BATTERY continuously, which is a tad embarrassing when power fails ;-) The numbers from upsc blah at localhost seem reasonable: ambient.temperature: 24.5 battery.charge: 99 battery.runtime: 3999 battery.voltage: 69.2 driver.name: bcmxcp
2009 Jan 26
1
ups emerson liebert GTX2 ESP-II serial protocol demo
2009/1/22 Spiros Ioannou <sivann at gmail.com> > Cher Arnaud, > Hi Spiros, > I send you a demo that reads info from an Emerson Liebert > GXT2-10000T230 through the RS-232 port. This uses the "ESP-II (ESP 2) > Protocol". > Current supported data includes: measurements (voltage, temperature, > etc) , ID strings (serial number, etc), status flags (inverter on,
2005 Dec 05
3
Powerware 5125 works ?
Hi there. At the moment I'm trying to get my HP T1500 XR (Powerware 5125) UPS to work with NUT. NUT registers that the UPS is on battery/online, but I just cant get the program to shut down the computer I'm using the original cable (thus I didn't enter anything in the ups.conf file) If I remove the cable and run the daemon/program the computer will shutdown after x minutes defined in
2009 Oct 18
3
liebert GTX2 ESP-II serial support
2009/10/15 Farkas Levente <lfarkas at lfarkas.org> > hi, > i read your thread at: > > http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-January/003772.html > > http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-January/003775.html > we've got exactly the same problem that we need a nut driver for liebert > ups. is there any progress in this field?
2010 Apr 02
7
Liebert GXT2 NUT driver
Hi guys, I found the troblue and fix it! I attached the patch. The trouble was in the command reply buffer use. You compute the value that value = reply[6]*256+reply[5] <- it's wrong The right solution: value = reply[5] * 256 + reply[6]; And other bug, battery.runtime compute, you divide this value 60 <- it's wrong right value: divide 1.0 I continue the work on this