De un problema real en una estación de empaque a una plataforma de trazabilidad visual

1. La búsqueda de una solución que ya existiera
2. El camino de Hikvision que no pudimos utilizar
3. Las conversaciones que ayudaron a construir la lógica
4.  El descubrimiento técnico central 
5.  El primer laboratorio 
6.  La primera demostración al cliente 
7.  La primera implementación real 
8.  De una estación a toda la operación 
9.  Los problemas de infraestructura 
10.  La migración de Hikvision a Uniview 
11.  El nacimiento de Sentria Agent 
12.  El apagón que puso a prueba el sistema 
13.  El error entre las estaciones 12 y 13 
14.  La estabilización 
15.  Cómo funciona Sentria hoy 
16.  Qué problemas ayuda a resolver 
17.  Lo que diferencia a Sentria 
18.  Para qué empresas está diseñado 
19.  Qué necesita una empresa para implementarlo 
20.  El futuro de Sentria
21. Conclusion
    

Entre la poca información disponible sobre este tipo de soluciones encontramos una propuesta de Hikvision orientada al seguimiento de paquetes.

La lógica era similar a lo que necesitábamos: un escáner registraba el código, una cámara grababa la operación, un servidor relacionaba el escaneo con el momento exacto y posteriormente se podía buscar el código y recuperar la grabación correspondiente.

Nos pareció que ya no era necesario inventar nada. Si la herramienta existía y contábamos con el respaldo del fabricante, podíamos instalarla, probarla y ofrecerla al cliente.

Contactamos a Hikvision y pedimos acceso a una licencia temporal o una demostración. Nuestra intención era montar una estación de prueba dentro de nuestra oficina, comprender el sistema antes de ofrecerlo y enviarle al cliente una demostración real de que funcionaba.

Después de varios correos, no logramos acceso a una demostración bajo nuestras condiciones de prueba.

No decidimos inmediatamente desarrollar un producto comercial. Establecimos una condición mucho más sencilla:

«Si teníamos tiempo y recursos disponibles, intentaríamos construir una pequeña demostración. Si funcionaba, se la presentaríamos al cliente. Si no funcionaba, abandonaríamos la idea sin seguir consumiendo recursos.»

Antes de escribir el sistema, hablé con personas cercanas que conocían distintas áreas de la tecnología.

Una de las conversaciones más importantes fue con José Serpa, quien tenía experiencia con sistemas de cámaras. Le expliqué el problema, la solución que habíamos encontrado en Hikvision y las limitaciones. También le pregunté si conocía otra marca o herramienta que pudiera resolver algo similar.

No encontramos ninguna alternativa cercana.

Entonces dejamos de hablar de marcas y comenzamos a hablar de cómo funcionaban realmente las cámaras, los NVR y los activadores. José propuso la posibilidad de conectar un pulsador o una señal que se activara en el momento del escaneo. Ese pulso podría indicar a la cámara o al sistema que en ese instante estaba ocurriendo un evento que debía registrarse.

La idea me pareció brillante porque ayudaba a entender el elemento que faltaba: el sistema necesitaba una marca que señalara el momento exacto.

También hablé con mi amigo Jesús Martínez, quien en ese momento trabajaba en California, dentro del entorno tecnológico de Silicon Valley. Le presenté la idea y le pregunté si conocía una aplicación, una empresa o algún desarrollador que hubiera trabajado con algo parecido. Jesús estaba relacionado con proyectos de entregas mediante drones e inteligencia artificial, pero no conocía una solución cercana a lo que buscábamos.

Estas conversaciones no produjeron un producto terminado, pero ayudaron a construir la lógica. Empecé a unir tres piezas: la necesidad real del cliente, la estructura que habíamos observado en la solución de Hikvision, y la idea de utilizar el escaneo como el evento que marcara el momento exacto dentro del video.

La primera idea era activar físicamente una cámara en el momento del escaneo.

Sin embargo, mientras estudiábamos el funcionamiento de los NVR entendimos que no necesitábamos encender o comenzar a grabar una cámara cada vez que alguien escaneaba un paquete.

La cámara podía grabar continuamente. Lo que necesitábamos era registrar con precisión el código escaneado, la estación donde ocurrió, la fecha, la hora exacta y la cámara correspondiente a esa estación. Con esa información podíamos solicitar al NVR el fragmento de video que correspondiera a ese momento.

El escaneo no tenía que activar la grabación. El escaneo podía convertirse en una marca temporal dentro de una grabación que ya existía.

Ese fue uno de los descubrimientos que definió Sentria.

«La cámara documentaba lo ocurrido. El escáner identificaba el producto. Sentria debía construir el puente entre ambos.»

Durante un período en el que teníamos menor carga de trabajo, me enfoqué personalmente en estudiar cómo podíamos construir la demostración.

Investigamos cómo comunicarnos con las cámaras y el NVR, cómo consultar las grabaciones y cómo extraer solamente el fragmento necesario.

Creamos una arquitectura básica: un programa cliente instalado en la estación, un servidor central, una base de datos, un registro por cada código escaneado, una relación entre estación, cámara, fecha y hora, un buscador y un proceso para generar el video correspondiente.

La primera versión se desarrolló principalmente con Python, Flask, HTML, SQLite y FFmpeg, con comunicación con el NVR y procesamiento de video mediante RTSP y HLS.

En ese momento no existía una gran interfaz. Gran parte de las pruebas se realizaba observando directamente la consola y los resultados del código. Veíamos qué dato llegaba, en qué momento llegaba, cuál era la latencia, qué formato de hora utilizaba el NVR, qué canal correspondía a cada cámara, si el fragmento empezaba demasiado temprano o demasiado tarde, y si el video recuperado coincidía realmente con el escaneo.

También descubrimos que cada fabricante podía manejar de manera distinta la comunicación, los horarios y la consulta de las grabaciones. Nuestro conocimiento previo sobre cámaras y videovigilancia fue fundamental para comprender esas diferencias.

Antes de instalar nada en la operación del cliente, construimos dentro de nuestra oficina una pequeña estación de empaque. Instalamos una cámara, un escáner, una mesa de trabajo, una computadora cliente, un NVR, un servidor de prueba, y productos y etiquetas para simular paquetes.

No estábamos probando solamente código. Estábamos reconstruyendo físicamente el proceso del cliente para entender cómo se comportaría el sistema dentro de una estación real.

El video del laboratorio documenta que para el 2 de octubre de 2025 ya teníamos un flujo funcional: se escaneaba un código, el sistema registraba el código, la estación y la hora, el servidor consultaba el NVR, se generaba el fragmento de video, y el usuario podía reproducir la evidencia asociada.

Solo después de comprobar que la lógica funcionaba comenzamos a construir una interfaz más fácil de utilizar.

Cuando tuvimos un resultado que consideramos suficientemente estable, volvimos a hablar con el cliente.

No le presentamos una idea abstracta. Le mostramos el sistema funcionando. Le enviamos un video donde podía observar cómo se escaneaba un código, cómo aparecía en el buscador y cómo se recuperaba el momento exacto del empaque.

La respuesta fue directa:

«Eso es lo que quiero. Me gusta. Vamos a hacerlo.»

El cliente pidió instalar una primera demostración dentro de una estación real y comprobar cómo se comportaba en producción. En ese momento comenzó a correr el reloj. Ya no se trataba solamente de una investigación interna: habíamos hecho una promesa de entrega.

Planteamos un precio para la demostración con una condición favorable para el cliente: si el piloto funcionaba y el proyecto completo era aprobado, el valor pagado por la prueba sería descontado del proyecto final.

Esto también fue importante para Team Gears. La demostración comenzó a generar los recursos necesarios para mantener el desarrollo activo. En lugar de financiar indefinidamente el proyecto con recursos generales de la empresa, Sentria comenzó a sostener parte de su propia evolución.

El primer piloto se instaló en una de las estaciones con mayor flujo de trabajo.

Para el servidor utilizamos una mini PC porque el código era ligero y no necesitaba inicialmente una infraestructura excesivamente grande. Esa experiencia dio origen al concepto que posteriormente llamamos Sentria Box: un equipo compacto con capacidad suficiente para procesar los registros y coordinar la comunicación sin introducir retrasos significativos.

La primera instalación utilizaba un servidor pequeño, un NVR Hikvision de aproximadamente 4 TB, una cámara Hikvision, un escáner, una computadora de estación, el cliente de Sentria, el servidor de Sentria y acceso remoto para supervisión.

El sistema comenzó a funcionar y a producir resultados. Sin embargo, también comenzó a mostrarnos todo lo que el laboratorio no podía enseñarnos.

En la operación real había diferentes sesiones de usuario, programas que podían cerrarse, procesos que no permanecían activos en segundo plano, equipos utilizados simultáneamente para otras tareas, cambios de red, reinicios, interrupciones y comportamientos de Windows que no aparecían en nuestra oficina.

Tuvimos varias caídas iniciales. En ocasiones, la consola se cerraba. Otras veces, algún programa o proceso detenía el cliente. Algunas estaciones dejaban de comunicarse con el servidor. Cada problema nos obligaba a revisar, corregir y volver a probar.

La primera demostración permaneció aproximadamente seis meses, o incluso un poco más, dentro de la operación activa. Durante ese período monitoreábamos constantemente que los escaneos llegaran, que la base de datos tuviera los registros, que el video correspondiera al código, que el servidor continuara activo, que la estación siguiera comunicándose y que no hubiera retrasos o pérdidas.

También realizábamos verificaciones aleatorias: buscábamos códigos procesados y comprobábamos que el sistema devolviera el video correcto. Después de las correcciones iniciales, el piloto comenzó a trabajar de manera estable. Llegó un momento en que pudimos dejarlo operando prácticamente solo.

Después de comprobar los resultados, el cliente tomó una decisión: quería Sentria en todas sus estaciones. La solicitud pasó de una sola prueba a una instalación de aproximadamente 12 estaciones. También surgió el interés de replicar la solución en futuras operaciones en New Jersey y Texas.

Ese fue el momento en que Sentria dejó de ser solamente una solución particular para una computadora. Ahora tenía que convertirse en una infraestructura completa.

Era necesario diseñar el cableado estructurado, las cámaras, la posición de cada cámara, los puertos de red, los canales del NVR, el servidor, el almacenamiento, el UPS, el rack, la identificación de cada estación, la administración remota y la posibilidad de crecer hacia otras ubicaciones.

La estructura física de las estaciones imponía restricciones importantes. La distancia entre el área superior y la mesa de empaque era reducida. Una cámara demasiado grande podía interferir con el operador o perder partes importantes de la operación. Por eso buscamos cámaras compactas y delgadas que pudieran instalarse dentro de la estructura de cada estación y mostrar con claridad el paquete, las manos del operador, el producto, la etiqueta, el proceso de cierre y el área donde ocurrían los movimientos relevantes.

Realizamos el cableado para las cámaras IP, terminamos conexiones RJ45 y organizamos cada recorrido. Cada elemento tenía que quedar identificado: estación, cámara, cable, puerto, panel, canal del NVR, dirección de red y computadora asociada.

Esa identificación no era un detalle estético. Si una estación se relacionaba con el canal equivocado, el código podía recuperar un video correcto técnicamente, pero perteneciente a otra mesa.

La instalación física también produjo problemas que no tenían relación directa con el software. Uno de ellos fue el rack.

Habíamos preparado el servidor, el NVR y el UPS, pero cuando intentamos instalar el servidor descubrimos que el rack no tenía suficiente profundidad. Las fotografías documentan que el espacio disponible era de aproximadamente 16 pulgadas, mientras que el equipo necesitaba cerca de 20 pulgadas o más, además del espacio requerido para conectores y ventilación.

El servidor simplemente no cabía. Tuvimos que detener la instalación, medir nuevamente, adquirir un rack más profundo y reorganizar la infraestructura. Eso generó retrasos.

Fue una enseñanza sencilla pero importante:

«Una solución puede funcionar perfectamente en software y detenerse por unas pulgadas de diferencia en un gabinete.»

Mientras resolvíamos cámaras, servidores, cableado y racks, también enfrentábamos presión, viajes, imprevistos y responsabilidades fuera del código. Hubo incluso momentos en los que tuve que continuar revisando o actualizando la implementación desde un aeropuerto en Carolina del Norte.

Sentria no se desarrolló únicamente desde un escritorio. Se desarrolló desde la oficina, la planta, las estaciones, una plataforma elevadora, viajes y conexiones remotas en momentos en los que la operación necesitaba seguir avanzando.

La primera versión se había desarrollado alrededor del comportamiento de Hikvision. Sin embargo, para la instalación completa utilizamos cámaras y un NVR Uniview.

En teoría, ambas marcas resolvían funciones similares. En la práctica, sus protocolos, formatos y métodos de comunicación eran diferentes. Cuando comenzamos la implementación descubrimos que el código no podía comunicarse con Uniview exactamente de la misma forma que lo hacía con Hikvision.

Tuvimos que estudiar cómo entregaba Uniview las grabaciones, cómo manejaba las fechas y horarios, cómo identificaba los canales, cómo respondía a las solicitudes, cómo extraer el fragmento correcto y cómo adaptar el procesamiento sin introducir retrasos.

La migración tomó tiempo, pero finalmente logramos que Sentria funcionara con Uniview sin una pérdida apreciable de precisión ni una latencia que afectara la operación.

Esto también cambió la forma en que veíamos el producto. Sentria no debía estar atado para siempre a una sola marca. Debía contar con una estructura suficientemente flexible para adaptarse a distintas plataformas de video, siempre que cumplieran con los requisitos técnicos necesarios.

Después de instalar varias estaciones, apareció otro problema. Algunas computadoras dejaban de estar en línea. En ocasiones el cliente de Sentria se cerraba o algún proceso externo parecía detenerlo. El operador podía continuar utilizando la computadora sin darse cuenta de que Sentria había dejado de comunicarse con el servidor.

Inicialmente teníamos que entrar remotamente en las estaciones y revisar cada una manualmente. Eso no era sostenible.

Como respuesta creamos Sentria Agent. El agente se instaló en las estaciones para reportar si el servidor estaba disponible, si el proceso de Sentria estaba activo, si la estación estaba comunicándose, si existían registros pendientes, qué versión estaba instalada y cuándo se había producido la última comunicación.

Posteriormente agregamos herramientas para reiniciar componentes, reinstalar tareas, actualizar el cliente, instalar módulos, ejecutar escaneos de prueba, actualizar el agente y aplicar acciones sobre una estación o sobre todas.

Sentria comenzó a pasar de una herramienta que registraba eventos a una plataforma que también podía vigilar su propio funcionamiento.

«Ya no dependíamos exclusivamente de que una persona descubriera una falla. El sistema podía informarnos que una estación había dejado de responder.»

Mientras estábamos investigando por qué algunas estaciones se desconectaban, ocurrió un apagón general en la planta. Sentria generó múltiples alertas porque casi todas las estaciones dejaron de responder.

Contactamos al responsable de la operación y preguntamos si había ocurrido algo con la red o con la electricidad. La respuesta fue clara: había ocurrido un apagón general.

Después de restablecerse la energía apareció un segundo problema. Varias computadoras y el servidor cambiaron de dirección IP. Esto interrumpió la comunicación entre algunos componentes. Intentamos restablecer el sistema remotamente durante el fin de semana, pero muchas estaciones no estaban accesibles porque no había usuarios trabajando en ellas.

Cuando recuperamos el acceso, corregimos la comunicación y las estaciones comenzaron a enviar los registros que habían quedado pendientes. La pérdida estimada fue mínima o nula.

Ese evento demostró el valor de conservar una cola local de registros. Aunque una estación perdiera temporalmente la conexión, no todo tenía que desaparecer. Los datos podían permanecer pendientes y sincronizarse cuando la comunicación regresara.

«Una interrupción dejó de significar automáticamente una pérdida definitiva de evidencia.»

Durante esa misma etapa se reportó que algunos códigos asociados a la estación 12 mostraban video de la estación 13. En otros casos, el usuario veía una estación vacía cuando esperaba observar actividad.

Inicialmente podía parecer un error en la búsqueda o en la extracción del video. Después de revisar la configuración descubrimos la causa: las estaciones 12 y 13 habían quedado invertidas durante la instalación. Era un error humano de secuencia. Sentria estaba consultando el canal que tenía configurado, pero ese canal se había relacionado con la estación equivocada.

Corregimos la configuración y realizamos pruebas con códigos específicos. Cada registro volvió a mostrar el video correspondiente. También ofrecimos revisar y recuperar, en la medida de lo posible, los datos históricos relacionados con el período afectado.

Este incidente reforzó una regla importante de implementación:

«La estación física, la computadora, el cable, el puerto, la cámara, el canal del NVR y la configuración lógica deben representar exactamente la misma secuencia.»

No basta con instalar correctamente el software. La trazabilidad depende de que toda la cadena esté correctamente identificada.

Después del apagón, la corrección de las direcciones, la sincronización de registros y la reparación de las estaciones 12 y 13, continuamos monitoreando la operación.

Al cierre de esta recopilación, Team Gears no había recibido nuevos reportes ni alarmas relacionadas con fallos del sistema después de aquellas correcciones. Las estaciones estaban trabajando de manera estable. Cada registro se relacionaba con el video correspondiente sin contratiempos reportados.

La captura del panel del 29 de julio de 2026 documenta 302.877 escaneos registrados, 12 estaciones activas, 1 ubicación, 9 usuarios activos, todas las estaciones reportando estado operativo, procesos activos, comunicación correcta con el servidor y cero registros pendientes en las colas mostradas.

Estos números no representan una demostración. Representan una herramienta trabajando dentro de una operación real.

Sentria conecta la acción física de escanear un código con la evidencia visual de una operación.

Un operador prepara un paquete en una estación. Durante el proceso, escanea el código correspondiente. El cliente de Sentria registra el código, la estación, la fecha, la hora exacta y la información necesaria para identificar la cámara. El servidor recibe y conserva el registro.

Cuando un usuario autorizado busca el código, Sentria consulta la grabación correspondiente y genera un fragmento que incluye el momento de la operación. El usuario puede entonces buscar por código, filtrar por fecha, filtrar por estación, reproducir el video, descargar la evidencia, compartirla mediante un acceso seguro, consultar registros desde una interfaz web, trabajar con usuarios y permisos, revisar el estado de las estaciones y diagnosticar interrupciones.

La arquitectura conserva el servidor principal dentro de la operación del cliente, lo que permite trabajar localmente y mantener control sobre el video y los registros. Al mismo tiempo, el acceso web seguro permite consultar la información sin exponer directamente toda la red interna.

Sentria no reemplaza la grabación de las cámaras. Tampoco reemplaza el sistema operativo del cliente. Sentria actúa como la capa que une el evento, el código, la estación, el tiempo, la cámara, el video y la evidencia.

Sentria fue creado inicialmente para investigar reclamaciones en operaciones de fulfillment, pero el problema que resuelve aparece en muchas industrias.

Algunos casos: un cliente afirma que faltaba un producto dentro del paquete; el artículo recibido no corresponde con el pedido; una etiqueta fue colocada en la caja equivocada; un operador escaneó un código diferente; el paquete salió correctamente, pero la reclamación ocurrió después; la empresa necesita demostrar cómo fue preparado un envío; la supervisión quiere investigar un error humano; es necesario verificar en qué estación se procesó una operación; se necesita localizar evidencia sin revisar horas completas de grabación; una estación dejó de reportar y es necesario determinar qué registros quedaron pendientes.

El sistema no beneficia únicamente a la empresa. También puede proteger al cliente y al empleado. La evidencia puede demostrar que una reclamación es válida y que ocurrió un error durante el empaque. Pero también puede demostrar que el empleado realizó correctamente el proceso y que el producto sí fue colocado dentro del paquete.

Sentria no está diseñado únicamente para negar reclamaciones. Está diseñado para ayudar a reconstruir lo que realmente ocurrió.

Sentria no comenzó como un software genérico al que después intentamos encontrarle un cliente. Comenzó dentro de una operación real.

Cada función nació de un problema observado. El buscador nació porque revisar grabaciones manualmente era demasiado lento. La relación por estación nació porque cada mesa tenía una cámara distinta. La extracción de video nació porque el cliente no necesitaba descargar horas completas. Sentria Agent nació porque algunas estaciones dejaban de responder. Las alertas nacieron porque era necesario detectar las caídas antes de perder información. Las colas pendientes nacieron porque una desconexión no debía eliminar los registros. El acceso seguro nació porque el sistema no podía quedar limitado a una dirección IP local. La compatibilidad con Uniview nació porque la infraestructura real no utilizó la misma marca del laboratorio. La identificación meticulosa nació después de entender el impacto de invertir dos estaciones.

«Sentria evolucionó a través de los problemas reales que encontró mientras estaba trabajando.»

Esa es una de sus diferencias principales. No fue construido solamente para funcionar en condiciones ideales. Fue construido mientras enfrentaba apagones, cambios de IP, cierres de procesos, sesiones de Windows, errores humanos, diferencias entre fabricantes, limitaciones físicas, racks incorrectos, estaciones activas y operaciones que no podían detenerse indefinidamente.

Sentria puede aportar valor en operaciones donde exista una acción física que pueda identificarse mediante un código y que necesite evidencia visual: fulfillment, logística, almacenes, centros de distribución, reempaque, preparación de pedidos, devoluciones, clasificación de mercancía, control de calidad, manufactura ligera, recepción y despacho, y procesamiento de activos identificados por código.

No todas las empresas necesitan Sentria. Está especialmente diseñado para operaciones donde existen muchas transacciones, donde las reclamaciones tienen un costo significativo, donde la búsqueda manual de video consume demasiado tiempo, donde es necesario verificar qué ocurrió con un artículo específico, y donde la trazabilidad tradicional no muestra cómo se ejecutó físicamente la operación.

La implementación depende de la operación, pero normalmente requiere una estación o punto de trabajo definido, un código que identifique la operación, un escáner, una computadora por estación o un equipo compatible, cámaras correctamente ubicadas, red cableada estable, NVR compatible, almacenamiento suficiente, servidor local o infraestructura aprobada, identificación exacta de estaciones y canales, usuarios y permisos, acceso de soporte, y políticas de retención y seguridad.

La cámara debe mostrar claramente el área relevante. No basta con colocar una cámara general en el techo. El ángulo, la distancia, la iluminación y la posición deben permitir distinguir lo que realmente ocurre durante el proceso.

La cantidad de almacenamiento dependerá del número de cámaras, la resolución, los cuadros por segundo, la compresión, si la grabación es continua o por movimiento, y el tiempo de retención requerido.

Sentria comenzó resolviendo una necesidad específica en una ubicación. Pero desde el inicio de la expansión el cliente planteó la posibilidad de utilizarlo en otras operaciones.

La visión del producto incluye múltiples ubicaciones, administración centralizada, más estaciones, diferentes fabricantes de cámaras y NVR, alertas más avanzadas, reportes, auditoría, herramientas para compartir evidencia de forma controlada, integraciones con otras plataformas, APIs, monitoreo de salud, gestión de usuarios y roles, mejor diagnóstico remoto, automatización de recuperación y mayor facilidad de implementación mediante Sentria Box.

La meta no es convertir Sentria en una plataforma llena de funciones que nadie utiliza. La meta es mantener la misma lógica que dio origen al proyecto:

«Observar un problema real, comprenderlo, construir una solución útil y comprobarla dentro de la operación.»

Sentria comenzó con una cámara Wi-Fi instalada de lado en una estación de empaque. La cámara grababa, pero encontrar la evidencia era demasiado complicado.

Buscamos soluciones en el mercado y encontramos opciones técnicamente capaces, pero económicamente difíciles de justificar. Intentamos trabajar con una solución existente de Hikvision, pero no pudimos conseguir la demostración. Entonces decidimos probar si podíamos construir nuestra propia alternativa.

Conversamos con personas de confianza, estudiamos el funcionamiento de las cámaras y los NVR, construimos un laboratorio, escribimos la primera versión, la probamos, cometimos errores y la llevamos a producción.

La primera demostración se convirtió en una estación. La estación se convirtió en doce. La prueba se convirtió en una plataforma con servidor, agentes, alertas, usuarios, acceso seguro y más de 300.000 registros.

Durante el proceso tuvimos caídas, cambios de protocolo, problemas de red, un rack demasiado pequeño, estaciones invertidas, un apagón, registros pendientes y actualizaciones hechas desde viajes. No ocultamos esos problemas porque son parte de lo que construyó la solución.

Sentria no llegó a su estado actual porque todo funcionó correctamente desde el primer día. Llegó porque cada problema fue observado, diagnosticado y convertido en una mejora.

«Sentria nació cuando entendimos que grabar una operación no era suficiente. Había que convertir esa grabación en evidencia que pudiera encontrarse, comprenderse y utilizarse cuando realmente hiciera falta.»

Ver Demo de Sentria

¿Tu operación empaca y escanea? El demo está abierto.