Announcement

Collapse
No announcement yet.

Strange non-report problem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Strange non-report problem

    A strange problem has popped up and I wonder if anyone else has seen it?

    I have a wireless Quickbridge connected to my Omni (actually have two) and I use a key fob to turn off my alarm. (Have panels also, but this is usually easier.) To get this to work, I have a line of Omni code that says then this zone is not ready, disarm the alarm.

    This works fine. I have a HS Event that triggers when my garage door is opened, and it announces "disarm alarm" every 10 seconds. Each time just before I speak, I check the HAI interface state, then check to see if the alarm has been disarmed, and if it has, I exit, otherwise I speak and repeat.

    Now the strange problem. About 50% of the time, the HAI interface doesn't report back that the alarm is disarmed UNTIL the full entry delay, even know I disarm it much before that. Another words, if I have an entry delay of 60 seconds, and I shut the alarm off in 20 seconds, it still reports its armed AWAY for 40 more seconds.

    As I said above, I do an interface check every time and don't get an error. Also tried a plain old HS Event on an alarm state change, and that doesn't trigger until after the full entry delay either. Is this a bug in the HAI panel? I think I can get around it by checking the key fob zone status instead on the alarm state, but I'm not sure why I need to?

    Here is the log:

    2/25/2004 4:51:17 PM~!~Event Trigger~!~HAI Zone Triggers Large Garage Door Open
    2/25/2004 4:51:17 PM~!~Send X10 from ext interface~!~Garage Lights Off dim: 0 extra: 0
    2/25/2004 4:51:28 PM~!~Speak~!~Disarm Security System Now.
    2/25/2004 4:51:39 PM~!~Speak~!~Disarm Security System Now.
    2/25/2004 4:51:49 PM~!~Speak~!~Disarm Security System Now.
    2/25/2004 4:51:59 PM~!~Speak~!~Disarm Security System Now.
    2/25/2004 4:52:09 PM~!~Speak~!~Disarm Security System Now.
    2/25/2004 4:52:19 PM~!~Speak~!~Disarm Security System Now.
    2/25/2004 4:52:29 PM~!~Speak~!~Disarm Security System Now.
    2/25/2004 4:52:39 PM~!~WARNING~!~Alarm Entry Warning Expired. Possible Alarm Trip.
    2/25/2004 4:52:39 PM~!~Event Trigger~!~HAI Zone Triggers Garage Beam Crossed
    2/25/2004 4:52:39 PM~!~Event Trigger~!~HAI Zone Triggers Set Garage Motion Virtual On
    2/25/2004 4:52:39 PM~!~MOTION~!~\\\\\\\\\\ Garage Occupancy Sensor set to "occupied" - Vacant (00:00)
    2/25/2004 4:52:39 PM~!~Event Trigger~!~HAI Zone Triggers Set Garage Motion Virtual On
    2/25/2004 4:52:40 PM~!~Event Trigger~!~Value change trigger (Security System Changed Status):Security Status from: 3 to: 0

    You wouldn't know it but I actually shut off the alarm after the second "disarm" message at 4:51:39 but the status didn't change until 4:52:40

    [This message was edited by anogee on Wed, 25 February 2004 at 11:07 PM.]

  • #2
    Update: The problem seems to effect zone communication as well. It seems the Omni just stops communicating (but doesn't return an error) during the entry delay, even if the alarm is disarmed sooner.

    Comment


    • #3
      anogee,

      I am not 100% sure about this, but if I remember it when Tom Morgan gives me a call in the next day or two, I will ask him (he used to work for HAI) but I think it is the communicator guard. In other words, when the panel is invoking the communicator for potentially dialing up the monitoring company, that takes precedence over everything else. Since the entry delay is a delay before a burglar alarm, they may be shutting down the other functions in case they need to dial. It is overkill IMHO since killing the alarm in some timeframe like 15 seconds or so after the full blown burglar alarm starts will prevent a dial-out, your total time is absurdly long to be preventing other communication from happening. Nonetheless, if it is consistent, then I bet it is by design.

      If all else fails, call HAI to confirm.

      Regards,

      Rick Tinker (a.k.a. "Tink")
      HomeSeer Technologies

      Regards,

      Rick Tinker (a.k.a. "Tink")

      Comment


      • #4
        Thanks Rick.

        I figured it had something to do with that as it seemed to be so consistent. Probably just in case it must report an alarm, it is being extra safe until it knows all is clear.

        Comment

        Working...
        X