New OH2 version of alarmdecoder binding

Tags: #<Tag:0x00007f616ff16238>

Hi all. I’ve been working on an OH2 version of the OH1 alarmdecoder binding with @billfor. It is now at the point where we have opened a “WIP” pull request for it. While it is still a work-in-progress, it should be fully functional. However, we need a few volunteers who are willing to test it out and comment on it.

The ipbridge thing and the keypad thing have been tested moderately well, but the serialbridge, zone, rfzone, and lrr things have been through only very minimal testing.

The draft README file is available here.

The binding jar file built from the current PR is available here.

The PR is here.

2 Likes

Has anyone been able to download the new binding and test it out?

I removed the “Work In Progress” tag from the binding PR a few days ago, and it has now been through a code review. So if anyone is willing and able to test out the new binding before it gets merged, now would be a good time! Other than responding to code review comments and any bug reports or comments from testers, we aren’t planning any more changes at the moment.

Good news! The PR was merged this morning, so the new alarmdecoder binding should be available in the next 2.5.5-SNAPSHOT build.

For those who would like to try it out without upgrading to the current 2.5.5-SNAPSHOT (and are already running a 2.5.x version of openHAB):

The 2.5.5-SNAPSHOT build of the alarmdecoder binding is now available here: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.alarmdecoder/2.5.5-SNAPSHOT/org.openhab.binding.alarmdecoder-2.5.5-SNAPSHOT.jar

The README file is available here.

Hi Bob - thanks for this new update! I just did the conversion from the old binding to this one. I do have one question though that I haven’t been able to get working yet. I’ve got a few RF keyfobs that I had previously linked in with an item as follows:

Number alarm_keyfob_g1 “g1 Keyfob” (gGuestkey) {alarmdecoder=“RFX:0999999#data”}

I’ve noticed a bunch of auto discovered RF zones but none of the serials match the serial on the keyfob. I tried to manually create a thing with the serial of the keyfob but no such luck. Is it at all possible to get these key-presses in with the new binding?

Thank you!

Hi Jared. As far as I know, the RF keyfobs should work pretty much the same was as before. The way discovery works is that whenever the bridge handler sees a message from a device that hasn’t been “discovered” before, it sends it to the discovery code, which in turn adds an entry for it to the discovery inbox. So in theory it should discover your keyfobs as soon as it gets a message from them. It is a new binding, though, so it’s possible you are running in to a bug. I would recommend setting the logging level for the binding to TRACE, and you will then see the messages coming in from the AD unit, plus details about how they are being processed. You should see a message that starts with “!RFX:” followed by the device’s serial number when you activate one of the keyfobs.

BTW - Make sure you are running the most recent version of the binding (2.5.8), since a few fixes have gone in over the past few months. I’ll probably be submitting another new fix for some keypad address mask issues sometime this week.

So I am starting to migrate to docker and I noticed that my docker instance discovered the remote once I pressed it. Somehow now after a reboot my regular instance also discovered the remote and seems to be working.

Also - this works so much better than the v1 binding! Before I couldn’t get it to recognize repeat button presses (IE if you hit unlock 2 times - the second one wouldn’t be caught by OH until you did another button.) Using expire to reset the button to closed lets me grab sequential presses. Thank you!!

(I’m not certain how I will live without the expire binding when that time comes :/)

Cool! I’m glad to hear it is working well for you now!

(I’m not certain how I will live without the expire binding when that time comes :/)

From what I’ve heard, some roughly equivalent bit of functionality will be included in OH3.0 before it releases, although it likely won’t be in the form of a binding. So hopefully it won’t be too much of an issue!

1 Like
1 Like

Hi @BobA First, I’d like to say ‘thanks’ for this binding. It was one of the reasons I opted to go with OH in the first place.

I can’t really say this is a bug - I’m not using this in the intended way - but I hope that maybe you can tell me what’s going on, and perhaps this new 2.5.5 binding could be adapted to this use case.

A little background. I have two OH installations, and that’s the crux. The first is an Openhabian install that started with the 1.8 binding, directly connected to an AD2USB on a 128BPT panel. I recently installed OH in a docker container on another machine to do more “heavy lifting” than what I can do solely on the Pi, and it’s in connecting these two that something interesting happens…

I believe that in the 1.8 binding, I had to connect the AD2USB via the TCP setting and run ser2sock. No problem. I have had that working for some time. However, as an experiment, I set the OH install in the Docker with the 2.5.5 binding to try and read the TCP information from the 1.8 binding on the Pi connected with the AD2USB. It worked. Very cool. I don’t have to set up some MQTT-based interface between the two installations…

Then I went ahead and just upgraded to the 2.5.5 binding on the Pi. It works on the Pi. However, I now get the following error in the logs on the Docker container:

Error Invalid number of parts in keypad message while parsing message [10000001100000003A–],003,[10[10000001100000003A–],003,[f70700060003001c28020000000000],"DISARMED READY TO ARM ". Please report bug.

While the binding is not set to be used this way, I am very curious if there’s a way to check the parsing and not throw an error, which will effectively make a single installation of an AD2USB available over the network to other OH installations. I’m working on a redundancy/failover strategy (and some test installs) with multiple OH installations, so this would allow for a lot of reuse if it’s an easy use case to manage.

Purely as an aside,completely off-topic,and I’m probably the only OH user with this situation, there are some limitations on this 128BPT panel (outside of the scope of your binding) in that outside of the initial zones on the panel, all expansions utilize the V-Plex bus. Ultimately I’m going to have to purchase another AD device (USB, HAT, etc) to read that bus independently, but I digress… Since I can create multiple bridges easily with your 2.5.5 binding, I think this is going to be really interesting to monitor multiple V-Plex zones in multiple buildings. Very helpful binding, and I appreciate your work on this.

Hi Brian. I’m not sure I really understand what the problem is. You have 2 instances of openHAB connecting to the the same AD unit via sock2ser? I actually thought that should generally work, assuming that sock2ser handles the connection multiplexing properly. Although if you were to SEND data from both instances at once it would probably cause problems. However, from your log message it looks like you are just getting mangled data, which the binding can’t really do much about. Maybe someone else can chime in with some suggestions.

The first thing I would recommend it to make sure that you are running the latest version of the binding. There have been several updates since 2.5.5. The latest 2.5.9-SNAPSHOT build should be available here:
https://ci.openhab.org/view/Integration%20Builds%20(2.5.x)/job/openHAB2.5.x-Addons/lastSuccessfulBuild/artifact/bundles/org.openhab.binding.alarmdecoder/target/

Next, try enabling TRACE level logging for org.openhab.binding.alarmdecoder and restarting everything (including the AD and sock2ser). Then look at the logs and see if you are getting properly formatted messages from the AD.

In general, having active/active redundancy using openHAB can be very complicated and probably isn’t worth the effort. I’d recommend an active/standby scheme instead, where you either spin up a second instance or bring its bindings/things online only when you’ve confirmed that the first instance is down.

Hi Bob. Sorry for the slow update. I did update my openhabian installation with the AD2USB to 2.5.8-1 and also installed your latest 2.5.9 snapshot that you linked to. Everything seems to be working smoothly now. I am using the AD2USB on Openhabian (direct connection) with ser2sock and the TCP bridge, and am reading it on OH in the Docker container on the TCP bridge. I haven’t updated all of my items and such yet from the old binding, but it looks like everything is reading correctly without errors. This is really valuable in my situation since I can leverage the AD2USB on an OH install on a Pi and still get the data across my LAN for other OH installs. In my particular case, I have a need for several OH instances performing localized functions and sharing data with a ‘master’ OH installation. But managing it all purely via MQTT can get cumbersome for everything.

Great! I’m glad to hear it’s working for you!