Need Help Integrating NX-8V2 Panel

bigeazy000 · July 12, 2014, 8:16pm

Hello,

I am new to the forum, and am struggling with getting an NX-8V2/NX-584 integrated with my VeraLite using the Caddx app. When I took a stab at this several months ago, I tried this and couldn’t make it work, and I assumed that it was because I tried running serial over an cat5e cable of about 75ft in length. Now, I have the Vera directly connected to the NX-584 via usb-serial using a female/female db-9 adapter. I have reversed the pins on the NX-584 as I understand by default it ships with null modem configuration. Can someone confirm this please? Also, I am using this forum as reference for programming the keypad:

http://forum.micasaverde.com/index.php/topic,14295.0.html

However, the NX-8V2 looks like it uses different locations than the NX-8E does. At one point, I thought I had figured out the corresponding locations for the NX-8V2, but I don’t have them now. Does someone know off hand which locations I need to be configuring for the NX-8V2? Any help you can offer would be much appreciated, thanks!

bigeazy000 · July 12, 2014, 9:46pm

Ok, an update. I figured out the location mapping, by reading the manual again, that’s my bad. However , I am at the same place where I was when I tried to make it work a few months ago. Here is what I am seeing in the luup debug log when I try to get it going:

50 07/12/14 14:13:56.573 luup_log:21: Initializing Caddx NX-584 LEAK this:118784 start:450560 to 0x9aa000 <0x2b6c3680>
50 07/12/14 14:13:56.577 luup_log:21: Opening serial port <0x2b6c3680>
50 07/12/14 14:13:56.578 luup_log:21: Sending message and waiting for response: 0x21 Interface Configuration Request <0x2b6c3680>
50 07/12/14 14:13:56.579 luup_log:21: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b6c3680>
50 07/12/14 14:13:58.268 luup_log:21: Received inconvenient message 0x06 LEAK this:217088 start:667648 to 0x9df000 <0x2b6c3680>
50 07/12/14 14:13:58.269 luup_log:21: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b6c3680>
50 07/12/14 14:13:58.269 luup_log:21: Sending message: 0x1D Positive Acknowledge <0x2b6c3680>
50 07/12/14 14:13:58.269 luup_log:21: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b6c3680>
50 07/12/14 14:13:58.271 luup_log:21: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b6c3680>
50 07/12/14 14:14:00.761 luup_log:21: Received inconvenient message 0x06 LEAK this:32768 start:700416 to 0x9e7000 <0x2b6c3680>
50 07/12/14 14:14:00.762 luup_log:21: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b6c3680>
50 07/12/14 14:14:00.762 luup_log:21: Sending message: 0x1D Positive Acknowledge <0x2b6c3680>
50 07/12/14 14:14:00.763 luup_log:21: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b6c3680>
50 07/12/14 14:14:00.764 luup_log:21: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b6c3680>
50 07/12/14 14:14:03.264 luup_log:21: Received inconvenient message 0x06 <0x2b6c3680>
50 07/12/14 14:14:03.265 luup_log:21: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b6c3680>
50 07/12/14 14:14:03.265 luup_log:21: Sending message: 0x1D Positive Acknowledge <0x2b6c3680>
50 07/12/14 14:14:03.266 luup_log:21: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b6c3680>
50 07/12/14 14:14:03.267 luup_log:21: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b6c3680>
50 07/12/14 14:14:05.751 luup_log:21: Received inconvenient message 0x06 <0x2b6c3680>
50 07/12/14 14:14:05.752 luup_log:21: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b6c3680>
50 07/12/14 14:14:05.752 luup_log:21: Sending message: 0x1D Positive Acknowledge <0x2b6c3680>
50 07/12/14 14:14:05.753 luup_log:21: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b6c3680>
50 07/12/14 14:14:05.754 luup_log:21: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b6c3680>
50 07/12/14 14:14:08.252 luup_log:21: Received inconvenient message 0x06 <0x2b6c3680>
50 07/12/14 14:14:08.253 luup_log:21: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b6c3680>
50 07/12/14 14:14:08.253 luup_log:21: Sending message: 0x1D Positive Acknowledge <0x2b6c3680>
50 07/12/14 14:14:08.253 luup_log:21: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b6c3680>
50 07/12/14 14:14:08.254 luup_log:21: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b6c3680>
50 07/12/14 14:14:10.753 luup_log:21: Received inconvenient message 0x06 <0x2b6c3680>
50 07/12/14 14:14:10.754 luup_log:21: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b6c3680>
50 07/12/14 14:14:10.754 luup_log:21: Sending message: 0x1D Positive Acknowledge <0x2b6c3680>
50 07/12/14 14:14:10.755 luup_log:21: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b6c3680>
50 07/12/14 14:14:10.756 luup_log:21: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b6c3680>

I have the Vera Lite directly connected to the NX-584 via pl2303 and female/female serial adapter. There is no cable involved, other than the usb/serial adapter. I have the jumpers opposite of default on the nx-584. I have tried reversing them, when I do that I get an error initializing the interface. I have also programmed the NX-584 on my NX-8V2 by doing the following:

*8
program code 9713 (this is the default and works still)
72# (this is the address for the NX-584E according to the manual)
Entered the following based on Eddie’s recommendations, except I left it at 9600 baud:

Location 0=blank (binary)
Location 1=4 (9600 baud)
Location 2, Segment 1 = 2,5,6,7,8
Location 2, Segment 2 - 1,3,4
Location 3, Segment 1 = 2,4,5,6,7,8
Location 3, Segment 2 = 1,2,3,4,5
Location 3, Segment 3 = 1,2,3,5,7
Location 3, Segment 4 = 3,4,5,6,7,8

I left location 4 as defaults. Attached is a screenshot of the serial port config. Any ideas on what I am missing? Thanks!

futzle · July 14, 2014, 10:20pm

This log output (thanks for capturing that, it’s perfect) is consistent with:

Physical connection and Vera configuration are probably good.
Bytes sent from the security system to Vera are arriving just fine.
No bytes sent from Vera are arriving at the security system.
The most common explanation for this is that your USB-to-Serial adapter isn’t getting enough power from the USB serial port to drive an RS-232 signal. The usual fix is to buy a decent externally-powered USB hub and insert that between the Vera Lite and the USB-to-Serial adapter.

(The “Inconvenient 0x06” logs are just some random status update that the security system is trying to tell you about because someone walked past a zone and tripped it. They are not part of the problem, but they helped diagnose it.)

bigeazy000 · July 15, 2014, 12:52pm

Thanks for your response and for confirming my suspicions I tired two different USB/adapters with 2 different chipsets, and saw the same ing with both. Unfortunately, there is no easy way for me to get power to that area for a powered USB hub (I was using a POE splitter to get power to the Vera) and honestly the serial/USB route seems like it’s more trouble than it’s worth. I ordered a wiznet and should have it later this week, and will give that a shot as soon as I get it.

Thanks again for your input, i will post an update one I get that in place.

bigeazy000 · July 17, 2014, 8:37pm

Well, this log looks familiar. This is the Vera talking to a wiznet that is directly connected to the nx-584e via db-9 female/female adapter. Any ideas now?

50 07/17/14 13:34:06.186 luup_log:13: Nest: plugin version 1.6 starting up… <0x2b765680>
50 07/17/14 13:34:06.590 luup_log:23: Initializing Caddx NX-584 LEAK this:266240 start:348160 to 0x10a4000 <0x2b765680>
50 07/17/14 13:34:06.590 luup_log:23: Opening socket to 172.16.0.11 port 5000 <0x2b765680>
50 07/17/14 13:34:06.691 luup_log:23: Sending message and waiting for response: 0x21 Interface Configuration Request <0x2b765680>
50 07/17/14 13:34:06.692 luup_log:23: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b765680>
50 07/17/14 13:34:07.180 luup_log:23: Received inconvenient message 0x06 <0x2b765680>
50 07/17/14 13:34:07.181 luup_log:23: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b765680>
50 07/17/14 13:34:07.181 luup_log:23: Sending message: 0x1D Positive Acknowledge <0x2b765680>
50 07/17/14 13:34:07.182 luup_log:23: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b765680>
50 07/17/14 13:34:07.183 luup_log:23: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b765680>
50 07/17/14 13:34:09.746 luup_log:23: Received inconvenient message 0x06 LEAK this:266240 start:614400 to 0x10e5000 <0x2b765680>
50 07/17/14 13:34:09.747 luup_log:23: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b765680>
50 07/17/14 13:34:09.747 luup_log:23: Sending message: 0x1D Positive Acknowledge <0x2b765680>
50 07/17/14 13:34:09.747 luup_log:23: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b765680>
50 07/17/14 13:34:09.748 luup_log:23: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b765680>
50 07/17/14 13:34:12.249 luup_log:23: Received inconvenient message 0x06 LEAK this:16384 start:630784 to 0x10e9000 <0x2b765680>
50 07/17/14 13:34:12.249 luup_log:23: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b765680>
50 07/17/14 13:34:12.249 luup_log:23: Sending message: 0x1D Positive Acknowledge <0x2b765680>
50 07/17/14 13:34:12.250 luup_log:23: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b765680>
50 07/17/14 13:34:12.251 luup_log:23: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b765680>
50 07/17/14 13:34:14.699 luup_log:23: Received inconvenient message 0x06 <0x2b765680>
50 07/17/14 13:34:14.700 luup_log:23: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b765680>
50 07/17/14 13:34:14.700 luup_log:23: Sending message: 0x1D Positive Acknowledge <0x2b765680>
50 07/17/14 13:34:14.701 luup_log:23: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b765680>
50 07/17/14 13:34:14.702 luup_log:23: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b765680>
50 07/17/14 13:34:17.235 luup_log:23: Received inconvenient message 0x06 <0x2b765680>
50 07/17/14 13:34:17.236 luup_log:23: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b765680>
50 07/17/14 13:34:17.236 luup_log:23: Sending message: 0x1D Positive Acknowledge <0x2b765680>
50 07/17/14 13:34:17.236 luup_log:23: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b765680>
50 07/17/14 13:34:17.237 luup_log:23: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b765680>
50 07/17/14 13:34:19.732 luup_log:23: Received inconvenient message 0x06 <0x2b765680>
50 07/17/14 13:34:19.732 luup_log:23: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b765680>
50 07/17/14 13:34:19.732 luup_log:23: Sending message: 0x1D Positive Acknowledge <0x2b765680>
50 07/17/14 13:34:19.733 luup_log:23: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b765680>
50 07/17/14 13:34:19.734 luup_log:23: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b765680>
50 07/17/14 13:34:22.208 luup_log:23: Received inconvenient message 0x06 <0x2b765680>
50 07/17/14 13:34:22.209 luup_log:23: Message: Unsolicited message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x80 <0x2b765680>
50 07/17/14 13:34:22.209 luup_log:23: Sending message: 0x1D Positive Acknowledge <0x2b765680>
50 07/17/14 13:34:22.210 luup_log:23: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2b765680>
50 07/17/14 13:34:22.211 luup_log:23: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x2b765680>
50 07/17/14 13:34:24.725 luup_log:23: Received inconvenient message 0x06 <0x2b765680>

futzle · July 17, 2014, 9:59pm

Darn. The symptoms are the same but the ailment must be different.

The problem has to be somewhere between the WizNet and the NX-584.

Next, if I were in your place, I’d be playing with the four jumpers on the NX-584 board. There are only 16 combinations, and only 4 of them are meaningful and don’t duplicate pin connections. The RTS-CTS serial connectors (J7 and J9) are still important because even though the NX-584 ignores them, the WizNet honours them and won’t send bytes if CTS isn’t pulled low.

Failing that: an open circuit one pin of your DB9-adapter?

Some sanity checks:

One of the LEDs on the NX-584 (DS3) flashes when it receives a valid message from the host. I bet that this LED isn’t lighting up. For me, this light blinks when I do things to the Vera plugin (such as viewing the event log).
Another LED (DS6) lights up when the NX-584 is waiting for acknowledgment from the host. I bet that this LED is always on. For me, this light blinks because messages are always acknowledged.
Another LED (DS4) lights up when the NX-584 tries to send a message to the host. I bet that this LED is flashing every 1.5 seconds. That’ll correspond to those Inconvenient Messages.

bigeazy000 · July 17, 2014, 10:26pm

You are dead on on the LEDs. I tried replacing the gender changer with a straight-through db-9 cable and got the same result. So at this point, there are only 2 options:

Something is misocnfigured on the Vera side to prevent it from sending ack packets correctly.
Something is wrong with the NX-584

I have tried many jumper combinations on the NX-584, J10 is the one in question I would think. I even tried swapping the jumpers between j7-j10 etc. with the hope that maybe it was just a bad jumper. I’m not sure if I have any jumpers around to test with, but I may try that next. It could just simply be that the board needs to be replaced, I’m thinking about RMA’ing it and trying a new one…

futzle · July 18, 2014, 12:36am

There simply isn’t a way for the plugin to opt out of sending acknowledgment messages. It’s hardcoded into the plugin code. On the Vera itself, you can turn on additional debugging on LuaUPnP to see all the bytes it is sending up the serial port. That should absolve the Vera of any fault.

Something else you can try is to take Vera out of the picture, turn the NX-584 to ASCII mode and try to communicate with it through telnet to the WizNet from a real computer. You can handcraft the bytes of an acknowledgment packet in your clipboard and paste them into the telnet session. Watch the LEDs as you do it. If it works then the NX-584 will stop repeating the same zone status message because you finally acknowledged it.

bigeazy000 · July 18, 2014, 12:42am

Now I am at a complete loss. I removed the wiznet, and plugged directly into the NX-584 with a USB/Serial adapter and laptop that I KNOW is a working combination. I am a network engineer, and I use this laptop and adapter all the time to console into devices to work on them. Anyway, I also put the NX-584 in ascii mode. When I did, I got the following code over and over:

098602280000000004803EC6
098602280000000004803EC6
098602280000000004803EC6
098602280000000004803EC6
098602280000000004803EC6
098602280000000004803EC6
098602280000000004803EC6

My goal was to send some commands to the board to see if the device would acknowledge (LED DS6). I was actually trying all kinds of things, but I tried this command many times, 0128292A. My understanding is that this should return a specific response, which is documented here:

http://www.turn-n-burn.com/DestinyNetworks/Downloads/WebHelp/Caddix_Security_Systems.htm

I got nothing, no matter what I tried. I even tried many different jumper combinations, when I moved j8, I stopped receiving the repeated code as I expected I would. But, no combination of me changing jumpers and/or entering random command resulted in any difference in the board receiving data, either on the leds or on the console. My thought at this point was that maybe it was a bad pin/contact on the nx-584, so I decided if was if that was the case, that changing back to default jumper placements, and using a null modem cable should reverse the effect. So, I tried it. Same exact result, so now I have no idea where to go. I still suspect that the board is bad. I have to believe that the connectivity between the Nx-584 and NX-8V2 is good, as it accepts commands, etc. Do you have any other ideas? At this point, maybe I will try to contact Interlogix for support as I dont know what else to try other than replacing it with a new board.

Thanks in advance for any additional ideas you can provide, and I really appreciate your assistance so far!

futzle · July 18, 2014, 1:28am

Until you send a Positive Acknowledge message back to the NX-584 to tell it you’ve seen its Zone Status message it’ll ignore anything you send it. The logs you captured from Vera show the outgoing bytes you need (011D…) for a Positive Acknowledge. That’s a more valid test than sending the Interface Configuration Request message that you quoted. Also be sure you are sending carriage returns and line feeds which are part of the ASCII protocol.

bigeazy000 · July 18, 2014, 1:44am

Ok, I can try that. I will make sure that my ASCII sessions are correct in my terminal, what exactly is the message I should send? Is it just “011D”?

futzle · July 18, 2014, 1:54am

Go and look at the log captures you posted:
0x01 0x1d 0x1e 0x1f

bigeazy000 · July 19, 2014, 10:31pm

Well, I think I executed the ascii commands correctly. I tried sending “0x7e 0x01 0x1d 0x1e 0x1f” as well as trying an individual code like “0x1d” and didnt see any response, either in the console screen, or on the LEDs. I’m stumped. Like I said earlier if it was a bad db-9 pin on the board I wouldnt expect to get anything on the screen when I switched to null modem, as that would reverse the pins. Any other ideas? If not, I guess I’m going to have to try another board…

futzle · July 19, 2014, 10:42pm

Nono, in ASCII mode you don’t send the message-start byte (0x7e), and you send the bytes as two ASCII characters each:

011D1E1F

With appropriate CRLF delimiters.

I’ve been assuming that you have the NX-584 Serial Protocol document and have been referring to it. If not, Google it.

bigeazy000 · July 19, 2014, 11:25pm

I give up. I’m not even sure what I am trying to prove anymore by doing this either. I tried using teraterm (as I know I can configure it to send CR+LF in the response), tried to send the command you posted with nothing back from the nx-584. Ive tried using 3 different usb/serial adapters, a wiznet, straight serial, null modem, a female/female adapter, a different cable between nx-8v2 and nx-584 etc. I have eliminated every possible piece of hardware as a cause except the nx-584.

To your point, it would be nice to see if it responded via an ascii command from my teraterm, but I cant make that work either. And what would it prove anyways? It still gives me the same feedback in the vera setup, regardless of which connection methods I tried. Even if I did see something magical happen when my laptop was connected to it, it still wont work with the Vera/Plugin.

I have spent many hours trying to make this work, and have gotten really frustrated in the process. I dont think you believe that it is a hardware issue with the nx-584, but what else could it be?

futzle · July 20, 2014, 12:10am

You might be right. You’ve tried at least two different ways to communicate with the NX-584 and you’ve got enough evidence that it is never seeing the messages that you send to it.

So what’s left to swap out? Apart from the NX-584 (ignore anything on the alarm panel side of it), is there any other piece of equipment that all of your tests have in common? It sounds like no.

If you’ve got the option of returning your NX-584 for another one, do it. I guess I’m just sceptical because of all the connectivity problems that I’ve helped diagnose on this forum (and they’re all here for anyone to read), yours would be the first time that the board is at fault.

If you still have the slightest suspicion that you aren’t sending the right commands up to the NX-584, and you have a Windows computer, you might try running the DL900 software on it. This is the software that installers use to configure panels. It’s absolutely sure to get the serial protocol right. (I have no personal experience with DL900 except to know that the version I tried to run under Wine crashed.)

bigeazy000 · July 20, 2014, 12:18am

I’ve read through the forums, but at this point I think I’m just the unlucky one that got the bad board. It was due to happen to someone eventually, right?

The place I bought the nx-584 from has a 12 month warranty, so I would just have to pay the cost of shipping to have it replaced so I’m going to do it. As a last ditch effort, I will try to get the DL900 software running and see if I can get anywhere with it before I send the board back.

I really appreciate your help and suggestions along the way. You’ve been very helpful!

bigeazy000 · July 24, 2014, 5:40am

UPDATE:

 I d/l'ed the DL900 software and was not able to connect to the board with it either. I received the replacement board today, and 5 minutes after opening the box, BAM! It connected the first time to the CADDX plugin. Now I just need to figure it out.

I'm sure the failure rate on these boards is really low, but that is what it was for me... Thanks again for your help along the way futzle!

futzle · July 24, 2014, 7:08am

Well, I can’t ever say again that I haven’t seen a bad NX-584 board.

Well done, and here’s hoping for a happy ending to your adventures with the plugin.