Ir al contenido

← Todas las funcionalidades

Monitorización textil (tejeduría)ESP32 PLCMQTTControl

Un canal de comandos petición/respuesta sobre MQTT

Los comandos remotos MQTT convierten un nodo de telemetría unidireccional en un dispositivo que de verdad puedes operar. Cada PLC ESP32 se suscribe a esp32/{id}/comands y responde por esp32/{id}/comands_response: pide información del sistema, lista la tarjeta SD, lanza la subida de un fichero — todo desde una consola Node-RED, sin ladder y sin portátil junto a la máquina. Es el canal de gestión de un despliegue real de monitorización de máquinas textiles repartido en dos plantas.

Topics emparejados por dispositivo

El ID del PLC va incrustado en ambos nombres de topic, de modo que un comando siempre se dirige exactamente a un dispositivo, mientras que un dashboard de supervisión puede suscribirse al comodín esp32/+/comands_response y ver responder a toda la flota en tiempo real. Cada respuesta lleva la identidad del PLC, así que las respuestas son atribuibles incluso agregadas. Un comando desconocido tampoco se desvanece en el vacío — devuelve un error explícito con la lista de comandos soportados, porque el silencio es el peor diagnóstico posible.

Mantén ligero el callback MQTT

El callback de PubSubClient se ejecuta dentro de mqtt.loop(), y hacer trabajo pesado ahí — recorrer el directorio de la SD, construir cadenas de respuesta largas — arriesga paquetes MQTT perdidos e incluso resets por watchdog. El callback de este ejemplo hace lo mínimo, copiar el comando a un buffer y levantar un flag, y el loop principal lo recoge y lo ejecuta en la siguiente pasada. Es la misma disciplina que se aplica a una rutina de servicio de interrupción — recibir rápido, procesar después.

Comandos que se ganan el sueldo

Tres comandos cubren el grueso de la operación diaria de la flota. El comando info devuelve uptime, heap libre, dirección IP y RSSI del WiFi para chequeos de salud remotos; list inventaría los ficheros .json almacenados en la tarjeta SD con sus tamaños; y upload entrega el fichero elegido al módulo HTTP POST para recuperar un día completo de datos. La resuscripción ocurre tras cada reconexión MQTT, así que el canal de comandos sobrevive de forma transparente a reinicios del broker y caídas de red.

Un fragmento de la implementación

Tal cual del ejemplo desplegado en el ESP32 PLC — cópialo libremente:

void setup() {
  Serial.begin(115200);
  SD.begin();

  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASS);
  uint32_t t0 = millis();
  while (WiFi.status() != WL_CONNECTED && millis() - t0 < 15000) delay(500);

  mqtt.setServer(MQTT_HOST, MQTT_PORT);
  mqtt.setCallback(onMqttMessage);
  checkMQTT();
}
Ver el ejemplo completo funcionando Consigue el pack del proyecto

El ejemplo completo es un programa entero — cabecera de conexionado, setup y bucle principal — listo para adaptar a tu aplicación.

Preguntas frecuentes

¿Por qué no poner comandos y respuestas en el mismo topic?

El PLC recibiría sus propias respuestas y entraría en bucle, y las consolas no podrían filtrar peticiones de respuestas. Los topics emparejados dan un enrutado limpio y permiten poner ACL distintas a cada sentido en el broker.

¿Qué impide que un cliente no autorizado envíe comandos?

La conexión al broker usa credenciales, y las ACL del broker pueden restringir quién puede publicar en los topics de comandos. Mantén el broker en la red de planta y da a las consolas sus propias cuentas.

¿Puedo añadir comandos de actuación, como parar una máquina?

Técnicamente sí — suscríbete y gobierna una salida — pero en este despliegue de monitorización los comandos son deliberadamente de solo lectura más operaciones de fichero. Si actúas, añade validación de payload, idempotencia y un enclavamiento en el lado de la máquina.

Funcionalidades relacionadas