---
title: "2N intercom in Link’nX: switch actions and event triggers"
description: Open, lock or hold a 2N door from a Link’nX scenario, and start scenarios on a code, card, call or door state event with precise filters.
canonical: https://wiki.can-nx.com/en/guides/link-2n-automation/
language: en
product: Link’nX
audience:
  - administrateur
  - installateur
context: "Link’nX web: 2N actions and triggers of a declared intercom"
---

# 2N intercom in Link’nX: switch actions and event triggers

Context: Link’nX web: 2N actions and triggers of a declared intercom

In Link’nX, a 2N action controls one of the switches of a 2N intercom: open, close, lock, unlock, hold the door open or release that hold. A 2N trigger starts a scenario on an intercom event: code or card entered, call, door state, motion, user rejected, and so on.

Intended for the authorized installer or administrator. The usable functions and events depend on the hardware and its configuration.

## Before you start

- The intercom is [declared in Link’nX](https://wiki.can-nx.com/en/guides/link-2n-device/). To filter events by user, its XML configuration has been imported there.
- The project and gateway shown are those of the installation.
- You know the function of each relay: a switch number appearing in the list does not tell you which door it controls.
- The detectors, readers, door contacts and functions used exist and are configured on the intercom.

## Create an action on a 2N switch

1. Open **Actions → Add**. In **Select an action type**, choose **2N**, then fill in **Name**.
2. Select **2N Device**.
3. In **Number of the switch to be operated**, choose **1**, **2**, **3** or **4**, according to the switch intended in the installation.
4. In **Action**, choose the command using the table below.
5. Click the **floppy disk at the bottom right** and wait for **Success!**.
6. To automate it, [add the action to the relevant scenario](https://wiki.can-nx.com/en/guides/link-compose-scenario/).

| Choice | Effect described in the help |
| --- | --- |
| **Open** | Activates the selected switch. |
| **Close** | Deactivates the selected switch. |
| **Lock** | Keeps it deactivated; unlocking is then required to return to normal operation. |
| **Unlock** | Removes the switch lock. |
| **Hold-open the door** | Requests a held active state. |
| **Release / cancel hold-open** | Removes the hold and returns to normal operation. |

Before using **Hold-open the door** on an electric door strike, check that it can stay powered over time: otherwise, the equipment may be damaged.

A switch that is both locked and held is considered locked; once unlocked, it remains held. So do not confuse **Unlock**, which removes the lock, with **Release / cancel hold-open**, which removes the hold. If you do not know the expected state and behavior, have them confirmed before automating the command.

To edit or duplicate an action, follow the [actions guide](https://wiki.can-nx.com/en/guides/link-action-edit/), in particular the confirmation of affected scenarios. When editing, wait for **Updated!** after saving.

## Create a trigger on a 2N event

1. Open **Triggers → Add**. Choose **2N** in **Select a trigger type**, then fill in **Name**.
2. Choose **2N Device**, then **Event**.
3. Under **Event conditions**, fill in only the necessary criteria, using the table in the next section. The fields offered change depending on the event; their help appears on hover.
4. Save with the floppy disk and wait for **Success!**.
5. [Add the trigger to the intended scenario](https://wiki.can-nx.com/en/guides/link-compose-scenario/): saving alone does not associate it.

Criteria combine: every criterion filled in must match the event received. An empty field or the **--** choice ignores that criterion. **Invalid** or **Inactive** is an explicit choice, different from an empty field. After changing the event, check the criteria again. If you change device while filtering a user, check that this user does belong to the configuration of the new device.

Fictitious example: **Card entered → Code validity → Invalid** targets an invalid result. If **User ID** is also filled in, this second criterion must also match and may exclude events that do not contain this user. To accept all users, leave this filter on **--**.

## Choose the criteria for each event

| Event | Available criteria or specific behavior |
| --- | --- |
| **Device state** | No additional filter; the help describes the event after the device starts. |
| **Motion detected**, **Noise detected** | **Motion detector state** or **Noise detector state**: **start** for the beginning, **end** for the end, or **--**. The hardware and the detection must be configured. |
| **Code entered** | **Code entered**, **Code validity**, **User ID**. Enter a specific code only in this field, without sending it in a message. |
| **Card entered** | **Code validity** and **User ID**; the validity criterion keeps this label, even for a card. |
| **Logic input changed**, **Logic output changed** | **I/O port logic state**: **Active**, **Inactive** or **--**; exact **I/O port name**. To get the list of ports, open the intercom’s IP address followed by `/api/io/caps` in a browser, for example `192.168.1.20/api/io/caps` (fictitious example), and sign in with an HTTP API account. |
| **Switch state changed** | **Switch number**, from 1 to 4, and **Switch state**: **Active**, **Inactive** or **--**. The switches are configured in the 2N interface, in the **Hardware → Switches** menu. |
| **Call state changed** | **Call direction**: **Incoming** or **Outgoing**; **Call state**: **Connecting**, **Ringing**, **Connected**, **Terminated**, or **--** to ignore a criterion. |
| **Tamper switch activated** | **Switch state**: beginning **start**, end **end** or **--**. The tamper switch function must be configured in the 2N interface, in the **Digital Inputs → Tamper Switch** menu. |
| **Unauthorized door open**, **Door open too long** | **Unauthorized door opening state** or **Door state**: **start**, **end** or **--**. A door-open switch must be connected to a digital input, and the function configured in the 2N interface, in the **Digital Inputs → Door State (Door Open Sensor)** menu. |
| **User authenticated** | Exact **User name**, entered or suggested after import; **User ID**. |
| **Card held (4 seconds)** | Exact **Reader ID** and **Validity result**: **Valid**, **Invalid** or **--**. |
| **Silent alarm**, **REX button activated**, **Access limited** | No additional filter. **Access limited** signals the rejection of the user. Choose the actions to associate in the scenario. |
| **Finger entered** | **Fingerprint validity** and **User ID**. The form filters the event; it asks for neither a fingerprint image nor a copy. |
| **Mobile key entered (bluetooth)** | **Mobile key validity** and **User ID**. |
| **DTMF (dual-tone multi-frequency) code entered** | **Code validity**: **Valid**, **Invalid** or **--**. |
| **Door state changed** | **Door state**: **Opened**, **Closed** or **--**. |
| **User rejected** | **Rejection reason**, among the choices displayed, and **User ID**. |

In the French interface, **start** and **end** also stay in English.

The user names and IDs offered come from the configuration imported in the [2N declaration](https://wiki.can-nx.com/en/guides/link-2n-device/) of the selected device. Do not choose another person just to be able to continue.

## Check the result

1. Find and reopen the action to review the device, the switch number and the command; for a trigger, review the device, the event and the filters.
2. Check that the action or trigger is in the intended scenario, then that scenario’s activation and conditions.
3. Test on site: cause the event that starts the scenario, for example a code or a call, then watch the door. **Success!** confirms the save; only this physical test validates how the door works.

## Troubleshooting

- Command without effect: check the device and its switch number, then the association with the scenario, its activation and its conditions.
- Missing event: check the event and the criteria filled in, then the scenario. If commands work but no event arrives, also check the declaration’s **Logging API authentication method**, separate from the switch one.
- Filter too restrictive: identify the criteria your goal needs before removing any. Do not broaden an opening automation without checking the consequences.
- Empty user list: it is only filled after a configuration file has been imported into the declaration of the selected device. Check the chosen device, then the import in the [2N declaration](https://wiki.can-nx.com/en/guides/link-2n-device/).
- An event missing from this guide, a choice that produces no event or a model whose capabilities are not established: contact support to confirm the applicable path.

## Contact support

If the problem persists after these checks, write to support@can-nx.com stating the project and gateway, the 2N device, the action or trigger concerned, the filters, the scenario and the symptom. Do not send a secret code or a file containing private data.

French labels: **Appareil 2N**, **Numéro de l'interrupteur à actionner**, **Ouvrir**, **Fermer**, **Verrouiller**, **Déverrouiller**, **Maintenir la porte ouverte**, **Relâcher / annuler l'ouverture maintenue**; **Évènement**, **Conditions de l'évènement**, **Carte saisie**, **Validité du code**, **ID de l'utilisateur**, **Invalide**, **Inactif** and **--**.