Node-RED en cooperativas: medidores, alertas y registro
Caso de cooperativa con Node-RED: lecturas, MQTT, permisos, almacenamiento, alertas y prueba de respaldo para medidores rurales.
Un medidor rural envio cero durante dos horas y el aviso quedo en el telefono del proveedor. En una cooperativa electrica con internet rural, lecturas, cortes, tension y reclamos llegan desde equipos distintos y con horarios distintos. Node-RED 4.1 permite unir mensajes, reglas y alertas en flujos visibles. Este caso muestra que se carga primero, quien edita y como se prueba el respaldo.
Donde se corta la lectura antes de facturar
La cifra que corrige la rutina viene del release: Node-RED 4.1.10 fue publicado el 8 de mayo de 2026 como version de mantenimiento. En un sistema de lecturas, una version reciente importa cuando corrige dependencias, nodos, editor y seguridad del runtime.
Dos horas sin lectura bastan para cerrar mal una guardia.
La escala global explica por que estos flujos no conviene dejarlos en una maquina sin dueño. Octoverse 2025 informo mas de 180 millones de desarrolladores y 630 millones de repositorios. Una cooperativa local baja esa escala a medidores, radioenlaces, cuadrillas y socios. El requisito es el mismo: cada cambio necesita autor, fecha y salida.
El flujo visual que nadie exporto
El antagonista es el flujo armado en el navegador, sin exportacion, sin comentario y con una credencial escrita en un nodo. El gerente de una cooperativa electrica con internet rural puede tener un mapa de postes plastificado, radios en una repisa y un patch cord amarillo cruzando el rack. La lectura debe decir si fallo el medidor, el enlace, el broker o la regla.
La guia local de Node-RED parte de Node.js y un runtime que corre flujos. La documentacion de contexto explica donde se guardan datos temporales o persistentes usados por los nodos. Para datos de facturacion o reclamo, ese contexto sirve poco como memoria final: la lectura cerrada debe quedar en una base con auditoria.
El contrato del mensaje se escribe con campos obligatorios: medidor, zona, fecha, lectura, unidad, origen y version. Un mensaje sin zona queda rechazado. Un mensaje repetido conserva el primer cierre y registra el intento. Esa regla corta discusiones entre guardia, facturacion y proveedor.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, el medidor o gateway publica lectura, hora, tension, identificador y estado. Segundo, Mosquitto recibe el mensaje MQTT y lo entrega al flujo autorizado. Tercero, Node-RED valida formato, rango, duplicado y antiguedad. Cuarto, PostgreSQL guarda lectura, medidor, socio, zona, usuario, estado y auditoria. Quinto, MinIO/S3 guarda CSV de respaldo, capturas o reportes firmados cuando el proceso lo requiere. Sexto, una alerta avisa a guardia si faltan lecturas o si una zona cae. Septimo, el backup copia base, flujos, credenciales cifradas y archivos, y se prueba restaurando una lectura.
Node-RED recibe mensajes y entrega rutas, transformaciones y alertas. Mosquitto recibe publicaciones MQTT y entrega mensajes a suscriptores con permisos por usuario y topic. PostgreSQL recibe registros estructurados y entrega consultas por zona, medidor y fecha. El monitoreo recibe estado de servicios y entrega alertas. Si falla Node-RED, dejan de correr reglas. Si falla MQTT, no entran lecturas. Si falla la base, no queda cierre confiable.
Que se instala o configura primero
La pila inicial usa Node-RED 4.1, Node.js, Mosquitto, PostgreSQL 18, repositorio S3, HTTPS, usuarios del editor, ACL por topic, backup diario y tablero de faltantes. El piloto cuesta entre USD 1.100 y USD 3.200, entre ARS 1,56 y 4,54 millones al dolar vendedor oficial de $1.419 informado por Bluelytics. Incluye tres flujos, veinte medidores de prueba, dos alertas, permisos y restauracion.
El plazo va de tres a cinco semanas. UMSA suele pedir un entregable verificable: broker con usuario por origen, flujo exportado, regla de duplicados, tabla de lecturas, alerta por zona, reporte diario y recuperacion en otro host. El costo no incluye cambio de medidores, obra electrica ni enlace de ultima milla.
La primera prueba conviene hacerla con una zona chica. Se simulan diez lecturas, se repite una, se corta el broker, se recupera el servicio y se compara PostgreSQL contra el CSV. Guardia debe recibir una alerta con zona, horario, cantidad de medidores afectados y responsable.
Donde se rompe y como probarlo
Primer riesgo: contexto en memoria para datos que deben durar. La senal aparece cuando reiniciar Node-RED borra el ultimo estado. La prueba reinicia el servicio y compara la base. Segundo riesgo: MQTT sin permisos por topic. La senal es un equipo publicando en zona ajena. La prueba intenta publicar con credencial incorrecta y exige rechazo.
Tercer riesgo: flujos sin version. La senal aparece cuando nadie sabe quien cambio una regla. La prueba exporta flujos, revisa hash y registra aprobacion. Cuarto riesgo: credenciales fuera del backup. La senal es una restauracion que abre flujos pero no conecta al broker. La prueba levanta el stack en otro host y procesa una lectura real. La guardia termina cuando el sistema muestra lectura, zona, hora y prueba.