Una alerta por email en Node-RED es una de las formas más sencillas de recibir un aviso cuando un valor de sensor publicado por MQTT sale de rango. En este tutorial construirás un flujo que vigila un topic de temperatura, envía un email cuando cruza un límite, evita enviar decenas de duplicados y además te avisa cuando un dispositivo deja de publicar por completo.
Qué vamos a construir
El flujo terminado hace cuatro cosas:
- Se suscribe a un topic de sensor en un broker MQTT.
- Decide si el valor está en estado de alarma usando un límite alto y un límite de reinicio más bajo (histéresis), para que un valor que oscila alrededor del límite no dispare emails repetidos.
- Envía un email cuando empieza la alarma y otro cuando se despeja, con un cooldown para que un sensor inestable no pueda inundar tu bandeja de entrada.
- Envía un email aparte si no ha llegado ningún mensaje en diez minutos, porque un sensor muerto suele ser más peligroso que una lectura alta.
Para los ejemplos usamos el servidor MQTT público gratuito en broker.connectmq.com con el prefijo de topic connectmq/demo/k7f3qa. Elige tu propia cadena aleatoria en lugar de k7f3qa y recuerda que cualquiera puede leer el área pública, así que úsala solo para pruebas y prototipos, no con datos de producción.
Instalar el nodo de email
Node-RED no incluye un nodo de email de serie. Instálalo desde Menu → Manage palette → Install buscando node-red-node-email, o desde la línea de comandos en tu directorio de usuario de Node-RED:
cd ~/.node-red
npm install node-red-node-email
# después, reinicia Node-RED
El paquete añade un nodo de salida e-mail que envía por SMTP y un nodo de entrada e-mail que lee un buzón. Solo necesitamos el nodo de salida. Su comportamiento es sencillo: msg.payload se convierte en el cuerpo, msg.topic en el asunto y, si el campo To del nodo se deja vacío, msg.to fija el destinatario.
Configuraciones SMTP que funcionan de verdad
| Proveedor | Servidor | Puerto | Conexión segura | Notas |
|---|---|---|---|---|
| Gmail / Google Workspace | smtp.gmail.com | 465 | Activada | Requiere verificación en dos pasos y una contraseña de aplicación |
| Microsoft 365 | smtp.office365.com | 587 | Desactivada (usa STARTTLS) | SMTP AUTH debe estar permitido para el buzón |
| Servicio transaccional (SendGrid, Mailgun, SES) | Host del proveedor | 465 o 587 | Según el proveedor | La mejor entregabilidad para correo automatizado |
| Relay local (Postfix) | localhost | 25 | Desactivada | Solo si ya tienes un relay en marcha |
Con Gmail, no uses tu contraseña normal. Crea una contraseña de aplicación en la configuración de seguridad de tu cuenta de Google y pégala en el nodo. Para cualquier cosa que vaya más allá de un proyecto personal, un servicio de email transaccional con un dominio de envío verificado ofrece mejor entregabilidad, porque los filtros de spam atrapan con facilidad el correo de alertas automatizado enviado desde un buzón personal.
Construir el flujo de alerta por email en Node-RED
El flujo es: mqtt in → function (lógica de alarma) → e-mail, más una rama con un nodo trigger para detectar el silencio. Si nunca has conectado nodos MQTT, el tutorial de Node-RED con MQTT explica en detalle el nodo de configuración del broker.
Paso 1: suscribirse al sensor
Añade un nodo mqtt in con:
- Server:
broker.connectmq.com, puerto1883, un client ID único comonr-alerts-k7f3qa - Topic:
connectmq/demo/k7f3qa/greenhouse/temperature - Output: detección automática (objeto JSON parseado o cadena)
Paso 2: la lógica de alarma
Un simple nodo switch que comprueba payload > 30 envía un email por cada lectura superior a 30. Si el sensor informa cada diez segundos, son 360 emails por hora. En su lugar, guarda el estado en el contexto del nodo y emite solo en las transiciones. Pon esto en un nodo function:
const HIGH = 30; // activar la alarma en este valor o por encima
const RESET = 28; // despejar la alarma en este valor o por debajo
const COOLDOWN_MS = 15 * 60 * 1000; // tiempo mínimo entre emails
let value = msg.payload;
if (typeof value === "object" && value !== null) value = value.value;
value = Number(value);
if (isNaN(value)) return null;
const inAlarm = context.get("inAlarm") || false;
const lastSent = context.get("lastSent") || 0;
const now = Date.now();
let event = null;
if (!inAlarm && value >= HIGH) event = "raised";
if (inAlarm && value <= RESET) event = "cleared";
if (!event) return null;
context.set("inAlarm", event === "raised");
// Notificar siempre el despeje, pero limitar la frecuencia de nuevas alarmas
if (event === "raised" && now - lastSent < COOLDOWN_MS) {
node.status({ fill: "yellow", shape: "ring", text: "alarm suppressed (cooldown)" });
return null;
}
context.set("lastSent", now);
node.status({
fill: event === "raised" ? "red" : "green",
shape: "dot",
text: event + " at " + value
});
msg.topic = event === "raised"
? `ALARM: greenhouse temperature ${value} C`
: `Cleared: greenhouse temperature back to ${value} C`;
msg.payload =
`Greenhouse temperature ${event}.\n\n` +
`Current value: ${value} C\n` +
`Alarm limit: ${HIGH} C, reset limit: ${RESET} C\n` +
`Time: ${new Date(now).toISOString()}\n` +
`Source topic: connectmq/demo/k7f3qa/greenhouse/temperature\n`;
return msg;
La diferencia entre HIGH y RESET es la banda de histéresis. Un valor que rebota entre 29,8 y 30,2 dispara una sola vez y después permanece en alarma hasta que baja de verdad a 28.
Paso 3: configurar el nodo e-mail
Conecta la salida del nodo function a un nodo e-mail. Rellena el destinatario, el servidor, el puerto, la conexión segura, el usuario y la contraseña según la tabla anterior. Haz deploy, y el estado del nodo mostrará si el inicio de sesión SMTP tuvo éxito la primera vez que pase un mensaje.
Paso 4: detectar dispositivos silenciosos
Añade un segundo cable desde el nodo mqtt in hasta un nodo trigger configurado así:
- Send: nothing
- Then: wait for 10 minutos, con extend delay if new message arrives marcado
- Then send: una cadena como
No data from greenhouse sensor for 10 minutes
Cada lectura entrante reinicia el temporizador, así que el trigger solo se dispara cuando el sensor se queda en silencio. Lleva su salida a un nodo change que establezca msg.topic con una línea de asunto y después al mismo nodo e-mail.
Probar sin esperar a una ola de calor
Publica valores de prueba desde una terminal:
# normal
mosquitto_pub -h broker.connectmq.com -p 1883 -i test-k7f3qa -t "connectmq/demo/k7f3qa/greenhouse/temperature" -m "24.5"
# activar la alarma
mosquitto_pub -h broker.connectmq.com -p 1883 -i test-k7f3qa -t "connectmq/demo/k7f3qa/greenhouse/temperature" -m "31.2"
# sigue alto, sin email nuevo
mosquitto_pub -h broker.connectmq.com -p 1883 -i test-k7f3qa -t "connectmq/demo/k7f3qa/greenhouse/temperature" -m "30.4"
# despejar
mosquitto_pub -h broker.connectmq.com -p 1883 -i test-k7f3qa -t "connectmq/demo/k7f3qa/greenhouse/temperature" -m "27.0"
Deberías recibir exactamente dos emails. Durante las pruebas, reduce temporalmente COOLDOWN_MS y el retardo del trigger, y coloca un nodo debug en paralelo con el nodo e-mail para ver qué se enviaría sin llamar al servidor SMTP cada vez.
Solución de problemas de entrega de email
| Problema | Qué comprobar |
|---|---|
| El nodo muestra "Invalid login" | Usa una contraseña de aplicación con Gmail; comprueba que SMTP AUTH está activado en los buzones de Microsoft 365 |
| Tiempo de espera de conexión agotado | Algunos ISP y proveedores cloud bloquean el puerto 25 y a veces el 465/587; prueba el otro puerto o un servicio transaccional |
| Error "Self signed certificate" | Combinación incorrecta de puerto y conexión segura, por ejemplo conexión segura activada en el 587 |
| Los emails llegan a spam | Envía desde un dominio con SPF y DKIM configurados y evita asuntos en mayúsculas |
| Un email por cada lectura | El nodo function no guarda el estado; asegúrate de devolver null cuando no hay transición |
| Ningún email tras reiniciar con el valor alto | Por defecto, el contexto está en memoria; es lo esperado, la siguiente lectura vuelve a evaluar el estado |
Si necesitas que el estado de alarma sobreviva a un reinicio de Node-RED, activa un almacén de contexto persistente en settings.js y usa context.get("inAlarm", "file"). La guía de contexto de Node-RED explica las opciones.
Alertas por email en Node-RED frente a reglas de alerta por umbral de ConnectMQ
Si tus dispositivos publican en un broker de ConnectMQ, ya tienes una segunda opción. Su portal incluye reglas de alerta por umbral y un log de alertas: eliges un topic, fijas un límite y cada cruce queda registrado donde tú y tu equipo podéis revisarlo, sin ejecutar ningún software adicional.
Los dos enfoques se complementan:
| Necesidad | Reglas de alerta del portal | Flujo de email en Node-RED |
|---|---|---|
| Umbral simple sobre un topic | Sí, configurado en el portal | Sí |
| Historial de alertas en un solo lugar | Log de alertas en el portal | Lo construyes tú, por ejemplo con Node-RED y MySQL |
| Lógica personalizada (histéresis, condiciones combinadas, horarios) | Solo reglas de umbral | Todo lo que puedas escribir en JavaScript |
| Entrega en una bandeja de entrada, chat o SMS | No es el propósito del log de alertas | Nodo e-mail, más Telegram u otros nodos de notificación |
| Sin servidor adicional que mantener | Sí | Necesita una instancia de Node-RED |
Un patrón habitual es configurar reglas de umbral en el portal para la visibilidad y la auditoría, y ejecutar junto a ellas un pequeño flujo de Node-RED para el puñado de condiciones que deben llegar al teléfono de alguien de madrugada. Como Node-RED es solo otro cliente MQTT, ambos leen los mismos topics del mismo broker. Esa es la forma general de las integraciones con un broker MQTT gestionado: el broker mueve los mensajes de forma fiable y las herramientas externas se suscriben y actúan sobre ellos.
Lista de comprobación para producción
- Pasa del servidor público a tus propias credenciales (
YOUR_USERNAME,YOUR_PASSWORD,YOUR_CLIENT_ID) en el puerto 8883 con TLS. - Guarda las contraseñas SMTP en las credenciales del nodo, nunca en un nodo function ni en un archivo de flujo que subas a git.
- Usa QoS 1 en la suscripción para que una desconexión breve no descarte en silencio la lectura que cruza el límite.
- Conserva el watchdog de silencio; detecta baterías agotadas, cortes de Wi-Fi y gateways caídos.
- Envía a una dirección de grupo o lista de distribución en lugar de a una sola persona.
- Prueba la cadena completa cada mes publicando un valor alto ficticio.
Empieza con ConnectMQ
Las alertas solo son tan fiables como el broker que entrega las lecturas. ConnectMQ te ofrece un broker MQTT gestionado con TLS, MQTT 5 y alertas por umbral en el portal, y tus flujos de Node-RED se conectan a él como cualquier otro cliente. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y podrás pasar este flujo del servidor público a credenciales privadas en pocos minutos.
Preguntas frecuentes
¿Qué nodo de Node-RED envía emails?
El nodo de salida e-mail del paquete node-red-node-email. Instálalo desde el gestor de paleta y después usa msg.payload para el cuerpo y msg.topic para el asunto.
¿Cómo evito que Node-RED envíe un email por cada lectura?
Guarda el estado de alarma en el contexto y envía solo en las transiciones, añade un límite de reinicio por debajo del límite de alarma para tener histéresis y aplica un cooldown entre emails de alarma, como se muestra en el nodo function de arriba.
¿Puede ConnectMQ enviar el email en lugar de Node-RED?
El portal ofrece reglas de alerta por umbral y un log de alertas. Para entregar notificaciones en una bandeja de entrada, ejecuta un cliente como Node-RED que se suscriba al broker y envíe el email.
¿Por qué Gmail rechaza el inicio de sesión de Node-RED?
Google bloquea las contraseñas normales para SMTP desde aplicaciones. Activa la verificación en dos pasos, genera una contraseña de aplicación y úsala en el nodo e-mail con smtp.gmail.com en el puerto 465 y conexión segura.



