A confiabilidade do Raspberry Pi raramente é limitada pela placa em si; ela é limitada pelo cartão SD, pela fonte de alimentação, pelo calor e por softwares que ninguém reinicia quando travam. Este guia percorre as mudanças que transformam um Pi de projeto de bancada em um gateway MQTT que roda sem supervisão por meses: reduzir as gravações no armazenamento, usar um sistema de arquivos raiz somente leitura, escolher alimentação e refrigeração, ativar watchdogs e monitorar o dispositivo remotamente via MQTT. Cada seção inclui os comandos para aplicar a mudança.
Por que Pis sempre ligados falham
Quando um gateway Pi fica em silêncio em campo, seja em uma estação de saneamento, em um silo ou no galpão de uma fábrica, a causa normalmente cai em uma de poucas categorias:
| Falha | Sintoma típico | Causa raiz |
|---|---|---|
| Corrupção do armazenamento | Inicia em shell de emergência, remontagem somente leitura, arquivos faltando | Cartão SD desgastado ou energia perdida no meio de uma gravação |
| Subtensão | Reboots aleatórios, dispositivos USB caindo, Wi-Fi reiniciando | Fonte fraca, cabo longo ou fino, periféricos que consomem muito |
| Superaquecimento | Lentidão, throttling, comportamento errático | Sem refrigeração em um gabinete fechado |
| Travamento de software | O dispositivo responde ao ping, mas os dados param | Script travado, deadlock, vazamento de memória, problema na pilha de rede |
| Perda de rede | Lacuna nos dados e depois backlog perdido | Queda do Wi-Fi, reboot do roteador, falha da rede celular |
A boa notícia é que cada uma delas tem uma mitigação bem conhecida. Nenhuma exige hardware exótico, e a maioria se resolve com poucas linhas de configuração.
Armazenamento: reduza as gravações ou troque a mídia
Cartões SD têm resistência limitada a gravações e pouca proteção contra perda de energia. Um gateway que gera muitos logs, grava em um banco de dados e deixa o journald persistir os logs pode desgastar um cartão barato surpreendentemente rápido. Há três soluções complementares.
Use um armazenamento melhor. Um Raspberry Pi 4 ou 5 pode inicializar a partir de um SSD USB, e o Pi 5 também suporta drives NVMe pelo M.2 HAT+. Ambos lidam com gravações muito melhor do que cartões SD. Se precisar usar SD, escolha um cartão de alta resistência de marca confiável, projetado para gravação contínua.
Corte gravações desnecessárias. Mantenha os logs na RAM, desative o swap se não precisar dele e monte com noatime:
# journald apenas na RAM (os logs se perdem no reboot, então encaminhe os importantes)
sudo mkdir -p /etc/systemd/journald.conf.d
printf "[Journal]\nStorage=volatile\nRuntimeMaxUse=30M\n" | sudo tee /etc/systemd/journald.conf.d/volatile.conf
sudo systemctl restart systemd-journald
# desativa o arquivo de swap
sudo systemctl disable --now dphys-swapfile 2>/dev/null || true
# confere se as opções de montagem da raiz incluem noatime
findmnt /
Grave de forma deliberada. Se o seu gateway guarda mensagens em disco enquanto está offline, agrupe as gravações e use SQLite em modo WAL, como no tutorial de buffer MQTT offline em Python. Evite regravar um arquivo de estado JSON a cada segundo.
Sistema de arquivos raiz somente leitura
Para gateways que não precisam mudar de software com frequência, uma raiz somente leitura é a proteção mais forte contra corrupção. O Raspberry Pi OS inclui uma opção de overlay filesystem: a raiz real fica somente leitura e todas as alterações vão para uma camada na RAM que desaparece no reboot.
sudo raspi-config nonint enable_overlayfs
sudo reboot
# mais tarde, para atualizar o software:
sudo raspi-config nonint disable_overlayfs
sudo reboot
Você também pode ativá-la de forma interativa em Performance Options no raspi-config. Planeje-se para duas consequências. Primeiro, tudo o que o gateway precisa guardar (mudanças de configuração, um buffer de mensagens) exige uma partição gravável separada ou um drive externo. Segundo, as atualizações exigem um ciclo de reboot de manutenção, então automatize-o ou documente-o.
Alimentação: o fator mais subestimado
A subtensão causa mais comportamentos misteriosos do que qualquer outro problema de hardware. Use a fonte oficial do seu modelo ou uma fonte industrial com folga: o Raspberry Pi 5 foi projetado para uma fonte USB-C de 5 V 5 A, e o Pi 4 para 5,1 V 3 A. Mantenha os cabos curtos e grossos e alimente drives USB ou modems por um hub alimentado se eles consumirem muito.
Verifique se o Pi já passou por subtensão ou throttling desde o boot:
vcgencmd get_throttled
Um resultado throttled=0x0 é o que você quer. O bit 0 (0x1) significa subtensão agora, o bit 16 (0x10000) significa que houve subtensão desde o boot, e os bits 2 e 18 indicam throttling. Publique esse valor via MQTT para enxergar os problemas antes que causem falhas.
Em locais com rede elétrica instável, um pequeno HAT de UPS ou um nobreak CC dá ao Pi tempo para desligar de forma limpa. Mesmo alguns segundos de autonomia protegem o sistema de arquivos muito melhor do que um corte seco.
Calor e gabinetes
O Pi reduz a frequência da CPU quando esquenta, o que protege o hardware, mas deixa a sua aplicação mais lenta. Em uma caixa plástica fechada ao sol, algo comum em instalações externas no verão brasileiro, um Pi pode chegar a esse ponto com pouca carga. Use um case dissipador ou o Active Cooler oficial em um Pi 5, ventile os gabinetes e mantenha o Pi longe de outras fontes de calor. Leia a temperatura com vcgencmd measure_temp e inclua-a nas suas mensagens de saúde.
Watchdogs: recupere sem visita técnica
Um watchdog reinicia o sistema quando o software para de responder. Use duas camadas.
Watchdog de hardware via systemd. O SoC do Pi inclui um temporizador de watchdog que o systemd pode alimentar. Se o kernel ou o próprio systemd travar, a placa reinicia.
sudo mkdir -p /etc/systemd/system.conf.d
printf "[Manager]\nRuntimeWatchdogSec=15\nRebootWatchdogSec=2min\n" | sudo tee /etc/systemd/system.conf.d/watchdog.conf
sudo systemctl daemon-reexec
dmesg | grep -i watchdog
Watchdog de aplicação. Um processo Python travado não aciona o watchdog de hardware, porque o systemd continua saudável. Rode o gateway como serviço do systemd com Restart=always e, para travamentos (não apenas falhas), use Type=notify com WatchdogSec=: o script precisa enviar um heartbeat regularmente, ou o systemd o encerra e reinicia.
import os
import socket
def sd_notify(state: str):
addr = os.getenv("NOTIFY_SOCKET")
if not addr:
return
if addr.startswith("@"):
addr = "\0" + addr[1:]
with socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) as s:
s.connect(addr)
s.sendall(state.encode())
# depois que o MQTT conectar: sd_notify("READY=1")
# no loop principal, só quando o trabalho estiver realmente avançando:
# sd_notify("WATCHDOG=1")
Envie WATCHDOG=1 apenas quando o loop estiver de fato saudável, por exemplo depois de uma leitura e uma publicação bem-sucedidas. Enviá-lo a partir de uma thread separada que sempre roda anula o propósito. O arquivo de unit completo está no guia para rodar um script Python MQTT na inicialização.
Resiliência de rede
Quedas de conectividade são normais, não excepcionais. Projete para elas:
- Deixe a paho-mqtt reconectar automaticamente com
reconnect_delay_set(1, 60)econnect_async(). - Guarde as leituras localmente enquanto estiver desconectado e reenvie-as em ordem.
- Inclua um timestamp em cada payload para que os dados reenviados caiam no horário certo.
- Use uma mensagem Last Will em um topic
statusretained para que o backend saiba quando o gateway desaparece. - Prefira Ethernet a Wi-Fi sempre que possível; no Wi-Fi, desative a economia de energia com
sudo iw dev wlan0 set power_save offse notar quedas.
Monitoramento remoto de saúde via MQTT
Não dá para consertar o que não se vê. Faça cada gateway publicar uma pequena mensagem de saúde a cada minuto: uptime, temperatura da CPU, flags de throttling, espaço livre em disco, profundidade do buffer e versão do software. O tutorial de estatísticas do sistema do Raspberry Pi via MQTT mostra um publicador completo. Com um broker MQTT na nuvem no meio, você acompanha uma frota inteira de um só lugar, e as regras de alerta por limite do ConnectMQ podem sinalizar um gateway cuja temperatura ou profundidade de buffer ultrapasse um limite. O status retained do Last Will, mais o topic $SYS/broker/connection/{clientId}/state do broker, mostra quais dispositivos estão online neste momento.
Checklist de confiabilidade
- Inicialize a partir de SSD ou NVMe, ou use um cartão SD de alta resistência.
- Logs na RAM, swap desativado,
noatimena montagem da raiz. - Overlay somente leitura ativado em implantações estáveis.
- Fonte oficial ou industrial;
get_throttledretorna0x0. - Dissipador ou refrigeração ativa; temperatura monitorada.
- Watchdog de hardware ativado no systemd.
- Gateway rodando como serviço do systemd com
Restart=alwayse um watchdog de aplicação. - Reconexão MQTT automática, buffer offline e Last Will configurados.
- Métricas de saúde publicadas a cada minuto e acompanhadas por alertas.
- Sistema operacional blindado e conexões TLS, seguindo o checklist de segurança para IoT com Raspberry Pi.
Aplicados em conjunto, esses passos eliminam os modos de falha mais comuns e tornam os raros restantes recuperáveis remotamente. Para o básico de conectar um Pi a um broker, comece pelo tutorial MQTT com Raspberry Pi e consulte a documentação oficial do Raspberry Pi para detalhes de alimentação e boot específicos de cada modelo.
Mantenha o lado do servidor confiável com o ConnectMQ
Um gateway que nunca falha ainda perde dados se o broker com quem ele fala falhar. Um broker MQTT gerenciado como o ConnectMQ cuida do broker para que você se concentre na borda. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, conecte o seu gateway via TLS na porta 8883 e acompanhe os topics de saúde dele no explorador de topics ao vivo.
Perguntas frequentes
Quanto tempo dura um cartão SD em um gateway Raspberry Pi?
Depende inteiramente da carga de gravação e da qualidade do cartão. Reduzir as gravações e usar um cartão de alta resistência ou um SSD aumenta muito a vida útil, enquanto logs intensos podem desgastar um cartão barato rapidamente.
Um sistema de arquivos somente leitura vai quebrar meu cliente MQTT?
Não, se o cliente só precisar ler o próprio código e a configuração. Tudo o que ele precisar persistir, como um buffer offline, exige um local gravável separado.
Preciso de um nobreak para um Raspberry Pi?
Nem sempre, mas vale a pena onde a energia é instável. Um desligamento limpo protege o sistema de arquivos, e uma raiz somente leitura reduz o estrago quando a energia é cortada sem aviso.
Devo agendar reboots periódicos?
Reboots agendados escondem os problemas em vez de resolvê-los. Watchdogs mais monitoramento de saúde são melhores, mas um reboot semanal é uma alternativa pragmática enquanto você investiga um vazamento.
