Guides

ChirpStack: como receber um alerta quando um dispositivo deixa de enviar

O ChirpStack não tem alertas nativos. Três formas de saber que um dispositivo LoRaWAN ficou em silêncio: a integração HTTP, a API gRPC e um watchdog alojado.

O ChirpStack não avisa quando um dispositivo deixa de enviar. A razão é simples: o ChirpStack é um servidor de rede, não uma plataforma de monitorização. Expõe dados através de integrações e de uma API, e deixa os alertas para quem consumir esses dados. Não há motor de regras, nem separador de notificações, nem um e-mail de «dispositivo offline» à espera de ser activado.

Um sensor com a pilha gasta, com humidade dentro da caixa ou com um rejoin falhado produz exactamente o mesmo que um sensor que funciona bem e apenas ainda não transmitiu: nada. A falha só se nota quando alguém olha para um gráfico.

O que o ChirpStack dá de facto

Estado do dispositivo. O ChirpStack envia periodicamente o comando MAC DevStatusReq e guarda o nível de bateria e a margem de ligação que o dispositivo devolve. O intervalo configura-se no perfil do dispositivo. É útil para apanhar uma pilha em fim de vida, mas não ajuda com um dispositivo que deixou de falar de todo: um pedido de estado sem resposta fica simplesmente sem resposta.

A marca temporal lastSeenAt. É este o campo que interessa, e tudo o resto é uma forma de o vigiar.

Opção 1: a integração HTTP (recomendada)

A que dá menos trabalho e a mais fiável. Em Applications ▸ a sua aplicação ▸ Integrations ▸ HTTP, defina um URL de endpoint. O ChirpStack fará um POST em JSON a cada uplink, com o EUI do dispositivo, o nome, o contador de tramas e os gateways que o ouviram.

{
  "deviceInfo": { "devEui": "24e124707c481234", "deviceName": "IO103M" },
  "fCnt": 412,
  "rxInfo": [ { "gatewayId": "2cf7f11e15ec0000", "rssi": -97, "snr": 8.2 } ],
  "object": { "battery": 88 }
}

Atenção: o ChirpStack envia eventos de join, ack e estado para o mesmo URL. Trate apenas os uplinks como sinal de vida — um ack não é um sensor a funcionar.

Publicamos um script Python de ficheiro único, sem dependências, que faz exactamente isto: uplink-watchdog, com licença MIT.

Opção 2: consultar a API

Em alternativa, pode ler o lastSeenAt de todos os dispositivos periodicamente e alertar sobre valores desactualizados.

Uma armadilha: o ChirpStack v4 já não inclui API REST. A interface REST da v3 era uma camada de tradução sobre gRPC e foi removida na v4. Quem precisa de REST tem de correr o contentor separado chirpstack-rest-api; caso contrário, fala gRPC através do pacote chirpstack-api.

O polling também escala pior: com algumas centenas de dispositivos estará a fazer um pedido paginado grande de poucos em poucos minutos para saber algo que o servidor de rede lhe teria dito de graça.

Escolher o limiar de silêncio

É aqui que falha quase toda a monitorização feita em casa. Um tempo-limite único não serve para um parque real: um contador de pessoas que transmite de 15 em 15 minutos e um sensor de nível que transmite uma vez por dia precisam de janelas separadas por duas ordens de grandeza. Curta demais, os sensores diários dão alarme falso todas as noites; larga demais, um contador morto passa despercebido um dia inteiro.

A abordagem que resulta é por dispositivo e aprendida: registe o intervalo médio de cada dispositivo e trate cerca de três intervalos falhados como avaria. Três é tolerante que chegue para sobreviver a um uplink perdido — normal em qualquer rede rádio — e apertado que chegue para apanhar uma avaria real no próprio dia.

Um pormenor fácil de escapar: exclua do cálculo dessa média as falhas com duração de avaria. Se uma paragem de dois dias entrar na média, o intervalo esperado dispara e a avaria seguinte demora muito mais a ser detectada. O ritmo aprendido deve reflectir apenas comportamento saudável.

Vigie também os gateways

Cada uplink traz um array rxInfo com os gateways que o receberam. Registá-los dá-lhe monitorização de gateways sem configuração adicional: se um gateway deixa de aparecer em qualquer rxInfo, deixou de encaminhar. Isto importa porque um gateway em baixo parece que todos os dispositivos por trás dele morrem ao mesmo tempo — e o que quer saber é a causa, não o sintoma.

O problema de alojar a vigilância em casa

Aplica-se a todas as opções acima e vale a pena dizê-lo com clareza: se a sua monitorização corre na sua própria infra-estrutura, ninguém vigia a vigilância. Se o processo morre, se a máquina reinicia ou se o disco enche, os alertas param — e a ausência de alertas é indistinguível de estar tudo bem.

Numa rede de hobby é um risco aceitável. Num parque pelo qual responde contratualmente, é a falha que mais cedo ou mais tarde custa caro.

Opção 3: um watchdog alojado

Foi para isto que construímos o UplinkWatch, portanto leia esta secção com isso em mente. Cola o nosso URL de ingestão nesse mesmo campo de integração HTTP e a vigilância passa a correr na nossa infra-estrutura em vez da sua. Dispositivos e gateways registam-se sozinhos, o ritmo é aprendido por dispositivo, e os alertas seguem por e-mail, notificação no telemóvel ou webhook. Gratuito até 5 dispositivos.

Alojado na União Europeia: os nossos servidores estão em Helsínquia (Finlândia), na Hetzner. Os seus metadados de uplink não saem da UE.

Se tem apenas um punhado de dispositivos e gosta de gerir os seus próprios serviços, o script da opção 1 chega perfeitamente.

Nota: a interface web do UplinkWatch está em inglês. Apoio em português por e-mail para info@geosensor.tech.

Also available in: English · Deutsch · Français · Español

Last updated 2026-09-03.