APC UPS won't talk to me

On Thu, 23 Jul 2009 13:50:27 -0700, Andrew Rossmann wrote (in article ):

This has been said a few times here. Until I get a breakout box and look at a few of the lines on that connector to see if it's actually data or just pulling lines high or low, I won't know.

I know that APC says that a standard serial cable won't work. I'm using their p/n cable that came with the UPS.

Thanks for your input.

Reply to
notme
Loading thread data ...

I recommend you check out:

formatting link

I tried to get APC:s software to run on a Solaris x86 system, but gave up. apcupsd works fine, even through a prolific based usb-serial adapter.

I haven't tried it on MacOS though.

I have an APC Smart UPS 700, which speaks serial, not some status port wiggle. It does require a APC specific cable though.

The link above contains references to simple commands that can be issued through a terminal emulator to verify that the communication works.

Reply to
Thomas Tornblom

"notme" schreef in bericht news: snipped-for-privacy@news.eternal-september.org...

First: I was mistaken about the question mark. You should send a Y.

You should use a normal ANSI terminal set to: 2400,n,8,1

APC is known for using non-standard cables. The one I saw had the next connections:

PC(DE9F) UPS(DE9M)

2------------------2 3------------------1 5------------------9 1-4 7-8

But there sure are other ones depending on the UPS-type. This one is for the APC Smart UPSs. No need to say there's no hardware handshake in this one.

But... Does your UPS talk RS232 anyway? I seem to remember that BackupPro types are rather dumb things that only do some signaling i.e. using pin 2 to tell the UPS is on battery. Guess on the PC side this should be considered a "break" and that's all.

petrus bitbyter

Reply to
petrus bitbyter

On Thu, 23 Jul 2009 14:24:01 -0700, Thomas Tornblom wrote (in article ):

Thanks for that. A great resource for APC owners who want to hack the device.

The commands you speak of are commands sent through the apcupsd daemon, not thorough a terminal program. Building the daemon for OS X and installing it is a (to me) monumental task.

But I think joining the support mailing list could prove helpful.

Thanks again.

Reply to
notme

On Thu, 23 Jul 2009 14:24:01 -0700, Thomas Tornblom wrote (in article ):

This site has much information about communication with the APC UPS's.

This is a diagram of the cable that came with my Backup-Pro UPS 650 (model BP650S):

APC Part# - 940-0095B Signal Computer UPS DB9F DB9M DTR 4 ----* CTS 8 ----| DSR 6 ----| DCD 1 ----* GND 5 ---------------*---- 4 Ground | *---- 9 Common RI 9 ----* | RxD 2 ----*--------------- 2 On Battery TxD 3 ----------[####]---- 1 Kill UPS Power 4.7K ohm

Apparently it uses voltage-level signaling not serial communication.

But I see no reason this won't work via a USB-serial adapter. When the RxD or TxD line is brought low, a bit is set or cleared in the buffer in the USB-serial driver.

It's a whole other story whether OS X will recognize such signals.

Why wouldn't this work with the USB-serial adapter?

Thanks.

Reply to
notme

** Good point; YES would be the logical conclusion.
** Seems that is what is left, Mr. Occam.

Reply to
Robert Baer

That's correct. The basic model simply toggle the equivalent of DTR high or log to signal that the UPS is or is not providing power from battery.

An AC UPS that speaks their (not so incredibly) "Smart" prototcol, namely the SmartUPS and more expensive APC UPS options, uses a serial cable that is wired:

APC UPS 1 3 2 2 9 5

In fact, if you plug in a standard, full-signal, 9 pin cable to both the APC and CPU, you run the risk of powering down the APC real fast.

FWIW, I sell an APC US solution in the OpenVMS space. I have seen this communications problem with APC UPSs all too many times. ;)

--
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
Reply to
VAXman-

yeah it will, usb-to-serial adaptors duplicate the same modem control pins and signals, applications that don't do direct IO port access will work just fine on usb-serial adaptors.

I did that myself last month.

Reply to
Jasen Betts

These converters are known to cause trouble if used with anything other than standard terminal communication. They might be designed for data transfer only or they might add a delay in the signals that causes havoc. Anyway they were useless to use chip programmers on laptops without serial port.

Reply to
Jeroni Paul

serial=20

if/when the=20

data

I have seen UPSs that talk contact closures, EIA-232, EIA-485, and even Ethernet. It varies by make model and options. I have seen them in power ranges from 50 W to 500,000 W with appropriate VA and surge ratings.

Reply to
JosephKK

A USB-to-serial-adaptor is not a DAQ interface. It doesn't simply send a stream of pin states or state-change events directly to the host.

A typical USB-to-serial adaptor[1] will expect a sequence consisting of a start bit, 8 data bits, an optional parity bit and 1 or 2 stop bits, all occurring at the configured (or auto-detected) baud rate.

[1] CDC, ACM = Communication Device Class, Abstract Control Model.

When it sees such a signal (IOW, when the UART says "a byte has been received"), it will queue the the received byte to be sent to the host.

It may also inform the host if the control lines (DCD, DSR, RI) change, but this feature (SERIAL_STATE notification) is optional.

Based upon your wiring diagram, if you can find a USB-to-serial adaptor which supports the Ring Indicator (RI) line, you should be okay. Or if you can find one which supports DSR or DCD, you can make your own cable which uses this line instead.

You may have better luck with DSR or DCD. RI is the least useful signal, as you can just have the modem driver listen for a "RING" response from the modem. If the RS-232 driver is 4-in-4-out (e.g. MAX238), it's likely that RI is the one which will be ignored.

Also, note that you can't directly query the state of CTS (the device just NAKs Tx packets if the Tx buffer is full), so if the RS-232 driver is

2-in-2-out (e.g. MAX232), you're out of luck, as none of DCD, DSR or RI will be monitored.

FWIW, the USB CDC specification is at:

formatting link

Reply to
Nobody

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.