search for: battery_voltage_nominal

...dstate_setinfo("battery.charge", "%u", battery_charge); > - } > } > > @@ -1167,9 +1167,22 @@ > hex2d(d_value+1, 2) * input_voltage_scaled / 120); > > bv = hex2d(d_value+3, 2) * battery_voltage_nominal / 120.0 ; Does battery_voltage_nominal get set correctly? Theoretically, it should be 48, since the 2nd and 3rd digits of ups.debug.V are 08, and that gets multiplied by 6. Might be useful to have an intermediate value that doesn't scale to actual battery voltage for the charge calculation, s...

...ned)(s_value[5]); - dstate_setinfo("battery.charge", "%u", battery_charge); - } } @@ -1167,9 +1167,22 @@ hex2d(d_value+1, 2) * input_voltage_scaled / 120); bv = hex2d(d_value+3, 2) * battery_voltage_nominal / 120.0 ; - + // bv is 48V nominal rather than 12V + dstate_setinfo("battery.voltage", "%.2f", bv); + if(tl_model == TRIPP_LITE_SMARTPRO) { + if (bv / 4 >= V_interval[1]) + bp =...

...harge", "%u", battery_charge); > > - } > > } > > > > @@ -1167,9 +1167,22 @@ > > hex2d(d_value+1, 2) * input_voltage_scaled / 120); > > > > bv = hex2d(d_value+3, 2) * battery_voltage_nominal / 120.0 ; > > Does battery_voltage_nominal get set correctly? Theoretically, it > should be 48, since the 2nd and 3rd digits of ups.debug.V are 08, > and that gets multiplied by 6. Yes, as it appear as 48V in the output of upsc. > Might be useful to have an intermediate value...

On May 22, 2014, at 10:03 AM, Stefan Bruda wrote: >> >> Does battery_voltage_nominal get set correctly? Theoretically, it >> should be 48, since the 2nd and 3rd digits of ups.debug.V are 08, >> and that gets multiplied by 6. > > Yes, as it appear as 48V in the output of upsc. Good. > >> Might be useful to have an intermediate value that doesn't sca...

...ools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/<http://people.debian.org/%7Eaquette/> Free Software Developer - http://arnaud.quette.free.fr/ sample output: > > BATTERY_TIME_REMAIN: 52.0 > BATTERY_VOLTAGE: 263.0 > BATTERY_VOLTAGE_NOMINAL: 275.0 > BATTERY_CURRENT: 0.0 > BATTERY_CAPACITY: 100.0 > BYPASS_VOLTAGE: 231.0 > MAX_LOAD: 10000.0 > LOAD_WATTS: 1033.0 > LOAD_VA: 1245.0 > LOAD_PERCENT: 14.0 > INPUT_FREQUENCY: 49.9 > OUTPUT_FREQUENCY: 49.9 > BYPASS_FREQUENCY: 49.9 > INVERTER_TEMP: 0.0 > BATTER...

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

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?

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