DSC Alarm Action in OH2

Hello @Moxified,

The ‘Suppress Acknowledgement Messages’ option just stops the 500 and 550 messages from being posted to PANEL_MESSAGES.

I have been looking at the binding and made some changes that fix the following warnings:

[WARN ] [calarm.handler.PartitionThingHandler] - DSC Alarm bridge handler not available. Cannot handle command without bridge

You can find it here. I have also been looking into your other issues but I cannot seem duplicate them. When in debug logging, I can see that PANEL_MESSAGE is updated when a 672 or 502 message is received, and PANEL_SYSTEM_ERROR is also updated. I even wrote a rule to send an email when PANEL_MESSAGE changes to 672 and it worked. See my log samples below:

openhab.log

2017-02-26 14:19:34.926 [DEBUG] [ng.dscalarm.internal.DSCAlarmMessage] - parseAPIMessage(): Message Received (6721) - Code: 672, Name: Failure to Arm, Description: 672: An attempt was made to arm the partition and it failed., Data: 1
2017-02-26 14:19:34.926 [DEBUG] [rm.handler.DSCAlarmBaseBridgeHandler] - handleIncomingMessage(): Message received: 6721D0 - Code: "672", Name: "Failure to Arm", Description: "672: An attempt was made to arm the partition and it failed.", Partition: 1, Data: 1
2017-02-26 14:19:34.927 [DEBUG] [rm.handler.DSCAlarmBaseBridgeHandler] - findThing(): Thing Found - org.eclipse.smarthome.core.thing.internal.ThingImpl@7ee369e5, org.openhab.binding.dscalarm.handler.PartitionThingHandler@7916e1c3, PARTITION
2017-02-26 14:19:34.927 [DEBUG] [rm.handler.DSCAlarmBaseBridgeHandler] - handleIncomingMessage(): Thing Search - 'org.eclipse.smarthome.core.thing.internal.ThingImpl@7ee369e5'
2017-02-26 14:19:34.927 [DEBUG] [calarm.handler.PartitionThingHandler] - dscAlarmEventRecieved(): Thing - dscalarm:partition:192_168_0_20:partition1   Command - FailureToArm
2017-02-26 14:19:34.927 [DEBUG] [calarm.handler.PartitionThingHandler] - updateChannel(): Panel Channel UID: dscalarm:partition:192_168_0_20:partition1:partition_arm_mode
2017-02-26 14:19:34.929 [DEBUG] [g.dscalarm.handler.PanelThingHandler] - setTimeStampState(): Already Set!
2017-02-26 14:19:34.929 [DEBUG] [g.dscalarm.handler.PanelThingHandler] - updateChannel(): Panel Channel UID: dscalarm:panel:192_168_0_20:panel:panel_message

events.log

2017-02-26 14:19:34.930 [ItemStateChangedEvent     ] - PARTITION1_STATUS changed from Partition Not Ready to Failure to Arm
2017-02-26 14:19:34.931 [ItemStateChangedEvent     ] - PANEL_MESSAGE changed from 609: General status of the zone - open. to 672: An attempt was made to arm the partition and it failed.
2017-02-26 14:19:35.428 [ItemStateChangedEvent     ] - ZONE22_TRIPPED changed from ON to OFF
2017-02-26 14:19:35.432 [ItemStateChangedEvent     ] - ZONE22_STATUS changed from OPEN to CLOSED
2017-02-26 14:19:35.432 [GroupItemStateChangedEvent] - DSCAlarmMotion changed from OPEN to CLOSED through ZONE22_STATUS
2017-02-26 14:19:35.433 [ItemStateChangedEvent     ] - ZONE22_MESSAGE changed from 609: General status of the zone - open. to 
2017-02-26 14:19:35.433 [ItemStateChangedEvent     ] - PANEL_MESSAGE changed from 672: An attempt was made to arm the partition and it failed. to 610: General status of the zone - restored.

I was hoping it would be something obvious but I’m just not seeing it. Sorry, not sure what to do at this point.

Thank you. I’m not sure what could be going on then. I put your new jar in place just to see if that would help but it still does not. What can I do to help track this down? Is there something else that could be causing this such as a config I have or something? For the most part my items and things are straight modified from your documentation.

Openhab:

2017-02-26 16:10:17.877 [DEBUG] [larm.handler.EnvisalinkBridgeHandler] - read(): Message Received: 16:10:24 6721D0
2017-02-26 16:10:17.878 [DEBUG] [ng.dscalarm.internal.DSCAlarmMessage] - parseAPIMessage(): Message Received (6721) - Code: 672, Name: Failure to Arm, Description: 672: An attempt was made to arm the partition and it failed., Data: 1

2017-02-26 16:10:17.878 [DEBUG] [rm.handler.DSCAlarmBaseBridgeHandler] - handleIncomingMessage(): Message received: 16:10:24 6721D0 - Code: “672”, Name: “Failure to Arm”, Description: “672: An attempt was made to arm the partition and it failed.”, Time Stamp: 16:10:24, Partition: 1, Data: 1
2017-02-26 16:10:17.878 [DEBUG] [calarm.handler.PartitionThingHandler] - dscAlarmEventRecieved(): Thing - dscalarm:partition:dscalarm:partition1 Command - FailureToArm
2017-02-26 16:10:17.878 [DEBUG] [calarm.handler.PartitionThingHandler] - updateChannel(): Panel Channel UID: dscalarm:partition:dscalarm:partition1:partition_arm_mode
2017-02-26 16:10:18.570 [DEBUG] [rm.handler.DSCAlarmBaseBridgeHandler] - DSC Alarm Polling Task - ‘dscalarm:envisalink:dscalarm’ is ONLINE
2017-02-26 16:10:20.377 [DEBUG] [larm.handler.EnvisalinkBridgeHandler] - read(): Message Received: 16:10:26 6511CD
2017-02-26 16:10:20.378 [DEBUG] [ng.dscalarm.internal.DSCAlarmMessage] - parseAPIMessage(): Message Received (6511) - Code: 651, Name: Partition Not Ready, Description: 651: Partition can not be armed., Data: 1

2017-02-26 16:10:20.379 [DEBUG] [rm.handler.DSCAlarmBaseBridgeHandler] - handleIncomingMessage(): Message received: 16:10:26 6511CD - Code: “651”, Name: “Partition Not Ready”, Description: “651: Partition can not be armed.”, Time Stamp: 16:10:26, Partition: 1, Data: 1

Events:

2017-02-26 16:10:17.885 [ItemStateChangedEvent ] - PARTITION1_STATUS changed from Partition Not Ready to Failure to Arm
2017-02-26 16:10:20.387 [ItemStateChangedEvent ] - PARTITION1_STATUS changed from Failure to Arm to Partition Not Ready
2017-02-26 16:11:19.903 [ItemStateChangedEvent ] - KEYPAD_READY_LED changed from 0 to 1
2017-02-26 16:11:19.917 [ItemStateChangedEvent ] - PARTITION1_STATUS changed from Partition Not Ready to Partition Ready
2017-02-26 16:11:57.394 [ItemStateChangedEvent ] - PANEL_TIME changed from 2017-02-26T16:08:00.000-0500 to 2017-02-26T16:12:00.000-0500

Actually, in general, PANEL_MESSAGE sees very little updates but it is getting some so it appears to be working. Here is my item just in-case:

String PANEL_MESSAGE 						"Panel Message: [%s]" 						<"shield-1"> 		(DSCAlarmPanel) 						{channel="dscalarm:panel:dscalarm:panel:panel_message"}

Is the name of your bridge ‘dscalarm’? Here is my item entry for PANEL_MESSAGE:

String PANEL_MESSAGE "Panel Message: [%s]" (DSCAlarmPanel) {channel="dscalarm:panel:192_168_0_XXX:panel:panel_message"}

I believe so yes:

Bridge dscalarm:envisalink:dscalarm [ ipAddress=“x.x.x.x”, password=“xxxxx” ]
{
Thing panel panel [ userCode=“xxxx”, suppressAcknowledgementMsgs=true ]

Yes, it looks like it is.

I wouldn’t put myself in the creative category… :smiley:

Anyway, could it be related to java or not having another binding or something? I know I have to manually add “feature:install openhab-transport-serial” otherwise I get “Unresolved requirement: Import-Package: gnu.io

Linux OpenHAB 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u1 (2017-02-22) x86_64 GNU/Linux
java version "1.8.0_121"
Java™ SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot™ 64-Bit Server VM (build 25.121-b13, mixed mode)

I’m using Windows, but whenever I update the binding I have to do the following in the Karaf console:

bundle:uninstall org.openhab.binding.dscalarm

And then restart openhab.

I just checked feature:list | grep dsc and it shows nothing installed:

openhab> feature:list | grep dsc
openhab-binding-dscalarm | 2.0.0 | | Uninstalled | addons-2.0.0 | DSCAlarm Binding

That may be similar to purging the cache folder…

When I added your “beta” bundle, I deleted it out of /usr/share/openhab2/addons, cleared /var/lib/openhab2/cache and put the new one in the addons folder. I’m not sure how those directories map out on windows.

If I don’t purge the cache folder, it will continue to load the old binding at least if I don’t add a new one. I haven’t tried removing the old binding and putting the new jar without purging cache.

I wonder if there is something different between how linux and java interpret vs windows. Would you be able to test a linux VM? I’ll see if I can maybe throw together a window vm to test windows OH vs mine. That could potentially eliminate a few things.

I will need to set up a Linux machine (virtual or real) which will take a little time. It’s not a bad idea though. I will start moving toward that and let you know. Thanks.

Thanks! If you need any assistance (not trying to insult, just not sure your comfort level with linux), I’d be happy to help!

For the time being, my rule tweaks are working fine so I’m in no rush. Just would be nice to figure out for future use.

Trent

I have an older laptop that used to have Debian on it, but I took it off to play around with Windows 10 when it first came out. I’ll just reinstall Debian on it again and go from there. It should do the trick. If I run into problems I’ll let you know. Thanks, I appreciate it.

Hello Trent,

I have tested the binding on my Linux system and I was able to see the same issues. It turns out my logic was not setting PANEL_MESSAGE for all messages coming in. It was probably happening on my Windows system too, but I just didn’t catch it. I have placed a new .JAR file here, if you want to try it. Thanks.

Perfect! Works great. Thank you.

2017-03-04 17:36:52.933 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 651: Partition can not be armed. to 672: An attempt was made to arm the partition and it failed.
2017-03-04 17:36:52.937 [ItemStateChangedEvent ] - PARTITION1_STATUS changed from Partition Not Ready to Failure to Arm
2017-03-04 17:36:54.935 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 672: An attempt was made to arm the partition and it failed. to 651: Partition can not be armed.

Hello @rsstephens,

I’m little confused. You already help me few months ago setting up DSC binding 2.0 on OH2. Everything was working perfectly. Few weeks ago I tried out to activate PGM output to control my garage door exactly as @Moxified did.

So I read out all this thread and try several thing. No success. I tried binding 2.0. I tried binding 1.9 whith action bundle (legacy on on OH2). With this config it was worst, I never succeed to connect the bridge. Something weird, with this configuration I had to uninstall the bundle DSC 2.0 manually before installing JAR files for binding 1.9 because removing binding 2.0 by the way of PaperUI was not working. The final setup was bundle 1.9 for both binding and action active but PaperUI was still viewing binding 2.0??? So now, I just don’t know how to proceed to clean everything to make it work correctly.

Do you think you could give me some hints on how to proceed? Do I need to reinstall Openhab from scratch? Do I only need to install correctly binding 1.9 to make it work?

Thanks !

It has been a while since I got it all working but I use the DSC 2.1 binding only. I manually installed it from his link in post 20.

I assume if you use OH 2.1 that just came out, it would include the 2.1 version of the binding. That’s where I would start. (only my test box which doesn’t use DSC binding due to single connection to EVL is on 2.1 yet) From there you just need to get your config files right. The docs should steer you to the proper config.

You don’t need the legacy binding or the action.

Hello Martin,

When @Moxified was trying to use PGM capabilities the 2.0 binding didn’t have the ability to send commands directly to the DSC Alarm system. That option has since been added to the binding using a different method other than ‘actions’. The current binding version, 2.1, has this capability, so I would recommend restarting with version 2.1 and using the binding from there. That way you won’t have to install a separate beta version to get that feature working. Here are some links that may help out:

DSC Alarm Documentation
openHAB 2.1 Announcement
openHAB2.1 Release

P.S.
Just saw @Moxified’s reply. Basically, just repeating what he said.

@rsstephens, @Moxified,

Guys you are both very quick to answer! Thanks to both of you. I will give it a try during the weekend and let you know.
Best Regards!

ps: Issue fixed. Garage door is now responding! Thanks again!

@rsstephens,

I’ve been successfully using the DSC Alarm binding with my Envisalink for some time now (OH 2.5.1). Given the posts above I have not installed add-ons manually - just installed the DSC Alarm Binding via Paper UI.

I’m only just now trying to control the PGM outputs via the binding and am struggling to get it working.

I’ve configured the relevant PGM of my alarm to use PGM option 19, i.e. triggered via keypad sequence “*71”. It works as expected when “*71” is entered via the alarm keypad, but not from OH.

This is my items file:

String dsc_alarm_panel_command "DSC Alarm Panel Command" {channel="dscalarm:envisalink:<snip>:send_command"}
Switch dsc_alarm_send_command "Send Command to DSC Alarm"

And this is my rule:

ule "Send Command"
when
    Item dsc_alarm_send_command received command ON
then
    logInfo("dsc.rules", "DSC Alarm Send Command rule triggered")
    dsc_alarm_panel_command.sendCommand("071,*71")
end

The rule fires when I turn on the switch, but the PGM doesn’t activate. There’s no error in Openhab.log.

Are you able to point me in the right direction please? Is the format of my string correct? If I change my command to say:

dsc_alarm_panel_command.sendCommand("030,1")

It arms the alarm in away mode as expected.

Thank you!

Cheers,

David.

Hello David,

I believe the 071 command requires the first data character to be the partition number. So in your case it would look like the following:

"071,1*71"

Assuming it is partition 1. Hope this helps.

1 Like

Thanks @rsstephens! That’s working pefectly. Rookie mistake on my part being the first time I tried to do this. I had assumed that the PGMs weren’t partition specific since when keying the command on the DSC keypad only “*71” is required, but I guess that keypad itself is registered to partition 1 so all commands entered on it are automatically applied to partition 1.

Thanks again,

David.