Saltar al contenido
alarmasmonitoreo

Cómo conectar paneles DSC y Paradox a la nube

Aprende a conectar paneles DSC y Paradox a una plataforma de monitoreo en la nube: comunicadores IP/GPRS, formatos de eventos, connector y errores comunes.

Equipo Treinco

Conectar paneles DSC y Paradox a la nube es hoy uno de los proyectos más rentables para una empresa de monitoreo: te permite recibir eventos por IP o celular, ofrecer una app al usuario final y operar tu central desde cualquier lugar, sin abandonar el parque de paneles que ya tienes instalado. La buena noticia es que no necesitas reemplazar equipos: DSC y Paradox llevan años fabricando comunicadores que hablan protocolos estándar. En esta guía te explicamos las piezas involucradas, las dos rutas de conexión posibles y los errores más comunes al hacerlo.

Por qué llevar tus paneles a la nube

El esquema tradicional —panel que marca por línea telefónica a un receptor en tu central— funciona, pero tiene límites claros: las líneas telefónicas están desapareciendo, la supervisión del enlace es pobre (te enteras de que un panel dejó de comunicar cuando falta su prueba periódica) y toda tu operación depende de un solo sitio físico.

Al pasar los eventos a una plataforma en la nube ganas:

  • Supervisión en tiempo casi real del estado de comunicación de cada panel.
  • Doble vía (IP + celular) sin hardware adicional en tu central.
  • Operación distribuida: tus operadores ven los mismos eventos desde cualquier sitio.
  • Servicios de valor agregado: app para el abonado, notificaciones, historial consultable.

El punto de partida: el comunicador

El panel por sí solo no “sale a internet”. Necesita un comunicador, que puede venir integrado o agregarse como módulo.

Comunicadores IP

Se conectan al puerto Ethernet del sitio y envían los eventos por la conexión a internet del cliente. En la línea DSC, los comunicadores de las series TL (por ejemplo, los usados con paneles PowerSeries y PowerSeries Neo) cumplen este rol; en Paradox, el módulo IP150 es el más conocido. Son la opción más económica de operar (no requieren SIM), pero dependen del router y la energía del sitio.

Comunicadores GPRS/LTE

Usan una SIM celular para reportar. En DSC existen variantes celulares y duales de la misma familia de comunicadores; en Paradox, los módulos de la serie PCS. Su gran ventaja es la independencia: siguen comunicando aunque corten el internet del sitio o el sabotaje afecte el cableado de red.

La configuración recomendada para cuentas de monitoreo serias es la dual: IP como vía principal y celular como respaldo. El comunicador conmuta solo cuando la vía principal falla.

Formatos de eventos: qué “habla” tu panel

Independientemente del medio (IP o celular), el contenido del mensaje sigue un formato estándar:

  • Contact ID: el más universal. Cada evento incluye número de cuenta, código de evento (130 robo, 110 fuego, 401 apertura/cierre, etc.), partición y zona. Tanto DSC como Paradox lo soportan en toda su línea.
  • SIA: formato alternativo con códigos alfabéticos (BA para alarma de robo, OP para apertura). Disponible en buena parte de los equipos de ambas marcas.
  • SIA DC-09: no es un formato de eventos sino un transporte IP estandarizado que encapsula eventos Contact ID o SIA en paquetes TCP/UDP, con cifrado y supervisión opcionales. Es lo que usan los comunicadores modernos para hablar con receptores IP.

Lo esencial: si tu plataforma de monitoreo entiende Contact ID y SIA sobre DC-09, entiende a tus paneles DSC y Paradox.

Las dos rutas hacia la nube

Aquí está la decisión de arquitectura. Ambas rutas son válidas y muchas empresas usan las dos a la vez.

Opción A: receptor local + connector

Si ya operas un receptor físico (SurGard, Ademco, Bosch), tus paneles siguen reportando exactamente como hoy —por línea telefónica, IP o celular— y no tocas ninguna programación en campo. Lo que agregas es un connector: un software que se instala junto al receptor, toma los eventos que este entrega (por puerto serie o red) y los sube cifrados a la plataforma en la nube.

Es la ruta ideal para migrar un parque grande sin visitas técnicas: el día uno, todas tus cuentas ya están en la nube.

Opción B: recepción IP directa

Los comunicadores IP/celular de los paneles se programan para reportar directamente a un endpoint de recepción en la nube (una dirección IP o dominio y un puerto, usando SIA DC-09). No hay receptor físico intermedio.

Es la ruta natural para instalaciones nuevas: menos hardware, alta más rápida y supervisión de enlace nativa. Requiere reprogramar el destino de reporte en cada comunicador, por lo que en cuentas existentes se suele hacer de forma gradual. Plataformas como Treinco Cloud soportan ambas rutas en paralelo, de modo que puedes migrar a tu ritmo.

Qué es un connector (y por qué simplifica todo)

Vale la pena detenerse en esta pieza, porque resuelve el problema más difícil de la migración: el equipamiento existente.

Un connector es un puente de software entre tu infraestructura local y la nube. Sus funciones típicas:

  • Recibe eventos de receptores locales (o directamente de paneles, actuando como receptor IP).
  • Normaliza los distintos formatos a un modelo común de eventos.
  • Almacena y reenvía: si el enlace a la nube se cae, guarda los eventos localmente y los entrega cuando vuelve la conexión, sin pérdidas.
  • Cifra la comunicación hacia la plataforma.

En cuanto al despliegue, hay tres variantes habituales: instalado en tu central (por ejemplo, como contenedor Docker junto al receptor, imprescindible si el receptor entrega por puerto serie), en un servidor en la nube con IP fija dedicada (útil cuando los paneles reportan por IP y quieres una dirección estable sin alojar nada tú), o totalmente gestionado por el proveedor de la plataforma. La elección depende de dónde están tus receptores y de cuánto quieras administrar. En nuestra página de centrales de monitoreo puedes ver los tres modos comparados.

Pasos generales de configuración

Los menús exactos varían según panel, comunicador y versión de firmware —consulta siempre el manual del fabricante—, pero el proceso general es el mismo:

  1. Define la ruta: ¿este panel reportará a tu receptor local (opción A) o directo a la nube (opción B)?
  2. Prepara la recepción: da de alta la cuenta en la plataforma con su número de abonado, y anota el endpoint de recepción (host y puerto) si usarás la opción B.
  3. Configura el comunicador: destino de reporte (host/puerto o número de receptor), protocolo (Contact ID o SIA sobre DC-09), número de cuenta y, si aplica, clave de cifrado y APN de la SIM.
  4. Habilita la doble vía si el comunicador es dual: vía principal, vía de respaldo y condiciones de conmutación.
  5. Configura la supervisión: intervalo de polling o prueba periódica, y en la plataforma la alerta correspondiente cuando un panel deja de comunicar.
  6. Prueba de punta a punta: dispara eventos reales de cada tipo (alarma, restauración, armado, desarmado, tamper, falla de AC) y verifica que lleguen con la zona y partición correctas.
  7. Documenta: cuenta, equipo instalado, versión de firmware, vías configuradas y fecha de prueba.

Errores comunes (y cómo evitarlos)

  • Probar solo un tipo de evento. Que llegue la prueba periódica no garantiza que las alarmas lleguen con zona y partición correctas. Prueba el catálogo completo.
  • Olvidar la supervisión de enlace. Un panel conectado a la nube sin supervisión es un panel que puede llevar semanas mudo sin que nadie lo note. Configura el intervalo de supervisión y la alerta de pérdida de comunicación desde el día uno.
  • Duplicar cuentas durante la migración. Si un panel reporta a la vez por el receptor local y por IP directa con el mismo número de cuenta, puedes recibir eventos duplicados o pisarte entre rutas. Migra cada cuenta por una sola ruta a la vez.
  • Depender solo del internet del cliente. Un comunicador solo-IP se queda mudo con un corte de luz al router. Para cuentas críticas, exige vía celular de respaldo.
  • No cifrar el DC-09. El estándar soporta cifrado; si envías eventos por internet abierto sin cifrar, estás exponiendo información de seguridad de tus clientes. Actívalo siempre que el comunicador lo permita.
  • Ignorar la zona horaria y el NTP. Relojes desincronizados generan historiales confusos y pueden causar rechazos en enlaces supervisados con marca de tiempo.
  • No registrar qué firmware tiene cada comunicador. Cuando algo falla meses después, saber la versión exacta ahorra horas de diagnóstico.

Conclusión

Conectar paneles DSC y Paradox a la nube no exige reemplazar tu parque instalado: con los comunicadores adecuados, los protocolos estándar (Contact ID y SIA DC-09) y un connector para tu receptor local, puedes migrar gradualmente y con marcha atrás en todo momento. Empieza por un grupo piloto de cuentas, valida el flujo completo de eventos y luego escala.

¿Quieres ver el proceso funcionando con un panel real? Agenda una demo y te mostramos la conexión de punta a punta en Treinco.

¿Listo para transformar tu operación?

Agenda una demostración personalizada con nuestro equipo

¿Dudas? Escríbenos