Back-ups XS BX1500G switches to battery and shuts off when USB cable connec

[Anonymous user]

PC: Dell PE1800 server
OS: Ubuntu 7.04
Management SW: apcupsd

UPS Model: BX1500G

UPS Load: 18-20%
Estimated Run Time: 33min


I've got a new Back-ups XS BX1500G. I've gotten the 'apcupsd' software in Linux configured to talk to the UPS and to successfully shut down the server when the UPS loses AC power and the designated battery level is reached. The communication with the UPS appears to be working fine.


I have been testing the setup by setting a threshold in the software to a threshold a couple of percentage points below the current battery capacity and unplugging AC power. After unplugging AC power I can watch the battery capacity drop until it hits my programmed threshold, and the 'apcupsd' software successfully shuts down the server. Everything is working fine to this point.

After the server shuts down I restore AC power to the UPS. If the USB cable is plugged into the server, when power is restored the UPS will go through its self test and switch to battery power then after 30-60 seconds will cut power to the server. If I remove the USB cable, the UPS will run off of the restored AC power and does not shut off.

I can futz around with the UPS and eventually get it out of this mode. I haven't figured out exactly what gets it out of this mode. Once out of that mode everything seems to work fine again until I run another AC power loss test.

[Anonymous user]

Having the same problem with a Back-UPS Pro 550, booting to OS still loop the complete procedure.

[Anonymous user]

PC: Dell PE1800 server
OS: Ubuntu 7.04
Management SW: apcupsd

UPS Model: BX1500G

UPS Load: 18-20%
Estimated Run Time: 33min


I've got a new Back-ups XS BX1500G. I've gotten the 'apcupsd' software in Linux configured to talk to the UPS and to successfully shut down the server when the UPS loses AC power and the designated battery level is reached. The communication with the UPS appears to be working fine.


I have been testing the setup by setting a threshold in the software to a threshold a couple of percentage points below the current battery capacity and unplugging AC power. After unplugging AC power I can watch the battery capacity drop until it hits my programmed threshold, and the 'apcupsd' software successfully shuts down the server. Everything is working fine to this point.

After the server shuts down I restore AC power to the UPS. If the USB cable is plugged into the server, when power is restored the UPS will go through its self test and switch to battery power then after 30-60 seconds will cut power to the server. If I remove the USB cable, the UPS will run off of the restored AC power and does not shut off.

I can futz around with the UPS and eventually get it out of this mode. I haven't figured out exactly what gets it out of this mode. Once out of that mode everything seems to work fine again until I run another AC power loss test.

[BillP]

i believe this is normal actually..

here is the UPS timeline for with and without software, seen below. the UPS needs to reboot its outlets in order to signal your computer to turn on but i think you are interrupting the process during your testing so you are seeing undesired behavior. i assume that apcupsd acts the same way as PCPE in this manner.

this is what it sounds like to me, someone please correct me if you think otherwise.


Shutdown time line, software not installed:*

1. UPS goes to battery, the on battery beep sounds

2. The UPS will sound the on battery beep until it reaches the last few minutes of run time. The length of time depends on the load and how old the battery is.

3. When the unit reaches the last few minutes of battery life it will then sound its low battery alarm.

4. Just before the battery is completely exhausted the ups will turn itself off.

5. If the UPS went to battery due to a brown out the unit at this point will be in LVSM until the voltage becomes acceptable again.

PowerChute Personal Edition/Software default shutdown time line:*

1. UPS goes to battery and PCPE/software starts its preserve battery power counter.

2. When the counter expires it sends a command to the UPS to start counting its turn off delay and then commands the OS to shutdown.

*3. The operating system shuts down and the UPS continues to count its turn off delay. (Once the UPS finishes counting its turn off delay it will reboot and nothing can stop this from happening.)*

*4. The UPS cuts power to the outlets then rechecks to see if the incoming power is acceptable. If it is not it waits there until power returns.*

5. If the UPS went to battery due to a brown out the unit at this point will be in LVSM until the voltage becomes acceptable again.

[Anonymous user]

Thanks for the quick reply. I'm not sure I'm seeing a correlation between the descriptions above and the behavior I'm seeing.

I'm setting the shutdown threshold in my 'apcupsd' software to shut down at say 96% battery when the battery charge is at 98% (I've never even approached full battery discharge in my testing. All of my testing was above 75% battery charge.).

I then pull the AC plug for the UPS, it switches to battery, and I can watch the battery charge slowly drop until I hit my 96% trigger for the management software. The management software initiates shutdown of the OS.

The OS shuts down, PC turns off, and the UPS runs for a while longer and then the UPS turns off completely.

After the UPS shut down completely I plugged the UPS back into the AC power. I believe I had to hit the power switch on the UPS (not 100% sure there) to turn it back on. When I then hit the power switch on the PC the UPS switches over to battery immediately if the USB cable is plugged into the PC (it doesn't do that if USB is not plugged in).

After switching to battery the UPS will run on battery for 30-60 seconds (haven't timed it exactly) and then it cuts power to the PC. AC power is connected to the UPS and the battery capacity was at around 96% when it cut power to the PC. The USB cable is connected to the PC, but the PC OS is not yet running at this point, so nothing is talking to the UPS. I'm guessing the UPS is seeing voltage on the USB power line.

[BillP]

hmm ok. i needed to re-read this a few times to understand.

After the UPS shut down completely I plugged the UPS back into the AC power. I believe I had to hit the power switch on the UPS (not 100% sure there) to turn it back on. When I then hit the power switch on the PC the UPS switches over to battery immediately if the USB cable is plugged into the PC (it doesn't do that if USB is not plugged in).

this sounds normal but you should not need to turn the UPS back on. upon reconnecting AC power, i'd give it a minute or two and see of the UPS turns on back by itself, after it realizes there is voltage at the AC outlet. also, is there any other settings you have set in regards to powering back on? I am only a little familiar with apcupsd so i am not sure if something else is configurable like a turn on delay, etc

one part i dont understand is:

When I then hit the power switch on the PC the UPS switches over to battery immediately if the USB cable is plugged into the PC (it doesn't do that if USB is not plugged in).

I assume this isnt a mistake/typo? i dont know why the UPS would switch to battery power, if AC power is lost. maybe you are referring to the UPS self test that the UPS goes through every time it comes back on? how long is the UPS on battery at this point for?

i am not sure if it is the way that the software is shutting the UPS down but i'd have to assume that this is expected behavior.

let me know if you have any other comments. thanks!

[Anonymous user]

i picKed a winna wrote:
hmm ok. i needed to re-read this a few times to understand.

After the UPS shut down completely I plugged the UPS back into the AC power. I believe I had to hit the power switch on the UPS (not 100% sure there) to turn it back on. When I then hit the power switch on the PC the UPS switches over to battery immediately if the USB cable is plugged into the PC (it doesn't do that if USB is not plugged in).

this sounds normal but you should not need to turn the UPS back on. upon reconnecting AC power, i'd give it a minute or two and see of the UPS turns on back by itself, after it realizes there is voltage at the AC outlet. also, is there any other settings you have set in regards to powering back on? I am only a little familiar with apcupsd so i am not sure if something else is configurable like a turn on delay, etc

I'm not 100% sure I had to hit the power button on the UPS. I went through so many permutations trying to figure this out it's hard to remember what I did and when. I'll give it another try this evening.

one part i dont understand is:

When I then hit the power switch on the PC the UPS switches over to battery immediately if the USB cable is plugged into the PC (it doesn't do that if USB is not plugged in).

I assume this isnt a mistake/typo? i dont know why the UPS would switch to battery power, if AC power is lost. maybe you are referring to the UPS self test that the UPS goes through every time it comes back on? how long is the UPS on battery at this point for?

Nope that's not a typo. This is really the whole crux of the problem. When the UPS gets into this mode, I cannot get a complete boot because as soon as the PC turns on and the USB cable is connected, the UPS switches to battery and shuts off after a delay (30-60 seconds). AC power is still present, so I don't understand why the UPS is switching to battery and shutting off.

[BillP]

okay, well i would just try the test once and see if you can take any notes on what you are trying. then we can see. i am getting confused though cause it doesnt seem normal but i am sure we will find out there is a reason.

[Anonymous user]

Okay, so I was able to run one test last night. I need to run more some more, but here's what I did...

1) Server was running, UPS plugged into AC, USB cable unplugged.
2) I plugged the USB cable into the UPS and it immediately switches to battery power (UPS still plugged into AC).
3) I initiate a manual shutdown of the server to shut it down before UPS cuts power.
4) Server shuts down and 60 seconds after I plugged in the USB cable (UPS still plugged into AC), the UPS cuts power.
5) I leave the UPS off for five minutes.
6) USB cable still plugged in, I turn on UPS and turn on computer. The UPS does not switch to battery (as it has done previously).
7) OS boots. Battery level is at 100%. I set the BATTERYLEVEL in the 'apcupsd' daemon to trip at 98%.
8) Unplug AC and watch battery level drop to 98% and 'apcupsd' initiates OS shutdown.
9) OS shuts down. UPS cuts power.
10) Wait 5 minutes, plug UPS back into AC.
11) UPS powers on, computer powers on and boots (USB cable still connected).
12) UPS did not switch to battery and shut off as it was doing before when USB cable is plugged in and computer powered on.

Waiting for a while before plugging in the AC power seems like it may resolve the issue I was seeing. I need to run some more iterations of this test to verify.

This is disturbing to some degree because in the case of a real power event, I have no control over how long the power is off and when it comes back on.


Relevant portion of 'apcupsd.conf':

# ======== Configuration parameters used during power failures ==========
#

# The ONBATTERYDELAY is the time in seconds from when a power failure
# is detected until we react to it with an onbattery event.
#
# This means that, apccontrol will be called with the powerout argument
# immediately when a power failure is detected. However, the
# onbattery argument is passed to apccontrol only after the
# ONBATTERYDELAY time. If you don't want to be annoyed by short
# powerfailures, make sure that apccontrol powerout does nothing
# i.e. comment out the wall.
ONBATTERYDELAY 6

#
# Note: BATTERYLEVEL, MINUTES, and TIMEOUT work in conjunction, so
# the first that occurs will cause the initation of a shutdown.
#

# If during a power failure, the remaining battery percentage
# (as reported by the UPS) is below or equal to BATTERYLEVEL,
# apcupsd will initiate a system shutdown.
BATTERYLEVEL 20

# If during a power failure, the remaining runtime in minutes
# (as calculated internally by the UPS) is below or equal to MINUTES,
# apcupsd, will initiate a system shutdown.
MINUTES 5

# If during a power failure, the UPS has run on batteries for TIMEOUT
# many seconds or longer, apcupsd will initiate a system shutdown.
# A value of 0 disables this timer.
#
# Note, if you have a Smart UPS, you will most likely want to disable
# this timer by setting it to zero. That way, you UPS will continue
# on batteries until either the % charge remaing drops to or below BATTERYLEVEL,
# or the remaining battery runtime drops to or below MINUTES. Of course,
# if you are testing, setting this to 60 causes a quick system shutdown
# if you pull the power plug.
# If you have an older dumb UPS, you will want to set this to less than
# the time you know you can run on batteries.
TIMEOUT 0

# Time in seconds between annoying users to signoff prior to
# system shutdown. 0 disables.
ANNOY 300

# Initial delay after power failure before warning users to get
# off the system.
ANNOYDELAY 60

# The condition which determines when users are prevented from
# logging in during a power failure.
# NOLOGON [ disable | timeout | percent | minutes | always ]
NOLOGON disable

# If KILLDELAY is non-zero, apcupsd will continue running after a
# shutdown has been requested, and after the specified time in
# seconds attempt to kill the power. This is for use on systems
# where apcupsd cannot regain control after a shutdown.
# KILLDELAY 0 disables
KILLDELAY 0

[Anonymous user]

I came across this thread last night when I was trying to set up my new BR1000G Back-Ups Pro RS model UPS. I was having exactly the same issues as the original poster, and it seems that the thread has gone largely unanswered by both community contributors and APC / Schneider employees.

During my testing, I set up apcupsd on a Slackware Linux distribution, and had it set to kill power to the UPS as the last thing it did during the shutdown process. I had the UPS plugged into a switchable surge protector, and initially a simple 60w lamp connected to the UPS rather than the PC.

In order to test the function of the UPS, and the installation of the apcupsd, I switched off the surge protector, and waited for the PC to shutdown, followed by the UPS powering off about 60 seconds later. As soon as the UPS cut the power to it's battery protected outputs, I switched the surge protector back on, and the UPS responded by re-supplying power to the battery protected outputs, and coming off battery. As soon as I turned on the PC however, the UPS switched to battery mode, and rebooted, cutting power 60 seconds later. This behaviour was 100% repeatable, and somewhat disconcerting.

I should also point at that the UPS events log on the screen, and in apcupsd, showed the number of transfers as increased each time I switched the power on and off with this first testing methodology.

I did some further research, and discovered that the UPS is not fully 'shut down' when the power is cut from the battery protected outputs. The lights on the UPS continue to be lit for another 30 seconds. If I wait for those lights to go out, restoring power does not result in the UPS cutting power and rebooting.

My understanding therefore, is that if the UPS is issued a killpower command, it MUST go through a reboot before it operates properly again. If power is restored at any time after the UPS receives it's kill power signal, the UPS will go through this odd process of switching to battery for 60 seconds and then powering off and then on again. This process starts as soon as a signal is detected on the USB line.

When you think about the different timings that the UPS has to handle, there does present a situation that results in an unclean shut-down:

• 1. Power restored before apcupsd triggers a shutdown <- Works fine; UPS and PC do not shut down
• 2. Power restored 90 seconds or longer after apcupsd has sent the kill power command <- Works fine; UPS will restore power, starting the PC as normal
• 3. Power restored 60 ~ 90 seconds after apcupsd has sent the kill power command <- Un-clean shutdown; UPS will restore power immediately, restarting the PC. UPS will then switch to battery, cut power after 60 seconds, and then power up again

Two additional cases exist, and I will have to test these this evening:

• 4. Power restored immediately after apcupsd has started shutting down the system (kill power command ends up being sent with power restored) <- Not yet tested, would like the UPS to continue rebooting and restart the PC
• 5. Power restored 0 ~ 60 seconds after apcupsd has sent the kill power command <- Not yet tested, would like the UPS to continue rebooting and restart the PC

As far as I can tell, this is a bug in the UPS firmware that has gone un-discovered for some time. The UPS should always go completely through it's shut down and restart cycle whenever it receives a kill power signal; nothing should prevent this from happening, and it should certainly not go through the on-battery, cut power process at all. I cannot see a situation where this behaviour would be expected or beneficial.

[Anonymous user]

So I thought I'd add that I've tested the last two additional cases, with results as follows:

• 4. Power restored immediately after apcupsd has started shutting down the system (kill power command ends up being sent with power restored) <- Un-clean shutdown; UPS powers off then on, restarting the PC, but then powers off and on again some time later during the PC boot process; event counter on the UPS was not reset
• 5. Power restored 0 ~ 60 seconds after apcupsd has sent the kill power command <- Un-clean shutdown; UPS powers off then on, restarting the PC, but then powers off and on again some time later during the PC boot process; event counter on the UPS was not reset

[BillP]

Neil,

The Back-UPS is working as designed. When it receives the power down signal from APCUPSD or for that matter PowerChute it waits 2 minutes and then cuts AC. If in that 2 minutes power has been restored the Back-UPS will reboot. The reason for this is most BIOs are configured to restart the OS when it sees AC has been restored. So the Back-UPS cuts AC to initiate the automated OS start up. If yuor OS is restarting before AC has been cut my guess would be the BIOs is configured incorrectly.

[Anonymous user]

Bill P., Thanks very much for your response. I've updated my posts to include case numbers for clarity. I think the Back-UPS is working sort of as designed, but has a flaw in the firmware that will always cause an un-clean shutdown in certain cases. I'll try to summarise and be more clear and concise.

In cases 1 and 2, the UPS performs as designed, it either doesn't shutdown because the outage was either short (case 1), or it shutsdown fully because the outage was long (case 2).

The behaviour I see when the UPS receives the kill power signal during a longer outage is as follows:

• Wait ~60 seconds
• Cut power to protected outlets (UPS lights still on)
• Wait ~30 seconds
• Switch off UPS (lights go out)

Once power is restored, the UPS turns on correctly and reboots connected equipment (correct completion case 2)

If power is restored to the UPS during the second (30 second) wait period however (case 3), the UPS immediately provides power to the protected outlets, restarting any connected devices. This would be great if it were not for the fact that this appears to interrupt the UPS shutdown cycle because as soon as a signal is sensed on the USB cable, the UPS goes through the following process:

• Switch to battery power
• Wait ~120 seconds
• Cut power to protected outlets
• Wait ~5 seconds
• Restore power to protected outlets

Obviously because this process starts as soon as a signal is detected on the USB cable (On connected system boot up), the result is that an un-clean shutdown takes place ~120 seconds into the boot process, which may already be complete.

I'm completely at a loss by the way, for why the UPS switches to battery for 120 seconds during this process, mains power is always present during this strange behaviour.

[Anonymous user]

Cases 4 & 5 show even more strange behaviour...

These two cases can be summarised as one however, by looking at the situation from the point of view of the UPS:

     Power is lost -> Power is restored -> 'Kill Power' Signal is received.

Obviously this situation can happen when power is restored shortly after the connected system has started its shutdown process. Correct UPS behaviour would be to power cycle the protected outputs, in order to reboot any connected devices. What I end up seeing in this situation however, 100% consistently, is as follows:

• 'kill power' signal received
• Wait ~60 seconds
• Cut power to protected outlets
• Wait ~5 seconds
• Restore power to protected outlets
• Wait ~120 seconds
• Switch to battery power (even though mains power is present)
• Wait ~120 seconds
• Cut power to protected outlets
• Wait ~5 seconds
• Restore power to protected outlets

This behaviour, as in Case 3, always results in an un-clean shutdown, though in this case it is more like ~240 seconds after booting.

[BillP]

Neil,

I tried to recreate the issue today with a BR1500G and could not. When APCUPSD sent the kill command to the UPS it would wait 60 seconds and then kill power to all outlets. If I restored AC before the 60 seconds was up the UPS would stay on battery and kill power to all outlet after the 60 seconds. At not time did I see the master control outlet power cycle.

I understand from your post that your unit is a BR1500G. What firmware is on that unit? I will attempt to find a BR1500G with the same firmware to test.

[Anonymous user]

Bill P.,

My unit is a BR1000G, rather than a BR1500G. Having said that, my understanding is that they are mostly the same; here is a copy of apcaccess that I just took showing the firmware and other details:

APC      : 001,036,0902

DATE     : 2014-02-06 12:27:06 -0800

HOSTNAME : unRAID

VERSION  : 3.14.10 (13 September 2011) slackware

UPSNAME  : unRAID

CABLE    : USB Cable

DRIVER   : USB UPS Driver

UPSMODE  : Stand Alone

STARTTIME: 2014-02-05 17:08:25 -0800

MODEL    : Back-UPS RS1000G

STATUS   : ONLINE

LINEV    : 124.0 Volts

LOADPCT  :  18.0 Percent Load Capacity

BCHARGE  : 100.0 Percent

TIMELEFT :  44.0 Minutes

MBATTCHG : 20 Percent

MINTIMEL : 20 Minutes

MAXTIME  : 0 Seconds

SENSE    : Medium

LOTRANS  : 088.0 Volts

HITRANS  : 147.0 Volts

ALARMDEL : No alarm

BATTV    : 27.3 Volts

LASTXFER : No transfers since turnon

NUMXFERS : 0

TONBATT  : 0 seconds

CUMONBATT: 0 seconds

XOFFBATT : N/A

SELFTEST : NO

STATFLAG : 0x07000008 Status Flag

SERIALNO : 3B1336X12806

BATTDATE : 2013-09-05

NOMINV   : 120 Volts

NOMBATTV :  24.0 Volts

NOMPOWER : 600 Watts

FIRMWARE : 868.L3 -P.D USB FW:

END APC  : 2014-02-06 12:27:20 -0800

It seems that you've tested Case 4 - Power restored after the 'kill power' signal has been sent, but before the UPS has cut power

There is also an issue with:

Case 3 - Power is restored between 0 and 30 seconds after the UPS has killed power to all outlets, but hasn't full shut down

Case 5 - UPS receives a 'kill power' signal after power shortly after power has been restored

[Anonymous user]

It is also important to make sure that when you're doing testing, the system that you're using really is connected to the battery protected outputs and the USB, otherwise the situation will be different because USB connectivity will be lost / gained at different points in the process to what would occur in a real world situation.

[Anonymous user]

I've been looking for a workaround. Definitively, if the mains power comes back after apcupsd has shutdown the computer and the ups is not totally off (buttons still illuminated) then the ups will go on battery when the usb cable is detected by the computer. If this happens before the OS has booted then you have no control -> endless loop. To avoid this plug the usb in a usb hub (instead of plugging it directly to the computer). I use my monitor, which has an embedded usb hub. Then the ups will not go on battery until the usb hub is detected by the kernel, and since by that time you already have apcupsd running, you can detect the wonky state by adding these lines at the end of the file: /etc/apcupsd/onbattery (before the command "exit 0"):

# try to detect wonky state
apcaccess >/etc/apcupsd/status.txt
CNT=`cat /etc/apcupsd/status.txt | grep "LASTXFER" | grep -c "Forced"`
UPTM=`cat /proc/uptime | cut -d' ' -f1 | cut -d'.' -f1`
echo " " >> /etc/apcupsd/status.txt
echo "UPTIME = $UPTM s, CNT = $CNT" >> /etc/apcupsd/status.txt
if [ $UPTM -le 60 -a $CNT -eq 1 |http://www.apc-forums.com/]; then
echo "Wonky state detected !!" >> /etc/apcupsd/status.txt
shutdown -h now
fi

This code detects the wonky state if we are on battery after rebooting (uptime less than 1 minute) and the reason for LASTXFER (which we get through the program apcaccess) was "Forced by software". In this case the computer is immediately shut down in a proper way because the ups is about to cut the power ungracefully in less than 1 minute !! Seconds after cutting power to the load, the ups itself detects that indeed there is power available in the wall outlet and then it powers the load again and the computer boots normally. So it seems that when apcupsd asks the ups to killpower it is left in a estrange state. Since my procedure shuts down the computer immediately, it does not allow apcupsd to killpower when the ups goes on battery "Forced by software", and the loop is finished. If you allow apcupsd to issue the killpower command again the loop will continue forever.

I know this is just a dirty hack, but for the moment it works.

By the way, this is the full output of apcaccess when in the wonky state:

APC : 001,038,0953
DATE : Fri Mar 04 12:53:54 CET 2011
HOSTNAME : *********
VERSION : 3.14.6 (16 May 2009) debian
UPSNAME : APCPro900
CABLE : USB Cable
MODEL : Back-UPS BR 900GI
UPSMODE : Stand Alone
STARTTIME: Fri Mar 04 12:53:48 CET 2011
STATUS : ONBATT
LINEV : 226.0 Volts
LOADPCT : 23.0 Percent Load Capacity
BCHARGE : 088.0 Percent
TIMELEFT : 40.0 Minutes
MBATTCHG : 15 Percent
MINTIMEL : 5 Minutes
MAXTIME : 30 Seconds
SENSE : Low
LOTRANS : 156.0 Volts
HITRANS : 300.0 Volts
ALARMDEL : Always
BATTV : 24.6 Volts
LASTXFER : Forced by software
NUMXFERS : 1
XONBATT : Fri Mar 04 12:53:50 CET 2011
TONBATT : 6 seconds
CUMONBATT: 6 seconds
XOFFBATT : N/A
SELFTEST : NO
STATFLAG : 0x07060010 Status Flag
MANDATE : 2010-07-12
SERIALNO : 3B1029X01355
BATTDATE : 2001-09-25
NOMINV : 230 Volts
NOMBATTV : 24.0 Volts
NOMPOWER : 540 Watts
FIRMWARE : 879.L1d.I USB FW:L1
APCMODEL : Back-UPS BR 900GI
END APC : Fri Mar 04 12:53:56 CET 2011

Message was edited by: root21

[BillP]

do we have event logs from apcupsd? it is very confusing to me that the UPS is going to battery when you plug the cable in. does the cable have a part # on it? i assume so but just another thought.

what are you trying to simulate with these tests by plugging and unplugging the cable in, if you dont mind me asking?

i found out that you started a chat and email ticket on this as well and after discussing it, we still arent sure what the issue is.

maybe we are still missing something 😞

[Anonymous user]

I don't have access to the logs right now. I can see about that this evening. However, note that in step 1 in the above sequence 'apcupsd' is not running because the USB cable was not plugged in. If 'apcupsd' does not see a valid UPS device connected when it tries to start on boot, 'apcupsd' will stop running, and therefore, not log. There should be logs after the OS boots (step 7 above) and the USB cable is plugged in.


The problem is that the UPS is getting into a mode where I cannot have the USB cable plugged in when the PC is turned on, otherwise the UPS switches to battery power and cuts power. This happens when AC power is connected to the UPS and doesn't make sense. It happens whether the the cable is plugged in, then the PC power is turned on, or if the PC is booted, then the USB cable is plugged in.

I don't have the part number for the cable. It is the one that came in the box with the unit. I can look and see if there is a part number on it this evening.

What I'm trying to simulate is a power loss event and the graceful OS shutdown after loss of AC power and surpassing the designated battery level, and UPS turn on and OS boot after AC restore. I want the OS to shut down gracefully (rather than the UPS just chopping power) so I don't get file system corruption. On AC power restore I want the system to come back up correctly. The coming back up part has been a problem because the UPS has been getting into the weird mode (UPS switching to battery and shutting down when USB cable connected).

[Anonymous user]

The USB cable had some print on the cable jacket. The only thing that looked like a part number was "E52534-D". The cable came with the UPS and has an RJ-45 type connector that plugs into the UPS on one end and a USB type-A connector that connects to the PC on the other end.

Below is the log file excerpt from when I was testing last night. Note that the first line in the log was after the reboot when I lugged in the USB cable. As noted before, 'apcupsd' was not running before I plugged in the USB cable because it shuts down if there is no UPS to talk to, and therefore, it doesn't log.


Log file excerpt:
Mon Dec 20 21:48:56 MST 2010 apcupsd 3.12.4 (19 August 2006) debian startup succeeded
Mon Dec 20 21:52:37 MST 2010 apcupsd exiting, signal 15
Mon Dec 20 21:52:37 MST 2010 apcupsd shutdown succeeded
Mon Dec 20 21:52:48 MST 2010 apcupsd 3.12.4 (19 August 2006) debian startup succeeded
Mon Dec 20 21:54:05 MST 2010 Communications with UPS restored.
Mon Dec 20 21:54:06 MST 2010 Power failure.
Mon Dec 20 21:54:12 MST 2010 Running on UPS batteries.
Mon Dec 20 21:54:41 MST 2010 Battery charge below low limit.
Mon Dec 20 21:54:41 MST 2010 Initiating system shutdown!
Mon Dec 20 21:54:41 MST 2010 User logins prohibited
Mon Dec 20 21:54:59 MST 2010 apcupsd exiting, signal 15
Mon Dec 20 21:54:59 MST 2010 apcupsd shutdown succeeded
Mon Dec 20 22:01:34 MST 2010 apcupsd 3.12.4 (19 August 2006) debian startup succeeded
Mon Dec 20 22:03:43 MST 2010 apcupsd exiting, signal 15
Mon Dec 20 22:03:43 MST 2010 apcupsd shutdown succeeded
Mon Dec 20 22:03:54 MST 2010 apcupsd 3.12.4 (19 August 2006) debian startup succeeded
Mon Dec 20 22:04:41 MST 2010 apcupsd exiting, signal 15
Mon Dec 20 22:04:41 MST 2010 apcupsd shutdown succeeded
Mon Dec 20 22:04:52 MST 2010 apcupsd 3.12.4 (19 August 2006) debian startup succeeded
Tue Dec

[BillP]

What I'm trying to simulate is a power loss event and the graceful OS shutdown after loss of AC power and surpassing the designated battery level, and UPS turn on and OS boot after AC restore. I want the OS to shut down gracefully (rather than the UPS just chopping power) so I don't get file system corruption. On AC power restore I want the system to come back up correctly. The coming back up part has been a problem because the UPS has been getting into the weird mode (UPS switching to battery and shutting down when USB cable connected).

after this happens, the UPS does need to reboot in order to reset its timers or whatever it does. this goes back to the timeline that I gave you.

if the graceful shutdown process is started from the software (apcupsd), the OS should shutdown first and then there is a timer on the UPS that turns on that cannot be stopped. if the AC power comes back to the UPS at any point during this time, you will still need to reboot the UPS in order to get everything to turn back on and start working properly. AC power coming back during the shutdown process of the OS or UPS does not stop this entire timeline from happening unfortunately. i think that whatever is happening here is relating to this fact. this applies to any UPS. i cant explain why the UPS goes to battery when connecting the cable but i can verify the first part is correct.

let me know if i am still going along the wrong path here and if so, i apologize.

[Anonymous user]

>

after this happens, the UPS does need to reboot in order to reset its timers or whatever it does. this goes back to the timeline that I gave you.

if the graceful shutdown process is started from the software (apcupsd), the OS should shutdown first and then there is a timer on the UPS that turns on that cannot be stopped. if the AC power comes back to the UPS at any point during this time, you will still need to reboot the UPS in order to get everything to turn back on and start working properly. AC power coming back during the shutdown process of the OS or UPS does not stop this entire timeline from happening unfortunately. i think that whatever is happening here is relating to this fact. this applies to any UPS. i cant explain why the UPS goes to battery when connecting the cable but i can verify the first part is correct.

let me know if i am still going along the wrong path here and if so, i apologize.

All of this sounds fine and reasonable. If the counter in the UPS kicks off, it must continue to its conclusion... a restart of the UPS. I don't think there's anything contradictory between that, the test scenario, or the operation of the 'apcupsd' software. When 'apcupsd' sees that the battery level drops below the specified threshold, it initiates an OS shutdown, presumably kicking off the counter in the UPS. Ofter the OS shuts down, the UPS shuts down. I've seen that.


I need to get to the bottom of the problem when the UPS gets into the mode where the USB cable being plugged in causes the UPS to shut down. Why is this happening?

From my observation, when the UPS gets into this mode, it seems that when the UPS detects a voltage on the USB cable it immediately switches to battery, then shuts off in 60 seconds(probably that timer you talked about). I've seen this happen in the following two scenarios:

1) USB cable plugged in, UPS running on AC, PC off. Turn on PC, UPS switches to battery, then shuts off after 60 seconds.
2) USB unplugged, UPS running on AC, PC booted and running. Plug in USB cable, UPS immediately switches to battery then shuts off in 60 seconds.

In case 1 it's impossible for the UPS to be receiving any commands from software, because the OS hasn't even booted yet. It happens immediately when the power switch to the PC is turned on.

In case 2 the OS is booted, but 'apcupsd' is not running because the UPS cable was not connected when 'apcupsd' started, so 'apcupsd' terminates itself.

I can't think of any scenario where this behavior is valid. It seems like a bug to me.

[BillP]

eureka! i think i finally fully understand. i agree, that does not seem right. i will have to investigate with the Back UPS folks since that it is not part of my team.

if its okay with you, i will send them this thread and then see where i get.

[Anonymous user]

i picKed a winna wrote:
if its okay with you, i will send them this thread and then see where i get.

By all means, please do. I'm happy to provide any more debug information they may need.

[BillP]

one thing that was asked was if you were using the green functionality of this unit? with the master/controlled outlets? we'd want to make sure thats disabled and rule any strange things out with that. just an idea that was thrown out there which won't necessarily fix the issue with this particular computer, is there any other system there that you can try with the APC Software (Windows)? i know that you said the apcupsd does not start unless something is connected but someone also suggested that to see if we see the same symptoms on a different machine.

[BillP]

Neil,

I have tested 3 different Back-UPS with APCUPSD running on Windows, Mac OSX 10.6 and Fedora. In none of the tests was I able to cause the UPS to restore power before the Killpower cycle completed. I did find some strange behavior on Fedora when I messed up the halt file. The OS powered down and then back up before the UPS powered down. I also noticed that with Windows running APCUPSD the UPS would Killpower 60 seconds after receiving the command yet with PowerChute the UPS would wait 120 seconds.

You may want to post to the APCUPSD mail list to see if anyone in that group has seen this issue and has a solution.

[Anonymous user]

The leaf icon is not present on the front panel, which I believe means it is not using the green function.

Also, nothing else is plugged into the UPS, just the server computer.

I'll see if I can hook another windows PC up to it and try the APC windows software. However, if the UPS is in the wonky state, as I stated before, just turning the PC on with the USB cable plugged in causes it to switch to battery and cut power, so I fail to see how booting windows is going to solve that when it won't even get to the point of booting windows. I'll see if I can get it into this state while plugged into the windows PC.

When the UPS does not get into the 'wonky' state and I am able to have the USB cable plugged in, it does operate as expected.

[BillP]

i agree. i guess i was assuming that connecting the USB on both ends was causing it to go to battery. it only happens when you connect the RJ-45 side and the USB-A end is not connected to the computer? maybe i missed that part or maybe i was thinking that when i asked if you were using the APC cable or had a different one for some reason which had a strange pinout on it. there is so much to this issue i keep forgetting little [important] pieces 😞

[Anonymous user]

I'm using the stock cable that came with the UPS... RJ45 one end, usb type-A on the other end.

When I refer to the USB cable being 'connected' or 'plugged in' I mean it is connected on both ends (computer and UPS). When I say 'disconnected' or 'unplugged' it doesn't matter which end is unplugged, the behavior is the same.

When the UPS is in the bad state, if there is continuity between the UPS and the PC through the USB cable and the PC power is on, it's bad news. Doesn't matter if the PC power is on first, then the USB connected, or if the USB is connected, then the power turned on.

[BillP]

ok, i will look into this more tomorrow and monday. i will have to track one of these units down i guess and check it out but i wont be able to do that until monday when i am back in the office after the Christmas holiday. hope that is alright.

happy holidays!

[Anonymous user]

I'll try to do some more testing and gather more info also.

Thank you.

[BillP]

something came to mind but i am not so sure it is the issue because everything else seems to work fine but i assume there is no physical damage to the cable that you can see like a bent pin or even on the UPS data port side? probably not but just throwing it out there!

[Anonymous user]

The cable and UPS looked pristine. No obvious damage. I can double check the connector pins this weekend

[Anonymous user]

The problem can be reproduced easily if we stop the apcupsd daemon and run apctest. Then issue command number 1: kill ups power (without unplugging the socket). The ups will go on battery (we gracefully stop computer now) and after 1 minute it will switch off the load and then switch it on again. The computer will boot and when the usb cable is detected the ups will go on battery and cut power to the load in 1 minute.

It seems that asking the ups to kill power sets up a flag that makes it switch to battery again and again. The flag is only cleared when the ups is allowed to be completely off or when we start running the apcupsd daemon.

[Anonymous user]

Just found this thread ... and have the same issue with BX1500G, also same with BX1300G. I'm using apcupsd in CentOS 5.5 x86_64 on Dell PowerEdge T310. I have apcupsd running in CentOS 4.5 and 5.5 i86 on older Dell's using APC BackUPS XS 1500's that work perfectly.

I have also determined this "funky" state does not seem to clear until the UPS is completely shut-off manually or until apcupsd comes back on-line. I'll try your hack until APC comes up with a more elegant solution.

Thanks,

Tom

[Anonymous user]

Hi. Did you ever find out the reason for this problem? I have bought a Back-UPS BR 900GI and I'm suffering exactly the same problem that dlotton describes. I totally agree with all the details of the given description. I'm running apcupsd on a desktop PC with Ubuntu Lucid.

I've been trying to isolate the problem and I have also found that the UPS enters that 'wonky' status where plugging in the USB cable makes it switch to battery and then -after a short period- switch off the load and then restart. If the USB cable is not disconnected, the same situation repeats over and over, in an infinite loop, in such a way that the computer never has enough time to boot and start the apcupsd daemon.

I've found that the loop stops if the UPS is disconnected from mains power, then allowed to run on battery until the on-battery timeout expires -I've set it to 60 seconds- and then allowed to totally stop to the point that the buttons backlight is off.

In my case the 'wonky' status is triggered when there is a power failure -which I simulate by unplugging the ups from the wall- and then, after the shutdown process of the PC is complete and the UPS is not completely off -the display is already dark but the buttons are still illuminated- the mains power is restored. Since you never know when power will come back there is a chance that the loop situation happens during normal use.

Any help will be appreciated. I've tried connecting it to a Windows computer with PowerChute and it worked correctly, although I couldn't test it for a long time.

[Anonymous user]

root21,

Your problem does sound like the one I described and I have not found a resolution to the problem.

It is difficult for me to find the right time do do such troubleshooting since it takes my production server out of service.

Please post back here if you learn anything. I'll do the same.

[Anonymous user]

I've been looking at the code inside the latest version of the file usb.c (the part of the apcupsd source code that implements the usb driver) and I realize that all is based on reverse engineering. So it could be that, for recent ups models, the apcupsd code does not match the ups firmware any more. I think that the powerchute Linux version is not available for Debian or Ubuntu, and anyway I would prefer an integrated Linux solution like apcupsd rather than a windows like solution.
With more experimentation I've found that you don't need the usb hub (as I said in one of my previous posts). In my case, and with the proposed hack, the computer needs 39 seconds of uptime to detect the wonky state and shutdown properly. Since, while on battery, the ups holds the power for one minute, we can connect the usb cable directly to the computer.
Note that the underlined part of the code in my previous post must be between brackets: [ ]. The brackets have dissapeared for unkown reason.

[Anonymous user]

Also, you should disable the disk drive check during reboot, because this takes more than one minute, and if it happens that the drives are checked while in the wonky state, then power will be cut during disk check and a reboot will happen. If the drive checking starts again then we have a loop and disk can become corrupt.

[Anonymous user]

I recently experienced this exact problem with connecting the RJ45/USB cable and subsequently having my PC and UPS shut down.
I have found the root cause, and I have verified the solution for my system.

Background info: I recently decided to upgrade several components within my PC and to upgrade the OS to Win7.
My UPS model is a BACK-UPS NS 1250. It has been working fine for several years, though I've noticed an
important clue over this time: when my NEC LCD monitor was on, the UPS reported a load of ~550 Watts (not even reasonable).
With the monitor off, the load was reported to be 160 Watts (very believable).

I was nearly done with my upgrade, and reconnecting the UPS USB cable after installing the PowerChute software
was next on the task list. I had rearranged some of my USB cables, and as I connected the one for the UPS, I heard
the cooling fan in the UPS crank up and I noticed the display showing a load of 700+ Watts. ... then everything shut down.

There was clear cause and effect. After disconnecting the USB end and monitoring the UPS's
load meter, I could make the meter go from 195 Watts to 500+ Watts by just touching the shield of the USB cable to
the bare metal of the PC chassis. My voltmeter showed a DC offset between the the two points of 340mVolts.

To keep the story short, my monitor was the problem. It has an external power brick with a five foot length of wire
between the brick and the monitor power plug. The monitor pulls 5 amps from this 12VDC side of the brick.
The monitor in turn is connected to the PC with a shielded DVI cable. The 340mV offset is produced across the
five foot wire with 5 amps going through it. This low impedance voltage source raises the potential of the PC chassis,
which is in turn connected to the UPS via the UPS's USB cable.

I reduced the length of the five foot wire to one foot. The offset voltage went from 340mV to 120mV. With the USB
cable shield touching the PC chassis, the reported load on the UPS meter went from ~550 Watts to ~300 Watts.
Knowing that the load was closer to 200W, this fix was insufficient. I then installed a 3 prong to 2 prong, 120VAC
adapter in front of the monitor's power brick (essentially floating the monitor, but it is still grounded through the DVI
cable shield to the PC chassis). (These 2 prong things usually have a tab which is meant to be attached to the center
screw of a normal duplex wall outlet -- don't do this or you'll perpetuate the problem. Put insulating tape over the tab.)
My UPS's load meter now reads ~200W. I'm content.

For the APC engineers, this problem should now be easy to reproduce using an adjustable lab power supply to force
the chassis voltage of any PC to a few hundred milli-volts above ground. Observe the load meter. See what happens when
the UPS thinks it's overloaded.

For other afflicted users, ask your neighborhood EE to make some DC measurements between the RJ45/USB shield
and the PC chassis. Then have him or her evaluate your system, looking for ground loops or power bricks like mine.

SeanR

[Anonymous user]

On 4/23/2011 3:28 AM, Sean said:

I then installed a 3 prong to 2 prong, 120VAC
adapter in front of the monitor's power brick (essentially floating the monitor, but it is still grounded through the DVI
cable shield to the PC chassis). (These 2 prong things usually have a tab which is meant to be attached to the center
screw of a normal duplex wall outlet -- don't do this or you'll perpetuate the problem. Put insulating tape over the tab.)
My UPS's load meter now reads ~200W. I'm content.

I'm going to resurrect this thread. I have a BackUPS XS-1300. Here's the output from apcaccess:

APC : 001,036,0881
DATE : 2002-01-01 00:18:40 -0500 
HOSTNAME : lanner
VERSION : 3.14.13 (02 February 2015) unknown
UPSNAME : lannerBat
CABLE : USB Cable
DRIVER : USB UPS Driver
UPSMODE : Stand Alone
STARTTIME: 2002-01-01 00:18:38 -0500 
MODEL : Back-UPS XS 1300 LCD 
STATUS : ONLINE LOWBATT 
LINEV : 122.0 Volts
LOADPCT : 16.0 Percent
BCHARGE : 100.0 Percent
TIMELEFT : 2.1 Minutes
MBATTCHG : 0 Percent
MINTIMEL : 0 Minutes
MAXTIME : 0 Seconds
SENSE : Medium
LOTRANS : 88.0 Volts
HITRANS : 139.0 Volts
ALARMDEL : No alarm
BATTV : 26.5 Volts
LASTXFER : No transfers since turnon
NUMXFERS : 0
TONBATT : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
SELFTEST : NO
STATFLAG : 0x05000048
SERIALNO : JB0639006217 
BATTDATE : 2006-09-19
NOMINV : 120 Volts
NOMBATTV : 24.0 Volts
NOMPOWER : 780 Watts
FIRMWARE : 836.H3 .D USB FW:H3
END APC : 2002-01-01 00:18:41 -0500 

It's been plugging away for a couple-three years or more (I forget when I bought it).

After a recent power failure, I noticed the UPS' fan would come on now and again without a switch to/from battery. I know there's a bad battery; I've been relying more on the UPS' filtering capacity than the battery.

While looking into that, I noticed the load wasa lot higher than I expect. I turned off my desktop and flipped the power switch to it and the monitor. That reduced the load to about 100W which was still outrageous since the only things powered at that point were the SB6121 cable modem and the Lanner 7530 firewall. I unplugged the USB cable and the load dropped to near the expected 30W. I plugged the cable back in and powered down the Lanner and the load dropped to 5-10W. That was still too high since the C.M. doesn't draw *that* much. I unplugged the C.M.; no change. I unplugged the Lanner's power brick; the load dropped to zero. I plugged it in; the load increased to 5-10W. I unplugged the USB cable; the load dropped to 1W or so. I floated the ground on the Lanner's power brick; connecting the USB cable (at both ends) no longer causes a 'phantom' 100W load.

My C.M., firewall, switches, desktop, LCD monitor, cell phone and other things are powered from this UPS. The 'other things' are switched off most of the time; typical load is about 140W but does increase to 260W when I'm compiling the firewall. The only two 'external connections' are the cable to the C.M. and a CAT5e strung to the other end of the house to provide networking there.

Is it possible that the Lanner's power brick is bad? (I have a different 12VDC brick I can try.) I can also disconnect the co-ax cable and the long CAT53 in case the problem comes from there. Where I'm leading with this: what is the likelihood that a ground loop or a ground fault (in the A/C wiring) is the cause of this 'phantom load' oddity (by causing current to flow across unusual paths until it finds a nice, comfy ground to sink into)?

[Anonymous user · Accepted solution]

On 3/8/2015 5:39 PM, Nea said:

Is it possible that the Lanner's power brick is bad? (I have a different 12VDC brick I can try.)

I swapped in another power brick. I swapped the original back in but floated its ground. The phantom load vanished in both cases.