Honeywell Vista (AD2USB / AlarmDecoder)

GEM integrates with a Honeywell Vista alarm panel (Vista 20P / 21iP and compatible Ademco panels) through an AlarmDecoder adapter — an AD2USB, AD2PI, or AD2SERIAL module that taps the panel's keypad bus and exposes it over the network. GEM connects to the AlarmDecoder over TCP and uses the AlarmDecoder ASCII protocol to arm and disarm the panel, watch each panel zone go ready / faulted / in-alarm / bypassed, follow the partition's armed state, and report panel events (fire, low battery, AC loss, tamper, and dozens more).

This is a local integration. GEM talks straight to the AlarmDecoder on the building LAN — there is no cloud account and no Honeywell subscription involved.

Hardware this driver supports

GEM lists this driver as Honeywell Vista (AD2USB / AlarmDecoder). It works only with a Honeywell/Ademco Vista panel that has an AlarmDecoder (AD2USB / AD2PI / AD2SERIAL) wired onto its keypad bus and reachable over TCP. It is not for DSC panels — for those see DSC PowerSeries Neo or Envisalink EVL-4 — and it is not a cloud integration; for cloud-monitored systems see Alarm.com.

GEM dials out to the AlarmDecoder

Unlike a DSC panel-initiated integration, GEM connects out to the AlarmDecoder at the IP and TCP port you give it. There is nothing for the panel to "call in" to — you point GEM at the adapter, and GEM keeps the connection open and reconnects on its own if it drops.

What you get

• Arm / Disarm the panel: Arm Away, Arm Home (stay), and Disarm, issued as GEM device commands you can put on a macro, a trigger, or your own UI button. Each command carries the panel user code that actually performs the arm/disarm.
• Live zone state. Each GEM zone you create for a panel zone tracks its real-time condition — ready, fault, trouble, alarm, or bypass — refreshed by a periodic status poll and by the panel's real-time event stream.
• Per-zone event reporting. The driver listens for the panel's unsolicited event packets and translates 80+ Vista event codes (for example fire_alarm, low_battery, ac_power_loss, sensor_tamper, smoke_alarm) into a readable last_message on the affected zone.
• Partition arm state. The panel's armed state is published back onto the device as arm_state (armed_away / armed_home / disarmed / not_ready) so your automations can react to it.

Prerequisites

• A Honeywell/Ademco Vista panel (Vista 20P / 21iP or compatible) with healthy programming.
• An AlarmDecoder (AD2USB / AD2PI / AD2SERIAL) wired to the panel's keypad bus and assigned a free keypad slot (programmed as a virtual keypad / addressable device on the panel).
• The AlarmDecoder's serial stream exposed over TCP — typically ser2sock running on the AD2PI / AD2USB host, or an RS-232-to-IP bridge for an AD2SERIAL — reachable from the GEM server.
• A valid panel user code (4–6 digits) for arm/disarm. The code is not stored on the device; it is supplied with each arm/disarm command.
• The Security subsystem (it ships by default, labeled Security). Panel zones live under it, and the homeowner Security control looks here for the panel device.

Two different numbers — keep them straight

The keypad slot is the AlarmDecoder's address on the Vista keypad bus (an installer setting on the panel). The zone number is the physical panel zone (1–96) you map each GEM zone to. They are unrelated — the slot lets the adapter see the bus at all; the zone number is what you put in a GEM zone's address.

Setup

1. Wire and configure the AlarmDecoder

Follow the AlarmDecoder documentation for your adapter:

1. Wire the AlarmDecoder to the Vista panel's keypad bus (the green/yellow data pair plus power).
2. Program the panel to give the adapter a free keypad slot / address (a virtual keypad). Without a slot the adapter cannot see the bus and GEM will get no zone or arm status.
3. Expose the adapter over TCP. On an AD2PI/AD2USB host this is usually ser2sock (commonly TCP port 10000); an AD2SERIAL goes through an RS-232-to-IP bridge on whatever port it provides. Note the IP and port — you will enter both in GEM.

2. Add the device

1. Open Devices and add a new device with the driver set to Honeywell Vista (AD2USB / AlarmDecoder).
2. Fill in the connection fields:
   • AlarmDecoder IP — the LAN IP of the adapter (or of the RS-232-to-IP bridge for AD2SERIAL).
   • TCP Port — the port the adapter listens on. Common values are 10000 (ser2sock) or 4999; whatever your adapter is configured for.
3. Save and enable the device. GEM connects and logs "vista security socket connected". On connect it requests arm status and a full zone-status sweep, then keeps both refreshed.

3. Point the Security subsystem at the panel

So the homeowner workflow and zone grouping find the panel:

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

Any zone you place under the Security subsystem then resolves to this panel automatically. (Alternatively you can set an individual zone's Device directly to the panel; a zone's own Device takes priority over its subsystem's Device.)

4. Create a zone for each panel zone

Unlike some panel integrations, this driver does not auto-create zones — you create them so GEM knows which panel zones to track:

1. Open Zones and add a zone under the Security subsystem.
2. Set the zone's address to the Vista zone number (1–96) — an integer, not a name. Anything that isn't the numeric zone number will silently fail to match the panel's reports.
3. Give the zone a friendly label (for example Front Door, Kitchen Motion). Naming a zone with words like door, window, motion, smoke, or water helps — the homeowner Security control groups zones into Doors, Windows, Motion, Smoke & Fire, and Water by matching those keywords in the label.
4. Repeat for every panel zone you want to monitor.

Once a zone's address matches a reporting panel zone, its state begins tracking the panel in real time. A zone whose address doesn't match any panel zone simply never updates, and the log notes "unknown vista security zone" when the panel reports on a number you haven't mapped.

Arming and disarming

Arming is done with device commands. The driver exposes:

Command	What it does
arm_away	Arms in Away mode (perimeter + interior).
arm_home	Arms in Stay / Home mode (perimeter only).
disarm	Disarms the panel.

Each arm/disarm command takes:

• user_code — required. The panel user code (4–6 digits) the panel validates and acts on. The driver intentionally does not store it, so every arm/disarm must supply it. If it is missing, the command returns "user code required" and nothing is sent to the panel.
• partitions — optional. An 8-character partition mask; it defaults to 10000000 (partition 1 only). Leave it at the default for a single-partition system.

You fire these from:

• The Commands screen or the device's command list — for commissioning and testing. Run arm_away with user_code set to a real user code and watch the panel arm.
• Automation — call the command in a macro or trigger (for example, arm Away when the site goes to Night mode). See Macros and Triggers. Put the code in the step's user_code argument.
• Your own UI button — wire a control button to send arm_away / arm_home / disarm with a user_code argument.

The built-in Security touch-panel control does not arm this panel

GEM's homeowner Security control sends its on-screen keypad PIN as a code argument, which is what the DSC integration expects. This driver requires the code in user_code instead, so the control's Arm Home / Disarm / Arm Away buttons return "user code required" with a Vista panel. Drive Vista arming from macros, the Commands screen, or a custom UI button that passes user_code. The control's zone list (below) still displays Vista zones; only the arm/disarm and bypass buttons are not wired for this driver.

Reading the panel's armed state

The panel's current arming is published to the device's arm_state attribute as one of armed_away, armed_home, disarmed, or not_ready. A macro condition or trigger can read it — for example to avoid re-arming an already-armed system, or to flash a light when the panel reports not_ready. The driver currently tracks a single partition; multi-partition support is not yet implemented.

Zones and live state

Each GEM zone you mapped mirrors its panel zone. The driver updates the zone's state as the panel reports:

state value	Meaning
ready	Zone is closed/secure and ready to arm.
fault	Zone is open or faulted (door/window open, motion, etc.).
trouble	Zone reports a trouble condition.
alarm	Zone is in alarm.
bypass	Zone is bypassed at the panel.

In addition, the panel's real-time event stream updates the zone's last_message with the most recent event for that zone, translated to a readable name. Examples include fire_alarm, fire_alarm_restore, low_battery, rf_low_battery, ac_power_loss, ac_power_restore, sensor_tamper, smoke_alarm, water_flow_alarm, bypass, duress, and many more (80+ codes in all). A fault_restored event returns the zone's state to ready.

In the homeowner Security control, a zone shows red when faulted and green when ready, and faulted zones float to the top of their group. You can search zones by name and toggle Show Faults / Show All. (Bypass controls in that screen depend on commands this driver doesn't provide — see below — so they don't apply to Vista.)

Status and diagnostic commands

These query the panel on demand and are mainly useful during commissioning. They don't change the panel's armed state. The driver also calls the first two automatically on a schedule to keep state fresh.

Command	What it does
get_arm_status	Requests the current partition arm status.
get_zone_status	Requests a full zone-status sweep (all zones).
get_partitions	Requests partition information.
get_zone_descriptors	Requests zone descriptors from the panel.
passthrough	Sends a raw AlarmDecoder string in the command argument — an escape hatch for advanced adapter commands.

Attribute reference

Device attributes — configuration

Attribute	Required	Type	Notes
ip	yes	string	LAN IP of the AlarmDecoder (or RS-232-to-IP bridge). Shown as AlarmDecoder IP.
port	yes	integer	TCP port the AlarmDecoder listens on (commonly 10000 or 4999). Shown as TCP Port.

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 arming: armed_away / armed_home / disarmed / not_ready.
connected	boolean	Online flag — true while the AlarmDecoder connection is up.

Zone attributes

Attribute	Required	Type	Notes
address	yes	string	The Vista zone number (1–96). You set this when you create the zone.
state	auto	string	ready / fault / trouble / alarm / bypass (see Zones and live state).
last_message	auto	string	Most recent panel event for the zone, as a readable name.

How it works

Outbound connection. When the device is enabled, GEM opens a TCP connection to the AlarmDecoder at the configured IP and port and keeps it open. On connect it requests arm status, waits briefly, then requests a full zone-status sweep so existing zones populate right away.

Periodic polling plus real-time events. After the initial sweep the driver re-polls arm and zone status on a timer, and in between it processes the panel's unsolicited event packets as they arrive — zone faults/restores, alarms, troubles, low-battery, AC loss, and the rest — mapping each onto the matching zone's state and last_message.

Connection health. If no data is seen from the adapter for 120 seconds, GEM marks the device Disconnected (not just on a dropped socket) and reconnects. A device that won't stay connected almost always means the AlarmDecoder isn't reachable on the configured IP/port, or the adapter isn't seeing the keypad bus (no slot assigned, or a wiring fault).

Known limitations and notes

• Single partition. The driver tracks and arms partition 1; multi-partition support is not yet implemented. The partitions mask defaults to 10000000.
• No zone bypass command. This driver does not expose a bypass/unbypass command, so the homeowner Security control's Bypass buttons don't function with a Vista panel. Bypass a zone at a physical keypad if needed.
• User code is per-command. The panel user code is never stored on the device — every arm and disarm must include user_code. Keep it out of shared/exported macros where the value would be visible.
• Zones are manual. Panel zones are not auto-discovered; you create a GEM zone per panel zone with address = the zone number.

Troubleshooting

Symptom	Check
Device won't connect / keeps going Disconnected	Confirm the AlarmDecoder IP and TCP Port, and that ser2sock (or the RS-232-to-IP bridge) is running and reachable from the GEM server. The driver also drops the connection if it sees no data for 120 seconds.
arm_away / disarm returns "user code required"	Pass a real panel user code in the user_code argument. The driver does not store it, and the built-in Security control's keypad sends code instead — use a macro or the Commands screen.
Arm/disarm command sends but the panel doesn't arm	A zone is faulted (open door/window) or the panel has a trouble; the panel refuses to arm. Clear or bypass the fault at a keypad, then re-arm. The wrong user code will also be rejected by the panel.
No zone status at all	The AlarmDecoder isn't seeing the keypad bus — check the bus wiring and that the adapter has a free keypad slot assigned on the panel.
A specific zone never updates; log says "unknown vista security zone"	That zone's address doesn't match a panel zone number. Set the zone's address to the integer Vista zone number (1–96).
Zones show in the list but states look wrong	Confirm each zone's address maps to the right physical panel zone, and that the panel is actually reporting (run get_zone_status from the Commands screen).

Related documentation

• Devices — where the Vista panel device is added and its AlarmDecoder IP and port are set.
• Subsystems — assign the panel as the Security subsystem's device.
• Zones — create one zone per panel zone with address = the zone number.
• Commands — where arm_away, arm_home, and disarm are dispatched and wired into automation.
• Macros and Triggers — arm/disarm on a schedule or in response to events, passing the user_code argument, and react to arm_state and zone state.
• DSC PowerSeries Neo and Envisalink EVL-4 — the DSC-panel alternatives.
• Alarm.com — cloud-monitored panels without a local integration path.