DSC PowerSeries Neo (IT-2 / TL280)

GEM integrates with a DSC PowerSeries Neo alarm panel through the panel's ITv2 integration protocol — the same protocol DSC's TL280 / TL280E network communicators speak. One GEM device represents the whole panel. From there GEM can arm and disarm partitions, watch every panel zone go open/closed/in-alarm, follow exit/entry-delay countdowns, surface panel trouble and alarm conditions, and bypass zones — all over the building LAN with no cloud account involved.

This is a local, encrypted integration. The session is secured with AES-128 keying that the panel and GEM negotiate automatically.

Hardware this driver supports

GEM lists this driver as DSC IT-100 / IT-2, but it speaks the ITv2 integration protocol used by the TL280 / TL280E communicator on DSC PowerSeries Neo panels (HS2016 / HS2032 / HS2064 / HS2128). It is not the legacy IT-100 RS-232 serial module, which uses a different text protocol — pair this driver with a Neo panel that has a TL280/TL280E (or the equivalent built-in integration communicator), not an IT-100 serial board. For older PowerSeries panels reached through an Eyez-On module, see Envisalink EVL-4; for cloud-monitored systems, see Alarm.com.

The panel connects to GEM — not the other way around

Unlike most network devices, GEM does not dial out to the panel. GEM opens a listening port and the panel/communicator connects inward to it (a "panel-initiated" session). That means two things during commissioning: you program GEM's server IP into the communicator, and you make sure the communicator can reach GEM on the integration port (default TCP 3072, plus UDP 3073). There is nothing for GEM to "find" — it waits for the panel to call in.

What you get

• Arm / Disarm per partition: arm away, arm home (stay), arm night, arm with no entry delay, and disarm — issued from GEM as device commands you can put on a UI button, a macro, or a trigger.
• Live zone state, auto-created. GEM creates a zone for each panel zone the first time the panel reports on it, under the Security subsystem, and tracks its real-time condition (open/closed, plus tamper, fault, low-battery, and alarm flags).
• Partition feedback. Each partition's armed/disarmed/exit-delay/entry-delay/alarm state is published back onto the device, so the homeowner Security control and your automations can react to it, including a live exit/entry-delay countdown.
• Trouble and alarm reporting. Partition troubles, alarms, and per-device trouble detail are published as device attributes as the panel raises and clears them.
• Zone bypass. Bypass and un-bypass individual zones — and because the panel reports each zone's bypass state, the homeowner Security control's on-screen Bypass buttons work and show bypassed zones with a badge.
• Panel user management. List the panel's user slots, enable and disable users, and set access codes, keypad labels, user attributes (supervisor, duress, bypass, remote access), and per-user partition assignments — from GEM, without walking to a keypad.

Prerequisites

• A DSC PowerSeries Neo panel with a TL280 / TL280E communicator installed, powered, and on the network, with healthy panel programming.
• Integration enabled in the communicator's installer programming (section 851 — see below).
• The panel's Integration ID (section [851][422]) and Access Code (section [851][423], 8 digits — or the 32-hex value in [851][700]).
• A valid DSC user code for arm/disarm.
• A static IP or DHCP reservation for the GEM server, programmed into the communicator (section [851][428]), and network reachability from the panel to the GEM server on TCP 3072 and UDP 3073.
• The Security subsystem (it ships by default, labeled Security). Auto-created panel zones land under it, and the built-in homeowner Security control looks here for the panel device.

Three different secrets — keep them straight

The Integration ID ([851][422]) identifies the session, the Access Code ([851][423]) encrypts/authenticates it, and a user code is what actually arms/disarms the panel. The Integration ID and Access Code come from the communicator's installer programming; the user code is an ordinary keypad code. Don't confuse the Access Code (an integration secret) with a user code (a keypad PIN) — they are not interchangeable.

Setup

1. Program the communicator for integration

In the communicator's installer programming (typically *8 + installer code), enable the integration session and point it at the GEM server. The exact keystrokes vary slightly by firmware; the essentials are:

• [851][428] — enter the GEM server's IP address (the machine running GEM). This is who the panel calls in to.
• [851][425] / [851][426] — enable integration and real-time notifications (so zone and partition events are pushed, not just polled).
• [851][422] — read the 12-digit Integration ID (you'll enter this in GEM).
• [851][423] — read the 8-digit Access Code (you'll enter this in GEM).
• [851][999] — reboot the communicator after changes (a brief keypad trouble during reboot is normal).

Typical TL280 / TL280E programming walkthrough

This mirrors DSC's TL280 configuration guide. Use it as a reference; your installer should follow the documentation for your exact panel/firmware.

1. Section 382 — enable option 5 (Alternate Communicator).
2. Section 300 — set Receiver 1 to Alternate Com Receiver 1.
3. Section 380 — confirm communications are enabled.
4. Section 310 — set a system account code (and the matching partition account code).
5. [851] > 005 — enable option 3 (DHCP), or program a static IP in sections 001/002/003/007/008.
6. [851] > 100 — turn on option 2.
7. [851] > 425 — enable options 3 and 5.
8. [851] > 426 — turn on option 3 (required for real-time notifications).
9. [851] > 428 — enter the GEM server IP.
10. [851] > 422 — read the Integration ID (12 digits).
11. [851] > 423 — read the Access Code (8 digits).
12. [851] > 999 — enter 55 to reboot the communicator.

2. Add the device

1. Open Devices and add a new device with the driver set to DSC IT-100 / IT-2.
2. Fill in the fields:
   • Integration ID — the 12-digit value from section [851][422].
   • Access Code — the value from section [851][423] (or [851][700]). Stored encrypted.
   • Master Code — a valid DSC user code used for arm/disarm when an internal caller omits one (the homeowner keypad always sends its own; a macro typically relies on this). Leave it blank and every code-carrying command is refused with no access code configured unless the caller passes code — the driver will not guess. Stored encrypted.
   • TCP Port — the integration port GEM listens on. Leave at the default 3072 unless you have a reason to change it; whatever you set here, the communicator must reach.
3. Save and enable the device. GEM starts listening and logs "waiting for panel connection". When the panel calls in, the log shows "session established" and the device goes Connected.

Who may command the panel

Two separate controls decide this, and they are not interchangeable.

The panel code is the floor, and it applies everywhere whether or not anything was configured. Disarm, zone bypass and the panel user-management commands answer access code required for a non-elevated caller who did not send a code argument — GEM will not substitute the stored Master Code for them. Anyone who knows a panel code can already do these things standing at the keypad; what this stops is a guest tablet or a REST session doing them without one, on GEM's stored credential.

Bypass is on that list because bypassing a contact on an armed system means the alarm does not trip for that opening — a disarm scoped to one door — and the central address confinement cannot narrow it, since every panel zone is published on this one device. Occupants are not shut out: the Security control prompts for the code on the bypass path exactly as it does for disarm.

Arming is not on that list. Arming is a security upgrade, and the callers that do it without a code are the ones that should — a voice "lock up the house", a keypad button bound to arm_away. The query_* / get_* status reads need no code either, so status widgets keep working on a wall panel.

Set a PIN on the Security control (UI → Controls) if the panel is reachable from a shared tablet. That is a separate gate in front of the whole control, and it is what stops a passer-by reaching the keypad at all.

The device Elevated flag is a blunter instrument again: an Elevated device refuses every command from a non-elevated session, arming and disarming included. Switch it on only where the panel is driven from admin sessions and macros alone — turning it on at a site with PIN wall panels takes arm and disarm away from them. Internal callers are untouched by any of this: an admin-authored "goodnight" macro that arms the panel, or a nightly bypass test, keeps working with no code written into it. See Roles → Elevated devices and macros.

Optional fields

• Module IP Address (ip) is not used to dial out — the panel initiates the connection. Leave it blank. The driver fills it in the first time the panel completes an encrypted session, using the address that session actually arrived from, and logs "learned panel address". A value you type here is only a starting guess; the observed one replaces it.

• Only Accept Sessions From Module IP (restrict_panel_ip) turns that address into an allowlist. With it on, an inbound connection from any other host is dropped immediately and logged as "refusing panel connection from unexpected peer", which keeps another host on the network from taking the session slot the panel needs — or from feeding GEM a forged arm/disarm/alarm event.

  The driver turns this on for you as soon as the panel's first encrypted session is established, so the pairing is open while you commission and closed for the rest of the install's life. Only a session that negotiated encryption counts, and encryption needs the access code — merely connecting to the port does not pin anything. A UDP-only panel is pinned the same way, from the address whose datagram carried a frame that came out of AES decryption; an address that merely sent a datagram is never used, because that can be forged.

  If the panel ever moves, clear this checkbox. The next session re-learns the new address and switches enforcement back on by itself; you do not need to type the address or reload the device. Give the communicator a static address or a DHCP reservation so this stays a one-time event.

• Auto-Pin Panel Address (auto_pin_panel_ip) is the off switch for the paragraph above. Leave it on. Turn it off only where the panel legitimately reaches GEM from more than one address — multi-homed, or NAT that does not preserve the source — which would otherwise lock the panel out after its first session.

• udp_port defaults to 3073; add it only if you moved the UDP side off the default, or set it to 0 to stop GEM listening on UDP at all and take panel sessions over TCP only. GEM listens on UDP whether or not your panel uses it, so if yours calls in over TCP, 0 closes a listener you were never using.

• log_level defaults to minimal. Set it to verbose temporarily to log every panel event while troubleshooting, then set it back.

3. Point the Security subsystem at the panel

So the homeowner Security control and the standard security workflow find the panel:

1. Open Subsystems and edit Security.
2. Set its Device to the DSC panel you just added.
3. Save.

The subsystem's Device is how GEM resolves "the security panel" for the homeowner control.

4. Let the zones auto-populate

You do not create panel zones by hand. The first time the panel reports on a zone (on connect, or when the zone opens/closes), GEM auto-creates a zone under the Security subsystem:

• the zone address is the panel zone number,
• the zone label is "<device> Zone <n>" — rename it to something friendly (for example Front Door, Kitchen Motion),
• the zone state then tracks the panel in real time.

Open Zones and filter to the Security subsystem to confirm they appeared. Naming a zone with words like "door", "window", or "motion" helps — the homeowner Security control groups zones into Doors, Windows, Motion, Smoke, and Water by matching keywords in the label. If a zone never appears, confirm the Security subsystem exists (auto-create is skipped without it).

5. Disable arming from the touch panel (optional)

The built-in homeowner Security control enables its arm/disarm buttons by default. To turn arming off for a site, add the attribute arm_enabled (type boolean) to the Security subsystem and set it to false — the control then shows "System arming is DISABLED." A subsystem with no arm_enabled attribute arms normally.

Arming and disarming

Arming is done with device commands. The driver exposes:

Command	What it does
arm_away	Arms the partition in Away mode (perimeter + interior).
arm_home	Arms in Stay / Home mode (perimeter only).
arm_stay	Same as arm_home — an alias for stay arming.
arm_night	Arms in Night mode (stay arming with the panel's night settings).
arm_no_entry_delay	Arms away with the entry delay suppressed (instant).
disarm	Disarms the partition.

Each arm/disarm command takes two arguments:

• code — the DSC user code sent to the panel. The panel validates it, so it must be a real user code. If a command omits code, the driver falls back to the device's Master Code — for macros, triggers, schedules and elevated sessions. A non-elevated caller must send its own (see Who may command the panel above), and if the Master Code attribute is blank nobody gets a fallback: the command answers no access code configured and nothing is sent to the panel.
• partition — the partition number. If omitted it defaults to partition 1, which is the only partition the homeowner Security control targets.

You can fire these three ways:

• For testing — run the command from the device's command list or the Commands screen with code (and partition if needed) and watch the result.
• From a UI — the homeowner Security control's Arm Home, Disarm, and Arm Away buttons map to arm_home, disarm, and arm_away. Each prompts for a code on an on-screen keypad (minimum 4 digits) and sends it to the panel as the user code.
• From automation — call the command in a macro or trigger (for example, "arm Night when the house goes to Sleep mode"). See Macros and Triggers. Put the user code in the step's code argument, or rely on the device's Master Code.

Reading the panel's state

The partition's current state is published to the device's arm_state attribute as one of disarmed, armed_home, armed_away, armed_night, exit_delay, entry_delay, or alarm. Per-partition state is also published as partition_<n>_state (partition_1_state, partition_2_state, …). A macro condition or trigger can read these — for example to avoid re-arming an already-armed system, or to flash a light during entry delay.

The homeowner Security control reads arm_state for its big status banner and to highlight the active arm button, and it shows a live exit/entry-delay countdown driven by the panel's reported delay duration.

Multiple partitions

The homeowner Security control only ever targets partition 1. To arm or disarm a second partition, call the command from a macro or the Commands screen with the partition argument set to that partition number.

Zones and live state

Each auto-created GEM security zone mirrors its panel zone. As the panel reports events, the driver updates these attributes on the zone:

Attribute	Meaning
state	open or closed — the zone's open/closed condition.
alarm	true while the zone is in alarm.
tamper	true while the zone reports tamper.
fault	true while the zone reports a fault.
low_battery	true for a wireless zone with a low battery.
delinquency	true while the zone reports a supervision/delinquency fault.
alarm_in_memory	true if the zone was in alarm since the last disarm (alarm memory).
bypassed	true while the zone is bypassed.

In the homeowner Security control a zone shows red when it is open or faulted, orange when bypassed, and green otherwise; faulted zones float to the top of their group. You can search zones by name and toggle between Show Faults, Show All, and Show Bypass.

Zone bypass

The driver provides bypass_zone and unbypass_zone. Both take the panel zone number in the address argument, plus optional partition (blank is partition 1) and code (see the code requirement above):

• From a macro or the Commands screen: bypass_zone with address = 5.
• From the homeowner Security control: tap a zone to bypass/un-bypass it, or use Bypass Faulted to bypass every open zone at once. The control passes the zone's address, which is exactly what these commands expect, and the panel-reported bypassed flag drives the on-screen BYPASS badge.

From a non-elevated session — a guest tablet, a PIN wall panel, a REST client — both commands require the caller to send a code, and answer access code required without it. The Security control already prompts for one on this path, so the on-screen bypass badges work as they always have; a script that omitted the code does not. Macros, triggers and schedules are unaffected and may omit it — bind an admin-authored "bypass the patio door" macro to a button when occupants need it without typing a code at all.

Panel user management

The driver can read and program the panel's user slots (access codes) over the integration session. These are the same users you would otherwise manage from a keypad with *5 programming.

These commands need the panel's master code

User programming runs in the panel's Access Code Programming mode, which the panel only opens for the master code — user 1's code. Every command below takes an optional code argument; if omitted, the device's Master Code attribute is used — but only for macros, triggers, schedules and elevated sessions. A non-elevated caller must pass code itself and is refused with access code required otherwise. If the Master Code attribute holds an ordinary user code (fine for arm/disarm), user-management commands will be rejected by the panel — pass the real master code in code, or set the Master Code attribute to it.

Command	Args	What it does
get_users	start, count, code	Lists user slots: label, enabled/disabled, code length, attributes, partitions, proximity-tag flag. Defaults to all slots the panel reports.
enable_user	user, new_code, code	Enables a user by assigning a 4, 6, or 8-digit access code.
disable_user	user, code	Disables a user. The slot keeps its label; the code is replaced with the panel's "disabled" sentinel.
set_user_code	user, new_code, code	Changes an existing user's access code (PIN).
set_user_label	user, label, code	Sets the user's keypad label (max 14 characters; longer labels are truncated).
set_user_attributes	user, attributes, code	Sets attribute flags. attributes accepts a comma list of names (supervisor, duress, bypass, remote, bell_squawk, one_time), a JSON object, or a raw flags number. Flags not listed are cleared.
set_user_partitions	user, partitions, code	Sets which partitions the user's code works on, as a comma list or JSON array (e.g. 1,2). Partitions not listed are removed.

Example — onboard a house sitter from a macro or the Commands screen:

1. enable_user with user = 10, new_code = 4821.
2. set_user_label with user = 10, label = House Sitter.
3. set_user_partitions with user = 10, partitions = 1.
4. When they leave: disable_user with user = 10.

Rules the panel enforces (the driver surfaces these as command errors):

• User 1 is the master. It cannot be disabled, and the panel owns its attributes and partition assignments — only its code and label can be changed.
• Enable/disable resets the slot. When a slot crosses between enabled and disabled, the panel resets that user's attributes and partition assignments to its defaults. Re-apply them after enabling (as in the example above).
• Codes are 4, 6, or 8 digits, matching the panel's configured code length.
• Access codes are never returned. get_users reports whether each slot is enabled and the code's length, but never the code itself, so PINs don't end up in logs or command history. Codes sent to the panel are scrubbed the same way: code and new_code arguments are redacted from Request History before the request row is stored, so the master code and a newly assigned PIN never sit in the request log either.
• Users edited at a keypad while GEM is connected are announced by the panel; the driver logs which slots changed.

Attribute reference

Device attributes — configuration

Attribute	Required	Type	Notes
integration_id	yes	string	Integration ID, section [851][422]. Shown as Integration ID.
access_code	yes	string (secure)	Access Code, section [851][423] (or 32-hex [851][700]). Shown as Access Code.
master_code	yes	string (secure)	Default DSC user code used for arm/disarm when a command omits code. Must be the actual master code (user 1) for the user-management commands to work without an explicit code. Shown as Master Code.
port	yes	integer	TCP port GEM listens on for the panel. Default 3072. Shown as TCP Port.
ip	no	string	Module IP. Not used to connect (the panel initiates). Learned automatically from the first encrypted panel session — leave it blank. Shown as Module IP Address.
restrict_panel_ip	no	boolean	Enabled automatically once the panel completes its first encrypted session. When on, inbound panel sessions from any address other than ip are refused — TCP connections and UDP datagrams alike. Ignored (with a warning) if ip is empty. Clear it to re-learn a panel that moved. Shown as Only Accept Sessions From Module IP.
auto_pin_panel_ip	no	boolean	On by default. Records the address of the first fully established, encrypted panel session as ip and enables restrict_panel_ip. Turn off only where the panel reaches GEM from more than one address. Shown as Auto-Pin Panel Address.
udp_port	no	integer	UDP port for the ITv2 session. Default 3073. Set to 0 to disable the UDP listener and accept panel sessions over TCP only. Shown as UDP Port.
log_level	no	string	minimal (default), verbose (logs every panel event for debugging), or silent.

Device attributes — published by the driver

These appear automatically as the panel reports state; you don't set them.

Attribute	Type	Notes
arm_state	string	Current panel state: disarmed / armed_home / armed_away / armed_night / exit_delay / entry_delay / alarm.
partition_<n>_state	string	Per-partition state, same values as arm_state.
partition_<n>_ready	boolean	true when the partition is ready to arm.
partition_<n>_alarm	boolean	true while the partition is in alarm; clears on restore.
partition_<n>_trouble	boolean	true while the partition reports a trouble; clears on restore.
partition_<n>_trouble_flags	integer	Raw trouble bit-flags for the partition.
partition_<n>_exit_delay	boolean	true during the partition's exit delay.
partition_<n>_exit_delay_duration	integer	Exit-delay length in seconds, used for the on-screen countdown.
max_zones	integer	Panel capability — maximum zones, learned on connect.
max_partitions	integer	Panel capability — maximum partitions, learned on connect.
trouble_<type>_<number>	string	Detailed per-device trouble (e.g. a specific sensor's trouble state) when the panel reports it.
connected	boolean	Online flag — true while a panel session is established.

Zone attributes

Attribute	Required	Type	Notes
address	yes	string	The panel zone number. Filled in automatically when the zone is auto-created.
state	auto	string	open / closed.
alarm, tamper, fault, low_battery, delinquency, alarm_in_memory, bypassed	auto	boolean	Zone condition flags (see Zones and live state).

Diagnostic commands

These query the panel on demand and are mainly useful for commissioning and support. They don't change the panel's armed state.

Command	Args	What it does
get_zones	—	Returns the driver's cached zone states.
get_partitions	—	Returns the driver's cached partition states.
get_system_state	—	Returns cached partitions plus zones in one call.
query_capabilities	—	Asks the panel for its capabilities (max zones/partitions).
query_global_status	—	Requests a full global status refresh.
query_zone_status	address, count	Queries zone status starting at a zone number; count limits how many zones are reported.
query_partition_status	partition	Queries a partition's status.
query_zone_bypass_status	address	Queries a zone's bypass state.
query_trouble_status	—	Requests the current system trouble list.

How it works

Listening for the panel. When the device is enabled, GEM opens a TCP listener on the configured port and waits — the log reads "waiting for panel connection." The panel (via its TL280/TL280E communicator) connects inward to GEM's IP and port. GEM never dials the panel, so a device that stays Disconnected almost always means the communicator can't reach GEM (wrong server IP in [851][428], or a firewall blocking the inbound port).

Encrypted session. Once the panel connects, GEM and the panel negotiate AES-128 keying (Type 1 or Type 2, auto-detected) using the Integration ID and Access Code. The log reports the encryption type on "session established."

State is only believed once that session is established. Zone open/close, partition arm/disarm, alarms and troubles are acted on only after the handshake completes, an encryption type is negotiated, and receive decryption is actually keyed; anything arriving before that is logged and ignored ("ignoring … panel session not established/encrypted"). Without it a plaintext frame from any host on the LAN would parse, and a forged partition:disarmed would make GEM report the building disarmed and fire whatever automation is keyed on arm_state. Connection and lifecycle logging is unaffected, and a healthy panel reaches this state within the first exchange.

Initial pull, then events. On connect GEM queries capabilities and an initial status pull ("status ready"), so partitions and known zones populate right away. After that, updates are event-driven — the panel pushes zone open/close, partition arm/disarm, exit/entry delay, alarms, and troubles as they happen, and the driver maps each onto the matching attribute. A heartbeat keeps the session alive.

Auto-reconnect. If the listener can't start (for example the port is in use) the driver retries with an increasing backoff. If the panel drops the session, the log reads "session closed, waiting for panel to reconnect" and GEM accepts the next inbound connection automatically.

Known limitations and notes

• Panel-initiated only. There is no outbound "connect to the panel" path; GEM listens and the communicator must be programmed with GEM's IP. A NAT or firewall between them must allow the inbound integration ports.
• Single partition from the touch panel. The homeowner Security control targets partition 1. Multi-partition arming has to be driven from macros/commands with an explicit partition.
• Master Code is the arm/disarm fallback, for internal callers. Macros and triggers that don't pass a code use the device's Master Code; keep it set to a valid DSC user code. The homeowner keypad always supplies its own. With the attribute blank there is no fallback at all and no guessed default — code-carrying commands answer no access code configured rather than spending an attempt at the panel, which would count toward its lockout.
• Trouble flags are raw. partition_<n>_trouble_flags is a numeric bit-field straight from the panel; trouble_<type>_<number> carries the human-readable per-device detail when the panel sends it.

Troubleshooting

Symptom	Check
Device stays Disconnected; log shows "waiting for panel connection"	The communicator isn't reaching GEM. Confirm GEM's server IP in section [851][428], and that the panel can reach GEM on the integration port (default TCP 3072 / UDP 3073) through any firewall/NAT. If Only Accept Sessions From Module IP is on, also check for "refusing panel connection from unexpected peer" — the panel is calling in from an address that doesn't match Module IP Address. Clear that checkbox — the driver re-learns the new address and re-enables itself on the next session.
Log shows "dropping unencrypted frame on an encrypted session"	Something on the network sent GEM a panel frame in the clear while the real panel's encrypted session was up. GEM ignored it, and the genuine session is unaffected. A repeating burst is worth investigating — it is not something a healthy panel does.
Connects then drops, or never establishes a session	Integration ID or Access Code mismatch. Re-read sections [851][422] and [851][423] and re-enter them. Set log_level to verbose to see the negotiation.
Arm/disarm rejected with a command error	The user code is wrong, or the panel locked out the integration after repeated bad codes. Verify the code on a physical keypad and wait out any lockout before retrying.
Arm "succeeds" but the panel doesn't arm	A zone is faulted (open door/window) or the panel has a trouble; clear or bypass it, then re-arm.
Zones never appear	Confirm the Security subsystem exists (auto-create is skipped without it). Zones are created on the first event GEM receives for each zone number.
Homeowner control shows "System arming is DISABLED"	The Security subsystem has arm_enabled set to false; set it to true or delete the attribute.
Homeowner control shows "Missing security device"	Set the Security subsystem's Device to the DSC panel under Subsystems.

Related documentation

• Devices — where the DSC panel device is added and its connection fields are set.
• Subsystems — assign the panel as the Security subsystem's device (and arm_enabled, to turn arming off).
• Zones — auto-created panel zones live under the Security subsystem.
• Commands — where arm_away, arm_home, arm_night, disarm, and bypass_zone are dispatched and wired into automation.
• Macros and Triggers — arm/disarm on a schedule or in response to events, and react to arm_state and zone state.
• Envisalink EVL-4 — the alternative for older DSC PowerSeries panels reached through an Eyez-On keybus module.
• Alarm.com — cloud-monitored DSC/other panels without a local integration path.