Chapter 01
Introduction and concepts
Access Controller is a cloud-managed door access-control system made by 2plus1. It runs gyms, studios, offices, workshops, apartment blocks and holiday lets from one web panel: people and their fobs, doors and the small controllers that drive them, access levels and weekly schedules, release-by-phone, bookable rooms with their own resident portal, a live reception screen, a full event log and Telegram alerts when a door is forced or left open.
Its starting point is that you should not have to rip anything out. Access Controller is a drop-in replacement for any Wiegand system: the readers, locks, cabling and fobs already on site stay exactly where they are, and only the controller box changes.
This manual is written for three readers:
- Owners and office managers who add people, hand out fobs, set opening hours and look at the log. Chapters 2, 4, 6, 7, 8, 10 and 11 are for you.
- Installers who fit readers, locks and controllers and get them talking to the panel. Chapters 3, 5, 13 and 17 are for you.
- Providers and IT who host the panel, create tenants and look after security. Chapters 12, 14, 15 and 16 are for you.
A drop-in upgrade for existing door hardware
Most door systems already on the wall (Paxton, Kantech, Honeywell, ZKTeco, unbranded kits, old PC-based panels) use the same building blocks: a Wiegand reader on the outside of the door, a 12 V electric strike or maglock, an exit button on the inside and, sometimes, a door contact. Access Controller reuses all of that. You keep the readers, the locks, the cabling and the fobs already in people's pockets; only the old controller box is replaced by an Access Controller unit, and everything is then managed from the panel.
- Any Wiegand 26-bit or 34-bit reader works: proximity, MIFARE, keypad-with-fob, QR readers that output Wiegand.
- Existing fobs and cards keep working, because the code is read straight off the reader and stored as it arrives.
- Standard relay output for strikes and maglocks, exit-button and door-contact inputs, fail-safe or fail-secure per door.
- One-door and two-door controllers, PoE (wired) or Wi-Fi: one board can drive two independent doors, each with its own reader, relay, exit button and door contact.
- Sites can migrate door by door; every door keeps working on its own if the network drops.
The building blocks
The panel is organised around a small number of ideas. Once these are clear, every page in the panel makes sense.
| Term | What it means |
|---|---|
| Person | Someone who may open doors: a member, a staff member, a resident, a cleaner. Has a name, optional email and phone, a photo, notes, and a status of active or inactive. Called "People" in the panel. |
| Fob | A physical credential (fob, card, tag) with a unique code read by the door reader. A person can hold several fobs. Each fob has a status of active or revoked. Codes are shown as uppercase hexadecimal, for example A1B2C3. |
| Door | A physical door. Has a name, a description, and a fail behaviour (fail-safe or fail-secure). A door is driven by one controller channel. |
| Controller | The small ESP32 unit fitted near the door that reads the reader, fires the lock relay, watches the exit button and door sensor, and talks to the panel. A single-door controller drives one door; a dual-door controller drives two (channel 1 and channel 2). |
| Schedule | A weekly pattern of when access is allowed: for each day of the week either no access, all day, or a time window (which may run overnight, such as 22:00 to 06:00). |
| Access level | A named bundle of doors plus one schedule, for example "Members: front entrance and gym floor, 06:00 to 22:00". A person holds one or more access levels. A level with no schedule is 24/7. |
| Tenant | One customer organisation with its own people, doors, controllers, settings, staff logins and branding. A single-site customer has one tenant. A provider hosting many customers has many. |
| User | A staff login for the panel (not to be confused with a person who opens doors). Every user has a role: super admin, admin, viewer, or a custom role. |
| Room | A door that has been made bookable: a residents' lounge, shared gym, laundry or meeting room. Residents reserve a slot on the resident portal and the door opens for them for that slot. A room needs a door module and an exit button; a fob reader is optional. |
| Booking | One person's reservation of a room for one slot. A confirmed booking is another reason the door may open, alongside a fob and a phone call. |
| Event | One line in the log: an access attempt (granted or denied with a reason), a door event (door opened, door closed, exit button pressed), an alert from a door (forced, held open) or a system event (controller registered, enrolment started, a person moved to the trash, a booking confirmed, an import). |
| Alert | An event the door raises on its own rather than in answer to a fob: door forced (opened with no grant) or door held open (open longer than the time set on the door). Alerts are always logged and can also be sent to a Telegram chat per tenant. |
How a decision is made
When a fob is presented, the door grants access only if all four of these are true:
- the fob is known and its status is active;
- the person holding it is active;
- one of the person's access levels includes this door; and
- the current local day and time fall inside that level's schedule (or the level has no schedule).
If any test fails, the door stays locked and the log records why (unknown fob, fob revoked, person inactive, no access level for door, outside schedule). The same rule is used by the "Check access" tool on the dashboard, so you can test your set-up before anyone walks up to the door.
A confirmed room booking adds a fifth possibility: it gives that person's fobs a time window on that room's door, from a few minutes before the slot until just after it ends (chapter 8).
Other paths open doors without a fob at all. The exit button on the inside always releases the door (free egress). Release by phone lets a recognised caller, or a guest with an apartment number and PIN, open the door from the access line. The resident portal gives someone whose booking is running an "Open the door" button on their phone. All are logged. Where a door contact is fitted the controller also logs every opening and closing of the door, and raises an alert if the door is forced or held open.
How the controller keeps working offline
Access Controller is designed so that a broken internet connection never locks anyone out or leaves a door open.
- The panel compiles a keyset for every door: the complete list of fobs that may open that door, each with its allowed time windows. The keyset is pushed to the controller over MQTT as a retained message and the controller saves it to its own flash memory.
- The controller makes every grant or deny decision locally from that keyset. It does not ask the panel. A scan is answered in milliseconds whether or not the panel is reachable.
- Events that happen while offline are queued on the controller (up to about 100 KB, oldest dropped first) and sent to the panel when the link returns, so the log catches up.
- Whenever you change something that affects a door (add a fob, revoke one, change a level or schedule, set someone inactive) the panel pushes a fresh keyset within seconds. It also re-pushes every few hours so daylight-saving changes are covered.
- The controller keeps the clock over the network (SNTP) and can carry an optional battery-backed real-time clock. If the controller has no trusted time and a fob is time-restricted, the firmware fails open and logs it, in keeping with the product's fail-safe stance.
Revocation therefore takes effect within seconds while the controller is online, and no later than the next periodic push after an outage.
What "cloud-managed" means here
The panel is a single program that contains the web interface, the MQTT broker the controllers connect to, and the database. 2plus1 hosts it for you, or you can run it on your own server or a small cloud machine (see chapter 16). Controllers only need to reach the panel's address on the MQTT port; they never need inbound connections, and the panel never needs to reach into your site network.
Where things are in the panel
The left sidebar is the whole map of the product. Which entries you see depends on your role (chapter 12).
| Sidebar entry | What it is for | Chapter |
|---|---|---|
| Dashboard | Counts, controller health, recent activity, Check access tool | 2 |
| People | People, fobs, photos, access levels, phone release, bulk changes, the trash | 6 |
| Enrolment | Starting enrolment mode at chosen doors, assigning captured fobs, import from CSV or an AC8000 backup | 6 |
| Access levels | Which doors, on which schedule | 7 |
| Schedules | Weekly time windows | 7 |
| Bookings | Room bookings made by residents or by staff, and marking them paid | 8 |
| Rooms | Turning doors into bookable rooms: hours, slots, extras, price | 8 |
| Log | Every event, with filters | 11 |
| Doors | Doors, fail behaviour, reader/relay mapping, reception screen link | 3, 10 |
| Controllers | Onboarding, status, push keys, unlock, update, re-point | 5 |
| Flash & adopt | Flashing a new controller and sending it its settings | 5 |
| Users | Staff logins, roles | 12 |
| Branding | Logo and accent colour | 2 |
| Tenants | Provider only: create and switch between customers | 14 |
| Settings | Controller Wi-Fi, controller type, pin maps, bookings and the resident portal, Telegram alerts, the site number for phone enrolment, adoption address, phone API token | 4, 8, 13 |