I decided that a UPS would be a good investment to make for my computer. The power supply in my area tends to be fairly stable, but one never knows when a nasty spike or an outage will come along (especially in the windy season... if you've never experienced a SoCal Santa Ana windstorm, trust me, they can get pretty nasty). The last thing I wanted was to have some kind of hardware damage as a result of it. Also, too, yanking the power out from under any unix machine can do nasty things to the filesystem, and although I don't really have anything truly vital on the machine, it'd be a royal pain in the ass to fix everything back up just the way I like it. So, I set to finding an affordable UPS that would meet my needs.
This proved to be no small task. There are a variety of UPS manufacturers out there, but the market shrinks considerably when you factor into the equation a need for UPS control software that runs under IRIX and costs under $400 or so (that was the amount I found myself able to justify spending on this purchase). Ultimately I went with a TrippLite OmniSmart 675 UPS; it met my needs for cost, features, availability (I wanted to purchase at a local store and not via mail order), and it was the single most recommended brand amongst other SGI users with whom I had spoken. Also, the control software, which did support IRIX, was free. Other companies wanted upwards of $300 for the software alone, which I found unreasonable for my situation. Another case where PC and Mac users get all the pricing advantages.
I won't go into the details of how I determined the right VA rating for my system; that is covered in detail in many other places. It's not hard to do, and a simple web search should turn up enough information should you want to do the same. I think there's actually a "UPS FAQ" out there that tells you how to do it. Most UPS manufacturers have a section outlining the process on their web pages.
The software installed just fine, as did the UPS itself. The major problem was getting my O2 to properly communicate with the UPS. Whenever the computer was on and attached to the UPS via the included communications cable (I call it a "communications" cable because it's not truly a serial cable, and definitely not a serial data connection, even though it goes through the serial port), the UPS turned on its "low battery" warning, even though the battery was just fine. After a lot of troubleshooting, I found that the problem seemed to be entirely due to the included communications cable. The OmniSmart UPS uses what is called "contact closure" in order to communicate its current state to the computer to which it is attached. In other words, there are a few switches inside the UPS that open or close depending on what is going on (wall power fails, the battery is low, etc.). And for some reason, the UPS did not like way the O2 implemented the serial port. From the very instant the computer was powered on the "low battery" light was active, which more or less ruled out that changing the software would help matters in any way. So, much like the one ugly guy that nobody wants to touch at an orgy, I was forced to take matters into my own hands.
Before you read any further, you should really read the update to this page. Especially if you think you might want to attempt this on your own.
Out came the multitester and my normal array of jumper wires and diagnostic probes (a fancy way of saying bent paper clips and safety pins, respectively). After comparing the wiring diagram provided in the instructions for my UPS to the results of a lot of testing of the included cable, I found out that one of the pins on the O2's serial port was set to a certain state at power on or reboot, which could then be changed later as a result of accessing the serial port (using a program such as cu). So, depending on whether or not the machine had been freshly rebooted or power cycled, the UPS would give me a "low battery" light and not function properly. The UPS control software did not set the state of this pin correctly, so as soon as the software was started it began to issue "low battery" warnings and initiate an automatic shutdown. However, I could ground various pins manually on the UPS cable and get the result I wanted; the UPS software would register whether or not the wall power had gone out or whether or not the battery was legitimately low. And so, being one to completely disregard common sense, I rewired the cable to suit what I found to be a better wiring pattern. Sure enough, the UPS then communicated with the O2 just fine. Mother Nature was even kind enough to provide some severe winds the next day and knock out power on my block so I could test whether or not my O2 would shut itself down properly; sure enough, everything worked beautifully.
Here's my setup:
| Bare wire
Red wire Orange wire Yellow wire Brown wire Black wire |
Soldered to shield
Pin 4 Pin 5 Pin 6 Pin 2 (see note below) Pin 1 |
Bare wire
Red wire Orange wire Yellow wire Brown wire Black wire |
Soldered to shield
Pin 1 Pin 5 Pin 6 Not used Not used |
NOTE: there is what appears to be a diode in line with the brown wire inside the cable end housing. It's surrounded by plastic so I can't really get to it in order to look at it. This wire is not used in my cable however, so I doubt it harms anything by not having a matching diode in the rewired cable.
These pinouts all apply to the end of the cable that attaches to the UPS, NOT to the end that attaches to the computer. Make sure you get that right should you attempt this.
The above re-wired pinout does indeed produce the desired results on my particular machine. And I have been running this setup for about four months now without any problems whatsoever, and the entire system still operates fine.
Ok, I hear you saying, "Why did you leave out the black and the brown wire? They must be there for a reason." Presumably they are there for a reason... the wiring diagram inside the manual says that they are for the "external inverter shutdown" but nowhere else in the manual does it explain what that is exactly (note: read the updates below for information regarding the external inverter shutdown pin). All I know is this; I want my setup to operate in such a fashion that when the power goes out, the computer will continue to run until the battery in the UPS gets low, at which point it should shutdown. And that's all I want it to do. I know the UPS does its job just fine when not attached to the computer, so presumably the computer doesn't actually need to be there for the UPS to work. Also, all I care about is that the computer be signaled when the wall power goes out and when the UPS battery is low. The above new wiring scheme does exactly that. So, if someone can give me a good technical reason why those external inverter shutdown wires need to be attached, I'll re-attach them. But as it is now, this change makes the difference between having a computer that will shut itself down automatically and one that requires human intervention in the event of a power failure. Since power failures do not plan themselves around my schedule, I need the machine to be able to do that on its own. So it's either this or nothing.
A few other configuration notes
The software that TrippLite makes available to you if you purchase one of their UPS systems is really nice. I like it quite a bit. I found it easy to install, easy to configure, and easy to maintain. Plus, and above all else, it works, it supports IRIX, and it was included in the price of the UPS (which, in my opinion, is how it SHOULD be). A few configurational changes needed to be made after installing the software though, and I will document them here.
After installing and configuring the software as per the directions (you weren't thinking of attempting all that without reading the manual, were you?), there are a couple of configuration files that should be edited to customize the software to the particulars of the O2. For the purposes of this discussion, let's stipulate (I sound like Randolph Herber when I say that) that the software was installed in /usr/local/paplus (which is where I installed it, I believe the default is to install it in /opt/paplus).
First, edit the file /usr/local/paplus/bin/pap_shutdown and change the lines that read:
SOLARIS_2_SPARC|SOLARIS_2_INTEL|SILICON_GRAPHICS_IRIX)to this:
PATH=/sbin:/usr/sbin:/usr/bin:$PATH
exec init 0
;;
SOLARIS_2_SPARC|SOLARIS_2_INTEL|SILICON_GRAPHICS_IRIX)
PATH=/sbin:/usr/sbin:/usr/bin:$PATH
exec /etc/shutdown -y -g0 -i0 -p
;;
This is important because just exec'ing an init 0
is lame. Why is it lame? Because it will bring the machine
down to a point where you can remove the power, whereas shutdown
(aside from just generally being more graceful and polite) when exec'ed
with the -p option will power the machine off for you. You
don't have to do it this way if you don't want; I just prefer it this way
for my particular setup.
That's basically all that needs to be changed. I made two other changes because I preferred the software to operate in a different manner. First I created a shell script that I saved as a file called /usr/local/paplus/bin/pap_announce which consists of the following contents:
#!/bin/shThen, I modified the two .ini files that are used to announce the status of the UPS to the world by means of the /sbin/wall command.
/usr/bsd/logger -t paplus -p local0.emerg
In file /usr/local/paplus/ini/server.ini I changed the line that reads:
BroadcastCommand=/sbin/wallto this:
BroadcastCommand=/usr/local/paplus/bin/pap_announceAnd then I changed the line in file /usr/local/paplus/ini/shutdown.ini that reads:
BroadcastCommand=/sbin/wallto this:
BroadcastCommand=/usr/local/paplus/bin/pap_announceI did it this way so that instead of using wall and just announcing information to all the logged in users, events will be logged to the system log. Also, on my particular system I have it configured so that all messages of the emergency level get broadcast to logged in users. So I have the best of both worlds in this way. Why did I have to make a separate shell script instead of just including the logger command in the .ini files? It seems that the PowerAlert Plus software will not issue the broadcast command properly if it has command line options. A bug on the software's part I guess, but it's easily remedied with the use of the external shell script.
One last thing... for the serial device I configured the software to use /dev/ttyf2. Since the software communicates to the UPS by utilizing the lines normally meant for hardware flow control, you want to use a device with this capability. That pretty much rules out the /dev/ttyd* entries. It's been a while since I fiddled with the software, but as I recall using the /dev/ttym* entries did not work. That would make sense, too, since there are two switches the UPS can open and close to indicate its state, and according to the man page for serial(7), the /dev/ttym* entries can only handle one of the sensing lines, not two.
Hopefully all the above information is clear. If not, feel free to let me know in the hopes that perhaps I can correct it.
As is typical of me, I did this entire thing the hard way when there was a much easier way of resolving this problem all along. Eventually someone submitted the info on this page to a technician at TrippLite, and I got into a rather interesting conversation about the setup and how it should work versus how it did work. Ultimately I found out that all the above wiring was absolutely unnecessary, although I still think my wiring schematic makes a lot more sense than the original. Anyhow, here's the gist of what I learned: