Alarm.com reporting latency for sensor status and history

Support
1

I set up 2 DSC systems with ADC and Surety recently and am seeing some confusing behavior with latency/delays/accuracy of some of the zones (for both the current sensor status, and the activity history of those sensors). This isn’t exactly a support request; I’m just wondering what the intended/documented behavior is, what others’ experience is, and if there are perhaps some changes I should make to get my systems working better.

I said 2 DSC systems; I have an older one which is PowerSeries (PC1832) with the alarm.com SEM, and is fully deployed, and a newer one which is PowerSeries Neo (HS2064) which supports alarm.com natively, but which is brand new and only partially installed. Most of this post reflects my experience with the PC1832+SEM.

My experience with sensor reporting latency falls into 3 distinct buckets:

  1. contact sensors configured for normal arming (DSC zone type 01 or 03, Surety/ADC website shows these as reporting type “Door/Window” and “Door/Window or Glassbreak”) – these report status and history reliably but with notable latency (1-3 minutes from closed to open in my experience, sometimes open to closed gets reported immediately and sometimes it doesn’t)

  2. contact sensors configured for stay/away arming (DSC zone type 05 or 06, Surety/ADC website shows these as reporting type “Cabinet/Safe/Interior Door”) – these mostly report status and history reliably with the same latency as bucket #1, but sometimes the history events get batched together for the same device (I’ll see a flurry of consecutive “Opened” events without intervening “Closed” events), and a few of these devices essentially never change status even over days. However the current status does agree with the history (either both correct, or both stale).

  3. motion sensors configured for stay/away arming (DSC zone type 05 or 06, Surety/ADC website shows these as reporting type “Motion” as well as physical type “Motion”)). These behave with the same delays and discrepancies as I noted in bucket #2, but more so (more likely to delay or batch reporting for a sensor, also more likely a given sensor never reports at all). Further, the current status does not always agree with the history (the current status can say Activated when the last history event was an Activated to Idle transition, or vice versa).

A couple caveats

  • none of this seems to affect use of the alarm and zone sensors as an alarm. If I arm the alarm, I think events from these zones are reported correctly for either triggering, or not triggering, an alarm. I’m talking here just about the zone status/history visible in the app and website, which I find useful for a number of cases: walk-testing the alarm, giving me confidence the zone sensors are working correctly, giving me a general sense of who’s been in what areas of my house, and some automation use cases, plus “you left the door open too long” alerts.

  • some of this might be peculiarities of the PC1832+SEM which is an older system not originally designed around ADC? Does this behave differently on newer or other systems? In particular, the newer PowerSeries Neo I’m in the process of installing, right now has only contact sensors programmed for normal arming (what I called bucket #1) and there, I see the same “delayed by a minute or 3 but it arrives eventually” behavior I documented for bucket #1; I have not yet tried stay/away zone types with the Neo.

  • I’ll grant it’s possible that the delays and weirdness I’m talking about are between my sensors and panel, not between my panel and ADC. I don’t think this is the case. First, I see the same behavior for wired and wireless sensors; I don’t think it’s an RF problem. Second, I have other local sources of truth (keypad, DLS, walk test, envisalink) that indicate my sensors are reporting reliably and immediately to the panel. It’s only in ADC zone status/history I see weirdness. Third, I can make the same sensor go between the behaviors described in buckets 1/2/3 just by changing its zone type. (And for all these reasons, I’m omitting a bunch of “normal support request” details like which system, which zone, did I do RF troubleshooting, did I do communicator troubleshooting, etc. These details could matter, but I don’t believe they do. Overall I’m trying to ask in this post about the baseline expected behavior for a properly configured system.)

A note on buckets #2 vs #3 and how they got configured at ADC+Surety: ADC infers the contact physical type, and reporting type, from the zone programming (at least for DSC panels), but Surety support can override that. Normally if you program a DSC zone for type 01 or 03 (delayed or instant entry), ADC infers physical type contact, reporting type Door/Window (03 gets “Door/Windor or Glassbreak”), mapping to my bucket #1. If you program a DSC zone for type 05 or 06 (stay/away, delayed or instant), ADC infers physical type motion, reporting type Motion (mapping to my bucket #3). There’s no way to get to bucket #2 (a contact sensor with stay/away arming, with ADC treating it as a contact sensor) directly on a DSC system, without asking Surety support to customize that, as I understand it.

Finally, I understand ADC enforces a “max events per time period” or “cooldown period” for event status reporting, and it’s different for contact and motion sensors, something like 3 minutes for contact sensors and 1 hour for motion sensors. That would explain some but not all of the differences I see between bucket #1 and bucket #3, but doesn’t explain why bucket #2 acts differently from both #1 and #3.

All that said, there are a couple distinct things I want to ask about.

a) minimum latency for reporting the first change to a zone that has not changed status in a while. Say a door has been closed for an hour and I open it, what’s the soonest I should expect that to show up in the app? Right now that can be multiple minutes; that’s not a dealbreaker but was hoping for better.

b) anyone else seen, or can explain, the behavior where DSC stay/away zones are not reflected correctly in the app or website view of sensor status and history, basically ever? My system has ~6 such zones, 4 of them have roughly accurate status and history, 2 of them just don’t change status ever in the ADC/Surety app view. (The panel definitely sees them change status, I can even use them to trigger an alarm which is reflected at ADC+Surety, the status changes just don’t show up on the “sensors” view or the history view, even after multiple hours.)

c) I want to draw attention to the distinction between buckets #2 and #3. For the same sensor and the same zone programming (DSC zone types 05 and 06), ADC defaults to treating it as physical type Motion (bucket #3) and I understand that changes the cooldown period from 3 minutes to 1 hour. If I have Surety support change it to physical type Contact (bucket #2), that distinctly improves the behavior I see… in my experience, it’s distinctly more likely to show all transitions in history, to show those transitions pretty soon after they happen, and to keep history and current status in sync… but still not always (ie bucket #2 is still distinct from bucket #1). Other than the “cooldown period” or “max # of transitions reported per hour”, should there be any difference between the “motion” and “contact” physical types and reporting types on the ADC end?

d) overall, anyone have a good experience using stay/away zone types on a DSC system with ADC/Surety and having the live and historical sensor status reported accurately and promptly in the app/website?

e) overall, anyone have a great experience using normal zone types (not stay/away) on a DSC system with ADC/Surety and having the live and historical sensor status reported accurately and immediately in the app/website?

I want to be clear none of this is a deal-breaker and I’m grateful for the great support I’ve already gotten from Surety… the system works reliably as an armed alarm, and with the exception of sensor using stay/away zone types, it works reliably enough for my curiosity and automation purposes. My overall tone is, how well can I expect the app/website zone status reporting to work (for DSC systems, for these vintages of DSC systems, for different zone types, etc if those details matter). Very curious to hear either other peoples’ experiences or canonical advice. Thank you.

2

I have a dsc neo system and while I haven’t timed things I am seeing no real latency except with motion sensors reporting “closed” after being triggered.

For example when I leave my garage and the garage door closes which is a wired sensor that reflects in the alarm.com app as closed within a few seconds and then I can arm away thru the app.

3

If you are actively watching the app, leaving it open and watching the status as you open doors, it will not update immediately when the door opens. There will be a short latency period before the data is available to the app. This is probably 5-20 seconds most often. Refresh the app to see the status change. Shouldn’t be minutes though.

Are you seeing the same delay in the app and the website? Is there a difference?

If there is a difference, what kind of phone are you using, OS version, and what carrier?

Further, the current status does not always agree with the history (the current status can say Activated when the last history event was an Activated to Idle transition, or vice versa)

This isn’t normal. The current status for activity monitoring should reflect what is reflected as the last status change in history generally.

You mention walk testing the alarm. Are you actually turning on walk test mode on the panel?

4

Thanks all.

Transition from open to closed, on a contact sensor not configured for stay/away arming, is the best case, and shows up within a few seconds.

Transition from closed to open takes longer to show up - I’ll have to run some more scientific experiments with a stopwatch, but subjectively, it feels like it’s almost always longer than that 5-20 second, sometimes much longer – my experience feels more like 30 seconds to 3 minutes. I was curious if this is typical; sounds like it’s not, so I should do some more careful experiments/measurements.

I was using the mobile app, on a strong wifi connection backed by fiber. iPhone Pro Max 12, current iOS. I tend to just use my phone instead of carrying a laptop around when I’m walking around testing, but I can try the website and see if there’s any difference. I’m using pull down to refresh, instead of just waiting for it to update, and the pull-to-refresh succeeds (spinner goes away) within 1-2 seconds usually.

So: I’m happy to run more experiments and take more notes, trying cell network instead of wifi, website instead of mobile phone, etc and write down some hard numbers.

The current status for activity monitoring should reflect what is reflected as the last status change in history generally.

Great, that’s what I’m hoping for.

You mention walk testing the alarm. Are you actually turning on walk test mode on the panel?

I have done that to make sure that my wireless motion sensors were working properly, to rule that out as a factor, so I have turned on the walk test mode a couple times, but generally no, I meant that more informally as I was hoping to just walk around the house and try all the sensors and verify their function in the app, instead of turning on the real walk test mode and dealing with the noise. I realize that’s not as rigorous.

Oh, I also realized for my complaint about “bucket #2” devices (DSC zone type 5 or 6 meaning stay/away arm, but ADC treating it as a contact sensor), there’s a glitch on my end so my data point there might not be valid. One of the programming changes I made doesn’t seem to have stuck, and so there seems to be a wired and wireless sensor fighting to report on the same zone number which clearly wouldn’t work out well; I realized that last minute before I had to leave that site so I can’t fix it or run more experiments at the moment. When I get back to that location I’ll fix that issue and revisit my notes, but hopefully with correct zone programming, bucket #2 acts just like bucket #1; I don’t see a reason they should act differently.

5

I was finally able to return to this. The case I described in previous post about “glitch on my end”, the zone programming including wired/wireless issues was all correct, but the zone labels in the DSC panel+keypad were wrong which had confused me. I cleared that up, and the offending zone is working correctly locally (as soon as I open/close it, the local keypads show that correctly). The zone labels had always been correct in Surety/ADC (and the local zone labels being wrong, shouldn’t matter at ADC since I’ve changed them on the ADC side). However the zone showed always open in ADC, regardless of its actual status. I turned monitoring off and back on for this zone, and now it shows always closed, regardless of its actual status (and even after waiting several minutes in case it’s just slow). So I think what I have here is one specific zone in one specific system that’s messed up somehow, and not a general case, and I’ll file a separate support request on this.

Assuming I can get that fixed, it’s likely everything I said about “bucket #2” was a red herring based on experiences with a broken configuration.

I still intend to take more latency measurements and write down the general experience I get for reporting latency for ADC depending on

  • PoweSeries PC1832 vs Neo
  • zone type is contact vs motion
  • zone is connected as wired vs wireless if that matters (I don’t think it does)
  • loading the ADC UI over wifi vs cell network if that matters (I don’t think it does)

My general sense so far is that for both PC1832 and Neo, it takes somewhere between 30 seconds and 3 minutes for a contact sensor to show as open after a transition from closed->open, and much less time (5-15 second) for it to show as closed after a transition from open->closed. In PowerSeries Neo, motion sensors seem to work about the same (I’ve only tried wired motion sensors). In PowerSeries PC1832, motion sensors seem to work about the same if I have Surety override them as physical type = contact, and far worse (not really usable at all for status/history monitoring) if they stay as physical type = motion (and this is true for both wired and wireless motion sensors).

6

OK, ignoring zones that seem to be misbehaving, here’s my general experience for the PC1832 with SEM (dual path, cellular and ethernet through my router and cable internet).

I’m testing by leaving the mobile app running, opening or closing a door, and then repeatedly using pull-to-refresh in the mobile app until I see a change. Mobile app is running on an iPhone connected to strong wifi and cable internet, and the pull-to-refresh always succeeds in about 2 seconds.

Contact sensors using normal zone types (01 or 03), show as physical type = contact in the ADC UI: From closed to open, about 30 seconds from when I trip the zone to when it shows up in the ADC UI (web or mobile app). From open to closed, the latency is much lower (almost immediate, maybe 2 seconds on average) before the UI shows it as closed again.

Motion sensors using stay/away zone type (05), showing as physical type = motion in the ADC UI: Extremely unpredictable, I couldn’t get these to behave at all, and had Surety support change all of mine to physical type = contact.

Motion sensors using stay/away zone type (05), showing as physical type = contact in the ADC UI: hard to say what the exact latency is, sometimes they show up within ~30 seconds after I walk through the room, sometimes it takes longer, to go from “closed” (no activity) to “open” (activity detected). After activity is detected, they stay in “open” status for 50-30 minutes after activity stops, but they do go back to closed eventually. I realize there’s a lot more going on with motion sensors than contact sensors – the sensor itself has to detect motion, it has false positive elimination, it might not send the “zone violated” signal right away, once it does it stays in the “active” state for some period, there’s probably a cooldown timer in the motion sensor itself before it reports again, maybe additional cooldown timers in the panel, and cooldown logic in ADC’s software for zones they think are motion sensors. Plus wireless motion sensors might transmit even fewer events than that to save energy/battery life.

For what it’s worth, I have both wired and wireless contact sensors and both wired and wireless motion sensors, and I haven’t noticed the wireless ones acting any different than the wired ones (for both contact and motion sensors).

Overall, my experience with the PC1832 is: best case, newly open zone is reported about 30 seconds later, newly closed zone is reported almost immediately. Motion sensors that are overridden to be contact sensors in ADC, can take a little longer than that “best case” latency in the newly-tripped direction (transition from idle to active), and much longer (tens of minutes) of additional latency in the back-to-idle direction. And motion sensors that ADC considers to be motion sensors, in my experience are not usable for zone monitoring/history; not all events are reported and the status can lag by hours and the history and current status can disagree.

7

Testing my own system, I can see the timing of the open and closed you are referencing, though not as extreme.

Open sensors report about 10-15 seconds pretty consistently when actively refreshing as well as checking in dealer history, but closed does report sooner. It’s not something I really ever remember having quantified with real time vigilance of the app status, but it does seem odd. I’ll see what ADC says.

8

Was there any update on this? We have a laundry room door to the outside that gets open/closed quickly very often (garbage cans outside that area). Several times I have received a notification from ADC that the door has been left open. We then go and check and it is closed. It is defined as a door/window instant perimeter. I put a new battery in the sensor, but does not help. Also, I do have some sensor rules to turn the lights on outside that area if it is dark. Thanks.

9

I also checked locally. Opened and shut that door about 10 times and the panel was always 100% correct. Changed ADC to 60 minutes to notify. Maybe the sensor is too active.

10

Was there any update on this? We have a laundry room door to the outside that gets open/closed quickly very often (garbage cans outside that area). Several times I have received a notification from ADC that the door has been left open. We then go and check and it is closed. It is defined as a door/window instant perimeter. I put a new battery in the sensor, but does not help

This likely wouldn’t be a latency concern, if ADC is sending a left open notification that means the panel didn’t send or ADC didn’t receive and process the closed signal. Opening and closing the sensor again would resolve. If that door is frequently open and shut repeatedly it’s a more likely issue.

To best assist we would need to know when the left open notifications were sent which correspond to a time the door is actually shut. Can you confirm time stamps on those notifications?

Did you have the left open time set for less than 3 minutes? If so and the door is repeatedly opened, sensor activity delay may be impacting this.

11

I will monitor more closely if it happens again and note time stamps, etc. Where is the 3 min setting set? Don’t believe I changed anything except changing the ADM 30 min to 60 for notifications. Thanks.

12

I am referring to the duration of the sensor left open as a parameter in the notification.

You can select 1 or 2 minutes, but if the door opens and closes frequently there may be cases where the sensor activity delay results in unexpected delay in the notification.

If it wasn’t that low, it is likely an issue with the panel syncing the status with ADC. A timestamp would help us confirm what info ADC had and when the notification was first sent.

13

Where do you set the duration of the sensor left open? Thanks.

14

Login to Alarm.com. Click notifications. Edit your sensor left open notification. One of the parameters is the duration the sensor must be left open before the notification is sent.