Conecta, detecta y envía comandos.

Míralo en funcionamiento.

Abre el panel de la cantera y reproduce una ejecución grabada.

Cómo se procesa un mensaje.

Un dispositivo envía un mensaje por MQTT, HTTP, Sparkplug B o LwM2M. Tras decodificar el mensaje e identificar el dispositivo, DeviceChain pasa el evento a los servicios que lo almacenan, actualizan el estado del dispositivo y evalúan tus reglas. Las reglas coincidentes activan acciones. Los servicios se comunican mediante NATS JetStream.

Los clientes o las unidades de negocio pueden compartir una instalación, con aislamiento entre tenants en la base de datos y el bus de mensajes. El operador administra la instalación y sus tenants. La documentación de multitenencia explica el aislamiento.

Perfiles de dispositivo tipados y versionados.

Los tipos de dispositivo describen equipos como contadores, congeladores o camiones. Cada tipo usa un perfil que define sus mediciones, comandos y reglas de detección. Varios tipos pueden compartir un perfil. Puedes editar un borrador, publicar una versión o volver a una anterior.

Relaciona un dispositivo con su cliente, emplazamiento o activo, y usa esas relaciones para encontrar sus lecturas. Las relaciones tipadas también permiten describir conexiones entre dispositivos y otras entidades.

Perfiles de dispositivo

Métricas, definiciones de comandos tipados y reglas de detección, publicadas en versiones.

Grafo de relaciones

Relaciones tipadas y dirigidas entre entidades. Puedes declarar atributos como facetas para explorar y filtrar por varios criterios a la vez, como emplazamiento, línea de producto y propietario.

Grupos dinámicos

Una expresión CEL sobre los atributos de las entidades. Cada lectura del grupo calcula sus miembros mediante una consulta indexada a la base de datos.

Clientes, áreas y activos

Los dispositivos se asignan a clientes, áreas y activos. Los activos se organizan en un árbol de padres e hijos. Las áreas son ubicaciones con nombre; sus límites se dibujan como geocercas independientes. Cada evento registra las relaciones del dispositivo al escribirse, conservando el contexto histórico tras una reasignación.

Credenciales y sustitución

El dispositivo conserva un token estable; sus credenciales son independientes y se pueden rotar. Una sola operación sustituye el hardware averiado, retira las credenciales de la unidad anterior y conserva el historial del dispositivo.

Estado en tiempo real

El último valor de cada medición y si el dispositivo está conectado. MQTT, Sparkplug B y LwM2M notifican conexiones y desconexiones directamente. Un dispositivo HTTP se considera conectado mientras siga enviando datos.

Prueba una regla con el historial almacenado.

Previsualiza un borrador con eventos almacenados para ver cuándo se habría activado su condición. La previsualización usa el mismo compilador y motor de reglas que el procesamiento en tiempo real.

Ejecuta la previsualización desde el lienzo de automatización antes de publicar. Parte de un estado de reglas vacío, no carga atributos de dispositivos ni aplica el ámbito de grupos, y notifica las lecturas omitidas o los límites alcanzados. La documentación del motor de detección detalla sus límites.

Tres formas de escribir una regla

Un formulario en el perfil del dispositivo, un lienzo visual de automatización o una descripción en lenguaje natural cuando está habilitado el servicio opcional de IA.

Alarmas

Las alarmas registran los estados activo, reconocido y resuelto, y pueden cambiar de severidad. La resolución depende de la regla; algunas reglas de ventana necesitan nuevos eventos para resolverse.

Ocho tipos de regla

Umbral, tasa de cambio, repetición, duración, ausencia, agregado en ventana, correlación de áreas y conectividad. Las reglas de ausencia y conectividad detectan dispositivos que dejan de enviar datos o se desconectan.

Geocercas

Dibújalas en la consola o envía polígonos con huecos mediante la API. La condición de una regla puede comprobar la pertenencia con geo.inFence(...). Cada evento de ubicación lleva la versión de geocercas vigente al llegar; la reproducción usa las geocercas de ese momento.

Ámbito

Las reglas se definen en un perfil de dispositivo; la mayoría de los tipos se pueden limitar a un grupo dinámico. La pertenencia al grupo se registra en cada evento cuando llega.

Describe una regla en lenguaje natural.

Con el servicio opcional de IA, escribe algo como «activar una alarma de severidad mayor cuando un congelador permanezca por encima de -15°C durante diez minutos» y recibe un borrador de regla. El borrador pasa por el mismo compilador que una regla escrita a mano. El servicio puede revisarlo a partir de los errores del compilador, hasta un límite fijo de intentos. Devuelve un borrador válido o los errores que no pudo resolver. Revisa la regla antes de publicarla: la compilación comprueba su estructura, no si refleja tu intención.

Las reglas publicadas se ejecutan sin llamar al modelo. Para habilitar la creación de reglas con IA, el operador registra el proveedor, pone un modelo a disposición del tenant y registra su consentimiento para la inferencia externa. La opción no está disponible hasta completar los tres pasos. Puedes dejar el servicio deshabilitado.

Paneles versionados que puedes integrar.

Consulta tu telemetría con SQL.

La telemetría se almacena en TimescaleDB, una extensión de PostgreSQL. Consúltala directamente con una herramienta compatible, como Metabase, Grafana, Power BI o psql, usando un rol de lectura analítica configurado.

Cada tenant puede tener su propio rol de lectura, con acceso a un esquema analítico de vistas de eventos, mediciones, agregados por minuto, ubicaciones, alertas y cambios de conexión. La base de datos filtra estas vistas al tenant del lector. El acceso a ubicaciones requiere un permiso adicional. La guía de SQL y BI explica la configuración.

Rol de solo lectura

Un rol de inicio de sesión por tenant con acceso de lectura a las vistas analíticas. Tú decides qué tenants reciben ese acceso.

O usa la API

Las aplicaciones usan la API GraphQL, que lee las mismas tablas sobre las que se construyen las vistas analíticas.

GraphQL, SDK de cliente y MCP.

La API usa GraphQL, con un esquema para cada área de la plataforma, y los archivos de esquema se publican con la documentación. El SDK de TypeScript se publica en npm (@devicechain/client), y el de .NET en NuGet (DeviceChain.Sdk). El SDK de .NET incluye comprobaciones de compilación anticipada; un paquete Unity, compilado desde el código fuente, lo adapta a los transportes de Unity.

Un servidor opcional Model Context Protocol permite que asistentes de IA como Claude, Cursor o VS Code lean dispositivos, estado, telemetría, alarmas y comandos. Las llamadas usan el token y los permisos del usuario conectado. El servidor expone una selección de herramientas de solo lectura, no la API completa.

GraphQL

Un esquema por área de la plataforma, con los archivos de esquema publicados.

SDK

TypeScript en npm y C#/.NET en NuGet, además del paquete Unity.

MCP

Un servidor de recursos OAuth 2.1 con herramientas de solo lectura, limitado al tenant del usuario.

Se ejecuta en Kubernetes, con PostgreSQL y NATS.

Las entidades se almacenan en PostgreSQL y la telemetría en TimescaleDB. NATS JetStream transporta los mensajes internos, actúa como broker MQTT y mantiene el estado clave-valor. La instalación configura estos componentes.

dcctl es un único binario que incluye el chart de Helm y la configuración de OpenTofu. Utiliza docker, kubectl, helm y OpenTofu (o Terraform), que debes instalar antes, además de kind (Kubernetes en Docker) para un clúster local. dcctl install prepara un clúster y dcctl bootstrap crea una instancia en él. Ambos comandos pueden usar un clúster existente. Los flujos de instalación e inicialización se prueban de extremo a extremo en kind, que también permite ejecutar DeviceChain en un portátil. El repositorio incluye una configuración OpenTofu que crea un clúster Google Kubernetes Engine con grupos de nodos separados para bases de datos y servicios.

En un clúster Google Kubernetes Engine con tres nodos de base de datos de 4 vCPU y 16 GB, y tres nodos de servicios de 4 vCPU y 8 GB, una instalación HA con sus valores predeterminados sostuvo 10.000 eventos por segundo durante diez minutos, en cada una de dos versiones de desarrollo que pasaron a formar parte de v0.22.0. Las comprobaciones evento por evento no encontraron eventos almacenados ausentes, duplicados ni inesperados. Los servicios y los líderes de los streams del broker de mensajes se mantuvieron en una misma ubicación equilibrada entre los nodos de servicios; dejando la ubicación al planificador, la versión candidata de v0.19.0 se midió del mismo modo a 6.000 eventos por segundo. Cada evento contenía una lectura. La prueba usó un tenant con su límite de ingesta elevado; con el límite predeterminado de 1.000 lecturas por segundo, los dispositivos de un tenant se admiten como máximo a 5.000 por segundo. La sección de rendimiento medido documenta las condiciones y los recursos. Estos resultados describen esa carga y ese clúster; no son una garantía de capacidad.

La instalación predeterminada también configura Prometheus, Grafana y Alertmanager, con las reglas de alerta y los paneles de la plataforma. Con las copias de seguridad habilitadas, ambas bases de datos archivan continuamente para recuperar un punto en el tiempo. La recuperación y la conmutación por error se prueban con ejercicios automatizados en un clúster en ejecución. La prueba de recuperación solo pasa si los secretos guardados antes de la copia siguen pudiendo descifrarse.

Operaciones y gobernanza.

Notificaciones de alarmas, entregas externas, auditoría, límites por tenant, retención de datos y eliminación de tenants.