I’ve been using openhab to arm/disarm my alarm for a while with good success. Just the other day I realized an issue with what I was doing. I have on my sitemap an item that represents partition_arm_mode. Thats 0 for disarm, 1 for away, 2 for stay. This has been working great but my wife pushed “away” sending a 1 the other day while the system wasn’t ready to arm. The DSC ignored the command completely but OH was convinced the alarm was armed away instantly.
If you watch OH, it does get a 502 error panel message so it’s not oblivious but all of my rules rely on that partition_arm_mode which changed to 1 and stuck that way until I armed and disarmed the alarm at the physical keypad.
Any suggestions on ways around this? The only thing I have come up with for now is to remove that item from my sitemap and create a new number that triggers rules that check for ready status and or error messages but I would rather avoid that if there is a simpler way. Complex rules often are buggy for a while as I’m not a true coder. (just today realized why a “ghost” had been ringing my doorbell… code snippet copy fail. It was actually my house telling me to open the windows.)
I think you will have to go down the rule path on this one. The problem is you need to create something that either prevents the arm command from being processed, or something to poll the alarm and change it back to the disarmed state if the arming failed. In both cases the only way I can think of to do that is with rules.
I am able to produce this condition also. The binding doesn’t check to verify that the alarm system is actually armed or disarmed when the command is issued. It just sends the command, sets the value, and assumes it is armed. I will look at the code and see if I can do some verification. In the mean time I think that it could probably be overcome in a rule as @rlkoshak has stated. A couple of messages come from the alarm system when this condition happens: a 672 (Failure to Arm) and a 651 (Partition not ready). Maybe these could be monitored for in a rule and used to reset the partition_arm_mode to 0 when received. Hope this helps.
@rsstephens
You may also want to turn off autoupdate on the Binding declaration, and use the response codes from the Panel as the positive indication that it’s moved into the correct state.
That’s how I did it on the DSC Panel implementation for Vera.
You’d effectively request an Arming state, via the functional equivalent of an openHAB Action, and you’d get events when it got there (state changes). The latter was used for any scene-based control. In openHAB, this would be nearly equivalent to having the binding do it (no Action binding needed), and adding the autoupdate="false"
I set autoupdate to false in the item file for the binding declaration of item PARTITION1_ARM_MODE, but that didn’t seem to make a difference as the binding is setting the state of partition_arm_mode. Maybe I’m missing something. I did write the following rule and that does reset the partition_arm_mode state to 0 if the partition_status is “Partition Not Ready” or “Failure to Arm”.
rule SetPartition1ArmMode
when
Item PARTITION1_ARM_MODE received command
then
if(PARTITION1_STATUS.state.toString == "Partition Not Ready" || PARTITION1_STATUS.state.toString == "Failure to Arm") {
postUpdate( PARTITION1_ARM_MODE, 0)
}
end
That rule wouldn’t cover all arm failures though. If the system failed to arm stay due to a door getting opened and left open for example. Since it only checks immediately upon requesting the arm, it would show that it armed but then miss the subsequent failure.
Also would fail to recognize if somebody started an exit delay and stopped the countdown via keypad or disarmed the system via keypad. Actually, this probably isn’t true as the dsc will inform OH. I’m not home so I can’t try.
When the DSC is arming in exit delay and it is interrupted, the DSC sends the message 655 (Partition Disarmed). When the binding receives this message it sets partition_arm_mode to 0. I did test it for that scenario and it worked. But you are right there could be other scenario’s that this rule could fail. The one caveat that I see with doing it this way is that the rule resets the partition_arm_mode to 0 after initially being set to another value through the sitemap. I guess that could be an issue if partition_arm_mode is being monitored through other means, such as another rule.
There would be a few more things that’d need to change.
If I’m reading the code correctly, when the arming state is requested that’s sent off as a cmd (like 030) to the DSC (which is good) but then the code immediately sets the Item state.
It’s this latter part that I handle differently. In my case, I consider the initial part as the request to arm and then I wait for the Arming confirmation (like 652) to come back before I set the Armed status information.
I split these apart intentionally, in order to handle the delays and/or cancellation events that can occur in the middle.
… I could also be reading the code incorrectly, since I did it in a rush this morning
Ah, I see now. You’re reading the code correctly. The binding code does set the arm status when it receives the arming confirmation 652, but the code that sends a request to arm command is also setting it, which needs to change. I see what needs to happen. I appreciate the feedback. Thanks Mark.
@david, I will apply the the changes to OH2 for sure. It will take a little longer because the structure is different and will take redoing some internal code. Thanks.
Hello,
I have an issue on OH2, DSC binding version 2.2.0.201709201937. I manage 2 partitions. Partitions 2 could be armed (away or stay mode) and disarmed without any problem. However, partition 1 could only be armed. If I try to disarmed it, it stay armed on the panel but the status in openhab is disarm.
I use sendCommand(PARTITION1_ARM_MODE, 0) and sendCommand(PARTITION2_ARM_MODE, 0). Why it’s working on partition 2 and not on partition 1?
I tried to set log file to debug mode but I did not get any error.
