Das Veröffentlichen per Kepware MQTT ist einer der schnellsten Wege, Daten aus einem Werk voller unterschiedlicher SPSen in die Cloud zu bringen: Kepware beherrscht die Treiber bereits, und die IoT-Gateway-Funktion setzt einen MQTT-Client obendrauf. In diesem Tutorial konfigurieren Sie den Kepware MQTT Client Agent so, dass er Tags per TLS an einen Cloud-Broker sendet, wählen und gestalten die JSON-Payload, fügen einen Last Will hinzu, prüfen die Daten und teilen die gebündelten Nachrichten des Agents optional in einen sauberen Topic-Baum mit einem Topic pro Tag auf.
So funktioniert der Kepware MQTT Agent
Kepware (KEPServerEX und sein Nachfolger Kepware Server) ist ein industrieller Konnektivitätsserver mit Treibern für Hunderte von SPS- und Geräteprotokollen. Sein IoT-Gateway-Plug-in ergänzt Agents, die Tag-Daten an externe Systeme übertragen. Der MQTT Client Agent ist einer davon: Er verbindet sich als gewöhnlicher MQTT-Client mit einem Broker und veröffentlicht Tag-Werte als JSON.
Das Modell ist einfach:
- Channels und Devices pollen Ihre SPSen über Kepware-Treiber, so wie sie es bereits für SCADA tun.
- Ein MQTT Client Agent hält die Broker-Verbindung, die Publish-Einstellungen und das Payload-Format.
- IoT Items sind die Tags, die Sie diesem Agent hinzufügen, jeweils mit eigener Scan-Rate und eigenem Änderungsverhalten.
- In jedem Publish-Zyklus sendet der Agent eine JSON-Nachricht mit den fälligen Werten an sein Topic.
Da der Agent eine ausgehende Verbindung aufbaut, müssen Sie keine eingehenden Ports zum Kepware-Rechner öffnen. Das ist ein wesentlicher Grund, warum dieses Muster so beliebt ist, um OT-Daten zu einem Cloud-MQTT-Broker zu bringen. Genaue Bezeichnungen und Standardwerte unterscheiden sich leicht zwischen Kepware-Versionen. Verstehen Sie die folgenden Feldnamen daher als Orientierung und prüfen Sie die Hilfedatei Ihrer Version, wenn etwas anders aussieht.
Bevor Sie beginnen
- Kepware mit lizenzierter und installierter IoT-Gateway-Funktion.
- Mindestens ein Channel und Device, das bereits Tags mit guter Qualität liefert. Prüfen Sie das zuerst im Quick Client.
- Verbindungsdaten des Brokers. Für einen ersten Test nutzen Sie den öffentlichen MQTT-Broker ausschließlich mit unkritischen Tags; er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten. Für den Produktivbetrieb erstellen Sie einen privaten Broker und notieren Benutzername, Passwort und Client-ID.
- Ausgehender Zugriff vom Kepware-Host auf TCP 8883 (TLS) des Brokers.
Schritt 1: Den MQTT Client Agent anlegen
Klappen Sie im Kepware-Konfigurationstool IoT Gateway auf, fügen Sie per Rechtsklick einen neuen Agent hinzu und wählen Sie MQTT Client als Typ. Der Assistent fragt die Grundeinstellungen ab:
| Einstellung | Wert für ConnectMQ | Hinweise |
|---|---|---|
| Name | ConnectMQ_Cloud |
Beliebiger beschreibender Name |
| URL | ssl://broker.connectmq.com:8883 |
ssl:// für TLS verwenden; tcp://...:1883 nur für schnelle öffentliche Tests |
| Topic | connectmq/demo/k7q2/plant1/kepware |
Im Produktivbetrieb Ihre eigene Hierarchie verwenden, etwa acme/plant1/kepware |
| QoS | 1 | Der kostenlose Serverless-Plan unterstützt QoS 0 und 1; QoS 2 erfordert einen kostenpflichtigen Plan |
| Rate | 1000 ms | Wie oft der Agent ausstehende Aktualisierungen veröffentlicht |
| Format | Standard (JSON) | Später auf Advanced umstellen, um die Payload anzupassen |
| Max events per publish | Standard | Begrenzt, wie viele Tag-Aktualisierungen in eine Nachricht passen |
Öffnen Sie anschließend die Sicherheits- bzw. Client-Einstellungen des Agents und tragen Sie ein:
- Client-ID: für den öffentlichen MQTT-Broker einen beliebigen eindeutigen, nicht leeren Wert wie
kepware-k7q2. Für einen privaten Broker exakt die mit Ihren Zugangsdaten ausgegebene Client-ID; Client-IDs sind an diese Zugangsdaten gebunden. - Benutzername und Passwort: leer für den öffentlichen MQTT-Broker;
YOUR_USERNAMEundYOUR_PASSWORDfür einen privaten. - TLS-Version: TLS 1.2 oder neuer.
Der Broker präsentiert ein öffentlich vertrauenswürdiges Let's-Encrypt-Zertifikat, daher müssen Sie normalerweise kein CA-Zertifikat importieren. Wenn Ihr Unternehmen TLS-Verkehr über einen Proxy prüft, muss der Kepware-Host stattdessen dem Zertifikat dieses Proxys vertrauen.
Schritt 2: Einen Last Will hinzufügen
Konfigurieren Sie den Last Will des Agents, damit Konsumenten erkennen, wenn Kepware verschwindet:
- Topic:
connectmq/demo/k7q2/plant1/kepware/status - Nachricht:
offline
Bricht die Verbindung des Agents unerwartet ab, veröffentlicht der Broker diese Nachricht in seinem Namen. Kombinieren Sie das mit einer Dashboard-Regel, die Werte ausgraut, sobald der Status offline lautet.
Schritt 3: IoT Items hinzufügen
Fügen Sie per Rechtsklick auf den Agent IoT Items hinzu und navigieren Sie zu den gewünschten Tags. Legen Sie für jedes Item fest:
- Scan-Rate: wie oft Kepware den Tag für diesen Agent abtastet. Passen Sie sie daran an, wie schnell sich der Wert tatsächlich ändert; ein bis fünf Sekunden passen für die meisten Prozesswerte.
- Bei jedem Scan oder bei Datenänderung veröffentlichen: Bevorzugen Sie Datenänderung für Zustände und langsame Analogwerte. Das ist Kepwares eingebautes Report by Exception, erklärt in unserem Leitfaden zu Report by Exception.
- Totband: Bei verrauschten Analogwerten unterdrückt ein Totband Änderungen unterhalb eines Schwellwerts.
Beginnen Sie mit wenigen Tags, bestätigen Sie den durchgängigen Datenfluss und fügen Sie dann den Rest hinzu.
Schritt 4: Die Daten prüfen
Abonnieren Sie von einem beliebigen Rechner mit dem Mosquitto-Client:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i kepware-viewer-k7q2 -t "connectmq/demo/k7q2/#" -v
Im Standard-Format sieht jede Nachricht auf dem Agent-Topic so aus:
{
"timestamp": 1792137600000,
"values": [
{ "id": "Line1.Filler.Speed", "v": 118.4, "q": true, "t": 1792137599950 },
{ "id": "Line1.Filler.Running", "v": true, "q": true, "t": 1792137599950 },
{ "id": "Line1.Filler.GoodCount", "v": 48211, "q": true, "t": 1792137599950 }
]
}
id ist der vollständige Kepware-Tag-Pfad, v der Wert, q gibt an, ob die Qualität gut ist, und t ist der Zeitstempel des Tags in Millisekunden seit der Epoche. Bei einem privaten ConnectMQ-Broker zeigen der MQTT-Client im Browser und der Live-Topic-Explorer des Portals dieselben Nachrichten, ohne dass Sie etwas installieren müssen.
Schritt 5: Die Payload mit einem Advanced-Template gestalten
Mit dem Advanced-Format schreiben Sie ein Template mit Platzhaltern, die Kepware ausfüllt. Ein Template, das die Felder für nachgelagerten Code verständlicher benennt, sieht so aus:
{
"source": "kepware-plant1",
"sent": |SERVERTIMESTAMP|,
"tags": [
|#each VALUES|
{ "name": "|TAGNAME|", "value": |VALUE|, "good": |QUALITY|, "ts": |TIMESTAMP| }|#unless @last|,|/unless|
|/each|
]
}
Das Template muss für jede Wertekombination gültiges JSON ergeben, auch wenn sich nur ein Tag geändert hat. Testen Sie es, indem Sie die Nachrichten beobachten, während Sie Tags im SPS-Simulator oder im Quick Client umschalten.
Schritt 6: Auf einen Topic-Baum pro Tag verteilen
Der Agent veröffentlicht Batches auf ein Topic. Das ist effizient, doch viele Konsumenten bevorzugen ein Topic pro Wert in einer ISA-95-Hierarchie, die einen Unified Namespace (UNS) erst navigierbar macht. Die ISA-95-Ebenen Enterprise → Site → Area → Line → Cell werden dabei zu Topic-Ebenen, sodass aus einem Kepware-Tag einer Siemens-S7-Steuerung etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur wird und MES, Historian und Analysewerkzeuge jeden Wert an einer festen Adresse finden. Mehr zu diesem Muster lesen Sie in Sparkplug B und Unified Namespace. Ein kleiner Republisher übernimmt die Aufteilung. Er läuft überall, verbindet sich als normaler Client mit dem Broker und bildet Kepware-Tag-Pfade auf Topics ab:
# kepware_fanout.py - Kepware-Batches im Standard-Format in Topics pro Tag aufteilen
import json, uuid
import paho.mqtt.client as mqtt
ROOT = "connectmq/demo/k7q2/plant1"
SOURCE = f"{ROOT}/kepware"
def to_topic(tag_id: str) -> str:
# "Line1.Filler.Speed" -> "connectmq/demo/k7q2/plant1/line1/filler/speed"
return f"{ROOT}/" + "/".join(part.lower() for part in tag_id.split("."))
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(SOURCE, qos=1)
def on_message(client, userdata, message):
batch = json.loads(message.payload)
for item in batch.get("values", []):
payload = {"value": item["v"], "quality": "good" if item["q"] else "bad", "ts": item["t"]}
client.publish(to_topic(item["id"]), json.dumps(payload), qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"kep-fanout-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.tls_set()
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD") # privater Broker
client.connect("broker.connectmq.com", 8883, keepalive=30)
client.loop_forever()
Aus jedem Kepware-Batch werden mehrere Retained Messages pro Tag. Das Limit des öffentlichen MQTT-Brokers von zehn Nachrichten pro Sekunde und Client gilt also für den Fan-out-Client; halten Sie die Test-Tag-Liste klein. Bei einem privaten Broker richten sich die Limits nach Ihrem Plan. Unser Artikel zu ISA-95-MQTT-Topics hilft Ihnen beim Entwurf der Zielhierarchie, und ConnectMQ erkennt ISA-95-strukturierte Topics in der Geräteansicht automatisch.
Fehlerbehebung beim Kepware MQTT Agent
| Symptom im Kepware-Ereignisprotokoll oder Verhalten | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Agent kann sich nicht verbinden, Verbindung abgelehnt | Falsches URL-Schema oder falscher Port | ssl:// mit 8883, tcp:// mit 1883 |
| TLS-Handshake-Fehler | TLS-Inspection-Proxy, alte TLS-Version | Proxy-CA vertrauen, TLS 1.2+ wählen |
| Not authorized | Falscher Benutzername, falsches Passwort oder falsche Client-ID | Alle drei aus dem Broker-Portal kopieren |
| Verbindet sich und trennt sich wiederholt | Zwei Clients mit derselben Client-ID | Jedem Agent und Test-Client eine eindeutige ID geben |
Nachrichten kommen an, aber q ist false |
Kommunikationsproblem mit dem Gerät in Kepware | Channel oder Device reparieren, Quick Client prüfen |
| Nachrichten als zu groß abgelehnt | Zu viele Tags pro Publish | Max events per publish senken oder auf mehrere Agents aufteilen |
| Topic auf dem öffentlichen MQTT-Broker abgelehnt | Mehr als acht Topic-Ebenen | Topic kürzen |
Checkliste für den Produktivbetrieb
- Privater Broker mit TLS auf 8883 und Zugangsdaten aus dem Portal.
- Eindeutige Client-ID pro Agent, niemals mit Test-Tools geteilt.
- Last Will konfiguriert und überwacht.
- Veröffentlichen bei Datenänderung und Totbänder für analoge Tags.
- Nachrichtengröße innerhalb des Limits Ihres Plans: 256 KB im kostenlosen Serverless-Plan, 1 MB im kostenpflichtigen Serverless-Plan.
- Firewall des Kepware-Hosts: nur ausgehend 8883.
- Ein Runbook für die Rotation von Zertifikaten oder Zugangsdaten.
Das Gesamtbild, wo Kepware zwischen SPSen, Gateways und Konsumenten steht, zeigt der Leitfaden zu Industrial IoT mit MQTT. Wenn Sie Kepware mit einem eigenen Gateway vergleichen, zeigt unser Tutorial zum OPC-UA-zu-MQTT-Gateway die Open-Source-Alternative.
Starten Sie mit ConnectMQ
Geben Sie Ihrem Kepware-Server in wenigen Minuten ein Cloud-Ziel. Registrieren Sie sich unter app.connectmq.com, wählen Sie den kostenlosen Serverless-Plan ohne Kreditkarte, erstellen Sie einen Broker und kopieren Sie den generierten Benutzernamen, das Passwort und die Client-ID in den MQTT Client Agent. ConnectMQ ist ein verwalteter MQTT-Broker, Sie müssen also keinen Server patchen, und Schwellwert-Alarmregeln im Portal können Ihre Tags überwachen, sobald sie eintreffen.
Häufig gestellte Fragen
Unterstützt Kepware MQTT über TLS?
Ja. Verwenden Sie im MQTT Client Agent eine ssl://-URL mit Port 8883 und wählen Sie eine aktuelle TLS-Version. Broker mit öffentlich vertrauenswürdigen Zertifikaten erfordern normalerweise keinen zusätzlichen Zertifikatsimport.
Kann Kepware jeden Tag auf ein eigenes MQTT-Topic veröffentlichen?
Der MQTT Client Agent veröffentlicht Batches auf das Topic des Agents, und die Optionen für Topics pro Tag hängen von der Kepware-Version ab. Ein kleiner Fan-out-Client, der Batches in Topics pro Tag aufteilt, funktioniert mit jeder Version.
Welche QoS sollte der Kepware MQTT Agent verwenden?
QoS 1 ist ein guter Standard für Tag-Daten: Die Zustellung ist mindestens einmal garantiert, bei geringem Overhead. QoS 2 wird für Telemetrie selten benötigt.
Kann eine Cloud-Anwendung über Kepware MQTT Tags zurückschreiben?
Der Agent lässt sich so konfigurieren, dass er Schreibanfragen auf einem abonnierten Topic annimmt. Aktivieren Sie das jedoch nur mit strenger Zugriffskontrolle und bei klarem Bedarf. Die meisten Installationen halten den Cloud-Pfad rein lesend.
