Shelly Manager

Contexto y Motivación

Los dispositivos Shelly (relés inteligentes de segunda generación, Gen2) son ampliamente utilizados en automatización industrial por su bajo coste, su API HTTP/RPC nativa y su soporte MQTT. Sin embargo, gestionarlos a escala —con decenas o cientos de unidades en distintas ubicaciones— requiere una solución centralizada que vaya más allá de la app oficial. Este proyecto construye esa solución desde cero, con control total sobre cada capa del stack.

Arquitectura del Sistema

El sistema se compone de tres grandes bloques: FRONTEND BACKEND (Node.js + Express + TS) HTTP RPC MQTT over TLS

Backend — Node.js con TypeScript y Express. Expone una API REST completa bajo el prefijo `/api`. Se conecta a MySQL para persistencia de metadatos de dispositivos, tipos, perfiles y firmwares. Se conecta a InfluxDB para almacenar y consultar logs de telemetría de los dispositivos. Dos servicios de fondo corren en paralelo: el `deviceChecker` y el `deviceLogger`.

Frontend — Angular con Tailwind CSS. SPA con routing propio, servida como estáticos desde el mismo servidor Express. Consume la API REST del backend mediante un servicio centralizado (`BackendService`) y gestiona el estado de selección de dispositivo entre vistas con un `DeviceService` basado en `BehaviorSubject` de RxJS.

Infraestructura — AWS Greengrass actúa como broker MQTT con TLS mutuo (certificados X.509). Los dispositivos Shelly publican telemetría y logs en topics MQTT. El backend se suscribe a esos topics para ingestar datos en InfluxDB.

Funcionalidades Implementadas

Dashboard de Dispositivos

La vista principal muestra en tiempo real el estado de toda la flota de dispositivos en una tabla con búsqueda en vivo. Para cada dispositivo se visualiza:

Hostname configurado en el dispositivo
Tipo de dispositivo (modelo Shelly)
Estado de conectividad (Online/Offline) con badge de color
Señal WiFi en dBm
Versión de firmware instalada
Estado de conexión MQTT al broker Greengrass

Desde el dashboard se puede acceder a tres acciones por dispositivo:

Vista de información detallada: abre un modal que consulta en tiempo real al dispositivo vía HTTP RPC (`Shelly.GetStatus`, `Shelly.GetDeviceInfo`, `MQTT.GetConfig`) y muestra hostname, firmware, MAC, modelo, estado MQTT, topic, uptime, RSSI WiFi, estado del relé y temperatura interna.
Edición rápida: permite cambiar el hostname del dispositivo en caliente y resetear su configuración de sistema (timezone y servidor SNTP) sin necesidad de acceso físico.
Acceso a configuración avanzada: navega a la vista de configuración pasando el dispositivo seleccionado mediante el `DeviceService`.

Configuración Remota de Dispositivos

Vista dedicada a la configuración avanzada de un dispositivo seleccionado. Recibe el contexto del dispositivo a través del `DeviceService` (patrón de estado compartido con RxJS), lo que permite una navegación fluida desde el dashboard sin recargas ni parámetros en la URL.

Permite enviar configuraciones RPC directamente al dispositivo (`Sys.SetConfig`) con soporte para:

Configuración de debug (MQTT debug, WebSocket debug)
Servidor SNTP
Zona horaria
Gestión automática del reinicio del dispositivo si el cambio lo requiere (`restart_required`)

Gestión de Logs y Telemetría

Vista de consulta de logs históricos almacenados en InfluxDB. El operador puede:

Seleccionar uno o varios dispositivos de la flota (filtrados por los que tienen topic MQTT configurado)
Definir un rango de fechas de inicio y fin
Consultar los logs almacenados en la medición `device_logs` de InfluxDB
Ver el hostname asociado a cada entrada de log (resuelto desde el `deviceID`)

El `deviceLogger` del backend se suscribe en tiempo real a los topics MQTT `{mqtt_topic}/debug/log` de cada dispositivo registrado, parsea el formato de log nativo de Shelly (deviceId, logId, timestamp Unix, sourceInfo, mensaje) y escribe cada entrada como un punto en InfluxDB con tags y fields estructurados.

Operaciones en Lote (Batch)

Vista que permite seleccionar un tipo de dispositivo y ver todos los dispositivos de ese tipo agrupados, facilitando operaciones masivas sobre segmentos de la flota. Útil para aplicar configuraciones o actualizaciones de firmware a un grupo homogéneo de dispositivos sin tener que operar uno a uno.

Alta de Nuevos Dispositivos

Formulario reactivo con validación completa (Angular Reactive Forms) para registrar nuevos dispositivos en el sistema. Valida:

Hostname (requerido)
IP con regex de validación de formato IPv4
Tipo de dispositivo (seleccionado de los tipos registrados en el sistema)

Gestión de Certificados AWS IoT

Una de las funcionalidades más sofisticadas del sistema. Permite generar desde la propia interfaz web un **AWS IoT Thing** con su certificado X.509 asociado, listo para ser flasheado en un dispositivo Shelly. El flujo completo es:

1. El operador introduce el `client_id` (identificador único del dispositivo) y selecciona el site/región AWS
2. Se abre un modal para introducir las credenciales AWS temporales (access key, secret key, session token)
3. El backend verifica que el Thing no existe previamente en AWS IoT
4. Crea el Thing, genera el par de claves y el certificado X.509, lo activa y lo adjunta al Thing
5. El frontend recibe el certificado, la clave privada y la clave pública y permite descargarlos como archivos `.pem.crt` y `.pem.key` con el nombre del dispositivo como prefijo

Este flujo elimina completamente la necesidad de acceder a la consola de AWS para el aprovisionamiento de cada dispositivo, reduciendo el tiempo de onboarding de un dispositivo nuevo de minutos a segundos.

Panel de Administración

Cuatro secciones de administración completas con operaciones CRUD:

Admin Devices — Gestión de la base de datos de dispositivos. Permite cambiar la IP de un dispositivo (útil cuando cambia su asignación DHCP) y eliminar dispositivos del sistema. Incluye búsqueda en tiempo real. Admin Types — Catálogo de tipos de dispositivos Shelly soportados. CRUD completo para mantener el catálogo actualizado cuando se incorporan nuevos modelos. Admin Profiles — Gestión de perfiles de configuración reutilizables. Cada perfil almacena un objeto JSON de configuración RPC completo asociado a un tipo de dispositivo. Incluye un editor JSON en modal con validación de formato, y soporte para importar configuraciones desde archivo. Los perfiles permiten estandarizar la configuración de dispositivos del mismo tipo y aplicarla de forma consistente. Admin Firmwares — Repositorio de firmwares. Permite subir archivos de firmware al servidor (multipart/form-data con Multer), registrarlos en la base de datos con nombre y fecha, y gestionarlos. Cuando se elimina un firmware, el sistema elimina también el archivo físico del disco. Esto centraliza el repositorio de firmwares para poder distribuirlos a los dispositivos desde una URL interna.

Device Checker — Monitorización Automática

Servicio de fondo que se ejecuta cada 5 minutos y recorre todos los dispositivos registrados. Para cada uno:

1. Hace ping a la IP para verificar conectividad
2. Si responde, consulta las APIs RPC del dispositivo (`Shelly.GetStatus`, `Shelly.GetDeviceInfo`, `MQTT.GetConfig`)
3. Actualiza en MySQL el estado, WiFi, firmware, uptime, MQTT, topic y deviceID

Esto garantiza que el dashboard siempre refleja el estado real de la flota sin intervención manual.

Cliente Python — Ampere Client

Como complemento al sistema de gestión web, se desarrolló **Ampere Client**, un cliente Python que extiende las capacidades del ecosistema. Este cliente permite interactuar con la plataforma y los dispositivos desde scripts de automatización, integraciones con otros sistemas o pipelines de datos, aportando flexibilidad programática al ecosistema más allá de la interfaz web.

El Reto Técnico más Relevante: Colaboración con Shelly para Compatibilidad con AWS Greengrass

Este es, sin duda, el hito más significativo del proyecto y uno de los logros técnicos más destacables.

El problema: AWS Greengrass actúa como broker MQTT con TLS mutuo usando certificados autofirmados. Al intentar conectar los dispositivos Shelly Gen2 a este broker, la conexión fallaba sistemáticamente. Tras un análisis exhaustivo del comportamiento del dispositivo, se identificaron **dos bugs críticos en el firmware oficial de Shelly**:

1. Gestión incorrecta de certificados con TLS autofirmado: El firmware no manejaba correctamente la cadena de certificados cuando el broker usaba certificados de una CA privada (no pública), lo que hacía imposible establecer la conexión TLS mutua que requiere Greengrass.
1. Consumo desbordante de CPU por la librería TLS: La librería de encriptación TLS que utilizaba el firmware consumía el 100% de los recursos del procesador del dispositivo durante el handshake TLS, impidiendo que la conexión llegara a completarse y dejando el dispositivo inoperativo.

La acción: Se abrió contacto directo con el equipo de soporte técnico de Shelly, documentando el problema con trazas detalladas, capturas del comportamiento del procesador y casos de prueba reproducibles. Se trabajó en colaboración con su equipo de ingeniería proporcionando validaciones de cada versión candidata del firmware hasta confirmar que el comportamiento era correcto.

El resultado: Shelly desarrolló y publicó un **nuevo firmware** que resolvía ambos problemas, haciendo a sus dispositivos Gen2 completamente compatibles con AWS Greengrass y, por extensión, con cualquier broker MQTT con TLS mutuo y certificados autofirmados. Este firmware está hoy disponible para todos los usuarios de Shelly en todo el mundo.