I have a DSC PC1832 panel with Envisalink 3 and using the DSC plugin. For the most part things were easy to setup and works well. I have a need to determine if a zone was bypassed when the alarm was armed from the keypad and can’t figure it out.
The scenario- We have glass break detectors and we also have dogs. The dogs can sometimes trip the glass break detectors if they bark when we are away. We bypass the glass break detectors when arming AWAY if the dogs are in the house. What I would like to do is set the AC to 77 if the dogs are inside and set the AC to 81 if they are outside. So I wanted to test if a zone is bypassed to set the AC.
I thought that I could use the Alarm Detailed State and test for ‘Force’ but the detailed state is always ‘Armed’ regardless of whether a zone is bypassed or not. I’m assuming that’s because the zone is not open, it’s just bypassed.
So the question is, is there a way to determine if a zone is bypassed when the alarm is armed or being armed?
I’ve not seen a way to retrieve the Bypass status of a Zone via the API, but you may be able to use Status code 702 “Partial Closing”, in an Advanced Scene, to determine that at-least-one Bypass was present at time of arming.
It wouldn’t be particularly localized, since it would occur if any Bypass were present in the system, but it would get you closer. There are a few threads here that talk about using this Advanced Scene logic to do tricks like this.
Well I did a whole lot of searching and learned a lot, however I have been unable to get the panel to generate the code 702. I also tried looking for code 653 (Partition Ready ? Force Arming Enabled) but couldn’t see that code either as I was bypassing,arming and disarming from the keypad. The only codes I’ve seen (in the logs) so far are 650, 651, 652, 655, 656 and 841.
The keypad definitely knows that you are bypassing a zone, it warns you. So I imagine the Envisalink can see it too (since it connects like a keypad) and maybe just not passing it through? I have the latest firmware on the Envisalink 3.
Is there some programming needed on the DSC panel itself for it to generate the 702 code? I can do that if needed.
I’m just running by what’s in the API guide itself, but you might need to go through the installer guide since it’s quite possible that this level of reporting needs to be enabled.
Partial Closing is mentioned, for example, under section 341 “Miscellaneous Closing (Arming) Reporting Codes”… but what needs to be put into that field I have no idea.
In the EyezOn log it shows Partial Closing. I am trying to use the VendorStatusCode to trigger a scene but no luck. I read a post by #strangely somewhere on this forum that the vendor status codes were not working for partition level events so I may be out of luck looking for 702.
There may be another way…in the Vera logs I did see Code 510 which is sent when one of the keypad LEDs change (like when arming) along with the state of each LED stored in the VendorStatusData. One of the LEDs is for Bypass and sure enough, in the log, the data for Bypass is on when a zone is bypassed. So i tried using VendorStatusCode 510 to trigger a scene and then check the VendorStatus Data to see if the Bypass light is on. Oddly code 510 doesn’t trigger.
Is using the VendorStatusCode as a trigger event the correct method or am I going about this all wrong?
If you're seeing that in the EyezOn logs, then there should be a counterpart in the Vera logs... even if nothing else fires (Scene wise).
It’ll be in the form of a “…[tt]processIncoming::[/tt]” debug log line in the [tt]/var/log/cmh/LuaUPnP.log[/tt] file.
Is using the VendorStatusCode as a trigger event the correct method or am I going about this all wrong?
That's the right way.
The [tt]VendorStatus*[/tt] variables are present, at the Partition level, and looks to be hooked to the correct location within the code. Are you seeing values for these, on the Partition Device?
These should always have the last panel-level event on them, in a vendor specific format and will be visible under the Advanced Tab of the Partition Device
They’re definitely not there for Panel level events, but they should be for Partition level stuff (but I admit, it’s been some time since I ran the code, since I use a different panel)
It’ll be in the form of a “…processIncoming::” debug log line in the /var/log/cmh/LuaUPnP.log file. Yes, I do see the “…processIncoming…” in the vera log but only for the codes I mentioned in the earlier post. Not for code 702 or 653 even though they do appear in the EyezOn log. The sequence I get in the vera logs is; 650 Partition Ready, 656 Exit Delay in Progress, 510 Keypad LED State, 652 Partition Armed. The EyezOn log is much more detailed as far as the status changes go.
The VendorStatus* variables are present, at the Partition level, and looks to be hooked to the correct location within the code. Are you seeing values for these, on the Partition Device? In the alarm device Advanced tab I see the same codes that I see in the logs with the exception that I don’t see 510 but the 510 command is immediately followed by the 652 command and I wouldn’t be able to catch that since it happens so quickly. So I see 650 before attempting to arm, then 656 Exit Delay, followed by 652 Partition Armed once the delay ends.
[quote=“Netzero, post:13, topic:178070”]I got the beta version of firmware release 1.11 and code 702 is now working. No other issues found so far.[/quote]Thanks for the progress update.
When we’ve interacted with the Envisacor lads in the past, they’ve been extremely responsive. Sounds like you’re getting a similar experience from them. There’s another thread going on here about the 80x series codes, so hopefully they add themselves to the discussion on the eyes-on site, and that can be resolved also.
Best Home Automation shopping experience. Shop at Ezlo!