Nutztierüberwachung mit IoT: Tiere, Tränken und Stallklima mit LoRaWAN und MQTT überwachen

IoT-Systeme zur Nutztierüberwachung geben Landwirten einen Blick auf Tiere, Wasser und Haltungsbedingungen, ohne dass sie jede Koppel zweimal am Tag abfahren müssen. In diesem Leitfaden entwerfen Sie ein vollständiges Setup: LoRaWAN-Halsbänder und -Sensoren auf der Weide, einen Netzwerkserver, der die Uplinks dekodiert, und einen MQTT-Broker, der diese Messwerte in einen Topic-Baum verwandelt, den Ihre Dashboards und Alarme nutzen können. Außerdem erhalten Sie eine funktionierende Python-Bridge und ein Alarmierungsmuster, das Sie noch heute auf einem kostenlosen öffentlichen MQTT-Broker testen können.

Was Nutztierüberwachung mit IoT tatsächlich misst

Die meisten Probleme in einer Herde zeigen sich zuerst als Veränderung einiger weniger einfacher Signale. Ein gutes System versucht nicht, alles zu messen; es misst die Handvoll Dinge, für die sonst jemand mit dem Quad rausfahren müsste.

Die Intervalle sind wichtig, weil fast alle diese Geräte mit Batterien und unter den Duty-Cycle-Grenzen von LoRaWAN laufen. Ein Halsband, das jede Minute meldet, leert seine Batterie schnell und überschreitet in vielen Regionen auch das, was das Netz tragen sollte. Planen Sie langsame, regelmäßige Uplinks plus ereignisgesteuerte Nachrichten, wenn sich etwas ändert.

Warum LoRaWAN auf der Weide und MQTT dahinter

Weiden sind groß und haben auf Bodenhöhe selten WLAN oder zuverlässigen Mobilfunk. LoRaWAN passt gut, weil ein Gateway auf einem Stalldach oder einem Mast eine große Fläche abdecken kann und Sensoren lange mit einer Batterie auskommen. Der Preis ist die Bandbreite: Payloads sind winzig, typischerweise ein Dutzend Byte gepackter Binärdaten.

LoRaWAN liefert Daten nicht direkt an Ihre Anwendung. Die Kette sieht so aus:

1. Das Halsband oder der Tränkensensor sendet einen Uplink per Funk.
2. Ein oder mehrere Gateways leiten ihn an einen LoRaWAN-Netzwerkserver weiter, etwa The Things Stack oder ChirpStack.
3. Der Netzwerkserver dekodiert die Payload mit einem Codec (einer kleinen JavaScript-Funktion) und veröffentlicht ein JSON-Ereignis.
4. Ihre Integration nimmt dieses Ereignis und stellt es Dashboards, Alarmen und Speicherung zur Verfügung.

Beide großen Netzwerkserver stellen Uplinks über MQTT bereit, doch ihre Topics sind netzwerkspezifisch und voller Funkmetadaten. Ein bewährtes Muster ist eine kleine Bridge, die den Netzwerkserver abonniert und eine saubere, auf den Hof ausgerichtete Nachricht an Ihren eigenen MQTT-Broker veröffentlicht. Alles Nachgelagerte (Dashboards, Home Assistant, Node-RED, eine mobile App) spricht dann mit einem stabilen Topic-Baum, der sich nicht ändert, wenn Sie den Netzwerkserver wechseln. Die Leitfäden zur The-Things-Network-MQTT-Integration und zu ChirpStack MQTT behandeln die Seite des Netzwerkservers im Detail.

Wenn das Konzept eines zentralen Nachrichtenknotens neu für Sie ist, lohnt es sich, vorher die kurze Erklärung zu lesen, was ein MQTT-Broker macht.

Den Topic-Baum entwerfen

Benennen Sie Topics nach dem Hof, nicht nach dem Funk. Ein Baum, der Standort, Bereich und Asset folgt, ist leicht zu lesen und leicht mit Wildcards zu abonnieren:

farm1/pasture-north/animals/cow-0412/position
farm1/pasture-north/animals/cow-0412/activity
farm1/pasture-north/troughs/trough-03/level
farm1/barn-a/climate/env-01/telemetry
farm1/barn-a/fence/energizer-1/voltage
farm1/status/bridge

Einige Regeln halten das wartbar:

• Stabile IDs verwenden (Ohrmarkennummer, Tränkennummer) in Topics, keine DevEUIs. Behalten Sie die DevEUI zur Fehlersuche in der Payload.
• Den letzten Messwert retained speichern für Tränken, Klima und Zaunspannung, damit ein Dashboard, das um 5 Uhr morgens geöffnet wird, sofort den aktuellen Zustand zeigt.
• Alarme nicht als Befehle retained speichern. Alarme sind Ereignisse; ein retained Alarm, der bei jedem Wiederverbinden erneut zugestellt wird, stiftet Verwirrung.
• Payloads als kleines JSON halten, mit einem Zeitstempel vom Netzwerkserver, denn entscheidend ist der Zeitpunkt des Uplinks, nicht der Zeitpunkt der Verarbeitung durch die Bridge.

Beispiel für eine Tränkennachricht:

{
  "ts": "2026-10-16T05:42:10Z",
  "level_pct": 18,
  "level_cm": 9.4,
  "battery_v": 3.52,
  "rssi": -112,
  "snr": -4.5,
  "dev_eui": "a84041000181c2f1"
}

Die Bridge bauen: vom Netzwerkserver zu MQTT

Die folgende Bridge abonniert Uplink-Ereignisse von ChirpStack v4, nimmt das dekodierte Feld object, ordnet jedes Gerät einem Hof-Topic zu und veröffentlicht es erneut. Für den ersten Test veröffentlicht sie in den öffentlichen Bereich von broker.connectmq.com, der kein Konto benötigt, aber für jeden lesbar ist; verwenden Sie also ein zufälliges Präfix und nur Testdaten.

Installieren Sie die Bibliothek:

pip install "paho-mqtt>=2.0"

import json
import time
import uuid
import paho.mqtt.client as mqtt

# ChirpStack v4 (lokal oder gehostet) - an Ihren Netzwerkserver anpassen
LNS_HOST = "chirpstack.local"
LNS_PORT = 1883
LNS_TOPIC = "application/+/device/+/event/up"

# Ziel-Broker - zuerst der öffentliche MQTT-Broker, später Zugangsdaten
DEST_HOST = "broker.connectmq.com"
DEST_PORT = 1883
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/farm1"

# DevEUI -> (Bereich, Art, Asset-ID)
DEVICES = {
    "a84041000181c2f1": ("pasture-north", "troughs", "trough-03"),
    "70b3d57ed005a1b2": ("pasture-north", "animals", "cow-0412"),
    "a84041000181d004": ("barn-a", "climate", "env-01"),
}

dest = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                   client_id=f"farm-bridge-{uuid.uuid4().hex[:6]}")
dest.will_set(f"{PREFIX}/status/bridge", "offline", qos=1, retain=True)
dest.connect(DEST_HOST, DEST_PORT, keepalive=60)
dest.loop_start()
dest.publish(f"{PREFIX}/status/bridge", "online", qos=1, retain=True)


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected to network server:", reason_code)
    client.subscribe(LNS_TOPIC, qos=1)


def on_message(client, userdata, msg):
    try:
        event = json.loads(msg.payload)
    except json.JSONDecodeError:
        return
    dev_eui = event.get("deviceInfo", {}).get("devEui", "").lower()
    if dev_eui not in DEVICES:
        print("Unknown device", dev_eui)
        return
    area, kind, asset = DEVICES[dev_eui]
    decoded = event.get("object") or {}
    rx = (event.get("rxInfo") or [{}])[0]

    out = dict(decoded)
    out["ts"] = event.get("time")
    out["dev_eui"] = dev_eui
    out["rssi"] = rx.get("rssi")
    out["snr"] = rx.get("snr")

    leaf = {"troughs": "level", "animals": "position",
            "climate": "telemetry"}.get(kind, "telemetry")
    topic = f"{PREFIX}/{area}/{kind}/{asset}/{leaf}"
    retain = kind != "animals"
    dest.publish(topic, json.dumps(out), qos=1, retain=retain)
    print("->", topic, out)


lns = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                  client_id=f"farm-lns-{uuid.uuid4().hex[:6]}")
lns.on_connect = on_connect
lns.on_message = on_message
lns.connect(LNS_HOST, LNS_PORT, keepalive=60)

print("Publishing under", PREFIX)
try:
    lns.loop_forever()
except KeyboardInterrupt:
    dest.publish(f"{PREFIX}/status/bridge", "offline", qos=1, retain=True)
    time.sleep(0.5)

Beobachten Sie das Ergebnis von einem beliebigen Rechner aus:

mosquitto_sub -h broker.connectmq.com -p 1883 -i farm-viewer-7731 -t "connectmq/demo/<your-id>/farm1/#" -v

Der öffentliche MQTT-Broker erlaubt 8 Topic-Ebenen, sodass connectmq/demo/<id>/farm1/pasture-north/troughs/trough-03/level mit genau 8 Ebenen das Maximum ist; für tiefere Bäume lassen Sie während der Tests die Ebene farm1 weg. Der Artikel zum öffentlichen MQTT-Broker listet die weiteren Limits auf.

Alarme, auf die Landwirte tatsächlich reagieren

Dashboards sind nützlich, aber auf dem Hof liegt der Wert in den Alarmen. Beginnen Sie mit einer kurzen Liste und stimmen Sie sie so ab, dass niemand lernt, Benachrichtigungen zu ignorieren.

1. Tränkenfüllstand unter 25 Prozent bei zwei aufeinanderfolgenden Messungen (ein einzelner Wert kann ein trinkendes Tier sein).
2. Kein Uplink eines Tränken- oder Zaunsensors über 3 Intervalle, was meist eine leere Batterie oder einen beschädigten Sensor bedeutet.
3. Zaunspannung unter Ihrem Schwellwert (viele Landwirte verwenden einige Kilovolt) bei zwei Messungen.
4. Tier außerhalb eines Geofence, ausgewertet anhand der Positionsnachrichten.
5. Temperatur-Feuchte-Index im Stall über Ihrer Hitzestressgrenze in Milchvieh- oder Geflügelställen.
6. Aktivitätsrückgang im Vergleich zum jüngsten Durchschnitt des Tiers selbst, als Hinweis zur Kontrolle statt als Notfall markiert.

Für numerische Schwellwerte wie Tränkenfüllstand oder Stalltemperatur bietet das ConnectMQ-Portal Schwellwert-Alarmregeln und ein Alarmprotokoll, sodass Sie "level_pct unter 25" für ein Topic ohne Code konfigurieren können. Geofences und Prüfungen wie "keine Daten über 3 Intervalle" brauchen etwas Logik, die Sie in Node-RED oder in einem kleinen Python-Subscriber ausführen können, der sich als gewöhnlicher MQTT-Client verbindet:

def inside_fence(lat, lon, fence):
    # fence = (min_lat, min_lon, max_lat, max_lon) - einfaches Begrenzungsrechteck
    return fence[0] <= lat <= fence[2] and fence[1] <= lon <= fence[3]

Ein Begrenzungsrechteck ist grob, aber robust; Polygon-Geofences eignen sich besser für unregelmäßige Koppeln, und eine Bibliothek wie Shapely macht das unkompliziert.

Stolperfallen im Feld und wie Sie sie vermeiden

• GPS-Genauigkeit und Batterie. Halsbänder, die bei jedem Uplink eine Position bestimmen, entladen sich schnell. Bevorzugen Sie Geräte, die in Ruhe seltener und bei vom Beschleunigungssensor erkannter Bewegung häufiger melden.
• Platzierung des Gateways. Höhe schlägt alles andere. Ein Gateway auf dem Stallfirst mit einer ordentlichen Außenantenne deckt meist weit mehr ab als eines im Gebäude.
• Codec-Drift. Ändert ein Hersteller die Firmware, können sich die Namen der dekodierten Felder ändern. Halten Sie die Zuordnung der Bridge an einer Stelle und protokollieren Sie unbekannte Felder.
• Vertrauen in die Uhrzeit. Verwenden Sie den Zeitstempel des Netzwerkservers. Bridges, die neu starten, können sonst Lücken oder Duplikate in Ihrem Verlauf erzeugen.
• Speicherung. Der Broker ist ein Echtzeit-Knotenpunkt, kein Historian. Senden Sie Messwerte mit Telegraf oder Node-RED an eine Datenbank, wenn Sie für Weideanalysen einen Verlauf über die ganze Saison benötigen.
• Hofdaten nicht öffentlich veröffentlichen. Tierpositionen verraten, wo sich wertvoller Bestand befindet. Der öffentliche Broker dient nur zum Testen.

Vom Test zum Einsatz auf dem Hof

Sobald die Bridge funktioniert, stellen Sie das Ziel auf einen privaten Broker mit Zugangsdaten und TLS um. Mit einem verwalteten MQTT-Broker müssen Sie den Broker weder betreiben noch patchen; das ist wichtig, wenn die für das System verantwortliche Person auch für das Abkalben verantwortlich ist. Erstellen Sie in ConnectMQ im Portal einen Broker, kopieren Sie den generierten Benutzernamen, das Passwort und die Client ID und ändern Sie die Zielverbindung:

DEST_HOST = "broker.connectmq.com"   # oder der im Portal angezeigte Host
DEST_PORT = 8883
dest = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
dest.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
dest.tls_set()  # das CA-Bundle des Systems validiert das Let's-Encrypt-Zertifikat

Der kostenlose Serverless-Plan unterstützt bis zu 25 Verbindungen, was eine Bridge, ein Dashboard, eine Node-RED-Instanz und einige Smartphones bequem abdeckt. Größere Betriebe mit vielen Standorten können auf einen kostenpflichtigen Plan mit mehr Verbindungen und Shared Subscriptions für lastverteilte Verbraucher wechseln. Das Gesamtbild der Hofautomatisierung einschließlich Bewässerung und Gewächshäusern finden Sie im Leitfaden zu Smart Farming IoT und im Leitfaden zur IoT-Automatisierung.

Verbinden Sie Ihre Hofsensoren mit ConnectMQ

ConnectMQ gibt Ihrer LoRaWAN-Bridge, Ihren Dashboards und Alarmierungswerkzeugen einen sicheren gemeinsamen Treffpunkt, mit TLS, generierten Zugangsdaten und Schwellwertalarmen direkt im Portal. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, und richten Sie Ihre Bridge in wenigen Minuten darauf aus.

Häufig gestellte Fragen

Brauche ich LoRaWAN für die Nutztierüberwachung mit IoT?

Nicht immer. Ställe mit WLAN können WLAN- oder Ethernet-Sensoren nutzen, die direkt über MQTT veröffentlichen, aber auf offener Weide sind LoRaWAN oder Mobilfunk-IoT wegen Entfernung und Batterielaufzeit meist die einzige praktikable Option.

Können GPS-Halsbänder direkt über MQTT veröffentlichen?

Die meisten LoRaWAN-Halsbänder nicht; sie senden Uplinks an einen Netzwerkserver, der dann über MQTT veröffentlicht. Mobilfunk-Halsbänder veröffentlichen manchmal direkt über MQTT oder HTTP, und in beiden Fällen kann eine Bridge die Daten in Ihren Topic-Baum normalisieren.

Wie oft sollten Tränkensensoren melden?

Alle 10 bis 30 Minuten ist ein gängiger Kompromiss zwischen Batterielaufzeit und früher Warnung. Kombinieren Sie das mit einem Alarm bei zwei aufeinanderfolgenden niedrigen Messwerten, um Fehlalarme durch trinkende Tiere zu vermeiden.

Ist der öffentliche MQTT-Broker für echte Hofdaten sicher?

Nein. Der öffentliche Bereich von broker.connectmq.com ist für jeden lesbar und zum Testen gedacht. Verwenden Sie für Produktivdaten, insbesondere Tierpositionen, einen privaten Broker mit Zugangsdaten und TLS.