Componentes de la Pila Tecnológica

Descripción General

Esta sección examina en detalle cada componente de la pila de la solución IoT. Al finalizar esta sección, podrás:

Explicar la función y configuración de cada componente tecnológico
Entender cómo los componentes interactúan y dependen entre sí
Describir alternativas comerciales y cuándo recomendarlas
Responder preguntas de los clientes sobre la selección de componentes y sus ventajas e inconvenientes

Mapa de Componentes

El siguiente diagrama muestra cómo se conectan los componentes tecnológicos y la dirección de su flujo de datos:

┌─────────────────────────────────────────────────────────────────────┐
│ Dashboard de Grafana │
│ (Visualización y Alertas) │
└───────────────────────────┬─────────────────────────────────────────┘
                            │ Consultas (Flux/SQL)
┌───────────────────────────▼─────────────────────────────────────────┐
│ InfluxDB + MariaDB │
│ (Series de Tiempo + Almacenamiento Relacional) │
└───────────────────────────┬─────────────────────────────────────────┘
                            │ Escrituras (nodos de Node-RED)
┌───────────────────────────▼─────────────────────────────────────────┐
│ Node-RED │
│ (Motor de Flujos, Procesamiento de Datos, Integración) │
└───────────────────────────┬─────────────────────────────────────────┘
                            │ Suscripción (MQTT)
┌───────────────────────────▼─────────────────────────────────────────┐
│ Broker MQTT (Mosquitto / EMQX) │
│ (Enrutamiento de Mensajes) │
└───────────────────────────┬─────────────────────────────────────────┘
                            │ Publicación (MQTT)
┌───────────────────────────▼─────────────────────────────────────────┐
│ ESP32 │
│ (Microcontrolador + Sensores/Actuadores) │
└─────────────────────────────────────────────────────────────────────┘

Componente 1: Microcontrolador ESP32

Rol en la Pila

El ESP32 es el dispositivo de borde que interactúa directamente con sensores y actuadores. Recopila mediciones físicas (temperatura, humedad, movimiento, etc.) y las convierte en datos digitales para su transmisión.

Especificaciones Clave

Especificación	Detalle
Procesador	Xtensa LX6 de doble núcleo (o LX7 en S3) hasta 240 MHz
RAM	520 KB SRAM (hasta 8 MB PSRAM en algunos modelos)
Flash	4-16 MB
WiFi	802.11 b/g/n, 2.4 GHz
Bluetooth	BLE 4.2 (Clásico en el original, solo BLE en C3/S3)
GPIO	Varía según el modelo: 16-34 pines programables
ADC	12 bits, hasta 18 canales
DAC	8 bits, 2 canales (no en C3/S3)
Sueño Profundo	Consumo de ~10 µA
Voltaje de Operación	3.3V (tolerante a 5V en algunos pines)

Variantes de Modelo y Guía de Selección

Modelo	Característica Clave	Ideal Para	Rango de Precio
ESP32 DevKit (original)	GPIO completo, Bluetooth Clásico	Prototipado de propósito general	$5-8
ESP32-S3	Acelerador de IA, más PSRAM	Pantallas LVGL, ML en el borde	$6-10
ESP32-C3	Núcleo RISC-V, menor costo	Sensores simples, sensibles al costo	$3-5
ESP32-CAM	Interfaz de cámara, PSRAM	Captura de imágenes, vigilancia	$7-12
ESP32-XIAO (Seeed)	Ultracompacto (21x17.5mm)	Wearables, espacios reducidos	$4-7
ESP32-Tower (Olimex)	Conectores industriales, LiPo	Prototipado con periféricos	$12-18

Lo que el ESP32 Puede y No Puede Hacer

Al analizar capacidades con los clientes, usa esta evaluación de límites:

Capacidades:

Leer hasta 18 sensores analógicos simultáneamente (con multiplexación ADC)
Controlar relés, LEDs, motores (mediante circuitos integrados controladores)
Procesar JSON, realizar cálculos, aplicar lógica
Comunicarse por WiFi hasta ~50 m en interiores, ~100 m en exteriores
Operar con batería durante semanas o meses (con optimización de sueño profundo)
Servir una página web simple o un endpoint de API REST

Limitaciones:

No puede procesar video de alta resolución (limitado a captura JPEG, no streaming)
Rendimiento limitado de punto flotante (usar aritmética entera cuando sea posible)
Alcance WiFi restringido; sin celular/LTE sin un módulo externo
Sin Ethernet nativo; requiere módulo SPI Ethernet (W5500, ENC28J60)
Límite de desgaste de la Flash (~100,000 ciclos de escritura para flash SPI)
Sin aceleración criptográfica por hardware en el ESP32 original (S3 tiene soporte mejorado)

Componente 2: Broker MQTT (Mosquitto / EMQX)

Rol en la Pila

El broker MQTT es el enrutador central de mensajes. Todos los dispositivos publican datos en el broker y todos los servicios del backend se suscriben a través de él. El broker desacopla a los emisores de los receptores: los dispositivos no necesitan conocerse entre sí.

Comparación Mosquitto vs EMQX

Característica	Mosquitto	EMQX
Licencia	Eclipse Public License (código abierto)	Apache 2.0 (núcleo de código abierto, edición enterprise disponible)
Lenguaje	C	Erlang
Conexiones Máximas (un solo nodo)	~10,000	~1,000,000
Soporte de Clúster	Limitado (modo puente)	Clustering nativo (escalado horizontal)
MQTT 5.0	Soportado	Soportado
Motor de Reglas	No (requiere integración externa)	Motor de reglas tipo SQL integrado
Dashboard Web	Mínimo (orientado a CLI)	Interfaz web completa
Uso de Recursos	~10 MB RAM	~50 MB RAM (mínimo)
Configuración	Archivo de texto (`mosquitto.conf`)	Dashboard + archivo de configuración
Soporte TLS	Sí	Sí
Sistema de Plugins	Sí (auth, logging)	Sí (ganchos de auth, extensiones)

Cuándo Recomendar Cada Uno

Recomendar Mosquitto cuando:

Implementaciones con menos de 1,000 dispositivos
Servidor con recursos limitados (p. ej., Raspberry Pi)
Configuración simple sin requisitos de clúster
El cliente prefiere sobrecarga mínima

Recomendar EMQX cuando:

Implementaciones con más de 1,000 dispositivos
Se requiere alta disponibilidad y clustering
Se necesita un motor de reglas integrado para preprocesamiento de datos
El cliente quiere un dashboard de gestión

Componente 3: Node-RED

Rol en la Pila

Node-RED es el motor de automatización e integración. Recibe datos MQTT, los procesa, los almacena y dispara acciones. Es el componente donde reside la mayor parte de la lógica de negocio.

Capacidades Clave

Programación basada en flujos: El cableado visual de nodos elimina el código repetitivo
Más de 1,000 nodos de la comunidad: Amplía la funcionalidad mediante paquetes npm
Editor integrado: IDE basado en navegador con consola de depuración e inspector de nodos
Almacenamiento de contexto: Conserva el estado entre mensajes (flujo, global, basado en archivos)
Endpoints HTTP: Puede actuar como servidor web o API REST
Nodo Function: Escribe JavaScript personalizado para lógica compleja
Subflujos: Encapsulan lógica reutilizable en nodos individuales

Uso Típico de Memoria

Escala de Implementación	Uso de RAM	Notas
Demo / proyecto único	50-100 MB	Flujos mínimos, pocos nodos
Producción pequeña (10-50 dispositivos)	100-300 MB	Múltiples flujos, nodos de base de datos
Producción media (50-500 dispositivos)	300-500 MB	Flujos complejos, endpoints HTTP
Grande (500+ dispositivos, procesamiento intenso)	500 MB - 2 GB	Considerar escalado horizontal

Componente 4: InfluxDB (Base de Datos de Series de Tiempo)

Rol en la Pila

InfluxDB almacena los datos de sensores como puntos de series de tiempo. Cada punto tiene un nombre de medición, etiquetas (metadatos indexados) y campos (valores numéricos). Esta estructura está optimizada para cargas de trabajo IoT.

Ejemplo de Modelo de Datos

measurement: "environment"
tags: location="factory_zone1", sensor_id="esp32_01"
fields: temperature=26.5, humidity=62.3
timestamp: 2026-05-17T10:30:00Z

Características Clave

Consultas continuas: Reducen el muestreo y agregan datos automáticamente
Políticas de retención: Eliminan automáticamente datos más antiguos que una duración configurable
Lenguaje de consulta Flux: Potente transformación y análisis de datos
API HTTP: Escribe y consulta datos mediante endpoints REST
Importación masiva: Rellena datos históricos desde CSV u otras fuentes

Estimación de Almacenamiento

Intervalo de Muestreo	Dispositivos	Puntos/Día	Almacenamiento/Día
10 segundos	10	86,400	~5 MB
1 minuto	50	72,000	~4 MB
5 minutos	100	28,800	~1.5 MB
1 hora	500	12,000	~0.7 MB

Versiones de InfluxDB

Versión	Estado	Recomendación
InfluxDB 1.x	Estable, a largo plazo	Ideal para implementaciones pequeñas/medianas. Lenguaje de consulta tipo SQL.
InfluxDB 2.x / OSS	Actual, activa	Lenguaje Flux, nueva interfaz, pero mayor uso de recursos.
InfluxDB Cloud	Servicio gestionado	Para clientes que quieren cero mantenimiento.

Componente 5: Grafana

Rol en la Pila

Grafana es la capa de visualización que convierte los datos almacenados en dashboards accionables. Se conecta a InfluxDB (y MariaDB) y proporciona visualización gráfica en tiempo real.

Características Clave para Preventa

Plantillas de dashboards: Exporta y reutiliza en demostraciones para clientes
Motor de alertas: Notificaciones por correo electrónico, Telegram, Slack, Webhook
Anotaciones: Marca eventos (p. ej., “dispositivo fuera de línea”, “umbral superado”)
Variables: Crea dashboards interactivos donde el cliente elige rango de tiempo, dispositivo, ubicación
Paneles: Series de tiempo, gráfico de barras, medidor, tabla, mapa de calor, estadística y más

Principios de Diseño de Dashboards para Demos con Clientes

Comienza con las métricas clave: Temperatura, humedad, consumo de energía — los números que más importan a los clientes
Usa codificación por colores: Verde (normal), amarillo (advertencia), rojo (alerta) para comprensión instantánea
Incluye selector de rango de tiempo: Permite al cliente cambiar entre vistas de 1h, 24h, 7d, 30d
Agrega líneas de umbral: Muestra los rangos aceptables directamente en los gráficos
Mantenlo limpio: Evita la sobrecarga de información — 3-5 paneles por dashboard es ideal para demos

Componente 6: Docker y Docker Compose

Rol en la Pila

Los contenedores Docker empaquetan cada servicio (Mosquitto, Node-RED, InfluxDB, Grafana) en unidades aisladas y portátiles. Docker Compose los orquesta como una sola pila.

¿Por Qué Usar Contenedores?

Reproducibilidad: El mismo entorno en cualquier máquina (Windows, Mac, Linux)
Aislamiento: Cada servicio se ejecuta de forma independiente; una falla no se propaga
Actualizaciones simplificadas: Reemplaza un contenedor sin afectar a los demás
Portabilidad para demos: Empaqueta y despliega toda la pila en el servidor del cliente
Eficiencia de recursos: Los contenedores comparten el kernel del sistema operativo anfitrión (vs. VMs)

Descripción de la Pila Docker Compose

Un docker-compose.yml típico para esta pila incluye:

Servicio	Imagen	Puertos	Volumen
Mosquitto	`eclipse-mosquitto:2`	1883, 8883	Configuración, datos, log
Node-RED	`nodered/node-red:4`	1880	Datos de usuario
InfluxDB	`influxdb:2`	8086	Almacenamiento de datos
Grafana	`grafana/grafana:11`	3000	Dashboards, configuración

Tabla Resumen de Decisiones Tecnológicas

Cuando los clientes preguntan por alternativas, esta tabla de referencia es útil durante las consultas:

Componente	Solución Elegida	Alternativa Principal	Diferenciador Clave
Microcontrolador	ESP32	Arduino Due, STM32	WiFi + BLE integrados, costo
Comunicación	MQTT	HTTP, CoAP, Zigbee	Ligero, pub-sub, QoS
Broker	Mosquitto/EMQX	VerneMQ, HiveMQ CE	Código abierto, MQTT 5.0
Automatización	Node-RED	Home Assistant, n8n	Flujo visual, orientado a IoT
Base de Datos de Series de Tiempo	InfluxDB	TimescaleDB, Prometheus	Rendimiento de escritura, retención
Visualización	Grafana	Kibana, Chronograf	Múltiples fuentes, alertas
Contenerización	Docker	Podman, Kubernetes	Estándar de la industria, simple

Resumen

Cada componente de la pila tecnológica cumple un propósito específico, y comprender sus roles permite conversaciones efectivas con los clientes:

ESP32 gestiona la recopilación de datos de sensores y el control de dispositivos en el borde
El broker MQTT proporciona enrutamiento confiable de mensajes entre dispositivos y servidores
Node-RED procesa datos, aplica lógica de negocio e integra sistemas
InfluxDB almacena datos de series de tiempo con alto rendimiento de escritura
Grafana visualiza los datos en dashboards en tiempo real con alertas
Docker hace que toda la pila sea portátil, escalable y fácil de desplegar

¿Desarrollas un producto IoT comercial?

Ofrecemos servicios ODM de ESP32, del diseño a la fabricación. Del prototipo a la producción: el equipo detrás de este tutorial puede construirlo contigo.

Hablemos →