Alarmdecoder 2.5.5 Binding

@BobA

Thank you for the hard work to publish the 2.x alarmdecoder binding. I am excited to see this migration as it is one of two bindings left that are running on 1.x.

I attempted to migrate to the Alarm Decoder binding 2.5.5 this morning and had to roll back. I encountered a few issue or features that may be missing?

  1. alarmReady Contact:

Before the migration I noticed there was no contact/switch for alarmReady in the keypad. In the 1.x binding there was a contact configured. In my rules I utilize that contact for being conditional before the automation takes place. I do not see that as an option in the ReadMe file.

Contact alarmPanelContactReady      "panel ready: [%d]" (gPanel)      {alarmdecoder="KPM:00#contact,bit=17"}

I could live without the contact and I can supplement it with a rule if need be and was not a deal breaker.

  1. Keypad Control Panel on IOS sitemap:

While migrating the binding I moved the control panel that was available in the 1.x binding to the new binding utilizing the intCommand in the keypad. Following this migration the mappings became like a switch instead of momentary buttons like in the previous binding. For example if I hit 1 on the keypad in the sitemap a 1 appeared next to the buttons (switch) and the button did not release. In the previous binding it released the value when the key was pressed. It is impossible to have a duplicate digit in your access code that is reused on the same line.

Number alarmPanelLine1 "" (gPanel)   {alarmdecoder="SEND#1=1,2=2,3=3", autoupdate="false"}
Number alarmPanelLine2 "" (gPanel)   {alarmdecoder="SEND#4=4,5=5,6=6", autoupdate="false"}
Number alarmPanelLine3 "" (gPanel)   {alarmdecoder="SEND#7=7,8=8,9=9", autoupdate="false"}
Number alarmPanelLine4 "" (gPanel)   {alarmdecoder="SEND#10=*,0=0,11=POUND", autoupdate="false"}

Updated configuration:

Number alarmPanelLine1 "" (gPanel) {channel="alarmdecoder:keypad:ad1:keypad1:intcommand" }

This was not a deal breaker either since the keypad is hardly ever used… It is controlled mainly with homekit/specific buttons Home/Away/Disarm.

  1. Relays cannot be controlled from the new binding:

I utilize several virtual relays in my alarmdecoder to set off zones for example when I have a water leak with a Zwave device. With these virtual relays I trigger 24 hours zones so I do not sleep through a text message in the middle of night when there is a leak in the basement. This was never a documented feature in the 1.x binding but it did work.

Item Configuration:

Number alarmWaterDetect "Water Alarm Panel" {alarmdecoder="SEND#1001=L411\r,1002=L410\r", autoupdate="false"}

Associated Rule:

   // Rules for water sensor contact message
    rule "Send email on Water Sensor Contact"
    when
            Item water_heater_water_2_sensor changed to ON or Item sump_water_3_sensor changed to ON or Item washer_water_4_sensor changed to ON
    then
            logInfo ("log", "Rule=Water Detected!!")
            sendCommand(Main_Water, ON)
            alarmWaterDetect.sendCommand(1001)
            mailActions.sendMail (mailTo, "Check High water or Water Leak!", "Check for water leak!!")
            mailActions.sendMail (mailTo2, "Check High water or Water Leak!", "Check for water leak!!")
    end


// Rule to clear alarm panel once water sensor is no longer in alarm
rule "Clear alarm panel when water no longer present"
when
        Item water_heater_water_2_sensor changed to OFF or Item sump_water_3_sensor changed to OFF or Item washer_water_4_sensor changed to OFF
then
        if(water_heater_water_2_sensor.state == OFF && sump_water_3_sensor.state == OFF  && washer_water_4_sensor.state == OFF) {
        logInfo ("log", "Rule=Clear Relay 41 water no longer Present!!")
        alarmWaterDetect.sendCommand(1002)
        }
end

When I tried to enter the relay in CommandMapping (To use the legacy intCommand structure) in the keypad thing openhab2 said it was an illegal value. When I utilize the keypad command string and substituted 1001 for L411\r in the rule I received a warning for an illegal value.

Without being able to control relays from alarm decoder I had to roll back to the 1.x version of the binding. Am I doing something wrong or a feature that was left out? The ReadMe file only talks about specific keypad commands where this would be an alarmdecoder command?

I am using LRR (I know you were looking for somebody to test) but I backed out before seeing if it worked. I can try again once we can get relays working.

Thanks,

Dan

Hi Dan. Thanks, this is good feedback. The new binding hasn’t had a lot of testing yet, so it’s good to have people trying it out.

Before the migration I noticed there was no contact/switch for alarmReady in the keypad.

I double-checked the code, and there actually is a read-only switch channel for ready. It is just called “ready”. It looks like it is missing from the README file for some reason, though. Probably just an oversight on my part, or maybe an editing accident. I’ll add it in.

Following this migration the mappings became like a switch instead of momentary buttons like in the previous binding. For example if I hit 1 on the keypad in the sitemap a 1 appeared next to the buttons (switch) and the button did not release.

That’s weird. I’m not sure why that is happening. I’ll have to take a look at it.

Relays cannot be controlled from the new binding

Yes, that’s a known limitation. I didn’t add in support for zone emulation yet, mainly because there was nobody to test it. I’ll have to take a look at what changes would be required to support it. The right way to do it would probably be to add a new thing type, or maybe to add to the existing zone thing.

I am using LRR (I know you were looking for somebody to test) but I backed out before seeing if it worked. I can try again once we can get relays working.

There are a few tweaks I’d like to make to the lrr thing, but it should basically work. I’d be interested to hear if it works ok for you.

Bob,

Thanks for getting back to me so quickly.

Before the migration I noticed there was no contact/switch for alarmReady in the keypad.

This is great… Less work to do with rules… I am glad this one was easy!

Following this migration the mappings became like a switch instead of momentary buttons like in the previous binding. For example if I hit 1 on the keypad in the sitemap a 1 appeared next to the buttons (switch) and the button did not release.

I can roll the binding forward to 2.x this afternoon and provide a screenshot… It was very weird. I tried clearing the item in the file and sitemap to see if that resolved it and it did not.

Relays cannot be controlled from the new binding

I mislabeled this as relays but you are correct virtual zones (sorry about that). I have four configured in my home for Water Detection/Garage Doors/Forced entry on my front door with Z-Wave devices that are triggered as a virtual zone through AD. I am more than willing to test the feature during development and is critical for me since my family is not the best at keeping the garage doors closed :slight_smile:.

I am using LRR (I know you were looking for somebody to test) but I backed out before seeing if it worked. I can try again once we can get relays working.

I can roll the binding forward this afternoon and test LRR and provide feedback. I will report back with anything that I come up with.

Thanks,

Dan

@BobA

Here is the results of my testing this afternoon.

Issue #1: Ready Contact

Channel works fine with name “ready”… good to go.

Issue #2: Keypad in sitemap:

Before the conversion:

Items:

Number alarmPanelLine1 "" (gPanel)   {alarmdecoder="SEND#1=1,2=2,3=3", autoupdate="false"}
Number alarmPanelLine2 "" (gPanel)   {alarmdecoder="SEND#4=4,5=5,6=6", autoupdate="false"}
Number alarmPanelLine3 "" (gPanel)   {alarmdecoder="SEND#7=7,8=8,9=9", autoupdate="false"}
Number alarmPanelLine4 "" (gPanel)   {alarmdecoder="SEND#10=*,0=0,11=POUND", autoupdate="false"}

Sitemap:

Switch item=alarmPanelLine1 label="Keypad" 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="_____#_____"]

After the conversion:

items:

Number alarmPanelLine1 "" (gPanel)   {channel="alarmdecoder:keypad:ad1:keypad1:intcommand"}
Number alarmPanelLine2 "" (gPanel)   {channel="alarmdecoder:keypad:ad1:keypad1:intcommand"}
Number alarmPanelLine3 "" (gPanel)   {channel="alarmdecoder:keypad:ad1:keypad1:intcommand"}
Number alarmPanelLine4 "" (gPanel)   {channel="alarmdecoder:keypad:ad1:keypad1:intcommand"}

LRR Testing:

I converted LRR to the new binding successfully. I like that you are parsing it in the binding (channels) instead of with a rule that was used in the 1.x binding. I sent several LRR messages and they were received. My only comment is I had to add the transformation MAP file for the CID message that was included in the 1.x binding for readability on my sitemap.

String LrrMessage "CID Message[MAP(alarm_LRR_eventmap.map):%s]" {channel="alarmdecoder:lrr:ad1:lrr:cidmessage"}

The only other thing that I had noticed with LRR was I did not see any CID report codes during the testing. I looked at the raw LRR message and I did confirm nothing was sent.

Thanks,

Dan

I just submitted a PR that contains support for virtual zones. It does this by introducing a new “vzone” thing. This will allow you to open/close virtual zones from openHAB.

Bob,

Thanks for the work with this one:

To resolve issue #2 - Use autoupdate false feature:

Number alarmPanelLine1 "" (gPanel)   {channel="alarmdecoder:keypad:ad1:keypad1:intcommand", autoupdate="false"}
Number alarmPanelLine2 "" (gPanel)   {channel="alarmdecoder:keypad:ad1:keypad1:intcommand", autoupdate="false"}
Number alarmPanelLine3 "" (gPanel)   {channel="alarmdecoder:keypad:ad1:keypad1:intcommand", autoupdate="false"}
Number alarmPanelLine4 "" (gPanel)   {channel="alarmdecoder:keypad:ad1:keypad1:intcommand", autoupdate="false"}

Dan

BobA,
I am trying to convert the AlarmDecoder 1.0 binding to your 2.5.5 version. I have my zones setup. The problem I am having is setting up the alarmdecoder keypad. I don’t see a “thing” created for it. Does this need to be created manually?
Thanks for any help.
Mike

Hi Mike. Yes, the keypad needs to be added manually. Only zones and rfzones are automatically discovered. Most likely you should use a mask of 0 (the default) for your keypad thing.

BobA,
Thanks, I was able to add the keypad and setup my zones. Now I’m trying to figure out how to be able to set the alarm system to away and home and also how to disarm it. Would I use the Keypad command or the Integer Mapped keypad command? Could you give me any example how it would look? I would probably have to include the alarm code in the command to disarm the alarm.
Thanks,
Mike

You can use either the command (Keypad Command) or intcommand (Integer Keypad Command) channel to send commands. I would probably recommend the command channel if you are starting from scratch. The intcommand channel is really just for backward compatibility with the V1 binding. An item linked to the command channel should accept a string, and you should be able to send it anything you can punch in on your keypad. The docs say:

Commands sent from the keypad thing are limited to the set of valid keypad command characters supported by the Alarm Decoder (0-9,*,#,<,>). In addition, the characters A-H will be translated to special keys 1-8. Command strings containing invalid characters will be ignored.

I would recommend typing commands in to the UI to test it out, and then if you want you can create rules to send commands automatically later. Just be aware that the “special keys” (A-H) map to the programmable keys on the side of your keypad, if it has them. If it does, and they are programmed as some sort of panic buttons, you should obviously be careful about sending those characters.

Bob,
Below is the Previous OpenHAB item that I used to set my alarm system to Stay mode in the 1.0 Binding. Where would I add the “SEND#ON=POUND3” in the new binding command?

Previous:

Switch ArmStay “Arm Stay” {alarmdecoder=“SEND#ON=POUND3”, autoupdate=“false” }

New:

Switch ArmStay “Arm Stay” {channel=“alarmdecoder:keypad:747621a4:command”, autoupdate=“false”}

Thanks for your help,
Mike

There is no direct equivalent, because V2 bindings only expose channels. In this case the command channel expects a string like “#3”. I’m not sure what the closest equivalent to that V1 item config would be. If you want to send one command when a switch item it toggled on, and another when it is toggled off, I would probably use a rule. There may be some way to use a mapping to do the same thing (i.e. map ON to a particular command string), but I’m not sure offhand what it would be.

I’m trying to upgrade from v1 to v2 and I’ve hit problems.

  1. The binding doesn’t seem to work with symlinks. I did have it working earlier using the given device name.

  2. It appears to initialise and immediately go off line:
    2020-08-29 16:54:48.633 [hingStatusInfoChangedEvent] - ‘alarmdecoder:keypad:ad1:keypad1’ changed from INITIALIZING to ONLINE

    2020-08-29 16:54:49.188 [hingStatusInfoChangedEvent] - ‘alarmdecoder:serialbridge:ad1’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): For input string: “c7000000”

I tried to roll back to v1 but that’s not working so I’m going to try to go forward to v2 but I’m not sure what to change next.

That’s not the fault of the binding itself, but of the serial library used by openHAB. If I recall right, it will only automatically detect serial device names that conform to certain pre-defined patterns. If you want to use a non-standard serial device name you may need to define it in an environment variable so the system will recognize it. If you search around in the forum you should find more info about that.

  1. It appears to initialise and immediately go off line:
    2020-08-29 16:54:48.633 [hingStatusInfoChangedEvent] - ‘alarmdecoder:keypad:ad1:keypad1’ changed from INITIALIZING to ONLINE

    2020-08-29 16:54:49.188 [hingStatusInfoChangedEvent] - ‘alarmdecoder:serialbridge:ad1’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): For input string: “c7000000”

I tried to roll back to v1 but that’s not working so I’m going to try to go forward to v2 but I’m not sure what to change next.

It’s hard to tell much from that. You should try setting the logging level for org.openhab.binding.alarmdecoder to DEBUG or TRACE. Then you will see more details in the log of communications with the alarmdecoder unit, such as messages in and out, etc. Then you should be able to tell what’s going wrong.

Thanks for the update on the symlinks. It used to work on v1 but I’m guessing that may have used a different library. I’ll have a look at the environment variables.

Apologies for the sketchy post yesterday - I though the v1 to v2 upgrade would be quick and I ran out of time. Theses are potentially the relevant lines from the log:
2020-08-30 09:15:16.525 [TRACE] [der.internal.handler.ADBridgeHandler] - Received msg: [10000001000000003A–],000,[f7c700000000001c08020000000000]," GBD Security 30-08-20 09:44"
2020-08-30 09:15:16.527 [TRACE] [der.internal.handler.ADBridgeHandler] - Notifying child handlers that panel is in ready state
2020-08-30 09:15:16.552 [WARN ] [der.internal.handler.ADBridgeHandler] - Runtime exception in reader thread
java.lang.NumberFormatException: For input string: “c7000000”
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:1.8.0_252]
at java.lang.Integer.parseInt(Integer.java:583) ~[?:1.8.0_252]
at org.openhab.binding.alarmdecoder.internal.protocol.KeypadMessage.getIntAddressMask(KeypadMessage.java:131) ~[?:?]
at org.openhab.binding.alarmdecoder.internal.handler.KeypadHandler.handleUpdate(KeypadHandler.java:159) ~[?:?]
at org.openhab.binding.alarmdecoder.internal.handler.ADBridgeHandler.notifyChildHandlers(ADBridgeHandler.java:337) ~[?:?]
at org.openhab.binding.alarmdecoder.internal.handler.ADBridgeHandler.parseKeypadMessage(ADBridgeHandler.java:230) ~[?:?]
at org.openhab.binding.alarmdecoder.internal.handler.ADBridgeHandler.readerThread(ADBridgeHandler.java:170) ~[?:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
2020-08-30 09:15:16.587 [DEBUG] [der.internal.handler.ADBridgeHandler] - Message reader thread exiting
2020-08-30 09:15:16.588 [DEBUG] [oder.internal.handler.ADThingHandler] - Bridge status changed to OFFLINE for AD handler
2020-08-30 09:15:16.591 [DEBUG] [oder.internal.handler.ADThingHandler] - Bridge status changed to OFFLINE for AD handler
2020-08-30 09:15:16.593 [DEBUG] [oder.internal.handler.ADThingHandler] - Bridge status changed to OFFLINE for AD handler
2020-08-30 09:15:16.595 [DEBUG] [oder.internal.handler.ADThingHandler] - Bridge status changed to OFFLINE for AD handler
2020-08-30 09:15:16.597 [DEBUG] [oder.internal.handler.ADThingHandler] - Bridge status changed to OFFLINE for AD handler
2020-08-30 09:15:16.590 [DEBUG] [oder.internal.handler.ADThingHandler] - Bridge status changed to OFFLINE for AD handler

Thing config is 1 keypad and 5 RF zones

Might be worth noting that the panel is an Ademco Galant rather than Vista so there are a few differences in the way the messages work although it can’t be anything fundamental because it still uses 6160 keypads and 5800 RF peripherals.

Quick bit of research and I think the binding is looking at the address mask in the keypad message.

According to the Alarm Decoder protocol wiki, this is 4 bytes expressed as 8 hex nybbles so c7000000 is valid as addressing the message to devices 0, 1, 2, 6 and 7.
0, 1, and 2 make sense as these are the two keypads plus the decoder. 6 and 7 are not in the allowable range for any of the addressable peripherals but you can get an ECP trigger interface so maybe this sits permanently on one of those addresses.

Is the number format exception due to expecting all the characters to represent digits?

Yes, the problem is that the mask “c7000000” is larger than the code expects. It expects to convert the address mask’s hex string to an integer, but that value is larger than Java’s maxint. I’ll have to change the code to use a long, or maybe to parse it up differently.

Try this test build and see if it fixes the problem:

https://github.com/bobadair/openhab2-addons/releases/tag/alarmdecoder-fix2

Edit: Fix is now merged in to 2.5.9-SNAPSHOT

BTW - I agree that the decoded address mask “c7000000” should indicate devices 0,1,2,6, and 7, at least from what the AD protocol docs say. I have no idea why it would be referencing 6 and 7. It seems like every model of panel has its own little peculiarities.

That was it.

Thanks for the binding and your support in getting it working with my panel.