Kernfunktion: Cloud-Edge-Koordination mit MQTT

Der MQTT-Kanal trägt die Cloud-Edge-Koordination von Edge-EMS Builder: Er meldet Echtzeitdaten und Entscheidungsergebnisse des Edge an die Cloud und empfängt Cloudstrategien, die automatisch in lokale Konfiguration überführt werden. Cloud-Edge-Koordination ist eine Grundfunktion aller drei Produktstufen und keine separat zu bezahlende oder individuell zu entwickelnde Zusatzoption.

1. Verbindungskonfiguration

Eine MQTT-Verbindungskonfiguration beschreibt den Zugang zu einem Broker:

Parameter	Beschreibung
protocol	mqtt / mqtts (TLS deaktiviert/aktiviert)
protocolVersion	Unterstützt 3.1 / 3.1.1 / 5.0
serverHost / serverPort	Brokeradresse und Port
clientId / username / password	Clientkennung und Authentifizierungsdaten
cleanSession / keepAliveInterval / connectTimeout	Sitzungs- und Verbindungsparameter

Ein Edge-EMS Builder-Gerät kann mehrere MQTT-Verbindungen gleichzeitig konfigurieren, etwa zu einer Cloudplattform und einem lokalen Gateway. Veröffentlichungs- und Abonnementkonfigurationen werden jeweils einer konkreten Verbindung zugeordnet.

2. Veröffentlichung: Edge-Daten in beliebigem Format an die Cloud senden

Die Veröffentlichungskonfiguration legt Intervall, Ziel-Topic und Nachrichteninhalt fest:

Parameter	Beschreibung
topic / qos	Veröffentlichungsziel und Dienstgütestufe
uploadStrategy	CRON-Ausdruck zur Steuerung des Veröffentlichungsintervalls
publishContent	Lua-Skript, das den Inhalt der aktuellen Veröffentlichung zurückgibt

Das Skript publishContent verwendet dieselbe Syntax wie die Ausdrucksengine und kann beliebige JSON-Strukturen zusammenstellen:

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

-- Array-Felder werden ebenfalls unterstützt
payload.phaseVoltages = { ${Meter1_Ua}, ${Meter1_Ub}, ${Meter1_Uc} }

return payload

Die Engine serialisiert die zurückgegebene Lua-Tabelle automatisch als JSON und veröffentlicht sie auf dem angegebenen Topic. Die Cloud erhält eine standardkonforme JSON-Nachricht:

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

3. Abonnements: Cloudbefehle in lokale Schreibaktionen umwandeln

Die Abonnementkonfiguration bestimmt Topic, Nachrichtenverarbeitung und gegebenenfalls eine Antwort:

Parameter	Beschreibung
topic / qos	Abonniertes Topic und Dienstgütestufe
actionContent	Lua-Skript, das eingehende Nachrichten verarbeitet und eine Liste von Schreibbefehlen zurückgibt
needResponse / responseTopic / response	Antwort erforderlich, Antwort-Topic und Antwortinhalt; ebenfalls per Skript zusammenstellbar

Nach Eingang einer abonnierten Nachricht kann das Skript die Originalnachricht über die feste Variable ${subscribe_message} lesen, auswerten und in Schreibbefehle umwandeln:

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

Dieses Skript übersetzt eine von der Cloud gesendete Zeitstrategie – JSON mit mehreren Zeitfenstern und jeweils einem Moduswert – in mehrere Schreibbefehle für Zeitplandaten (Customization). Die Cloud sendet einmal JSON im vereinbarten Format; am Edge werden die Werte automatisch zeitabhängig wirksam, ohne zusätzliche Entwicklung.

4. Szenarien mit erforderlicher Antwort

Manche Cloudprotokolle, etwa im JSON-RPC-Stil, verlangen nach einer Nachricht eine Antwort mit dem Ausführungsergebnis. Edge-EMS Builder unterstützt dazu in der Abonnementkonfiguration:

• responseTopic: Ziel-Topic der Antwort; das Skript kann beispielsweise id aus der Originalnachricht extrahieren und das Topic dynamisch bilden.
• response: Antwortinhalt; kann die festen Variablen ${subscribe_result} für den Ausführungserfolg und ${subscribe_result_message} für das detaillierte Ergebnis verwenden.

So kann die Cloud nach der Strategieverteilung erkennen, ob die Strategie am Edge wirksam wurde, statt allein das Senden als Erfolg zu werten.

5. Typischer geschlossener Ablauf

Cloud verteilt Zeitstrategie → MQTT-Abonnementaktion verarbeitet die Nachricht → Zeitplandaten werden geschrieben und zeitabhängig wirksam → Triggerschema oder Frontend führt die Strategie aus → Edge meldet Ergebnisse regelmäßig gemäß Veröffentlichungskonfiguration an die Cloud

Dies ist ein häufiges Cloud-Edge-Muster: Strategieverteilung und Ergebnismeldung werden unabhängig konfiguriert. Beide Seiten können separat angepasst werden, ohne die andere zu beeinflussen.

6. Übertragung nach Netzunterbrechung fortsetzen

Schlägt eine Veröffentlichung wegen vorübergehend fehlender Netzwerkverbindung fehl, puffert Edge-EMS Builder die Nachricht automatisch. Die Warteschlangengröße ist konfigurierbar. Nach Wiederherstellung der Verbindung werden Nachrichten automatisch erneut gesendet, um den Verlust wichtiger Meldedaten durch Netzschwankungen zu vermeiden.

Diese Abbildung basiert auf der Konfigurationslogik dieser Seite und zeigt Daten- und Steuerungsabläufe. Konkrete Felder entnehmen Sie den beschriebenen Konfigurationen und Skripten.

Nächste Schritte

• Vollständige Parameter und Anfrage-/Antwortformate: Handbuch für MQTT-Publish-/Subscribe-Skripte
• Direkte Koordination zwischen Geräten statt zwischen Gerät und Cloud: Gerätekoordination und Freigabeziele
• Echtzeitdaten können auch an ein eigenes Frontend gesendet werden: Echtzeitübertragung und direkte Steuerung für Frontends