The wife came home today and said the alarm went off the moment she opened the door as there was no entry delay to give her time to disarm the panel.
My panel auto arms in Arm Away (assuming all zones are secured) upon a 45 minute no response from our Ping Sensors, maybe the wife went shopping and didn’t arm the system (was my thinking when I created the scene) which happened today. ;D
However, I’m remembering (now) reading something somewhere if the Exit Delay is not engaged (opening and closing a door) during the arming sequence, the panel will Arm Instant. Is this true?
Would someone confirm if the Arm Instant engages (even if you select Arm Away) if the door is not opened and closed during arming?
The panel’s “*84 - Auto Stay Arm” programming option controls whether the alarm reverts to “STAY” mode when armed “AWAY” and you don’t exit / open a door. This option is enabled by default. (meaning if you don’t exit, the arm mode changes to “STAY” when armed “AWAY”) AFAIK there is not any option to arm “INSTANT” if you don’t exit the premises. (as doing so would only ensure false alarms)
Hmmm…So it is something I can change?
But I’m wondering how it’s enabled now vs not being enabled before and there has always been an exit delay when we come home, even when it’s auto-arming.
I’m sure it was @mcvflorin who wrote somewhere (although I could not find the reference) that the Away reverts to Stay mode (as you indicated) but Stay is Instant, so we are saying the same thing anyway.
And there are two “Instant” modes. ArmedInstant / MAXIMUM and StayInstant / INSTANT, neither of which are showing in my logs when the system is auto armed when the exit delay is not used. So I’m perplexed how the alarm went off this morning, when it armed in the same manner as it’s armed right now. Log output below.
The wife is on her way home now so I’ll see what happens here shortly when she opens the door this time.
50 06/28/12 16:44:25.238 luup_log:180: (VistaAlarmPanel::processIncoming) Incoming data = '[0100000110000000----],001,[f70000008001000c2c000000000000],"ARMED ***AWAY***** ALL SECURE **"'. <0x312d6680>
50 06/28/12 16:44:25.239 luup_log:180: (VistaAlarmPanel::getStatusFlags) Active flags: ARMED_AWAY, CHIME_MODE
*Edit. Exit / Entry Delay was functional, so the only thing I can assume now is, it was a coincidence that the alarm went off before.....Sigh.
Welcome! You can download v2.45 from the toolbar on your Dashboard. Apps > Install apps.[/quote]
Thanks for the feedback. I’ve actually made much progress since my initial post. So I’ve got the ad2usb installed, got the plugin downloaded, and have my panel up and running.
I created all my zones for my sensors. I seem to be having the same issue with the faulted zones never clearing. If I understand it correctly I need to update the TTL time to something other than 20 minutes if I want to have a more real time feedback.
I finally also have basic scene scripting running so I am going to try to use the created zones in some scenes. Based on the reading of the entire thread it sounds like using the sensors in scenes is somewhat fragile but we’ll see.
Thanks again for the feedback and the patience with my totally noob questions.
I seem to be having the same issue with the faulted zones never clearing. If I understand it correctly I need to update the TTL time to something other than 20 minutes if I want to have a more real time feedback.
I'm not sure why it's set at the default of 20 minutes, maybe to cutdown on the load presented to Vera?
I changed my TTL to 15 seconds over the weekend and a restart no longer keeps the zones tripped, although I'm not sure why it would have made any difference.....
I am going to try to use the created zones in some scenes.
In my garage I use it to turn off the exhaust fan when the overhead door is open, and in the house I have it turn off the HVAC if a window or slider is opened.
It's been very reliable.
The reason the TTL is 20 minutes by default is because that is the OnTime value for motion sensor in the 3-in-1 sensor. It’s also 20 minutes to prevent spamming our server with notifications. For example if the TTL is 15 seconds in an area with a lot of movement this means that a notification would be sent every 15-20 seconds.
[quote=“mcvflorin, post:466, topic:168766”]The reason the TTL is 20 minutes… to prevent spamming our server with notifications[/quote]Understood.
What would be beneficial to users and MCV alike (since it costs MCV $ to send the msg’s) is an email server of sorts, built into Mios/Vera seperate from your servers, such as AP15e’s SND, which is what I use, since I generate about 2k notifications/day.
I have been using the plugin with my panel successfully for a few weeks. I do notice a few issues and I’m not certain if others are seeing the same:
Whenever I arm the panel the UI never shows the panel as armed. The locked icon doesn’t change and the status always shows as “Not Ready” even though my panel indicates the alarm is armed and/or ready.
Otherwise, the plugin seems to work fine. This issue is a really hassle as I can’t tell remotely if the alarm is armed. Additionally, I want to create some scenes to do things like turn on the lights in an entryway if the alarm is armed and the door sensor trips. That won’t work without the armed status working correctly. Right before I added the AD2USB to my panel I had smoke detectors enabled in the system. The smoke detectors were already in the house in the existing system but they were not enabled for some reason. My panel indicates that one of the sensors should be checked; however, the panel ready light still shows the panel is ready.
Any ideas? I am runing the 2.45 version of the plugin.
Hi I’ve been using this plugin for a while now without problems. However, I recently upgraded my firmware and had to reinstall the Alarm plugin. I’m trying to store my PIN so I don’t have to type it in every time using Automator. I changed the secure state to 1 from default of 0 and then type in the pin and hit store. It works for a while but hen defaults back to no pin stored.
Am I doing this right? Whats the proper way to store pin so you never have to type it again. Before people get started I know this isn’t the securest thing to do. But I had it working before and note sure if the more recent plugin is working or not.
This could happen because the keypad address is not the correct one. How many partition do you have?[/quote]
I’m not sure about partitions. The alarm guy said that there were 2 other keypad devices. I have a hardwired keypad, plus another “virtual” (for lack of a better term) keypad that is used for the wireless sensor interface. I believe the address is for the keypad is set correctly.
[quote=“JOD, post:469, topic:168766”]
Whenever I arm the panel the UI never shows the panel as armed
Are you arming the panel from Vera?
I am using the UI to arm and disarm the system
The locked icon doesn't change
With 2.45 - Always showing locked is a known bug.
the status always shows as "Not Ready"
Do the zones change state as they are tripped/untripped?
Yes. For example if I put the system in “chime” mode the door sensors that I created with the cheat sheet will trip.
Are you able to view the log files?[/quote]
Yes. For example here is the log file when I attempt to arm the system to “stay” mode then disarm the system. I set the pin code right before arming the system so I’m not sure why it says undefined.
As I mentioned earlier Zone 9 reports an error on my display panel but the light on the hardwired display reports the system as READY even with that Zone 9 Error while the plugin UI always shows “NOT READY”.
First, the panel sends messages to devices on address 16 to 23, which means that you have 8 keypads(?).
Secondly, if the plugin detects an alarm, it doesn’t update the partition status variable, so whatever the last state it was in, this is what will be shown on the dashboard. So this is a plugin limitation, which will be fixed in the next plugin version, whenever it may be.
[quote=“mcvflorin, post:478, topic:168766”]First, the panel sends messages to devices on address 16 to 23, which means that you have 8 keypads(?).
Secondly, if the plugin detects an alarm, it doesn’t update the partition status variable, so whatever the last state it was in, this is what will be shown on the dashboard. So this is a plugin limitation, which will be fixed in the next plugin version, whenever it may be.[/quote]
OK - thanks. That’s what I suspected was that the fault on the fire alarm was causing the plugin issues. The panels 16-23 being enabled is because my installed enabled all the panels on the controller while we were debugging the AD2USB. So if I clear the fire fault on that particular zone I believe that will fix the issue using the existing version of the plugin. Do you agree?