Skip to main content

Direct Γ— Neon Controller

A third-party facial reader can be integrated into Accelero in two ways: behind a Neon Controller or in Direct mode. Both handle access control, but they do not deliver the same set of features.

This page consolidates what works in each architecture and the behavior differences by manufacturer, to guide the choice during design β€” including hybrid installations, which combine both modes at different points of the same customer.


The two modes​

In both cases the Communication Gateway is present: it is what delivers the registrations, the photos, and the physical identifiers (cards) to the equipment. What changes is where the access decision is made.

Neon Controller β€” the facial reader works as a slave reader: it delivers the identification through a Wiegand output to the Neon Controller, which applies the rules and decides the release. The controller also drives the barrier, reads the access point sensors, and keeps operating without a network.

Direct β€” the equipment asks Accelero, in real time, whether that person can enter at that point, at that moment. The answer comes from Accelero's access engine, and it is the equipment itself that drives the barrier. It dispenses with the Neon Controller β€” that is the central advantage, in acquisition and infrastructure cost.

The rule that defines the limit of Direct

In Direct, the decision is one question and one answer. Therefore:

  1. Every rule that depends on an external action before the release β€” another identification, or an operator clicking to release β€” does not work in Direct. This is the case with Escort and Dual Custody.
  2. Every feature that depends on physical inputs and outputs of the access point β€” door sensor, exit request button, siren, delay, interlocking β€” requires the Neon Controller, because in Direct there is no Iongrade board at that point.

Features by architecture​

FeatureWith NeonDirect
Accelero access rules (areas, categories, time ranges)βœ… Yesβœ… Yes β€” applied by Accelero's access engine on each query
Special controls (anti-passback, area occupancy limit, block list)βœ… Yesβœ… Yes β€” validated on the server
Events and logsβœ… Yesβœ… Yes
Real-time monitoringβœ… Yesβœ… Yes
Notificationsβœ… Yesβœ… Yes
Manual check-in (by the operator)βœ… Yesβœ… Yes β€” action performed in the system
Check-in at the access pointβœ… Yesβœ… Yes
Escort (person and vehicle)βœ… Yes β€” the controller waits for the second identification❌ No
Dual custodyβœ… Yes❌ No
Card + password (reader with keypad)❌ No❌ No
Opening delay (vaults, treasury areas)βœ… Yes❌ No
Door held open / door forced alarmβœ… Yes❌ No
Door sensors, exit request button (REX), I/O and automation, alarmsβœ… Yes❌ No
Interlocking (mantrap) and logging of the interlock blockβœ… Yes β€” and without depending on a network❌ No
Barrier actuation (turnstile, door, gate)βœ… Yesβœ… Yes β€” through the equipment's own relay
Bidirectional point with a single piece of equipmentβœ… Yes β€” the controller handles entry and exit at the same point❌ No β€” the reader has one relay; it requires one device on each side
Modes that combine actuations on the same board (two doors, interlocked door, card collection box, remote control, delay)βœ… Yes❌ No
Fingerprint and duress finger readingβœ… Yes⚠️ Depends on the manufacturer (see below)
QR code read by the equipment itselfβœ… Yes⚠️ Depends on the manufacturer (see below)
Photo or biometrics capture by the reader itself (remote enrollment)βœ… Yes⚠️ Depends on the manufacturer (see below)
Elevator control (advance call and button panel)βœ… Yesβœ… Yes
Contingency on communication lossβœ… Yes β€” local list on the Neon⚠️ Yes, with limitations β€” depends on the manufacturer (see below)
Passage confirmationβœ… Yes⚠️ Depends on the manufacturer
Dispenses with the Neon Controller (cost)❌ Noβœ… Yes

What does not change between the architectures​

While there is communication, both architectures use the same Accelero access engine β€” the Neon queries the server in the same way as the equipment in Direct. All of the validations below apply in both modes, and none of them is a reason to choose one architecture over the other:

  • Person and identifier registered, enabled, and within the validity period
  • Company and category enabled
  • Area and time range permission
  • Maximum area occupancy
  • Anti-passback (person and vehicle)
  • Block list (blacklist)
  • General block of the access point
  • Minimum time between readings of the same person (re-read suppression)
  • Authorization by event, in the case of visitors
  • Custom rules contracted by the customer

Likewise, events, reports, monitoring, and notifications belong to the system β€” not to the access point architecture.


Contingency: the subtlest difference​

In both architectures there is operation during a communication loss, but what remains of control is different.

With Neon β€” the controller receives the list of identifiers in advance and keeps applying up to two time ranges per person while it is offline. This is Accelero's contingency, configured by category.

In Direct β€” the one that stores the list is the equipment itself, and it starts releasing based on the local registration. The behavior varies:

  • Control iD β€” receives the time ranges, so it keeps some schedule control even offline.
  • Hikvision and Intelbras β€” do not receive time ranges. Offline, the equipment operates practically as a whitelist: whoever is registered gets in β€” with no schedule restriction.
Commercial point of attention

In projects where the schedule restriction is a requirement (shifts, contractors, restricted areas), a communication loss in Direct can release accesses outside the allowed schedule, depending on the manufacturer. Consider the Neon Controller at those points.


Differences by manufacturer​

Direct does not behave the same on all equipment. What changes is what each manufacturer's API allows Accelero to send and receive.

ManufacturerDirectPassage confirmationProximity cardQR codeFingerprint and duress fingerCapture by the readerTime range in contingency
Hikvisionβœ… Yes β€” via remote check (requires BR firmware)βœ… Yesβœ… Yes❌ No❌ Noβœ… Photo❌ No
Control iDβœ… Yes❌ Noβœ… Yesβœ… Yesβœ… Yes (iDFlex)βœ… Photo and fingerprintβœ… Yes
Intelbrasβœ… Yes❌ No❌ No β€” face only❌ No❌ No❌ No❌ No
Dahuaβœ… Yes❌ No❌ No β€” face only❌ No❌ No❌ No❌ No
ZKTeco, Beward, and others❌ Only via Neon Controllerβ€”β€”β€”β€”β€”β€”

Passage confirmation is the ability of the equipment to return the result of the decision to the system and signal that the passage occurred. Where it does not exist (Control iD, Intelbras, and Dahua), Accelero operates in automatic passage: once access is authorized, the system considers that the person passed through and changes their area. If the person identifies themselves and does not pass through, the system does not make that distinction β€” which affects occupancy counting, anti-passback, and the person's location in reports.

Proximity card β€” Hikvision and Control iD receive the cards as their own identifiers from Accelero, which allows combining face and card at the same point and serving those who do not use biometrics. Intelbras and Dahua receive only the link to the facial registration: operation is face only.

QR code, fingerprint, and duress finger β€” only Control iD receives QR codes and fingerprint biometric templates, and it is the only one with a duress finger (the person opens with a specific finger and the system silently logs the duress). The approved fingerprint reader is the iDFlex, today integrated via Neon Controller.

Capture by the reader β€” the ability to use the equipment itself as an enrollment station, capturing the photo (Hikvision and Control iD) or the fingerprint (Control iD) and returning it to Accelero, without needing a separate camera or desktop reader.

Why Control iD keeps the schedule in contingency

Accelero sends the person's categories to Control iD, which the equipment converts into access groups with a schedule. On the other manufacturers, the payload contains only identification, name, and face β€” that is why, offline, only the list of who can enter remains.

note

The list of models, firmwares, and the supported mode per model is in Approved Equipment.


Design considerations​

Network dependency β€” in Direct, each access is a query to the server. Without communication, the point falls back to the equipment's contingency, with the limitations above. With Neon, the decision is local: the controller keeps applying the rules, and interlocking works even without a network.

One relay per device β€” in Direct, the one that releases is the reader's own relay, and there is only one. The equipment normally drives the turnstile, the lock, or the gate, but it covers one direction of passage. A bidirectional point is solved with two devices, one on each side, each releasing its own direction β€” which must be included in the project sizing. The Neon Controller handles both directions with a single board.

Position of the actuation relay β€” in Direct, the one that drives the barrier is the reader itself, and the opening relay sits inside the equipment body, on the outer side of the door. At points where this is unacceptable, the project must provide for a relay module installed in a protected area (on the inner side), or adopt the Neon Controller, which is already in the internal area with the actuation under its responsibility.

Cost β€” Direct eliminates the controller and the Wiegand cabling up to it. In installations with many simple points, it is the more economical architecture.


How to choose​

Hybrid architectures are normal: the same customer can have points in Direct and points with Neon.

Direct serves well simple-flow points β€” employee entrances, access turnstiles, receptions β€” where the requirement is to apply Accelero's access rules and log the event.

The Neon Controller is required when the point demands:

  • Escort or dual custody;
  • Door sensors, exit request button (REX), alarms, or any I/O automation;
  • Opening delay or interlocking (mantraps, vaults);
  • Entry and exit at the same point with a single device;
  • Modes that combine actuations on the same board β€” two doors, interlocked door, card collection box, remote control;
  • Offline operation with guaranteed schedule restriction;
  • Reliable occupancy counting and anti-passback on equipment without passage confirmation;
  • Fingerprint reading, even on Control iD (the iDFlex is integrated via Neon);
  • Equipment without Direct support (ZKTeco, Beward, LPRs, and others).

Items under validation​

To avoid incorrect interpretation, the items below have not yet been validated on the bench β€” they should not be read as unavailable, only as unconfirmed:

  • Card + password: Accelero's access engine has password validation per channel, but its use on a facial reader depends on a specific barrier type and is not confirmed in either architecture;
  • Cold room and other Synapsis adaptations, which today use controller channels as detection points;
  • Equipment-by-equipment approval of the Intelbras line and of Direct on Dahua.
Document under consolidation

This page consolidates the internal technical survey from July 2026. The items marked as ⚠️ To validate will be updated after the tests with the equipment.


Next Steps​