Device Events
Events holds the payloads devices delivered and what the ERP did with each one. Where Inbound proves a request arrived, Events shows whether it was understood — a punch that became attendance, a tag read that became a sighting, or something the handler could not interpret.
Where to find it
Go to EdgeBridge > Events.
What the list shows
| Column | Description |
|---|---|
| Event id | The event record. |
| Received / Date | When it arrived. |
| Gateway | Which gateway delivered it. |
| Source | The device that produced it. |
| Type | What kind of event — a punch, a tag read, a weight. |
| Payload | The raw data as the device sent it. |
| Status | See below. |
| Result | What the ERP produced, or why it did not. |
| View | Opens the event in full. |
Statuses
| Status | Meaning |
|---|---|
| New | Received, not yet interpreted. |
| Processed | Understood and acted on — a record exists somewhere in the ERP. |
| Ignored | Deliberately skipped, such as a repeat punch inside the ignore window. |
| Error | The handler could not process it. |
Ignored is usually correct, not a fault. A biometric unit reads a finger several times in a second, and the repeat-punch window collapses those into one — see Settings.
Diagnosing an error
- Open the event and read the payload as the device actually sent it.
- Check the device id in it is mapped — Employee IDs for a person, Item Tags for a thing.
- For a tag read, check a read point exists for that reader and antenna.
- Fix the mapping — later events of the same shape will then process.
An unmapped device id is by far the most common cause. The ERP received the punch; it simply does not know whose finger it was.
Retention
Events are kept for the number of days set in Settings. Records they created — attendance, sightings, counts — are permanent regardless.
Related pages
- Inbound — the requests that carried these
- Employee IDs · Item Tags — mapping device ids
- Sightings — what tag reads become