Monitoramento de Gado com IoT: Animais, Bebedouros e Clima do Galpão com LoRaWAN e MQTT

Sistemas de monitoramento de gado com IoT dão ao produtor visão sobre os animais, a água e as condições das instalações sem precisar percorrer cada piquete duas vezes por dia, seja em um confinamento no Mato Grosso ou em uma fazenda leiteira no Sul de Minas. Neste guia você vai projetar uma solução completa: colares e sensores LoRaWAN no campo, um network server que decodifica os uplinks e um broker MQTT que transforma essas leituras em uma árvore de tópicos que seus painéis e alertas podem usar. Você também terá uma bridge funcional em Python e um padrão de alertas que pode testar hoje mesmo no servidor MQTT público (gratuito).

O que o monitoramento de gado com IoT realmente mede

A maioria dos problemas do rebanho aparece primeiro como uma mudança em alguns sinais simples. Um bom sistema não tenta medir tudo; ele mede o punhado de coisas que, de outra forma, exigiriam uma pessoa rodando de quadriciclo.

Os intervalos importam porque quase todos esses dispositivos funcionam com bateria e estão sujeitos aos limites de duty cycle do LoRaWAN. Um colar que envia dados a cada minuto esgota a bateria rapidamente e, em muitas regiões, também ultrapassa o que a rede deveria transportar. Planeje uplinks lentos e regulares, mais mensagens disparadas por eventos quando algo muda.

Por que LoRaWAN no campo e MQTT por trás

Pastos são grandes e raramente têm Wi-Fi ou cobertura celular confiável no nível do chão. O LoRaWAN se encaixa bem porque um único gateway no telhado do galpão ou em um poste pode cobrir uma área extensa, e os sensores funcionam por muito tempo com uma bateria. A contrapartida é a largura de banda: os payloads são minúsculos, normalmente uma dúzia de bytes em binário compactado.

O LoRaWAN não entrega os dados diretamente à sua aplicação. A cadeia é esta:

1. O colar ou o sensor de bebedouro envia um uplink por rádio.
2. Um ou mais gateways o encaminham a um network server LoRaWAN, como o The Things Stack ou o ChirpStack.
3. O network server decodifica o payload com um codec (uma pequena função JavaScript) e publica um evento JSON.
4. Sua integração pega esse evento e o disponibiliza para painéis, alertas e armazenamento.

Os dois principais network servers expõem os uplinks via MQTT, mas seus tópicos são específicos de cada rede e cheios de metadados de rádio. Um padrão prático é rodar uma pequena bridge que assina o network server e republica uma mensagem limpa, orientada à fazenda, no seu próprio broker MQTT. Tudo o que vem depois (painéis, Home Assistant, Node-RED, um app móvel) passa a conversar com uma única árvore de tópicos estável, que não muda se você trocar de network server. Os guias sobre a integração MQTT do The Things Network e o ChirpStack MQTT cobrem em detalhes o lado do network server.

Se o conceito de um hub central de mensagens é novo para você, vale ler a explicação curta sobre o que faz um broker MQTT antes de seguir.

Projetando a árvore de tópicos

Dê aos tópicos nomes da fazenda, não do rádio. Uma árvore que segue local, área e ativo é fácil de ler e fácil de assinar com curingas:

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

Algumas regras mantêm isso sustentável:

• Use IDs estáveis (número do brinco, número do bebedouro) nos tópicos, não DevEUIs. Mantenha o DevEUI no payload para solução de problemas.
• Retenha a última leitura de bebedouros, clima e tensão da cerca, para que um painel aberto às 5 da manhã mostre imediatamente o estado atual.
• Não retenha alarmes como comandos. Alertas são eventos; um alarme retido que se repete a cada reconexão gera confusão.
• Mantenha payloads em JSON pequeno com o timestamp do network server, porque o que importa é a hora do uplink, não a hora em que a bridge o processou.

Exemplo de mensagem de bebedouro:

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

Construindo a bridge: do network server ao MQTT

A bridge abaixo assina os eventos de uplink do ChirpStack v4, extrai o campo decodificado object, mapeia cada dispositivo para um tópico da fazenda e o republica. No primeiro teste, ela publica no servidor MQTT público broker.connectmq.com, que não exige conta, mas pode ser lida por qualquer pessoa; por isso, use um prefixo aleatório e apenas dados de teste.

Instale a biblioteca:

pip install "paho-mqtt>=2.0"

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

# ChirpStack v4 (local ou hospedado) - ajuste para o seu network server
LNS_HOST = "chirpstack.local"
LNS_PORT = 1883
LNS_TOPIC = "application/+/device/+/event/up"

# Broker de destino - primeiro a área pública de testes, credenciais depois
DEST_HOST = "broker.connectmq.com"
DEST_PORT = 1883
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/farm1"

# DevEUI -> (área, tipo, id do ativo)
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)

Acompanhe o resultado de qualquer máquina:

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

O servidor MQTT público permite 8 níveis de tópico, então connectmq/demo/<id>/farm1/pasture-north/troughs/trough-03/level, com exatamente 8 níveis, é o máximo; para árvores mais profundas, remova o nível farm1 durante os testes. O artigo sobre o servidor MQTT público, indicado na introdução, lista os demais limites.

Alertas que o produtor realmente atende

Painéis são úteis, mas na fazenda o valor está nos alertas. Comece com uma lista curta e ajuste-a para que as pessoas não aprendam a ignorar as notificações.

1. Nível do bebedouro abaixo de 25 por cento em duas leituras consecutivas (uma única leitura pode ser um animal bebendo).
2. Nenhum uplink de um sensor de bebedouro ou de cerca por 3 intervalos, o que normalmente indica bateria esgotada ou sensor danificado.
3. Tensão da cerca abaixo do seu limite (muitos produtores usam alguns quilovolts) em duas leituras.
4. Animal fora de uma cerca virtual (geofence), avaliado nas mensagens de posição.
5. Índice de temperatura e umidade do galpão acima do seu limite de estresse térmico em instalações de leite ou aves.
6. Queda de atividade em relação à média recente do próprio animal, sinalizada para inspeção, e não como emergência.

Para limites numéricos, como nível do bebedouro ou temperatura do galpão, o portal da ConnectMQ inclui regras de alerta por limite e um log de alertas, então você pode configurar "level_pct abaixo de 25" em um tópico sem escrever código. Geofences e verificações de "sem dados por 3 intervalos" exigem alguma lógica, que você pode rodar no Node-RED ou em um pequeno assinante em Python conectado como cliente MQTT comum:

def inside_fence(lat, lon, fence):
    # fence = (min_lat, min_lon, max_lat, max_lon) - retângulo delimitador simples
    return fence[0] <= lat <= fence[2] and fence[1] <= lon <= fence[3]

Um retângulo delimitador é rudimentar, mas robusto; geofences poligonais são melhores para piquetes irregulares, e uma biblioteca como a Shapely torna isso simples.

Armadilhas de campo e como evitá-las

• Precisão do GPS e bateria. Colares que fixam a posição a cada uplink se esgotam rápido. Prefira dispositivos que enviam dados com menos frequência em repouso e com mais frequência quando o acelerômetro detecta movimento.
• Posicionamento do gateway. A altura vence tudo. Um gateway na cumeeira do galpão com uma antena externa adequada costuma cobrir muito mais do que um dentro de uma construção.
• Mudanças no codec. Se um fabricante muda o firmware, os nomes dos campos decodificados podem mudar. Mantenha o mapeamento da bridge em um só lugar e registre campos desconhecidos.
• Confiança no relógio. Use o timestamp do network server. Do contrário, bridges que reiniciam podem criar lacunas ou duplicatas no seu histórico.
• Armazenamento. O broker é um hub em tempo real, não um historiador. Envie as leituras a um banco de dados com Telegraf ou Node-RED se precisar de histórico de uma temporada inteira para análise de pastejo.
• Não publique dados da fazenda publicamente. A localização dos animais revela onde está o rebanho valioso. O servidor MQTT público serve apenas para testes.

Do teste à implantação na fazenda

Quando a bridge estiver funcionando, mude o destino para um broker privado com credenciais e TLS. Com um broker MQTT gerenciado, você não precisa rodar nem atualizar o broker, o que faz diferença quando a pessoa responsável pelo sistema também é responsável pelos partos. Na ConnectMQ, crie um broker no portal, copie o usuário, a senha e o client ID gerados e altere a conexão de destino:

DEST_HOST = "broker.connectmq.com"   # ou o host exibido no seu portal
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()  # o pacote de CAs do sistema valida o certificado Let's Encrypt

O plano gratuito Serverless suporta até 25 conexões, o que cobre com folga uma bridge, um painel, uma instância do Node-RED e alguns celulares. Operações maiores, com muitos locais, podem migrar para um plano pago com mais conexões e shared subscriptions para consumidores com balanceamento de carga. Com o estado retido de cada bebedouro, piquete e galpão em uma árvore de tópicos estável, você já tem a base de um gêmeo digital da fazenda. Para uma visão mais ampla da automação rural, incluindo irrigação e estufas, veja o guia de agricultura inteligente com IoT e o guia de automação IoT.

Conecte os sensores da sua fazenda à ConnectMQ

A ConnectMQ, um broker MQTT gerenciado, oferece à sua bridge LoRaWAN, aos painéis e às ferramentas de alerta um ponto de encontro seguro, com TLS, credenciais geradas e alertas por limite integrados ao portal. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e aponte sua bridge para ele em poucos minutos.

Perguntas frequentes

Preciso de LoRaWAN para o monitoramento de gado com IoT?

Nem sempre. Galpões com Wi-Fi podem usar sensores Wi-Fi ou Ethernet que publicam MQTT diretamente, mas, para pastos abertos, LoRaWAN ou IoT celular costumam ser a única opção prática por causa da distância e da duração da bateria.

Colares GPS podem publicar MQTT diretamente?

A maioria dos colares LoRaWAN não pode; eles enviam uplinks a um network server, que então publica em MQTT. Colares celulares às vezes publicam MQTT ou HTTP diretamente e, em ambos os casos, uma bridge pode normalizar os dados para a sua árvore de tópicos.

Com que frequência os sensores de bebedouro devem enviar dados?

A cada 10 a 30 minutos é um equilíbrio comum entre duração da bateria e alerta antecipado. Combine isso com um alerta em duas leituras baixas consecutivas para evitar alarmes falsos quando os animais bebem.

O servidor MQTT público é seguro para dados reais da fazenda?

Não. O servidor MQTT público broker.connectmq.com pode ser lido por qualquer pessoa e é destinada a testes. Use um broker privado com credenciais e TLS para dados de produção, especialmente a localização dos animais.