Recognition and display
Use this workflow to accept a device installation, investigate a display that does not update, or verify an on-site recognition result. The goal is to match one recognition that just happened with a new event on the screen.
Identify the active event path
Open the display settings, confirm the mode, and ask the technician to record the destination to which the device actually sends events. The two modes use different receiving services.
| Local mode | Cloud mode |
|---|---|
| Device → local device service on the display → screen | Device → central or configured cloud service → display callback service → screen |
| Check whether the display received the device event first | Check upstream receipt, then delivery to the display |
| Online count comes from local device records on the display | Online count comes from the configured central interface |
Local mode can receive device events directly. Accept this display path by verifying the new event on the display. If delivery also requires central retention or accommodation statistics, verify that central data path separately.
Prepare a traceable recognition
- Confirm that the participant is on the target device using the synchronization workflow.
- Record the device identifier, internal personnel ID, and current time. Check for obvious clock differences between device and display.
- Check the recent device heartbeat and active display mode, then open the main display.
- Have the person complete one recognition and record the device's actual feedback.
Verify the path for your mode
Local mode
- Check that the device reports to this display, using the configured protocol and port.
- Ask the technician to locate the new event in display management records or receiving logs by device ID and time.
- Check that the latest card updates and compare the person, recognition result, and event time.
- If the device reported but the display did not receive the event, check the destination, connectivity, protocol, and device credentials.
Pass condition: This device event was received and displayed. A delivery requiring central retention also needs the central record check.
Cloud mode
- Check the display's central service URL and connection status.
- Ask the technician to find this device event in the central service or the actual upstream cloud receiver.
- Check that the upstream callback targets this display's cloud receiving service, and inspect the callback result.
- Find the same event in display records or logs, then verify the main screen update and contents.
Pass condition: Upstream receipt, display receipt, and the visible result all correspond to this recognition. A healthy central heartbeat completes only the connectivity check.
Read the display correctly
| Content | What it helps you assess | How to interpret it |
|---|---|---|
| Latest and previous recognition cards | The two most recent displayed people and results | Check event times to distinguish new results from old records |
| Recent photo area | Browse recent recognition records | The main page shows up to eight recent events, not the entire history |
| Recognition result | The device result parsed by the receiving layer | Check the original event when fields are missing or an unknown person is reported |
| Online device count | Devices considered online by the active mode's data source | Sources differ by mode; “--” means the count is not currently available |
| Central connection status | Recent connectivity from the display to its configured central service | Verify device availability and personnel synchronization separately |
Why photos may remain after a restart
The display loads locally saved recent records on startup. If none exist, it may show demonstration placeholders. Visible photos establish only that the page has display data. Trigger a real new recognition and match the person, device, and time for acceptance.
Troubleshoot by symptom
| Symptom | Check first | Next step |
|---|---|---|
| Center connected, but no new recognition | Whether the active mode's receiver has this event | Follow the local or cloud sequence above to find the interruption |
| Device online, but the test person is not recognized | That person's record and photo on this device | Return to personnel synchronization |
| No event at the receiver | Actual device destination, connectivity, and reporting response | Technician checks the protocol and access configuration |
| Receiving record exists, but the screen is unchanged | Current test time, correct display, and whether the event is a duplicate | Preserve the event identifier and receipt result for display support |
| Wrong name or missing photo | Personnel ID, reported fields, and photo data | Compare the device record with the actual received event |
| Center disconnected, but old records remain | Displayed record times, active mode, and central address | Restore central connectivity and retest functions that depend on it |
Record a result that can be traced
Record the mode, device identifier, internal personnel ID, recognition time, processing result at each receiving stage, and screen result. An event identifier and a redacted screenshot make investigation easier. A screenshot showing only “online” does not replace evidence for the full flow.
For maintainers: receiver and display checks
Local access uses HTTP 8180 by default and cloud callbacks use HTTP 8011; follow the delivered site configuration. Reporting the same event again may not create a new screen update. Correlate event IDs and times instead of treating repeated transmissions as separate recognitions.