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:
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)
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).
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.