[Nut-upsuser] NUT with Cyber Power 700 AVR

[Rob Donovan]

hi there, I ran portmon.  Read on...

    I'm running nut 2.2.2-6.5 under Debian Lenny 5.05 on a Dell T110
PowerEdge Server hooked to a Cyberpower 1500 AVR LCD.  All new hardware
purchased in the last 3 months.  I tried to attach via usb at first, but
was getting stale data errors in syslog sometimes lasting a minute or
more, plus USBDEVFS_CONTROL errors too, so I decided to try a serial
cable instead.  I get exactly the same errors Thomas was getting:

/sbin/upsdrvctl start cp1500avr1
Network UPS Tools - UPS driver controller 2.2.2
Network UPS Tools - CyberPower driver 1.00 (2.2.2)
Giving up on hardware detection after 3 tries
Unable to get initial hardware info string
Driver failed to start (exit status=1)

/lib/nut/cyberpower -DDDDDDD -a cp1500avr1
Network UPS Tools - CyberPower driver 1.00 (2.2.2)
debug level is '7'
Giving up on hardware detection after 3 tries
Unable to get initial hardware info string

    Changing to driver = powerpanel in ups.conf :

/lib/nut/powerpanel -DDDDDDD -a cp1500avr1
Network UPS Tools -  CyberPower text/binary protocol UPS driver 0.23
(2.2.2)
Warning: This is an experimental driver.
Some features may not function correctly.

debug level is '7'
Trying binary protocol...
read: timed out
read: timed out
read: timed out
Trying text protocol...
send: (2 bytes) => 0d 0d
read: timed out
send: (3 bytes) => 50 34 0d
read: timed out
read: timed out
send: (3 bytes) => 50 34 0d
read: timed out
read: timed out
send: (3 bytes) => 50 34 0d
read: timed out
read: timed out
CyberPower UPS not found on /dev/ttyS0


ls -l /dev/ttyS*
crw-rw---- 1 root nut     4, 64 2010-08-06 09:18 /dev/ttyS0
crw------- 1 root root    4, 65 2010-08-05 15:20 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 2010-08-05 15:19 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 2010-08-05 15:19 /dev/ttyS3

    After running the cyberpower driver :

stty < /dev/ttyS0
speed 1200 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

    There are many ways to screw up serial port assignment on this
machine, but I think I have it correct in the BIOS.  I have :

Serial Communications = On with Console Redirection via COM2
Console Redirection After Boot = Enabled
External Serial Connector = Serial Device 1
Console Redirection Failsafe BAUD Rate = 115200
Serial Address Select = Serial Device1=COM1, Serial Device2=COM2

    That is, COM2/Serial Device 2 are used for Serial-over-Lan console
redirection, which works fine on ttyS1.  There is only one physical
connector on the back of the box, which I'm specifying is connected to
Serial Device 1 = COM1 which I have to presume is ttyS0.

   I should note that the "External Serial Connector" assignment tends to
drift.  The documentation says that you can toggle between Serial Device
1, Serial Device 2 and Remote Access Device using "Terminal Escape
Sequences" though I can't find any documentation on what those might
be.  They seem to be happening though.  If I set "External Serial
Connector  = Serial Device 1" in the BIOS and boot, then check it (using
Dell Open Manage) it's still set to 1.  But after another boot or two
it's set to 2.  Setting External Connector to Serial Device 1, power
cycling the UPS (it is not powering my machine at the moment), issuing
the above commands, and checking the connector is still assigned to
Serial Device 1 gives the results above.  It is interesting to note,
however, that I got the same results once and then found it was set to 2...

  The External Serial Connector drift is probably not the cause of this
problem though.  If you Google "Giving up on hardware detection after 3
tries" you can find several people reporting this problem back to at
least 2007.  I think all of them had Cyberpower UPSs.  I don't recall
any of them mentioning Dells, or External Serial Connector settings.
Moreover, if I boot with External Serial Connector = Serial Device 2
then the UPS will beep and keep flipping to battery during and after the
boot, presumably because it is interpreting SOL traffic as
instructions.  If I set External Serial Connector = Serial Device 1
before the boot this doesn't happen.  The boot stalls at the nut
startup, presumably waiting for timeouts, which then fails.  So there is
a difference when the UPS is connected to ttyS0, but it still doesn't work.


  Anyway, since I have an old Windows PC with a serial connector, I
decided to run portmon.  For future reference, I found this worked:

Disable any existing ups services/startups in msconfig (I had old APC
stuff running...)
Install portmon
Install software under test (cyberpower in my case)
Disable com1 in device manager
reboot
enable com 1
run portman
  connect local
  monitor com1 only
connect ups by serial cable
power on ups
restart cyberpower's service in service management -> messages fill portman
save messages.

I had a lot of trouble with stuff grabbing com1 before portmon, which
then couldn't monitor it.  I even got into a lovely state where the
machine would hibernate a few seconds after boot at one point
(disconnecting the serial cable fixed that - I think APC/MS ups.exe was
involved, somehow...).

The log file is attached to this message.  I ran Cyberpower's Power
Panel Personal edition at about 591 and clicked a couple of buttons.
That doesn't seem to have affected the log at all.  The full log
was too big for the list; I've truncated it here.  It's all repeats
after about line 100 anyway.    I note that line 1
is missing.  I didn't chop it : it just wasn't in the log.  Hopefully
you'll know why.

Incidentally, like Thomas I didn't know until I read it here that
Cyberpower was being less than helpful.  I bought this UPS to use with
nut at least in part because the nut documentation I read online led me
to believe that it would work both on usb and serial, and that
Cyberpower had donated a device to nut for development in the past.

Finally, I'll note that I tried Ubuntu 10.04 for a few weeks before
switching to Debian Lenny, under which I used nut 2.4.3 via usb
connection with fewer or no errors.  I think my next step is to try
grabbing 2.4.3 from a less stable Debian branch and see where that gets me.




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cp.LOG
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20100806/398edee2/attachment-0001.txt>