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:
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)
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.
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.
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.
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.
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?
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.
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:
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.
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:
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.