IoT-Automatisierung: Wohnungen, Gebäude, Landwirtschaft und Energie mit MQTT automatisieren

IoT-Automatisierung bedeutet, Sensoren, Regeln und Aktoren die Routineentscheidungen in einem physischen Raum zu überlassen, vom Ausschalten des Lichts in einem leeren Büro bis zum Öffnen eines Bewässerungsventils, wenn der Boden trocken ist. Dieser Leitfaden liefert Ihnen eine Architektur, die für Wohnungen, Gebäude, landwirtschaftliche Betriebe und Energiesysteme funktioniert, zeigt funktionierende Automatisierungen mit Home Assistant und Python über MQTT und erklärt, wie Sie das Ganze zuverlässig und sicher halten.

Was IoT-Automatisierung ist und warum MQTT im Zentrum steht

Jede Automatisierung folgt, so komplex sie auch ist, demselben Kreislauf: erfassen, entscheiden, handeln, bestätigen. Ein Sensor misst etwas, eine Regel entscheidet, ob gehandelt werden muss, ein Aktor erledigt die Arbeit, und eine Zustandsmeldung bestätigt, dass es geschehen ist.

Klassische Automatisierungssysteme bildeten diesen Kreislauf in der Steuerung eines einzelnen Herstellers ab. Das funktioniert, bis ein Zigbee-Bewegungsmelder ein WLAN-Relais steuern soll oder die Leistung eines Solarwechselrichters bestimmen soll, wann ein Warmwasserbereiter läuft. IoT-Automatisierung zerlegt den Kreislauf in unabhängige Teile, die über eine gemeinsame Messaging-Schicht kommunizieren, und diese Schicht ist fast immer MQTT.

MQTT passt, weil:

• Publish/Subscribe Geräte von der Logik entkoppelt. Ein Sensor veröffentlicht einmal; beliebig viele Regeln, Dashboards und Logger können abonnieren.
• es schlank genug für Mikrocontroller ist wie ESP32 und ESP8266 und nativ von Tasmota, ESPHome, Zigbee2MQTT, Shelly-Geräten und Home Assistant unterstützt wird.
• Retained Messages einer neu gestarteten Rule Engine sofort den aktuellen Zustand jedes Geräts mitteilen.
• Last-Will-Nachrichten melden, wenn ein Gerät offline geht, sodass Automatisierungen in einen sicheren Zustand wechseln können.

Wenn der Broker für Sie neu ist, beginnen Sie mit was ein MQTT-Broker leistet und kehren Sie dann hierher zurück.

Die vierschichtige Architektur der IoT-Automatisierung

Dieselbe Struktur gilt, ob Sie eine Wohnung, ein Bürogebäude mit 20 Stockwerken oder ein Gewächshaus automatisieren.

Die Trennung dieser Schichten macht das System wartbar. Sie können einen Zigbee-Sensor durch einen WLAN-Sensor ersetzen oder Regeln von Home Assistant nach Node-RED verschieben, ohne den Rest neu zu verdrahten, solange die Topics gleich bleiben.

Lokaler Broker, Cloud-Broker oder beides?

Ein Broker auf einem lokalen Raspberry Pi hält Automatisierungen am Laufen, wenn das Internet ausfällt, was für Licht und Heizung wichtig ist. Ein Cloud-Broker macht Geräte von überall erreichbar, verbindet Standorte, die nicht im selben Netz liegen (ein Hof mit mehreren Feldern, ein Unternehmen mit mehreren Gebäuden), und nimmt Ihnen das Patchen und Sichern eines Brokers ab. Viele Installationen kombinieren beides: Zeitkritische Regeln laufen lokal, während Monitoring, Fernsteuerung und standortübergreifende Koordination über einen Cloud-MQTT-Broker laufen. Das Tutorial Home Assistant mit einem externen MQTT-Broker führt durch dieses Setup.

Topic-Design für Automatisierung

Klare Topic-Namen machen Regeln lesbar und verhindern versehentliches Übersprechen zwischen Geräten. Ein praxistaugliches Layout:

<site>/<area>/<device>/<channel>
<site>/<area>/<device>/<channel>/set      (commands)

home/livingroom/thermostat/temperature
home/livingroom/thermostat/setpoint/set
office/floor3/zone-b/occupancy
farm/greenhouse1/soil/moisture
farm/greenhouse1/valve/state
energy/house/solar/power

Faustregeln, die Stunden an Debugging sparen:

1. Trennen Sie Zustands-Topics (was das Gerät meldet) von Befehls-Topics (was es tun soll), typischerweise mit dem Suffix /set.
2. Veröffentlichen Sie Zustände als Retained, damit Dashboards und Rule Engines sie nach einem Neustart sofort sehen.
3. Verwenden Sie JSON-Payloads mit Einheiten und Zeitstempeln, wenn ein Gerät mehrere Werte meldet.
4. Geben Sie jedem Gerät ein status-Topic mit einem Last Will offline.

Der Leitfaden zur MQTT-Topic-Struktur im Smart Home geht tiefer, einschließlich des Umgangs mit Gruppen und Szenen. In Fabriken wird dasselbe Prinzip zum Unified Namespace (UNS): Dort folgen die Ebenen der ISA-95-Hierarchie aus Unternehmen, Standort, Bereich, Linie und Zelle, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur.

IoT-Automatisierung nach Umgebung

Die Architektur bleibt gleich, aber jede Umgebung hat eigene Prioritäten.

Wohnungen und Häuser

Die Hausautomation ist der ausgereifteste Bereich. Home Assistant ist die übliche Logikschicht, wobei MQTT Geräte aus vielen Ökosystemen verbindet: Zigbee-Sensoren über Zigbee2MQTT, mit Tasmota geflashte WLAN-Steckdosen und eigene ESP32-Boards, gebaut mit ESPHome. Typische Automatisierungen sind anwesenheitsbasierte Beleuchtung, Heizpläne, Leckagewarnungen und Benachrichtigungen. Eine häufige Stolperfalle ist es, sich bei Dingen, die offline funktionieren müssen, etwa einem Lichtschalter, auf die Cloud zu verlassen; halten Sie diese lokal.

Gewerbegebäude

Die Gebäudeautomation konzentriert sich auf HLK, Beleuchtung, Belegung und Luftqualität, meist über viele Zonen hinweg. Bestehende Systeme sprechen BACnet, KNX oder Modbus, und Gateways übersetzen sie in MQTT, damit neuere Anwendungen die Daten nutzen können, ohne die Gebäudeleittechnik anzufassen. Lesen Sie Gebäudeautomation mit MQTT für die Architektur und BACnet zu MQTT für den Gateway-Schritt. Belegungsgesteuerte HLK und Beleuchtung sind die klassischen schnellen Erfolge, weil leere Räume leicht zu erkennen sind.

Landwirtschaft und Gewächshäuser

Die landwirtschaftliche Automatisierung hat mit großen Entfernungen, rauen Bedingungen und batteriebetriebenen Sensoren zu tun. Bodenfeuchte, Lufttemperatur, Luftfeuchtigkeit und Wasserstände steuern Bewässerung, Lüftung und Beschattung. Auf dem Feld ist LoRaWAN verbreitet, wobei Netzwerkserver wie The Things Network Uplinks über MQTT weiterleiten, wie in The Things Network und MQTT beschrieben. Ein Cloud-Broker ist hier besonders nützlich, weil Felder und Gewächshäuser selten ein lokales Netz teilen. Der Leitfaden zu Smart Agriculture mit IoT und das Tutorial zur Gewächshausautomatisierung behandeln die Details.

Energie

Die Energieautomatisierung bringt Erzeugung, Speicherung und Verbrauch ins Gleichgewicht: einen Warmwasserbereiter bei hoher Solarleistung laufen lassen, ein E-Auto außerhalb der Spitzenzeiten laden oder unkritische Lasten abwerfen. Wechselrichter, Batterien und Smart Meter stellen oft Modbus oder lokale APIs bereit, die kleine Bridges an MQTT veröffentlichen. Konkrete Umsetzungen zeigen Energiemonitoring zu Hause mit MQTT und Überwachung von Solarwechselrichtern.

Praxis: Eine Bewässerungsautomatisierung nach Bodenfeuchte

Bauen wir einen vollständigen Kreislauf aus Erfassen, Entscheiden und Handeln. Ein Gerät veröffentlicht die Bodenfeuchte, Home Assistant entscheidet, wann bewässert wird, und ein Ventil meldet seinen Zustand. Sie können alles auf dem kostenlosen öffentlichen MQTT-Broker broker.connectmq.com testen, bevor Sie echte Hardware anschließen. Wählen Sie ein eindeutiges Präfix wie connectmq/demo/k7x2p9 und verwenden Sie es überall unten; der öffentliche Bereich ist für jeden lesbar, dorthin gehören also nur Testdaten.

Schritt 1: Sensor und Ventil über die Kommandozeile simulieren

Veröffentlichen Sie einen Retained-Feuchtewert:

mosquitto_pub -h broker.connectmq.com -p 1883 -i soil-k7x2p9 \
  -t "connectmq/demo/k7x2p9/greenhouse1/soil" -r \
  -m '{"moisture": 42.5, "tempC": 19.8}'

Beobachten Sie in einem zweiten Terminal alles unter dem Präfix:

mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-k7x2p9 \
  -t "connectmq/demo/k7x2p9/#" -v

Schritt 2: Die Entitäten in Home Assistant definieren

Fügen Sie in Home Assistant die MQTT-Integration hinzu (Einstellungen, Geräte & Dienste, Integration hinzufügen, MQTT) mit dem Broker broker.connectmq.com, Port 1883 und einer eindeutigen Client-ID zum Testen. Deklarieren Sie dann Sensor und Ventil in configuration.yaml:

mqtt:
  sensor:
    - name: "Greenhouse Soil Moisture"
      unique_id: greenhouse1_soil_moisture
      state_topic: "connectmq/demo/k7x2p9/greenhouse1/soil"
      unit_of_measurement: "%"
      value_template: "{{ value_json.moisture }}"
  switch:
    - name: "Greenhouse Valve"
      unique_id: greenhouse1_valve
      command_topic: "connectmq/demo/k7x2p9/greenhouse1/valve/set"
      state_topic: "connectmq/demo/k7x2p9/greenhouse1/valve/state"
      payload_on: "ON"
      payload_off: "OFF"
      retain: false

Schritt 3: Die Automatisierungsregel schreiben

automation:
  - alias: "Irrigate greenhouse when soil is dry"
    mode: single
    triggers:
      - trigger: numeric_state
        entity_id: sensor.greenhouse_soil_moisture
        below: 30
        for: "00:05:00"
    conditions:
      - condition: time
        after: "06:00:00"
        before: "20:00:00"
    actions:
      - action: switch.turn_on
        target:
          entity_id: switch.greenhouse_valve
      - delay: "00:10:00"
      - action: switch.turn_off
        target:
          entity_id: switch.greenhouse_valve

Die for-Klausel ignoriert kurze Einbrüche durch Sensorrauschen, die Zeitbedingung verhindert nächtliches Bewässern, und die feste Verzögerung garantiert, dass das Ventil schließt, selbst wenn keine Feuchtewerte mehr ankommen. Veröffentlichen Sie einen Feuchtewert von 25 und lassen Sie ihn fünf Minuten stehen; im mosquitto_sub-Fenster erscheint dann ON auf dem Topic valve/set, zehn Minuten später gefolgt von OFF. Eine echte Ventilsteuerung würde valve/set abonnieren und ihre tatsächliche Stellung auf valve/state veröffentlichen.

Dieselbe Regel ohne Home Assistant

Nicht jeder Standort betreibt Home Assistant. Node-RED (siehe das Node-RED MQTT Tutorial) oder ein kleiner Python-Service kann dieselbe Logik ausführen. Diese Version nutzt paho-mqtt 2.x und ergänzt eine Hysterese, damit das Ventil nicht um den Schwellenwert herum flattert:

import json
import threading
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/k7x2p9/greenhouse1"
DRY, WET, MAX_RUN_S = 30.0, 45.0, 600
valve_on = False
timer = None


def set_valve(client, on):
    global valve_on, timer
    valve_on = on
    client.publish(f"{PREFIX}/valve/set", "ON" if on else "OFF", qos=1)
    if timer:
        timer.cancel()
    if on:  # Sicherheit: nie länger als MAX_RUN_S laufen lassen
        timer = threading.Timer(MAX_RUN_S, set_valve, args=(client, False))
        timer.start()
    print("valve", "ON" if on else "OFF")


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


def on_message(client, userdata, msg):
    moisture = json.loads(msg.payload)["moisture"]
    if not valve_on and moisture < DRY:
        set_valve(client, True)
    elif valve_on and moisture > WET:
        set_valve(client, False)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"irrigation-{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()

Checkliste für das Design von IoT-Automatisierungen

Gehen Sie diese Liste durch, bevor Sie einer Automatisierung etwas Wichtiges anvertrauen:

1. Sicherer Zustand bei Ausfall. Legen Sie fest, was jeder Aktor tun soll, wenn Rule Engine, Broker oder Sensor verschwinden. Ventile schließen, Heizungen schalten ab, Türen bleiben verriegelt.
2. Entprellung und Hysterese. Nutzen Sie Zeitfenster oder getrennte Ein- und Ausschaltschwellen, damit Rauschen kein schnelles Hin- und Herschalten verursacht.
3. Zustand bestätigen. Steuern Sie ein Gerät über /set, aber speisen Sie Dashboards und Folgeregeln aus seinem gemeldeten state.
4. Offline-Geräte behandeln. Abonnieren Sie die status-Topics mit Last Will und alarmieren Sie, wenn ein kritischer Sensor verstummt.
5. Manuelle Übersteuerung erhalten. Menschen müssen die Automatisierung vor Ort übersteuern können, und Regeln sollten das respektieren.
6. QoS bewusst wählen. QoS 1 für Befehle und Alarme, QoS 0 für häufige Messwerte. Der Artikel zu MQTT QoS-Stufen erklärt, warum.
7. Absichern. Verwenden Sie TLS, eindeutige Zugangsdaten pro Gerät oder Gateway und stellen Sie niemals einen Broker ohne Authentifizierung bereit. Die Checkliste MQTT Security Best Practices gilt hier direkt.
8. Entscheidungen protokollieren. Veröffentlichen Sie auf einem Log-Topic, was die Regel getan hat und warum, damit Sie „Warum ging die Heizung um drei Uhr nachts an?“ debuggen können.

Automatisierungen langfristig testen und pflegen

Eine Automatisierung, die am ersten Tag funktioniert, kann Monate später unbemerkt ausfallen: Eine Sensorbatterie ist leer, ein Firmware-Update benennt eine Entität um, oder ein Gerät bekommt eine neue IP-Adresse und verbindet sich nie wieder. Behandeln Sie Automatisierungen wie jede andere Software, auf die Sie sich verlassen.

Testen Sie Regeln zunächst mit simulierten Nachrichten, bevor sie echte Aktoren berühren. Einen künstlich niedrigen Feuchtewert oder ein künstliches Belegungsereignis über die Kommandozeile zu veröffentlichen, ist der schnellste Weg zu sehen, ob eine Regel auslöst, und kostet nichts. Halten Sie für jede wichtige Regel eine kurze Liste solcher Testnachrichten bereit, damit Sie sie nach Updates wiederholen können.

Überwachen Sie als Nächstes den Zustand der Eingänge, nicht nur der Ausgänge. Eine Heizungsregel, die auf einem Temperatursensor beruht, ist nur so gut wie dessen letzte Meldung. Verfolgen Sie die Zeit seit der letzten Veröffentlichung jedes kritischen Geräts und lösen Sie einen Alarm aus, wenn sie einige Meldeintervalle überschreitet. Retained-status-Topics mit Last Will machen das einfach, weil sich ein abgestürztes Gerät selbst meldet.

Überprüfen Sie Automatisierungen schließlich einige Male im Jahr. Entfernen Sie Regeln, an deren Erstellung sich niemand erinnert, prüfen Sie, ob Schwellenwerte noch zur Jahreszeit oder Kultur passen, und stellen Sie sicher, dass manuelle Übersteuerungen weiterhin funktionieren. Ein kleiner, gut verstandener Regelsatz ist wertvoller als ein großer, dem niemand vertraut.

Typische Stolperfallen

• Regeln über viele Tools verteilt. Liegt ein Teil der Logik in der Firmware einer Steckdose, ein Teil in Home Assistant und ein Teil in Node-RED, kann niemand das Verhalten vorhersagen. Wählen Sie eine primäre Rule Engine.
• Retained-Befehle. Ein retained ON auf einem Befehls-Topic schaltet das Gerät bei jedem Reconnect erneut ein. Speichern Sie Zustände als retained, nicht Befehle.
• Geteilte Client-IDs. Zwei Clients mit derselben ID werfen sich in einer Schleife gegenseitig vom Broker. Machen Sie jede ID eindeutig.
• Kritische Pfade nur über die Cloud. Halten Sie sicherheits- und komfortkritische Regeln lokal und nutzen Sie die Cloud für Monitoring und Fernzugriff.
• Protokollwahl ignorieren. Matter, Zigbee und WLAN haben jeweils Vor- und Nachteile; Matter vs. MQTT erklärt, wie sie koexistieren können.

IoT-Automatisierung mit ConnectMQ über Standorte hinweg skalieren

Sobald Sie mehr als einen Standort haben oder Fernzugriff ohne geöffnete Ports am Router brauchen, wird ein verwalteter MQTT-Broker zum einfachsten Knotenpunkt. ConnectMQ bietet jedem Standort denselben Endpunkt über TLS auf Port 8883 oder Secure WebSocket auf Port 8084 für Browser-Dashboards, sodass sich Home-Assistant-Instanzen, Node-RED-Flows, Gateways und Geräte an verschiedenen Orten auf einem Broker treffen. Der Live-Topic-Explorer im Portal hilft Ihnen zu prüfen, was Geräte tatsächlich veröffentlichen, und Schwellenwert-Alarmregeln mit Alarmprotokoll können Sie warnen, wenn ein Messwert eine Grenze überschreitet. Die Automatisierungslogik selbst bleibt in Home Assistant, Node-RED oder Ihrem eigenen Service, die als gewöhnliche MQTT-Clients verbunden sind.

Der kostenlose Serverless-Plan unterstützt bis zu 25 Verbindungen, was eine typische Wohnung oder ein kleines Gewächshaus bequem abdeckt. Größere Gebäude und standortübergreifende Installationen können auf den kostenpflichtigen Serverless-Plan mit bis zu 1.000 Verbindungen oder auf einen Dedicated-Cluster wechseln. Vergleichen Sie die Optionen in der Übersicht zum verwalteten MQTT-Broker.

Starten Sie mit ConnectMQ

Entwickeln Sie Ihre Automatisierungen als Prototyp auf dem öffentlichen MQTT-Broker, der für Tests und Prototypen gedacht ist, und wechseln Sie zu einem privaten Broker, sobald echte Geräte live gehen. Registrieren Sie sich unter app.connectmq.com im kostenlosen Serverless-Plan, ganz ohne Kreditkarte, erstellen Sie einen Broker und kopieren Sie den generierten Benutzernamen, das Passwort und die Client-ID in Home Assistant, Node-RED oder Ihre Geräte. Stellen Sie den Port auf 8883 mit TLS um, und Ihre Regeln funktionieren unverändert weiter.

Häufig gestellte Fragen

Brauche ich Home Assistant für IoT-Automatisierung?

Nein. Home Assistant ist die häufigste Logikschicht für Wohnungen, aber Node-RED, openHAB oder ein kleiner Python- oder Node.js-Service, der mit demselben MQTT-Broker verbunden ist, kann identische Regeln ausführen. Broker und Topics bleiben gleich, egal wofür Sie sich entscheiden.

Sollte mein Automatisierungs-Broker lokal oder in der Cloud laufen?

Führen Sie zeit- und sicherheitskritische Regeln lokal aus, damit sie auch bei Internetausfällen funktionieren. Nutzen Sie einen Cloud-Broker für Fernzugriff, standortübergreifende Setups und Monitoring, oder kombinieren Sie beides mit lokalen Regeln und Transparenz über die Cloud.

Führt ConnectMQ meine Automatisierungsregeln aus?

Nein. ConnectMQ ist der Messaging-Knotenpunkt und bietet Schwellenwert-Alarmregeln für das Monitoring, aber die Automatisierungslogik läuft in Tools wie Home Assistant, Node-RED oder Ihren eigenen Services, die sich als MQTT-Clients mit dem Broker verbinden.

Warum schaltet sich mein Gerät bei jedem Reconnect ein?

Wahrscheinlich haben Sie den Befehl mit dem Retain-Flag veröffentlicht. Der Broker speichert Retained Messages und liefert sie an jeden neuen Subscriber aus; speichern Sie also Zustands-Topics als retained, aber niemals Befehls-Topics.

Kann ich IoT-Automatisierung ohne Hardware testen?

Ja. Simulieren Sie Sensoren mit mosquitto_pub gegen broker.connectmq.com, mit eindeutiger Client-ID und eindeutigem Topic-Präfix, und beobachten Sie die resultierenden Befehle mit mosquitto_sub, bevor Sie echte Geräte anschließen.