Conectar un reloj checador a un software de asistencia no debería empezar buscando un puerto de red ni escribiendo una dirección IP al azar. El primer paso es definir cómo viajarán los registros desde el dispositivo hasta la plataforma, qué software administrará empleados y horarios, y qué debe ocurrir cuando la red falle. Una conexión que parece funcionar porque el equipo “aparece en línea” todavía puede producir problemas si la hora está desajustada, los usuarios se duplican, las checadas llegan con retraso o el software no corresponde al protocolo del dispositivo.

En empresas mexicanas, esta decisión también tiene un componente de continuidad y trazabilidad. Los registros de asistencia pueden terminar alimentando incidencias, puntualidad, horas laboradas y procesos de nómina. Además, la reforma laboral publicada el 1 de mayo de 2026 incorporó la obligación de registrar electrónicamente el inicio y la finalización de la jornada, con disposiciones generales que entrarán en vigor a partir del 1 de enero de 2027 y cuyo ámbito y excepciones deberá determinar la STPS. Por ello, conviene construir desde ahora un flujo donde sea posible rastrear la marca original, la sincronización y cualquier corrección posterior (Diario Oficial de la Federación, 2026).

 

Idea clave La conexión correcta se diseña como una cadena: reloj checador -> red o medio de transferencia -> software -> usuarios y horarios -> reportes. Si uno de esos eslabones no está definido, el sistema puede estar conectado técnicamente y aun así producir información poco confiable.

 

Antes de conectar: identifica qué tipo de arquitectura necesitas

No todos los relojes checadores se conectan de la misma forma. Algunos están pensados para trabajar de manera autónoma y exportar información por USB; otros se comunican por TCP/IP o Wi-Fi; y los equipos compatibles con protocolos de comunicación push pueden enviar registros hacia plataformas web o servicios en la nube. ZKTeco describe sus plataformas web de tiempo y asistencia como compatibles con dispositivos standalone que utilizan comunicación push por Ethernet, Wi-Fi y otras redes, pero la compatibilidad debe verificarse por modelo y versión (ZKTeco, 2026).

 

 

USB no es lo mismo que “conectar el reloj al software”

Un equipo que exporta registros por memoria USB puede resolver una operación pequeña, pero no mantiene una comunicación continua con una plataforma. Por ejemplo, LFace10 se utiliza como alternativa básica cuando se buscan reportes SSR y transferencia local. Ese esquema puede ser suficiente para una sola ubicación, pero pierde atractivo cuando recursos humanos necesita revisar varias sucursales, dar bajas de forma central o recibir checadas sin esperar una descarga manual (ZKTeco Tienda Oficial, 2026a).

TCP/IP y Wi-Fi: dos medios de red, no dos sistemas diferentes

Tanto Ethernet como Wi-Fi pueden transportar la comunicación entre el dispositivo y el software. La diferencia principal está en la infraestructura. Una conexión cableada suele ser más predecible en puntos fijos; Wi-Fi simplifica instalaciones donde no hay cable de red, pero depende de cobertura, interferencia, autenticación y estabilidad del punto de acceso. Horus TL2, por ejemplo, publica Wi-Fi de 2.4 GHz y TCP/IP, mientras que M1 está orientado a Wi-Fi de 2.4 GHz y BioTime Cloud 2.0 (ZKTeco Tienda Oficial, s. f.-a, s. f.-b).

 

 

Checklist previo: qué debes tener antes de tocar la configuración

La mayor parte de los problemas de conexión se detecta antes de configurar el reloj. Una lista corta de información técnica evita reinicios, cambios de IP improvisados y pruebas que terminan debilitando la seguridad de la red.

• Nombre exacto del modelo y revisión del dispositivo.
• Versión de firmware y, cuando aplique, versión del protocolo de comunicación push.
• Software de destino y versión: BioTime Cloud 2.0, BioTime Pro, ZKBio Time u otra plataforma.
• Lista de dispositivos oficialmente compatibles con esa versión.
• Método de conexión disponible en el reloj: TCP/IP, Wi-Fi, ADMS/PUSH, USB u otro.
• Tipo de direccionamiento: DHCP, reservación DHCP o IP fija documentada.
• Dirección del servidor o servicio, nombre DNS, protocolo y puertos requeridos por la implementación.
• Acceso a la administración de red y firewall; no depender de desactivar protecciones permanentemente.
• Zona horaria, fecha, hora y política de sincronización.
• Convención única para ID de empleado, número de usuario y sucursal.
• Respaldo de usuarios, plantillas y registros existentes antes de migrar.
• Responsable de aprobar altas, bajas y cambios después de la puesta en marcha.

No uses puertos “de memoria” Los valores pueden variar por versión y arquitectura. ZKTeco muestra en su documentación ejemplos de configuración de servidor, ADMS, HTTP/HTTPS y puertos, pero para producción debe utilizarse el valor que corresponda a la instalación real. Evita abrir puertos innecesarios o publicar el checador directamente a Internet.

 

Cómo conectar un reloj checador al software: proceso paso a paso

1. Confirma compatibilidad entre reloj y software

Antes de configurar red, valida que el modelo esté soportado por la plataforma. La compatibilidad no se debe asumir solo porque reloj y software sean de la misma marca. Puede depender de firmware, protocolo PUSH, versión de aplicación o tipo de dispositivo. La página de BioTime Pro en México mantiene un recurso específico de “Dispositivos Compatibles”, y ZKTeco recomienda revisar firmware, versión de PushComm y número de serie cuando un dispositivo compatible no logra registrarse correctamente (ZKTeco Tienda Oficial, s. f.-c; ZKTeco, 2026).

2. Conecta el dispositivo a la red y define su direccionamiento

En Ethernet, conecta el equipo al segmento de red previsto y decide si usará una IP fija o una reservación DHCP. Para instalaciones corporativas suele ser más fácil administrar una reservación o una IP documentada que permita localizar el dispositivo sin que cambie de dirección. Registra IP, máscara, gateway y DNS. En Wi-Fi, valida que el reloj sea compatible con la banda y el método de seguridad utilizado; equipos como M1 y Horus TL2 publican conectividad Wi-Fi de 2.4 GHz.

No basta con que el reloj tenga una dirección IP. Si debe comunicarse con una plataforma fuera de la subred, necesita gateway y, cuando se configura un nombre de servidor, resolución DNS funcional. Una prueba de red debe confirmar que existe una ruta entre el dispositivo y el servicio sin exponer otros segmentos de manera innecesaria.

3. Configura el servidor, ADMS o servicio en la nube

En dispositivos con comunicación push, el menú puede incluir opciones como Cloud Server, ADMS o servidor. Ahí se configura la dirección del sistema receptor, el protocolo y el puerto definidos para la implementación. En su FAQ, ZKTeco indica que para equipos PUSH deben revisarse el tipo de dispositivo, la configuración de Cloud Service, HTTP/HTTPS y la dirección/puerto del servidor. La nomenclatura exacta cambia entre modelos, por lo que conviene trabajar con la guía del equipo (ZKTeco, 2026).

Para BioTime Cloud, la lógica suele ser que el dispositivo compatible tenga salida hacia el servicio y quede asociado a la cuenta o licencia correspondiente. Para una plataforma instalada en infraestructura propia, como una solución web centralizada, el servidor debe estar disponible desde la red del reloj y los servicios requeridos deben estar activos. Si interviene NAT, VPN o múltiples sedes, TI debe definir la ruta; improvisar redirecciones de puertos públicos no es una buena práctica.

4. Registra o aprueba el dispositivo en el software

Una vez que el equipo puede llegar al servicio, la plataforma debería mostrarlo como dispositivo pendiente, conectado o reconocido, según el producto. Verifica número de serie, nombre del sitio y zona horaria antes de asignarlo. En plataformas de comunicación PUSH, el alta puede originarse desde la solicitud del dispositivo; ZKTeco incluso advierte en su FAQ que no siempre conviene agregar manualmente un equipo si el servidor debe detectarlo automáticamente (ZKTeco, 2026).

5. Sincroniza fecha, hora y zona horaria

Una conexión perfecta con la hora equivocada produce reportes incorrectos. Revisa fecha, zona horaria, horario estacional y la fuente que mantendrá sincronizados los dispositivos. En México, la política de horario estacional no es uniforme para todo el territorio, por lo que la configuración debe corresponder a la ubicación real de cada sucursal. Cuando hay varias sedes, cada evento debe llegar con la hora correcta y el software debe interpretarlo en el contexto del sitio.

 

 

6. Decide dónde se administrarán los usuarios

Evita crear a la misma persona de forma independiente en reloj y software sin una regla de identidad. Define si el alta maestra ocurrirá en la plataforma o en el equipo y cómo se distribuirán los usuarios. El ID debe ser estable: si “Empleado 125” existe con un número en una sucursal y con otro número en la central, los registros pueden duplicarse o quedar asociados a perfiles distintos. Antes de sincronizar una base existente, respalda plantillas y prueba con un grupo pequeño.

7. Envía usuarios al dispositivo o recupera la base existente

En una instalación nueva, lo habitual es cargar empleados en el software, asignarles el dispositivo o área correspondiente y sincronizar. En una migración, puede ser necesario recuperar usuarios existentes desde el reloj. Antes de usar una opción masiva, confirma qué elementos viajan: nombre, ID, tarjeta, huella, rostro, contraseña y privilegios no siempre se comportan igual en todos los modelos. La compatibilidad de plantillas biométricas también puede variar entre algoritmos o generaciones de hardware.

8. Genera checadas de prueba y confirma que llegan completas

Haz al menos cinco pruebas controladas: una entrada válida, una salida, un usuario no autorizado o inexistente, una marca durante una interrupción breve de red y otra después de recuperar la conexión. Revisa en el software hora, dispositivo, empleado, método de autenticación y estado. Si el reloj almacena eventos localmente cuando pierde red, confirma que los pendientes se envían después y que no se duplican.

9. Configura turnos, incidencias y reportes después de validar la comunicación

Que las marcas lleguen al software no significa que el sistema de asistencia esté terminado. Después se deben asignar horarios, calendarios, tolerancias, descansos, turnos nocturnos e incidencias. BioTime Cloud y BioTime Pro están diseñados para interpretar registros contra reglas de asistencia y generar reportes, pero la empresa debe probar sus propios casos antes de cerrar la implementación (ZKTeco Tienda Oficial, s. f.-c, s. f.-d).

10. Documenta la configuración y entrega la operación

Al terminar, documenta el modelo, número de serie, IP o reservación, nombre de red, sitio, software, versión, servidor, método de conexión, zona horaria, fecha de prueba, responsable y procedimiento de contingencia. No es recomendable guardar contraseñas administrativas en un documento abierto; registra dónde se custodian de forma segura. La documentación debe permitir que TI o soporte identifique el equipo sin depender de la memoria del instalador.

Qué arquitectura conviene según el tamaño y la operación

 

 

Ejemplos de equipos ZKTeco según el tipo de conexión

Los siguientes modelos sirven para visualizar escenarios de conectividad; no son una lista de compra obligatoria. La selección debe comenzar por el software y el flujo, y después validar que el equipo sea compatible con la versión contratada.

 

 

Errores comunes al conectar un reloj checador a software

1. Configurar primero el reloj y preguntar después si el software lo soporta.
2. Asignar una IP fija que ya está ocupada por otro dispositivo.
3. Usar Wi-Fi con señal débil y atribuir las pérdidas de sincronización al software.
4. Olvidar gateway o DNS cuando el servidor está fuera de la subred.
5. Configurar hora, zona horaria o horario estacional de forma distinta entre reloj y plataforma.
6. Abrir puertos en Internet o desactivar el firewall de forma permanente para “hacer que funcione”.
7. Crear usuarios con IDs diferentes en cada sucursal y después intentar consolidar las marcas.
8. Migrar cientos de plantillas biométricas sin probar compatibilidad de algoritmo y firmware.
9. Confundir “dispositivo en línea” con “registros procesados correctamente”.
10. No probar qué ocurre durante una caída de red y cómo se recuperan los eventos pendientes.
11. No documentar IP, servidor, serial, versión y responsable.
12. Integrar nómina antes de estabilizar horarios, incidencias y reportes de asistencia.

Problemas frecuentes y cómo diagnosticarlos

 

 

Diagnóstico seguro Desactivar antivirus o firewall puede servir como prueba temporal en un entorno controlado, pero no debe convertirse en la solución permanente. En producción, identifica el servicio y los puertos necesarios y crea reglas específicas. Si para funcionar el reloj necesita quedar expuesto directamente a Internet, revisa la arquitectura con TI antes de continuar.

 

Seguridad de red y de administración: qué no debes omitir

Un reloj checador es un dispositivo conectado que almacena identidades y eventos. Tratarlo como “solo un reloj” puede abrir una superficie innecesaria en la red. La conexión debería seguir el principio de mínimo acceso: el dispositivo necesita comunicarse con los servicios definidos, no con toda la infraestructura corporativa.

• Cambiar credenciales administrativas predeterminadas y limitar quién las conoce.
• Separar, cuando la infraestructura lo permita, los dispositivos de asistencia en una VLAN o segmento controlado.
• Permitir únicamente las comunicaciones requeridas hacia el servidor o servicio; evitar reglas “any-any”.
• Usar HTTPS, VPN o mecanismos de transporte seguro cuando la plataforma y la arquitectura lo soporten.
• Evitar administración remota abierta a Internet y redirecciones de puertos sin justificación.
• Mantener inventario de firmware y plan de actualización probado antes de desplegar masivamente.
• Revisar logs de desconexión, cambios administrativos y sincronización.
• Respaldar la base de datos y definir una política de recuperación, no solo de exportación de reportes.

Biometría, datos personales y registros laborales en México

Cuando el sistema procesa nombres, identificadores, fotografías, ubicaciones o plantillas biométricas, la empresa realiza tratamiento de datos personales. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares exige un tratamiento legítimo, controlado e informado, además de principios como finalidad, proporcionalidad, información y responsabilidad y medidas administrativas, técnicas y físicas para proteger la información (Cámara de Diputados del H. Congreso de la Unión, 2025).

La instalación técnica debe reflejar esa obligación: define qué datos se sincronizan, quién puede administrar biometría, cuánto tiempo se conserva, qué sucede cuando un empleado causa baja y qué alternativa existe si una persona no puede usar el método principal. No sincronices más información de la necesaria solamente porque el dispositivo la soporta.

En materia laboral, el artículo 804 de la Ley Federal del Trabajo contempla los controles de asistencia entre los documentos que el patrón debe conservar cuando los lleva en el centro de trabajo. A esto se suma la reforma del 1 de mayo de 2026 sobre registro electrónico de inicio y finalización de jornada. El reloj y el software pueden formar parte de ese proceso, pero el cumplimiento dependerá de las disposiciones aplicables, integridad de registros, configuración y gobierno de correcciones; ningún modelo garantiza por sí solo el cumplimiento jurídico (Cámara de Diputados del H. Congreso de la Unión, 2026; Diario Oficial de la Federación, 2026).

 

 

Antes de pedir soporte o una cotización

Tener la información correcta reduce mucho el tiempo de diagnóstico. Antes de contactar a soporte, prepara: modelo, número de serie, firmware, software y versión, tipo de conexión, dirección IP del reloj, red/sucursal, captura del estado del dispositivo en la plataforma, fecha y hora de una checada de prueba y descripción exacta del síntoma. Si el problema comenzó después de un cambio de red, router, servidor o licencia, indícalo desde el inicio.

 

Siguiente paso Si estás por conectar uno o varios relojes checadores, solicita que la propuesta incluya no solo el equipo: compatibilidad, red, alta del dispositivo, sincronización de usuarios, configuración del software, prueba de turnos, reporte de aceptación y capacitación. Ese alcance evita que “instalado” signifique únicamente que el dispositivo enciende.

 

Conclusión: una buena conexión se comprueba en el reporte, no en el icono “online”

Conectar un reloj checador a un software de asistencia implica más que enlazar dos equipos. La implementación debe confirmar compatibilidad, definir la arquitectura de red, configurar el servidor o servicio, sincronizar hora y usuarios, generar eventos de prueba y comprobar que el software interpreta correctamente los registros. La prueba final no es que el reloj tenga Internet: es que una checada pueda rastrearse desde el dispositivo hasta el reporte sin perder identidad, hora ni contexto.

Para una empresa pequeña, Wi-Fi y una plataforma en la nube pueden simplificar la administración. En varias sedes, el reto cambia hacia IDs únicos, monitoreo, roles, continuidad e integración. Y en entornos corporativos, seguridad de red, respaldo y gobierno de cambios se vuelven tan importantes como el protocolo de comunicación.

Antes de conectar toda la plantilla, prueba un dispositivo y un grupo pequeño de usuarios. Documenta la configuración, simula una caída de red y revisa el reporte de un turno real. Esa validación suele detectar más problemas que cualquier lista de especificaciones y reduce el riesgo de descubrirlos durante el cierre de nómina.

 

 

Preguntas frecuentes sobre conectar un reloj checador a software

¿Puedo conectar cualquier reloj ZKTeco a BioTime?

No necesariamente. Debe verificarse la lista de dispositivos compatibles, firmware y método de comunicación de la versión de BioTime que se utilizará.

¿Es mejor conectar por cable o Wi-Fi?

Para un punto fijo, Ethernet suele ofrecer mayor estabilidad. Wi-Fi puede ser suficiente si existe buena cobertura y una red bien administrada. La elección depende del modelo y de la infraestructura.

¿Necesito una IP fija?

No siempre. Una reservación DHCP puede ofrecer una dirección estable sin configurar manualmente el equipo. Lo importante es que la dirección sea predecible y esté documentada cuando la arquitectura lo requiera.

¿Qué es ADMS en un reloj checador?

Es una modalidad de comunicación utilizada por determinados equipos para enviar información hacia un servidor o plataforma configurada. El menú y los parámetros exactos dependen del dispositivo y firmware.

¿Puedo abrir un puerto del router para conectarlo desde Internet?

Técnicamente algunas arquitecturas lo permiten, pero no debería ser la primera opción. Es preferible utilizar el método de comunicación previsto por el fabricante, conexiones salientes, VPN o una arquitectura gestionada, con reglas mínimas y revisión de TI.

¿Qué hago si el software no detecta el dispositivo?

Confirma compatibilidad, red, servidor/ADMS, protocolo, puerto, fecha/hora y estado del servicio de comunicación. Revisa también firmware y logs antes de reiniciar o reinstalar.

¿Los empleados deben darse de alta en el reloj o en el software?

Depende de la plataforma, pero conviene definir una fuente maestra. En instalaciones centralizadas suele ser más ordenado administrar empleados en el software y sincronizarlos, evitando IDs diferentes por sucursal.

¿Qué pasa si se cae Internet?

Depende del modelo. Muchos equipos almacenan eventos localmente y los sincronizan al recuperar la comunicación. Esa conducta debe probarse con el dispositivo específico antes de producción.

¿Conectar el reloj al software ya cumple con el registro electrónico de jornada?

No. La conexión es solo una parte. Deben cumplirse las disposiciones aplicables, conservar integridad y trazabilidad y configurar correctamente horarios, usuarios y correcciones.

¿Cómo sé si la conexión quedó bien?

Genera marcas controladas, verifica hora e identidad, corta y restablece la red, confirma recuperación de eventos y revisa que el reporte final coincida con el escenario de prueba.

 

Referencias

• Cámara de Diputados del H. Congreso de la Unión. (2025). Ley Federal de Protección de Datos Personales en Posesión de los Particulares (última reforma DOF 14-11-2025). https://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf
• Cámara de Diputados del H. Congreso de la Unión. (2026). Ley Federal del Trabajo. https://www.diputados.gob.mx/LeyesBiblio/pdf/LFT.pdf
• Diario Oficial de la Federación. (2026, 1 de mayo). Decreto por el que se reforman, adicionan y derogan diversas disposiciones de la Ley Federal del Trabajo, en materia de reducción de la jornada laboral. https://dof.gob.mx/nota_detalle_popup.php?codigo=5786537
• ZKTeco. (2026). FAQ: conexión de dispositivos PUSH con ZKBio Time y configuración de servidor/ADMS. Recuperado el 24 de agosto de 2026, de https://zkteco.com/en/faq
• ZKTeco. (2026). ZKBio Time. Recuperado el 24 de agosto de 2026, de https://www.zkteco.com/en/ZKBio_Time/ZKBioTime
• ZKTeco Tienda Oficial. (2026a). Reloj checador vs Excel: diferencias, riesgos operativos y cuándo cambiar. https://zktecotiendaoficial.com/blog/reloj-checador-vs-excel-diferencias-riesgos-operativos-y-cuando-cambiar/
• ZKTeco Tienda Oficial. (s. f.-a). M1 | Terminal de asistencia con huella y conectividad Wi-Fi. Recuperado el 24 de agosto de 2026, de https://zktecotiendaoficial.com/product/m1/
• ZKTeco Tienda Oficial. (s. f.-b). Horus TL2 | Reloj checador de asistencia y control de acceso Wi-Fi con reconocimiento facial. Recuperado el 24 de agosto de 2026, de https://zktecotiendaoficial.com/product/horus-tl2/
• ZKTeco Tienda Oficial. (s. f.-c). BioTime Pro. Recuperado el 24 de agosto de 2026, de https://zktecotiendaoficial.com/software/biotime-pro/
• ZKTeco Tienda Oficial. (s. f.-d). BioTime Cloud 2.0. Recuperado el 24 de agosto de 2026, de https://zktecotiendaoficial.com/software/biotime-cloud/
• ZKTeco Tienda Oficial. (s. f.-e). P160 | Terminal biométrica con reconocimiento de palma y huella digital para asistencia. Recuperado el 24 de agosto de 2026, de https://zktecotiendaoficial.com/product/p160/
• ZKTeco Tienda Oficial. (s. f.-f). F22 | Control de acceso y asistencia Wi-Fi biométrico. Recuperado el 24 de agosto de 2026, de https://zktecotiendaoficial.com/product/f22/

---

Nota legal y técnica. Este artículo es informativo y no sustituye asesoría laboral, jurídica, de protección de datos, redes o ciberseguridad. Los menús, protocolos, puertos, versiones y compatibilidades cambian por modelo y firmware; la configuración final debe validarse con la documentación vigente y con el responsable de TI o integrador.