April 3, 201412 yr The fix is as follows: if [ -d /boot/config/plugins/apcupsd/scripts ] && [ "$(ls -A /boot/config/plugins/apcupsd/scripts)" ]; then for file in /boot/config/plugins/apcupsd/scripts/*; do rm /etc/apcupsd/${file##*/} ln -s $file /etc/apcupsd/${file##*/} done fi The additional 'if' statement checks for the presence of a script folder, with files inside, before running the for loop. If the folder is missing or empty, no action is taken. An updated Version (4_nro) is attached. Thanks again for this. Installed with no problems. Decided to use your custom scripts too along with ssmtp. Seems like a great combo.
April 3, 201412 yr I've added some more changes to the plugin, increasing the version number to 3_nro.plg (attached). I had often read that apcupsd could send emails letting the administrator know about certain events, but my installation at least had never done this. I have ssmtp installed (by Dynamix email notify), and wanted to run my mail through this because it works very well. Previous to this version of the plugin, /etc/apcupsd/apccontrol would be modified so that the variable $WALL, which by default is wall, would be changed to: mail -s 'unRAID_SERVER_UPS_Alert' root\ This command fails on my system, because mail is not installed. In any case, I'm not sure that I would want all of the 'wall' commands being sent to me by email; this was certainly not the intended configuration of apcupsd, which looks for additional script files to execute at each calling of apccontrol. Some of these script files are installed with the apcupsd package as examples, but the intention is that the user would customise these to their requirements as needed. Since unRAID runs in RAM, the script folder needs to be located on the flash drive to be preserved between reboots. The $APCUPSD_MAIL variable in the 3.14.10 package of apcupsd was defined in each custom script. In the 3.14.12 package now used, this variable is defined as an export variable in /etc/apcupsd/apccontrol. If you're trying to test your scripts using this variable, be sure to call them using apccontrol [event name] rather than directly. If you choose to have no user customised script files in the /boot/config/plugins/apcupsd/scripts folder, the default example scripts will be installed as normal. One important thing to note, is that the doshutdown script is first modified to the following by the plugin installation script: /sbin/powerdown exit 99 If you do create your own custom doshutdown script, it must contain these last two lines in order to correctly call the unRAID powerdown script. In addition to the updated plugin, I've attached some custom scripts that I'm using in my system. These are a slightly better reference than the default examples, and are written in a format compatible with ssmtp. To summarise, I have made three changes for this version: Removed the line which changes the $WALL variable in apccontrol Changed the $APCUPSD_MAIL variable to /usr/sbin/ssmtp in /etc/apcupsd/apccontrol Added the following code to look for user created scripts in the /boot/config/plugins/apcupsd/scripts folder. For each file present, the code removes the default script, and replaces it with a symlink to the user code for file in /boot/config/plugins/apcupsd/scripts/*; do rm /etc/apcupsd/${file##*/} ln -s $file /etc/apcupsd/${file##*/} done Quick question about mail/ssmtp. I had installed the ssmtp package when I initially installed apcupsd as a package and not a plugin. I have since installed Dynamix, Email Notifications (from Dynamix), and of course this as a plugin. Do I need the other ssmtp "package" installed or can I tell it not to install on boot? I don't want to have anything that isn't needed here!
April 3, 201412 yr Quick question about mail/ssmtp. I had installed the ssmtp package when I initially installed apcupsd as a package and not a plugin. I have since installed Dynamix, Email Notifications (from Dynamix), and of course this as a plugin. Do I need the other ssmtp "package" installed or can I tell it not to install on boot? I don't want to have anything that isn't needed here! The Dynamix email notifications plugin is the only one that I'm using. This obviously gives you a nice webUI to configure the settings, but there is no reason that you'd need both installed, no. If you have two installations of the same plugin, the last one to be installed should overwrite the first. If two identical packages are called by two different plugins, then the second package installation will just skip. Dynamix plugins have an odd method of renaming the installation packages, which results in packages stored with unique file names resulting in the installation never being skipped. Instead, Dynamix provides a unique way of by-passing the installation of a package, which is to edit the .plg file and change the package to 'no-install' near the top of the script. Here is an example from my system where I've disabled installation of the OpenSSL package in the Dynamix email notification plugin: <FILE Name="/tmp/plugin-packages"> <INLINE> # Mandatory packages 13.1 13.37 14.0 14.1 a openssl-solibs txz 0.9.8y-i486-1 0.9.8y-i486-1 1.0.1e-i486-1 1.0.1e-i486-1 do-install # openssl library n openssl txz 0.9.8y-i486-1 0.9.8y-i486-1 1.0.1e-i486-1 1.0.1e-i486-1 no-install # openssl library </INLINE> </FILE> To summarise; if you're not doing anything special with your additional ssmtp package, remove it and just use Dynamix. If you've customised your standalone ssmtp package in any way, and you'd like to keep the changes, try setting the package to 'no-install' in the Dynamix plugin.
April 3, 201412 yr Quick question about mail/ssmtp. I had installed the ssmtp package when I initially installed apcupsd as a package and not a plugin. I have since installed Dynamix, Email Notifications (from Dynamix), and of course this as a plugin. Do I need the other ssmtp "package" installed or can I tell it not to install on boot? I don't want to have anything that isn't needed here! The Dynamix email notifications plugin is the only one that I'm using. This obviously gives you a nice webUI to configure the settings, but there is no reason that you'd need both installed, no. If you have two installations of the same plugin, the last one to be installed should overwrite the first. If two identical packages are called by two different plugins, then the second package installation will just skip. Dynamix plugins have an odd method of renaming the installation packages, which results in packages stored with unique file names resulting in the installation never being skipped. Instead, Dynamix provides a unique way of by-passing the installation of a package, which is to edit the .plg file and change the package to 'no-install' near the top of the script. Here is an example from my system where I've disabled installation of the OpenSSL package in the Dynamix email notification plugin: <FILE Name="/tmp/plugin-packages"> <INLINE> # Mandatory packages 13.1 13.37 14.0 14.1 a openssl-solibs txz 0.9.8y-i486-1 0.9.8y-i486-1 1.0.1e-i486-1 1.0.1e-i486-1 do-install # openssl library n openssl txz 0.9.8y-i486-1 0.9.8y-i486-1 1.0.1e-i486-1 1.0.1e-i486-1 no-install # openssl library </INLINE> </FILE> To summarise; if you're not doing anything special with your additional ssmtp package, remove it and just use Dynamix. If you've customised your standalone ssmtp package in any way, and you'd like to keep the changes, try setting the package to 'no-install' in the Dynamix plugin. Perfect. Thanks so much. And no, I didn't do anything special with the other package so I'll remove it. Dynamix and it's plugins are quite nice!
April 6, 201412 yr ... An updated Version (4_nro) is attached. Hi Nezil, First up, a big thanks for putting in the time and effort into getting the UPS issues sorted with the APCUPSD team. And also helping out here with updates to the unRaid plugin. As I recently swapped my UPS to an APC BR900G, it sounds like I'm affected by the bug. I've updated the plugin to your latest version "Apcupsd-3.14.12-i486-4_nro.plg", but I'm having a minor issue with email notifications. I run Dynamix with the email notification plugin, so ssmtp is installed and configured through that. I use the same Gmail address to send both from and to, SSL enabled. It works fine, either via the inbuilt plugin test, or regular status emails. The issue with the APCUPSD plugin is that I don't receive any emails. This is the output I get in the syslog when running an actual test of the UPS: Apr 6 13:37:32 Tower apcupsd[3764]: Power failure. Apr 6 13:37:38 Tower apcupsd[3764]: Running on UPS batteries. Apr 6 13:37:39 Tower sSMTP[30063]: Creating SSL connection to host Apr 6 13:37:39 Tower sSMTP[30063]: SSL connection using RC4-SHA Apr 6 13:37:41 Tower sSMTP[30063]: RCPT TO:<Tower UPS Tower Power Failure !!!@> (553 5.1.2 or other punctuation after the recipient's email address. rk15sm64357801pab.37 - gsmtp) Apr 6 13:37:49 Tower apcupsd[3764]: Mains returned. No longer on UPS batteries. Apr 6 13:37:49 Tower apcupsd[3764]: Power is back. UPS running on mains. Apr 6 13:37:50 Tower sSMTP[30075]: Creating SSL connection to host Apr 6 13:37:50 Tower sSMTP[30075]: SSL connection using RC4-SHA Apr 6 13:37:52 Tower sSMTP[30075]: RCPT TO:<Tower UPS Tower Power has returned@> (553 5.1.2 or other punctuation after the recipient's email address. ha11sm27590855pbd.17 - gsmtp) And it does the same thing when manually sending an email using the plugin's scripts, e.g. "/etc/apcupsd/apccontrol onbattery" It appears to be failing when trying to run the following command to send the email, i.e. the command: $APCUPSD_MAIL -s "$MSG" $SYSADMIN I've tried to figure out what's going wrong, but I'm too experienced with this stuff. Any idea how to fix this?
April 7, 201412 yr ... An updated Version (4_nro) is attached. Hi Nezil, First up, a big thanks for putting in the time and effort into getting the UPS issues sorted with the APCUPSD team. And also helping out here with updates to the unRaid plugin. As I recently swapped my UPS to an APC BR900G, it sounds like I'm affected by the bug. I've updated the plugin to your latest version "Apcupsd-3.14.12-i486-4_nro.plg", but I'm having a minor issue with email notifications. I run Dynamix with the email notification plugin, so ssmtp is installed and configured through that. I use the same Gmail address to send both from and to, SSL enabled. It works fine, either via the inbuilt plugin test, or regular status emails. The issue with the APCUPSD plugin is that I don't receive any emails. This is the output I get in the syslog when running an actual test of the UPS: Apr 6 13:37:32 Tower apcupsd[3764]: Power failure. Apr 6 13:37:38 Tower apcupsd[3764]: Running on UPS batteries. Apr 6 13:37:39 Tower sSMTP[30063]: Creating SSL connection to host Apr 6 13:37:39 Tower sSMTP[30063]: SSL connection using RC4-SHA Apr 6 13:37:41 Tower sSMTP[30063]: RCPT TO:<Tower UPS Tower Power Failure !!!@> (553 5.1.2 or other punctuation after the recipient's email address. rk15sm64357801pab.37 - gsmtp) Apr 6 13:37:49 Tower apcupsd[3764]: Mains returned. No longer on UPS batteries. Apr 6 13:37:49 Tower apcupsd[3764]: Power is back. UPS running on mains. Apr 6 13:37:50 Tower sSMTP[30075]: Creating SSL connection to host Apr 6 13:37:50 Tower sSMTP[30075]: SSL connection using RC4-SHA Apr 6 13:37:52 Tower sSMTP[30075]: RCPT TO:<Tower UPS Tower Power has returned@> (553 5.1.2 or other punctuation after the recipient's email address. ha11sm27590855pbd.17 - gsmtp) And it does the same thing when manually sending an email using the plugin's scripts, e.g. "/etc/apcupsd/apccontrol onbattery" It appears to be failing when trying to run the following command to send the email, i.e. the command: $APCUPSD_MAIL -s "$MSG" $SYSADMIN I've tried to figure out what's going wrong, but I'm too experienced with this stuff. Any idea how to fix this? FYI - I'm seeing the same thing with this with the same error message as you. Weird that it's throwing a punctuation error. Hopefully Nezil can look into this soon.
April 7, 201412 yr ... An updated Version (4_nro) is attached. Hi Nezil, First up, a big thanks for putting in the time and effort into getting the UPS issues sorted with the APCUPSD team. And also helping out here with updates to the unRaid plugin. As I recently swapped my UPS to an APC BR900G, it sounds like I'm affected by the bug. I've updated the plugin to your latest version "Apcupsd-3.14.12-i486-4_nro.plg", but I'm having a minor issue with email notifications. I run Dynamix with the email notification plugin, so ssmtp is installed and configured through that. I use the same Gmail address to send both from and to, SSL enabled. It works fine, either via the inbuilt plugin test, or regular status emails. The issue with the APCUPSD plugin is that I don't receive any emails. This is the output I get in the syslog when running an actual test of the UPS: Apr 6 13:37:32 Tower apcupsd[3764]: Power failure. Apr 6 13:37:38 Tower apcupsd[3764]: Running on UPS batteries. Apr 6 13:37:39 Tower sSMTP[30063]: Creating SSL connection to host Apr 6 13:37:39 Tower sSMTP[30063]: SSL connection using RC4-SHA Apr 6 13:37:41 Tower sSMTP[30063]: RCPT TO:<Tower UPS Tower Power Failure !!!@> (553 5.1.2 or other punctuation after the recipient's email address. rk15sm64357801pab.37 - gsmtp) Apr 6 13:37:49 Tower apcupsd[3764]: Mains returned. No longer on UPS batteries. Apr 6 13:37:49 Tower apcupsd[3764]: Power is back. UPS running on mains. Apr 6 13:37:50 Tower sSMTP[30075]: Creating SSL connection to host Apr 6 13:37:50 Tower sSMTP[30075]: SSL connection using RC4-SHA Apr 6 13:37:52 Tower sSMTP[30075]: RCPT TO:<Tower UPS Tower Power has returned@> (553 5.1.2 or other punctuation after the recipient's email address. ha11sm27590855pbd.17 - gsmtp) And it does the same thing when manually sending an email using the plugin's scripts, e.g. "/etc/apcupsd/apccontrol onbattery" It appears to be failing when trying to run the following command to send the email, i.e. the command: $APCUPSD_MAIL -s "$MSG" $SYSADMIN I've tried to figure out what's going wrong, but I'm too experienced with this stuff. Any idea how to fix this? OK... After a quick test I managed to get the email working from the onbattery script. For some reason the -s "$MSG" portion of the command is giving it trouble. I removed it and tested it and the email went through. Obviously is this is the fix for this then we would need to recreate the onbattery and offbattery scripts and put them in the proper directory to be called instead of the stock ones. However I did notice another problem that I have no idea about. Testing both the onbattery script and the included commfailure script from Nezil, neither one of them actually spit out any content into the email. There was a subject line and nothing else. So I'm not sure what's going on there. Nezil?
April 8, 201412 yr ... An updated Version (4_nro) is attached. Hi Nezil, First up, a big thanks for putting in the time and effort into getting the UPS issues sorted with the APCUPSD team. And also helping out here with updates to the unRaid plugin. As I recently swapped my UPS to an APC BR900G, it sounds like I'm affected by the bug. I've updated the plugin to your latest version "Apcupsd-3.14.12-i486-4_nro.plg", but I'm having a minor issue with email notifications. I run Dynamix with the email notification plugin, so ssmtp is installed and configured through that. I use the same Gmail address to send both from and to, SSL enabled. It works fine, either via the inbuilt plugin test, or regular status emails. The issue with the APCUPSD plugin is that I don't receive any emails. This is the output I get in the syslog when running an actual test of the UPS: Apr 6 13:37:32 Tower apcupsd[3764]: Power failure. Apr 6 13:37:38 Tower apcupsd[3764]: Running on UPS batteries. Apr 6 13:37:39 Tower sSMTP[30063]: Creating SSL connection to host Apr 6 13:37:39 Tower sSMTP[30063]: SSL connection using RC4-SHA Apr 6 13:37:41 Tower sSMTP[30063]: RCPT TO:<Tower UPS Tower Power Failure !!!@> (553 5.1.2 or other punctuation after the recipient's email address. rk15sm64357801pab.37 - gsmtp) Apr 6 13:37:49 Tower apcupsd[3764]: Mains returned. No longer on UPS batteries. Apr 6 13:37:49 Tower apcupsd[3764]: Power is back. UPS running on mains. Apr 6 13:37:50 Tower sSMTP[30075]: Creating SSL connection to host Apr 6 13:37:50 Tower sSMTP[30075]: SSL connection using RC4-SHA Apr 6 13:37:52 Tower sSMTP[30075]: RCPT TO:<Tower UPS Tower Power has returned@> (553 5.1.2 or other punctuation after the recipient's email address. ha11sm27590855pbd.17 - gsmtp) And it does the same thing when manually sending an email using the plugin's scripts, e.g. "/etc/apcupsd/apccontrol onbattery" It appears to be failing when trying to run the following command to send the email, i.e. the command: $APCUPSD_MAIL -s "$MSG" $SYSADMIN I've tried to figure out what's going wrong, but I'm too experienced with this stuff. Any idea how to fix this? Tyler - I've figured out the problem and now have one of the scripts working properly. I need to update the other ones and then I'll attach them. I can't say exactly why what is happening is happening, but it's working nonetheless! More to come...
April 8, 201412 yr For anyone that decided to go with the last updated apcupsd from Nezil, the scripts for email sending need a bit of tweaking in order to work. You'll want to replace pretty much all of them since the stock versions don't work with ssmtp it seems. Through trial and error on the command line I was able to figure out a couple of things. First, the default scripts are setup for mail which can take the subject via "-s" on the command line. ssmtp doesn't like that very much so this has to be removed. Next, the subject needs to also send a newline command and not just a blank character otherwise the email would send with no content. So the echo command sending a blank character has been removed and instead where a new line is needed we add -e to the command and a \n at the end. So it looks like this: echo -e "Subject: Tower has lost power\n" The subject line is the most important one to add this to. The other blank lines will work fine, but I figured if I was changing it for one I might as well change it for all. I've updated all the scripts to reflect this and I've tested them all except the doshutdown one. I don't particularly want to take the system down at the moment! Attached you'll find the new scripts. Place them all in /boot/config/plugins/apcupsd/scripts/ and the plugin file thingie should do the rest on reboot to remove the stock scripts and link to these. You can also do that manually which is what I've done at the moment to test. Don't forget to remove the .txt extension! I can only add 4 files so I'll have to do one on the next post. commfailure.txt commok.txt doshutdown.txt offbattery.txt
April 9, 201412 yr For anyone that decided to go with the last updated apcupsd from Nezil, the scripts for email sending need a bit of tweaking in order to work. You'll want to replace pretty much all of them since the stock versions don't work with ssmtp it seems. Through trial and error on the command line I was able to figure out a couple of things. First, the default scripts are setup for mail which can take the subject via "-s" on the command line. ssmtp doesn't like that very much so this has to be removed. Next, the subject needs to also send a newline command and not just a blank character otherwise the email would send with no content. So the echo command sending a blank character has been removed and instead where a new line is needed we add -e to the command and a \n at the end. So it looks like this: echo -e "Subject: Tower has lost power\n" The subject line is the most important one to add this to. The other blank lines will work fine, but I figured if I was changing it for one I might as well change it for all. I've updated all the scripts to reflect this and I've tested them all except the doshutdown one. I don't particularly want to take the system down at the moment! Attached you'll find the new scripts. Place them all in /boot/config/plugins/apcupsd/scripts/ and the plugin file thingie should do the rest on reboot to remove the stock scripts and link to these. You can also do that manually which is what I've done at the moment to test. Don't forget to remove the .txt extension! I can only add 4 files so I'll have to do one on the next post. What happens if the network (and internet connection) is down as a result of the power outage? Does the mail process fail gracefully or does it hang the shutdown process because smtp can't connect to the mail server?
April 9, 201412 yr For anyone that decided to go with the last updated apcupsd from Nezil, the scripts for email sending need a bit of tweaking in order to work. You'll want to replace pretty much all of them since the stock versions don't work with ssmtp it seems. Through trial and error on the command line I was able to figure out a couple of things. First, the default scripts are setup for mail which can take the subject via "-s" on the command line. ssmtp doesn't like that very much so this has to be removed. Next, the subject needs to also send a newline command and not just a blank character otherwise the email would send with no content. So the echo command sending a blank character has been removed and instead where a new line is needed we add -e to the command and a \n at the end. So it looks like this: echo -e "Subject: Tower has lost power\n" The subject line is the most important one to add this to. The other blank lines will work fine, but I figured if I was changing it for one I might as well change it for all. I've updated all the scripts to reflect this and I've tested them all except the doshutdown one. I don't particularly want to take the system down at the moment! Attached you'll find the new scripts. Place them all in /boot/config/plugins/apcupsd/scripts/ and the plugin file thingie should do the rest on reboot to remove the stock scripts and link to these. You can also do that manually which is what I've done at the moment to test. Don't forget to remove the .txt extension! I can only add 4 files so I'll have to do one on the next post. Thanks acurcione! Added your 5 modified scripts and tested them all, including "doshutdown". Most importantly, the shutdown worked (clean), and they all sent emails as expected. What happens if the network (and internet connection) is down as a result of the power outage? Does the mail process fail gracefully or does it hang the shutdown process because smtp can't connect to the mail server? Previously I didn't have my modem on a UPS, but the unRaid box was, and the shutdown worked fine. That was with APCUPSD 3.14.10. I just it a quick test with the latest version by disconnecting the WAN on my modem. ssmtp timed out after about 30 seconds, and I got the following in my syslog: Apr 9 21:40:25 Tower sSMTP[4277]: Unable to locate smtp.gmail.com Apr 9 21:40:25 Tower sSMTP[4277]: Cannot open smtp.gmail.com:465 Note this was not running the "doshutdown", just one of the standard notification scripts. I guess the other issue for some people depending on their Internet connection is if power is out at the street level having your modem on a UPS may not help anyway.
April 23, 201412 yr Guys... I'm so sorry that I didn't notice the ongoing discussion on this thread. I have a 6 week old son (as well as a 3.5 year old), which means that I'm only able to grab a few hours hear and there to do work on things like this. I'm also pretty far from a professional, so I may not have all the answers! I've subscribed to the thread now and should be able to jump in if I see any further discussion / posts. I'm happy to see that you found a solution, and I'm going to have a look now into why you ran into this. I'm thought I'd uploaded exactly the scripts that I'm using, so I'm confused as to why you'd be having problems. It is possible that I uploaded something wrong, especially given that I'm running on only a few hours sleep. Apologies again, and stand by for some new updated plugins that I've been working on recently for Transmission, and OpenVPN... I now have my unRAID system connecting permanently to OpenVPN, but ONLY sending Transmission traffic over the VPN tunnel!
April 23, 201412 yr Tyler / acurcione, I can see where the problem lies, and I think perhaps I wasn't clear enough... In my post here, I linked examples of scripts for use with ssmtp. Here is the content of my 'onbattery' example file: #!/bin/sh # # This shell script if placed in /etc/apcupsd # will be called by /etc/apcupsd/apccontrol when the UPS # goes on batteries. # We send an email message to root to notify him. # HOSTNAME=`hostname` MSG="$HOSTNAME UPS Power Failure" ( echo "Subject: $MSG" echo " " echo "Utility power has been lost, and essential devices are now running on UPS battery power" echo " " echo "Apcaccess current status:" echo " " /sbin/apcaccess status ) | $APCUPSD_MAIL $SYSADMIN exit 0 As you can see, there is no -s option in the command that actually calls the mail program. I think your mistake may have been to use the example scripts given by apcupsd in the /etc/apcupsd folder, and it's my mistake for not making it clear that you shouldn't be simply copying these over to your flash drive, but rather creating new ones based on my template. In any case, looking at acurcione's solution, it seems that the same solution was used; great minds think alike I guess! I'm glad I got to the bottom of the problem at least!
April 23, 201412 yr Tyler / acurcione, I can see where the problem lies, and I think perhaps I wasn't clear enough... In my post here, I linked examples of scripts for use with ssmtp. Here is the content of my 'onbattery' example file: #!/bin/sh # # This shell script if placed in /etc/apcupsd # will be called by /etc/apcupsd/apccontrol when the UPS # goes on batteries. # We send an email message to root to notify him. # HOSTNAME=`hostname` MSG="$HOSTNAME UPS Power Failure" ( echo "Subject: $MSG" echo " " echo "Utility power has been lost, and essential devices are now running on UPS battery power" echo " " echo "Apcaccess current status:" echo " " /sbin/apcaccess status ) | $APCUPSD_MAIL $SYSADMIN exit 0 As you can see, there is no -s option in the command that actually calls the mail program. I think your mistake may have been to use the example scripts given by apcupsd in the /etc/apcupsd folder, and it's my mistake for not making it clear that you shouldn't be simply copying these over to your flash drive, but rather creating new ones based on my template. In any case, looking at acurcione's solution, it seems that the same solution was used; great minds think alike I guess! I'm glad I got to the bottom of the problem at least! Hey Nezil. If your files actually work without adding in the new line thing (or whatever you call it) than I don't see how. The subject line is the one that truly needs it from my testing, but I added it to every line I wanted a break in anyway. They all work now so that's all that's important I guess!
April 24, 201412 yr There is a new line in my script acurcione, it looks like this: echo " " To be honest, your solution is probably more elegant though!
April 30, 201412 yr Group, Not sure anyone else has this issue but I have a Back-UPS XS 1300 LCD and I just replaced the batteries in it so it should have a 100% on the batteries. The APCUPSD plugin shows a "UPS: ONLINE LOWBATT" but it all seems to be working fine. I followed the APC instructions on replacing the batteries so that should be good. I was not sure if there is something I need to reset because I cannot find anything that states otherwise. I figured someone may have had this same issue and can help. Thanks GSD
April 30, 201412 yr It might be that the batteries were low on power and need to charge up a bit. Check to see if it ("UPS: ONLINE LOWBATT") changes after some time.
April 30, 201412 yr So best to pull the load and recharge? The batteries should still be able to charge while on load as long as you still have power and are not running on the batteries.
April 30, 201412 yr Yeah same thing I thought but the power has been stable for days and it is still indicating a low battery status. I am going to try what they call a runtime calibration on it to see if that works.
April 30, 201412 yr The use of ACPTEST in the command line resets the APC Backup UPS setting when you perform a calibration. This reset battery to full load. So just a thought if anyone else runs into this.
May 21, 201412 yr Would everyone mind posting which UPS they are using and the pros and cons on it? I want to buy one in the next couple of days but want to see what everyone else is using.
Archived
This topic is now archived and is closed to further replies.