DSC Alarm Action in OH2

I see there is a DSC Alarm Action for OH 1.8.x here https://github.com/openhab/openhab/wiki/DSC-Alarm-Action

Is there a version of this binding available for OH2, or planned, or is it integrated into the current DSC Alarm Binding already?

Alternatively, is there a 1.x compatible version of this for OH2. Seems like one would be able to do a few useful things with this.

Currently OH2 doesn’t have the ability to develop Action bundles. To have that capability you would need to run the OH1 version of the binding and the action. I do plan on adding that option when the capabilities are available.

1 Like

Sorry to dust off an oldie. Is there any progress on this?

I’m working on migrating to OH2. I use senddscalarmcommand action to trigger pgm outputs as well as arm the alarm and will need this functionality. I can probably find a different method for arming the alarm but the PGM is important as it operates my garage door openers.

I don’t see the 1.x versions of the bindings or action even with legacy turned on.

Hello @Moxified,

There are still no action bundles for OH2 but I have been working on a work around to give the same functionality. If you want to test it, here is a JAR file for the DSC Alarm Binding with this feature. The setup is different than in OH1. The first thing you must do is create an item to hold the command string you are sending and link it to a channel in the bridge. It would look something like the following:

String SEND_DSC_ALARM_COMMAND "Send a DSC Alarm Command" {channel="dscalarm:envisalink:192_168_0_XXX:send_command"}

The next thing would be to use the built in function sendCommand() in your rule to issue the command to the binding. It would look something like these examples:

sendCommand(SEND_DSC_ALARM_COMMAND, "071,1*101#")  //Send Key Stroke String
sendCommand(SEND_DSC_ALARM_COMMAND, "000") //Send Poll Command

Notice the command variations in the examples. If a command has data, there needs to be a comma between the command and the data as seen above in the first example. If there is no data then it would only require the command itself as in the second example.

If you want to test you will need to copy the JAR file to the addons directory and uninstall the current version in the PaperUI. Let me know how it goes. Hope this helps. Thank you.

1 Like

Thanks @rsstephens,

I ended up getting the 1.9 addons working as I found another much more recent post from you stating it was still not possible and that you were still using the 1.9 yourself. I will take a peek at this over the next few days but admit I’m still very fresh to the OH2 way of doing things so the channel and things learning curve adds to my difficulties. I also couldn’t figure out how to remove the 1.9 addons. I deleted the jar files but they still load. OH2 likes to cache things somehow. I haven’t figured that out yet either.

This may not be the place for this question but why have they not implemented Actions? I purposefully have been avoiding OH2 because it was beta and seemingly incomplete but it has now left beta and 1.x support is rapidly disappearing yet OH2 seemingly isn’t ready for prime time. Kinda reminds me of Vera’s ui7 mess. I think you lived through that with me if I remember correctly.

As always, thanks for your work!

Oh so many thx for this!

Will test it later today or tomorrow as soon as I have some time to spare.

Your are welcome @tinuva. Thank you for testing. Let me know how it goes.

Regards,
Russell

Hello @Moxified,

Not sure why Actions have not been implemented. There was talk of it earlier in the development of OH2 but not much since that I can find. I think the Actions used are of the OH1 version and still work fine. Some Actions interact with the binding it is supporting, like the DSC Alarm binding, and therefore require the older version of the binding.

Yes, I remember the Vera UI7 mess. I know I switched my Vera back to UI5 at least once before settling on a stabler UI7. As for OH2, I believe is very stable now. I have been running exclusively on OH2 for roughly 2 or 3 months now and I’m not looking to go back. So whenever you are ready to jump over to OH2 I think you will find it to be pleasant to work with, and there is plenty of help on this community.

Thanks for your feedback, I appreciate it.

Regards,
Russell

Hi Russell,

I can confirm that it does work with my pgm commands (1*72). I didn’t try any other commands as I don’t use them. (I’m open to use case suggestions :smiley: )

I installed a fresh copy of OH2 on a new debian VM. I found that it needed the 1.x compatibility layer as it was missing “org.apache.commons.net.util” which I found was part of the compatibility package.

It appears maybe you are defining your things via the things file? It took me a few minutes (still learning things) to figure out where to find my sendcommand channel as I added my evl bridge manually through paperui. Do you recommend manual things vs. inbox things? I’m going to have to go through and convert all of my 1.8 DSC items to the newer things/channels. I want to do it right and once.

Do you know when this binding will make it to production?

Thanks so much!

Also, I have a few errors I have seen in OH log.

I tried discovery of the bridge and received this:

2017-02-20 11:57:06.651 [ERROR] [.discovery.EnvisalinkBridgeDiscovery] - discoverBridge(): Error - Unable to get Subnet Information! java.lang.NullPointerException

I manually added the evl bridge thing and it was fine. Not a big issue as far as I’m concerned. Especially because how would it know my password for my evl as I don’t use the default one. I just thought it might ask for details or something.

I also saw this a couple of times. I restarted and I don’t seem to be getting it at the moment:

2017-02-20 12:59:17.030 [ERROR] [rm.handler.DSCAlarmBaseBridgeHandler] - sendCommand(): Command 'UnknownCode' Not Sent - Invalid!

This seems more relevant as it is directly related to the sendCommand channel.

One more thing. I found a typo in the documentation:

panel_time_low_battery Switch There is a low battery condition on a zone/sensor.

Should be

panel_zone_low_battery Switch There is a low battery condition on a zone/sensor.

Great to hear you got it working. Yes I do define my DSC Alarm things through a .things file because it makes it easier to upgrade and start over if needed. If you are going to use the PaperUI to add your things, I would add the bridge manually, as the discovery for the bridge can be error prone (as seen in your error log), and add the other things from the inbox, which tends to have a pretty stable discovery method. I have seen the ‘UnknownCode’ error before, it seems to happen before the connection is made to the Envisalink or a refresh of a configuration file occurs. I will look at it closer, but I don’t think it is too much to be concerned about.

Not sure when this will become part of the main source code I will need to submit a PR, but I would like to hear back from another member who is testing it also.

Thank you for the feedback @Moxified!

Yeah, I spent the afternoon messing with it and went ahead and converted my old dsc.items over to the newer format and will use the text files. I came to conclude that text was the safest method.

I plan to do some more prep work (other stuff not DSC) and then will probably go live with this version of the plugin instead of using 1.9. Let me know if there is anything else you need tested to help move the PR along.

Did you write the documentation examples? It references icons that aren’t part of the included icons (at least for basicui). If so, would you be willing to share?

I wish I could but most are downloads for personal use only, and I wouldn’t want to violate any copyright restrictions. I am going to remove all the references to icons in the documentation samples. Sorry.

:cry:

I understand.

It’s just too bad that the icon sets seem so limited. I mean, there isn’t even a doorbell or dining room icon. All sorts of great programmers but no artists that can draw up more icons. I guess because we are all geeks and not graphic designers.

Couple of things have popped up.

First, on OH start, I get a large quantity of:
[WARN ] [calarm.handler.PartitionThingHandler] - DSC Alarm bridge handler not available. Cannot handle command without bridge.
[WARN ] [g.dscalarm.handler.PanelThingHandler] - DSC Alarm bridge handler not available. Cannot handle command without bridge.

Seems benign as everything works. Just might be something to peek at.

Also there are a couple of items that aren’t receiving the same info as with 1.9.

PANEL_MESSAGE isn’t updating with all of the same messages as it does with 1.9. Seeing similar results with PANEL_SYSTEM_ERROR.

I have a rule that monitors for the PANEL_MESSAGE to throw 672 or 502 codes which is a arm failure as well as PANEL_SYSTEM_ERROR = “024: API System Not Ready to ARM…”

PANEL_SYSTEM_ERROR has yet to receive anything and is blank. PANEL_MESSAGE just ignores the failed arm attempt and goes from 500 (successful command) to 550 current security time.

I see that PARTITION1_STATUS changes to Failure to Arm.

I can roll up my sleeves and try to find a different way to identify when a failed arm attempt happens but this has worked for over a year in OH 1 with 1.9 binding. It seems like the binding isn’t passing all info as I doubt my panel randomly stopped sending the error messages.

The sendcommand is working still though so that is great!

For more info, I put the binding in debug logging and sure enough, I see the 672 code I need… it just never goes to the PANEL_MESSAGE item. In general, the panel_message seems much quieter than with 1.9 when looking over my OH 1.8 logs.

OH2 logs:

Openhab.log

2017-02-24 15:37:42.677 [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-24 15:37:42.677 [DEBUG] [rm.handler.DSCAlarmBaseBridgeHandler] - handleIncomingMessage(): Message received: 15:38:06 6721D0 - Code: “672”, Name: “Failure to Arm”, Description: “672: An attempt was made to arm the partition and it failed.”, Time Stamp: 15:38:06, Partition: 1, Data: 1

Events.log

2017-02-24 15:36:13.173 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 550: The current security system time. to 500: A command has been received successfully.
2017-02-24 15:36:13.177 [ItemStateChangedEvent ] - NUM_DSC_Vender_Status changed from 550 to 500
2017-02-24 15:37:42.683 [ItemStateChangedEvent ] - PARTITION1_STATUS changed from Partition Not Ready to Failure to Arm
2017-02-24 15:37:44.681 [ItemStateChangedEvent ] - PARTITION1_STATUS changed from Failure to Arm to Partition Not Ready

As can be seen, Panel_message doesn’t get updated.

1.8 logs:

Openhab.log has nothing as it wasn’t in debug.

Events.log

2017-02-22 07:34:02 - PANEL_MESSAGE state updated to 672: An attempt was made to arm the partition and it failed.
2017-02-22 07:34:02 - PARTITION1_STATUS state updated to Failure to Arm
2017-02-22 07:34:02 - NUM_DSC_Vender_Status state updated to 672

In comparison, 1.8 vs 2 grep of panel_message snippet:

1.8

2017-02-23 10:30:21 - PANEL_MESSAGE state updated to 609: General status of the zone - open.
2017-02-23 10:30:21 - PANEL_MESSAGE state updated to 653: Partition can now be armed (Force Arming Enabled).
2017-02-23 10:30:25 - PANEL_MESSAGE state updated to 610: General status of the zone - restored.
2017-02-23 10:30:25 - PANEL_MESSAGE state updated to 650: Partition can now be armed.
2017-02-23 10:39:26 - PANEL_MESSAGE state updated to 609: General status of the zone - open.
2017-02-23 10:39:26 - PANEL_MESSAGE state updated to 653: Partition can now be armed (Force Arming Enabled).
2017-02-23 10:39:30 - PANEL_MESSAGE state updated to 610: General status of the zone - restored.
2017-02-23 10:39:31 - PANEL_MESSAGE state updated to 650: Partition can now be armed.
2017-02-23 10:54:25 - PANEL_MESSAGE state updated to 609: General status of the zone - open.
2017-02-23 10:54:25 - PANEL_MESSAGE state updated to 653: Partition can now be armed (Force Arming Enabled).
2017-02-23 10:54:29 - PANEL_MESSAGE state updated to 610: General status of the zone - restored.
2017-02-23 10:54:29 - PANEL_MESSAGE state updated to 650: Partition can now be armed.
2017-02-23 11:16:04 - PANEL_MESSAGE state updated to 609: General status of the zone - open.
2017-02-23 11:16:04 - PANEL_MESSAGE state updated to 653: Partition can now be armed (Force Arming Enabled).
2017-02-23 11:16:09 - PANEL_MESSAGE state updated to 610: General status of the zone - restored.
2017-02-23 11:16:09 - PANEL_MESSAGE state updated to 650: Partition can now be armed.
2017-02-23 12:01:31 - PANEL_MESSAGE state updated to 609: General status of the zone - open.
2017-02-23 12:01:31 - PANEL_MESSAGE state updated to 653: Partition can now be armed (Force Arming Enabled).
2017-02-23 12:01:35 - PANEL_MESSAGE state updated to 610: General status of the zone - restored.
2017-02-23 12:01:35 - PANEL_MESSAGE state updated to 650: Partition can now be armed.

2.0

2017-02-24 15:21:45.599 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 500: A command has been received successfully. to 912: Tells the API to enter an access code.
2017-02-24 15:22:08.090 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 912: Tells the API to enter an access code. to 500: A command has been received successfully.
2017-02-24 15:23:55.103 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 500: A command has been received successfully. to 550: The current security system time.
2017-02-24 15:24:18.102 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 550: The current security system time. to 500: A command has been received successfully.
2017-02-24 15:27:55.127 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 500: A command has been received successfully. to 550: The current security system time.
2017-02-24 15:28:38.128 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 550: The current security system time. to 500: A command has been received successfully.
2017-02-24 15:31:54.651 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 500: A command has been received successfully. to 550: The current security system time.
2017-02-24 15:32:58.154 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 550: The current security system time. to 500: A command has been received successfully.
2017-02-24 15:35:54.675 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 500: A command has been received successfully. to 550: The current security system time.
2017-02-24 15:36:13.173 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 550: The current security system time. to 500: A command has been received successfully.
2017-02-24 15:39:54.703 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 500: A command has been received successfully. to 550: The current security system time.
2017-02-24 15:40:33.199 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 550: The current security system time. to 500: A command has been received successfully.
2017-02-24 15:43:54.729 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 500: A command has been received successfully. to 550: The current security system time.
2017-02-24 15:44:53.224 [ItemStateChangedEvent ] - PANEL_MESSAGE changed from 550: The current security system time. to 500: A command has been received successfully.

1.8 has several numbers, 609,610,653,650. 2.0 has basically 500 and 550 with one 912 when I executed a pgm.

I will definitely look into these issues. One thing you might try is to turn on the ‘Suppress Acknowledgement Messages’ in the Panel configuration parameters. You can do this in the PaperUI or in a .thing file like so:

Thing panel panel "DSC Alarm Panel" [ suppressAcknowledgementMsgs=true ]

I assume that is to suppress the errors? It didn’t seem to make any difference.

I was able to rewrite my rule to use the Failure to Arm status. Hopefully it will be reliable. I just didn’t want to revert to OH 1.8.

Thanks!

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.