Capacité principale : coordination cloud-edge MQTT

Le canal MQTT porte la coordination cloud-edge d’Edge-EMS Builder : il remonte au cloud les données et décisions de la périphérie, et reçoit les stratégies cloud pour les appliquer automatiquement à la configuration locale. Cette coordination est une capacité de base des trois catégories de produit, sans option avancée payante ni développement spécifique supplémentaire.

1. Configuration de connexion

Une configuration MQTT décrit la connexion à un broker :

Paramètre	Description
protocol	mqtt / mqtts, selon l’activation de TLS
protocolVersion	3.1 / 3.1.1 / 5.0 pris en charge
serverHost / serverPort	Adresse et port du broker
clientId / username / password	Identifiant client et authentification
cleanSession / keepAliveInterval / connectTimeout	Paramètres de session et de connexion

Un équipement Edge-EMS Builder peut configurer plusieurs connexions MQTT simultanément, par exemple vers une plateforme cloud et une passerelle locale. Chaque configuration de publication ou d’abonnement est liée à une connexion précise.

2. Publication : assembler les données edge dans le format voulu pour le cloud

La configuration de publication définit la fréquence, le topic destinataire et le contenu :

Paramètre	Description
topic / qos	Destination de publication et niveau de qualité de service
uploadStrategy	Expression CRON définissant la période de publication
publishContent	Script Lua renvoyant le contenu du message à publier

publishContent utilise la même syntaxe que le moteur d’expressions et permet de construire toute structure JSON :

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

-- Les champs de tableau sont également pris en charge
payload.phaseVoltages = { ${Meter1_Ua}, ${Meter1_Ub}, ${Meter1_Uc} }

return payload

Le moteur sérialise automatiquement la table Lua retournée en JSON et la publie sur le topic spécifié. Le cloud reçoit un message JSON standard :

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

3. Abonnement : convertir les commandes cloud en écritures locales

La configuration d’abonnement définit le topic, le traitement des messages et la nécessité d’un accusé de réception :

Paramètre	Description
topic / qos	Topic d’abonnement et qualité de service
actionContent	Script Lua analysant le message reçu et renvoyant une liste d’instructions d’écriture
needResponse / responseTopic / response	Réponse requise, topic et contenu de réponse, également construisibles par script

Après réception, le script accède au message brut via ${subscribe_message}, l’analyse et le convertit en instructions d’écriture :

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

Ce script convertit la stratégie horaire envoyée par le cloud, un JSON comportant plusieurs plages avec chacune une valeur de mode, en instructions d’écriture de données par plage horaire (Customization). Le cloud envoie un seul JSON au format convenu ; la périphérie applique automatiquement les valeurs selon l’horaire, sans développement supplémentaire.

4. Cas nécessitant une réponse

Certains protocoles cloud, par exemple de style JSON-RPC, exigent une réponse indiquant le résultat d’exécution. Edge-EMS Builder permet de définir dans l’abonnement :

• responseTopic : topic de réponse ; un script peut extraire id ou d’autres champs du message d’origine pour le construire dynamiquement.
• response : contenu de réponse, pouvant utiliser ${subscribe_result} pour la réussite de l’action et ${subscribe_result_message} pour le résultat détaillé.

Le cloud peut ainsi savoir précisément si la stratégie est active en périphérie, au lieu de considérer le simple envoi comme une réussite.

5. Exemple de boucle complète

Stratégie horaire envoyée par le cloud → analyse du message par l’action d’abonnement MQTT → écriture des données par plage horaire → exécution ultérieure par un plan de déclenchement ou l’interface → retour périodique des résultats au cloud selon la configuration de publication.

Ce mode courant de coordination configure séparément envoi des stratégies et remontée des résultats, sans couplage. L’un peut être ajusté sans affecter l’autre.

6. Reprise après déconnexion

Lorsqu’une tâche de publication échoue parce que l’équipement est temporairement déconnecté, Edge-EMS Builder met automatiquement les messages en cache, dans une file de taille configurable, et les retransmet au rétablissement du réseau pour éviter la perte de données importantes lors de perturbations.

Ce schéma représente le flux de données et de contrôle selon la configuration décrite ici. Référez-vous aux configurations et scripts pour les champs exacts.

Étapes suivantes

• Paramètres complets et formats requête/réponse : Manuel des scripts MQTT.
• Coordination directe entre équipements : Coordination et cibles de partage.
• Diffusion des données en temps réel vers votre propre interface : Diffusion temps réel et contrôle direct.