Color Ads · LUMO · Arquitectura técnica Rev A.1

Cómo se conecta todo.

Cada dispositivo del robot, su medio de conexión y por qué es el mejor: la propuesta pasó por una revisión adversarial de arquitectura de kioscos 24/7 y aquí está la versión corregida. Incluye el nuevo módulo dispensador de tarjetas, la decisión de comprar (no construir) el reconocimiento de identidad, la nube multi-tenant que administra la flota, y el costo por huésped registrado.

Mapa de conexiones

Un solo cerebro, medios dedicados

El mini-PC industrial es el orquestador; cada periférico usa el medio más confiable para su trabajo, y todo lo que sale a internet pasa por un único router LTE con VLANs y túnel cifrado. El datáfono nunca toca nuestros sistemas: vive en su propia VLAN y habla solo con su adquirente (el kiosco queda fuera de alcance PCI).

Tablet 13” (cabeza) UI + ojos · Android kiosco Cámara RGB-IR reconocimiento + liveness Audio XMOS (AEC) 2 mics + altavoz, eco cancelado Lector MRZ / OCR cédula · PPT · pasaporte Dispensador + encoder CRT-591 · 150 tarjetas Mifare PCB RP2040 motores · LEDs · presencia Datáfono SmartPOS del adquirente · sin cable MINI-PC N100 LINUX · ORQUESTADOR USBGuard · LUKS · watchdog Ethernet (USB-C+PD) · WebSocket USB 3.0 · UVC USB · audio clase UAC USB 2.0 · SDK Linux RS-232 nativo (COM industrial) USB-CDC · comandos alto nivel Router LTE industrial VLANs · WireGuard · SIM+eSIM egreso solo allowlist Ethernet WiFi · VLAN aislada (solo nube del adquirente) Cloudbeds TTLock · TTHotel Identidad (Didit / Truora) WhatsApp API Adquirente Backend Color Ads reservas · folio PIN · eKey · tarjeta UID doc + face + liveness clave · recibo (utility) orden de cobro REST telemetría · panel recepción LTE / WireGuard UPS DC + watchdog corta y restaura si el host muere 12/24V DC · I2C USB Ethernet / RS-232 inalámbrico / nube alimentación
DispositivoMedioProtocoloPor qué es la mejor forma
Tablet (cabeza)Ethernet vía USB-C + PDWebSocket · IPs fijasCable dedicado dentro del chasis: la cara del robot no depende del router ni del WiFi. Modo kiosco (device-owner) con auto-arranque; WiFi solo como respaldo.
Lector MRZ/OCRUSB 2.0SDK del fabricante (Linux x86)Es el único medio soportado por los SDKs; regla udev por serial para nombre estable. El N100 x86 existe justo porque estos SDKs casi no se publican para ARM.
Cámara RGB-IRUSB 3.0UVC estándarDriver nativo del kernel, cero mantenimiento; en controlador USB separado del audio para no competir por ancho de banda isócrono.
Audio (2 mics + altavoz)USBClase UAC · DSP XMOSCancelación de eco (AEC) resuelta en hardware: mics y altavoz comparten reloj en la misma placa. Sin esto, el concierge de voz se oye a sí mismo.
Dispensador + encoderRS-232 nativoProtocolo binario CRTPuerto COM industrial de la placa N100: cero adaptadores USB-serial que se cuelgan o re-enumeran a mitad de la noche.
Motores · LEDs · presenciaUSB-CDCComandos de alto nivelEl tiempo real vive en la PCB (RP2040: rampas, animación, watchdog); Linux solo manda intenciones. PIO del RP2040 ideal para steppers y LEDs, sin radio que asegurar.
Datáfono SmartPOSSin cableSemi-integrado cloudEl mini-PC ordena el cobro por la API del adquirente (Bold API Integrations / Redeban kioscos) y la terminal responde por webhook al backend. El robot jamás ve datos de tarjeta.
Router LTE industrialEthernetVLANs · WireGuard · SIM+eSIMUn solo punto de salida con firewall de egreso por allowlist y gestión remota fuera de banda; el datáfono va en VLAN aislada.
Periféricos USBHub industrialPower-cycling por softwareLa causa #1 de visita técnica en kioscos es un USB colgado: con el hub conmutable se reinicia cualquier dispositivo remotamente, sin enviar a nadie.
UPS DC + watchdog12/24V · I2CHeartbeat de hardwareSi el mini-PC se congela, el watchdog corta y restaura solo. El robot se recupera de casi todo sin un humano.

Lo que cambió tras la revisión adversarial

  • Tablet por cable, no por WiFi: el enlace interno más crítico del robot no puede depender de que el router reinicie.
  • Audio con AEC de hardware (XMOS), no mics al microcontrolador: el eco cancelado exige que mics y altavoz compartan reloj.
  • Terminal de pago desatendida (clase PAX IM30) en vez del A920 de mano: el A920 no está pensado para 24/7 anclado; Redeban tiene programa específico de kioscos.
  • RS-232 nativo de placa industrial en vez de adaptador USB-serial.
  • Modo degradado offline: llegadas del día en caché y PINs TTLock pre-generados — un microcorte de LTE no puede dejar a un huésped en la calle a las 2 a.m.
  • Recuperación remota: hub USB conmutable + watchdog en la UPS = el 90% de las fallas se resuelven sin visita técnica.

LUMO Cloud · plataforma multi-tenant

Una sola nube, cada hotel en su carril

Todo lo de arriba es el fierro de un robot. Esta capa es la que permite que sean cincuenta sin mezclarse: una plataforma serverless (Vercel + Postgres en Neon) donde cada hotel vive aislado y cada kiosco sabe exactamente quién es. El acceso al panel es por enlace mágico de un solo uso — un súper admin (Color Ads) y administradores por hotel, sin contraseñas que perder. Y ya no es una especificación: está corriendo en producción.

Cada hotel, su mundo

Aislamiento por propiedad

Cada propiedad tiene su ficha del concierge — la personalidad y los datos con los que LUMO responde cada pregunta —, su telemetría, su equipo, sus kioscos y su propia conexión con Cloudbeds. Nada se comparte entre hoteles: ni llaves, ni huéspedes, ni métricas.

Cloudbeds sin fricción

Un vault de llaves por hotel

Las credenciales de Cloudbeds viven en un vault por hotel, con renovación coordinada: dos funciones en la nube jamás se pisan los tokens. Para conectar, el panel genera un enlace inteligente de un solo uso (válido 1 hora) que lleva los 20 permisos exactos y aterriza en el hotel correcto: quien administra el Cloudbeds solo entra, elige su propiedad y acepta. Las instalaciones directas desde el Marketplace caen en una bandeja de “conexiones huérfanas” que el súper admin asigna con un clic.

El tipo decide la llave

Hotel · Short rental

Al crear la propiedad se elige su tipo, y la ruta de llave es del tipo, no de la reserva: hotel → tarjeta física, verificada antes de salir del dispensador; short rental → PIN de 6 dígitos gigante en pantalla + respaldo por WhatsApp (nunca canal único). ¿Llave diferida? En hotel te avisamos por WhatsApp y la tarjeta te espera abajo; en short rental el código llega igual, por pantalla y por WhatsApp.

Kioscos con cédula propia

Un kiosco recién encendido no es nadie hasta que se presenta. Y si la base de datos tiene un hipo, el kiosco falla cerrado: prefiere disculparse antes que caer al hotel equivocado.

  1. Se presenta

    La pantalla de emparejamiento muestra un código de 6 dígitos, agrupado y gigante — “107 076” — que expira en 15 minutos y se renueva solo.

    sin apuro
  2. El admin lo reclama

    Desde el panel del hotel se ingresa el código y el kiosco recibe nombre y hogar. Desde ese momento pertenece a esa propiedad y a ninguna otra.

    1 clic
  3. Credencial única

    El kiosco recibe su credencial de dispositivo una sola vez — si dos reclaman a la vez, exactamente uno gana. Desde entonces cada petición viaja identificada.

    atómico
  4. Revocable al instante

    ¿Kiosco retirado o sospechoso? Un clic en el panel y vuelve a la pantalla de emparejamiento, sin llaves viejas dando vueltas.

    segundos

El mismo motor en todas partes — y se puede tocar

  • Una sola máquina de estados: cada paso queda escrito antes de ejecutarse, el pago corre en paralelo, el carril ámbar recoge los casos raros y los guards de llave son simétricos — sin tarjeta verificada no hay entrega, sin código generado no hay envío (20/20 pruebas en verde). Corre idéntica en las funciones serverless de la nube — las mismas que atienden al kiosco — y en el simulador público del navegador: una única copia canónica.
  • No es un diagrama, está corriendo: el kiosco demo contra el sandbox real de Cloudbeds, el simulador con interruptor Hotel / Short rental para ver ambas rutas de llave, y la telemetría abierta. Check-in de punta a punta medido en 59 segundos.
  • Aislamiento verificado en vivo: un hotel aún sin conexión recibe un ámbar amable (“este kiosco aún no está conectado al sistema del hotel”) — jamás los datos de otra propiedad.

Prototipo de conexión · lectura de documento

Del documento apoyado a la identidad verificada

Así viaja el dato: el lector entrega la lectura cruda, el mini-PC orquesta, la nube de identidad decide, y la tablet solo muestra. Ningún documento se almacena en el kiosco (disco cifrado, PII solo en tránsito). Y cuando la identidad dice que sí, el tipo de propiedad decide cómo sigue la historia: en hotel, tarjeta del dispensador; en short rental, PIN en pantalla.

  1. Documento apoyado

    El lector MRZ/OCR detecta el documento y emite MRZ + PDF417 de la cédula por USB (SDK Linux).

    ~1 s
  2. Parseo local

    El mini-PC valida checksums del MRZ, extrae nombre/documento y los cruza con la reserva de Cloudbeds.

    <1 s
  3. Selfie + liveness

    La cámara RGB-IR captura el rostro; LUMO auto-encuadra con el cuello (tilt) y guía con los ojos.

    2–3 s
  4. Verificación en nube

    Doc + selfie van a la API de identidad (Didit / Truora): autenticidad, face match y liveness.

    2–5 s
  5. Resultado a la cara

    El webhook llega al mini-PC (vía backend + WireGuard) y la tablet celebra o pide reintento.

    <1 s
  6. Registro

    Check-in marcado en Cloudbeds; datos del huésped listos para el reporte SIRE/TRA de Migración.

    async

Línea hotelera · LUMO Card

Dispensador de tarjetas con encoder

LUMO vive en dos mundos: en short rentals la llave es digital (PIN/eKey TTLock, cero hardware extra); en hoteles la llave es la tarjeta física — y esa línea es este módulo: un dispensador motorizado con encoder RFID integrado, montado en la base (la base sube de 9 a 17 cm de alto y la boca de entrega queda iluminada en naranja al frente). Recarga por la puerta trasera de servicio, alarma de nivel bajo en el panel de recepción, y bin interno para tarjetas rechazadas. En LUMO Cloud esa división ya es una decisión de configuración: al crear la propiedad se elige su tipo, y este dispensador es la ruta “hotel” — el PIN gigante en pantalla, la ruta “short rental”.

MóduloTipoInterfazCapacidadUSDNota
Creator CRT-591-MDispensador + encoder MifareRS-232150481 – 582El estándar de facto en kioscos; precio real Alibaba; dispensa, captura y rechaza a bin interno.
Familia K750 / MTK F39V2Circulante (recicla)RS-232100–200 + tanque250 – 800La mejor arquitectura para hotel: al check-out la tarjeta vuelve al circuito sola.
TTCE-K720Dispensador + encoderRS-232/TTL150–400120 – 300La opción económica de parking; sin reciclaje.
Nidec Sankyo SCTGrado casino/bancaRS-232/USBsegún config800 – 1.500Fiabilidad premium; se justifica en flota 24/7 grande.
Encoder de mostrador (TTHotel E-4 / ZKTeco D147-H)Solo codificaUSBbandeja40 – 140MVP: codifica y el robot indica tomar la tarjeta de la bandeja.

Delta al BOM de serie: módulo recomendado (CRT-591-M + fuente 24 V + montaje y boca) ≈ +USD 550–700 por unidad como opción "hotel de tarjeta"; MVP con encoder de mostrador +USD 140–200.

La tarjeta solo abre si la cerradura coopera

El encoder del dispensador escribe Mifare, pero cada marca de cerradura cifra sus tarjetas con claves propias. El semáforo honesto por ecosistema:

EcosistemaViabilidadCómo se integra
TTLock / TTHotelABIERTOAPI cloud + SDK. Truco fino: el propio CRT-591 lee el UID de la tarjeta y la API la activa en la cerradura vía gateway — sin escribir sectores propietarios. O encoder E-4 (€129) para modo clásico.
ZKTeco (ZKBiolock)ABIERTOSDK gratuito + su encoder USB D147-H (~USD 40–80) dentro del kiosco; documentan integración con máquinas de self check-in.
OnityVÍA DEALERSin SDK público: interfaz PMS por TCP/IP + encoder Onity comprado al dealer, montado dentro del kiosco.
SaltoLICENCIAProtocolo SHIP sobre ProAccess SPACE: licencia de pago + NDA + encoder Ethernet Salto dado de alta como kiosco.
dormakaba (Saflok/Ilco)CERRADOSolo programa de partners certificados; no viable sin acuerdo comercial.

Lectura comercial: dos líneas en paralelo — LUMO Rental (TTLock, llave digital, sin partes móviles extra) y LUMO Hotel (dispensador + encoder de tarjeta). Los ecosistemas abiertos (TTLock modo hotel, ZKTeco) se integran sin pedir permiso a nadie; las marcas legacy se abordan hotel por hotel vía su dealer.

Build vs. buy · reconocimiento de identidad

Comprar por API, no construir

La verificación (OCR del documento + face match + prueba de vida) se compra por consulta. Comparamos el mercado con precios verificados en agosto 2026:

ProveedorPrecio por verificaciónCédula · PPTNota
Didit RECOMENDADO500 gratis/mes · luego 0,33Sí · PPT a validarÚnico con pricing 100% público; sin mínimos ni contrato; liveness certificado iBeta; integración en horas. Un edificio típico opera en USD 0/mes.
Truora PLAN B / SIRE~0,30 – 1,00 (cotización)Sí · PPT y PEP explícitosLa colombiana: además cruza contra Registraduría. Clave si el hotel exige anti-fraude fuerte o población migrante. Cotizar en paralelo al piloto.
Veriff0,80 + mín. USD 49/mesSólido pero caro: ~USD 400/mes a 500 check-ins.
Sumsub1,35 + mín. USD 149/mesSu valor es AML/compliance financiero que un hotel no necesita.
Metamapopaco · mín. ~USD 1.167/mesAdquirida por Incode (2024); pricing por contrato. Descartada a esta escala.
Regula (licencia SDK)~10–30 mil USD/añoSí (incl. PDF417)Forense on-premise excelente; solo tiene sentido multi-edificio con requisito de datos en sitio.
AWS Rekognition (semi-DIY)0,02 – 0,05 en APIsOCR propio (no soporta cédula)La trampa: ahorro máx. ~USD 165/mes a cambio de 3–6 semanas de desarrollo, sin autenticidad de documento y todo el Habeas Data encima.

Decisión: arrancar con Didit, cotizar Truora en paralelo

  • Fase piloto: Didit embebido en la tablet (hosted flow) — USD 0 hasta 500 verificaciones/mes por edificio, sandbox público, sin hablar con ventas.
  • Escala / valor agregado: Truora suma el cruce contra Registraduría y soporte explícito de PPT — el argumento perfecto para hoteles con reporte SIRE/TRA exigente.
  • Nunca construir el reconocimiento propio: el ahorro no paga ni el primer mes de desarrollo, y la responsabilidad de datos biométricos queda en el proveedor certificado.

Costeo por usuario registrado

La tecnología cuesta centavos por huésped

Todo el stack (verificación de identidad, mensajes, IA, cerraduras, PMS) costeado por check-in y por kiosco al mes. TRM ~3.180.

ConceptoModalidadUSDNota
Verificación de identidad (Didit)por check-in0,00 – 0,33USD 0 hasta 500/mes por edificio; 0,33 el excedente. Con Truora cotizado: ~0,30–1,00.
WhatsApp Business API (Meta directo)por check-in0,002 – 0,0032–4 mensajes utility a USD 0,0008 c/u — la tarifa más baja del mundo; gratis si el huésped escribe primero.
Concierge IA (Claude Haiku)por check-in0,005 – 0,010USD 0,015–0,030 por conversación; ~1 de cada 3 huéspedes conversa. El check-in puro no consume IA.
TTLock / TTHotel (clave o tarjeta)por check-in0API cloud gratuita con el hardware.
Cloudbeds APIpor check-in0Incluida en el PMS que el hotel ya paga (verificar acceso API por plan).
Variable por huéspedpor check-in0,01 – 0,35≈ COP 30 – 1.100 por huésped registrado.
SIM de datos (respaldo LTE)mensual por kiosco8 – 13COP 25–40 mil (3–10 GB, operador local); WiFi del hotel como enlace principal.
Backend + hosting + panelmensual por kiosco2 – 5Vercel Pro + base de datos gestionada para TODO el sistema, prorrateado a 10+ kioscos.
Fijo por kioscomensual10 – 18≈ COP 32 – 57 mil al mes.

Edificio típico

300 check-ins/mes

USD 13 – 25 / mes≈ COP 41 – 80 mil · identidad en franja gratis de Didit

Edificio grande

800 check-ins/mes

USD 115 – 130 / mes≈ COP 365 – 415 mil · 300 verificaciones pagas a 0,33

El punto de la viabilidad

vs. recepción nocturna

< 1% – 4%del costo de una recepcionista (COP 2,5–3,5 M/mes) — el resto es margen del SaaS

Informativo: la comisión del adquirente por cobro con tarjeta (2,5–3,5% + ~COP 300 + IVA) la paga el hotel en cada transacción, como con cualquier datáfono — no es costo del stack LUMO.