Biometric devices

Where a site has a fingerprint or face reader at the door, BlueOneHR can take attendance straight
from it. Punches then arrive with a Source of Biometric, and are treated exactly like
punches made on the web or in the app.
Devices are managed at Attendance → Biometric Devices.
This screen is labelled legacy by the product itself. Read this before anything else on the
page. Seen on the demo workspace as an HR Head. The page carries
its own banner, shown above the breadcrumb:
"This page shows historical records only."
"Attendance terminals now report into the Attendance Devices module. This page reads the older
biometric tables, which no longer receive new punches, so a device that looks silent here may be
working normally. Open Attendance Devices for live device health, the punches arriving now, and the
identity queue."
"Existing rows were carried across when the new subsystem was installed, so nothing recorded here
has been lost."
The banner's Open Attendance Devices link goes to the newer Attendance Devices module
(
/attendance-devices/), which needs its own permission, 
attendance_devices.view_attendancedevice.
Without it the module shows a permission-denied screen that names the missing permission. The module
is not listed in the Attendance sub-navigation. Do not treat the rest of this page as the current
recommended way to manage biometric devices: it describes the legacy screen, and the newer module
is not yet documented here (see Not confirmed below).
Two families of device
They differ in which side starts the conversation, and that difference decides what your network
has to allow.
Push devices, which speak the ADMS protocol. The device connects out to BlueOneHR and sends
punches as they happen. Nothing needs to reach into your network from outside, which is usually the
easier arrangement.
Classic devices, which BlueOneHR polls on a schedule. Supported families include ZKTeco and
eSSL, Anviz, Matrix COSEC, Dahua, and e-Time Office. BlueOneHR connects to the device to collect
punches, so it must be able to reach the device on your network.
Both kinds appear on the same Biometric Devices page.
Matching a device to your people
A reader does not know your employees. It knows badge IDs — the number stored against a finger
or a face on the device itself.
So the step that makes a device useful is mapping each badge ID to the right employee. Until that is
done, punches still arrive and are stored, but they belong to nobody and no attendance is created
from them.
Open a device and use its Employees view to make the mapping. Existing punches for a badge are
matched to the employee once the mapping exists, so a device installed before the mapping was
finished does not lose the days in between.
When punches are not appearing
Check in this order. It is roughly the order of likelihood.
Is the badge ID mapped to an employee? By far the most common cause.
Is the device reaching BlueOneHR, or BlueOneHR reaching the device? Which direction depends on
the family, above.
Look at the device's logs in BlueOneHR. Punches that arrived but produced no attendance record
are visible there, which distinguishes a network problem from a mapping problem.
That distinction is worth making before escalating: "the device is offline" and "the device is fine
and nobody mapped the badges" look identical from the attendance screens and need completely
different fixes.
What a device does not change
A biometric punch is still just a punch. It is gathered into a daily record, compared against the
shift, and validated like any other. See How attendance works.
Not confirmed
The Attendance Devices module. Its screens were not seen with an account that holds its
permission, so live device health, the punches arriving now and the identity queue are not
documented, and this page describes the legacy Biometric Devices screen only.