Recurso principal: colaboração entre nuvem e borda por MQTT

O canal MQTT implementa a colaboração entre nuvem e borda do Edge-EMS Builder: envia dados em tempo real e resultados de decisões da borda para a nuvem e recebe estratégias da nuvem para convertê-las automaticamente em configurações locais. A colaboração entre nuvem e borda é um recurso básico das três modalidades de produto, não uma opção avançada que exige pagamento ou desenvolvimento personalizado separado.

I. Configuração da conexão

Uma configuração de conexão MQTT descreve como acessar um Broker:

Parâmetro	Descrição
protocol	mqtt / mqtts (define o uso de TLS)
protocolVersion	Suporta 3.1 / 3.1.1 / 5.0
serverHost / serverPort	Endereço e porta do Broker
clientId / username / password	Identificador do cliente e informações de autenticação
cleanSession / keepAliveInterval / connectTimeout	Parâmetros de sessão e conexão

Um dispositivo Edge-EMS Builder pode manter várias conexões MQTT simultâneas, por exemplo, com uma plataforma de nuvem e um gateway local. Cada configuração de publicação/assinatura é vinculada a uma conexão específica.

II. Publicação: montar dados da borda em qualquer formato para envio à nuvem

A configuração de publicação descreve “com que frequência enviar, para qual Topic e com qual conteúdo”:

Parâmetro	Descrição
topic / qos	Destino da publicação e nível de qualidade de serviço
uploadStrategy	Expressão CRON que controla a periodicidade da publicação
publishContent	Script Lua que retorna o conteúdo da mensagem a publicar

O script publishContent usa a mesma sintaxe do mecanismo de expressões e permite montar livremente estruturas JSON:

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

-- Campos de array também são suportados
payload.phaseVoltages = { ${Meter1_Ua}, ${Meter1_Ub}, ${Meter1_Uc} }

return payload

O mecanismo serializa automaticamente a Lua Table retornada em JSON e a publica no Topic especificado. A nuvem recebe uma mensagem JSON padrão:

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

III. Assinatura: converter comandos da nuvem em ações de gravação locais

A configuração de assinatura descreve “qual Topic assinar, como tratar as mensagens recebidas e se é necessária uma resposta”:

Parâmetro	Descrição
topic / qos	Topic assinado e nível de qualidade de serviço
actionContent	Script Lua que interpreta a mensagem recebida e retorna uma lista de comandos de gravação
needResponse / responseTopic / response	Necessidade de resposta, Topic de resposta e conteúdo da resposta (também montável por script)

Após receber uma mensagem em um tópico assinado, o script acessa a mensagem original pela variável fixa ${subscribe_message}, interpreta-a e a converte em comandos de gravação:

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

Esse script interpreta a “estratégia por faixa de horário” enviada pela nuvem — um JSON com vários períodos, cada um com um valor de modo — e a converte em comandos de gravação de dados por faixa de horário (Customization). Basta que a nuvem envie uma vez o JSON no formato acordado para que a borda o aplique automaticamente por período, sem desenvolvimento adicional.

IV. Cenários que exigem resposta

Alguns protocolos de nuvem, como os de estilo JSON-RPC, exigem uma resposta com o resultado da execução após o envio de uma mensagem. O Edge-EMS Builder permite definir simultaneamente na configuração de assinatura:

• responseTopic: Topic para envio da resposta; o script pode extrair campos como id da mensagem original para montá-lo dinamicamente;
• response: conteúdo da resposta, que pode referenciar as variáveis fixas ${subscribe_result} (sucesso da execução da ação) e ${subscribe_result_message} (resultado detalhado).

Assim, após enviar uma estratégia, a nuvem pode confirmar se ela entrou em vigor na borda, em vez de presumir sucesso apenas pelo envio.

V. Exemplo típico de malha fechada

A nuvem envia uma estratégia por faixa de horário → a ação de assinatura MQTT interpreta a mensagem → grava dados por faixa de horário, válidos por período → perfis de acionamento ou o frontend passam a executar a estratégia → a borda retorna periodicamente os resultados à nuvem conforme a configuração de publicação.

Esse é um dos modos mais comuns de colaboração entre nuvem e borda: envio de estratégias e reporte de resultados são configurados de forma independente e desacoplada, permitindo ajustar um lado sem afetar o outro.

VI. Retomada após desconexão

Quando uma tarefa de publicação falha porque o dispositivo está temporariamente sem conexão, o Edge-EMS Builder armazena automaticamente as mensagens não publicadas em cache, com tamanho de fila configurável, e as retransmite após a recuperação da rede para evitar perda de dados importantes por instabilidade de conexão.

Este diagrama foi elaborado a partir da lógica de configuração desta página e mostra os fluxos de dados e controle. Para os campos específicos, consulte as configurações e os scripts no texto.

Próximos passos

• Parâmetros completos dos scripts de publicação/assinatura e formatos de solicitações e respostas: Manual de scripts de publicação/assinatura MQTT.
• Para entender a colaboração direta entre dispositivos, em vez de entre dispositivo e nuvem: Colaboração entre dispositivos e destinos de compartilhamento.
• Além da nuvem, o Edge-EMS Builder pode enviar dados em tempo real à sua própria interface: Envio em tempo real ao frontend e controle direto.