Skip to content

Door Opening

A visitor opens a door with their phone. VisitorPass asks the integration over its channel, and the integration presents the visitor's badge on a door reader, as if a card had been held to it. AEOS decides whether the door opens, exactly as for a physical card, and keeps the audit trail.

The badge must already be on a carrier in AEOS — put there by Visitor Provisioning or by Credential Issued.

Requirements

  • Connection 1 in the network requirements: TCP 8001 from the AEOS server to each AEpu door controller.
  • An AEmon user that can edit and deploy the configuration of each AEpu.
  • The doors to be opened already exist in AEOS and work with a physical reader.

Prepare each AEpu

In AEmon, for each AEpu with doors to open:

  1. Add a GenericDeviceInterface with these properties:

    Field Value
    Channel connection provider TCP transport layer, listening port 8001
    Address offset 500
    Address range per device master 1
    Message syntax version 0
    Message logging off

  2. Under Device channel addresses, add device number 1, channel address 00000001, Enabled.

  3. Deploy the configuration to the AEpu.

Make the readers

Each door reader gets a door QR code, which visitors scan with their wallet to open the door. A door with an in and an out reader has two. On the AEOS page in VisitorPass, under Door Opening › Readers:

  1. Under New readers, enter how many readers to make and click Make. Each new reader gets its QR code, and waits under Not on an AEpu.
  2. For each reader, enter its name, after the AEOS access point and the side it opens, and the AEpu door controller it is wired to, by the host name or IP address the AEOS server reaches it on. Click Save readers.
  3. Download the QR codes, one at a time or with Download all, for the stickers.

A reader keeps its place on its AEpu once saved, and new readers go after it. Its place is its output on the AEpu's DipBri block in AEmon, so a wired door keeps its reader.

VisitorPass sends the readers to the integration over its channel: when the channel opens, every hour while it stays open, and within seconds of a change on the AEOS page. A send that fails is retried after a minute. The status next to Readers says whether the integration holds the readers shown. Neither server.json nor a restart is involved: the integration reconnects only an AEpu whose readers changed, and the doors on the other AEpus stay connected.

The integration keeps the last readers it was sent in readers.json, beside server.json, and starts from them, also while VisitorPass cannot be reached. A reader stays until VisitorPass sends readers without it. Do not edit readers.json.

Wire the doors

In AEmon, for each AEpu:

  1. Open the configuration diagram. A DipBri (501) block has appeared, with one output per reader on the AEpu, in the order of the AEOS page, named after the reader.
  2. Wire each output to the door its label names, through a BadgeMux where the door also has a physical reader.

  3. On each door wired to a DipBri output, add an identifier type entry:

    Field Value
    Identifier type Generic
    Target identifier type Generic
    Sub type 3
    Data type filter ffff
    Badge number Binary, Hex, bit position 0, length 128
    Customer code length 0, fixed code off
    Reverse bytes off

  4. Deploy the configuration to the AEpu.

Verify

  1. Check that the service has connected to every AEpu:

    Select-String -Path logs\out.log -Pattern 'Connected to AEpu','Could not connect to AEpu' | Select-Object -Last 10

  2. Open a door from a test visitor's phone, and check that the badge was presented:

    Select-String -Path logs\out.log -Pattern 'Emitting badge' | Select-Object -Last 5

  3. Check in AEOS that the door event names the test visitor.