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