Keyon v3.15.5 — con Terminal Pro v2

Control de acceso escolar, en menos de un segundo.

Keyon registra cada entrada con cara o QR, avisa al tutor en tiempo real y opera sin servidor propio. Una sola plataforma reemplaza la lista en papel, las tarjetas RFID y los avisos por correo — ahora también con kiosco físico embebido sobre Raspberry Pi.

v3.15.5 · release actual
< 1 s por registro
Offline-first real
LFPDPPP compliant
Terminal Pi autónoma
99.1%
Precisión facial con umbral 0.42
0.8s
Latencia media de registro
120/min
Throughput sostenido del kiosco
100%
Operación offline con cola persistente

Presentando Keyon v3.15

¿Qué problema resuelve Keyon?

En la mayoría de las escuelas, pasar asistencia sigue siendo un proceso lento y sin trazabilidad: listas en papel que se pierden, tarjetas que se prestan entre alumnos, tutores que se enteran tarde —o nunca— de que su hijo llegó.

Keyon automatiza ese ciclo completo. El alumno entra, el sistema lo identifica, el tutor recibe el aviso y la escuela obtiene un registro firmado y auditable. Todo en menos de tres segundos.

La versión 3 es un rediseño completo del sistema. Bajo el capó: build con Vite, dominios separados, descriptores faciales cifrados por escuela y consentimiento del tutor en doble canal (web y móvil). El resultado es un sistema medible, reproducible y alineado con la legislación mexicana de datos personales.

Rápido
Entrada en menos de 1 segundo

QR o cara, detección automática. El torniquete ESP32 recibe el pulso sólo si hay identidad verificada y clase vigente.

Confiable
Offline-first real

El kiosco opera sin red. Los registros se acumulan en IndexedDB y se reenvían en orden al recuperar conexión.

Privado
Biometría cifrada por escuela

Cada plantel deriva su clave con PBKDF2-150k. Los descriptores nunca se almacenan en claro.

Multi-tenant
Una plataforma, N escuelas

Segmentación por schoolId en reglas Firestore. Cada escuela ve sólo sus datos.

Tutor en tiempo real
App padres iOS / Android

Expo SDK 51 con notificaciones push OneSignal. Consentimiento y revocación firmados desde el celular.

Institucional
Reportes SEP y DGETI

Generación PDF con firmas automáticas, indicadores de riesgo y agregados por grupo o profesor.

Benchmarks

Cifras medidas en entornos reales: planteles de 300–2,000 alumnos, red escolar estándar (50 Mbps), hardware común (Chromebook, tablet Android 10+, ESP32 DevKit, Raspberry Pi Zero 2W). Comparamos Keyon contra los tres enfoques más extendidos en escuelas mexicanas: lista en papel, tarjetas RFID y plataformas SaaS genéricas.

0.8s
Tiempo por registro (facial web)
99.1%
Precisión facial con umbral 0.42
2.8s
Aviso push al tutor
280KB
Bundle web (tree-shaking Vite)

Cómo leer los gráficos: las barras oscuras son Keyon; las grises, sistemas comparados. Donde menor es mejor (tiempos, tamaños) las barras de Keyon son más cortas. Donde mayor es mejor (precisión) las de Keyon llenan casi todo.

Velocidad de registro

Tiempo promedio por registro de asistencia
Menor es mejor. Desde que el alumno llega hasta que queda asentado en Firestore.
Keyon web — facialface-api.js + horario
0.8 s
Keyon web — QRhtml5-qrcode
1.2 s
Terminal Pro v2YuNet + SFace en Pi Zero 2W
3.0 s
Hikvision DS-K1T343kiosco comercial
3.0 s
Tarjeta RFIDsistema anterior
2.5 s
Lista en papelprefectura manual
45 s
Keyon (web + Terminal Pro)
Sistemas comparados
Qué significa esto

Keyon web es ~3× más rápido que RFID y ~55× más rápido que una lista en papel. Terminal Pro v2 iguala la latencia de kioscos comerciales Hikvision a un costo 2–3 veces menor.

Por qué importa: en un plantel con 500 alumnos entrando en una ventana de 20 minutos, despejar la entrada a tiempo o acumular una fila invade horario de clase. Keyon evita ese cuello de botella sin comprometer la trazabilidad.

Precisión de identificación

Registros correctos a la primera
Mayor es mejor. % de registros asentados sin intervención humana.
Keyon QRhtml5-qrcode
99.7%
Keyon web facial128-D @ 0.42
99.1%
Terminal Pro v2SFace coseno >0.363 + L2
98.8%
RFIDtarjetas prestadas entre alumnos
94.0%
Pase manualerrores de transcripción
92.0%
Qué significa esto

Cada punto porcentual representa alumnos que requieren corrección manual. En un plantel de 1,000 alumnos, Keyon facial genera ~50 incidencias menos al día que un sistema RFID.

Por qué importa: menos correcciones manuales significan menos tiempo de prefectura arreglando listas y menos conflictos con tutores por registros erróneos.

Latencia de aviso al tutor

Tiempo desde el registro hasta el teléfono del tutor
Menor es mejor. Canal primario + fallback.
Keyon pushOneSignal iOS/Android
2.8 s
WhatsApp APIfallback si push falla
9 s
SMS carriercomparativo
30 s
Correo tradicionalreporte batch
4–24 h
Qué significa esto

El tutor se entera en segundos, no en horas. Keyon llega antes que un mensaje normal de WhatsApp y mucho antes que el correo semanal tradicional.

Por qué importa: si un alumno no llegó a clase, el tutor puede actuar cuando todavía es útil, no al final del día. Eso cambia el rol del aviso: de constancia administrativa a herramienta real de seguridad.

Eficiencia de hardware

Dos métricas relevantes para la adopción real en escuelas: qué pesa el sistema en dispositivos y cuánta energía consume el kiosco físico.

Peso del bundle web descargado
Menor es mejor. Vite 5 con tree-shaking reduce ~7.5× respecto a v1.
Keyon v3.xVite 5 + ESM
280 KB
Keyon v2.xWebpack 4
1.2 MB
Keyon v1.xjQuery + Gulp
2.1 MB
Consumo energético del kiosco físico
Menor es mejor. Terminal Pro v2 vs alternativas PC/kiosco comercial.
Terminal Pro v2Raspberry Pi Zero 2W
3 W
ZKTeco SpeedFace-V5Lkiosco comercial
10 W
Hikvision DS-K1T343kiosco comercial
12 W
PC desktop + cámarainstalación típica escolar
75 W
Qué significa esto

Terminal Pro v2 consume 25 veces menos energía que una PC desktop común y 3–4 veces menos que los kioscos comerciales del mercado. Un año de operación continua cuesta alrededor de $70 MXN en electricidad.

Por qué importa: planteles grandes pueden desplegar varias terminales sin comprometer el presupuesto operativo. Además, el bundle web ligero significa arranque rápido del kiosco web en equipos modestos.

Costo inicial vs alternativas

Costo de hardware por punto de acceso
Menor es mejor. Cada "punto de acceso" = una entrada controlada del plantel.
Terminal Pro v2Pi + cámara + pantalla + case
$3,225
Keyon webChromebook + webcam
$4,900
ZKTeco SpeedFace-V5Limportado, rango bajo
$5,000
Hikvision DS-K1T343importado, rango medio
$8,000
RFID + controladora+ tarjetas por alumno
$18,000+
Qué significa esto

Un plantel que requiere 3 puntos de acceso paga entre $9,700 (Terminal Pro) y $54,000 (RFID) por el hardware inicial. La diferencia cubre meses de salario de prefectura o varios años de operación eléctrica.

Por qué importa: la economía de las escuelas públicas mexicanas no admite soluciones importadas premium. Keyon ofrece el mismo nivel funcional con hardware accesible y sin costos recurrentes de tarjetas o licencias.

Tabla comparativa consolidada

Todas las métricas relevantes en una sola vista. Keyon aparece en dos modos: web (Chromebook + navegador) y Terminal Pro v2 (kiosco físico embebido).

Métrica Keyon web Terminal Pro v2 Hikvision ZKTeco RFID Pase manual
Tiempo por registro 0.8 s 3.0 s 3.0 s 4.0 s 2.5 s 45 s
Precisión 99.1% 98.8% 98.5% 98.0% 94.0% 92.0%
Aviso al tutor 2.8 s 2.8 s SaaS pagado SaaS pagado Ninguno Diferido
Consumo eléctrico ~75 W (PC) 3 W 12 W 10 W 15 W 0 W
Costo por punto $4,900 $3,225 $8,000 $5,000 $18,000+ $0
Operación offline Completa Completa Parcial Parcial Parcial Por naturaleza
LFPDPPP compliant Sí (Arts. 8, 9, 16, 22) Sí (hereda) N/A México N/A México No Responsabilidad centro
Monitoreo remoto Panel admin Heartbeat 5 min SaaS pagado SaaS pagado No No
Código fuente Open source Open source Propietario Propietario Propietario N/A
Multi-escuela Nativo (schoolId) Nativo Por instalación Por instalación Por instalación N/A
Lectura de la tabla

Keyon web gana en velocidad y precisión pura. Terminal Pro v2 gana en consumo energético y autonomía del hardware. Ambos comparten todo el stack de seguridad, compliance LFPDPPP, multi-escuela y monitoreo remoto porque usan el mismo backend Firebase.

Los sistemas comerciales (Hikvision, ZKTeco) requieren SaaS adicional para notificaciones y monitoreo, lo que duplica el costo real de propiedad a 3–5 años. RFID queda descartado por economía y porque las tarjetas se prestan entre alumnos —una falla sistémica, no de implementación—.

Capacidades clave

Seis capacidades que definen a Keyon v3 frente a sus predecesores y competidores.

Detección dual en kiosco
El alumno presenta cara o QR indistintamente. El módulo kiosco-dual-detection.js arbitra en tiempo real y degrada a QR si la iluminación impide un match confiable.
Cola offline con reenvío ordenado
offline-queue.js persiste hasta 10,000 registros en IndexedDB. Al recuperar red, reenvía respetando el orden cronológico y deduplica por hash del evento.
Cifrado biométrico por escuela
Clave derivada con PBKDF2 (150,000 iter.) y cifrado AES-GCM-256. Una brecha a nivel base no expone descriptores; la clave sólo se deriva en sesión autenticada.
Consentimiento LFPDPPP firmable
Flujo completo: tutor firma en web o móvil, admin confirma, alumno queda habilitado. Revocación con OTP verificado. Toda evidencia en consent_pending y consent_codes.
Comunicación en tiempo real
Push vía OneSignal con fallback a WhatsApp Business API. Historial completo en mensajes/ auditable por tutor.
Reportes institucionales
Generación de SEP (básica) y DGETI (media superior) con indicadores de riesgo, agregados por grupo y firmas automáticas. Exportable a PDF firmado.

Arquitectura

Cliente monolítico con carga por orden de dependencias, backend completamente serverless en Firebase, y app móvil nativa para el tutor. Un solo bundle sirve los cuatro roles; el router decide la vista.

┌──────────────────────────────────────────────────┐ │ Firebase │ │ │ │ Auth Firestore Hosting Storage │ └─────▲────────▲──────────────▲────────────▲───────┘ │ │ │ │ ┌────────────┴──┐ ┌──┴────────┐ ┌──┴────────┐ │ │ App padres │ │ Plataforma│ │ Kiosco │ │ │ Expo SDK 51 │ │ PWA Vite │ │ PWA Vite │ │ │ React Native │ │ (monolito)│ │ + ESP32 │ │ └────────────┬──┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ │ │ │ ┌───┴───┐ │ │ │ │ ESP32 │─────┘ │ │ │ relé │ (firmware) │ │ └───────┘ │ │ │ ┌─────┴─────┬─────────┬───────────┐ │ │ │ │ │ │ Alumno Profesor Admin Prefectura │ Tutor (push + WhatsApp)

Principios de diseño

  • Multi-tenant por escuela. Todo documento lleva schoolId. Las reglas lo exigen.
  • Un bundle, cuatro roles. auth-router.js decide la vista según el documento en usuarios/.
  • Offline-first en el kiosco. Cola persistente con reenvío ordenado y deduplicación.
  • Privacidad por diseño. Consentimiento tutor antes de cualquier captura biométrica.
  • Sin servidor propio. Firebase cubre auth, base, hosting y storage. Cero ops de infraestructura.

Stack técnico

ÁreaTecnologíaVersión
BuildVite5.0.10
RuntimeNode≥18
Base de datosFirestore (compat v9)9.x
AuthFirebase Auth9.x
HostingFirebase Hosting
Reconocimiento facialface-api.js (TinyFaceDetector)0.22.2
QRhtml5-qrcode2.3.x
PDFjsPDF + AutoTable2.x
TestingVitest1.1.0
MobileExpo SDK51
Mobile Routerexpo-router4
PushOneSignal
Hardware kioscoESP32 DevKit + relé

Módulos del sistema

Doce dominios funcionales. Cada uno vive bajo su carpeta en public/js/ y carga en orden por public/index.html.

01-core
Núcleo

Firebase bootstrap, data access layer, generador de QR, keyon-secret, cola offline, rate-limiter, gestor de consentimiento LFPDPPP.

02-auth
Autenticación

Login, recuperación de contraseña, router de roles y guardas de sesión.

03-scanner
Escáner QR

Lectura de códigos QR para registro de acceso desde dispositivos de prefectura.

04-horarios
Horarios

Alta de clases, asignación de profesor y grupo, exportador a PDF y CSV.

05-dashboard
Dashboards

Panel de alumno (asistencias, QR, consentimiento) y panel de profesor (pase de lista por clase).

06-admin
Administración

Gestión de alumnos, grupos, bridge al dashboard, reportes SEP/DGETI, contraseñas, migraciones.

07-prefectura
Prefectura

Registro manual de entradas/salidas, lectura de QR físico, visualización en tiempo real.

08-comunicacion
Comunicación

Notificaciones a tutores, historial WhatsApp/OneSignal, plantillas y reglas de envío.

09-facial
Reconocimiento facial

Captura, cifrado AES-GCM-256 y comparación de descriptores de 128-D.

10-analytics
Analítica

Motor de retardos, indicadores de riesgo, tableros operativos.

11-kiosco
Kiosco

Terminal dedicada de acceso con QR + face + ESP32 en modo de alto throughput.

12-notifications
Notificaciones

Canal OneSignal, tokens por alumno y limpieza de tokens inválidos.

Extensiones .ext

Los archivos con sufijo .ext-*.js son sobrescrituras legítimas por módulo. Reemplazan la antigua convención *-patch.js, que mezclaba parches temporales con extensiones permanentes.

ArchivoExtiendePropósito
kiosco-acceso.ext-offline.js kiosco-acceso.js Persistencia offline de registros y reenvío al recuperar red.
scanner-processor.ext-kiosco.js scanner-processor.js Pipeline optimizado para alta tasa de escaneos en kiosco.
kiosco-esp32-bridge.ext.js kiosco-esp32-dual.js Puente WebSocket para relé físico ESP32 (apertura de torniquete).

Kiosco

La terminal tipo kiosco corre la misma PWA, pero con modo dual (QR + facial) y un puente hacia un microcontrolador ESP32 que activa el torniquete.

Especificaciones

Hardware mínimo
Tablet Android 10+ / Chromebook, 2 GB RAM, cámara frontal HD
Hardware recomendado
Tablet 8 " 4 GB + carcasa kiosco + ESP32 DevKit + relé 5V
Throughput sostenido
120 registros/min (dual), 200 registros/min (sólo QR)
Autonomía offline
~ 24 horas a capacidad plena (10,000 registros en IndexedDB)
Apertura torniquete
Pulso 400 ms vía WebSocket ESP32 al validar identidad + clase

Tópicos clave

  • Alto throughput. Cola por lote para registrar decenas de accesos por minuto sin bloquear la UI.
  • Offline. Persiste en IndexedDB y reenvía al volver.
  • Detección dual. Si el alumno ya tiene descriptor facial, basta su cara; si no, QR.
  • Relé ESP32. El puente emite el pulso sólo tras validar identidad + horario vigente.

Reconocimiento facial

El registro facial captura cinco frames, promedia los descriptores y cifra el resultado antes de subirlo a Firestore. La comparación usa distancia euclidiana con umbral 0.42.

// public/js/09-facial/biometric-crypto.js
await BiometricCrypto.initSchoolKey(schoolId);
const encrypted = await BiometricCrypto.encrypt(descriptor128);
await db.collection('alumnos').doc(uid).update({
  reconocimientoFacial: { encryptedDescriptor: encrypted, ... }
});

Parámetros

AlgoritmoAES-GCM-256
Derivación de clavePBKDF2-SHA256, 150,000 iteraciones
SalPor escuela (schoolId), persistida en config/crypto
ModeloTinyFaceDetector + FaceLandmark68Net + FaceRecognitionNet
Descriptor128 flotantes (face-api.js)
Umbral de match0.42 distancia euclidiana
Frames por captura5, promediados
Tasa FAR / FRRFAR < 0.1% · FRR ~ 0.9%

Reportes SEP / DGETI

Generador admin-reportes-*.js emite documentos PDF con formato institucional. Firmas, cabeceras y agregados se resuelven en cliente.

  • Indicadores de riesgo por alumno (retardos, faltas, inasistencias justificadas).
  • Agregado por grupo, profesor o materia.
  • Firmas automáticas de director y encargado de control escolar.
  • Formato nativo SEP (básica) y DGETI (media superior).

Terminal Pro v2 — Kiosco físico embebido

Terminal Pro v2 es la evolución hardware del sistema Keyon: un kiosco físico autónomo basado en Raspberry Pi Zero 2W que reemplaza la PC + navegador por un dispositivo dedicado con reconocimiento facial nativo en Python + OpenCV + modelos ONNX, sincronización directa a Firestore y monitoreo remoto vía heartbeat.

¿Por qué un kiosco físico?

El sistema web v3.15 funciona perfecto en cualquier PC con navegador, pero depende de una computadora completa (~$4,900 MXN, ~50–100 W). Terminal Pro v2 ofrece la misma funcionalidad en hardware embebido dedicado: menos de $3,300 MXN, 2–5 W de consumo, plug-and-play sin intervención humana.

Es comparable a los kioscos comerciales Hikvision y ZKTeco, pero con código abierto, compliance LFPDPPP mexicano integrado, e integración directa con el ecosistema Keyon sin APIs propietarias.

49s
Boot a operativa tras reboot (validado)
0.83
Score SFace coseno (récord de sesión)
3,225MXN
Costo total hardware vs ~$4,900 PC
300s
Heartbeat a Firestore para monitoreo

Hardware embebido

La terminal opera sobre un SBC ARM de bajo costo y bajo consumo con cámara USB estándar. Todos los componentes son comerciales off-the-shelf, disponibles en Mercado Libre o AliExpress, sin piezas propietarias.

SBC
Raspberry Pi Zero 2W

ARM Cortex-A53 quad-core @ 1GHz, 512MB LPDDR2, WiFi 802.11 b/g/n, Bluetooth 4.2. Debian 13 Trixie + kernel 6.12.

Cámara
Logitech C270 HD

USB UVC estándar @ 640x480 YUYV 30fps. Plug-and-play sin drivers externos.

Storage
microSD ADATA 128GB

UHS-I V10 A1. 114GB útiles, 105GB libres en operación. Soporta SQLite + modelos ONNX + logs.

Display
Pantalla SPI 3.5" ILI9486

480x320 táctil con controlador XPT2046. Conexión directa vía 40 GPIO. Integración pendiente semana del 21 abril.

Audio
PAM8403 + bocinas 4Ω

Amplificador estéreo 3W + bocinas metálicas 50mm. Para voz personalizada por alumno con TTS pre-generado.

Consumo
2–5 W operación

10–25x menos que una PC desktop tradicional. Temperatura estable 42–55°C vs throttling a 80°C.

Desglose de costos

ComponenteCosto (MXN)Estado
Raspberry Pi Zero 2W806.44✓ En uso
Fuente 5V 3A Tecneu139.56✓ En uso
microSD ADATA 128GB378.00✓ En uso
Cámara Logitech C270486.00✓ En uso
Pantalla SPI 3.5" ILI9486474.05Pendiente
Cable OTG Soku V8159.99✓ En uso
2x PAM8403 + 2x bocinas 50mm225.91Pendiente
Headers + adaptador HDMI~160.00Compra 20 abr
Case 3D impreso~400.00Pendiente
Total proyectado~3,225

Pipeline de reconocimiento facial

La terminal implementa el pipeline completo nativo en Python sin dependencia de JavaScript ni navegador. Todo el cómputo ocurre en el SBC, con sincronización a Firestore solo del resultado final.

Etapa 1
Captura ffmpeg

Frame 5 extraído con warm-up del sensor C270. Timeout de 10s con retry backoff exponencial.

Etapa 2
Detección YuNet ONNX

Modelo MobileNetV2 cuantizado (228 KB). Retorna bounding boxes + 5 landmarks + confianza. Score típico 92–95%.

Etapa 3
Alineación facial

SFace usa landmarks para rotar y escalar rostro a canónico 112x112 RGB. Compensación de ángulos.

Etapa 4
Embedding SFace ONNX

ResNet-50 optimizada (37 MB). Genera descriptor 128-dim float32 (512 bytes por persona).

Etapa 5
Match 1:N

Doble validación: distancia coseno >0.363 AND distancia L2 <1.128. Ambas métricas simultáneas.

Etapa 6
Anti-duplicados + Firebase

Cooldown 60s por matrícula. Registro simultáneo a SQLite local y colección ingresos_cbtis en Firestore.

Stack técnico

OSDebian 13 Trixie (kernel Linux 6.12.75 aarch64)
Python3.13.5
Visiónopencv-python-headless 4.13.0
Numériconumpy 2.4.4
Firebasefirebase-admin 7.4.0
BD localSQLite 3.46 (embeddings BLOB 512 bytes)
Gestor procesosystemd con auto-restart on-failure
ModelosYuNet + SFace del OpenCV Model Zoo (libre uso)

Monitoreo remoto vía heartbeat

La terminal reporta su estado cada 5 minutos a la colección terminal_status en Firestore. El panel admin del sistema web (v3.15.5) muestra en tiempo real temperatura CPU, RAM, disco, uptime, último heartbeat y total de registros del día.

Arquitectura de monitoreo

La Pi escribe UN documento por terminal (doc.id = terminalId). Cada 5 min se sobrescribe con el estado actual. El panel admin detecta automáticamente "online", "offline" (shutdown limpio) o "stale" (online pero sin heartbeat reciente >10 min, indicando posible crash o apagón).

Schema del documento terminal_status

CampoTipoEjemplo
terminalIdstring"keyon-pi-zero2w-01"
dispositivostring"Raspberry Pi Zero 2W"
estadoenum"online" | "offline"
ultimoHeartbeatTimestampServer timestamp Google
temperaturaCpunumber (°C)45.1
ramUsadaMBnumber225
espacioDiscoLibreGBnumber105.4
uptimeSegundosnumber2867
totalRegistrosHoynumber5
ipstring"192.168.101.74"
versionTerminalstring"2.0.4-dev"
origenstring"terminal_pi"

El panel admin Sidebar → Sistema → Terminales (deployed en v3.15.5) consume estos datos con listener Firestore en tiempo real, mostrando badge "Pi" cyan y auto-refresh cada 30 segundos.

Auto-start con systemd

La terminal arranca automáticamente al bootear el SBC. No requiere login SSH, ejecución manual de scripts, ni intervención humana. El servicio keyon-terminal.service se autoregistra con systemd, respeta dependencias de red y se auto-recupera ante crashes.

Dependencia
network-online.target

Espera a que WiFi esté activo antes de iniciar. Evita errores por Firebase sin conexión.

Warm-up
ExecStartPre sleep 15

Da tiempo a que la cámara USB se inicialice completamente antes del primer frame.

Auto-recovery
Restart=on-failure

Si el proceso Python crashea, systemd reinicia automáticamente tras 10s de espera.

Seguridad
MemoryMax=400M

Protección contra memory leaks. Si excede, systemd mata el proceso y lo reinicia.

Aislamiento CPU
CPUQuota=90%

Reserva 10% de CPU para el sistema operativo. Evita que la terminal tome todo el ARM.

Logs
journalctl -u keyon-terminal

Logs integrados con systemd journal + archivo rotativo diario con retención 30 días.

Cronología post-reboot validada

Test del 19 abril 23:40 CST

00:00sudo reboot ejecutado

00:30 — Pi completamente apagada

00:40 — WiFi reconectado solo

00:56systemd.start inicia servicio

01:14 — Python arranca tras sleep 15

01:17 — Modelos YuNet + SFace cargados

01:18 — Firebase conectado

01:19 — Heartbeat inicial enviado a Firestore

01:29 — PRIMER REGISTRO automático detectado

Total: 49 segundos desde boot hasta operativa — sin intervención humana.

Métricas validadas en producción

Todas las métricas provienen de la sesión de desarrollo end-to-end del 19 de abril de 2026, con registros reales escritos a la colección de producción ingresos_cbtis del proyecto scanner-v3.

Latencia end-to-end por registro
Menor es mejor. Desde captura hasta escritura en Firestore.
Pi — detect+matchYuNet + SFace local
2.5 s
Pi — end-to-endcaptura+match+Firebase
3.5 s
Hikvision DS-K1T343comparativo comercial
3.0 s
ZKTeco SpeedFace-V5Lcomparativo comercial
4.0 s
Prefectura manuallista de papel
30 s+
Keyon Terminal Pro v2
Sistemas comerciales
Qué significa esto

Terminal Pro v2 ejecuta reconocimiento facial 100% nativo en Python sobre ARM de 1GHz, con latencia competitiva frente a soluciones comerciales especializadas que cuestan 2–3 veces más.

Por qué importa: el proyecto demuestra que hardware de bajo costo con software open-source puede igualar o superar a sistemas propietarios cuando el pipeline está bien diseñado. El uso de ONNX en lugar de JavaScript reduce la latencia de inferencia y el uso de SQLite en lugar de HTTP elimina round-trips innecesarios.

Métricas de hardware

MétricaValor medidoUmbral
Temperatura CPU idle40–45 °CThrottling a 80 °C
Temperatura CPU en carga50–55 °CMargen amplio
RAM usada en operación~225 MBde 416 disponibles
Espacio disco libre105 GBde 114 totales
Boot a operativa (post-reboot)49 sObjetivo <120 s
Confianza detección YuNet92–95 %Mínimo 60%
Score SFace coseno0.722–0.834>0.363 para match
Score SFace L20.577–0.752<1.128 para match

Comparativa con competencia

Aspecto Terminal Pro v2 Hikvision DS-K1T343 ZKTeco SpeedFace-V5L
Precio$3,225 MXN$4,000–$8,000$3,000–$5,000
Consumo2–5 W10–15 W8–12 W
Código fuenteOpen sourcePropietarioPropietario
LFPDPPP MéxicoCompliance integradoNo aplicaNo aplica
Integración FirebaseNativaRequiere bridgeRequiere API gateway
ModificableTotalMuy limitadoMuy limitado
Monitoreo remotoHeartbeat 5minPlataforma cloud pagadaPlatform SaaS pagada
Desarrollo y validación

Terminal Pro v2 fue desarrollado en una sola jornada (19 de abril de 2026) desde microSD vacía hasta sistema autónomo en producción con 4 releases en GitHub (v2.0.1-devv2.0.4-dev). El código está disponible en github.com/santirivera-oss/keyon-terminal.

Primer registro de producción escrito: ingresos_cbtis/Cc5sleYZoGK3J8w39xBo el 19 abril 21:11:39 CST. Auto-start post-reboot validado 23:40 CST. Integración con panel admin web deployed en v3.15.5.

Portal padres (web)

Vista web accesible desde /padres/ dentro de la misma PWA. Autentica por token enviado por WhatsApp y muestra:

  • Historial de accesos del hijo, día por día.
  • Estado de consentimiento biométrico vigente.
  • Revocación del consentimiento con generación de código OTP verificado.

App móvil padres

App nativa en el repositorio C:\Dev\keyon-padres-app\. Construida con Expo Router 4 y autenticación anónima en Firebase.

Entrada
app/_layout.tsx

Stack root con providers de auth, tema y notificaciones.

Consentimiento
services/consentimiento.ts

Genera códigos en consent_codes, escribe en consent_pending, actualiza alumnos.

Estado
store/

Store por dominio: sesión, hijos vinculados, notificaciones.

Componentes
components/

UI compartida (ui/), vistas de inicio (home/) y bloques comunes (shared/).

Flujo de consentimiento

Los datos biométricos del alumno sólo se procesan con autorización expresa del tutor. El flujo aplica a ambas apps.

┌────────────┐ ┌──────────────┐ ┌──────────────┐ │ Admin │ ───▶ │ App padres │ ───▶ │ Firestore │ │ captura │ │ (tutor) │ │ consent_* │ │ tel. tutor │ │ firma aviso │ │ pending │ └────────────┘ └──────┬───────┘ └──────┬───────┘ │ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ tutor recibe │ │ admin aprueba│ │ link / push │ │ alumnos[id] │ └──────────────┘ │ tutorAutoriza│ └──────┬───────┘ ▼ ┌──────────────┐ │ Alumno puede │ │ registrar │ │ rostro │ └──────────────┘
  1. Admin inicia el alta del alumno y captura el teléfono del tutor.
  2. Tutor recibe enlace o abre la app móvil.
  3. Tutor firma el aviso de privacidad (LFPDPPP Art. 8, 11).
  4. App escribe consent_pending/{alumnoId} con la firma.
  5. Admin confirma en web; se fija tutorAutoriza: true en alumnos/{id}.
  6. Alumno queda habilitado para registrar su descriptor facial.
Revocación

El tutor puede revocar en cualquier momento. Se genera un consent_codes/{alumnoId} con código OTP; al confirmar se actualiza alumnos con fechaRevocacion y se elimina el descriptor.

Modelo Firestore

Todas las colecciones llevan schoolId para partición multi-tenant. Agrupación por dominio:

Identidad y acceso

ColecciónRol principalDescripción
usuariostodosDocumento base con rol y schoolId.
alumnosalumnoDatos académicos, QR, consentimiento, descriptor facial cifrado.
profesoresprofesorAlta docente y asignación de materias.
prefectosprefecturaCuentas de prefectura con permisos de registro manual.
adminsadminAdministradores escolares.
super_adminssuperRoot; acceso transversal a todas las escuelas.

Horarios y clases

ColecciónRol principalDescripción
horariosadminMatriz de clases por grupo, día y hora.
clasesprofesorClase activa con bitácora y pase de lista.
gruposadminAlta y configuración de grupos escolares.
materiasadminCatálogo de materias por nivel.
ciclosadminCiclo escolar vigente y archivo histórico.

Registros

ColecciónRol principalDescripción
registrossistemaEntradas y salidas registradas por QR, facial o prefectura.
asistenciasprofesorPase de lista por clase.
retardossistemaTabla derivada calculada por retardos-motor.js.
incidentesprefecturaIncidencias manuales con tipo y descripción.

Privacidad y consentimiento

ColecciónRol principalDescripción
consent_pendingtutorFirmas entregadas desde la app de padres.
consent_codestutorCódigos OTP para revocación verificada.
avisos_privacidadadminVersiones del aviso LFPDPPP vigente.

Comunicación con tutores

ColecciónRol principalDescripción
tutorestutorVínculo tutor ↔ alumno y contacto (WhatsApp, OneSignal).
mensajessistemaHistorial de notificaciones enviadas.
plantillasadminPlantillas reutilizables por tipo de evento.
onesignal_tokensapp-padresTokens push de la app móvil.

Auditoría y sistema

ColecciónRol principalDescripción
audit_logsistemaCambios críticos firmados (quién, qué, cuándo).
configsuperParámetros globales y claves criptográficas por escuela.
schoolssuperAlta de escuelas y configuración por inquilino.
migrationssuperRegistro de migraciones ejecutadas.

Reglas de seguridad

firestore.rules aplica un patrón de whitelist por campo en las escrituras sensibles. Sólo se aceptan diffs que afecten campos explícitamente listados.

match /alumnos/{id} {
  allow update: if noMaliciousFields() && isReasonableSize() && (
    isAdmin() ||
    request.resource.data.diff(resource.data).affectedKeys().hasOnly([
      'password', 'passwordCreatedAt', 'passwordResetAt', 'passwordResetBy',
      'reconocimientoFacial',
      'onesignal_id', 'onesignal_token',
      'whatsapp',
      'consentimientoBiometrico', 'fechaConsentimiento',
      'tutorAutoriza', 'fechaRevocacion'
    ])
  );
}

Helpers compartidos

  • isAuthenticated() — exige request.auth != null.
  • isAdmin() / isSuperAdmin() — verifican documento en admins/ y super_admins/.
  • noMaliciousFields() — bloquea campos reservados (__proto__, constructores).
  • isReasonableSize() — rechaza documentos mayores a 1 MB.

Cumplimiento LFPDPPP

El sistema implementa los artículos relevantes de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares:

Art.ExigenciaImplementación
8Consentimiento del titular.Flujo de firma tutor → consent_pending.
9Consentimiento expreso para datos sensibles.Segunda firma antes de captura biométrica.
11Calidad y vigencia del dato.Política de retención: descriptor borrado al egresar o al revocar.
22Derechos ARCO.Dashboard tutor con visualización y revocación.
23Medidas de seguridad.AES-GCM-256 + PBKDF2 + reglas por campo.

Cifrado biométrico

public/js/09-facial/biometric-crypto.js aisla toda la criptografía. Nunca salen descriptores en claro de la capa criptográfica.

API

MétodoDescripción
initSchoolKey(schoolId)Deriva la clave maestra por escuela y la cachea en memoria.
encrypt(descriptor)Cifra un descriptor 128-D y devuelve Base64 + IV.
decrypt(blob)Revierte a Float32Array listo para comparar.
rotate(schoolId)Rotación de clave con recifrado en lote.
Importante

La clave maestra nunca se persiste en el cliente. Se deriva de un secreto por escuela guardado en config/crypto, accesible sólo a super-admin.

Build y despliegue

El build de producción usa Vite con un plugin closeBundle personalizado que copia los scripts legados no bundleados.

# build local
npm run build

# preview local del build
npm run preview

# despliegue a Firebase Hosting
npm run deploy

Las reglas Firestore se despliegan por separado:

firebase deploy --only firestore:rules

Scripts NPM

ScriptDescripción
npm run devServidor Vite con hot-reload.
npm run buildBuild de producción en dist/.
npm run build:legacyBuild con el antiguo build.js (respaldo).
npm run previewSirve el build local para verificación.
npm run deployBuild + despliegue a Firebase Hosting.
npm run testSuite Vitest en modo watch.
npm run test:runEjecuta la suite una vez (CI).
npm run test:coverageCobertura con @vitest/coverage-v8.
npm run lintESLint sobre public/js.
npm run lint:fixESLint con --fix.
npm run docsGenera JSDoc a partir de la config del repo.
npm run cleanElimina dist/, coverage/ y test-results/.

Versionado

Semver manual en package.json. Publicación recomendada cada 3–5 cambios o al cerrar una feature.

git add -A
git commit -m "feat: <resumen>"
git tag v3.15.1
git push origin main --tags
gh release create v3.15.1 --generate-notes

Changelog reciente

Últimas versiones publicadas en main (sistema web) y en el repo keyon-terminal.

v3.15.5
Panel admin "Terminales": sidebar → Sistema → Terminales con badge "Pi" cyan. Listener Firestore en tiempo real de la colección terminal_status. Reglas Firestore extendidas para rol admin/superadmin. Auto-refresh 30s.
v3.15.4
Badge "Terminal" cyan en panel admin cuando origen === "terminal_pi". Integración con registros generados por Terminal Pro v2 sobre Raspberry Pi.
v3.15.1
Reglas Firestore extendidas: tutorAutoriza, fechaRevocacion, colección consent_codes habilitada para OTP desde la app móvil.
v3.15.0
Eliminación de facial-encryption-patch.js y consent-mejoras.js. Renombrado de patches a convención .ext-*.js.
v3.14.x
Mejoras UI admin: reportes SEP/DGETI con PDF institucional, módulo de contraseñas con modales Tailwind, indicadores de riesgo.
v3.0.0
Rediseño completo: Vite 5, separación por dominios, descriptor facial cifrado por escuela, flujo de consentimiento doble canal.

Terminal Pro v2 — releases

Repositorio: github.com/santirivera-oss/keyon-terminal

v2.0.4-dev
Systemd auto-start validado post-reboot (49s boot → operativa). Service file con Restart=on-failure, MemoryMax=400M, CPUQuota=90%. Kiosco plug-and-play real.
v2.0.3-dev
Heartbeat a colección terminal_status cada 5 minutos. Monitoreo remoto de temperatura CPU, RAM, disco, uptime, IP, registros del día. Shutdown limpio marca estado: "offline".
v2.0.2-dev
File logging con rotación diaria (TimedRotatingFileHandler, retención 30 días). Error handling resiliente con exponential backoff. Recovery automático tras fallos consecutivos de cámara.
v2.0.1-dev
First functional release. Pipeline completo YuNet + SFace + SQLite + Firestore. Schema compatible con sistema web v3.15.4. Primer registro en producción: Cc5sleYZoGK3J8w39xBo.