alarmdecoder ad2usb binding?

[Bernd Pfrommer]

AlarmDecoder makes devices (such as ad2usb and ad2pi) that allow home automation systems to interface with Honeywell/Ademco security systems (in my case a vista 20p).

Is anybody working on a binding for that?

I'm planning on writing one, but do not want to duplicate work.

Bernd

[Kevin Gottsman]

I would love to see a native binding for OH. I asked the nutech developers if they would write a binding, but they said they weren't strong in Java. 

I wrote a very basic script that captures the ser2sock output and dumps it into a switch through the REST API. I also created a couple scripts to arm/disarm the alarm through Telnet/bash through hard coded passwords. Nothing fancy like a control panel. 

If you would like to see the scripts, let me know and I can post them here. Admittedly, they are very elementary. 

Kevin

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

--

--

Thanks,
Kevin

[Bernd Pfrommer]

Binding done, pull request submitted.

No write access (yet?), as I did not want to give the capability to disarm the system remotely, for security reasons.

Should be straight forward to add later on if so desired.

On Thursday, August 21, 2014 9:51:03 PM UTC-4, Kevin Gottsman wrote:

I would love to see a native binding for OH. I asked the nutech developers if they would write a binding, but they said they weren't strong in Java. 

I wrote a very basic script that captures the ser2sock output and dumps it into a switch through the REST API. I also created a couple scripts to arm/disarm the alarm through Telnet/bash through hard coded passwords. Nothing fancy like a control panel. 

If you would like to see the scripts, let me know and I can post them here. Admittedly, they are very elementary. 

Kevin

On Thursday, August 21, 2014, Bernd Pfrommer <bernd.p...@gmail.com> wrote:

AlarmDecoder makes devices (such as ad2usb and ad2pi) that allow home automation systems to interface with Honeywell/Ademco security systems (in my case a vista 20p).

Is anybody working on a binding for that?

I'm planning on writing one, but do not want to duplicate work.

Bernd

--
You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

--

--

Thanks,
Kevin

[Kevin Gottsman]

Bernd,

Very excited.... I will pull the code tonight and begin to play with it. Does the code work for just the USB device or are there intentions to make it work with serial/ser2sock (telnet)?

I would have an interest in the plugin having write access. Perhaps a true/false option in the config file.

--

Thanks,
Kevin

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Bernd Pfrommer]

Both serial tty and TCP stream are supported. There's a wiki page but it's not linked in to the side panel yet.

https://github.com/openhab/openhab/wiki/AlarmDecoder-Binding

In fact I have only tested with a TCP stream from an ad2pi + ser2sock since I don't own a ad2usb.

Let me know if you hit any bumps.

What write access did you have in mind? Keypad operations like arming/disarming only or also adding openhab contacts as zones into the ademco panel via virtual expander zones?

[Kevin Gottsman]

It works great with my Vista 10SE panel. I will need to do more detailed configuration to match up the zones. I have 8 wired zones and no wireless. Planning to upgrade to the 20P at some point.

Most of the basic data looks correct. Can't test the panel until tomorrow.

Only weird data is this -> panel status: 33152

A quick bug in org.openhab.binding.alarmdecoder/pom.xml

<name>openHAB 1-Wire Binding</name>

--

Thanks,
Kevin

[Bernd Pfrommer]

Dang it, I used the onewire binding as a template, and didn't cover my tracks properly!!!

How did you possibly pick up on that? Thomas EE just merged the new binding into the main trunk. Unless there is some impact, I'd like to hold off with the fix until we have enough changes for the next pull request.

About the panel status: it's a raw integer that can be used in rules etc. You have to mask the right bits out in order for it to make sense. No point in displaying it.

I added the Number item just to document that the alarm status panel is available as a single number.

[Bernd Pfrommer]

Kevin,

I submitted another pull request: there is a bug in the current binding. It has to do with the bitmask for RF contact devices. The fix should be in the 1.6.0 master within a few days.

Bernd

On Monday, September 15, 2014 1:52:19 AM UTC-4, Kevin Gottsman wrote:

[Shawn Mix]

I too would like to see the development of this binding to include the ability to write back. I currently use the AD2USB plugin on a vera lite device (zwave gateway) and would be interested in switching to direct connection through a RPi or arduino with USB. My openhab runs inside a virtual system on hardware that won't be easy to hook the connection up to so I'm looking for satellite device options that have Ethernet capabilities to talk to openhab.

As far as features, I would love to see the ability to interact with the keypad as well as listing the zones out and being able to set their arm/bypass ability. I understand the security concern for remote access, though in the right hands and handled properly this can be augmented with other measures. I'd love a simple true false option in the comfit for writing.

[Bernd Pfrommer]

AFAIK, openHAB does not provide an easy way to e.g. enter free-form strings or numbers, which would be a straight forward approach to send commands to the alarm panel.

In the absence of that, how do you envision the input? A switch (ON/OFF) for arming/disarming? That would require storing the security code in clear text somewhere in the config files, not exactly pretty.

The easiest and most general would be to emulate a keypad by binding a character (number) to each button. Problem is: openHAB does not have push buttons.

[Shawn Mix]

Good points. So I'll give you the input I have from how mine is currently hooked up:

Inside my Vera Lite, I currently have the code input during a startup script, and the plugin essentially takes that input to encrypt it into a file and call it back out later through a secured mechanism (inside the plugin). If someone breaks into it, it's not the most secure in the world where someone won't get access, but it's best effort security with what's available. That said, it's secure enough I think with the right mechanisms in place to protect your OpenHAB system from being accessed, that it can work. Once that component is there, then it's simply a matter of what you specified, using a String entry mapped to the different callable arming modes. For mine I only actively use Ready, Armed, Night, and Stay modes. Giving these as options to enter into the String variable for the item, can set the panel. Or if needed, transcribe simple 1-4 for example to equate into the different modes and set them.

If emulating a keypad, I could see this happening perhaps through use of the autoupdate=false option? I've seen this in some places where it can be used for a push button use case? Allowing to press the button in an app and it will always reset to an OFF state for example. So putting 10 items mapped to the different digits or mode buttons, could allow for "pushing" of the buttons? For those who want to store their code, perhaps simply create a script that calls pressing the appropriate alarm code button numbers, and then call the script when updating the main arm mode item (as a rule). Not the most secure again, but more obscure method of having the code stored.

Just some ideas.

[Kevin Gottsman]

I agree with you that it's not pretty (or preferred). My implemented
script is below. I have it tied to the exec binding and a basic switch.

Could we do something with a web interface with some kind of HTTP/HTTPS
call maybe REST?



-- Kevin



[kevin@server scripts]$ cat alarm_off.sh
#!/bin/sh

# Alarm off

{ echo "99999"; sleep 4; } | telnet 192.168.2.20 10000

where 99999 is the code that I pass to the panel.

> --
> You received this message because you are subscribed to the Google
> Groups "openhab" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openhab+u...@googlegroups.com

> <mailto:openhab+u...@googlegroups.com>.

> To post to this group, send email to ope...@googlegroups.com

> <mailto:ope...@googlegroups.com>.

[Bernd Pfrommer]

Finished coding the first draft, need to clean up and test.

Basic idea: bind switch to key stroke and reproduce the alarm keypad in the openhab gui. Items file will look like this:

    Switch alarmPanelButton0    "0" (gPanel)  {alarmdecoder="SEND#0", autoupdate="false"}

    Switch alarmPanelButton1    "1(OFF)" (gPanel)  {alarmdecoder="SEND#1", autoupdate="false"}

Then need to use an entry in the sitemap as well to make the switch show up as a button.

Issue (aside from the keypad looking clunky due to lack of formatting capabilities): if openhab events are logged at INFO level, the item names will show up in clear text, i.e. one should NOT name the button corresponding to zero alarmPanelButton0, or else the security code can be figured out from the openhab event log.

[Shawn Mix]

Would it be possible to program this in a manner that could use a single item and take the entry of a number to correspond and figure out the keypad button to press? I'd imagine this would re-program the current plugin. But if you think of it in this manner, and allow the programming to account for some sort of millisecond delay, this could allow you to create a single item in the interface with a line full of simple buttons 0-9? or perhaps 3 lines with 3 numbers and each and a single line with 4 instead? The only drawback, is you wouldn't have something like the known command modes listed out there as well. Perhaps some fake items represented to illustrate which is which? This might just look more like a regular keypad that is right aligned?

[Bernd Pfrommer]

Shawn,
Frankly I don't understand most of what you wrote.
But AFAIK there are no openhab GUI elements that allow input of strings or numbers (otherwise I'd have used those).
Does that answer relate to your comments?

[Shawn Mix]

Bernd,

Sorry that was a quick message that just came falling out of my head. I'll try to clarify:

My thought was to create one Item in the items file for the keypad. Set the type for the item to Number or String. When processing any commands for that item, changing the Number/String based on a parse of the input being passed to call the right keypress.

Combine this with a Sitemap Switch item mapped to this, or perhaps 3 in a row (call them keypad 1, 2, 3). Visually, they will show up as three rows, and using the mappings function:

mappings=[1="1",2="2"3="3"]

they will appear as buttons along the single line, instead of 10 lines of single buttons as you created. The only downside I see to this, would be the limited space on some screens (iOS/Android), but this could be supplemented by removing the arm mode labels. Perhaps another line or 2 below these buttons with descriptors for the modes and appropriate numbers. One could use this for a few lines that will take inputs to pass to the Keypad Item in the items files with the appropriate number/string input.

Due to the speed of the changes to the item, I'm not sure if some changes would need to be made to the binding to for instance wait until the delta between settings has been more than 3 seconds or so to ensure the user has finished pressing the code+mode to then pass the presses. For me, I'm currently using an AD2USB plugin to a Wave controller, that a binding is in the works for. Running mine through this binding there is some delay and thus I figure might apply for the AD2USB binding. If it's quick enough though, this may not be an issue.

If I have time later, I'll try and mock it together quickly to give you an idea of what I was thinking.

[Bernd Pfrommer]

Shawn,

After some distractions I got around to trying this, and the fake keypad actually looks much better!

Will map the number 10 -> *, the number 11 -> #, and pass the rest through as is.

Should be able to do the changes today and roll it into my production system for testing.

I'm still waiting for Thomas to approve the pull request for a rewritten insteonplm binding. That will make it easier for me to manage my branches. Once that has been approved I'll submit a pull request for the improved alarmdecoder binding, and update the wiki.

[Shawn Mix]

Glad to hear it worked out well. Post a pic if you have a chance, I'd love to see if it looks as I imagined. :)

Thinking out loud here for some who may be lazy and/or accepting of the PIN being stored on the system. If I were to simply take the binding, then write a script for the different arming modes used, I could theoretically just have the script enter in the PIN code, then call the Arm mode desired correct? This could allow me to instead present a pick list in the sitemap for Arm modes which will call designated scripts? I've done something similar for another item to call different scripts, I imagine this theory could help me remove the reliance on my Vera Plugin binding for AD2USB operations. It would likely be faster and more efficient as well since it would directly talk to the device vs going through one binding, only to be routed through to another interface.

I look forward to this update and will see about getting my USB device added to the OpenHAB system to test out once the PR is accepted.

[Bernd Pfrommer]

Got distracted and only managed today to code it up.

Looks better, but writing the .items and sitemap file is not at all intuitive.

This is how the sitemap file looks like:

    Switch item=alarmPanelLine1 mappings=[ 1="1____(OFF)",  2="2(AWAY)",  3="3__(STAY)"]

    Switch item=alarmPanelLine2 mappings=[ 4="4_________",  5="5(TEST)",  6="6(BYPASS)"]

    Switch item=alarmPanelLine3 mappings=[ 7="7(INSTANT)",  8="8(CODE)",  9="9_(CHIME)"]

    Switch item=alarmPanelLine4 mappings=[10="*__(READY)", 0="___0___", 11="____#____"]

And the corresponding entries in the items file:

Number alarmPanelLine1    "line 1" (gPanel)  {alarmdecoder="SEND#1=1,2=2,3=3", autoupdate="false"}

Number alarmPanelLine2    "line 2" (gPanel)  {alarmdecoder="SEND#4=4,5=5,6=6", autoupdate="false"}

Number alarmPanelLine3    "line 3" (gPanel)  {alarmdecoder="SEND#7=7,8=8,9=9", autoupdate="false"}

Number alarmPanelLine4    "line 4" (gPanel)  {alarmdecoder="SEND#10=*,0=0,11=POUND", autoupdate="false"}

First the Switch item in the sitemap generates a DecimalType (a number) according to the mappings entry, which is then sent to the Number item belonging to the alarmdecoder binding.

The Number item in turn has a map from incoming number -> arbitrary output string (with POUND being search/replaced to #). In the case above, I simply map the numbers to its literal strings, except for the 10 and the 11, which map to * and # respectively.

I only tested sending single characters, but you should be able to send a complete string (i.e. the security code + any action you want).

[Bernd Pfrommer]

Pull request #1638 has the above features. The Wiki has also been updated.

Thanks for the input, it definitely improved the binding.

[Bernd Pfrommer]

Pull request has been merged into the 1.6 master.

[Kevin Gottsman]

Bernd,

The new binding looks good at first pass.

Its not related to the binding, but I am not sure where the bug lies.
When I view the sitemap in the browser, the map is reversed.

http://192.168.2.8:8080/openhab.app?sitemap=alarm

987
654
321
#0*


When I viewed with greent and the IOS app, it was fine.

-- Kevin

On 11/5/14 4:14 PM, Bernd Pfrommer wrote:
> Pull request #1638 has the above features. The Wiki has also been updated.
> Thanks for the input, it definitely improved the binding.
>

> --
> You received this message because you are subscribed to the Google
> Groups "openhab" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openhab+u...@googlegroups.com

> <mailto:openhab+u...@googlegroups.com>.

> To post to this group, send email to ope...@googlegroups.com

> <mailto:ope...@googlegroups.com>.

[Bernd Pfrommer]

I only tested GreenT and Habdroid. The classical GUI looks completely screwed up.

Try this: in the sitemap file instead of label="", do label="line1" as shown below.

Wiki has been updated accordingly.

Switch item=alarmPanelLine1 label="line1" mappings=[ 1="1____(OFF)",  2="2(AWAY)",  3="3__(STAY)"]

Switch item=alarmPanelLine2 label="line2" mappings=[ 4="____4_____",  5="5(TEST)",  6="6(BYPASS)"]

Switch item=alarmPanelLine3 label="line3" mappings=[ 7="7(INSTANT)",  8="8(CODE)",  9="9_(CHIME)"]

Switch item=alarmPanelLine4 label="line4" mappings=[10="*__(READY)",  0="___0___", 11="____#____"]

Text item=sAlarmPanelDisplay

[Tom Gerhard]

I'm brand new to OpenHab, and was hoping to use this binding.   I extracted the jar from the 1.6 snapshot and put it in my 1.5 addons directory, but it doesn't appear to work.  I don't see the outbound tcp connection to the ser2sock server that the ad2usb is on, nor are there any messages logged.   Do I need to wait for 1.6?

-tom

PS, telnet to the hostname and port mentioned in the config returns the ad2usb stream as expected.

[Bernd Pfrommer]

Correct: the AlarmDecoder binding was added in 1.6.

But you don't have to wait for 1.6, you can already download it :)

The jar files are here:

https://openhab.ci.cloudbees.com/job/openHAB/

[Tom Gerhard]

Took the plunge and loaded 1.6.   Looks good so far!

[Kevin Gottsman]

That didn't work either. Not a big deal as I mostly use the IOS version.

I added a quick quirk at the bottom of the wiki page to note that there
are possible display issues with the classical GUI.


-- Kevin

> > an email to openhab+u...@googlegroups.com <javascript:>
> > <mailto:openhab+u...@googlegroups.com <javascript:>>.

> > To post to this group, send email to ope...@googlegroups.com

> <javascript:>
> > <mailto:ope...@googlegroups.com <javascript:>>.

> > Visit this group at http://groups.google.com/group/openhab

> <http://groups.google.com/group/openhab>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

[Tom Gerhard]

Discovered that the wireless transmitters (Honeywell 5816) on my doors use loop2 for their magnetic contact, requiring bitmask=0x20 (instead of 0x80 shown in the example).  loop1 is used with an external contact.

I believe the bits for RFX devices are as follows:

0x02 - battery

0x04 - supervision

0x10 - loop3

0x20 - loop2

0x40 - loop4

0x80 - loop1

[Bernd Pfrommer]

Tom,
Would you mind updating the wiki by inserting an example configuration line next to the motion sensor? Mangle the model number into the item name so people know they need a different bitmask for that device, or at least they know to pay attention to the loop number.

[Tom Gerhard]

Example added for 5816 on loop2, as well as description of the bitmask values that I noted.

[Bernd Pfrommer]

Looks good, thanks!

[Tom Gerhard]

I had a working alarmdecoder setup, and I broke it, but not sure how.

I get a zero byte alarmdecoder.log, and no related messages in openhab.log, but there is no TCP connection to the configured host and port for the alarm feed (telnet to that host:port works and receives updates from the panel).

All of my sensor statuses show "UNKNOWN", and the integer values all show zeros.

I had replaced the alarmdecoder binding jar file with one that I'd built, but have since restored the original one with no change.   I'm still pretty green overall with admining openhome, and don't have a good idea of where to look next.

I'd appreciate any hints on where to look.

Thanks,

-tom

[Bernd Pfrommer]

Couple of questions that may help you debug this:

What version of openhab are you running? On what platform? Can you do a clean install from the cloudbees nightly build? Make a copy of your configuration and etc directories to a safe place so you don't lose anything when upgrading.

I always make sure that all the openhab components are of the same revision.

Do you see messages in the openhab log that it is starting the binding? Switch on debug logging for the alarmdecoder binding (see wiki). Do the messages indicate that the alarmdecoder binding gets the configuration from openhab.config?

For a while the master branch was broken in a major way such that the bindings would not even get their configuration information. That led to scenario you are describing. That has been fixed though, so with the latest version you should be good.

Bernd

[Tom Gerhard]

Thank Bernd.

I'm running 1.6.0 on Fedora Core 19; JRE is 1.7

I think it's not loading the binding -- there are no signs of it in openhab.log, and I still get a 0 byte alarmdecoder.log with the log level set to TRACE.

I'll try a clean install tonight of 1.6.1 and let you know how that works out.

-tom

[Bernd Pfrommer]

1.6.1? Come on, that's way outdated :)

Get 1.7.0 and be on the bleeding edge...

[Tom Gerhard]

Thanks.   I'm back in action on 1.7.0.   Now back to whatever it was I was testing when I broke it.

[Tom Gerhard]

I'm now running 1.7.0, downloaded from CloudBees.  I'm finding that some times when I start openhab, the alarmdecoder binding starts, but doesn't load its configuration (alarmdecoder.log shows "binding started", and "processing item ..." for each item found, but no further messages).

I've restarted quite a few times with no config changes, and with (only) changes to the logging level, and it seems to work more often with the log level set to "TRACE" (vs. "DEBUG"), but it's not 100% solid.   Is it possible that there is some sort of timing issue? 

[Bernd Pfrommer]

Yes, timing issues. Blame it on the framework, done!

Kidding aside: I thought I had covered all startup issues with the alarmdecoder binding, but maybe not.

1) Can you post the debug log of the alarmdecoder binding when it doesn't start?

2) Try "touch"ing a file with alarmdecoder items in there and see if that jump starts the binding.

[Tom Gerhard]

Here's the alarmdecoder log:

2014-12-21 19:30:09 DEBUG o.o.b.a.i.AlarmDecoderActivator[:31]- AlarmDecoder binding has been started.
2014-12-21 19:30:09 TRACE o.o.b.a.i.AlarmDecoderGenericBindingProvider[:134]- processing item "alarmPanelStatusRaw" read from .items file with cfg string KPM:00#status
2014-12-21 19:30:09 TRACE o.o.b.a.i.AlarmDecoderGenericBindingProvider[:134]- processing item "alarmPanelStatusReady" read from .items file with cfg string KPM:00#status,bit=17
(repeats for each entry in alarm.items).

Touching alarm.items causes the items to be refreshed, but doesn't trigger the config to be loaded.

I've also set mainconfig:refresh=180 in openhab.cfg (before restarting), and touched that file a few minutes after starting, but there's no acknowledgement in the logs that anything happened.   Also no response after adding a line consisting of just '#' to the end of openhab.cfg.

[Bernd Pfrommer]

Strange. This how it should look.

12:39:36.000 DEBUG o.o.b.a.i.AlarmDecoderActivator[:31]- AlarmDecoder binding has been started.

12:39:37.463 DEBUG o.o.b.a.i.AlarmDecoderBinding[:123]- got tcp configuration: alarmdecoder-host:10000

12:39:37.464 INFO  o.o.b.a.i.AlarmDecoderBinding[:158]- accepting commands!

12:39:37.464 INFO  o.o.c.s.AbstractActiveService[:169]- AlarmDecoder binding has been started

12:39:37.464 DEBUG o.o.b.a.i.AlarmDecoderBinding[:276]- marking all items as unknown

You are right, it's not getting the config. I had this problem too a while ago when the 1.7 master branch was badly broken. None of the bindings found its configuration. At some point later that was fixed though. I don't have the latest changes (I last merged with the master on Dec 5th). Could be that either you have an old snapshot or it's broken again?

[Tom Gerhard]

Yes, that's what I see what it does load (plus the extra messages from setting the log level to TRACE.

My 1.7 snapshot was downloaded from cloudbees at 21:39 EST (GMT-5) on December 16.

For now, I'll just keep an eye on it and restart if needed.   It seems to be about a 50/50 shot.    I'm still in tinkering mode, so it's not mission critical for me yet.     

The only other binding I'm using at the moment is HTTP, and it doesn't need any config; I'll set up the Samsung TV and see if it follows a similar pattern, but it may not be until after Christmas.

[Bernd Pfrommer]

For me it was a 100% failure, so this could be a different issue. Definitely sounds like it's related to the framework rather than the binding itself.