Surveillance du bétail IoT : suivre animaux, abreuvoirs et climat des bâtiments avec LoRaWAN et MQTT

Les systèmes de surveillance du bétail IoT donnent aux éleveurs une vue sur les animaux, l'eau et les conditions de logement sans devoir parcourir chaque parcelle deux fois par jour. Dans ce guide, vous allez concevoir une installation complète : des colliers et des capteurs LoRaWAN sur le terrain, un serveur de réseau qui décode les uplinks, et un broker MQTT qui transforme ces mesures en une arborescence de topics exploitable par vos tableaux de bord et vos alertes. Vous obtiendrez aussi un pont Python fonctionnel et un modèle d'alerte que vous pouvez tester dès aujourd'hui sur le serveur MQTT public gratuit.

Ce que mesure réellement la surveillance du bétail IoT

La plupart des problèmes d'un troupeau se manifestent d'abord par la variation de quelques signaux simples. Un bon système ne cherche pas à tout mesurer ; il mesure la poignée d'éléments qui exigeraient sinon une personne en quad.

Les intervalles comptent, car presque tous ces appareils fonctionnent sur batterie et sont soumis aux limites de rapport cyclique de LoRaWAN. Un collier qui émet chaque minute épuisera rapidement sa batterie et, dans de nombreuses régions, dépassera aussi ce que le réseau doit transporter. Prévoyez des uplinks lents et réguliers, complétés par des messages déclenchés par événement lorsqu'un changement survient.

Pourquoi LoRaWAN sur le terrain et MQTT derrière

Les pâturages sont vastes et disposent rarement de Wi-Fi ou d'une couverture cellulaire fiable au niveau du sol. LoRaWAN convient bien, car une seule passerelle sur le toit d'un bâtiment ou sur un mât peut couvrir une grande surface, et les capteurs peuvent fonctionner longtemps sur batterie. La contrepartie est la bande passante : les payloads sont minuscules, généralement une douzaine d'octets de binaire compacté.

LoRaWAN ne livre pas directement les données à votre application. La chaîne se présente ainsi :

1. Le collier ou le capteur d'abreuvoir envoie un uplink par radio.
2. Une ou plusieurs passerelles le transmettent à un serveur de réseau LoRaWAN, comme The Things Stack ou ChirpStack.
3. Le serveur de réseau décode le payload avec un codec (une petite fonction JavaScript) et publie un événement JSON.
4. Votre intégration récupère cet événement et le met à disposition des tableaux de bord, des alertes et du stockage.

Les deux principaux serveurs de réseau exposent les uplinks via MQTT, mais leurs topics sont propres au réseau et chargés de métadonnées radio. Un schéma pratique consiste à exécuter un petit pont qui s'abonne au serveur de réseau et republie un message propre, orienté exploitation, vers votre propre broker MQTT. Tout ce qui se trouve en aval (tableaux de bord, Home Assistant, Node-RED, application mobile) dialogue alors avec une arborescence de topics unique et stable qui ne change pas si vous changez de serveur de réseau. Les guides sur l'intégration MQTT de The Things Network et sur ChirpStack MQTT détaillent le côté serveur de réseau.

Si la notion de hub de messages central est nouvelle pour vous, la courte explication sur le rôle d'un broker MQTT mérite d'être lue avant d'aller plus loin.

Concevoir l'arborescence des topics

Nommez les topics d'après l'exploitation, pas d'après la radio. Une arborescence qui suit le site, la zone et l'équipement est facile à lire et à interroger avec des wildcards :

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

Quelques règles la rendent maintenable :

• Utilisez des identifiants stables (numéro de boucle, numéro d'abreuvoir) dans les topics, pas les DevEUI. Gardez le DevEUI dans le payload pour le dépannage.
• Conservez la dernière mesure en retained pour les abreuvoirs, le climat et la tension de clôture, afin qu'un tableau de bord ouvert à 5 heures du matin affiche immédiatement l'état actuel.
• Ne mettez pas les alarmes en retained comme des commandes. Les alertes sont des événements ; une alarme retained rejouée à chaque reconnexion sème la confusion.
• Gardez des payloads JSON légers avec l'horodatage du serveur de réseau, car c'est l'heure de l'uplink qui compte, pas celle du traitement par votre pont.

Exemple de message d'abreuvoir :

{
  "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"
}

Construire le pont : du serveur de réseau vers MQTT

Le pont ci-dessous s'abonne aux événements d'uplink de ChirpStack v4, extrait le champ décodé object, associe chaque appareil à un topic de l'exploitation et le republie. Pour le premier test, il publie sur le serveur MQTT public gratuit broker.connectmq.com, qui ne nécessite aucun compte mais est lisible par tous : utilisez donc un préfixe aléatoire et uniquement des données de test.

Installez la bibliothèque :

pip install "paho-mqtt>=2.0"

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

# ChirpStack v4 (local ou hébergé) - à adapter à votre serveur de réseau
LNS_HOST = "chirpstack.local"
LNS_PORT = 1883
LNS_TOPIC = "application/+/device/+/event/up"

# Broker de destination - d'abord l'espace public de test, identifiants ensuite
DEST_HOST = "broker.connectmq.com"
DEST_PORT = 1883
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/farm1"

# DevEUI -> (zone, type, identifiant de l'équipement)
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)

Observez le résultat depuis n'importe quelle machine :

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

Le serveur public autorise 8 niveaux de topic : connectmq/demo/<id>/farm1/pasture-north/troughs/trough-03/level, avec exactement 8 niveaux, constitue donc le maximum ; pour des arborescences plus profondes, supprimez le niveau farm1 pendant les tests. L'article consacré au serveur MQTT public gratuit, lié plus haut, liste les autres limites.

Des alertes sur lesquelles les éleveurs agissent vraiment

Les tableaux de bord sont utiles, mais dans une exploitation, la valeur réside dans les alertes. Commencez par une courte liste et ajustez-la pour que personne ne prenne l'habitude d'ignorer les notifications.

1. Niveau d'abreuvoir inférieur à 25 % sur deux mesures consécutives (une seule mesure peut correspondre à un animal en train de boire).
2. Aucun uplink d'un capteur d'abreuvoir ou de clôture pendant 3 intervalles, ce qui signifie généralement une batterie à plat ou un capteur endommagé.
3. Tension de clôture inférieure à votre seuil (de nombreux éleveurs utilisent quelques kilovolts) sur deux mesures.
4. Animal hors d'une géoclôture, évalué sur les messages de position.
5. Indice température-humidité du bâtiment supérieur à votre limite de stress thermique pour les bâtiments laitiers ou avicoles.
6. Baisse d'activité par rapport à la moyenne récente de l'animal lui-même, signalée pour inspection plutôt que comme une urgence.

Pour les seuils numériques comme le niveau d'abreuvoir ou la température du bâtiment, le portail ConnectMQ inclut des règles d'alerte à seuil et un journal des alertes : vous pouvez ainsi configurer « level_pct inférieur à 25 » sur un topic sans écrire de code. Les géoclôtures et les vérifications « aucune donnée pendant 3 intervalles » nécessitent un peu de logique, que vous pouvez exécuter dans Node-RED ou dans un petit abonné Python qui se connecte comme un client MQTT ordinaire :

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

Un rectangle englobant est sommaire mais robuste ; les géoclôtures polygonales conviennent mieux aux parcelles irrégulières, et une bibliothèque comme Shapely les rend simples à mettre en œuvre.

Pièges du terrain et comment les éviter

• Précision GPS et batterie. Les colliers qui calculent leur position à chaque uplink se vident vite. Préférez des appareils qui émettent moins souvent au repos et plus souvent lorsque l'accéléromètre détecte un mouvement.
• Emplacement de la passerelle. La hauteur prime sur tout le reste. Une passerelle sur le faîte du bâtiment avec une véritable antenne extérieure couvre généralement bien plus qu'une passerelle à l'intérieur.
• Dérive du codec. Si un fabricant modifie le firmware, les noms des champs décodés peuvent changer. Gardez la table de correspondance du pont à un seul endroit et journalisez les champs inconnus.
• Fiabilité de l'horloge. Utilisez l'horodatage du serveur de réseau. Sinon, les ponts qui redémarrent peuvent créer des trous ou des doublons dans votre historique.
• Stockage. Le broker est un hub temps réel, pas un historien. Envoyez les mesures vers une base de données avec Telegraf ou Node-RED si vous avez besoin d'un historique sur toute une saison pour analyser le pâturage.
• Ne publiez pas les données de l'exploitation publiquement. La position des animaux révèle où se trouve un cheptel de valeur. Le serveur MQTT public gratuit sert uniquement aux tests.

Passer d'un test à un déploiement sur l'exploitation

Une fois le pont fonctionnel, basculez la destination vers un broker privé avec identifiants et TLS. Avec un broker MQTT managé, vous n'exploitez ni ne mettez à jour le broker vous-même, ce qui compte lorsque la personne responsable du système est aussi responsable des vêlages. Dans ConnectMQ, créez un broker dans le portail, copiez le nom d'utilisateur, le mot de passe et le client ID générés, puis modifiez la connexion de destination :

DEST_HOST = "broker.connectmq.com"   # ou l'hôte indiqué dans votre portail
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()  # le magasin de CA du système valide le certificat Let's Encrypt

Le plan Serverless gratuit prend en charge jusqu'à 25 connexions, ce qui couvre largement un pont, un tableau de bord, une instance Node-RED et quelques téléphones. Les exploitations plus importantes, réparties sur de nombreux sites, peuvent passer à un plan payant offrant davantage de connexions et des shared subscriptions pour répartir la charge entre consommateurs. Pour une vue d'ensemble de l'automatisation agricole, y compris l'irrigation et les serres, consultez le guide de l'agriculture intelligente IoT et le guide de l'automatisation IoT.

Connectez les capteurs de votre exploitation à ConnectMQ

ConnectMQ offre à votre pont LoRaWAN, à vos tableaux de bord et à vos outils d'alerte un lieu de rencontre sécurisé, avec TLS, des identifiants générés et des alertes à seuil intégrées au portail. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et dirigez-y votre pont en quelques minutes.

Questions fréquentes

Ai-je besoin de LoRaWAN pour la surveillance du bétail IoT ?

Pas toujours. Les bâtiments équipés de Wi-Fi peuvent utiliser des capteurs Wi-Fi ou Ethernet qui publient directement en MQTT, mais pour les pâturages ouverts, LoRaWAN ou l'IoT cellulaire est généralement la seule option réaliste en raison de la distance et de l'autonomie.

Les colliers GPS peuvent-ils publier directement en MQTT ?

La plupart des colliers LoRaWAN ne le peuvent pas ; ils envoient des uplinks à un serveur de réseau, qui publie ensuite en MQTT. Les colliers cellulaires publient parfois directement en MQTT ou en HTTP, et dans les deux cas un pont peut normaliser les données dans votre arborescence de topics.

À quelle fréquence les capteurs d'abreuvoir doivent-ils émettre ?

Toutes les 10 à 30 minutes est un compromis courant entre autonomie et alerte précoce. Associez-le à une alerte sur deux mesures basses consécutives pour éviter les fausses alarmes lorsque les animaux boivent.

Le serveur MQTT public gratuit convient-il à de vraies données d'exploitation ?

Non. L'espace public de broker.connectmq.com est lisible par tous et destiné aux tests. Utilisez un broker privé avec identifiants et TLS pour les données de production, en particulier la position des animaux.