Alarmdecoder 2.5.7 Binding - Serial Keypad

Add-ons Bindings
,
1

@BobA

Thank you for the hard work on the 2.x alarmdecoder binding. I am excited to see this migration!!

I setup the serial bridge and was able to get the basic contacts working. But I am not able to get the KeyPad items working. I am able to see the raw messages come in for the KeyPad text but its not updating the thing.

ad.items

Bridge alarmdecoder:serialbridge:ad1 [ serialPort="/dev/ttyUSB0", bitrate=115200, discovery=false ] {
    Thing keypad keypad1 [ addressMask=0, sendCommands=true ]
    Thing zone garageDoor "Garage Door" [ address=12, channel=1 ]
}

ad.things

String KeypadText "Message" {channel="alarmdecoder:keypad:ad1:keypad1:text"}
Contact garageDoor2     "Garage Door [MAP(contact.map):%s]" <door> (gDoor) {channel="alarmdecoder:zone:ad1:garageDoor:contact"}

Logs

10:41:44.219 [TRACE] [oder.internal.handler.ADBridgeHandler] - Received msg: !KPM:[10000001100000003A--],008,[f70000051008001c28020000000000]," DISARMED CHIME   Ready to Arm  "
10:41:48.178 [TRACE] [oder.internal.handler.ADBridgeHandler] - Received msg: !KPM:[10000001100100000A--],011,[f70000051011005028020000000000],"LOBAT 11                        "
2

After looking at the code seems like the KPM messages are missing the “!KPM” prefix check and assume it comes without a prefix. Do you think the serial and ipbridge get keypad messages differently?

3

I created a PR that should enable messages with and without the prefix. After looking at the docs seems like its a CONFIGBIT setting in the device. The messages with the prefix works with the old alarmdecoder1 binding so I suspect most have the CONFIGBIT enabled.

Ideally the binding should query for the CONFIGBIT and operate in the correct mode.
https://www.alarmdecoder.com/wiki/index.php/Protocol#CONFIGBITS

4

Hi Dave. Thanks for the PR! Yes, there is a config option to make the alarm decoder prefix the keypad messages with “!KPM:”. I think it defaults to off, but you are right that the binding should really support it in either mode. I didn’t think the V1 binding had supported the prefixed messages, so I figured that the new one was at least no worse than the old one. :slight_smile:.

Sorry I didn’t reply sooner, but my electricity was knocked out for a few days by tropical storm Isaias.

5

I am trying to migrate from Openhab2 to Openhab3, the alarmdecoder items were at the top of sitemap, so they were the first issue I ran into. I can get alarm status, so I know it is connected/initialized, but I cannot figure out how to arm the alarm.

It seems I can send command through command, but not through intcommand?

Here are my items:

String KeypadText "Message" {channel="alarmdecoder:keypad:ad1:keypad1:text"}
String KeypadCmd "Command" {channel="alarmdecoder:keypad:ad1:keypad1:command"}
Number KeypadIntCmd "intCommand" {channel="alarmdecoder:keypad:ad1:keypad1:intcommand", autoupdate="false"}

Here is my sitemap:

sitemap test label="test"
{
        Frame label="Alarm Status" {
                Text item=alarm_status
                Switch item=KeypadIntCmd label="Options:" mappings=[12="Arm"]
        }
}

Here is my alarmdecoder.thing:

Bridge alarmdecoder:ipbridge:ad1 [ hostname="192.168.x.x", tcpPort=10000, discovery=true ] {
    Thing keypad keypad1 [ addressMask=0, sendCommands=true, commandMapping="12=s" ]
    Thing lrr lrr [ partition=0 ]
}

In the log:

23:17:39.209 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'KeypadIntCmd' received command 12

However, I don’t see any sending occuring when connected to AlarmDecoder over telnet. I’m open for doing this differently. It seems the intention of the updated binding was not through the intcommand, so if there is a better way, let me know. Any help is appreciated!

6

I posted a reply over the weekend, but it seems to have been lost when the forum crashed. Were you able to get this working? It may help to enable debug or trace level logging for the alarmdecoder binding.

7

Thanks for the response! I had not tried checking the binding logging, but I just did, and I don’t see anything useful. In trace, I see the bus messages, but I don’t see a send when I click the switch.

If I send an invalid message to the keypad like:

KeypadCmd.sendCommand("s")

I do see an error:

21:49:59.544 [INFO ] [ecoder.internal.handler.KeypadHandler] - Invalid characters in command.

So I know that is at least attempting to send, but I assume it isn’t mapped correctly.

I switched back to openhab2, and I can see the send valid send/arm when I enable logging. Interesting that debug shows the bus messages when debug is enabled in openhab2, but trace needs to be enabled for openhab3 to show bus messages.

8

Hi. It’s probably best to use the "command’ channel for testing rather than the “intcommand” channel. The “intcommand” channel just allows you to map integers to command characters using the “commandMapping” string, which defaults to: “0=0,1=1,2=2,3=3,4=4,5=5,6=6,7=7,8=8,9=9,10=*,11=#”. This is mainly for backward compatibility. The “command” channel will allow you to send a string with multiple characters.

In either case, the characters that you can actually send are limited to “0-9,*,#,<,>”. In addition, the characters A-H will be translated to special keys 1-8. If you try to send anything else, you should see the log message: “Invalid characters in command. Ignoring command: {}”.

If you were using the old openhab1 binding under openHAB 2.x, the binding code is around 90% different, so you should expect different behavior from it.

9

Wow, that is quite the change, why did it have to change so much?

So my understanding is a need to send an “s” to the bus to arm the alarm. Do you have any recommendation on how to do that?

I tried all the special keys (A-H) and I hear noises on the keypad, but none of them seem to arm the alarm. I think one of them turned the doorchime on/off.

10

It looks like “s” is a deprecated command for arming DSC alarms. According to the Alarm Decoder docs, you should use special keys instead. It seems like key 4 (D) or key 5 (E). See the AD protocol docs here. If there is a number sequence you can punch in on the keypad to arm the alarm, you can also send that as a command string.

Wow, that is quite the change, why did it have to change so much?

Yeah, it turned out to be about the worst possible case for a V1 to V2/V3 port. There was nothing wrong with the original V1 code, it just turned out to be hard to port. The overall structure needed to change because it uses a bridge and things model. Then all of the channels needed to be redefined to work with the V2 channel/item model. Then discovery needed to be added. Then because it was old code, the serial library it was using was deprecated and needed to change, and it needed changes to meet new coding standards, and null annotations needed to be added, etc., etc.

I don’t want to discourage anyone from attempting other V1 ports, though. In most cases it is a lot easier. :slight_smile:

2 Likes
11

It seeems to work now. I never considered tht my AlarmDecoder was very out of date. After updating, sending a “D” arms the alarm in stay mode as exepected. Thanks for the help! And all the hard work updating the binding!