NX-8e Communication Issues

Forgive the long post but I want to give you as much information as possible. I started with a NX-6V2 and folks on the forum indicated I could buy a NX-584e and use it to connect to my vera controller. To make a very long story short, that isn’t going to work. Interlogix told me that unit is not supported despite the fact that their documentation says it will work. He thought there were two firmwares being burned to the units and one was compatible and the other only works with the NX-8V2. None the less I returned it and bought a NX-8e to make matters more simple. There is no shortage of folks on here with that setup working.

So it came in and I got it hooked up. So now for the fun, get it working with vera. I couldn’t find the recommended cable so I found a IDC 2x5 to DB9 connector that was pinned 1-1. I cut it and pinned it according to the instructions on the physical connection post. I feel like I have it pinned correctly. I used a straight through cable and a prolific usb to serial adapter to connect to vera. I have tried pinning the cable reversing the TX-RX, CTS-RTS but that appears to be in correct for my setup as I seem to get some communication from my panel without crossing them. When I cross them on my “home-made cable” before going to the straight through DB9 extension I get no communication at all from the panel and when I hook up to vera it freeze on loading lua engine. I get failed to setup interface message in the UI.

From the alarm panel perspective I have programmed it according to the instructions on this site without any issue. Got the error as expected and rebooted the panel and the expansion module error was cleared. When I connect the cable to vera using the pinout that is documented on this site and restart luup I get an opening IO port message but it reports a failure to open the port eventually in the UI.

So I installed putty to see what was being passed from the panel. When I connect putty to the serial and use the parameters (34800 Baud,Data bits - 8, Stop bits-1, parity-None) I get output like below. It is a pulse per line about every second or so. I did the walk test and nothing. Opened doors, windows, armed the unit and I get the same output no matter what. I thought about switching to asci but figured it would just give me a pulse of a different result that means nothing to me. Another thing to note is I do have a USB hub installed to provide additional power so the panel isn’t pulling from the vera controller.

~
▒W▒▒▒~▒
▒W▒▒▒~▒5.38▒
▒W▒▒▒~▒5.38▒
▒W▒▒▒~▒5.38▒
▒W▒▒▒~▒5.38▒
▒W▒▒▒~▒5.38▒
▒W▒▒▒~▒5.38▒
▒W▒▒▒~▒5.38▒
▒W▒▒▒~▒5.38▒

So I figured out how to read the logs of vera so I could see if anything useful was happening when I restarted the LUUP engine. It appears to make a connection to the panel but I get a received failed message. Vera log pasted below. Device 98 is the Caddx plugin in vera. I installed it from the app store, not github. I read the connect tab won’t work in UI7 but I am not getting that far. I have combed through this forum and don’t know where to go from here. I also attempted to connect to DL900 software and got a message saying something that indicated it saw the alarm panel. Folks on another forum indicated that message could be because the panel type wasn’t programmed into the panel or that the DL900 software didn’t have a matching record for that panel in its database. I didn’t spend a lot of time on that though.

10 03/04/16 21:24:17.575 mg_callback /data_request stop id: 38 <0x74b74520>
31 03/04/16 21:24:17.576 AlarmManager::Run 0x8e5dc8 notified of a change entry 0xb7ea78 id 85 deleted 0 <0x77574520>
31 03/04/16 21:24:17.727 AlarmManager::Run finish callback for alarm 0xa4e230 entry 0x8f8950 type 7 id 10 param=0x941ae0 entry->when: 1457148257 time: 1457148257 tnum: 0 slow 1 duration 0 <0x76b74520>
10 03/04/16 21:24:22.150 UPnPCallbackEventHandler 4 start PIDLOG2 11838 <0x75d74520>
25 03/04/16 21:24:22.236 IOPort::Connect device 98 connecting to 127.0.0.1:3481 iodevice: 105 path /dev/ttyUSB0 <0x75f74520>
25 03/04/16 21:24:22.237 IOPort::Connect connect 1: 127.0.0.1:3481 <0x75f74520>
25 03/04/16 21:24:22.238 IOPort::Connect connect 3: 127.0.0.1:3481 m_socket_handle 18 <0x75f74520>
25 03/04/16 21:24:22.239 IOPort::Connect OK 127.0.0.1:3481 <0x75f74520>
02 03/04/16 21:24:22.243 IOPort::Run RecvFailed 0 close 18 <0x75f74520>
10 03/04/16 21:24:22.251 UPnPCallbackEventHandler 4 start PIDLOG2 11838 <0x75b74520>
10 03/04/16 21:24:22.351 UPnPCallbackEventHandler 4 start PIDLOG2 11838 <0x75d74520>
10 03/04/16 21:24:22.451 UPnPCallbackEventHandler 4 start PIDLOG2 11838 <0x75b74520>
25 03/04/16 21:24:27.246 IOPort::Connect device 98 connecting to 127.0.0.1:3481 iodevice: 105 path /dev/ttyUSB0 <0x75f74520>
25 03/04/16 21:24:27.246 IOPort::Connect connect 1: 127.0.0.1:3481 <0x75f74520>
25 03/04/16 21:24:27.248 IOPort::Connect connect 3: 127.0.0.1:3481 m_socket_handle 18 <0x75f74520>
25 03/04/16 21:24:27.249 IOPort::Connect OK 127.0.0.1:3481 <0x75f74520>
02 03/04/16 21:24:27.253 IOPort::Run RecvFailed 0 close 18 <0x75f74520>
10 03/04/16 21:24:28.000 GlobalLog: mongoose ctx2: 0x937838 s: d:11838 <0x74b74520>
31 03/04/16 21:24:29.100 AlarmManager::Run 0x8e5dc8 notified of a change entry 0xb7ea78 id 85 deleted 0 <0x77574520>
31 03/04/16 21:24:29.101 AlarmManager::Run callback for alarm 0x8e5dc8 entry 0xb7ea78 type 51 id 85 param=(nil) entry->when: 1457148269 time: 1457148269 tnum: 1 slow 0 tardy 0 <0x77574520>
24 03/04/16 21:24:29.101 ZWaveJobHandler::ServicePollLoop not polling 3 bypass 0 freq 0 listen 0 <0x77574520>

I didn’t see it anywhere in your long post ;D but to start with the basics have you changed the settings in the panel to accept serial communications?
I would have to look but there is around 3 or 4 settings that you need to turn on or set before it will allow you to communicate on the serial bus.

That’s good debugging; thanks for making such a detailed post.

I still think it’s your cable. Here’s why.

The PuTTY test shows that you’ve got the panel’s TX pin connected properly, because you are seeing what looks like correct output from the serial line. It repeats irrespective of your walk test because it is waiting for an acknowledgment for the first message it sent, and PuTTY is not obliging it. This test doesn’t guarantee that the RX pin is connected right, though it gives you a strong hint. This test also doesn’t help particularly with the flow control (CTS/RTS, DTR/DSR) connections, which the panel doesn’t use but the other (computer) end of the serial line still expects to be operating. A bidirectional test from your computer, such as by using the DL900 software, could confirm that more of the pins are connected correctly. I have never run that software so I can’t offer any advice on its use.

The Luup log you’ve captured looks a lot like a serial communication fault. The first place I would look is the four flow control pins of your connector. If those are connected wrong, or are left floating, then the serial driver in the Vera will insist to the Vera software that there is no data to move, even if the TX pin is chattering away. Also, the Linux serial driver in the Vera may have different behaviour than the Windows serial driver you tested with PuTTY, so don’t take the PuTTY test or the DL900 test as gospel.

[quote=“integlikewhoa, post:2, topic:191512”]I didn’t see it anywhere in your long post ;D but to start with the basics have you changed the settings in the panel to accept serial communications?
I would have to look but there is around 3 or 4 settings that you need to turn on or set before it will allow you to communicate on the serial bus.[/quote]

Sorry if I wasn’t clear, I did follow the instructions in this forum that told me how to program the panel through the keypad. I have confirmed those settings about 10 times. :slight_smile:

[quote=“manicfarmer, post:4, topic:191512”][quote=“integlikewhoa, post:2, topic:191512”]I didn’t see it anywhere in your long post ;D but to start with the basics have you changed the settings in the panel to accept serial communications?
I would have to look but there is around 3 or 4 settings that you need to turn on or set before it will allow you to communicate on the serial bus.[/quote]

Sorry if I wasn’t clear, I did follow the instructions in this forum that told me how to program the panel through the keypad. I have confirmed those settings about 10 times. :)[/quote]

The cable seems perfectly reasonable. I initially had the pin out incorrect because of some bad assumptions and found the default pin out on this board for a 2x10 IDC connector and corrected my cable. It was then that I finally got some communication. If I am correct the communication I am seeing in putty is coming from pin 3 on the panel wired to pin 2 on the DB9 side. I will confirm that. I remember thinking that was strange because I would expect to see communication from the panel side on pin 5. Would a loopback check tell me anything on my cord? Connecting the rx and tx wires on the cable and seeing an echo of anything I type in putty? I will see if I can find anything with the cable. Maybe I will delve a little deeper into the DL900 software. It looks like it was written in MS Access (lol, I used to be an access programmer years ago and finding a commercial software written in it is laughable) and I determined I may be having a 32/64 bit issue with the system so I gave up. Thanks for following up so quickly. Whatever I end up with, I will post my results.

We are now in the world of debugging serial connections rather than the alarm plugin (which hasn’t even begun to run by this point). It isn’t my area of expertise. I don’t have an NX8e and nor do I (any more) use a USB to Serial adapter. What follows is a brain dump of some more ideas to explore.

People have reported seating and physical contact issues with the 2x5 connector. The male pins might not be touching the metal inside the female jacks even if the plastic looks properly seated.

Serial is full duplex. Loopback testing is a good idea but it can only tell you that the TX and RX pins are connected, not that you have the flow control pins connected. Flow control is an integral part of a serial connection. I don’t believe that the alarm board pays attention to CTS, nor does it assert RTS, but the computer sure does, and having them set wrong will prevent the computer sending bytes because it thinks the alarm board’s buffer is full. Same with DTR and DSR, which will make the computer think that the “modem” has dropped carrier. Loopback testing might (should) catch flow control errors but it relies on the operating system and the application (PuTTY) honouring the protocol, which I can’t vouch for, and which Vera might have different ideas about than Windows.

Thanks so much for your input Futzle. It definitely helped me solve my issue. After reading about the cable pinning I went to the NX-8e board with a multi-tester to see what pins were producing voltage on the panel. The TX (pin 3) and the RTS (pin 8, I think if memory serves me) had voltage. Pin 3 was pulsing from about 9.63-9.67. This must be the information that was pasted above being sent from the 8e. Pin 8 was steady at 9.33V. I felt like that is exactly what the 8e should be sending. I tested all my cables and everything was fine connecting to the prolific USB adapter. Read a thread that indicated it could be a driver issue with Vera and the PL2303 so I did the dmesg pre-post test per someones post and didn’t notice the offending text indicating a bad driver in vera. Considering that folks complained about the PL2303 adapter I decided to take a shot in the dark and order an ftdi adapter since everything felt right up to this point. Voila, connected it to my cable that I felt was pinned correctly and it worked first time. No communication issues. AS mentioned in other posts, connect tab doesn’t work but that isn’t really needed as you can use the serial port config for that purpose. I do want to note that I didn’t have to use a null modem cable using the pinout on the site. I will say I haven’t figured out how to do anything in here yet but before I start asking questions I will do some research and see what I can find on my own. Thanks again for your selfless efforts supporting and writing this plugin. Great work and thanks a bunch!!!

Sincere thanks for coming back and posting your solution so that others can learn from the experience too.

(Anyone reading this later: don’t take this as an indictment on all Prolific USB-to-Serial adapters; there is so much variation in the passive electrical components in an adapter that it dwarfs something as slight as the chipset used by the adapter. For all we know, it could be that manicfarmer’s USB-to-Serial adapter had a dodgy physical connection in the DB9 end and the electronics are fine.)

RS-232 and the NX-8E. Cable. Protocol. Voltages. Pinout. Etc.