Asistencia biométrica sin IP fija: cómo resolver el problema de red de una vez

El bloqueo más común del sector

Un cliente quiere asistencia biométrica en 5 franquicias. Tres usan internet residencial, una usa 4G y la quinta está en obra. El proveedor local responde: "necesitamos IP fija en cada sede". Y ahí muere el proyecto: la IP fija cuesta extra, a veces ni está disponible, y configurar 5 redes distintas no es un plan — es una lista de tickets.

El problema de fondo es el modelo de conexión: si tu software entra a la red del cliente para leer el marcador, la red del cliente tiene que estar accesible desde afuera. Ese requisito es el que genera todo el problema.

Las opciones tradicionales (y su precio real)

Cómo funciona el modo push (versión conceptual)

Los terminales ZKTeco modernos soportan un modo en el que el dispositivo es quien sale: se conecta a la dirección del servidor en la nube y entregarle sus eventos — marcaciones, pulsos de vida, sincronizaciones — por su propia iniciativa, sin que nadie entre a la red donde está instalado.

Las consecuencias prácticas:

• La IP del cliente puede ser dinámica y cambiar cuando quiera: no importa, porque nunca entras a su red.
• 4G funciona: un router con SIM es la instalación más común en obra y eventos.
• Variedad de sedes tras un solo NAT: varios terminales comparten la misma salida a internet sin conflicto.
• Cero tickets de red: no hay puertos que abrir, ni reglas de firewall que negociar con el cliente.

Qué significa esto para tu software

Si desarrollas el sistema (ERP, nómina, control de condominios), el modo push te cambia la conversación de implementación:

• Onboarding en horas, no en semanas: el técnico de la sede solo configura en el terminal la dirección del servidor y el número de serie queda registrado en tu plataforma.
• Multi-sede sin infraestructura: cada sucursal es un terminal más en la API, no un proyecto de red.
• Eventos en tiempo real: recibes cada marcación en el momento, no importas archivos al final del día.

Consumir los eventos desde tu backend se ve así:

import { createClient } from 'redis';

const sub = createClient({
  socket: { host: process.env.REDIS_HOST, port: Number(process.env.REDIS_PORT) },
  password: process.env.REDIS_PASSWORD
});

await sub.connect();

await sub.subscribe('punch_TU-SERIAL', (message) => {
  const event = JSON.parse(message);
  // marcar asistencia en tu sistema, notificar, disparar reglas...
  console.log(event.pin, event.timestamp);
});

Y si prefieres consultar en vez de escuchar, la API REST expone los reportes por terminal con rango de fechas y paginación.

¿Y si se cae el internet de la sede?

Es la pregunta correcta. Los terminales almacenan las marcaciones en su memoria local mientras no hay conexión y las reenvían cuando la red vuelve: el dispositivo es tolerante a caídas temporales. Para tu software, la recomendación es simple: usa los eventos en tiempo real para lo urgente (notificaciones, accesos) y el reporte REST como fuente de verdad para la conciliación.

Preguntas frecuentes