NX584E / Caddx / Networx Alarm Binding

Tags: #<Tag:0x00007f5c84b0e680> #<Tag:0x00007f5c84b0e518> #<Tag:0x00007f5c84b0e3b0>

(Bernhard Boser) #1

An openhab 2 binding for the Caddx security panel is available at:

Consult the readme for instructions on how to use.

(Paul Mancini) #2

Good stuff, @Bernhard_Boser though I have a couple of concerns. Perhaps my textual configuration is faulty. I have OpenHAB 2 on RPi2 with an NX-8E alarm panel. This has an automation serial port that is supposed to expose the same protocol as the NX-584E does.

The system status query returns accurate data, though some of my item values are inconsistent. For example, panel low battery comes back as 0 - false. You’ve implemented this as a switch with ON/OFF. When I list the items in Karaf, it shows State=ON. My panel has not reported low battery.

Byte 4 bit mask 0x40 represents low battery, yes?

07:09:13.304 [DEBUG] [ab.binding.nx584.handler.NX584Events] - received System Status Message:  0x08 0x04 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x02 0x03 0x24


Switch securityPanelLowBattery 	<yellowLED>	{ channel="nx584:security:nx8e:panel#low_battery" }


Switch item=securityPanelLowBattery label="Security Panel Low Battery"

Karaf console items list

openhab> smarthome:items list
securityPanelLowBattery (Type=SwitchItem, State=ON, Label=Security Panel Low Battery, Category=yellowLED)

(Bernhard Boser) #3

I have the same problem with battery status, perhaps a problem with the documentation. I really only use the interface for status update and ignore the rest. Sorry for not being of help.

BTW: Anyone knows if there is a way to add this to the distribution? Would avoid having to install and maintain separate jar files (and the heavy OpenHAB Eclipse development environment). Same for ISY binding which I am also using.

(Paul Mancini) #4

I believe if you submit a pull request (PR), then it will be pulled into the “distribution.” How to do that, I do not know.

(Rgerrans) #5

@Kai would be the one to reach out to

(Kai Kreuzer) #6

Correct. Make sure you have done all things mentioned here and then create a standard PR on Github (just like all these). And then please be patient as the code needs to be reviewed before it is merged and unfortunately, there is quite a long queue at the moment… But don’t take that as a signal that contributions are not welcome - they definitely are!

(Rgerrans) #7

@Bernhard_Boser Thanks for putting this together, it gets me one step closer to retiring my Vera controller.

Is there a way I can pull the current Alarm state status? I tried adding a [%s] to the Alarm Panel string but it doesn’t show any status, I also tried changing the Partition Switch to a String and pulling the #status from it as well.

(Bernhard Boser) #8

I’ll start on the pull request for the Caddx binding once the ISY binding
is part of the distribution. That one (I’m not the author) has been in the
queue for years and I do not understand why it’s in this limbo forever.


(Rgerrans) #9

@Bernhard_Boser So I looked at your code (not that I’m 100% sure of what I’m looking at) but didn’t see any #status that I could tell for the Partition but did see the #arm and #arm_stay in addition to the #ready channels. I set up three switches for ready, arm and stay but what I notice is they become mutually inclusive, re: if I’m in stay mode, the ready is on. If I set to Arm(Away), arm comes on and ready stays on. If I set to Stay, all three are on. Obviously I can write a proxy item to reflect the status but my first choice would be to have the status come from the Panel, or come from the Partition but allow me to change the status of the partition vs. having the actual status separate from how I set status.

(Bernhard Boser) #10

I do not remember the details. I have the following items:

Switch partitionReady “Ready” (gPartition, gPersist) { channel=
“nx584:security:creston:partition1#ready” }

Switch partitionArmed “Armed” (gPartition, gPersist) { channel=
“nx584:security:creston:partition1#armed” }

I’ve never used the “stay” mode. Sorry for not being helpful,


(Rgerrans) #11

I wish I had more programming experience to help. I’m about to go on the road for a week but when I get back I’ll get a copy of the Vera version to see if we can piece together the right pieces to get an integrated status / control channel. Thanks!!!

(Rgerrans) #12

So, my unlock rule didn’t seem to work.

Here is the Item definition:
String Security_Panel "Security Panel [%s]" {channel="nx584:security:caddx:panel"}

Here is the rule statement:

Which generated this error:
2017-03-27 18:09:48.704 [WARN ] [ab.binding.nx584.handler.NX584Events] - message rejected by panel

Is there something I’m missing?


(Bernhard Boser) #13

I suspect that the “disarm” feature over the serial interface can be
disabled for security reasons, and maybe that’s how yours is set up.

Here are my rules (I am not familiar with the syntax you are using, have
not kept up with openhab changes and new documentation in a while):

rule “arm”


Item nx584arm changed from OFF to ON


sendCommand(securityPanel, “arm”)


rule “disarm”


Item nx584arm changed from ON to OFF


sendCommand(securityPanel, “disarm”)


rule “clock”


Item nx584clock changed from OFF to ON


sendCommand(securityPanel, “setClock”)



(Rgerrans) #14

Thanks. I’ll take a deeper look when I get back. Through Vera I could sometimes call it to disarm w/o a pin but most time required a pin.

(Rgerrans) #15

Sure enough it was my system needing to be reprogrammed to accept arm/disarm commands w/o a pin. Thanks.

(Paul Mancini) #16

I think the you want to use your onOff method, rather than offOn for these:


You’re reporting an inverted state for each of these.

(Bernhard Boser) #17


Thanks for letting me know. I’ll update the code and git when I get around
to it - unfortunately probably not before fall …


(Rgerrans) #18

@Bernhard_Boser The binding seems to be causing some java errors and interfering with the communication in general over serial ports. I’ve noticed that almost every time I was doing an upgrade my Zwave binding couldn’t find the serial port. There for a while I could solve by clearing the cache directory but last night that wouldn’t work. I finally noticed these error files https://drive.google.com/open?id=0B77VHtwPft8eRjlWQlZ5azVBOTg being thrown off tied to the NX584 binding. Once I removed the binding and restarted my Zwave came back. I saw in your previous post you don’t have a lot of time on your hands for updates but I was hoping this is one you could take a quick look at since it’s a pretty critical one. Thanks and let me know any other files or information I can pull to help.

(Bernhard Boser) #19

I’m not observing problems and I do not know how to diagnose (or even
create) the error logs you link to.

(Rgerrans) #20

The java error files are appearing in my userdata directory, I didn’t set up anything to log them. Maybe @Kai has an idea.