Nut upsuser - Nov 2016 - Questions about Eaton 5E 1, 100W 2, 200VA 6-Outlet UPS

> On Oct 31, 2016, at 10:15 PM, Michael Evans <mjevans1983 at
gmail.com> wrote:
> 
> Are there any other tests I can perform or ways that I can help gather data
to get the longer tests supported?
> 
The "test.battery.start" command takes a parameter in seconds
(defaults to 600):

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/nutdrv_qx_blazer-common.c#L286

It is possible that 600 seconds is too long for your model.

All of these NUT instant commands get converted to one- or two-character
commands to be sent to the UPS:

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/nutdrv_qx_q1.c#L40

It is probably worth a quick check to see if the vendor software has any
documentation on the battery test options.

The battery test commands are likely to stop before the battery gets drained too
much. You can also use a power strip or circuit breaker to cut the input power
to determine runtime.

Thank you for the help.

Unfortunately Eaton's website is a nightmare to get concrete data,
software, or anything else out of.  The reputation for the quality of their
components and the compatibility for NUT alone is what white-listed the UPS
as a selection option.

The source code is enlightening; they're actually controlled/fed back via a
bi-directional serial over USB terminal?  I honestly don't feel like the
knowledge of such a protocol should be a closely guarded secret.

However, based on their website, the age of the control chips, and their
currently showcased products, I am not hopeful for useful results from
searches there or inquiries to product support.




After a few more tries of software requests, I ended up switching it off at
the breaker panel for a full-depletion test.

The ups.load value fluctuated more than I'd prefer during the testing, at
one point going well outside of the range I anticipated it to remain within.

For the first run:

A very rough average reading of "33" (compared to the 60W bulb at
"2")
lasted under 7 min 40 seconds.  I feel like rounding both of those down for
safety.

The last OB (only) value was 22.20; 90 seconds before the last OB LB was
measured.

The last, and the second to last reading (30 sec apart) were 21.50 and
21.10.

So far these are the 'active' numbers, I need to wait for the battery to
recover before performing a lower power test.

default.battery.voltage.high = 24.10
default.battery.voltage.low = 21.50
runtimecal = 450,32,?,?


I plan to re-test with a load of  8 to 10 (about 300W) since I'm unlikely
to have a load much less than that.  Alternately, I could test with that
60W bulb...

However while the runtimecal recommends picking values that are as far
apart as reasonable, I want to target at least one end nearer to the likely
load during normal use as I feel that will increase accuracy of estimate
during normal use.


On Tue, Nov 1, 2016 at 6:23 AM Charles Lepple <clepple at gmail.com>
wrote:
>
> > On Oct 31, 2016, at 10:15 PM, Michael Evans <mjevans1983 at
gmail.com>
> wrote:
> >
> > Are there any other tests I can perform or ways that I can help gather
> data to get the longer tests supported?
> >
> The "test.battery.start" command takes a parameter in seconds
(defaults to
> 600):
>
>
>
https://github.com/networkupstools/nut/blob/v2.7.4/drivers/nutdrv_qx_blazer-common.c#L286
>
> It is possible that 600 seconds is too long for your model.
>
> All of these NUT instant commands get converted to one- or two-character
> commands to be sent to the UPS:
>
>
>
https://github.com/networkupstools/nut/blob/v2.7.4/drivers/nutdrv_qx_q1.c#L40
>
> It is probably worth a quick check to see if the vendor software has any
> documentation on the battery test options.
>
> The battery test commands are likely to stop before the battery gets
> drained too much. You can also use a power strip or circuit breaker to cut
> the input power to determine runtime.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161102/eba1531d/attachment.html>

This post is to share and ask for confirmation of the accuracy of my
thinking in relation to mapping the results of the measurements to the
configuration variables provided.


While setting up for this latest test I noticed an that the 60W bulb, when
combined with 3 power factor correcting PSUs of lower wattage devices, had
an effect of '6 units' of power output.

This leads me to a more logical conclusion of the percentage actually
representing approximately 9-10 watts per percent, but the UPS either
having difficulty measuring a more inductive loading or such a low loading.

In any event, even though I measured a voltage of 24.40 at the start of the
lower power test I'll pick what I guess is the more conservative value seen
in the previous test.
Similarly a smaller sample period allowed the observation of slightly lower
low voltages, which I shall also ignore.

After 29 min at approximately 10 units of load (it seemed to flux between a
mode average of 10 and 12 depending on which output winding was selected)
the incessant beeping stopped.

I'll round 1740 down for some additional padding.

[eaton5e]
       driver = nutdrv_qx
       port    = auto
       vendorid = 06da
       productid = 0003
       default.battery.voltage.high = 24.10
       default.battery.voltage.low = 21.50
       runtimecal = 450,32,1700,10


However, having just 100% drained (until the UPS shut it's self off) the
battery, and having given it only a few min to recharge a bit those
settings give an incorrect charge reading.

Should the default.battery.voltage.high be the value seen during on-line
power conditions (charged up)?

Will that have a negative effect on the (safe) accuracy of the remaining
runtime?


*battery.charge: 100 *battery.voltage: 24.20
battery.voltage.high: 24.10
battery.voltage.low: 21.50
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 0003
driver.parameter.runtimecal: 450,32,1700,10
driver.parameter.synchronous: no
driver.parameter.vendorid: 06da
driver.version: 2.7.4-151-g9209e18
driver.version.data: Q1 0.07
driver.version.internal: 0.28
input.frequency: 60.1
input.voltage: 122.3
input.voltage.fault: 122.0
output.voltage: 122.3
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 0
ups.productid: 0003
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 06da


Thank you in advance for any corrections to my understanding of the
documentation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161103/56c032fb/attachment.html>