Digieye Integration (Computer Vision)
The Digieye integration connects ACCELERO to Digieye computer vision devices — equipment that processes images via the EyeFlow and DigiAI modules. With the integration active, ACCELERO registers and manages these devices, notifies Digieye about access events (so it can analyze the scene), triggers the equipment's outputs, and also allows using the device state (phase or I/O) as an access verification rule.
This integration is provided as a plugin (digieye) and must be installed and enabled by the IONGRADE technical team. Contact support to check compatibility with your ACCELERO version.
Current plugin version: 0.0.2 — compatible with ACCELERO 2.16.8 or higher.
The current plugin version (0.0.2) is still in an early stage. Screens, fields, and behaviors may change between versions — confirm with IONGRADE support before deploying to production.
What the integration does
Digieye is treated as a type of communication gateway and of device within ACCELERO. The registered devices communicate via MQTT, and ACCELERO acts as the orchestrator: it forwards events, commands outputs, and queries the equipment state for access decisions.
| Feature | What happens in ACCELERO |
|---|---|
| Registration of Digieye devices | Each piece of equipment is registered with a serial number, IP, port, communication gateway, and associated areas |
| Event binds | Access event types are linked to a device; when the event occurs, ACCELERO notifies Digieye (EyeFlow / DigiAI / trigger output) |
| Domocam event binds | Domocam camera event types are linked to a device, triggering the same notification to Digieye |
| Output triggering | An access event or an I/O action can turn a Digieye device output on/off |
| Access verification rule | The Phase verification rule grants or denies access according to the current Digieye phase or the state of a monitored I/O |
| Status monitoring | ACCELERO tracks the gateway's online/offline state and the version/IP/last communication reported by the devices |
It allows ACCELERO's decisions and physical actions (granting access, triggering an output) to be coordinated with Digieye's computer vision analysis, in real time, via MQTT.
Digieye Devices
Navigation path: side menu > Digieye
The main screen has two tabs: Devices and Gateways.
Main Digieye screen with the Devices and Gateways tabs.
Devices tab
Lists all registered Digieye devices.
List of Digieye devices (columns Serial number, Description, IP address, Port, General data, and Actions).
| Column | Content |
|---|---|
| Serial number | Serial number of the device |
| Description | Name/description of the device |
| IP address | IP of the device |
| Port | Communication port |
| General data | Device metadata |
| Actions | Edit device |
List buttons:
| Button | Function |
|---|---|
| New device | Opens the quick inline registration form |
| Search | Filters the list by description |
| More actions > Delete | Batch deletion of selected devices |
Quick registration (inline)
The inline New device form asks for: Serial number, Description, IP address, Port, and Gateway.
Gateways tab
Lists the communication gateways of type digieye. For each gateway, ACCELERO displays metadata reported by the devices: last communication, version, IP address, and the communication status with the devices (OK / Error per device).
The registration and configuration of the communication gateway follow the standard ACCELERO flow. The plugin only registers the digieye type and enriches the list with the metadata reported by the devices.
Device registration
When you edit a device (Edit button in the list), the Digieye screen opens with the General data, Event binds, and Domocam tabs.
Edit form of a Digieye device, with the General data, Event binds, and Domocam tabs.
General data tab
| Field | Description |
|---|---|
| Enabled inputs (comma-separated) | List of enabled device inputs, comma-separated |
| Enabled outputs (comma-separated) | List of enabled device outputs, comma-separated |
| Serial number | Serial number of the device |
| Description | Name/description of the device |
| IP address | IP of the device |
| Port | Communication port |
| Gateway | Communication gateway (type digieye) to which the device belongs |
| User | Access user for the device |
| Password | Access password for the device |
| Associated areas | ACCELERO areas associated with this device (multi-selection). Defines which events and which access rule apply to the equipment |
Operating hours (access validation)
Still on the General data tab, the Operating hours section defines the validation strategy used by the access verification rule:
| Field | Description |
|---|---|
| Validation strategy | Phase / I/O Monitoring / Do not validate |
| Phases enabled for access validation (comma-separated) | (Phase strategy) List of phases in which access is allowed |
| Default phase in case of communication failure | (Phase strategy) Phase assumed when the device/gateway is offline |
| I/O to monitor | (I/O Monitoring strategy) Number of the I/O whose state determines the blocking |
Use Do not validate when the device only receives event notifications or triggers outputs, without taking part in the access grant decision.
Event binds tab
Links access event types of ACCELERO to an action on the Digieye device. When a linked event occurs in an area associated with the device, ACCELERO publishes the corresponding notification via MQTT.
Event binds tab showing the New bind form and the list of registered binds.
New bind form:
| Field | Description |
|---|---|
| Event log description | Multi-selection of log event types that trigger the notification |
| Channel | Device channel associated with the bind |
| Integration type | EyeFlow / DigiAI / Turn output on / Turn output off |
| Class | Identifier of the class sent in the notification to Digieye |
| Type | Free type of the notification (default value: Multi) |
| Integration type | Effect |
|---|---|
| EyeFlow | Notifies the Digieye EyeFlow module with the event data (includes the person's photo, when available) |
| DigiAI | Notifies the Digieye DigiAI module with the event data |
| Turn output on | Commands the triggering of a device output on the given channel |
| Turn output off | Commands the turning off of a device output on the given channel |
Event notification flow: access event in ACCELERO → bind by event type → MQTT publication to the device topic (EyeFlow / DigiAI / setoutput).
Domocam tab
Allows linking Domocam camera event types to a Digieye device. When the selected Domocam event occurs on the chosen camera device, ACCELERO triggers the same notification to Digieye.
Domocam tab with the New bind form (Event types, Devices, Channel, Integration type, Class, Type) and the list of Domocam binds.
New bind form (Domocam):
| Field | Description |
|---|---|
| Event types | Multi-selection of Domocam event types that trigger the notification |
| Domocam | Source Domocam camera device of the event |
| Channel | Device channel associated with the bind |
| Integration type | EyeFlow / DigiAI / Turn output on / Turn output off |
| Class | Identifier of the class sent in the notification to Digieye |
| Type | Free type of the notification (default value: Multi) |
The Domocam tab is only available when the Domocam module is enabled in the environment. Without the module, only the access event binds are used.
Access verification rule
The plugin provides a dedicated access verification rule — Phase verification — that can be assigned to the areas' custom access rules. It grants or denies passage according to the state of the Digieye device associated with the destination area.
Navigation path: in the area's access rule configuration, select the custom rule Phase verification.
Selection of the access verification rule Phase verification in the custom rule configuration of an area.
How the rule decides
The rule acts on the Digieye devices associated with the destination area of the access. If no device is associated with the area, access is granted by this rule. For each associated device, the blocking depends on the Validation strategy configured on the General data tab:
| Strategy | Behavior |
|---|---|
| Phase | Access is denied if the device's current phase is not among the Enabled phases. With the device online, the current phase comes from the equipment; offline, the Default phase is used |
| I/O Monitoring | Access is denied when the monitored I/O is triggered |
| Do not validate | The rule never blocks based on this device |
When the rule denies, the recorded reason is the one for outside operating hours (NOT_AUTHORIZED_WORKING_HOUR).
In the Phase strategy, set the Default phase considering what should happen when the device is offline. If the default phase is not among the enabled ones, access will be denied during the unavailability.
I/O action: trigger Digieye output
The plugin adds the Act on Digieye output action to ACCELERO's I/O handler, which turns a Digieye device output on or off when an I/O condition is (or ceases to be) met.
Navigation path: I/O configuration / I/O handlers > Act on Digieye output action.
Configuration of the I/O action Act on Digieye output, with the Digieye, Output, and Status fields.
| Field | Description |
|---|---|
| Digieye | Target Digieye device of the action |
| Output | Number of the output to be triggered |
| Status | Desired state of the output (on/off) when the condition is met; the inverse state is applied when the condition no longer holds |
The plugin also exposes the I/O Digieye source on the I/O handler screens, allowing the use of Digieye device inputs/outputs as input variables of the I/O rules.
The inputs and outputs available for use in I/O depend on the values entered in Enabled inputs and Enabled outputs in the device registration.
How events are triggered
- Access events: when a linked log event occurs in a bind, and the device is associated with the event's area, ACCELERO publishes the notification to the device's MQTT topic (EyeFlow, DigiAI, or setoutput, according to the bind's integration type).
- Domocam events: when a Domocam event of the type and device linked in a Domocam bind occurs, the same notification is published.
- Phase / status change: ACCELERO continuously listens to the devices' phase state and the gateway's online/offline status, used by the access verification rule.
- Registration change: when saving or deleting a device, ACCELERO synchronizes the device configuration with the gateway.
The integration runs two continuous processes (DigieyeEventListener and DigieyePhaseListener) that listen to the events and the state of the devices via MQTT. They are started automatically with ACCELERO.
Use cases
Notify Digieye on every access of an area
- Register the device in Digieye > Devices > New device (serial, IP, port, gateway).
- Edit the device and, in General data, select the Associated areas.
- On the Event binds tab, create a bind: select the event types, the Channel, Integration type = EyeFlow (or DigiAI), and the Class.
- From then on, each linked event in that area is notified to Digieye.
Trigger a Digieye output on an event
- On the device, ensure the desired output in Enabled outputs.
- On the Event binds tab, create a bind with Integration type = Turn output on and the corresponding Channel/output.
- When the linked event occurs, the output is triggered.
Grant access only in certain phases
- On the device, set Validation strategy = Phase.
- Fill in Enabled phases and the Default phase.
- Associate the area with the device and assign the Phase verification rule to the area's access rules.
- Access then depends on the current phase reported by Digieye.
Best practices
- Correct associated areas: the event notification and the access rule only act on the areas associated with the device — confirm the link.
- Deliberate default phase: set the Default phase considering the desired behavior when the device is offline.
- Explicit inputs/outputs: keep Enabled inputs and Enabled outputs updated so that the I/O actions find the correct outputs.
- Healthy gateway: track the Gateways tab to ensure the devices are communicating (OK status and recent last communication).
Troubleshooting
Digieye does not receive event notifications
Possible causes:
- The device is not associated with the area where the event occurs.
- There is no bind for the event type.
- Communication gateway offline.
Solution:
- In General data, confirm the Associated areas.
- In Event binds, confirm that a bind exists for the event type.
- Check the gateway status on the Gateways tab.
Access being denied unexpectedly
Possible causes:
- The Phase verification rule is assigned to the area with the Phase strategy, and the current phase is not enabled.
- Device offline and Default phase outside the Enabled phases.
- Monitored I/O triggered (I/O Monitoring strategy).
Solution:
- Check the device's Validation strategy and Enabled phases.
- Check the gateway's online/offline status.
- For the I/O strategy, check the state of the I/O to monitor.
Output is not triggered
Possible causes:
- The output is not in Enabled outputs.
- Bind/I/O action with the wrong Channel/output.
- Gateway offline.
Solution:
- Confirm the output in Enabled outputs.
- Review the Channel/output of the bind or of the Act on Digieye output action.
- Check the gateway communication.
Integration with other modules
Areas
The link of Areas to the device is what defines which events are notified and where the access verification rule acts.
Controllers and Logs
The events that trigger notifications come from the access event logs generated by the Controllers. See Logs and Monitoring to understand the available event types.
I/O and Automation
The Act on Digieye output action and the I/O Digieye source integrate with the I/O and Automation module.
Next Steps
- Areas — Associate areas with the Digieye devices
- Controllers — Source of the access events
- Logs and Monitoring — Understand the event types that trigger notifications
- I/O and Automation — Use Digieye outputs and inputs in I/O rules
- Plugins — Learn more about ACCELERO's plugin system