NX584E / Caddx / Networx Alarm Binding

@Bernhard_Boser I’ve started noticing some errors the last few weeks in my log file:

2017-08-09 07:23:37.295 [WARN ] [b.binding.nx584.internal.panel.NX584] - receiver: fletcher error for msg len = 9:  0x86 0x00 0x20 0x00 0x00 0x40 0x42 0x00 0xc0
2017-08-09 07:23:37.299 [WARN ] [b.binding.nx584.internal.panel.NX584] - receiver: fletcher sum1 for msg type 0x06 - expected 0xf2 got 0xf2
2017-08-09 07:23:37.303 [WARN ] [b.binding.nx584.internal.panel.NX584] - receiver: fletcher sum2 for msg type 0x06 - expected 0x7e got 0x7d

Not sure if you have any ideas what might be going on? Thanks.

Indicates a communication error. The nx584 attaches a checksum at the end
of each message. In the reported cases the checksum does not agree with the
content of the message. I do not know if

  1. My code computes the checksum incorrectly.
  2. The nx584 reports and incorrect checksum.
  3. It actually is a communication error.

If you are not experiencing problems, I recommend to just ignore these
messages. I get them too, occasionally.

Bernhard

1 Like

@Bernhard_Boser Question for you. I didn’t see anything in your description to define an item to pickup the alarm going off so I can trigger a rule on that (turn on lights, notify, etc.). I tried monitoring the string from the panel:

String securityPanel "Security Panel" { channel="nx584:security:creston:panel"}

But that only reported armed / disarmed states

Did I miss it or is this not available to us?

No idea.

And I just wasted an afternoon trying to update openhab. Looks like in
addition to the new features even more new bugs …

I am not sure I will get back to this anytime soon.

Bernhard

No worries, sorry to hear about the hiccups. Have had those long days too…The fun of opensource sometimes.

I wish I had a stronger programming background and could work on the code myself. May take a look a bit today to see if I understand the structure enough to see if I can do anything with it.

Thanks and good luck getting back up and running.

No need to spend any of your time on this for my sake. I found a separate monitoring daemon (https://github.com/tjko/nxgipd)and just set it up to tie directly into mqtt for delivering statuses and using their command line program for making changes so all set to go.

Thanks again for all your work on the binding

Thanks for the link!
I was planning on switching to mqtt (to have a bit more distance from the openhab engine and the complex programming setup). This may be a good solution - preferable to coding my own!

Once I switched to Node-RED for my rules engine I made the jump to using mqtt as my backbone to give me more flexibility and have been pretty happy with it. Took some work to get all my items drfined into text files to give me more finite control of them (thank goodness for spreadsheets and concatenate…) but I’ve been happy with the outcome.

Here is the execution script that I submitted to the developer to send output to mqtt. https://github.com/tjko/nxgipd/blob/master/contrib/alarm-mqtt.sh. Let me know if you make any upgrades to it.

@Bernhard_Boser Thanks for your work on this binding. It has been working well for me. I have also had some of the warnings in the logs as mentioned above, but I haven’t noticed it affecting performance in any way. I’m using it on OH version 2.1.

@rgerrans I know you may have moved on to a different solution, but there is a lot of functionality in this binding that’s not documented in the readme. I believe what you need to access the occurrence of an alarm condition is to use panel#log in the declaration. It sends a continuous stream of many different events that could be useful. Just monitor it for “Alarm”. I have this mapped to a string as shown below.

String securityLog   "Security Log"   {channel="nx584:security:milwen:panel#log"}

If you look through the events handling file at
https://github.com/bboser/org.openhab.binding.nx584/blob/master/src/main/java/org/openhab/binding/nx584/handler/NX584Events.java you can see a full list of the log events.

Thanks. If I run into issues with my other setup I’ll take a look. If that’s the case I wouldn’t think it would be much issue to add a pull request with addional event handlers to capture the alarm events in the bnding vs parsing the log stream.

hello rgerrans,how have you connect to node red, your alarm?

I installed this daemon - https://github.com/tjko/nxgipd to feed my mqtt broker which I then pickup in Node-Red to monitor and send commands back

I have switched from the binding to the nxgipd daemon, and am using a modified version of your alarm-mqtt.sh script for output via mqtt to openHAB. Thanks for the script.

What method are you using to send commands back to the monitoring daemon? I am currently sending commands from openHAB via mqtt to the Rpi where the daemon is running. On that Rpi I have a script monitoring an mqtt channel and feeding the commands locally with nxcmd. It seems like there should be a more efficient way to do this. Ideally, I’d run the commands directly from the openHAB server on the remote nxgipd server.

Ok, thanks for the info. I have the basically the same command that you’ve shown in my script running on the local nxgipd machine. It’s embarrassing how long it took me to figure out that was what it took to pass the pin code.

I think I need the Exec binding for running commands directly on the openHAB machine. I’m just not familiar with running commands on a remote server from a script. It seems like a permissions nightmare. I know it’s possible but I’ll probably stick with the script I have for now. I was hoping you had a magic bullet. :smile:

1 Like

Sorry that I didn’t. Node-RED is my local rule engine on the same box as the daemon so I at least get to avoid the middle step of MQTT but I’m sure it’s not really costing you much of a delay or overhead.

BTW, thanks for flagging that I plain texted my pin ;). Been quite a while since I set that up and wasn’t paying enough attention when I pasted it.

Here’s a cleaned version of that referenced for anyone in the future:

I don’t run OH anymore (though am migrating back to it purely as a ZWave interface). I don’t remember if you can run a direct exec command from OH. If you can you could just feed it from a rule/automation. That’s what I do in Node-Red. I just set a message payload to run the following exec command

printf ‘XXXX’ | sudo /usr/local/bin/nxcmd [armaway|armstay|disarm]

Hope that helps.