search for: battery_charge

...(at > least to the running time that is), but I don't know what to do with > them (and I can no longer find that piece of information...). Here's where the battery.charge variable is calculated: https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1099 battery_charge = (unsigned)(s_value[5]); (In that file, the 3003 protocol is denoted by "tl_model == TRIPP_LITE_SMARTPRO".) Due to the command prefix characters in the protocol, the ups.debug.S hex values are actually indexed from 1 as follows: 1 2 3 4 5 6 7 ups.debug.S: 31 30 30...

...s), but I don't know what to do with > > them (and I can no longer find that piece of information...). > > Here's where the battery.charge variable is calculated: > > https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1099 > > battery_charge = (unsigned)(s_value[5]); > > (In that file, the 3003 protocol is denoted by "tl_model == TRIPP_LITE_SMARTPRO".) > > Due to the command prefix characters in the protocol, the > ups.debug.S hex values are actually indexed from 1 as follows: > > 1...

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

...ipplite_usb.c.original 2014-05-19 16:20:58.251634449 -0400 > +++ tripplite_usb.c 2014-05-19 16:53:54.806609602 -0400 > @@ -1098,8 +1098,8 @@ > > - /* This may not be right... */ > - if(tl_model == TRIPP_LITE_SMARTPRO) { > - battery_charge = (unsigned)(s_value[5]); > - dstate_setinfo("battery.charge", "%u", battery_charge); > - } > } > > @@ -1167,9 +1167,22 @@ > hex2d(d_value+1, 2) * input_voltage_scaled / 120); > &gt...

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

...16:20:58.251634449 -0400 > > +++ tripplite_usb.c 2014-05-19 16:53:54.806609602 -0400 > > @@ -1098,8 +1098,8 @@ > > > > - /* This may not be right... */ > > - if(tl_model == TRIPP_LITE_SMARTPRO) { > > - battery_charge = (unsigned)(s_value[5]); > > - dstate_setinfo("battery.charge", "%u", battery_charge); > > - } > > } > > > > @@ -1167,9 +1167,22 @@ > > hex2d(d_value+1, 2) * in...

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