Help Building an APC home automation driver for APC Smart UPS SC1500

[etc6849]

I just purchased an SC1500 for my rack (APC smart UPS), and I'm trying to build a custom home automation driver that will query the device to gather information.

Thus far, I have used the PowerChute software to test my cable. All works well. RealTerm in spy mode shows my PC sending ascii characters to the UPS and the UPS responding with data ending with a lf and cr.

However, when I try to send the similar commands as PowerChute out from my home automation software (motorola premise), I receive no response from the UPS!?!

The data is sent out of the serial port as ascii using "textmode" (with the powerchute server disabled under windows to free up the port)... For example, if I send the character B, I should receive the battery voltage, but I receive nothing? Should I be talking to the UPS in binary mode and not text mode? Is there some sort of initialization I need to be doing? Right now, I'm not sending anything other than B...

Anyone recently purchase a Smart UPS and write a driver? If so, please provide some hints :lol:

This protocol looks to be applicable to the UPS according to RealTerm in Spy mode:
http://www.networkupstools.org/protocols/apcsmart.html

 

[KentDub]

From a debugging perspective, I would move to sending hex rather than ASCII. This will let you easially make sure that the exact command is being sent (not missing or extra CrLf's, etc.) Do your testing in a real terminal client first, before integrating, such as Putty (freeware). Also, please make sure that your client has the right serial settings (the site you listed claims 2400 bps/8N1). I was just today freaking out that I couldn't get my new terminal server to work with my UPB PIM -- then I found out that I had the wrong baud rate :lol:

Give it a shot and let us know how it goes

 

[mustangcoupe]

I'd use a serial port sniffer to see what commands are being sent when you use powerchute and what is sent from the terminal window is the same

 

[etc6849]

Putty is a good idea for initial testing since I'm not entirely sure what in hex the HA program is sending out (my port sniffing software Realport with spy driver) won't work with it

The Powerchute software from APC spits out all kinds of stuff upon connection to the APC UPS. I have no idea what most of it means, but I'll have to capture the hex and analyse it.

From a debugging perspective, I would move to sending hex rather than ASCII. This will let you easially make sure that the exact command is being sent (not missing or extra CrLf's, etc.) Do your testing in a real terminal client first, before integrating, such as Putty (freeware). Also, please make sure that your client has the right serial settings (the site you listed claims 2400 bps/8N1). I was just today freaking out that I couldn't get my new terminal server to work with my UPB PIM -- then I found out that I had the wrong baud rate :lol:

Give it a shot and let us know how it goes

 

[123]

According to this reference, the pin-out for the serial-communications cable is non-standard.

 

[etc6849]

That's correct, for the smart UPS you need to use the supplied cable not a standard straight through cable. The good news is now I am receiving stuff from the UPS :lol:

All I had to do was first send Y to the UPS to first enable smart mode... DOH! After that, the other commands receive stuff back.

Now I just have to decode what is received back from the UPS (and it looks messy). Maybe I should use binarymode instead of textmode...

According to this reference, the pin-out for the serial-communications cable is non-standard.

 

[ipsgroup]

I just purchased an SC1500 for my rack (APC smart UPS), and I'm trying to build a custom home automation driver that will query the device to gather information.

...

Anyone recently purchase a Smart UPS and write a driver? If so, please provide some hints :lol:

Have you looked at Apcupsd for hints?. "Apcupsd can be used for power mangement and controlling most of APC's UPS models on Unix and Windows machines. Apcupsd works with most of APC's Smart-UPS models as well as most simple signalling models such a Back-UPS, and BackUPS-Office." (from their webpage at http://www.apcupsd.com/). Source and binaries are available on Source Forge.

Page 98 of the Apcupsd manual (http://www.apcupsd.com/manual/manual.pdf) has a table describing "The Smart Protocol." From Page 98:

Despite the lack of official information from APC, this table has been constructed. It's standard RS-232
serial communications at 2400 bps/8N1. Don't rush the UPS while transmitting or it may stop talking to
you. This isn't a problem with the normal single character queries, but it really does matter for multi-char
things like "@000". Sprinkle a few calls to usleep() in your code and everything will work a lot better.

The following table describes the single character "Code" or command that you can send to the UPS, its
meaning, and what sort of response the UPS will provide. Typically, the response shown below is followed
by a newline (\n in C) and a carriage return (\r in C). If you send the UPS a command that it does not
recognize or that is not available on your UPS, it will normally respond with "NA" for "not available",
otherwise the response is given in the "Typical results" column.​

Hope this helps.

 

[etc6849]

Thanks. This looks like a good resource for me.

 

[etc6849]

UPDATE: The home automation program I use (Motorola Premise) does not seem to work with the APC. I send S and receive nothing back...?

However, the good news is that putty works fine and I'm able to get a response to the commands listed in the reference just fine (after sending S once), but only under putty.

Any ideas? Serial communications are standard right? If it works in putty, why would it not work from Premise? In premise, I send the command out as ascii; ie textmode. This is the mode I have used to build drivers for a betabrite sign, onkyo receiver, PJ, etc... It's always worked for me until now. How exactly is putty sending the data?

 

[KentDub]

UPDATE: The home automation program I use (Motorola Premise) does not seem to work with the APC. I send S and receive nothing back...?

However, the good news is that putty works fine and I'm able to get a response to the commands listed in the reference just fine (after sending S once), but only under putty.

Any ideas? Serial communications are standard right? If it works in putty, why would it not work from Premise? In premise, I send the command out as ascii; ie textmode. This is the mode I have used to build drivers for a betabrite sign, onkyo receiver, PJ, etc... It's always worked for me until now. How exactly is putty sending the data?

Check the baud rate and other parameters for opening a COM port. If everything seems right, try doing using a serial loopback cable and setup Premise at one end and Putty at the other so you can take a peak exactly what Premise is doing.

Good luck

 

[etc6849]

Thanks Kent. I finally found a serial port spy program that will work with Premise and it's free to try for 15 days (called Advanced Serial Port Monitor). I'm not home to try the spy program with the APC Smart UPS, but I'm able to test my driver using a loop back plug I made locally on my laptop. FYI: SYS = Premise Server. I believe there is some haredware setting that isn't exactly right. The "Y" is sent by itself with no terminators. I don't know why the loopback adapter is causing the baud rate to be 9600... It should be 2400 (port is set as 2400 within Premise and under windows devices); I'm going to have to study this on my home automation server and not my laptop.

Note the Y is received to the loopback cable (not connected to the APC Smart UPS). However, do the hardware settings look ok for talking to an APC Smart UPS? I'll post more later this week when I make it home.

<20100330204820.963 SYS>
COM port is opened
<20100330204820.963 SYS>
Baud rate 9600
<20100330204820.963 SYS>
RTS on
<20100330204820.963 SYS>
DTR on
<20100330204820.963 SYS>
Data bits=8, Stop bits=1, Parity=None
<20100330204820.963 SYS>
Set chars: Eof=0x00, Error=0x00, Break=0x00, Event=0x00, Xon=0x11, Xoff=0x13
<20100330204820.963 SYS>
Handflow: ControlHandShake=(DTR_CONTROL), FlowReplace=(TRANSMIT_TOGGLE, RTS_CONTROL), XonLimit=2048, XoffLimit=512
<20100330204820.963 SYS>
Set timeouts: ReadInterval=2, ReadTotalTimeoutMultiplier=0, ReadTotalTimeoutConstant=0, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=5000
<20100330204820.963 SYS>
Purge the serial port: RXABORT, RXCLEAR, TXABORT, TXCLEAR
<20100330204823.247 TX>
Y
<20100330204823.277 RX>
Y
<20100330204823.717 TX>
Y
<20100330204823.737 RX>
Y
<20100330204824.138 TX>
Y
<20100330204824.168 RX>
Y
<20100330204826.461 SYS>
Purge the serial port: RXABORT, RXCLEAR, TXABORT, TXCLEAR
<20100330204826.481 SYS>
COM port is closed

EDIT: Disabling DTS and RTS within the driver under Premise seemed to fix the baud issue:

<20100330205402.204 SYS>
COM port is opened
<20100330205402.204 SYS>
Baud rate 2400
<20100330205402.204 SYS>
RTS off
<20100330205402.204 SYS>
DTR off
<20100330205402.204 SYS>
Data bits=8, Stop bits=1, Parity=None
<20100330205402.204 SYS>
Set chars: Eof=0x00, Error=0x00, Break=0x00, Event=0x00, Xon=0x11, Xoff=0x13
<20100330205402.204 SYS>
Handflow: ControlHandShake=(), FlowReplace=(), XonLimit=2048, XoffLimit=512
<20100330205402.204 SYS>
Set timeouts: ReadInterval=8, ReadTotalTimeoutMultiplier=0, ReadTotalTimeoutConstant=0, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=5000
<20100330205402.204 SYS>
Purge the serial port: RXABORT, RXCLEAR, TXABORT, TXCLEAR
<20100330205403.977 TX>
Y
<20100330205404.017 RX>
Y
<20100330205407.351 SYS>
Purge the serial port: RXABORT, RXCLEAR, TXABORT, TXCLEAR
<20100330205407.401 SYS>
COM port is closed

 

[etc6849]

Thanks everyone for the advice. It's working now. It turns out I was pointing a multivalue variable using a string ("2400"); this should have been an int pointer or 2400. The annoying part is the driver displayed 2400, but didn't actually set the baud rate to 2400; this is why it connected at 9600 and wouldn't work.

I'll post the completed driver under the Premise forum this week. It's written in a vbscripting language that Premise interprets in a single thread.

 

[etc6849]

Link to free APC SmartUPS driver: http://www.cocoontech.com/forums/index.php?showtopic=16267

Works with the free Motorola Premise software: http://www.cocoontech.com/wiki/premise

Enjoy! If you don't use Premise, but your platform supports vbscripts and events, you can use most of my code if you open the driver up in notepad++ or notepad for that matter.