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 <[email protected]> wrote: > > > On Oct 31, 2016, at 10:15 PM, Michael Evans <[email protected]> > 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.
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
