search for: battery_charged

On May 15, 2014, at 9:39 PM, Stefan Bruda wrote: > What bugs be though is that I cannot seem to be able to read the > remaining run time on battery. The battery charge is also widely > inaccurate (it drops to zero really fast and stays there). I read > somewhere that the usb.debug numbers may hold the key to this (at > least to the running time that is), but I don't know what

Hello, First of all thank you so much for the information. At 22:43 -0400 on 2014-5-15 Charles Lepple wrote: > > On May 15, 2014, at 9:39 PM, Stefan Bruda wrote: > > > What bugs be though is that I cannot seem to be able to read the > > remaining run time on battery. The battery charge is also widely > > inaccurate (it drops to zero really fast and stays

Hello, I own an older Tripp Lite SMART3000RM2U (protocol 3003). It does not work with usbhid-ups but it mostly works with the tripplite_usb driver (nut 2.7.1, the latest in the Gentoo tree), in the sense that the status (on line, on battery, etc.) is detected correctly, the machine is shut down on critical battery, and I can even get some information from the UPS. This is how it all looks:

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

On May 19, 2014, at 7:12 PM, Stefan Bruda wrote: > Hello, > > First of all thank you so much for the information. No problem, glad it is useful. > [...] > Therefore as far as my UPS is concerned s_value[5] is wildly > incorrect. So it turns out that the RM15002U also does not report anything useful for s_value[5]:

...896V04 > SN: 08009R0056BW932 > MANUF_DATE: 04JAN08 > PFC_ON: YES > DC_DC_CONVERTER_STATE: NO > ON_INVERTER: YES > UTILITY_STATE: NO > INRUSH_LIMIT_ON: NO > OVERTEMP_WARNING: NO > BATTERY_TEST_STATE: NO > INPUT_OVERVOLTAGE: NO > ON_BATTERY: NO > ON_BYPASS: NO > BATTERY_CHARGED: YES > BATTERY_LIFE_ENHANCER_ON: NO > REPLACE_BATTERY: NO > BOOST_ON: NO > DIAG_LINK_SET: NO > BUCK_ON: NO > UPS_OVERLOAD: NO > BAD_INPUT_FREQ: NO > SHUTDOWN_PENDING: NO > CHARGER_FAIL: NO > LOW_BATTERY: NO > OUTPUT_UNDERVOLTAGE: NO > OUTPUT_OVERVOLTAGE: NO >...

Hello, At 22:19 -0400 on 2014-5-19 Charles Lepple wrote: > > On May 19, 2014, at 7:12 PM, Stefan Bruda wrote: > > > Therefore as far as my UPS is concerned s_value[5] is wildly > > incorrect. > > So it turns out that the RM15002U also does not report anything useful for s_value[5]: > >

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?

Hi All, I'm a system administrator of a large data center, and I've recently replaced the machine that acted as the nut master for our cluster/cloud. The machine that was interfacing with our Powerware 9135 450KVA 3 phase UPS, not to confused with Eaton's Powerware 9135, and was a Fedora Core 4 box running nut version 2.0.3-4 connected by a serial cable. We are using these versions

Hi all, I just acquired a new UPS and have been trying to get it to work with NUT. It's an Eaton/Powerware 9120 700i with both USB and RS-232 interfaces. I first tried the USB interface (using bcmxcp_usb) and found that the UPS worked fine for a few minutes but then NUT lost communication and didn't get it back. In addition the UPS itself seemed to lock up at one point such that the

Dino, Alexey, there are a number of users suffering issues with your Powercom devices. Could you (Dino, and Keven if possible) please have a look at the below one, from Angela, and check for a fix? I've scheduled to release 2.6.1 next week, and having that fixed is part of the list. 2011/5/16 Angela Williams <angierfw at gmail.com> > Hi All > > On Friday 13 May 2011 at

Good evening, I tried getting this to work a couple years back but didn't have enough time to do all the debugging that was needed (apologies to the devs who tried to help at that time). It's working much better now, but I'm still not able to get an answer from upsc. Can anyone help me work out why I'm getting the error when querying with upsc: Error: Data stale My

Good evening, I tried getting this to work a couple years back but didn't have enough time to do all the debugging that was needed (apologies to the devs who tried to help at that time). It's working much better now, but I'm still not able to get an answer from upsc. Can anyone help me work out why I'm getting the error when querying with upsc: Error: Data stale My

List: I have an Eaton (Powerware) Model 5115 and am using the bcmxcp_usb driver on a OpenBSD 4.9 system. The upsdrvctl start appears to work and I get a message in my daemon log stating that it successfully started. I can successfully start the upsd daemon. I get a successful start messaage from the upsmon program, but it soon complains of 'stale' data. It looks like the driver