KI und IoT: Der komplette Leitfaden zu AIoT, von Edge-Modellen bis zu LLM-Agenten

KI und IoT ergänzen sich: IoT-Geräte erzeugen kontinuierliche Datenströme über die physische Welt, und KI macht daraus Erkennungen, Prognosen und Entscheidungen. Dieser Leitfaden erklärt, wo KI-Modelle laufen sollten, wie Daten und Befehle zwischen Geräten und Modellen fließen und wie Sie mit MQTT einen Echtzeit-Anomaliedetektor und einen sicheren Befehlspfad für KI-Agenten aufbauen.

Was AIoT bedeutet

AIoT, kurz für Artificial Intelligence of Things (Künstliche Intelligenz der Dinge), beschreibt Systeme, in denen vernetzte Geräte und maschinelles Lernen als ein Kreislauf zusammenarbeiten. Sensoren messen, Modelle interpretieren, und die Ergebnisse lösen Aktionen aus: einen Alarm, ein Wartungsticket, einen geänderten Sollwert oder ein angehaltenes Förderband.

Keine der beiden Hälften ist im großen Maßstab allein sehr nützlich. Tausende Sensoren erzeugen mehr Daten, als Menschen beobachten können, sodass ohne Analytics das meiste nie angesehen wird. Und ein Modell ohne Live-Daten ist nur ein Bericht über die Vergangenheit. Die Kombination ermöglicht es:

• Erkennen: ungewöhnliches Verhalten feststellen, während es passiert, statt es in einer monatlichen Auswertung zu entdecken.
• Vorhersagen: Ausfälle, Bedarf oder Energieverbrauch früh genug prognostizieren, um handeln zu können.
• Identifizieren: Objekte, Personen und Defekte in Kamera- und Audioströmen erkennen.
• Erklären und interagieren: Menschen Fragen zu ihren Anlagen in natürlicher Sprache stellen lassen.

Der schwierige Teil ist selten das Modell. Es geht darum, saubere, kontextualisierte Daten zuverlässig zum Modell zu bringen und die Ausgabe des Modells an die richtige Stelle zurückzuführen. Das ist ein Architekturproblem, und darauf konzentriert sich dieser Leitfaden.

Wo KI läuft: Gerät, Edge oder Cloud

Die erste Designentscheidung in jedem Projekt mit KI und IoT ist, wo die Inferenz stattfindet. Jeder Ort hat klare Stärken.

In der Praxis nutzen die meisten Systeme alle drei. Ein Gerät filtert und komprimiert, ein Edge-Knoten führt das zeitkritische Modell aus, und die Cloud trainiert Modelle und analysiert die Flotte. Der Vergleich Edge AI vs. Cloud AI hilft Ihnen, von Fall zu Fall zu entscheiden, und was ist Edge AI sowie was ist TinyML erklären die Edge-Optionen im Detail.

Eine nützliche Regel: Verlagern Sie die Berechnung so nah an den Sensor, wie es das Modell zulässt, und senden Sie nur, was nachgelagerte Systeme brauchen. Ein Beschleunigungssensor mit mehreren Kilohertz Abtastrate erzeugt viel zu viele Daten für ein kontinuierliches Streaming, aber ein Mikrocontroller kann jede Sekunde RMS, Spitzenwert und einige Frequenzbänder berechnen und diese Merkmale in einer kleinen JSON-Nachricht veröffentlichen. Wenn Sie On-Device-Inferenz selbst ausprobieren möchten, führt TinyML auf dem ESP32 durch ein vollständiges Beispiel, und der Vergleich von Edge-AI-Hardware hilft Ihnen bei der Wahl eines Gateways, wenn das Modell einem Mikrocontroller entwächst.

MQTT als Daten- und Befehlskanal für KI und IoT

Wie auch immer die Aufteilung aussieht: Geräte, Edge-Knoten und Cloud-Services müssen Daten austauschen. MQTT passt hervorragend zu dieser Rolle:

• Entkopplung. Ein Modell abonniert die Topics, die es braucht. Ein zweites Modell hinzuzufügen oder eines zu ersetzen, berührt die Geräte nicht.
• Bidirektional. Derselbe Broker transportiert Telemetrie nach oben und Befehle oder Modellergebnisse nach unten.
• Effizient. Kleine Header und persistente Verbindungen passen zu eingeschränkten Geräten und Mobilfunkverbindungen.
• Ergebnisse als Daten. Ein Modell veröffentlicht seine Ausgaben, etwa einen Anomalie-Score oder ein erkanntes Objekt, als neue Topics, die Dashboards, Alarmierung und andere Modelle konsumieren können.

Ein typisches Topic-Layout trennt Rohdaten, Modellausgaben und Befehle:

plant1/line2/pump3/telemetry          raw sensor readings (JSON)
plant1/line2/pump3/ai/anomaly         model output: score, label, model version
plant1/line2/pump3/ai/forecast        predicted values
plant1/line2/pump3/command/set        validated commands to the device

Modellausgaben auf eigenen Topics zu veröffentlichen ist ein unterschätztes Muster. Es macht KI-Ergebnisse wie jedes andere Signal beobachtbar, was wichtig ist, wenn jemand fragt, warum ein Alarm ausgelöst wurde. Außerdem können Sie so zwei Modellversionen parallel betreiben und vergleichen.

Bedenken Sie, dass der Broker Daten transportiert; er führt keine Modelle aus. ConnectMQ ist ein verwalteter MQTT-Broker ohne integrierte KI-Funktionen, und das ist das ehrliche, modulare Muster: Ihre Modelle laufen in Python-Services, auf Edge-Geräten oder ML-Plattformen, die sich als gewöhnliche MQTT-Clients mit dem Broker verbinden.

IoT-Daten für KI vorbereiten

Modelle sind nur so gut wie die Daten, die sie sehen, und rohe IoT-Daten sind unordentlich. Stellen Sie vor jedem Training und jeder Inferenz sicher, dass jeder Datenstrom einige Grundstandards erfüllt. Wer das früh richtig macht, spart sich später Wochen an Bereinigung.

Zeitstempel an der Quelle. Versehen Sie jeden Messwert dort mit einem Zeitstempel, wo er gemessen wird, nicht dort, wo er empfangen wird. Netzwerkverzögerungen, Wiederholungen und Edge-Pufferung bringen Nachrichten durcheinander, und ein Modell, das die Ankunftszeit nutzt, lernt Muster, die in Wahrheit Netzwerkartefakte sind. Synchronisieren Sie Geräteuhren per NTP und nehmen Sie den Zeitstempel in den Payload auf.

Explizite Einheiten und Anlagenkontext. Ein Wert von 71.2 sagt einem Modell in sechs Monaten nichts. Legen Sie Einheiten in den Payload oder in ein dokumentiertes Schema und sorgen Sie dafür, dass der Topic-Pfad die Anlage eindeutig identifiziert. Ein hierarchischer Namespace aus Standort, Bereich, Linie und Anlage ermöglicht es, Daten beim Aufbau von Trainingsdatensätzen nach Maschinentyp oder Ort zu gruppieren. In Industrie-4.0-Projekten ist das meist ein Unified Namespace (UNS), dessen Ebenen der ISA-95-Anlagenhierarchie folgen, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur; MES, Historian und KI-Dienste greifen dann auf dieselben Adressen zu. Wie Sparkplug-B-Geräte in diese Struktur passen, zeigt Sparkplug B und Unified Namespace.

Konsistente Abtastung. Viele Modelle setzen regelmäßige Intervalle voraus. Legen Sie fest, ob Geräte periodisch, bei Änderung oder beides melden, und dokumentieren Sie es. Wenn Geräte bei Änderung melden, hilft ein periodischer Heartbeat mit dem aktuellen Wert, „keine Änderung“ von „keine Daten“ zu unterscheiden.

Betriebskontext. Eine Pumpe, die beim Anlauf hohen Strom zieht, ist normal; derselbe Strom im stationären Betrieb nicht. Veröffentlichen Sie Maschinenzustand, Produkttyp oder Chargen-ID zusammen mit den Sensorwerten, damit Modelle diese berücksichtigen können.

Labels und Ereignisse. Überwachte Modelle brauchen Beispiele für die Ergebnisse, die Sie interessieren. Erfassen Sie Wartungseinsätze, Bedienernotizen und bestätigte Fehler als zeitgestempelte Ereignisse auf eigenen Topics, damit sie später mit der Sensorhistorie verknüpft werden können. Der Leitfaden zum Labeln von Sensor-Zeitreihendaten behandelt praxistaugliche Workflows.

Sie können die gesamte Datenpipeline auf einem öffentlichen MQTT-Broker, der für Tests und Prototypen und nicht für Produktionsdaten gedacht ist, mit simulierten Werten proben, bevor Sie echte Anlagen anbinden, genau das tut das folgende Praxisbeispiel.

Zentrale AIoT-Anwendungsfälle

Anomalieerkennung

Die Anomalieerkennung markiert Messwerte oder Muster, die vom Normalverhalten abweichen: ein Lager, das heißer läuft als üblich, ein ungewöhnliches Vibrationsspektrum, ein Energieprofil, das sich über Nacht ändert. Sie ist das häufigste erste KI-Projekt, weil sie keine gelabelten Ausfalldaten benötigt. Die Methoden reichen von gleitenden Statistiken bis zu Isolation Forests und Autoencodern. Beginnen Sie mit dem Leitfaden zur IoT-Anomalieerkennung.

Vorausschauende Wartung

Die vorausschauende Wartung schätzt, wann eine Anlage ausfallen wird, damit Wartung geplant werden kann. Sie braucht Historie, idealerweise einschließlich Ausfällen, und guten Kontext zu den Betriebsbedingungen. Der Artikel vorausschauende Wartung mit maschinellem Lernen behandelt Merkmale, Modelle und die Daten, die Sie zuerst sammeln müssen.

Prognosen

Prognosen sagen zukünftige Werte wie Energielast, Tankfüllstände oder Produktionsbedarf voraus. Klassische Zeitreihenmethoden schneiden oft gut ab und sind leichter zu erklären als Deep-Learning-Modelle.

Computer Vision

Kameras mit Objekterkennungsmodellen zählen Teile, prüfen auf Defekte, erkennen Personen in Sperrbereichen oder lesen Messinstrumente ab. Vision läuft meist an der Edge, weil das Streamen von Video in die Cloud teuer ist, und nur die Erkennungen wandern über MQTT, wie in YOLO-Objekterkennung mit MQTT gezeigt.

LLM-Agenten und natürlichsprachliche Schnittstellen

Große Sprachmodelle können Sensordaten zusammenfassen, Fragen zu Anlagen beantworten und per Tool Calling mit Geräten interagieren. Das ist mächtig und zugleich der Bereich, in dem Fehler physische Folgen haben. Der Leitfaden zu LLM-Agenten für IoT-Geräte behandelt die Architektur, und der folgende Abschnitt zeigt die Sicherheitsschicht, die zwischen einem Agenten und echter Hardware sitzen muss.

Praxis: Anomalieerkennung in Echtzeit über MQTT

Dieses Beispiel baut einen Streaming-Anomaliedetektor in Python. Ein Simulator veröffentlicht Vibrationswerte mit gelegentlichen Fehlern, und ein Detektor abonniert sie, bewertet jeden Messwert mit einem gleitenden Z-Score und veröffentlicht Anomalieereignisse auf einem separaten Topic. Beide laufen gegen den kostenlosen öffentlichen MQTT-Broker broker.connectmq.com, der anonyme Clients mit einer eindeutigen, nicht leeren Client ID akzeptiert. Daten dort sind für jeden lesbar, verwenden Sie also nur simulierte Werte.

pip install "paho-mqtt>=2.0"

Der Sensorsimulator

# sensor_sim.py
import json
import random
import sys
import time

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]  # beliebige kurze eindeutige Zeichenkette, z. B. a7f3k2
TOPIC = f"connectmq/demo/{RUN_ID}/line2/pump3/telemetry"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"pump3-sim-{RUN_ID}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

while True:
    vibration = random.gauss(2.0, 0.15)  # normale RMS-Schwinggeschwindigkeit in mm/s
    if random.random() < 0.03:
        vibration += random.uniform(1.0, 2.5)  # eingespeiste Fehlerspitze
    payload = {"ts": int(time.time() * 1000), "vibrationMmS": round(vibration, 3)}
    client.publish(TOPIC, json.dumps(payload), qos=0)
    time.sleep(0.5)

Der Streaming-Detektor

# detector.py
import json
import math
import sys
from collections import deque

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]
BASE = f"connectmq/demo/{RUN_ID}/line2/pump3"
WINDOW, THRESHOLD, MODEL_VERSION = 120, 4.0, "zscore-v1"
history = deque(maxlen=WINDOW)


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{BASE}/telemetry", qos=0)
    print("detector listening:", reason_code)


def on_message(client, userdata, msg):
    reading = json.loads(msg.payload)
    value = reading["vibrationMmS"]

    if len(history) >= 30:  # auf eine minimale Baseline warten
        mean = sum(history) / len(history)
        std = math.sqrt(sum((x - mean) ** 2 for x in history) / len(history)) or 1e-6
        score = (value - mean) / std
        if abs(score) > THRESHOLD:
            event = {
                "ts": reading["ts"],
                "value": value,
                "score": round(score, 2),
                "baselineMean": round(mean, 3),
                "model": MODEL_VERSION,
            }
            client.publish(f"{BASE}/ai/anomaly", json.dumps(event), qos=1)
            print("ANOMALY", event)
            return  # Anomalien aus der Baseline heraushalten

    history.append(value)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"detector-{RUN_ID}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Führen Sie python sensor_sim.py a7f3k2 in einem Terminal und python detector.py a7f3k2 in einem anderen aus und ersetzen Sie a7f3k2 durch Ihre eigene zufällige Zeichenkette. Beobachten Sie die Ergebnisse mit:

mosquitto_sub -h broker.connectmq.com -p 1883 -i viewer-a7f3k2 -t "connectmq/demo/a7f3k2/line2/pump3/ai/#" -v

Drei Details machen daraus mehr als ein Spielzeug. Anomale Werte werden aus der Baseline ausgeschlossen, damit ein Fehler dem Detektor nicht beibringt, dass Fehler normal sind. Jedes Ereignis trägt die Modellversion, sodass Sie erkennen, welcher Detektor es erzeugt hat. Und die Ausgabe ist ein normales MQTT-Topic, sodass ein Dashboard, ein Alarmierungsdienst oder ein Wartungssystem es abonnieren kann, ohne den Detektor zu ändern. Eine Version mit Isolation Forest über mehrere Merkmale finden Sie in Echtzeit-Anomalieerkennung in Python.

KI-Agenten sicher auf Geräte einwirken lassen

Wenn ein LLM-Agent oder irgendein Modell Befehle an physische Anlagen sendet, ist die wichtigste Komponente nicht das Modell. Es ist das Tor zwischen Modell und Gerät. Lassen Sie ein Modell niemals direkt auf Befehls-Topics veröffentlichen. Leiten Sie seine Vorschläge stattdessen über einen Validator, der eine Allowlist, Grenzwerte und Ratenbegrenzungen durchsetzt:

# command_gate.py - prüft von der KI vorgeschlagene Befehle, bevor sie Geräte erreichen
import json
import time
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/a7f3k2"
POLICY = {
    "line2/pump3": {"setpointRpm": (800, 1600)},
    "line2/fan1": {"speedPct": (0, 80)},
}
MIN_INTERVAL_S = 10
last_sent = {}


def validate(proposal):
    asset, param, value = proposal["asset"], proposal["param"], proposal["value"]
    if asset not in POLICY or param not in POLICY[asset]:
        return f"{asset}/{param} is not on the allowlist"
    lo, hi = POLICY[asset][param]
    if not isinstance(value, (int, float)) or not lo <= value <= hi:
        return f"value {value} outside [{lo}, {hi}]"
    if time.time() - last_sent.get(asset, 0) < MIN_INTERVAL_S:
        return "rate limit: too many commands for this asset"
    return None


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/ai/proposals", qos=1)


def on_message(client, userdata, msg):
    try:
        proposal = json.loads(msg.payload)
        error = validate(proposal)
    except (ValueError, KeyError) as exc:
        proposal, error = {"raw": msg.payload.decode(errors="replace")}, f"malformed: {exc}"
    audit = {"ts": int(time.time() * 1000), "proposal": proposal, "accepted": error is None, "reason": error}
    client.publish(f"{PREFIX}/ai/audit", json.dumps(audit), qos=1)
    if error is None:
        topic = f"{PREFIX}/{proposal['asset']}/command/set"
        client.publish(topic, json.dumps({proposal["param"]: proposal["value"]}), qos=1)
        last_sent[proposal["asset"]] = time.time()


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"gate-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Der Agent, welches LLM oder Framework er auch nutzt, veröffentlicht Vorschläge wie {"asset": "line2/pump3", "param": "setpointRpm", "value": 1450} auf ai/proposals. Nur das Tor veröffentlicht auf Befehls-Topics der Geräte, und jede Entscheidung wird in ein Audit-Topic geschrieben. Im Produktivbetrieb läuft das Tor mit eigenen Broker-Zugangsdaten, und Geräte akzeptieren nur Befehle von ihm. Sicherheitsfunktionen gehören weiterhin in die SPS oder Steuerung, wo keine darüberliegende Software sie übersteuern kann. Sichere KI-Steuerung von IoT-Geräten erweitert dies um menschliche Freigabeschritte, und einen MCP-Server für MQTT bauen zeigt, wie Sie einem Agenten Lese- und Befehlswerkzeuge strukturiert bereitstellen.

Eine Roadmap für AIoT-Projekte

1. Definieren Sie die Entscheidung. Was ändert sich, wenn das Modell ein Ergebnis liefert? Wenn nichts, hören Sie hier auf.
2. Daten sammeln und kontextualisieren. Konsistente Topics, Einheiten, Zeitstempel und Anlagenmetadaten. Die meisten KI-Projekte scheitern an der Datenqualität, nicht an Algorithmen.
3. Eine Baseline etablieren mit einfachen Regeln oder Statistiken. Sie zeigt Ihnen, ob ein komplexes Modell überhaupt etwas beiträgt.
4. Den Inferenzort wählen anhand von Latenz, Bandbreite und Konnektivität.
5. Modellausgaben als Topics veröffentlichen, mit Modellversion und Konfidenz.
6. Den Kreislauf vorsichtig schließen: zuerst Alarme, dann Empfehlungen, automatisierte Befehle zuletzt und nur über ein Validierungstor.
7. Überwachen und neu trainieren. Sensoren driften, Prozesse ändern sich, und Modelle verschlechtern sich. Der IoT-MLOps-Leitfaden behandelt Versionierung, Monitoring und erneutes Ausrollen.

Typische Stolperfallen

• Training mit nicht repräsentativen Daten. Ein im Sommer trainiertes Modell markiert womöglich jeden Wintermorgen als Anomalie.
• Fehlende Daten ignorieren. Ein Sensor, der verstummt, ist selbst ein Signal. Nutzen Sie Status-Topics mit Last Will, damit Modelle Lücken nicht für stabile Messwerte halten.
• Black-Box-Alarme. Bediener ignorieren Alarme, die sie nicht verstehen. Nehmen Sie Wert, Baseline und Grund in jedes Ereignis auf.
• LLMs zu sehr vertrauen. Sprachmodelle können plausible, aber falsche Befehle erzeugen. Prüfen Sie alles, was sie vorschlagen, gegen harte Grenzen.
• Alles in die Cloud senden. Hochfrequente Vibrationsdaten oder Video sollten an der Edge verarbeitet werden, wobei nur Merkmale oder Erkennungen nach oben gesendet werden.

Treiben Sie Ihre AIoT-Pipeline mit ConnectMQ an

Ihre Modelle brauchen einen verlässlichen Datenstrom hinein und einen kontrollierten Kanal für Ergebnisse und Befehle hinaus. Erstellen Sie unter app.connectmq.com ein kostenloses Konto im Serverless-Plan, ganz ohne Kreditkarte, und verbinden Sie dann Geräte, Detektoren und Agenten mit den generierten Zugangsdaten über TLS auf Port 8883. ConnectMQ unterstützt MQTT 3.1.1 und 5.0, und kostenpflichtige Pläne ergänzen Shared Subscriptions, sodass sich mehrere Detektor-Instanzen die Last eines Telemetriestroms teilen können. Für mehr Verbindungen oder eine isolierte Umgebung vergleichen Sie die Pläne für einen Cloud-MQTT-Broker.

Häufig gestellte Fragen

Was ist der Unterschied zwischen KI und IoT?

IoT ist das Netzwerk vernetzter Geräte, die in der physischen Welt messen und handeln, während KI die Gesamtheit der Verfahren ist, die Muster aus Daten lernen und Vorhersagen treffen. AIoT kombiniert beides, sodass Gerätedaten Modelle speisen und Modellausgaben Aktionen auslösen.

Sollte KI an der Edge oder in der Cloud laufen?

Führen Sie zeitkritische und bandbreitenintensive Inferenz wie Vision oder hochfrequente Vibrationsanalyse an der Edge aus. Nutzen Sie die Cloud für Training, flottenweite Analytics, Prognosen und große Sprachmodelle. Die meisten Systeme kombinieren beides.

Enthält ConnectMQ KI- oder Machine-Learning-Funktionen?

Nein. ConnectMQ ist die MQTT-Messaging-Schicht. Ihre Modelle laufen in Ihren eigenen Services, auf Edge-Geräten oder ML-Plattformen, die sich als MQTT-Clients mit ConnectMQ verbinden, um Daten zu empfangen und Ergebnisse zu veröffentlichen.

Kann ein LLM IoT-Geräte direkt steuern?

Das sollte es nicht. Leiten Sie die vorgeschlagenen Befehle eines Agenten über ein Validierungstor, das Allowlists, Wertgrenzen und Ratenbegrenzungen durchsetzt, ein Audit-Protokoll führt und als einziger Client auf Befehls-Topics der Geräte veröffentlichen darf.

Was ist das einfachste erste Projekt mit KI und IoT?

Echtzeit-Anomalieerkennung auf einem bestehenden Sensordatenstrom, weil sie keine gelabelten Ausfalldaten benötigt. Eine gleitende statistische Baseline wie im Beispiel dieses Leitfadens reicht oft aus, um nützliche Alarme zu liefern.