Capacidad principal: coordinación entre nube y borde mediante MQTT

El canal MQTT sostiene la coordinación entre nube y borde de Edge-EMS Builder: envía datos y decisiones del borde a la nube y recibe estrategias de la nube para convertirlas automáticamente en configuración local. Es una capacidad básica de los tres niveles de producto, no una opción avanzada que requiera un pago adicional o desarrollo a medida.

1. Configuración de conexión

Una conexión MQTT describe cómo acceder a un broker:

Parámetro	Descripción
protocol	mqtt / mqtts, según se utilice TLS
protocolVersion	Admite 3.1 / 3.1.1 / 5.0
serverHost / serverPort	Dirección y puerto del broker
clientId / username / password	Identificador del cliente y credenciales
cleanSession / keepAliveInterval / connectTimeout	Parámetros de sesión y conexión

Un dispositivo Edge-EMS Builder puede mantener varias conexiones MQTT simultáneas, por ejemplo con una plataforma en la nube y una pasarela local. Cada configuración de publicación o suscripción se vincula a una conexión concreta.

2. Publicación: organizar datos de borde en cualquier formato para enviarlos a la nube

La publicación define cada cuánto se envía, a qué topic y con qué contenido:

Parámetro	Descripción
topic / qos	Destino de publicación y nivel de calidad de servicio
uploadStrategy	Expresión CRON que controla el periodo de publicación
publishContent	Script Lua que devuelve el contenido del mensaje que se publicará

publishContent utiliza la misma sintaxis que el motor de expresiones y puede construir cualquier estructura JSON:

local payload = {}
payload.time = OffsetDateTime.now():unixMilli()
payload.power = ${PCS1_有功功率}
payload.status = ${PCS1_status}

-- También se admiten campos de array
payload.phaseVoltages = { ${Meter1_Ua}, ${Meter1_Ub}, ${Meter1_Uc} }

return payload

El motor serializa automáticamente la tabla Lua devuelta como JSON y la publica en el topic indicado. La nube recibe un mensaje JSON estándar:

{
  "time": 1745393449910,
  "power": 15.2,
  "status": "Charging",
  "phaseVoltages": [220.1, 219.8, 220.5]
}

3. Suscripción: convertir órdenes de la nube en acciones de escritura locales

La suscripción define el topic, el tratamiento de los mensajes y si se necesita respuesta:

Parámetro	Descripción
topic / qos	Topic suscrito y nivel de calidad de servicio
actionContent	Script Lua que analiza el mensaje y devuelve una lista de instrucciones de escritura
needResponse / responseTopic / response	Necesidad de respuesta, topic y contenido de respuesta, también construible mediante scripts

Al recibir un mensaje, el script obtiene su contenido original mediante la variable fija ${subscribe_message} y lo transforma en instrucciones de escritura:

local messageMap = jsonToMap(${subscribe_message})
local strategyList = jsonToListMap(toJsonString(messageMap.params.strategy))
local resultList = {}

for i, item in ipairs(strategyList) do
    local availableDate = completeDateTime(messageMap.params.date .. "T" .. item.start)
    local expiredDate = completeDateTime(messageMap.params.date .. "T" .. item["end"])

    table.insert(resultList, buildCommonWriteMap(
        "Customization", "mode", tostring(item.mode), availableDate, expiredDate, false
    ))
end

return resultList

Este script convierte una estrategia por franjas horarias enviada desde la nube, en forma de JSON con varios intervalos y un modo por intervalo, en instrucciones de escritura de datos por franjas horarias (Customization). La nube solo envía una vez el JSON acordado y el borde aplica automáticamente cada intervalo, sin desarrollo adicional.

4. Escenarios que requieren respuesta

Algunos protocolos de nube, como los de estilo JSON-RPC, exigen una respuesta con el resultado de ejecución. Edge-EMS Builder permite definir en la suscripción:

• responseTopic: topic de respuesta; un script puede construirlo dinámicamente a partir de campos como id del mensaje original.
• response: contenido de respuesta, que puede utilizar ${subscribe_result} para indicar si la acción tuvo éxito y ${subscribe_result_message} para detallar el resultado.

Así, la nube puede saber si la estrategia ya se aplicó en el borde, sin asumir éxito por el mero hecho de haberla enviado.

5. Ejemplo de bucle completo

La nube envía una estrategia por franjas horarias → la acción de suscripción MQTT analiza el mensaje → escribe datos Customization con vigencia por intervalos → los disparadores o la interfaz ejecutan posteriormente esa estrategia → el borde devuelve periódicamente los resultados según la configuración de publicación.

Es uno de los patrones más habituales de coordinación entre nube y borde. La distribución de estrategias y el envío de resultados se configuran de forma independiente; cualquiera de los dos puede ajustarse sin afectar al otro.

6. Reenvío tras recuperar la conexión

Si una tarea de publicación falla por una pérdida temporal de conectividad, Edge-EMS Builder almacena automáticamente los mensajes fallidos en una cola de tamaño configurable y los retransmite cuando se recupera la red, evitando perder datos importantes por fluctuaciones de conexión.

El diagrama representa el flujo de datos y control según la lógica de configuración de esta página. Consulta los campos concretos en las configuraciones y scripts del texto.

Siguientes pasos

• Parámetros completos y formatos de solicitudes y respuestas: Manual de scripts de publicación y suscripción MQTT.
• Coordinación directa entre dispositivos: Coordinación entre dispositivos y objetivos compartidos.
• Envío en tiempo real a una interfaz propia: Actualizaciones en tiempo real y control directo desde la interfaz.