Sophie

Sophie

distrib > Mandriva > 9.1 > ppc > by-pkgid > 37e222326095a93978d54b1564dd9954 > files > 132

apcupsd-3.10.5-1mdk.ppc.rpm

<!doctype html public "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
   <title>Testing Apcupsd</title>
   <meta name="Author" content="Kern Sibbald">
   <link rel=stylesheet href="apcupsd-styles.css" type="text/css">
</head>
<body>
<h1>Testing Apcupsd</h1>
<h2>Simple Signaling UPSes (sometimes called Dumb UPSes)</h2>
The following testing procedures apply only to Smart UPSes. If you have
a simple signaling UPS such as a BackUPS or other non-Smart UPS,
your testing procedures will be somewhat
different (Smart UPSes include SmartUPS and MatrixUPS models).
For example, for simple signaling (Dumb) UPSes, <b>apcupsd</b> is not currently
able to detect whether or not the serial cable is connected. In addition,
some simple signaling UPSes with certain cable combinations are not
able to detect the low battery condition. For more details
please see the <a href="cables.html">Cable Chapter
</a> of this manual, an more specifically, the <a href="cables.html#CableModes">Cable Modes section</a>.
Many of the other testing features should work similar to
described below. However, since it is easy to configure the
cable incorrectly and thus have premature shutdowns of
the UPS power, we <b>strongly</b> recommend, especially for simple
signaling (Dumb) UPSes, that you do most of
the initial testing with your computer plugged into the
wall rather than your UPS. Thus if the UPS power is suddenly
shutoff, your computer will continue to run. We also recommend
using the safe-apccontrol as described below, until you are
sure that the signaling is correct.
<p>Please note that if launch the execution of
<b>apcupsd</b> while your simple signaling UPS
is on battery power, it is very
likely that your UPS will immediately shut off the power.
This is due to the initialization of the serial port line signals.

<h2><a name="CableTest"></a>Determining Which Simple Signaling Cable You Have</h2>
For a simple signaling (dumb) UPS, it is important to know what
cable you have. All cables furnished by APC have the cable number
stamped on the side of the computer connector end of the cable.
Using this number with <b>apcupsd</b> will normally work fine.
<p></p>If you do not know what cable you have, you can use    
the <b>apctest</b> program to determine the type of cable
that you have. Please see the
<a href="apctest.html">apctest Chapter</a> of this manual for
the details of running <b>apctest</b>.

<h2>Smart UPSes</h2>
Most of rest of this chapter concerns testing Smart UPSes.
As noted above many of these tests will apply with
certain restrictions to Simple Signaling (dumb) UPSes.

<h2><a name="USBPort"></a>USB port</h2>
Please see the <a href="usb.html">USB Chapter</a> of this
manual for details of testing connections to a USB port.
Once you have the UPS and the computer connected, most of
the testing procedures described here apply equally well
to USB UPSes.

<h2>Checking the Installation</h2>
<p>Before continuing, please first read the section 
<a href="install.html#CheckInstall">Checking the Installation</a> in the Installation Section of
this manual.
<h2><a name="SerialPort"></a>Establishing Serial Port Connection</h2>
<p>Once you have compiled, installed, and invoked <b>apcupsd</b>, you should
wait to allow <b>apcupsd</b> to configure
itself and establish contact with the UPS. 
<p>If you see the following message about 30 seconds after starting
<b>apcupsd</b>:
<p class=tty>
apcupsd FATAL ERROR in apcserial.c at line 156<br>
PANIC! Cannot communicate with UPS via serial port.</p>
it means that <b>apcupsd</b> tried for about 30 seconds to
establish contact with the UPS via the serial port, but was
unable to do so.  Before continuing, you must correct this
problem.  Some of the possible sources of the problem are:
<ul>
<li style="margin-bottom: 0.1in">You have not configured the correct serial port name
    on the DEVICE directive in your <b>/etc/apcupsd/apcupsd.conf</b>
    configuration file.</li>
<li style="margin-bottom: 0.1in">The serial port that you have chosen has logins enabled. You
    must disable logins on that port, otherwise, the system prevents
    <b>apcupsd</b> from using it. Normally, the file /etc/inittab 
    specifies the ports for which a <b>getty</b> process is started (on Sun
    machines, the serial port program equivalent to <b>getty</b> is called <b>ttymon</b>).
    You must disable this for the port that you wish to use.</li>
<li style="margin-bottom: 0.1in">Make sure you are doing your testing
    as <b>root</b> otherwise, you may have permissions problems accessing
    the serial port.</li>
<li style="margin-bottom: 0.1in">You may have cabling problems, either with an incorrect cable,
    or the incorrect cable specification directive in the configuration
    file.</li>
<li style="margin-bottom: 0.1in">You may have a problem with the /etc/apcupsd/acpupsd.conf file.
    For example, check that you have specified the correct type of
    UPS and the correct networking directives. For more details, see
    the <a href="configure.html">Configuration Section of this manual</a>.</li>
<li style="margin-bottom: 0.1in">If you have a SmartUPS 5000 RM 15U or similar model, 
    that comes with a &quot;Web/SNMP management card&quot; in one of the &quot;Smart Slots&quot;,
    this card may interfere with the serial port operation. If you are having problems,
    please remove this card and try again.  Supposedly V3.0 of the card firmware has been 
    corrected to properly release the serial port.</li>
<li style="margin-bottom: 0.1in">Ensure that you have no other programs that are using
    the serial port. One user reported that he had problems because the serial port
    mouse (gpm) was using the same port as <b>apcupsd</b>. This causes intermittent 
    seemingly random problems.</li> 
<li style="margin-bottom: 0.1in">If you are using a WinNT or Win2000 machine, 
    the OS is probably attempting to attach a serial mouse to the
    port you are using (COM1 or COM2). To prevent this, edit your
    <b>c:\boot.ini</b> file, and you will find a line that looks something
    like the following:<p>
    multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation Version
    4.00"<p>
    Add the following to the end of the line: /NoSerialMice:COM1 (or COM2)
    so that the new line looks like:<p>
    multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation Version
    4.00" /NoSerialMice:COM1
    </li>
<li style="margin-bottom: 0.1in">If you are using a WinNT or Win2000 machine, 
    try connecting <b>apcupsd</b> to COM2 rather than COM1 (be sure to 
    change your c:\apcupsd\etc\apcupsd\apcupsd.conf to reflect the change).
    </li>
<li style="margin-bottom: 0.1in">If you are using a Solaris machine, you
    may have similar problems as described above for the WinNT machine.
    A possible fix is documented in the Sun section of the Configuration
    chapter of this manual.
    </li>
<li style="margin-bottom: 0.1in">Try connecting your UPS to another machine.
    If it works, then you probably have a bad serial port card. As unlikely
    as this may sound, at least two of our users have had to replace bad
    serial port cards. 
    </li>
<li style="margin-bottom: 0.1in">Try doing an <b>lsof /dev/ttyS0</b> where
    you replace the <b>/dev/ttyS0</b> with your serial port name. If you
    get no output, the port is free (or there is no physical port). If
    you get output, then another program is using the port, and you should
    see which one.</li>
<li style="margin-bottom: 0.1in">Try doing a <b>dmesg | grep tty</b>. This  
    may show you if a program has grabbed the port. (Thanks to Joe Acosta
    for the suggestion.)</li>
<li style="margin-bottom: 0.1in">If all else fails, make sure your system
    is configured for serial port support. </li>
<li style="margin-bottom: 0.1in">If you are running Linux, check your       
    <b>/proc</b> file system. For example: <b>cat /proc/devices</b> should
    print something like <b>4 ttyS</b> if you have a serial port. If
    your serial port is working, a <b>cat /proc/interrupts</b> should
    show the serial port usage (e.g. <b>4:   294553  XT-PIC  serial</b>)
    Also, <b>cat /proc/ioports</b> should show up something like
    <b>03f8-03ff : serial(auto)</b>. Or, <b>cat /proc/tty</b> should
    print a line like <b>serial  /dev/ttyS  4  64-127 serial</b>.
    Finally, a <b>cat /proc/tty/driver/serial</b> should print something
    like the following:<br>
    <b>serinfo:1.0 driver:5.05c revision:2001-07-08<br>
    0: uart:16550A port:3F8 irq:4 baud:9600 tx:1503168 rx:1461721 fe:8 RTS|DTR|RI</b>
    </li>
</ul>
The first thing to do is to look at your log file, usually
<b>/var/log/messages</b> because <b>apcupsd</b> writes more detailed
information to the log file whenever there is an error.
<p>
If you have a UPS that uses SubSmart or Smart protcol 
(see the <a href="configure.html#ConfigGeneral">Configuration</a> section
for a list of the UPSes using these protocols), 
you can manually test the serial communications with the
UPS by starting a serial port communications program 
(such as <b>minicom</b>, <b>tip</b>, or <b>cu</b>) with the settings
2400 8N1 (2400 baud, 8 bits, no parity, 1 stop bit). Be extremely
careful what you send to your UPS as certain characters may cause
it to power down or may even cause damage to the UPS. Try sending an
upper case Y to the UPS (without a return at the end). It should respond
with SM.  If this is not the case, review the possible problems listed
above. If you fat finger the Y and enter y instead, no cause for
alarm, you will simply get the APC copyright notice.
<p></p>

<p>Once you are sure that serial port communications is working,
proceed to the next test.
<h2>PS Test</h2>
After you start <b>apcupsd</b>, execute the following
command:</p>
<p class=tty> ps fax</p>

<p>or the equivalent for your system.
If you are running on Linux and using the fork()ing version
of apcupsd, you should something similar to the following 
output.</p>
<pre>
4492 ?        S      0:00 apcmain       -f /etc/apcupsd/apcupsd.conf
4496 ?        S      0:00  \_ apcser        -f /etc/apcupsd/apcupsd.conf
4497 ?        S      0:00  \_ apcnis        -f /etc/apcupsd/apcupsd.conf
</pre>
<p>This indicates that <b>apcupsd</b> is up and running and has started the
two (default) child processes.</p>
<dl>
        <dt>apcmain</dt>
        <dd>is the main program that waits until it receives a 
  termination signal (SIGTERM) or one of the child processes dies. </dd>
        <dt>apcser</dt>
        <dd>is the process that manages the serial port and takes 
  any actions (generates events) that are necessary as a result of a change of 
  state of the UPS. </dd>
        <dt>apcnis</dt>
        <dd>is the Network information server process that 
  provides EVENTS and STATUS information over the network. This
                information is used by the CGI programs.
        </dd>
</dl>
<p>
If you are running on a non-Linux system, or using pthreads on a
Linux system (recommended), your output will probably not show the
names of the processes and will appear more like the following:
<pre>
  632 ?        S      0:00 /sbin/apcupsd -f /etc/apcupsd/apcupsd.conf
  841 ?        S      0:00  \_ /sbin/apcupsd -f /etc/apcupsd/apcupsd.conf
  842 ?        S      0:00      \_ /sbin/apcupsd -f /etc/apcupsd/apcupsd.conf
</pre>

<h2>Logging Test</h2>
<p>Once you have established that the proper processes are running, do a
tail of the system log file, normally <b>/etc/var/messages</b>:
<p class=tty>tail /etc/var/messages</p> 
You should see output that looks similar to the following:</p>
<p class="indent">Dec 5 17:01:05 matou apcupsd[5917]: apcupsd 3.7.2 startup
succeeded</p>
<p>And if you have configured the network information server, you should
also see:</p>
<p class="indent">Dec 5 17:01:05 polymatou apcupsd[5975]: apcserver startup succeeded</p>
These messages should also appear in the temporary <a href="configure.html#ConfigInfoServer">EVENTS</a>
file (<b>/etc/apcupsd/apcupsd.events</b>)
if you are using the default configuration file.

<h2>apcaccess Test</h2>
This test consists of running <b>apcaccess</b> to see if <b>apcupsd</b>
is properly updating its internal variables. Please note that if you
are running a pthreaded version of <b>apcupsd</b> (installed from rpm
or --enable-pthreads on the ./configure line), you must enable the    
<b>apcupsd</b> Network Information Server in your configuration file
for <b>apcaccess</b> to work.
<p>   
To run the apcaccess test, use the
following command:
<p><b>apcaccess status</b></p>
Depending on the type of UPS you have, you will get slightly
different output, but an example For a Smart-UPS is as follows:
<pre>
APC      : 001,048,1088
DATE     : Fri Dec 03 16:49:24 EST 1999
HOSTNAME : daughter
RELEASE  : 3.7.2
CABLE    : APC Cable 940-0024C
MODEL    : APC Smart-UPS 600
UPSMODE  : Stand Alone
UPSNAME  : SU600   
LINEV    : 122.1 Volts
MAXLINEV : 123.3 Volts
MINLINEV : 122.1 Volts
LINEFREQ : 60.0 Hz
OUTPUTV  : 122.1 Volts
LOADPCT  :  32.7 Percent Load Capacity
BATTV    : 26.6 Volts
BCHARGE  : 095.0 Percent
MBATTCHG : 15 Percent
TIMELEFT :  19.0 Minutes
MINTIMEL : 3 Minutes
SENSE    : Medium
DWAKE    : 000 Seconds
DSHUTD   : 020 Seconds
LOTRANS  : 106.0 Volts
HITRANS  : 129.0 Volts
RETPCT   : 010.0 Percent
STATFLAG : 0x08 Status Flag
STATUS   : ONLINE 
ITEMP    : 34.6 C Internal
ALARMDEL : Low Battery
LASTXFER : Unacceptable Utility Voltage Change
SELFTEST : NO
STESTI   : 336
DLOWBATT : 05 Minutes
DIPSW    : 0x00 Dip Switch
REG1     : N/A
REG2     : N/A
REG3     : 0x00 Register 3
MANDATE  : 03/30/95
SERIALNO : 13035861
BATTDATE : 05/05/98
NOMOUTV  : 115.0
NOMBATTV :  24.0
HUMIDITY : N/A
AMBTEMP  : N/A
EXTBATTS : N/A
BADBATTS : N/A
FIRMWARE : N/A
APCMODEL : 6TD
END APC  : Fri Dec 03 16:49:25 EST 1999
</pre>
<p>
For a simple signaling or dumb UPS such as BackUPS, your output will be
very minimal as follows:
<pre>
APC      : 001,012,0319
DATE     : Mon Feb 18 09:11:50 CST 2002
RELEASE  : 3.8.5
UPSNAME  : UPS_IDEN
CABLE    : APC Cable 940-0128A
MODEL    : BackUPS
UPSMODE  : Stand Alone
STARTTIME: Mon Feb 18 09:11:45 CST 2002
LINEFAIL : OK
BATTSTAT : OK
STATFLAG : 0x008 Status Flag
END APC  : Mon Feb 18 09:15:01 CST 2002
</pre>
<p>If you see the above output, it is a good sign that <b>apcupsd</b>
is working.
Assuming that the output looks reasonable, check the following variables:
<dl>
<dt>LINEV</dt>
<dd>This is the line voltage and it should be a value that is appropriate for your
equipment. In the USA, it is typically about 120 Volts while in Europe, it is about
220 Volts.</dd>
<dt>BATTV</dt>
<dd>Unless you have additional battery packs, this should be near 24 Volts plus or
minus 5 Volts.</dd>
<dt>STATUS</dt>
<dd>This is the status of the UPS and it should normally be <b>ONLINE</b>.</dd>
</dl>
<p>
<p>If you see a message to the effect of:
<pre>
attach_shmarea: shared memory version mismatch (or UPS not yet ready to report)
</pre>
or if all the displayed values are zero, you have not waited long enough.
Wait a bit longer and then re-execute the <b>apcaccess status</b> command.
<p>If you see a message to the effect of:
<pre>
APCACCESS FATAL ERROR in apcaccess.c at line 336
tcp_open: cannot connect to server localhost on port 7000.
</pre>
It means that you have probably not enabled NIS in <b>apcupsd</b>.      

<h2>Communications Test</h2>
<p>At this point, you should ensure that
<b>apcupsd</b> is handling the serial port correctly. 
This test assumes you have a Smart UPS. If you have
a simple signaling UPS, please skip to the next section
(Simulated Power Fail Test). 
<p>When <b>apcupsd</b> detects
a problem, it generates an EVENT, which consists of sending
a message to the system log then invoking the <b>apccontrol</b>
script (normally in <b>/etc/acpupsd/apccontrol</b>) to handle
the event.</p>
<p>
In order to create an event, remove the serial port plug 
from the back of your computer or from
the back of the UPS. Within 6 seconds, <b>apcupsd</b> should detect the lack of serial port
communications and broadcast a <b>wall</b> message indicating that the
serial port communications was lost:</p>
<p class="tty">Warning serial port communications with UPS lost.</p>
<p>At the same time, it sends the same message to the system log and
to the temporary EVENTS file (<b>/etc/apcupsd/apcupsd.events</b>).
<p>Plug the serial port plug back into your computer, and within about 12
seconds, <b>apcupsd</b> should reestablish communications and
broadcast and log the following message:</p>

<p class="tty">Serial communications with UPS restored.</p>
<p>If these messages are logged but not broadcast, either you have your
<b>mesg</b> permission set to <b>no</b> (see <b>man wall</b>) or
there is a problem with <b>apccontrol</b>. If you are running a
window manager such as GNOME and don't have a console window open,
you may not receive the <b>wall</b> messages. However, you should
find them in your system log file (normally <b>/var/log/messages</b> and
in the temporary EVENTS file, <b>/etc/apcupsd/apcupsd.events</b>.
For example, to observe these events in the temporary EVENTS file, you
might do a
<p class="tty">tail -f /etc/apcupsd/apcupsd.events </p>
before running the test.
<p>
If you do not observe these messages, you should correct this
problem before proceeding with additional tests.</p>

<h2><a name="PowerFailSimulation"></a>Simulated Power Fail Test</h2>
At this point, you should verify that in the event of a power fail 
<b>apcupsd</b> properly calls <b>apccontrol</b>. This test is appropriate
for all models of UPSes (Smart or dumb). 
<p>
To avoid the possibility that <b>apcupsd</b> might shutdown your system,
locate where <b>apccontrol</b> resides on your system (normally,
<b>/etc/apcupsd/apccontrol</b>. Move this script to another location
e.g. <b>apccontrol.save</b> and replace it with the script found in
<b>examples/safe.apccontrol</b>. When that is done, ensure that
your UPS battery is fully charged and that you have at least 5 minutes
of remaining runtime on the batteries. This can be done by examining the
values of the <b>BATTCHG</b> and <b>TIMELEFT</b> variables in the printout
of <b>apcaccess status</b>. 
<p>Athough this should not be necessary, as an extra precaution, you
can shutdown your machine, remove the plug from the UPS you are testing,
and plug your machine into another UPS or directly into the wall.  Doing
so, will ensure that the UPS doesn't cut the power to your machine at
a bad time. Remember at the end of the testing to plug your machine back
into the UPS.</p>

<p>To begin the test, pull the power plug from the UPS. The first time
that you do this, psychologically it won't be easy, but after you
have pulled the plug a few times, you may even enjoy it as I do.
If all goes well,
<b>apcupsd</b> should detect the power failure and print several warning
messages. The first should appear after 5 to 6 seconds and read:</p>

<p class="tty">Warning power loss detected.</p>

Then generally 6 seconds later, <b>apcupsd</b> is sure that it
isn't a transient effect, so it sends:

<p class="tty">Power failure. Running on UPS batteries.</p>

After a few more seconds (total around 15 seconds), 
plug the power cord back in and ensure
that <b>apcupsd</b> is aware that the power has returned. It 
should print:

<p class="tty">Power has returned...</p>
<p>If you do not observe the above messages, please correct the 
situation before proceeding. The most likely cause of problems are:
<ul>
<li><b>apcupsd</b> doesn't recognize the power failure because
the configuration directives are not correct. E.g. wrong cable.</li>
<p>
<li>The file <b>/etc/apcupsd/apccontrol</b> doesn't exist or
is not marked as executable.</li>
</ul>
<p>
At this point, we recommend that you do a simulated power down of your system. 
If you are adventuresome or have been through this before, skip to the
next section in this manual and do the real power fail shutdown.
If you continue with the simulated power down and if
all goes well, <b>apcupsd</b> will go through all the motions without actually 
shutting down the system. Continue using the safe <b>apccontrol</b> that
you installed. Edit the configuration file <b>/etc/apcupsd/apcupsd.conf</b> and
change the value of <b>TIMEOUT</b> from 0 to something like 30. Doing
so will cause <b>apcupsd</b> to attempt to shutdown the system 30 seconds 
after it detects a power failure. Once this change has been made, you must
stop and restart <b>apcupsd</b> for the new configuration value to take
effect.
<p>
Once again, pull the power plug, and if all goes as expected, <b>apcupsd</b> should
attempt to shutdown the system about 30 seconds after it detects the power
failure. All the messages should be displayed by <b>wall</b> or by the
<b>tail -f </b> command. The precise message is determined by what is printed
in <b>/etc/apcupsd/apccontrol</b> for the <b>doshutdown</b> event. Though it
varies from system to system, it will generally be something like:
<p class="tty">Beginning Shutdown Sequence</p>
When <b>apcupsd</b> this message prints, reconnect the power. <b>apcupsd</b> should detect that
the power has been restored and attempt to cancel the shutdown.
<p>
<b>IMPORTANT</b> after this test, please replace the changed <b>apccontrol</b>
and <b>apcupsd.conf</b> with the original files.

<h2>System Shutdown Test</h2>
This is an intermediate test that you can do, for all UPS models
before doing the Full Power Down Test. First modify the
<b>/etc/apcupsd/apccontrol</b> file so that in the <b>killpower)</b>
case, the line that re-executes <b>apcupsd</b> with the <b>--killpower</b>
option is commented out. The original line probably looks something like:
<p class="tty">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;${APCUPSD} --killpower
<p>
when it is commented out, it looks like:
<p>
<p class="tty">#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;${APCUPSD} --killpower
<p>Now when you pull the power plug, and either the timer expires or
the batteries are exhausted (see the next section for more details), the
system should be fully shutdown.  
<p>After performing this test, please be sure to restore <b>/etc/apcupsd/apccontrol</b>
to its previous state.

<h2>Full Power Down Test</h2>
To complete the testing, you should do a power fail shutdown of your system.
This test is applicable to all UPS models.
Please do a backup of your system or take other precautions before
attempting this to avoid the possibility of lost data due to a problem
(I have been through this at least 10 times and never once had problems,
but we all know that someday something will go wrong).
<p>Before proceeding, please ensure that your halt script or the equivalent
has been properly updated by the install process to contain the logic to
call <b>apcupsd --killpower</b> when it detects a power failure situation 
(the presence of a /etc/powerfail file). See the <a href="install.html">install section</a>
of this manual, or the README files for additional details about the halt
modifications necessary.
<p>When you are ready to do the test,
either simply pull the plug and wait for the batteries to become exhausted, or
set the <b>TIMEOUT</b> configuration directive to something like 60 so that the
system will shutdown before the batteries are exhausted. We recommend doing
the full shutdown without using <b>TIMEOUT</b> to correctly simulate a real
power failure, but the choice is yours (I did it once here, but now use
TIMEOUT 30).
<p>
If all goes well, your system should be shutdown before the batteries
are completely exhausted and the UPS should be powered off by
<b>apcupsd</b>.  Please be aware that if you do the full power down, you
must ensure that your UPS is totally powered off.  Otherwise, it may
have been given the command to power off, but due to a long grace period
it is still waiting.  If you were to reboot your computer during the
grace period, the UPS could then suddenly turn off the power (this
happened to me).  To avoid this problem, always wait for your UPS to
power itself off, or power if off manually before restarting your
computer.  On my system, the UPS is configured as at the factory to have
a 180 second grace period before shutting off the power.  During this
type of testing, 180 seconds <b>seems</b> like an eternity, so please
take care to either wait or manually power off your UPS. To determine
what grace period is programmed into your UPS EEPROM, run <b>apcaccess
eprom</b> and look at the &quot;Shutdown grace delay&quot;.

<h2><a name="ShutdownSequence"></a>Shutdown Sequence</h2>
If you experienced so problems with the above testing procedures,
or if you are porting <b>apcupsd</b> to another system, or you
are simply curious, you may want to know exactly what is going on
during the shutdown process. If so, please see the
<a href="shutdown.html">Shutdown Chapter</a> of this manual.

<h2>Testing the CGI Programs</h2>
Please see the <a href="cgiprogs.html">CGI Programs</a> chapter of this
manual for how to test the Network Information Server and the CGI programs.

<h2>Recalibrating the UPS Runtime</h2>
This section does not apply to simple signaling or dumb UPSes such
as the BackUPS.
<p>
Smart UPSes internally compute the remaining runtime, and <b>apcupsd</b>
uses the value supplied by the UPS. As the batteries age (after say
two or three years), the runtime computation may no longer be accurate
since the batteries no longer hold the same charge. As a consequence,
in the event of a power failure, the UPS and thus <b>apcupsd</b> can
report a runtime of 5 minutes remaining when in fact only one minute
remains. This can lead to a shutdown before you might expect it, because
regardless of the runtime remaining that is reported, the UPS will
always correctly detect low batteries and report it, thus causing
<b>apcupsd</b> to correctly shutdown your computer.
<p>
If you wish have the UPS recalibrate the remaining runtime calculations,
you can do so manually as the current version of <b>apcupsd</b> does not
support this feature. To do so,
<ul>
 <li>Shutdown <b>apcupsd</b></li>
 <li>contact your UPS directly using some terminal program
  such as minicom, tip, or cu with the settings
  2400 8N1 (2400 baud, 8 bits, no parity, 1 stop bit). Be extremely
  careful what you send to your UPS as certain characters may cause
  it to power down or may even cause damage to the UPS. Try sending an
  upper case Y to the UPS (without a return at the end). 
  It should respond with SM.  If this is not the case, read
  the chapter on testing. If you fat finger the Y and 
  enter y instead, no cause for alarm, you will simply get the APC 
  copyright notice.</li>
 <li>when you are sure you are properly connected send an upper case
  D (no cr). This will put the UPS into calibration mode,
  and it will drain the battery down to 25% capacity (35% for a
  Matrix) at which point it will go back on the mains. 
  In doing so, it will recompute the runtime calibration.</li>
 <li>If you wish to abort the calibration, enter a second D command.</li>
 <li>When you are done, restart apcupsd.</li>
</ul>
In principle, you should be able to do this with the computer          
powered by the UPS, but if you wish to be completely safe, you should
plug your computer into the wall prior to performing the runtime 
calibration. In that case, you will need to artificially load the 
UPS with light bulbs or other means. You should supply a load of
about 30 to 35% but not more than 50%. You can determine the load
by looking at the output of the <b>apcaccess status</b> command
while <b>apcupsd</b> is running.
<p>
You should not run the recalibration command more than once or 
twice per year as discharging these kinds of batteries tends 
to shorten their life span.
<hr>

<a href="stopping.html" target="_self"><img src="back.gif" border=0 alt="Back"></a>
<aahref="troubles.html" target="_self"><img src="next.gif" border=0 alt="Next"></a>
<a href="index.html"><img src="home.gif" border=0 alt="Home"></a>
</body>
</html>