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.

Configure the service

Add a dip section to server.json, with one entry per AEpu:

server.json

  "dip": { // (1)!
    "enabled": true,
    "aepus": [
      {
        "host": "<aepu-host>", // (2)!
        "port": 8001, // (3)!
        "readers": [ // (4)!
          { "readerId": "<reader-uuid>", "label": "Main entrance" }, // (5)!
          { "readerId": "<reader-uuid>", "label": "Side entrance" }
        ]
      }
    ]
  },

1. The AEpu door controllers the service presents badges at. Used by Door Opening only; leave the section out without it.

2. The address of the AEpu door controller, not the AEOS server.

   Value: the controller's IP address or host name, as AEmon shows it.

3. The port the AEpu listens on for the service.

   Value: the listening port of the AEpu's GenericDeviceInterface from Prepare each AEpu, 8001.

4. One reader per door wired to this AEpu. Each becomes an output on the AEpu's DipBri block in AEmon, in list order.

   Add new readers to the end of the list. Reordering or removing a reader moves every door after it onto a different output, and the wrong door opens.

   A spare reader at the end costs nothing, and saves a restart when a door is added.

5. One door.

   readerId: a UUID that identifies the reader, unique across all AEpus. Partisia makes it, together with the reader's door QR code: the code names this id.

   label: the door's name, shown on the DipBri output in AEmon.

Each 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. Partisia makes the codes and the stickers.

Partisia staff

PRODUCTION.md in the visitorpass-aeos-integration repository › Door Opening › Create a door QR code

Restart the service:

.\servy\servy-cli.exe restart --name visitorpass-aeos-integration

Wire the doors

In AEmon, for each AEpu:

1. Open the configuration diagram. A DipBri (501) block has appeared, with one output per reader in readers.
2. Wire each output to its door, 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','Failed to 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.