I recently bought a new UPS, and I'm attempting to use nut to monitor it. Following setup instructions everything seemed to go well until it came to testing the connection, which failed.
There is just one serial connector on the computer, so I set it to monitor /dev/ttyS0. Either that is wrong, or communication is failing. I've been told to try minicom to monitor it, but I'm not familiar with minicom (or any similar app), so again, I may be wrong in the way I'm trying to use that. I was told that unconnecting the device, then re-connecting it should give me a raft of output to the terminal - I saw nothing.
Could someone please give me idiot-level instructions on how to tell whether I'm connecting to the correct port, or whatever other information I need?
Thanks
Anne
On Thu, 2009-02-26 at 10:17 +0000, Anne Wilson wrote:
I recently bought a new UPS, and I'm attempting to use nut to monitor it. Following setup instructions everything seemed to go well until it came to testing the connection, which failed.
There is just one serial connector on the computer, so I set it to monitor /dev/ttyS0. Either that is wrong, or communication is failing. I've been told to try minicom to monitor it, but I'm not familiar with minicom (or any similar app), so again, I may be wrong in the way I'm trying to use that. I was told that unconnecting the device, then re-connecting it should give me a raft of output to the terminal - I saw nothing.
Could someone please give me idiot-level instructions on how to tell whether I'm connecting to the correct port, or whatever other information I need?
Anne,
Are you sure the cable is correct? I recall in the past having trouble with an APC UPS that required an oddball RS-232 serial cable before it would communicate. There were different variants available and only one would work. Posting details of the brand/model of UPS involved might get better help.
Phil
On Thu, 2009-02-26 at 06:14 -0500, Phil Schaffner wrote:
On Thu, 2009-02-26 at 10:17 +0000, Anne Wilson wrote:
<snip>
There is just one serial connector on the computer, so I set it to monitor /dev/ttyS0. Either that is wrong, or communication is failing. I've been told to try minicom to monitor it, but I'm not familiar with minicom (or any similar app), so again, I may be wrong in the way I'm trying to use that. I was told that unconnecting the device, then re-connecting it should give me a raft of output to the terminal - I saw nothing.
Could someone please give me idiot-level instructions on how to tell whether I'm connecting to the correct port, or whatever other information I need?
Anne,
Are you sure the cable is correct? I recall in the past having trouble with an APC UPS that required an oddball RS-232 serial cable before it would communicate. There were different variants available and only one would work. Posting details of the brand/model of UPS involved might get better help.
OTOH, if the manufacturer has any common sense, at worst they'll require a "standard" (NOT!) null-modem cable. At best, they'll have circuitry/software on-board that accepts either a straight-through or null and adapts itself.
Being an _old_ telecom guy from way back, I prefer what was called a symmetrical null modem fully configured. From memory (and therefore suspect)
Pin---->Pin 2 3 3 2 4 4 6 6 7 7 8 20 20 8
Some also do 5 to 5.
However, a 2-3 cross and DTR and DCD high is all that really is needed.
Google for RS-232 will get you a ton of stuff.
As to the OP original question, check BIOS settings and make sure your serial is enabled. Set it to COM 3 and IRQ 4 should work. This would equate to "0" in an *IX system.
Look in your /var/log/messages file. At boot, you should see the device recognized.
Also, Minicom is _easy_ to use and understand. Give it a try. Even the man pages are not difficult.
Phil
<snip sig stuff>
HTH
On Thu, 2009-02-26 at 06:34 -0500, William L. Maltby wrote:
<snip>
As to the OP original question, check BIOS settings and make sure your serial is enabled. Set it to COM 3 and IRQ 4 should work. This would
s/COM 3/COM 1/ # Drat! More JAVA, more JAVA!
equate to "0" in an *IX system.
Look in your /var/log/messages file. At boot, you should see the device recognized.
<snip>
On Thursday 26 February 2009 11:34, William L. Maltby wrote:
On Thu, 2009-02-26 at 06:14 -0500, Phil Schaffner wrote:
On Thu, 2009-02-26 at 10:17 +0000, Anne Wilson wrote:
<snip>
There is just one serial connector on the computer, so I set it to monitor /dev/ttyS0. Either that is wrong, or communication is failing. I've been told to try minicom to monitor it, but I'm not familiar with minicom (or any similar app), so again, I may be wrong in the way I'm trying to use that. I was told that unconnecting the device, then re-connecting it should give me a raft of output to the terminal - I saw nothing.
Could someone please give me idiot-level instructions on how to tell whether I'm connecting to the correct port, or whatever other information I need?
Anne,
Are you sure the cable is correct? I recall in the past having trouble with an APC UPS that required an oddball RS-232 serial cable before it would communicate. There were different variants available and only one would work. Posting details of the brand/model of UPS involved might get better help.
OTOH, if the manufacturer has any common sense, at worst they'll require a "standard" (NOT!) null-modem cable. At best, they'll have circuitry/software on-board that accepts either a straight-through or null and adapts itself.
Being an _old_ telecom guy from way back, I prefer what was called a symmetrical null modem fully configured. From memory (and therefore suspect)
Pin---->Pin 2 3 3 2 4 4 6 6 7 7 8 20 20 8
Some also do 5 to 5.
However, a 2-3 cross and DTR and DCD high is all that really is needed.
Google for RS-232 will get you a ton of stuff.
As to the OP original question, check BIOS settings and make sure your serial is enabled. Set it to COM 3 and IRQ 4 should work. This would equate to "0" in an *IX system.
Yes, it says
COM Port 1 3F8/IRQ4
It's a long time since I did anything with com ports, and I wasn't expert, then, but that looks right.
Look in your /var/log/messages file. At boot, you should see the device recognized.
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Feb 26 12:12:25 borg2 kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Is this what I'm looking for? I don't see anything else.
Also, Minicom is _easy_ to use and understand. Give it a try. Even the man pages are not difficult.
Easy when you know how, eh? :-) I did try it. I changed it to monitor /dev/ttyS0. Apart from that, I hadn't a clue what to do. I did look at the man page, too, but not knowing what I was looking for didn't help.
Anne
On Thu, 2009-02-26 at 12:31 +0000, Anne Wilson wrote:
On Thursday 26 February 2009 11:34, William L. Maltby wrote:
<snip>
As to the OP original question, check BIOS settings and make sure your serial is enabled. Set it to COM 3 and IRQ 4 should work. This would equate to "0" in an *IX system.
Yes, it says
COM Port 1 3F8/IRQ4
It's a long time since I did anything with com ports, and I wasn't expert, then, but that looks right.
It is.
Look in your /var/log/messages file. At boot, you should see the device recognized.
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices. But wait until you have things working - I suspect you have _two_ ports (probably 1 9 pin and 1 25 pin). A second port of 25 pins might easily be mistaken for a printer port. Long ago a switch from Centronics style to RS-232 style began to become the "standard". Physically, it looks the same as a serial port, the visual difference being the "gender" of the connector will be opposite.
Feb 26 12:12:25 borg2 kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Is this what I'm looking for? I don't see anything else.
Yes. That means that all is as expected (i.e. as _I_ expect).
Also, Minicom is _easy_ to use and understand. Give it a try. Even the man pages are not difficult.
Easy when you know how, eh? :-) I did try it. I changed it to monitor /dev/ttyS0. Apart from that, I hadn't a clue what to do. I did look at the man page, too, but not knowing what I was looking for didn't help.
I haven't used it for a _long_ time, but IIRC there is an interactive menu system that works with some keystroke, maybe <ESC> key. Look for that stuff in the man pages and it should be clear sailing.
First, have you set the baud rate correctly? A lot of things used to default to 9600, but 38400 became common later on. Do the docs for the unit specify? If so, use the stty command, or in minicom or other terminal emulator it's method, to set the baud rate to that needed. Usually these days, no parity check is done so 8 bit characters should be OK.
Now, since the port is recognized the failure has to be from the port onward. If the RS-232 9 or 25 pin shell is connected via a cable to the main board, make sure that the cable connector is connected to the right header on the main board. Since Linux reported two ports, there should be two headers on the main board (_if_ that's the method - some ma inboards have them mounted directly on the main board). If the header/connector is not keyed, it may be connected backwards. If you have two RS-232D shells (9 or 25 pin) you may be connecting your cable to the wrong one.
Moving on, have you been able to verify the cable is good? If you have an RS-232 patch device with LED's, you can see activity (DTR, DCD, etc.) by hooking the cable to it. If you don't have one of those, a digital multi-meter can be used to see if you have expected voltages on certain pins (+/- 12 volts, IIRC). If you don't have one of those, a plain old dumb terminal can be hooked up and settings changed in a trial and error method.
Since they supplied the cable, is it new enough to assume that it is not damaged? If so, I suspect something easy like baud rate.
Anne
<snip sig stuff>
HTH
On Thu, Feb 26, 2009 at 8:37 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
On Thu, 2009-02-26 at 12:31 +0000, Anne Wilson wrote:
On Thursday 26 February 2009 11:34, William L. Maltby wrote:
<snip> As to the OP original question, check BIOS settings and make sure your serial is enabled. Set it to COM 3 and IRQ 4 should work. This would equate to "0" in an *IX system.
Yes, it says
COM Port 1 3F8/IRQ4
The Leibert manual for the UPS hopefully has some data about the software they supply with it, assuming they do supply software with it.
Disable the Serial Ports they are not using, in BIOS.
Probably 8N1 for the communications settings, along with the Baud rate? Like Bill, it's been a long time since I did anything with RS-232C communications..
Check the connector on the box, to be sure the cable to it is seated properly.
The cable they supplied with the UPS is probably OK, but, maybe not.
Even in the 3 off brand UPS we bought, a few weeks ago, they have capability to communicate. Not using it, but on the box it says, "RS-232 Interface Monitoring UPS status through RS-232 Communication Port by downloaded software".
If your UPS didn't come with Software, see if they have it available for Download. I suspect they do. Probably, it'll only work with M$ Windows, but if you can install it on a Windoze box, you can get an idea of what they want. If you are very lucky, it will work on Linux too. GL
On Thursday 26 February 2009 13:37, William L. Maltby wrote:
Look in your /var/log/messages file. At boot, you should see the device recognized.
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices.
I believe you are right. I remember those - and the 25-9-pin adapter :-). Peering around the back in a dark corner, I could well have been mistaken. OK - female socket, so that's a COM port, I think.
Now I'm really confused. The BIOS definitely only shows one COM port. To be honest, I can't remember whether I connected it or not. I guess I ought to open the box and see what's what, but not today - it's already too late to do that.
But wait until you have things working - I suspect you have _two_ ports (probably 1 9 pin and 1 25 pin). A second port of 25 pins might easily be mistaken for a printer port. Long ago a switch from Centronics style to RS-232 style began to become the "standard". Physically, it looks the same as a serial port, the visual difference being the "gender" of the connector will be opposite.
Feb 26 12:12:25 borg2 kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Is this what I'm looking for? I don't see anything else.
Yes. That means that all is as expected (i.e. as _I_ expect).
Also, Minicom is _easy_ to use and understand. Give it a try. Even the man pages are not difficult.
Easy when you know how, eh? :-) I did try it. I changed it to monitor /dev/ttyS0. Apart from that, I hadn't a clue what to do. I did look at the man page, too, but not knowing what I was looking for didn't help.
I haven't used it for a _long_ time, but IIRC there is an interactive menu system that works with some keystroke, maybe <ESC> key.
Ctrl-A Z - yes, I found that.
Look for that stuff in the man pages and it should be clear sailing.
First, have you set the baud rate correctly? A lot of things used to default to 9600, but 38400 became common later on. Do the docs for the unit specify? If so, use the stty command, or in minicom or other terminal emulator it's method, to set the baud rate to that needed. Usually these days, no parity check is done so 8 bit characters should be OK.
Now, since the port is recognized the failure has to be from the port onward. If the RS-232 9 or 25 pin shell is connected via a cable to the main board, make sure that the cable connector is connected to the right header on the main board. Since Linux reported two ports, there should be two headers on the main board (_if_ that's the method - some ma inboards have them mounted directly on the main board). If the header/connector is not keyed, it may be connected backwards. If you have two RS-232D shells (9 or 25 pin) you may be connecting your cable to the wrong one.
I'll check all that out tomorrow. I only have a supplied cable for 9 pin, so if everything else checks out I'll just have to try changing settings to ttyS1 and see if that helps.
Moving on, have you been able to verify the cable is good? If you have an RS-232 patch device with LED's, you can see activity (DTR, DCD, etc.) by hooking the cable to it. If you don't have one of those, a digital multi-meter can be used to see if you have expected voltages on certain pins (+/- 12 volts, IIRC). If you don't have one of those, a plain old dumb terminal can be hooked up and settings changed in a trial and error method.
I'm not handy with a multimeter, but if I have to, I'll give it a try :-)
Since they supplied the cable, is it new enough to assume that it is not damaged? If so, I suspect something easy like baud rate.
Brand new. I know anything's possible, but I'd put a bad cable very low on the list of likelihoods.
Settings at present:
A Serial Device : /dev/ttyS0 B Lockfile Location : /var/lock C Callin Program : D Callout Program : E Bps/Par/Bits : 38400 8N1 F Hardware Flow Control : Yes G Software Flow Control : No
All this is as set up in nut. Liebert do supply 'Multilink' software, but in theory nut installs the latest Liebert Multilink drivers. I'm seriously wondering whether I should remove nut and install the supplied software. However, I realise that I need to check the hardware situation first. Hopefully that will be done tomorrow.
Anne
On Thu, Feb 26, 2009 at 04:55:16PM +0000, Anne Wilson wrote:
On Thursday 26 February 2009 13:37, William L. Maltby wrote:
Look in your /var/log/messages file. At boot, you should see the device recognized.
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices.
I believe you are right. I remember those - and the 25-9-pin adapter :-). Peering around the back in a dark corner, I could well have been mistaken. OK - female socket, so that's a COM port, I think.
Let me just throw out one caveat here: Many UPSes that use a serial port don't really utilize it to transfer serial data, but rather just raise/lower some of the signal lines to let the software on the host know something has changed. Of course, lots of them, especially newer/smarter ones DO pass serial data. But if this one is one of the dumb ones, the cable may not even be a normal rs-232 cable, so trying to monitor it with a terminal may not produce much useful information.
Anne _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 2009-02-26 at 13:02 -0500, fred smith wrote:
<snip>
Let me just throw out one caveat here: Many UPSes that use a serial port don't really utilize it to transfer serial data, but rather just raise/lower some of the signal lines to let the software on the host know something has changed. Of course, lots of them, especially newer/smarter ones DO pass serial data. But if this one is one of the dumb ones, the cable may not even be a normal rs-232 cable, so trying to monitor it with a terminal may not produce much useful information.
Yes. My intent was to debug the computer side first. With a terminal hooked up, you can echo directly to a ttyS{0,1,...} some short line and see if the characters are readable. Whne that is achieved, looking at the terminal settings will let you know baud, parity stop bits, flow control (possibly), etc.
Once you know what one side of the cable is doing, then one can proceed to the other device. Divide and conquer.
<snip>
On Thu, 2009-02-26 at 16:55 +0000, Anne Wilson wrote:
On Thursday 26 February 2009 13:37, William L. Maltby wrote:
<snip>
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices.
I believe you are right. I remember those - and the 25-9-pin adapter :-). Peering around the back in a dark corner, I could well have been mistaken. OK - female socket, so that's a COM port, I think.
To be politically correct and eliminate ambiguity, we'll change the terms here. Socket (formerly female connector) on the computer s/b a parallel printer port. Almost always a 25 pin in the past, but I've not kept up with that stuff over the years.
Plug (formerly male connector) on the computer s/b serial ports.
On the cable, this is reversed, of course. Now if the cable has RS-232 on both ends and is not a fully symmetrical null modem cable, it will make a difference which end is connected to what. Make sure your cable socket end is what's hooked to the computer. Often the cables will be labeled which end goes to computer or device.
Sometimes cables have the same gender on both ends. If they've done that you could just have the cable reversed (presuming it's one of the asymmetric cables). It's not uncommon for a null to be made by jumpering certain pins on just one side of the cable and crossing 2 and 3 end to end.
Now I'm really confused. The BIOS definitely only shows one COM port. To be
Ouch! Since I've not kept up with this stuff I can't sat if there are other new devices which use 16550 serial drivers. _But_, there are definitely 2 ports as the detection routines must write to the ports and read status to determine if it's a 16450, 16550 and revision A or not (the original 16550 had insufficient buffer IIRC and the A had to be issued to prevent overflow at higher speeds. CPUs "back in the day" were just to slow to handle the interrupts quickly enough).
My guess is that your BIOS has a "menu" in the legacy devices area that has a drop-down or scrollable menu to select which port to configure. In there you can enable/disable, change default I/O and IRQ settings, etc. I think you'll find a second port defined.
Which raises the possibility of the computer's connector being on ttyS1 instead of 0. But I suspect if you check the back of the computer you might see two plug connectors. These should be the serial ports. In today's world, probably 9 pin.
honest, I can't remember whether I connected it or not. I guess I ought to open the box and see what's what, but not today - it's already too late to do that.
Where's your dedication?! Where's your glass of wine?! Not at the same location?! Time to leave I guess! :-)
But wait until you have things working - I suspect you have _two_ ports (probably 1 9 pin and 1 25 pin). A second port of 25 pins might easily be mistaken for a printer port. Long ago a switch from Centronics style to RS-232 style began to become the "standard". Physically, it looks the same as a serial port, the visual difference being the "gender" of the connector will be opposite.
Feb 26 12:12:25 borg2 kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Is this what I'm looking for? I don't see anything else.
Yes. That means that all is as expected (i.e. as _I_ expect).
Also, Minicom is _easy_ to use and understand. Give it a try. Even the man pages are not difficult.
Easy when you know how, eh? :-) I did try it. I changed it to monitor /dev/ttyS0. Apart from that, I hadn't a clue what to do. I did look at the man page, too, but not knowing what I was looking for didn't help.
I haven't used it for a _long_ time, but IIRC there is an interactive menu system that works with some keystroke, maybe <ESC> key.
Ctrl-A Z - yes, I found that.
In one of the menus from there, IIRC, you can set baud rate, parity, flow control, etc. BTW, someone mentioned UPS. Really dumb ones don't send anything except a power loss or battery low indication. Old ones used to do this just be controlling DTR (IIRC) and you couldn't "see" anything until it was raised. I don't know the details of yours (if it is a UPS) but there should be some docs or a CD that describes a minimal amount of that information. Or maybe they expect WinBlows and just put that information in a help menu.
BTW, someone mentioned RS-232C. That's the cable and electrical specifications. RS-232D is the connector specifications for a "D" shell connector. They don _not_ conflict. They are just different parts of the same overall specification. So you need have no confusion if you see us reference the seemingly conflicting specifications.
Look for that stuff in the man pages and it should be clear sailing.
First, have you set the baud rate correctly? A lot of things used to default to 9600, but 38400 became common later on. Do the docs for the unit specify? If so, use the stty command, or in minicom or other terminal emulator it's method, to set the baud rate to that needed. Usually these days, no parity check is done so 8 bit characters should be OK.
Now, since the port is recognized the failure has to be from the port onward. If the RS-232 9 or 25 pin shell is connected via a cable to the main board, make sure that the cable connector is connected to the right header on the main board. Since Linux reported two ports, there should be two headers on the main board (_if_ that's the method - some ma inboards have them mounted directly on the main board). If the header/connector is not keyed, it may be connected backwards. If you have two RS-232D shells (9 or 25 pin) you may be connecting your cable to the wrong one.
I'll check all that out tomorrow. I only have a supplied cable for 9 pin, so if everything else checks out I'll just have to try changing settings to ttyS1 and see if that helps.
Moving on, have you been able to verify the cable is good? If you have an RS-232 patch device with LED's, you can see activity (DTR, DCD, etc.) by hooking the cable to it. If you don't have one of those, a digital multi-meter can be used to see if you have expected voltages on certain pins (+/- 12 volts, IIRC). If you don't have one of those, a plain old dumb terminal can be hooked up and settings changed in a trial and error method.
I'm not handy with a multimeter, but if I have to, I'll give it a try :-)
Since they supplied the cable, is it new enough to assume that it is not damaged? If so, I suspect something easy like baud rate.
Brand new. I know anything's possible, but I'd put a bad cable very low on the list of likelihoods.
Settings at present:
A Serial Device : /dev/ttyS0 B Lockfile Location : /var/lock C Callin Program : D Callout Program : E Bps/Par/Bits : 38400 8N1 F Hardware Flow Control : Yes G Software Flow Control : No
Hardware flow control is suspect _if_ the device doesn't allow flow until some event is seen, e.g. DTR or DCD and/or some information from the device is ready to be transmitted. This could make it look like nothing is working. But that really depends on how the device is supposed to behave.
Unless the device can send large amounts of data or requires flow control, you might try disabling it.
All this is as set up in nut. Liebert do supply 'Multilink' software, but in theory nut installs the latest Liebert Multilink drivers. I'm seriously wondering whether I should remove nut and install the supplied software. However, I realise that I need to check the hardware situation first. Hopefully that will be done tomorrow.
Anne
<snip sig stuff>
HTH
On Thursday 26 February 2009 18:55:22 William L. Maltby wrote:
On Thu, 2009-02-26 at 16:55 +0000, Anne Wilson wrote:
On Thursday 26 February 2009 13:37, William L. Maltby wrote:
<snip>
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices.
I believe you are right. I remember those - and the 25-9-pin adapter :-). Peering around the back in a dark corner, I could well have been mistaken. OK - female socket, so that's a COM port, I think.
To be politically correct and eliminate ambiguity, we'll change the terms here. Socket (formerly female connector) on the computer s/b a parallel printer port. Almost always a 25 pin in the past, but I've not kept up with that stuff over the years.
Plug (formerly male connector) on the computer s/b serial ports.
On the cable, this is reversed, of course. Now if the cable has RS-232 on both ends and is not a fully symmetrical null modem cable, it will make a difference which end is connected to what. Make sure your cable socket end is what's hooked to the computer. Often the cables will be labeled which end goes to computer or device.
Sometimes cables have the same gender on both ends. If they've done that you could just have the cable reversed (presuming it's one of the asymmetric cables). It's not uncommon for a null to be made by jumpering certain pins on just one side of the cable and crossing 2 and 3 end to end.
Now I'm really confused. The BIOS definitely only shows one COM port. To be
Ouch! Since I've not kept up with this stuff I can't sat if there are other new devices which use 16550 serial drivers. _But_, there are definitely 2 ports as the detection routines must write to the ports and read status to determine if it's a 16450, 16550 and revision A or not (the original 16550 had insufficient buffer IIRC and the A had to be issued to prevent overflow at higher speeds. CPUs "back in the day" were just to slow to handle the interrupts quickly enough).
My guess is that your BIOS has a "menu" in the legacy devices area that has a drop-down or scrollable menu to select which port to configure. In there you can enable/disable, change default I/O and IRQ settings, etc. I think you'll find a second port defined.
OK - so far I've had to do this in short spells, which is definitely not the most productive. Hopefully tomorrow I'll get a good long spell when I can check out manuals both for the motherboard and the UPS.
Which raises the possibility of the computer's connector being on ttyS1 instead of 0.
I can change the config files and try those, too.
But I suspect if you check the back of the computer you might see two plug connectors. These should be the serial ports. In today's world, probably 9 pin.
honest, I can't remember whether I connected it or not. I guess I ought to open the box and see what's what, but not today - it's already too late to do that.
Where's your dedication?! Where's your glass of wine?! Not at the same location?! Time to leave I guess! :-)
Oddly enough my husband can get quite tetchy if I spend more than 12 hours a day with a computer :-)
Feb 26 12:12:25 borg2 kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Is this what I'm looking for? I don't see anything else.
Yes. That means that all is as expected (i.e. as _I_ expect).
Ctrl-A Z - yes, I found that.
In one of the menus from there, IIRC, you can set baud rate, parity, flow control, etc. BTW, someone mentioned UPS. Really dumb ones don't send anything except a power loss or battery low indication. Old ones used to do this just be controlling DTR (IIRC) and you couldn't "see" anything until it was raised. I don't know the details of yours (if it is a UPS) but there should be some docs or a CD that describes a minimal amount of that information. Or maybe they expect WinBlows and just put that information in a help menu.
In the 'User Manual' that comes with it there is no such info, as far as I can see. There's a 120-page manual on the CD. I'll examine that tomorrow. However, at a glance, it seems to expect you to set things up with its own gui software. Since there is a Linux setup section, I'm guessing that it runs in a browser. Again, I'll give it my attention in the morning.
BTW, someone mentioned RS-232C. That's the cable and electrical specifications. RS-232D is the connector specifications for a "D" shell connector. They don _not_ conflict. They are just different parts of the same overall specification. So you need have no confusion if you see us reference the seemingly conflicting specifications.
Being only moderately geeky, I just think of RS-232 as serial connection - I don't know the details :-)
Settings at present:
A Serial Device : /dev/ttyS0 B Lockfile Location : /var/lock C Callin Program : D Callout Program : E Bps/Par/Bits : 38400 8N1 F Hardware Flow Control : Yes G Software Flow Control : No
Hardware flow control is suspect _if_ the device doesn't allow flow until some event is seen, e.g. DTR or DCD and/or some information from the device is ready to be transmitted. This could make it look like nothing is working. But that really depends on how the device is supposed to behave.
Unless the device can send large amounts of data or requires flow control, you might try disabling it.
OK - I'll look at that, too.
I'm not often beaten by things, but sometimes I have to fight them on and off for quite a while before they are resolved. I'm grateful for all the help I'm getting here. I shan't be giving up for a good while yet :-) if at all.
Anne
On Thu, Feb 26, 2009 at 2:16 PM, Anne Wilson cannewilson@googlemail.com wrote:
On Thursday 26 February 2009 18:55:22 William L. Maltby wrote:
On Thu, 2009-02-26 at 16:55 +0000, Anne Wilson wrote:
On Thursday 26 February 2009 13:37, William L. Maltby wrote:
<snip> > > Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = > > 4) is a 16550A > > Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = > > 3) is a 16550A
<snip>
Oddly enough my husband can get quite tetchy if I spend more than 12 hours a day with a computer :-)
Feb 26 12:12:25 borg2 kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
BTW, someone mentioned RS-232C.
That was me (Lanny).
That's the cable and electrical
specifications.
A Serial Device : /dev/ttyS0 B Lockfile Location : /var/lock C Callin Program : D Callout Program : E Bps/Par/Bits : 38400 8N1 F Hardware Flow Control : Yes G Software Flow Control : No
Hardware flow control is suspect _if_ the device doesn't allow flow until some event is seen, e.g. DTR or DCD and/or some information from the device is ready to be transmitted. This could make it look like nothing is working. But that really depends on how the device is supposed to behave.
However, as I recall, if it works properly, it is always preferable to use HW Flow Control and not SW Flow Control. Let the HW do the work, if possible. (motto of how many SW Engineers?)
Anne: I suggest you check out the SW that is available for that UPS! After I got home awhile ago, I took at look at the SW Download page for the 3 off brand (made in Bogota, Colombia) Line Interactive UPS we bought a few weeks ago. Here is the URL:
http://www.ups-software-download.com/winpower.htm
As you can see, their SW is available for a variety of OS, including Linux (although not an .RPM). I am willing to bet the SW for your UPS is also available for Linux. Check it out! (BTW, I have no idea what language some of the stuff on that page is in. It is not Spanish....
<snip>
(BTW, I have no idea what
language some of the stuff on that page is in. It is not Spanish....
Kinda looks like Italian, or Portuguese. Maybe online translated if the syntax or usage looks wierd.
On 2/26/09, Scott Silva ssilva@sgvwater.com wrote:
<snip> (BTW, I have no idea what > language some of the stuff on that page is in. It is not Spanish....
Kinda looks like Italian, or Portuguese. Maybe online translated if the syntax or usage looks wierd.
I agree with that. Italian or Portuguese.
I am very curious now. I am going to get the Serial cable that came with the Nicomar Electronics (Bogota, Colombia) UPS we bought a few weeks ago, hook the UPS up to my box and try that SW. First in M$ Windows and then in Linux.
If Anne's UPS didn't come with SW (or it's not downloadable) I would be very surprised. She should not need to reinvent the wheel. The idea of having the UPS shutdown the box, if the box is unattended, is very nice. :-)
On 2/26/09, Lanny Marcus lmmailinglists@gmail.com wrote: <snip>
I am very curious now. I am going to get the Serial cable that came with the Nicomar Electronics (Bogota, Colombia) UPS we bought a few weeks ago, hook the UPS up to my box and try that SW. First in M$ Windows and then in Linux.
Monitoring SW is working in M$ Windows. Now, I need to read their documentation. :-) 33% load with this box and monitor. One graphic in their Quick Reference guide I couldn't find, but frequently the SW doesn't match the documentation. All of the UPS I have purchased over the years have the capability, but this is the first one I've hooked up.
I use CentOS 98% of the time and will try to install their Linux SW over the weekend.
If Anne's UPS didn't come with SW (or it's not downloadable) I would be very surprised. She should not need to reinvent the wheel. The idea of having the UPS shutdown the box, if the box is unattended, is very nice. :-)
Anne: I think if your UPS doesn't have SW in the box it came in, or available for Download, you should consider taking it back and exchanging for a UPS that does. They should have it available for Linux and other OS. Lanny
On Thu, Feb 26, 2009 at 15:30, Scott Silva ssilva@sgvwater.com wrote:
http://www.ups-software-download.com/winpower.htm (BTW, I have no idea what language some of the stuff on that page is in. It is not Spanish....
Kinda looks like Italian, or Portuguese.
It's Italian (at least, definitely not Portuguese).
Filipe
Italiano
On Thu, Feb 26, 2009 at 6:49 PM, Filipe Brandenburger filbranden@gmail.comwrote:
On Thu, Feb 26, 2009 at 15:30, Scott Silva ssilva@sgvwater.com wrote:
http://www.ups-software-download.com/winpower.htm (BTW, I have no idea what language some of the stuff on that page is in. It is not Spanish....
Kinda looks like Italian, or Portuguese.
It's Italian (at least, definitely not Portuguese).
Filipe _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thursday 26 February 2009 20:09:46 Lanny Marcus wrote:
http://www.ups-software-download.com/winpower.htm
As you can see, their SW is available for a variety of OS, including Linux (although not an .RPM). I am willing to bet the SW for your UPS is also available for Linux. Check it out! (BTW, I have no idea what language some of the stuff on that page is in. It is not Spanish....
There is supplied software for linux on the disk. If I can be sure that I've got the COM port right I'm tempted to install that instead of nut.
Anne
On Thu, 2009-02-26 at 20:36 +0000, Anne Wilson wrote:
On Thursday 26 February 2009 20:09:46 Lanny Marcus wrote:
http://www.ups-software-download.com/winpower.htm
As you can see, their SW is available for a variety of OS, including Linux (although not an .RPM). I am willing to bet the SW for your UPS is also available for Linux. Check it out! (BTW, I have no idea what language some of the stuff on that page is in. It is not Spanish....
There is supplied software for linux on the disk. If I can be sure that I've got the COM port right I'm tempted to install that instead of nut.
---- make sure that you've stopped any services and removed any apc software that might claim the port and lock anything else out.
I would probably use nut if at all possible.
Craig
On Thursday 26 February 2009 20:45, Craig White wrote:
make sure that you've stopped any services and removed any apc software that might claim the port and lock anything else out.
Yes, I uninstalled apcupsd. I checked system-config-services and made sure that I knew what everything is. I've rebooted a couple of times to check BIOS settings, so there should be nothing left over.
I would probably use nut if at all possible.
Nut is what I've been trying to work with for the last week, but no success so far. I'll spend a little more time with that this morning, but if I get no further I will try the supplied software (after I've browsed the manual to see whether I can spot any snags).
Anne
Anne Wilson wrote:
I'm not often beaten by things, but sometimes I have to fight them on and off for quite a while before they are resolved. I'm grateful for all the help I'm getting here. I shan't be giving up for a good while yet :-) if at all.
Anne
RS232C is enough to kick anyone's butt. For openers, the RS232C "standard" has been bent more ways than any other so-called standard I've ever worked with. I would never attack a situation such as you have (nothing given, find everything and prove 3 ways) without a breakout box. Lacking one of those, you might find the statserial program to be of some use in figuring out what the control lines are doing. # yum --enablerepo=dag install statserial will install it. It has a short man page. Run with no options except device ( # statserial /dev/ttyS0 ) will cause it to loop, indicating status of all control signals. You can manually tweak any of the pins with direction of "in" with a 9-volt battery or by using a paper-clip jumper from one of the "out" lines. It won't be long before you can identify the port, moving an "unknown" to "found".
Good luck!
On Thursday 26 February 2009 20:29:01 Robert wrote:
Anne Wilson wrote:
I'm not often beaten by things, but sometimes I have to fight them on and off for quite a while before they are resolved. I'm grateful for all the help I'm getting here. I shan't be giving up for a good while yet :-) if at all.
Anne
RS232C is enough to kick anyone's butt. For openers, the RS232C "standard" has been bent more ways than any other so-called standard I've ever worked with. I would never attack a situation such as you have (nothing given, find everything and prove 3 ways) without a breakout box. Lacking one of those, you might find the statserial program to be of some use in figuring out what the control lines are doing. # yum --enablerepo=dag install statserial will install it. It has a short man page. Run with no options except device ( # statserial /dev/ttyS0 ) will cause it to loop, indicating status of all control signals. You can manually tweak any of the pins with direction of "in" with a 9-volt battery or by using a paper-clip jumper from one of the "out" lines. It won't be long before you can identify the port, moving an "unknown" to "found".
I never bargained for getting in this deep :-)
Anne
On Thu, 2009-02-26 at 14:29 -0600, Robert wrote:
<snip>
breakout box. Lacking one of those, you might find the statserial program to be of some use in figuring out what the control lines are doing. # yum --enablerepo=dag install statserial will install it. It has a short man page. Run with no options except device ( # statserial /dev/ttyS0 ) will cause it to loop, indicating status of all control signals. You can manually tweak any of the pins with direction of "in" with a 9-volt battery or by using a paper-clip
IIRC (very iffy) +/- 12 volts is needed.
jumper from one of the "out" lines. It won't be long before you can identify the port, moving an "unknown" to "found".
There are pins designated to _provide_ the correct voltage full time (on 25 pin units - unsure about 9 pin). The google will get a specification of which they are - I can't remember.
Good luck!
<snip>
William L. Maltby wrote:
On Thu, 2009-02-26 at 14:29 -0600, Robert wrote:
<snip>
breakout box. Lacking one of those, you might find the statserial program to be of some use in figuring out what the control lines are doing. # yum --enablerepo=dag install statserial will install it. It has a short man page. Run with no options except device ( # statserial /dev/ttyS0 ) will cause it to loop, indicating status of all control signals. You can manually tweak any of the pins with direction of "in" with a 9-volt battery or by using a paper-clip
IIRC (very iffy) +/- 12 volts is needed.
jumper from one of the "out" lines. It won't be long before you can identify the port, moving an "unknown" to "found".
There are pins designated to _provide_ the correct voltage full time (on 25 pin units - unsure about 9 pin). The google will get a specification of which they are - I can't remember.
The RS-232C (un) standard specifies +5vdc to +25vdc as a "space" on data lines and a "true" on control lines; -5vdc to -25vdc as "mark" and "false". -5 to +5 is undefined ---BUT--- how many times have I seen the damn things operated using ttl levels. DTR (pin 4 of 9 or pin 20 of 25) should be a logical 1 if the port has been initialized.
On Thursday 26 February 2009 16:55:16 Anne Wilson wrote:
However, I realise that I need to check the hardware situation first.
Since I wrote that I've remembered that up to a couple of weeks ago an APC unit was connected to that serial port, and communicated correctly. That's one more piece of the jigsaw confirmed.
Anne
on 2-26-2009 8:55 AM Anne Wilson spake the following:
On Thursday 26 February 2009 13:37, William L. Maltby wrote:
Look in your /var/log/messages file. At boot, you should see the device recognized.
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices.
I believe you are right. I remember those - and the 25-9-pin adapter :-). Peering around the back in a dark corner, I could well have been mistaken. OK - female socket, so that's a COM port, I think.
Now I'm really confused. The BIOS definitely only shows one COM port. To be honest, I can't remember whether I connected it or not. I guess I ought to open the box and see what's what, but not today - it's already too late to do that.
Is there an internal modem? It might account for a second serial port.
On Thursday 26 February 2009 19:50:16 Scott Silva wrote:
on 2-26-2009 8:55 AM Anne Wilson spake the following:
On Thursday 26 February 2009 13:37, William L. Maltby wrote:
Look in your /var/log/messages file. At boot, you should see the device recognized.
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices.
I believe you are right. I remember those - and the 25-9-pin adapter :-). Peering around the back in a dark corner, I could well have been mistaken. OK - female socket, so that's a COM port, I think.
Now I'm really confused. The BIOS definitely only shows one COM port. To be honest, I can't remember whether I connected it or not. I guess I ought to open the box and see what's what, but not today - it's already too late to do that.
Is there an internal modem? It might account for a second serial port.
No. It's a fairly standard motherboard build
Anne
On Thursday 26 February 2009 13:37:00 William L. Maltby wrote:
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices. But wait until you have things working - I suspect you have _two_ ports (probably 1 9 pin and 1 25 pin). A second port of 25 pins might easily be mistaken for a printer port. Long ago a switch from Centronics style to RS-232 style began to become the "standard". Physically, it looks the same as a serial port, the visual difference being the "gender" of the connector will be opposite.
Just to update you on this. I checked the motherboard manual, and it clearly says there is one serial port and one parallel port. Strange that /var/log/messages seemed to report two, isn't it?
Anne
On Fri, 2009-02-27 at 14:51 +0000, Anne Wilson wrote:
On Thursday 26 February 2009 13:37:00 William L. Maltby wrote:
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices. But wait until you have things working - I suspect you have _two_ ports (probably 1 9 pin and 1 25 pin). A second port of 25 pins might easily be mistaken for a printer port. Long ago a switch from Centronics style to RS-232 style began to become the "standard". Physically, it looks the same as a serial port, the visual difference being the "gender" of the connector will be opposite.
Just to update you on this. I checked the motherboard manual, and it clearly says there is one serial port and one parallel port. Strange that /var/log/messages seemed to report two, isn't it?
Ummm .... maybe. In my experience docs are often not updated when a minor design change is made to hardware. But there is another possibility ...
What chip set on the mobo? Many chip sets include dual 16550A support and the mobo manufacturer, to save a penny or two or space or ease circuit trace design, might only provide a pin-out for a single port.
A review of the chip set specifications might confirm this. Then a visual inspection of the mobo, or a look at the layout in the manual (if you can rely on that at all) might confirm.
Hardly seems worthwhile unless you foresee a need for a second serial port in the future.
Anne
<snip sig stuff>
On Fri, Feb 27, 2009 at 10:18:34AM -0500, William L. Maltby wrote:
On Fri, 2009-02-27 at 14:51 +0000, Anne Wilson wrote:
On Thursday 26 February 2009 13:37:00 William L. Maltby wrote:
Feb 26 12:12:25 borg2 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Feb 26 12:12:25 borg2 kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Didn't you say there was only one port? There might be a second on the main board that is accessible via a header. If it's not hooked up disable all but the first in the BIOS (later). It's not really hurting anything as is, but it will free the I/O address and IRQ for assignment to other devices. But wait until you have things working - I suspect you have _two_ ports (probably 1 9 pin and 1 25 pin). A second port of 25 pins might easily be mistaken for a printer port. Long ago a switch from Centronics style to RS-232 style began to become the "standard". Physically, it looks the same as a serial port, the visual difference being the "gender" of the connector will be opposite.
Just to update you on this. I checked the motherboard manual, and it clearly says there is one serial port and one parallel port. Strange that /var/log/messages seemed to report two, isn't it?
Ummm .... maybe. In my experience docs are often not updated when a minor design change is made to hardware. But there is another possibility ...
What chip set on the mobo? Many chip sets include dual 16550A support and the mobo manufacturer, to save a penny or two or space or ease circuit trace design, might only provide a pin-out for a single port.
A review of the chip set specifications might confirm this. Then a visual inspection of the mobo, or a look at the layout in the manual (if you can rely on that at all) might confirm.
Hardly seems worthwhile unless you foresee a need for a second serial port in the future.
And some of t hose boards have a set of pins/header on the board and a little "slot fillter" thingy with a 9 pin serial socket on it and a small ribbon cable to plug into that header, which will then provide access to the second serial port. I've seen a lot of ASUS boards like that. wouldn't surpirse me if other vendors to it, too. probably saves board design complexity and maybe a few hundredths of a penny per board. :)
fred smith wrote:
And some of t hose boards have a set of pins/header on the board and a little "slot fillter" thingy with a 9 pin serial socket on it and a small ribbon cable to plug into that header, which will then provide access to the second serial port. I've seen a lot of ASUS boards like that. wouldn't surpirse me if other vendors to it, too. probably saves board design complexity and maybe a few hundredths of a penny per board. :)
and, many of the -newest- boards have no serial (or parallel) at all, not even a header. COM ports are a legacy ISA device, and they are removing the ISA stub entirely (the other remaining use of which was the floppy controller, which also is left off these newest boards). when you get rid of this stuff, you get rid of the ancient 8257 ISA DMA controller emulation.
my newest PC build, I needed serial for a weather station, an older cell phone, and a older GPS... so rather than mess with USB serial dongles, I got a $17 4 port PCI-E serial controller, which actually looksl ike 16550 UARTs to the host. works great. was branded Sabrent, I think, that or Syba.
On Thursday 26 February 2009 11:14:06 Phil Schaffner wrote:
On Thu, 2009-02-26 at 10:17 +0000, Anne Wilson wrote:
I recently bought a new UPS, and I'm attempting to use nut to monitor it. Following setup instructions everything seemed to go well until it came to testing the connection, which failed.
There is just one serial connector on the computer, so I set it to monitor /dev/ttyS0. Either that is wrong, or communication is failing. I've been told to try minicom to monitor it, but I'm not familiar with minicom (or any similar app), so again, I may be wrong in the way I'm trying to use that. I was told that unconnecting the device, then re-connecting it should give me a raft of output to the terminal - I saw nothing.
Could someone please give me idiot-level instructions on how to tell whether I'm connecting to the correct port, or whatever other information I need?
Anne,
Are you sure the cable is correct? I recall in the past having trouble with an APC UPS that required an oddball RS-232 serial cable before it would communicate. There were different variants available and only one would work. Posting details of the brand/model of UPS involved might get better help.
It's a Liebert Personal XT 700. The cable is supplied with the unit.
Anne
Anne Wilson wrote:
It's a Liebert Personal XT 700. The cable is supplied with the unit.
According to the NUT docs this UPS is supported by the usb driver, are you connecting the USB cable with it or using a serial cable?
http://eu1.networkupstools.org/compat/stable.html
Getting USB UPSs to work with NUT can be tricky as well, at least for me I typically have to force NUT to run as root otherwise it can't talk to the UPS.
What are you doing to test the connection? Have you tried running the NUT daemons in debug mode to see what they are doing(i.e. not running it using the init script).
The driver specified by the NUT docs for your UPS is the same one I had to use for one of my APC UPSs which is USB based.
nate
On Thursday 26 February 2009 17:20:50 nate wrote:
Anne Wilson wrote:
It's a Liebert Personal XT 700. The cable is supplied with the unit.
According to the NUT docs this UPS is supported by the usb driver, are you connecting the USB cable with it or using a serial cable?
The docs that come with nut say that you can use either serial or usb.
Getting USB UPSs to work with NUT can be tricky as well, at least for me I typically have to force NUT to run as root otherwise it can't talk to the UPS.
I'm not at the server at the moment, but I did follow the instructions that came with the package very closely.
What are you doing to test the connection? Have you tried running the NUT daemons in debug mode to see what they are doing(i.e. not running it using the init script).
As in the instructions, I ran ' /usr/local/ups/sbin/upsd' - which should have returned the info that it was connected. It also goes on to say that 'upsd prints dots while it waits for the driver to respond'. This didn't happen. All I got was
/usr/local/ups/sbin/upsd Network UPS Tools upsd 2.4.1 not listening on 192.168.0.95 port 3493
The last line is not a problem, as that address is this laptop, which was configured to access the software when necessary, but was not running at that moment. Just in case I was worrying for nothing, I tried the next command (as root):
/usr/local/ups/bin/upsc borg2Liebert@borg2 ups.status Error: Connection failure: Connection refused
The driver specified by the NUT docs for your UPS is the same one I had to use for one of my APC UPSs which is USB based.
After going through all this again to explain for you, that has made me think that I should check ownership etc again in the morning, and try the commands again as 'nut' rather than as root. It's making me think of when I set amanda up, and the commands always had to be run as amanda. It has to be worth a try.
Anne
Anne Wilson wrote:
As in the instructions, I ran ' /usr/local/ups/sbin/upsd' - which should have
I think upsdrvctl is what you want to try, or try calling the driver directly, e.g.
tux:~# /lib/nut/apcsmart -D -a primary Network UPS Tools (version 2.0.4) - APC Smart protocol driver Driver version 1.99.8, command table version 2.0 debug level is '1' Attempting firmware lookup APC - Attempting to find command set APC - Parsing out command set protocol_verify: 0x56 [V] unrecognized APC - About to get capabilities string Supported capability: 75 (D) - input.transfer.high Supported capability: 6c (D) - input.transfer.low Supported capability: 65 (4) - battery.charge.restart Supported capability: 6f (D) - output.voltage.target.battery Supported capability: 73 (4) - input.sensitivity Supported capability: 71 (4) - battery.runtime.low Supported capability: 70 (4) - ups.delay.shutdown Supported capability: 6b (4) - battery.alarm.threshold Supported capability: 72 (4) - ups.delay.start Supported capability: 45 (4) - ups.test.interval APC - UPS capabilities determined Detected SMART-UPS 1400 [QS9946222867] on /dev/ttyUSB0
(the above UPS is connected via serial cable to a USB->serial converter)
nate
Anne Wilson wrote:
The docs that come with nut say that you can use either serial or usb.
I certainly could be wrong but I would not expect the USB driver to work over a serial port. Though the serial driver could work over a USB->serial adapter as in my case, since the USB stuff is totally abstracted by the dongle.
So if your using the serial port try to use a driver that is not specifically targeted at usb use.
I didn't notice any other drivers for your UPS other than the USB one, you should try the usb port on the thing, and see what happens(run NUT as root if you can't get it working to see if that helps, need to change the init script to do it).
nate
On Thursday 26 February 2009 21:49, nate wrote:
Anne Wilson wrote:
The docs that come with nut say that you can use either serial or usb.
I certainly could be wrong but I would not expect the USB driver to work over a serial port. Though the serial driver could work over a USB->serial adapter as in my case, since the USB stuff is totally abstracted by the dongle.
So if your using the serial port try to use a driver that is not specifically targeted at usb use.
I didn't notice any other drivers for your UPS other than the USB one, you should try the usb port on the thing, and see what happens(run NUT as root if you can't get it working to see if that helps, need to change the init script to do it).
The install instructions give clear sections and details for usb or serial connection. I'm confident that I followed the correct section.
Anne
From: Anne Wilson cannewilson@googlemail.com
I recently bought a new UPS, and I'm attempting to use nut to monitor it. Following setup instructions everything seemed to go well until it came to testing the connection, which failed. There is just one serial connector on the computer, so I set it to monitor /dev/ttyS0. Either that is wrong, or communication is failing. I've been told to try minicom to monitor it, but I'm not familiar with minicom (or any similar app), so again, I may be wrong in the way I'm trying to use that. I was told that unconnecting the device, then re-connecting it should give me a raft of output to the terminal - I saw nothing. Could someone please give me idiot-level instructions on how to tell whether I'm connecting to the correct port, or whatever other information I need?
Maybe have a look at the setserial command, if you need to set/get serial parameters...
JD
On Thu, Feb 26, 2009 at 5:17 AM, Anne Wilson cannewilson@googlemail.com wrote:
I recently bought a new UPS, and I'm attempting to use nut to monitor it. Following setup instructions everything seemed to go well until it came to testing the connection, which failed.
<snip> Possibly something on one of these URLs will help you;
http://www.networkupstools.org/
http://tldp.org/HOWTO/html_single/UPS-HOWTO/#AEN187
You are trying to use nut and it is failing. Have you tried to use something else, to verify the connection is working OK?
On Friday 27 February 2009 00:17, Lanny Marcus wrote:
On Thu, Feb 26, 2009 at 5:17 AM, Anne Wilson cannewilson@googlemail.com
wrote:
I recently bought a new UPS, and I'm attempting to use nut to monitor it. Following setup instructions everything seemed to go well until it came to testing the connection, which failed.
<snip> Possibly something on one of these URLs will help you;
http://www.networkupstools.org/
http://tldp.org/HOWTO/html_single/UPS-HOWTO/#AEN187
You are trying to use nut and it is failing. Have you tried to use something else, to verify the connection is working OK?
http://www.networkupstools.org/ has a page where it gives all the necessary config changes for a Mandriva system. Since that is very similar to any RH-based system I used that for checking. Almost everything was exactly as I had set it up. To complete the match, I added the 'allowfrom' line, and changed user from root to the designated ups user, then tried to start the service:
[root@borg2 ~]# service upsd start upsd: unrecognized service [root@borg2 ~]# service upsmon start upsmon: unrecognized service
At that point I felt utterly defeated and uninstalled nut.
The Liebert manual gives requirements for running on Linux, amounting to RHEL4 and quite low-end hardware. Installation instructions are minimal - it seems to imply that if you use Linux you know exactly what you are doing :-)
I identified the correct install file on the CD, and changed to that directory. Then:
[root@borg2 Linux]# sh ML_36_003_Linux_x86.bin Using /tmp for temporary storage. Unpacking to /tmp/ML.tar... tail: cannot open `ML_36_003_Linux_x86.bin' for reading: No such file or directory Checksumming... Unable to perform the installation. Either the distribution file is corrupt or there is insufficient free space in /tmp. This product requires free space at least 3 times the size of the distribution file in /tmp. If that much is available, please try downloading the file again. Use 'ML_36_003_Linux_x86.bin <path>' to specify an alternate temporary directory. [root@borg2 Linux]# ML_36_003_Linux_x86.bin -bash: ML_36_003_Linux_x86.bin: command not found [root@borg2 Linux]# sh ./ML_36_003_Linux_x86.bin Using /tmp for temporary storage. Unpacking to /tmp/ML.tar... Checksumming... Extracting... pwd=/tmp/ML
Please wait while the MultiLink installation starts...
./Setup install * Checking kernel version (2.4.18 or later required)... * Checking for glibc... * Checking glibc version (2.2.4 or later required)... Uncompressing JRE distribution ./bin/jvmShell install /tmp/ML ./install/install.cfg Extracting JVM files to /tmp/ML/jre /tmp/ML/jre/bin/java -cp .:/tmp/ML/lib/em.jar -Djava.compiler=NONE install.LxInstall install ./install/install.cfg /tmp Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/ML/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at sun.security.action.LoadLibraryAction.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.awt.NativeLibLoader.loadLibraries(Unknown Source) at sun.awt.DebugHelper.<clinit>(Unknown Source) at java.awt.Component.<clinit>(Unknown Source) The operation is complete.
Does this mean that I need Sun java installed? (I have java-1.6.0-openjdk.) Or is there a conflict between the installed java and what it is trying to do?
I'm not sure why everything I try to do gets so complicated, but I can only assume that I look for trouble and find it :-)
Anne
./Setup install
- Checking kernel version (2.4.18 or later required)...
- Checking for glibc...
- Checking glibc version (2.2.4 or later required)...
Uncompressing JRE distribution ./bin/jvmShell install /tmp/ML ./install/install.cfg Extracting JVM files to /tmp/ML/jre /tmp/ML/jre/bin/java -cp .:/tmp/ML/lib/em.jar -Djava.compiler=NONE install.LxInstall install ./install/install.cfg /tmp Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/ML/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory
Hi,
It looks like the installer has its own JRE that requires libXp. Just install it using. yum install libXp
Regards,
Radu
On Friday 27 February 2009 11:33:35 Radu Radutiu wrote:
./Setup install
- Checking kernel version (2.4.18 or later required)...
- Checking for glibc...
- Checking glibc version (2.2.4 or later required)...
Uncompressing JRE distribution ./bin/jvmShell install /tmp/ML ./install/install.cfg Extracting JVM files to /tmp/ML/jre /tmp/ML/jre/bin/java -cp .:/tmp/ML/lib/em.jar -Djava.compiler=NONE install.LxInstall install ./install/install.cfg /tmp Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/ML/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory
Hi,
It looks like the installer has its own JRE that requires libXp. Just install it using. yum install libXp
Thanks. That was the clue. The software installed without a problem, then the viewer started. I tried setting it to ttyS0 and to ttyS1, but ttyS1 didn't see it at all, so back to ttyS0. The only problem was that it always said that the UPS was disconnected. Finally, after a long session of trial and error and browsing the manual, I spotted a sentence that says that it cannot work if getty is running. I commented out the mingetty lines in /etc/inittab and rebooted. Now it says 'conneted'!
The only problem is that when I launch the viewer program it says 'disconnected' at first, but changes to 'connected' after a few seconds. Is this normal? Is it only the viewer that's making the connection at that time?
I'm feeling much more confident now.
Anne
-
Anne Wilson -
Craig White -
Filipe Brandenburger -
fred smith -
John Doe -
John R Pierce -
Lanny Marcus -
nate -
Néstor -
Phil Schaffner -
Radu Radutiu -
Robert -
Scott Silva -
William L. Maltby