SIMUT

Manual do SIMUT

Instalação, configuração, uso no dia a dia e integração com servidores, para as três imagens publicadas: o painel (release), o LCD (alpha) e o registrador a bateria (Air).

Parte I

Conhecer

Capítulo 1

O SIMUT em uma página

Este capítulo diz o que o SIMUT faz, para quem ele serve e o que ele não é, mostra os três aparelhos lado a lado e ensina a ler o resto do manual. É para todo leitor, antes de qualquer outro capítulo.

O que o SIMUT faz

O SIMUT é um firmware para o Raspberry Pi Pico W que transforma a placa num monitor de temperatura, umidade e pressão. Um aparelho SIMUT:

  • lê até 16 sensores dos tipos DS18B20, DHT22, BME280 e BMP280, ligados aos pinos GP0 a GP15 (capítulo 2, capítulo 6);
  • grava o histórico no próprio aparelho, um registro por intervalo, a partir de 1 min. Com 11 grandezas e um registro por minuto, cabem cerca de 116 dias (medido em 31/07/2026; capítulo 15);
  • mostra as leituras no painel de toque ou no LCD, conforme a imagem, e na interface web, que o próprio aparelho serve (capítulo 11, capítulo 12, capítulo 13);
  • dispara alarmes por limite, com som, tela e aviso ao servidor, e aceita janelas de manutenção (capítulo 7);
  • envia as medições a um servidor seu por HTTP, HTTPS, MQTT ou MQTTS, e os alarmes por uma segunda linha, separada (capítulo 21, capítulo 22);
  • conversa com outros sistemas pelo Home Assistant, pelo Prometheus, pelo syslog e por uma API REST (capítulo 20, capítulo 26);
  • controla quem faz o quê, com até 32 contas e 13 permissões, senha na web e PIN no painel (capítulo 8);
  • se atualiza pela rede, pela página Arquivos (capítulo 17).

Para quem

O manual fala com quatro leitores:

Leitor O que faz com o aparelho
Quem instala Monta o hardware, grava o firmware, põe o aparelho na rede e liga os sensores
Quem opera Acompanha as leituras, atende os alarmes, abre janelas de manutenção e consulta o histórico
Quem integra Recebe a telemetria e a linha de alarmes num servidor e automatiza pela API
A equipe de TI Cuida da rede, das contas, do HTTPS, das atualizações e da segurança

Um mesmo profissional pode acumular mais de uma dessas funções. O roteiro de leitura no fim deste capítulo indica os capítulos de cada um.

O que o SIMUT não é

  • Não é um instrumento metrológico certificado. Antes de usá-lo onde a norma exige instrumento certificado, compare-o com uma referência sua. A calibração por sensor está no capítulo 6.
  • Não aciona equipamentos. O aparelho não tem saídas para relés ou atuadores. Um alarme sai como som, como aviso na tela e como mensagem ao seu servidor.
  • Não depende de nuvem. A interface web sai do próprio aparelho e funciona numa rede local sem internet. As medições só saem para um servidor que você configurar: de fábrica, a telemetria e a linha de alarmes estão desligadas. O que o aparelho procura na rede de fábrica é a hora certa, por NTP (capítulo 10).

Os três aparelhos

O mesmo código gera três imagens de firmware publicadas, uma para cada montagem de hardware:

  • release: o monitor com painel de toque colorido de 320×240;
  • alpha: o monitor com LCD de 16×2 caracteres e console pelo Bluetooth;
  • Air (SIMUT Air): o registrador a bateria, sem tela, que hiberna entre as leituras. É experimental.
Recurso release alpha Air
Tela Painel TFT com toque LCD 16×2 Nenhuma
Cigarra (buzzer) Sim Sim Não
Console pelo USB De emergência De emergência Completo
Console pelo Bluetooth Não Sim Sim, acordado
Interface web e API REST Sim Sim Só acordado (M0)
HTTPS na interface web Sim, com certificado Não Não
Endereço <nome>.local (mDNS) Sim Não Não
Ponto de acesso de configuração A pedido: menu do painel, comando ap ou gesto no boot A pedido: comando ap A pedido: comando ap
Contas e PIN no painel Sim Não Não
Gráfico, calendário e temas na tela Sim Não Não
Espelho do painel na web Sim Não Não
Hibernação entre leituras Não Não Sim
Telemetria e linha de alarmes Sim Sim Sim, nos despertares de transmissão
Home Assistant, Prometheus e syslog Sim Sim Com limites (capítulo 20)
Atualização pela web Sim Sim Só acordado
Situação Estável Publicada; a saída do LCD não foi testada em bancada Experimental

Os 16 slots de sensor, os quatro tipos de sensor, o histórico, os alarmes, as contas e as permissões são iguais nas três imagens. As diferenças de cada recurso estão no capítulo dele: o ponto de acesso no capítulo 9, o console no capítulo 14, o PIN no capítulo 8, o Air no capítulo 19.

As imagens de bancada

O código gera também três imagens para testes automáticos: pico_w_test, pico_w_test_https e pico_w_asserts. Elas não são publicadas e não servem para uso: as duas primeiras trazem o console completo e comandos de teste, e a terceira existe para detectar erros de concorrência. Use sempre uma das três imagens publicadas.

Como ele funciona por dentro

O RP2040, o processador do Pico W, tem dois núcleos:

  • o Core 0 faz quase tudo: lê os sensores, avalia os alarmes, grava o histórico, cuida da rede, atende a interface web e o console e envia a telemetria;
  • o Core 1 cuida só da tela. Na release, ele desenha o painel e lê o toque; na alpha, ele escreve no LCD; no Air, que não tem tela, ele não é usado.

A memória flash do Pico W tem 2 MB, divididos em duas metades:

Área Tamanho O que guarda
Programa 1.020 KiB O firmware, com a interface web inteira embutida
Sistema de arquivos (LittleFS) 1.024 KiB A configuração e as contas, o histórico, o log de eventos, a calibração, os pacotes de idioma, os temas do painel e os certificados

O que fica só na memória RAM se perde num reinício ou numa falta de energia:

  • o bloco aberto do histórico, com os registros ainda não selados. O aparelho grava uma cópia dele depois de cada registro e a recupera no boot, então uma falta de energia perde no máximo o último registro (capítulo 15);
  • a fila da linha de alarmes (capítulo 22);
  • a senha inicial do administrador, que o aparelho mostra uma única vez (capítulo 4).

O mapa completo do sistema de arquivos está no capítulo 17.

Figura 1. O aparelho em blocos: os sensores entram pelo Core 0, a tela fica com o Core 1, e a flash se divide entre o programa e o sistema de arquivos.

Versões

Este manual descreve a v2.11.1, de 12/10/2026, a versão publicada mais recente. A linha 2.7 saiu do beta com a v2.7.0.

O que a v2.11.1 mudou para quem usa o aparelho:

  • a troca obrigatória de PIN não pode mais ser pulada: SAIR volta à tela inicial, e o menu só abre depois da troca (capítulo 8);
  • no painel, uma conta com a permissão Usuários só concede as permissões de painel que ela mesma tem (capítulo 8);
  • uma política de PIN mais exigente não tranca mais do painel quem tem um PIN mais curto: a conta se identifica com o PIN antigo e vai para a troca, e a mensagem de PIN curto diz o mínimo da política (capítulo 8);
  • Adotar a sonda ligada aqui lê o GPIO do próprio slot, e a leitura segue com a sonda nova na hora (capítulo 6);
  • o AP aberto pelo gesto no boot segue o prazo de 15 min num aparelho com rede configurada (capítulo 9);
  • a página Arquivos explica a recusa v=6, a de uma imagem de outro chip (capítulo 17).

A v2.11.0, de 04/10/2026, tinha trazido:

  • o Pico 2 W (RP2350) passa a ter imagens publicadas: o .uf2 de fábrica, que traz a tabela de partições, e o .bin de atualização (capítulo 3);
  • no Pico 2 W, a atualização pela rede vai para o outro slot, sem tocar no sistema de arquivos, e sobe em teste. Se não se confirmar em cinco minutos, ou se o aparelho reiniciar antes, ele volta sozinho para a versão anterior, e o painel e a página Arquivos dizem isso (capítulo 26);
  • uma transferência longa, como uma atualização, um backup ou uma restauração, não cai mais quando outra página do aparelho está aberta no navegador (capítulo 18);
  • na alpha, gravar a configuração não reinicia mais o aparelho pelo watchdog.

Um aparelho com a v2.11.0 não tem os itens da v2.11.1, e o que as versões anteriores trouxeram está no apêndice Histórico de versões. Onde este manual diz “na v2.7.1” ou “pelo código da v2.7.1”, o texto vale também para as versões seguintes, salvo nas mudanças que o apêndice registra da v2.7.2 em diante. Como conferir a versão do seu aparelho está no capítulo 17.

Como ler este manual

Selos de imagem

Uma seção que vale só para algumas imagens começa com selos:

Selo Significado
release Vale para a imagem com painel de toque
alpha Vale para a imagem com LCD
air Vale para o SIMUT Air
main Está no código-fonte, mas ainda não numa versão publicada

Uma seção sem selo vale para as três imagens.

Selos de permissão

Uma ação que exige permissão mostra o nome técnico da permissão num selo, como PERM_NET_CONFIG, e o nome que a página Usuários usa no texto, como Rede. As 13 permissões estão no capítulo 8.

Faixas

Figuras

As figuras mostram telas do painel, fotos do LCD, páginas da interface web, fotos do hardware e diagramas. Onde uma figura ainda não foi capturada, o manual mostra uma caixa com a descrição do que ela vai mostrar e em que estado.

Textos da interface

Os rótulos aparecem em negrito, como o aparelho os mostra com o pacote de idioma pt-BR. Na primeira vez, o rótulo em inglês vem entre parênteses e em itálico, como Buscar redes (Scan): é o texto de um aparelho sem pacote de idioma. Comandos, campos e respostas do aparelho aparecem em fonte fixa, exatamente como o aparelho os escreve.

Os exemplos usam nomes de documentação: simut como nome do aparelho, MinhaRede como rede Wi-Fi, 192.0.2.10 como endereço e coletor.exemplo.com.br como servidor. Troque pelos seus.

Roteiro de leitura

Leitor Leia nesta ordem
Quem instala 2 Hardware, 3 Firmware, 4 Primeiro boot, 9 Rede, 6 Sensores, 10 Data e hora, 18 Recuperação
Quem opera 11 Painel ou 12 LCD, 13 Interface web, 7 Alarmes, 15 Histórico, 16 Log de eventos
Quem administra o aparelho 5 Configuração pela web, 8 Contas, 17 Atualização e backup, 14 Console
Quem integra 20 Visão geral, 21 Telemetria, 22 Linha de alarmes, 23 Home Assistant, 24 Prometheus, 25 Syslog, 26 API REST, 27 Frota
A equipe de TI 9 Rede e HTTPS, 29 Segurança, 8 Contas, 17 Atualização, 20 Portas, 27 Frota
Quem usa o Air 19 SIMUT Air, depois o roteiro da sua função

Os limites do aparelho estão no capítulo 28, os problemas comuns no capítulo 30 e os termos no capítulo 31.

Voltar ao sumário

Capítulo 2

Hardware e ligações

Este capítulo descreve o Pico W e a alimentação, o mapa completo de pinos de cada imagem, os pinos que servem para sensores, a ligação de cada tipo de sensor e a placa de circuito do projeto. É para quem monta o aparelho. A configuração dos sensores depois de ligados está no capítulo 6.

O Pico W e a alimentação

O SIMUT roda num Raspberry Pi Pico W: o processador RP2040, 2 MB de memória flash e o chip de rádio CYW43, que faz o Wi-Fi e o Bluetooth. O firmware é compilado para o Pico W e depende do rádio dele: o Pico sem W não serve.

A alimentação vem pelo conector USB do Pico W, em 5 V. Dentro do aparelho:

Ponto do Pico W Pino Alimenta
VBUS (5 V do USB) 40 O LCD da alpha
3V3 (saída do regulador) 36 O TFT e o toque da release, e os sensores
GND 3, 8, 13, 18, 23, 28, 38 Terra comum de tudo

Regras de montagem:

  • Terra comum. Ligue o GND do Pico W, da tela e de todos os sensores entre si.
  • Sensores e TFT no 3V3. Os sensores, os resistores de pull-up e o TFT vão no 3V3, o pino 36.
  • LCD no 5 V. O LCD 16×2 da alpha vai no 5 V (VBUS, pino 40), não no 3V3.
  • Cabo USB de qualidade. O guia de ligações do projeto pede cabo de pelo menos 22 AWG: queda de tensão no cabo causa reinícios.

Os GPIOs 23, 24, 25 e 29 não saem na borda da placa: o Pico W os usa internamente para falar com o chip de rádio.

O mapa de pinos

Cada imagem usa os pinos de GP16 em diante para a tela, o toque, a cigarra e, no Air, para o controle de energia. Os pinos de GP0 a GP15 ficam para os sensores nas três imagens.

GPIO Pino release alpha Air
GP0 a GP15 1, 2, 4–7, 9–12, 14–17, 19, 20 Slots de sensor Slots de sensor Slots de sensor
GP16 21 MISO do SPI0 (TFT e toque) RS do LCD Energia dos sensores e sinal de acordado (saída)
GP17 22 CS do toque EN do LCD Carregador (entrada)
GP18 24 SCK do SPI0 (TFT e toque) D4 do LCD Sem uso
GP19 25 MOSI do SPI0 (TFT e toque) D5 do LCD Sem uso
GP20 26 IRQ do toque D6 do LCD Sem uso
GP21 27 Sem uso D7 do LCD Sem uso
GP22 29 Cigarra Cigarra Sem uso
GP26 31 RST do TFT Sem uso Sem uso
GP27 32 DC do TFT Sem uso Sem uso
GP28 34 CS do TFT Sem uso Sem uso
GP23, GP24, GP25, GP29 — Rádio Rádio Rádio

“Sem uso” quer dizer que o firmware não usa o pino. Ele também não serve para sensor: um slot só aceita GP0 a GP15 (Onde ligar os sensores).

A numeração física segue a do Pico W: o pino 1 é o GP0, no canto do conector USB, e os pinos seguem em U até o 40, o VBUS, do outro lado do mesmo canto.

Figura 2. O mapa de pinos da release: sensores à esquerda, tela, toque e cigarra à direita.
Figura 3. O mapa de pinos da alpha: o LCD em GP16 a GP21, a cigarra em GP22.
Figura 4. O mapa de pinos do Air: só GP16 e GP17 além dos sensores.

A release: TFT e toque

release O painel é um TFT de 320×240 com controlador ILI9341 e toque resistivo com controlador XPT2046, no mesmo barramento SPI0. Os dois compartilham MISO, MOSI e SCK e têm cada um o seu CS.

Pino do módulo Função Liga em
VCC Alimentação 3V3 (pino 36)
GND Terra GND
CS Seleção do TFT GP28 (pino 34)
RESET Reinício do TFT GP26 (pino 31)
DC Dado ou comando GP27 (pino 32)
SDI (MOSI) Dados para o TFT GP19 (pino 25)
SCK Relógio GP18 (pino 24)
LED Luz de fundo 3V3 (pino 36)
SDO (MISO) Dados do TFT GP16 (pino 21)
T_CLK Relógio do toque GP18 (pino 24)
T_CS Seleção do toque GP17 (pino 22)
T_DIN Dados para o toque GP19 (pino 25)
T_DO Dados do toque GP16 (pino 21)
T_IRQ Aviso de toque GP20 (pino 26)

O firmware não controla a luz de fundo: com o pino LED no 3V3, ela fica sempre acesa.

A alpha: LCD 16×2

alpha A alpha usa um LCD de 16×2 caracteres com controlador HD44780, ligado em modo paralelo de 4 bits.

Pino do LCD Símbolo Liga em
1 VSS GND
2 VDD 5 V (VBUS, pino 40)
3 VO Cursor de um potenciômetro de 10 kΩ entre 5 V e GND (contraste)
4 RS GP16 (pino 21)
5 R/W GND
6 E GP17 (pino 22)
7 a 10 D0 a D3 Não ligados
11 D4 GP18 (pino 24)
12 D5 GP19 (pino 25)
13 D6 GP20 (pino 26)
14 D7 GP21 (pino 27)
15 A (LED+) 5 V, por um resistor de 100 Ω
16 K (LED−) GND

O aparelho só escreve no LCD, por isso o R/W vai direto ao GND. Com o contraste errado, o LCD parece apagado ou mostra blocos cheios: ajuste o potenciômetro com o aparelho ligado.

A cigarra

release alpha A cigarra fica entre o GP22 (pino 29) e o GND. Use uma cigarra passiva, que toca a frequência que recebe: o aparelho gera cada nota pelo PIO do RP2040. O Air não tem cigarra. Os sons estão no capítulo 7.

O Air: energia dos sensores e carregador

air O Air usa dois pinos além dos sensores. O do carregador se troca ou se desliga pelo console, com o comando air charger (capítulo 19); o de energia não tem comando e fica no GP16. Os pinos de fábrica:

Pino Direção O que faz
GP16 (pino 21) Saída Fica em nível alto enquanto o aparelho está acordado e em nível baixo enquanto ele dorme
GP17 (pino 22) Entrada, com pull-down Nível alto quer dizer carregador ligado: o aparelho para de hibernar e fica acordado

O GP16 serve para dois fins, e você pode usar um, os dois ou nenhum:

  • Cortar a energia dos sensores durante o sono. Ligue o GP16 à entrada de controle de uma chave do lado positivo, como um MOSFET de canal P com o circuito de acionamento adequado ou o pino de habilitação de um regulador de 3,3 V, e alimente os sensores pela saída dessa chave. Nunca alimente os sensores direto do GP16: um GPIO fornece pouca corrente e o DHT22 consome mais que isso durante a medição.
  • Medir o ciclo. O nível do GP16 mostra, num analisador lógico, quando o aparelho está acordado.

O GP17 espera um divisor resistivo a partir dos 5 V do carregador, que o leve a nível alto (3,3 V) enquanto o carregador está ligado. Com o carregador, o Air fica acordado e alcançável; sem ele, volta a hibernar no fim do tempo de ociosidade (capítulo 19).

Figura 5. O Air: o GP16 corta a energia dos sensores durante o sono, e o GP17 percebe o carregador.

Onde ligar os sensores

Nas três imagens, os sensores vão nos pinos GP0 a GP15, que são os 16 slots. A página Configurações e o console recusam qualquer pino de GP16 em diante. Um pino atende um só slot ativo: dois slots ativos no mesmo GPIO são recusados.

Tipo GPIOs por sensor Máximo de sensores
DS18B20 1 16, um por GPIO
DHT22 1 16, um por GPIO
BME280 ou BMP280 2 8, cada um no seu par (as regras do I²C)

Os tipos podem se misturar: 10 DS18B20 e 2 BME280 ocupam 14 GPIOs e deixam 2 livres.

Cuidados por imagem:

  • release Durante o boot, o GP8 e o GP9 transmitem e recebem o diagnóstico de boot pela UART1, a 115200 baud, até o sensor configurado neles assumir o pino. Com um adaptador USB-serial de 3,3 V no GP8 (pino 11), você lê em que etapa um boot parou.
  • A busca de sondas mexe no GP16. O botão Procurar sondas testa os pinos de GP0 a GP16 (capítulo 6). O GP16 é o MISO do TFT na release, o RS do LCD na alpha e, no Air, a saída que liga a energia dos sensores. A busca não devolve esses pinos ao estado de antes: reinicie o aparelho depois de uma busca.
  • A placa do projeto só leva GP0 a GP10 aos conectores de sensor (A placa do projeto).

Os sensores

Tipo Mede Alimentação Pull-up externo O aparelho aceita
DS18B20 Temperatura 3V3 4,7 kΩ do dado ao 3V3 −50 a 150 °C
DHT22 Temperatura e umidade 3V3 O que o fabricante do módulo indica Leitura com soma de verificação correta
BME280 Temperatura, umidade e pressão 3V3 4,7 kΩ em SDA e SCL, se o módulo não tiver −40 a 85 °C; 0 a 100 %; 300 a 1.100 hPa
BMP280 Temperatura e pressão 3V3 Igual ao BME280 −40 a 85 °C; 300 a 1.100 hPa

O aparelho liga o pull-up interno do RP2040 em todo pino de sensor. Ele é fraco demais para substituir os resistores externos da tabela. O que acontece com uma leitura fora da faixa está no capítulo 6.

DS18B20

O DS18B20 é um sensor de temperatura de 1 fio (1-Wire), em geral numa sonda à prova d’água com três fios.

Fio do sensor Liga em
GND GND
DQ (dado) O GPIO do slot
VDD 3V3 (pino 36)

Ponha um resistor de 4,7 kΩ entre o DQ e o 3V3.

Ligue uma sonda por GPIO. O aparelho identifica a sonda pelo número de série gravado nela (a ROM) e lê esse número com um comando que só funciona com uma sonda no fio. Com a ROM gravada no slot, o aparelho percebe a troca de sonda (capítulo 6).

Figura 6. Um DS18B20: três fios e um resistor de 4,7 kΩ entre o dado e o 3V3.

DHT22

O DHT22 mede temperatura e umidade por um único fio de dados.

Ligação Liga em
Alimentação (+) 3V3 (pino 36)
Dados O GPIO do slot
Terra (−) GND

Ligue um DHT22 por GPIO. O aparelho lê cada DHT22 a cada 2 s, o intervalo mínimo do sensor.

Figura 7. Um DHT22: alimentação, dados e terra.

BME280 e BMP280

O BME280 e o BMP280 são sensores I²C: usam dois GPIOs, SDA e SCL. Por fora os módulos são iguais; o BMP280 não mede umidade.

Pino do módulo Liga em
VCC (ou VIN) 3V3 (pino 36)
GND GND
SDA O GPIO do pino SDA do slot
SCL O GPIO do pino SCL do slot
CSB 3V3 (seleciona o modo I²C)
SDO GND para o endereço 0x76, ou 3V3 para 0x77
  • O endereço. Com um sensor por par, qualquer um dos dois endereços funciona: o aparelho procura em 0x76 e, sem resposta, em 0x77.
  • O tipo. Se você escolheu BME280 e o chip é um BMP280, ou o contrário, o aparelho corrige o tipo pelo identificador do chip e grava a correção (capítulo 6).
  • A busca de sondas só encontra um BME280 ou BMP280 em GP4 (SDA) e GP5 (SCL). Em outros pinos, configure o slot à mão.
Figura 8. Um BME280 no par GP4/GP5, o par que a busca de sondas encontra.

As regras do I²C

O RP2040 tem dois periféricos I²C. Cada um só aceita SDA e SCL em certos pinos:

Periférico Pinos de SDA Pinos de SCL Pares vizinhos
I2C0 GP0, GP4, GP8, GP12 GP1, GP5, GP9, GP13 GP0/GP1, GP4/GP5, GP8/GP9, GP12/GP13
I2C1 GP2, GP6, GP10, GP14 GP3, GP7, GP11, GP15 GP2/GP3, GP6/GP7, GP10/GP11, GP14/GP15

Com o SDA num pino de SDA e o SCL num pino de SCL do mesmo periférico, o aparelho usa o periférico I²C. Qualquer outro par é lido pelo PIO do RP2040, mais devagar: o SDA num periférico e o SCL no outro (SDA em GP8 e SCL em GP11), o SDA e o SCL trocados (SDA em GP5 e SCL em GP4) e dois pinos do mesmo papel (SDA em GP0 e SCL em GP4). O log de eventos registra o aviso BME in bit-bang (no free hardware I2C).

Para ligar vários BME280 ou BMP280:

  1. Um sensor por par. A leitura do aparelho aceita dois sensores no mesmo par, em 0x76 e 0x77, mas a página Configurações e o console recusam dois slots ativos no mesmo GPIO. Dê a cada sensor o seu par.
  2. O periférico fica com o primeiro par. O aparelho prende cada periférico aos pinos do primeiro sensor que o usa, pela ordem dos slots. Um segundo sensor em outro par do mesmo periférico é lido pelo PIO, como os pares cruzados, e o aviso do log traz ctx igual a 100 mais o GPIO do SDA.

A placa do projeto

O projeto publica uma placa de circuito para a release e a alpha, desenhada no KiCad. Os arquivos de projeto e de fabricação (Gerber e furação) estão na pasta PCB_test/ do repositório.

Revisão Etiqueta no repositório Diferença
v1.0 simut-pcb-v1.0 O conector do LCD tem a pinagem errada
v1.1 simut-pcb-v1.1 Pinagem do LCD corrigida e placa com nomes: pinos do TFT e do toque, bloco Alphanumeric, coluna de sensores S0 a S10, aviso de rede elétrica e endereço do projeto

Use a revisão v1.1, que é a da pasta PCB_test/. As duas revisões estão publicadas como releases do repositório, cada uma com o arquivo simut_pcb_fabrication.zip; a v1.0 fica só como registro do defeito.

O que a placa v1.1 tem:

  • Soquete do Pico W.
  • Entrada de rede elétrica, marcada 90-240Vac, com um conversor HLK-PM01 que fornece os 5 V. Os 5 V chegam ao pino VBUS do Pico W e ao LCD.
  • Conector TFT-Touch, de 14 pinos, na ordem da tabela da release. O VCC e o LED do módulo vêm do 3V3 do Pico W.
  • Conector Alphanumeric, de 12 pinos, na ordem VSS, VDD, VO, RS, RW, E, D4, D5, D6, D7, A e K, com um trimpot de contraste na placa.
  • Cigarra na placa, acionada pelo GP22 por meio de um transistor.
  • Coluna de sensores S0 a S10, ligada a GP0 a GP10, com redes de resistores de pull-up para o 3V3. Os pinos GP11 a GP15 não chegam a nenhum conector: nesta placa, o aparelho tem 11 posições de sensor.
  • Quatro furos de fixação para parafusos M2.5.

Os arquivos da placa e do esquema não definem o valor de nenhum resistor. Para as redes de pull-up dos sensores, use 4,7 kΩ, o valor da tabela dos sensores.

Figura 9. A placa v1.1 montada para a release: o Pico W, o conector do painel, a coluna de sensores e a entrada de rede elétrica.

Lista de conferência da montagem

Antes de ligar o aparelho pela primeira vez:

  1. O GND do Pico W, da tela e de todos os sensores está ligado entre si.
  2. Os sensores e os pull-ups vão no 3V3 (pino 36), não no 5 V.
  3. alpha O LCD vai no 5 V (pino 40), com o R/W no GND e o potenciômetro de contraste no VO.
  4. Cada DS18B20 tem o resistor de 4,7 kΩ do dado ao 3V3, e há uma sonda por GPIO.
  5. Cada BME280 ou BMP280 tem o seu par, com SDA e SCL nos papéis da tabela do I²C.
  6. Nenhum sensor está em GP16 ou acima.
  7. release O TFT e o toque compartilham MISO, MOSI e SCK, com CS separados: GP28 para o TFT e GP17 para o toque.
  8. Anote qual sensor está em qual GPIO: a configuração dos slots pede essa informação (capítulo 6).

Voltar ao sumário

Capítulo 3

Instalar o firmware

Este capítulo mostra quais arquivos cada versão publica, como escolher a imagem certa, como gravá-la pelo cabo USB, como pôr o pacote de idioma no aparelho, como montar uma imagem sob medida e como compilar o firmware a partir do código-fonte. É para quem instala um aparelho novo ou atualiza um aparelho antigo pelo USB. A atualização pela rede, de um aparelho já em uso, está no capítulo 17.

Os arquivos de cada versão

Cada versão publicada, na página de versões do projeto no GitHub (github.com/angeloINTJ/simut/releases), traz doze arquivos:

Arquivo Para que serve
simut_v2.11.1_release.uf2 Gravar a imagem release pelo USB
simut_v2.11.1_alpha.uf2 Gravar a imagem alpha pelo USB
simut_v2.11.1_air.uf2 Gravar a imagem do Air pelo USB
simut_v2.11.1_releasetwo.uf2 Gravar a release do Pico 2 W pelo USB, com a tabela de partições
simut_v2.11.1_release.bin Atualizar a release pela página Arquivos (capítulo 17)
simut_v2.11.1_alpha.bin Atualizar a alpha pela página Arquivos
simut_v2.11.1_air.bin Atualizar o Air pela página Arquivos
simut_v2.11.1_releasetwo.bin Atualizar a release do Pico 2 W pela página Arquivos; a imagem nova sobe em teste (capítulo 26)
language_pt-BR.lng Pacote de idioma português do Brasil
language_es-ES.lng Pacote de idioma espanhol
manifest.json Tamanho, soma SHA-256 e tipo de cada imagem, para um gestor de frota (capítulo 27)
SHA256SUMS A soma SHA-256 de cada arquivo acima, para conferir um download com sha256sum -c SHA256SUMS

As imagens do Pico 2 W (RP2350), com releasetwo no nome, são publicadas desde a v2.11.0.

Desde a v2.9.0, cada arquivo publicado também tem um atestado de procedência, que liga o arquivo à execução do CI que o gerou e ao commit de onde veio; quem tem o gh confere um download com gh attestation verify <arquivo> --repo angeloINTJ/simut. Os .bin e os .uf2 vêm assinados: a assinatura são os 241 bytes do fim do arquivo (capítulo 17).

O .uf2 e o .bin de uma mesma imagem têm o mesmo firmware: o .uf2 é o .bin embrulhado no formato que o Pico W aceita pelo USB. No Pico 2 W os dois arquivos diferem, embora o programa seja o mesmo. O .uf2 traz também a tabela de partições, que um Pico 2 W virgem não tem. O .bin traz a marca que faz a imagem nova subir em teste: se ela não se confirmar em cinco minutos, o aparelho volta sozinho para a imagem anterior. Não troque um pelo outro: a página Arquivos recusa o .uf2 (capítulo 17), e a unidade do BOOTSEL ignora o .bin.

Os pacotes de idioma não vão dentro do firmware. Eles ficam no sistema de arquivos do aparelho e entram por outro caminho (O pacote de idioma). Os 11 temas do painel (arquivos .thm) não vêm na página da versão: estão na pasta data/themes do código-fonte, e são opcionais (capítulo 11).

Figura 10. Os arquivos de uma versão e o caminho de cada um até o aparelho.

Escolher a imagem

A imagem depende do hardware montado (capítulo 2):

Hardware Imagem
Painel TFT com toque release
LCD 16×2 alpha
Sem tela, a bateria, com hibernação Air

Na dúvida sobre um aparelho já instalado, o tipo de imagem aparece na interface de programação: no campo sys.env de /api/status e no campo env de /api/perms (capítulo 26).

O aparelho confere o tipo de imagem de dois jeitos diferentes:

  • Pela página Arquivos, ele recusa uma imagem de outro tipo antes de aplicá-la (capítulo 17).
  • Pelo USB, ele aceita qualquer imagem. A conferência é sua: leia o nome do arquivo antes de copiar.

Uma imagem gravada no hardware errado não encontra a tela dela: o painel ou o LCD fica apagado. Grave de novo, pelo USB, a imagem certa.

Gravar pelo USB com o BOOTSEL

Este é o caminho para um Pico W novo e o caminho que sempre funciona, porque não depende do firmware que está na placa. Você precisa do cabo USB e do arquivo .uf2 da sua imagem.

  1. Desligue o cabo USB do Pico W.
  2. Aperte e segure o botão BOOTSEL, o único botão da placa.
  3. Ligue o cabo USB ao computador, ainda segurando o botão.
  4. Solte o botão. O computador mostra uma unidade de disco chamada RPI-RP2.
  5. Copie o arquivo .uf2 para a unidade RPI-RP2.
  6. Espere. A unidade some sozinha, e o Pico W reinicia já com o SIMUT.
Figura 11. O botão BOOTSEL, segurado enquanto o cabo USB é ligado.

A gravação pelo USB só escreve a área do programa. O sistema de arquivos fica como estava:

  • num Pico W novo, o sistema de arquivos está vazio. No primeiro boot, o aparelho o formata, cria as pastas e começa com a configuração de fábrica (capítulo 4);
  • num aparelho em uso, a configuração, as contas, o histórico, a calibração e os pacotes de idioma continuam lá. O firmware novo converte a configuração antiga no boot, dentro dos limites de Atualizar um aparelho antigo.

Com o picotool

O picotool é a ferramenta de linha de comando do Raspberry Pi para o RP2040. Com o Pico W no modo BOOTSEL (passos 1 a 4 acima):

picotool info
picotool load -x simut_v2.11.1_release.uf2

O picotool info confirma que a placa está no modo BOOTSEL. O load -x grava e reinicia a placa no fim.

Sem apertar o botão: o toque de 1200 baud

Um aparelho com o firmware funcionando entra no modo BOOTSEL sozinho quando o computador abre a porta serial USB dele a 1200 baud e a fecha. O pio run -t upload faz isso automaticamente antes de gravar (Compilar a partir do código-fonte). O toque só funciona enquanto o USB do firmware responde; num aparelho travado, use o botão.

air O Air desliga o USB enquanto dorme, e a porta serial some do computador. Grave o Air com ele acordado, em M0 (capítulo 19), ou pelo botão BOOTSEL.

O pacote de idioma

Sem pacote de idioma, o painel e a interface web aparecem em inglês. O console serial responde em português de fábrica, com ou sem pacote (capítulo 14).

O caminho recomendado é enviar o pacote pela interface web, depois que o aparelho estiver na rede (capítulo 4):

  1. Entre na interface web com uma conta que tenha as permissões Leitura PERM_FILE_READ e Upload PERM_FILE_UPLOAD. O admin tem as duas.
  2. Abra a página Arquivos e a pasta /lang.
  3. Toque em Enviar e escolha language_pt-BR.lng, o da mesma versão do firmware.
  4. Confira se o arquivo aparece na pasta com o tamanho certo.
  5. Reinicie o aparelho. O pacote só é lido no boot.

Detalhes da página Arquivos estão no capítulo 17, e o comportamento do idioma na web, no capítulo 13.

O uploadfs, só num aparelho novo

Quem compila da fonte pode gravar o sistema de arquivos inteiro com a pasta data/ do código-fonte:

pio run -e pico_w_release -t uploadfs

A pasta data/ leva os dois pacotes de idioma e os 11 temas. Depois de um uploadfs, apague language_es-ES.lng da pasta /lang pela página Arquivos, se você quer o aparelho em português, e reinicie.

Uma imagem sob medida

O configurador de build monta uma imagem com outro conjunto de recursos, pelo navegador. Ele tem português e inglês, tema claro e escuro, e pode ser instalado como aplicativo.

  1. Em Produto, escolha SIMUT (a imagem release), SIMUT Alpha, SIMUT Air ou SIMUT para o Pico 2 W.
  2. Em Recursos, ligue ou desligue o que a imagem leva. Cada recurso mostra quanto a imagem daquele produto cresce ou encolhe, medido compilando. Uma combinação que o firmware não compila aparece Bloqueada, com o motivo.
  3. Em Resultado, a página soma as mudanças e diz se a imagem Cabe, está No limite ou Não cabe, no espaço do programa e no teto da atualização pela rede. No Pico 2 W os dois tetos são o slot de 1.568.768 B.
  4. Toque em Compilar esta build. A integração contínua do projeto compila a imagem e entrega o .uf2, para o USB, e o .bin, para a página Arquivos (capítulo 17). No Pico 2 W são as duas imagens que a release publica para ele: o .uf2 de fábrica, com a tabela de partições, e o .bin, uma atualização que vai para o outro slot e roda em teste.

Compilar esta build exige um token do GitHub com acesso de escrita ao repositório. Sem ele, Pedir esta build abre um pedido no GitHub com a configuração preenchida.

  • A soma é uma estimativa. Contra oito builds reais de mudanças combinadas, ela errou por até 4.392 B de flash e 8.192 B de .bin. Por isso a página diz No limite perto de um teto; a build dá o número exato.
  • A imagem sai da main e informa a versão da main, que pode estar à frente da última versão publicada. Sem mudanças, a página aponta a última versão publicada, porque compilar gera a main de hoje.
  • A imagem continua do mesmo tipo. O configurador não troca a tela de um produto, então a página Arquivos aceita o .bin num aparelho do mesmo produto (capítulo 17).

Compilar a partir do código-fonte

A maioria das instalações usa as imagens publicadas. Compile só para mudar uma opção de compilação, como a frequência do TFT (capítulo 2).

Você precisa de Python 3 e do PlatformIO. Os passos abaixo repetem os da integração contínua do projeto:

git clone https://github.com/angeloINTJ/simut.git
cd simut
pip install platformio zopfli
pio pkg install -e pico_w_release
bash tools/arduino_pico_overrides/patch.sh
pio run -e pico_w_release
  • O patch.sh aplica as correções que o projeto faz no framework arduino-pico. Sem ele, a compilação falha. Rode-o de novo sempre que o framework for reinstalado.
  • O zopfli comprime as páginas web. Sem ele, a compilação usa o gzip e a imagem sai alguns kB maior.
  • O ambiente escolhe a imagem: pico_w_release, pico_w_alpha ou pico_w_air. O pio run sem -e compila só a pico_w_release.

A imagem sai em .pio/build/pico_w_release/, como firmware.uf2 e firmware.bin. Para gravar direto, com o Pico W ligado ao USB:

pio run -e pico_w_release -t upload

O PlatformIO usa o toque de 1200 baud e o picotool para gravar; o botão BOOTSEL também funciona.

Uma opção de compilação muda com -D e vale sobre o padrão do arquivo src/simut_config.h. Por exemplo, para escrever no TFT a 33,25 MHz em vez de 66,5 MHz:

PLATFORMIO_BUILD_FLAGS="-DSIMUT_TFT_SPI_HZ=33250000u" pio run -e pico_w_release

Atualizar um aparelho antigo

Versão no aparelho Como atualizar O que se perde
2.x Pela página Arquivos (capítulo 17), ou pelo USB Pela página, o que o backup não devolver; pelo USB, nada
1.6.2-beta a 1.x Pela página Arquivos, ou pelo USB A configuração e o histórico antigo (veja abaixo)
Anterior à 1.6.2-beta Só pelo USB, uma vez A configuração e o histórico antigo (veja abaixo)

As versões anteriores à 1.6.2-beta tinham um defeito na atualização pela rede: diziam que tinham aplicado a imagem sem aplicá-la. Por isso, a primeira atualização de um aparelho desses é pelo USB.

Um aparelho na versão 1.x perde duas coisas no primeiro boot da 2.11.1:

  • A configuração. O firmware não lê configurações das versões 1.x. O aparelho começa com a configuração de fábrica e uma senha nova para o admin, mostrada no console USB (capítulo 4). Anote a rede, as contas e os sensores antes de atualizar.
  • O histórico no formato antigo. Os arquivos .sim4 da pasta /history são apagados no primeiro boot. Baixe-os antes de atualizar e converta-os no computador, com a ferramenta tools/history_v5.py do código-fonte:
python3 tools/history_v5.py --convert-v4 AAAAMMDD.sim4 AAAAMMDD.h5

Um aparelho na versão 2.x mantém a configuração: o firmware novo a converte no boot.

Depois de gravar

O primeiro boot de um aparelho novo mostra a senha do administrador uma única vez, no console USB. Deixe o console aberto antes de o aparelho reiniciar (capítulo 4). Para conferir a versão gravada, veja o capítulo 17.

Voltar ao sumário

Capítulo 4

Primeiro boot e primeira configuração

Este capítulo leva um aparelho recém-gravado do primeiro boot até o uso: a senha inicial, a entrada na rede, a primeira entrada na web, o idioma, a hora, o primeiro sensor e o PIN do painel. É para quem instala. Cada passo é curto e aponta para o capítulo que traz os detalhes.

O caminho em resumo

  1. Abra o console USB e ligue o aparelho: anote a senha do administrador (A senha inicial). release No fim do boot, o painel pergunta a data e a hora (O que o boot mostra).
  2. Ponha o aparelho na rede: abra o ponto de acesso de configuração com o comando ap ou pelo menu do painel, ou grave a rede pelo console (Pôr o aparelho na rede).
  3. Entre na interface web e troque a senha (A primeira entrada na web).
  4. Instale o pacote de idioma e confira o fuso e a hora (Idioma, fuso e hora).
  5. Configure o primeiro sensor (O primeiro sensor).
  6. release Troque o PIN de fábrica do painel (O PIN do painel).
  7. Confira a lista final (Pronto para usar).
Figura 12. O primeiro boot em um só desenho: a senha, a hora, a rede, a web, o idioma, os sensores e o PIN.

Antes de ligar

Tenha à mão:

  • o aparelho com o firmware gravado (capítulo 3) e a montagem conferida (capítulo 2);
  • um computador com um programa de comunicação serial, como o picocom ou o PuTTY, e o cabo USB. O console usa 115200 baud, 8N1 (capítulo 14);
  • release alpha um celular ou computador com Wi-Fi, para entrar no ponto de acesso de configuração;
  • o nome e a senha da rede Wi-Fi do local. O aparelho só usa redes de 2,4 GHz, e o nome e a senha têm até 31 caracteres (capítulo 9).

O que o boot mostra

Um aparelho novo não tem rede configurada, e nenhuma imagem abre o ponto de acesso de configuração sozinha: ele abre quando você pede (Pôr o aparelho na rede). Sem rede também não há NTP, e o relógio em uso é o provisório, que parte de uma data gravada no firmware (capítulo 10). Por isso, no fim do boot, um aparelho sem rede configurada pede a data e a hora: a release, no painel; todas as imagens, numa linha do console USB:

Sem rede, relogio provisorio: conf time AAAA-MM-DD HH:MM:SS

O comando que a linha cita funciona no console de todas as imagens, pelo USB ou pelo Bluetooth (capítulo 10). Sem rede configurada, o boot não espera a rede: segue na hora, e a pergunta aparece logo no fim dele. O aparelho mede e grava o histórico com ou sem rede.

No painel

release Depois de ligar, o painel leva alguns segundos para mostrar as etapas do boot: cerca de 7,5 s, medidos em bancada em 22/09/2026, durante o desenvolvimento da v2.7.1. Em seguida aparecem SIMUT, a versão e a caixa com as etapas (capítulo 11). Sem rede configurada, a caixa não espera o roteador: mostra Conexão Ignorada pelo Usuário. e segue.

No fim do boot, num aparelho sem rede configurada, o painel abre a tela Data e hora em vez da tela inicial:

  • cinco colunas, dd / mm / aaaa hh : mm, que começam na data e na hora do relógio provisório;
  • acima de cada valor, uma seta que soma 1; abaixo, uma seta que subtrai 1. Segurada, a seta repete a cada 300 ms;
  • a linha Sem Wi-Fi, os dados levam esta hora., em âmbar;
  • os botões PULAR e SALVAR.

Ajuste a data e a hora do local e toque em SALVAR: o relógio passa a valer na hora, e o painel vai à tela inicial. PULAR vai à tela inicial sem mudar o relógio. Sem nenhum toque por 30 s, o painel faz o mesmo que PULAR: um aparelho que volta de uma falta de energia sem ninguém por perto mostra as leituras, não uma pergunta.

A pergunta não pede conta nem PIN, e volta a cada boot enquanto o aparelho não tiver rede: o acerto à mão não sobrevive a um reinício. Enquanto o relógio for o provisório, a barra de cima da tela inicial mostra a data e a hora em âmbar, com ? no lugar do -. Tudo isso está no capítulo 10.

Figura 13. A pergunta do fim do boot num aparelho sem rede: a data e a hora do relógio provisório, prontas para acertar.

No LCD

alpha O LCD mostra SIMUT 2.11.1 e Inicializando e, depois, uma barra de progresso (capítulo 12).

Num aparelho novo, o boot não espera a rede: no fim dele, o LCD mostra Sem WiFi e Offline por 3 s e passa às leituras (capítulo 12):

 Sem WiFi
    Offline

O LCD não mostra a data e a hora, e a pergunta sai só no console. No alpha, o console é o jeito de respondê-la: digite o comando que a linha cita, com a data e a hora locais, pelo console USB ou pelo Bluetooth:

SIMUT> conf time 2026-10-01 14:30:00
OK: Hora aplicada (imediato, nao persiste em reboot)

A interface web também acerta o relógio, por um ponto de acesso aberto com ap (capítulo 10).

No Air

air O Air não tem tela. Ao ligar, ele fica acordado (M0), com o console completo pelo USB e pelo Bluetooth e com a interface web. Como as outras imagens, ele não abre o ponto de acesso sozinho. Sem rede configurada, ele escreve no console a mesma linha do relógio provisório, e o comando time acerta o relógio (capítulo 10). Sem nenhuma atividade no console ou na web por 5 min, ele começa a hibernar (capítulo 19).

A senha inicial do administrador

Na primeira partida, o aparelho cria a conta admin com uma senha aleatória de 8 caracteres, feita de letras maiúsculas e algarismos, sem O, 0, I e 1. Ele mostra a senha uma única vez, no console USB:

==============================================
 SEC-003: FACTORY DEFAULTS ATIVADO
 Senha ADMIN inicial: R8TNC3VH
 Trocar no primeiro login (forcado).
==============================================

A senha do exemplo é ilustrativa. A moldura sai sempre em português, no meio das linhas de diagnóstico do boot, que começam com [DBG].

  • Nenhuma tela mostra a senha. O painel, o LCD e a interface web não a exibem. Só o console USB.
  • Ela não volta a aparecer. O aparelho não guarda a senha em texto: depois do primeiro reinício, a moldura não sai mais, e a senha continua valendo.
  • Abra o programa serial cedo. O aparelho espera 1 s pelo USB antes de escrever no console. Abra a porta assim que ela aparecer no computador.

Se você não viu a senha, gere outra pelo cabo USB (capítulo 14):

SIMUT> system admin reset confirm
Senha admin resetada. Nova senha (unica vez):
 K4XW7PQA
Trocar no 1o login via web (forcado).

air No Air, entre antes no modo privilegiado com enable. O comando não funciona pelo Bluetooth.

A conta viewer, a outra conta de fábrica, não tem senha conhecida. Gere uma senha para ela ou exclua a conta (capítulo 8).

Pôr o aparelho na rede

Pelo ponto de acesso de configuração

release alpha O ponto de acesso é a rede Wi-Fi que o aparelho cria para você configurá-lo. Ele só abre quando você pede. Os detalhes estão no capítulo 9.

  1. Abra o ponto de acesso. No console USB, que você já abriu para a senha, digite ap. A resposta traz a chave, e o console mostra também o nome da rede:

    SIMUT> ap
    
    [AP] SSID: simut_SETUP
    [AP] PSK : M7TQ4XH2RP   (WPA2)
    [AP] URL : http://192.168.4.1
    OK: Modo AP iniciado (WPA2). Senha: M7TQ4XH2RP
    Conecte-se ao AP e acesse http://192.168.4.1

    Na release, o item 8 do menu do painel, Modo de Configuração, faz o mesmo, com uma conta que tenha a permissão Rede no painel, e o painel passa a mostrar a rede e a chave (capítulo 11). Na alpha, o ap funciona também pelo Bluetooth, e o LCD alterna o endereço, a rede e a chave (capítulo 12).

  2. No celular ou no computador, conecte-se à rede simut_SETUP com a chave.

  3. Abra http://192.168.4.1. A página de entrada aparece.

  4. Entre como admin, com a senha inicial.

  5. Defina a senha nova na página Bem-vindo! (capítulo 13).

  6. Abra a página Rede, toque em Buscar, escolha a sua rede e digite a senha dela (capítulo 9).

  7. Toque em Salvar e reiniciar na barra de topo.

  8. Volte o celular ou o computador para a sua rede.

O aparelho reinicia e entra na rede. Se a senha da rede estiver errada, o aparelho fica tentando a rede pela escada de reconexão, e o ponto de acesso não volta sozinho: abra-o de novo e refaça a configuração (capítulo 9). Sem rede configurada, o ponto de acesso fica aberto até você gravar uma rede ou reiniciar o aparelho.

A chave do ponto de acesso é sempre a mesma para aquele aparelho, mesmo depois de um reset de fábrica. Anote-a: ela serve toda vez que o aparelho precisar do ponto de acesso.

Com o ponto de acesso aberto, o painel da release passa ao terminal da tela de boot e mostra o nome real da rede, simut_SETUP de fábrica, PSK seguido da chave, Acesse no celular: 192.168.4.1 e AP Ativo! Reinicie a placa para sair. O LCD do alpha alterna três páginas, com o endereço, a rede e a chave. O aparelho continua medindo com o ponto de acesso aberto (capítulo 9).

Figura 14. O painel com o ponto de acesso aberto: a rede, a chave e o aviso de AP ativo ficam na tela.
Figura 15. O LCD de uma alpha com o ponto de acesso aberto pelo comando ap: a página com o nome da rede.

Pelo console

Sem celular à mão, grave a rede pelo console USB.

release alpha No console de emergência:

SIMUT> system ssid MinhaRede
OK: SSID salvo. Use 'reload confirm' para reconectar.
SIMUT> system pass senha-da-rede
OK: Senha salva. Use 'reload confirm' para reconectar.
SIMUT> reload confirm

air No console completo do Air:

SIMUT> enable
SIMUT# configure terminal
SIMUT(config)# system ssid MinhaRede
SIMUT(config)# system pass senha-da-rede
SIMUT(config)# end
SIMUT# reload confirm

air O Air mede e grava o histórico mesmo sem rede. A rede serve para a telemetria e para a hora certa (capítulo 19).

Encontrar o endereço do aparelho

Na sua rede, o aparelho recebe um endereço IP do roteador. Para descobri-lo:

Onde Como
Console USB, todas as imagens show net status: a linha IP: (capítulo 14)
alpha LCD Conectado! e o endereço, por 3 s, no fim do boot (capítulo 12)
release Nome na rede http://simut.local, com o nome do aparelho seguido de .local (capítulo 9)
release Painel Configurações > Status do Sistema, página 2, linha IP (capítulo 11)
Roteador A lista de aparelhos conectados do roteador

Com o NTP ligado e sem servidor de hora alcançável, o nome .local não responde (Idioma, fuso e hora).

A primeira entrada na web

  1. No navegador, abra o endereço do aparelho, como http://192.0.2.10.
  2. Entre como admin.
  3. Se você ainda não trocou a senha inicial, a página Bem-vindo! pede a senha nova: pelo menos 8 caracteres, com letra, algarismo e símbolo (capítulo 13).

Sem pacote de idioma, a interface aparece em inglês. O resto da interface está no capítulo 13.

Idioma, fuso e hora

  1. Idioma. Envie language_pt-BR.lng para a pasta /lang, pela página Arquivos, e reinicie o aparelho (capítulo 3). O idioma de fábrica do aparelho é o português: depois do reinício com o pacote na pasta, o painel e a interface web ficam em português. O console já responde em português. release O idioma do painel muda em Configurações > Idioma (capítulo 11); o da web, no seletor de cada navegador (capítulo 13).
  2. Fuso. O de fábrica é −3, o de Brasília. Para outro, mude o Fuso Horário na página Configurações, seção Identidade, e toque em Salvar e reiniciar (capítulo 10).
  3. Hora. O NTP vem ligado e acerta o relógio pela internet. Numa rede sem acesso à internet, aponte o aparelho para um servidor de hora da própria rede ou acerte o relógio à mão: sem o primeiro acerto, o aparelho não termina de entrar na rede, e a telemetria espera (capítulo 10). Num aparelho que vai funcionar sem Wi-Fi, acerte a hora à mão depois de cada boot: em qualquer imagem, com o comando time no console; na release, também pela pergunta do boot ou pelo item 13 do menu, Data e hora (capítulo 10).

O primeiro sensor

  1. Abra Configurações e role até Sensores e GPIO.
  2. Toque em + Adicionar slot de sensor.
  3. Escolha o tipo, o GPIO de cada pino, o ID de Hardware e o Nome, e ligue Ativo.
  4. Toque em Concluído e depois em Salvar e reiniciar.

O passo a passo completo, com a busca de sondas e a calibração, está no capítulo 6. O sensor aparece no Painel de Controle depois das primeiras leituras.

release O mínimo e o máximo do cartão no painel dependem de o número do slot coincidir com o do GPIO. Veja a atenção de Os cartões antes de escolher os pinos.

air No Air, configure os sensores pela web com o aparelho acordado ou pelos comandos sensor do console (capítulo 14).

O PIN do painel

release O painel não usa senha: cada pessoa se identifica com a conta e um PIN. A conta admin sai de fábrica com o PIN 1234, que precisa ser trocado no primeiro uso (capítulo 8).

  1. Na tela inicial, toque em CFG, na barra de botões de baixo, logo depois do último sensor (capítulo 11).
  2. Na tela Quem está usando o painel?, toque em admin e depois em ENTRAR.
  3. Digite 1234 e toque em ENTRAR.
  4. O painel abre a tela Novo PIN. Digite o PIN novo e toque em ENTRAR.
Figura 16. A troca obrigatória do PIN de fábrica: a tela Novo PIN abre direto depois do 1234.

O tamanho mínimo e os caracteres do PIN seguem a política de PIN (capítulo 8). Para cada operador, crie uma conta com PIN e só as permissões de que ele precisa (capítulo 8).

Pronto para usar

Confira antes de entregar o aparelho:

  1. A senha do admin foi trocada e está guardada em lugar seguro.
  2. A conta viewer tem senha nova ou foi excluída (capítulo 8).
  3. O aparelho está na rede, e você sabe o endereço dele (Encontrar o endereço).
  4. A chave do ponto de acesso está anotada (capítulo 9).
  5. A hora está certa e o fuso é o do local (capítulo 10). release No painel, a data e a hora da barra de cima não têm o ? do relógio provisório.
  6. Há um só pacote de idioma na pasta /lang (capítulo 3).
  7. Cada sensor aparece no Painel de Controle com leituras plausíveis (capítulo 6).
  8. Os limites de alarme de cada sensor estão definidos (capítulo 7).
  9. release O PIN do admin não é mais 1234, e cada operador tem a sua conta com PIN (capítulo 8).
  10. A telemetria e a linha de alarmes estão configuradas, se houver servidor (capítulo 21, capítulo 22).
  11. Um backup da configuração foi baixado (capítulo 17).
  12. air O ciclo de hibernação foi conferido (capítulo 19).

Voltar ao sumário

Parte II

Configurar

Capítulo 5

Configuração pela web: os três botões e a página Configurações

Este capítulo explica como a interface web grava uma alteração de configuração, o que cada um dos três botões de gravação faz e quando o aparelho precisa reiniciar. Depois, percorre a página Configurações campo a campo. É para quem configura o aparelho pelo navegador.

Como uma alteração é gravada

Nas páginas de configuração, nada é gravado enquanto você digita. Cada campo alterado vira uma alteração preparada, guardada na aba do navegador. As páginas Configurações, Alarmes e Sons, Telemetria, Rede e Usuários preparam alterações no mesmo conjunto: você pode alterar um limite de alarme, passar para a página Rede, alterar o DNS e gravar tudo de uma vez.

O conjunto preparado:

  • sobrevive à troca de página e ao recarregar a página, dentro da mesma aba;
  • some se você fechar a aba, tocar em Sair ou entrar de novo;
  • não é visto por outra aba, outro navegador ou outra pessoa.

Na primeira alteração de um conjunto novo, um aviso lembra: Clique em “Salvar e Reiniciar” para aplicar as alterações. (Click “Save & Restart” to apply your changes.). A partir daí, a barra de topo mostra um selo e os botões de gravação (capítulo 13). No celular, eles ficam numa barra fixa no rodapé.

Os campos de cada página mostram o valor gravado no aparelho, com as alterações preparadas por cima. O que aparece na página é o que será gravado.

O ensaio: o aparelho decide

Cerca de 0,6 s depois da última alteração, a página envia o conjunto preparado ao aparelho como um ensaio (o parâmetro _dry=1). O aparelho aplica todas as verificações de faixa e de formato numa cópia da configuração, compara a cópia com a configuração em uso e responde quais grupos de configuração mudariam e se algum deles exige reinício. Nada é gravado e nada reinicia.

Quem decide é o aparelho, não a página. Um campo digitado de volta ao valor atual não conta como mudança.

O selo da barra de topo mostra a resposta:

Selo Quando Botões oferecidos
Alterações não salvas (Unsaved changes) O ensaio ainda não respondeu, ou o aparelho recusou o ensaio Só Salvar e reiniciar
Reinicia por: (Restarts for) seguido dos grupos O ensaio respondeu que algum grupo exige reinício Só Salvar e reiniciar
Não exige reinício (No restart needed) O ensaio respondeu que tudo se aplica sem reiniciar Testar, Aplicar agora e Salvar e reiniciar

O aparelho recusa o ensaio quando o conjunto inclui slots de sensor ou calibração (capítulo 6). Essas alterações só se gravam com Salvar e reiniciar. Contas (capítulo 8) passam pelo ensaio desde a v2.10.0, mas sem Testar: uma conta não se testa. No SIMUT Air, o ensaio é sempre recusado (No SIMUT Air).

Os grupos aparecem com o nome curto que o aparelho usa, em inglês, como time ou alarms. Com Não exige reinício, pare o ponteiro sobre o selo para ver a lista dos grupos. A tabela de Os grupos de configuração diz o que cada nome inclui.

Figura 17. Uma alteração que exige reinício: o selo diz Reinicia por: time e só o botão Salvar e reiniciar aparece.

Os três botões

Botão O que faz Depois
Testar (Test) Aplica as alterações à configuração em uso sem gravá-las (_nosave=1) O conjunto continua preparado. Um reinício volta aos valores gravados
Aplicar agora (Apply now) Grava e aplica, sem reiniciar O conjunto preparado é esvaziado
Salvar e reiniciar (Save & restart) Grava e reinicia o aparelho, sempre (_reboot=1) O conjunto preparado é esvaziado e a página se recarrega

Testar e Aplicar agora só aparecem quando o ensaio respondeu Não exige reinício. Salvar e reiniciar aparece sempre que há alteração preparada, e reinicia mesmo quando a alteração se aplicaria sem reinício.

Para experimentar uma alteração sem gravá-la:

  1. Faça a alteração, por exemplo um limite de alarme.
  2. Espere o selo mostrar Não exige reinício.
  3. Toque em Testar.

O aviso Aplicado SEM salvar — um reinício desfaz (Applied WITHOUT saving — a restart undoes it) aparece, seguido dos grupos aplicados. A barra de gravação continua visível, porque a alteração ainda não está gravada. Para mantê-la, toque em Aplicar agora. Para desistir dela, toque em Sair ou feche a aba e reinicie o aparelho.

Para gravar sem reiniciar:

  1. Faça as alterações.
  2. Espere o selo mostrar Não exige reinício.
  3. Toque em Aplicar agora.

O aviso Aplicado e salvo (Applied and saved) aparece, seguido dos grupos aplicados. A sessão continua aberta e o aparelho não sai do ar.

Para gravar e reiniciar:

  1. Faça as alterações.
  2. Toque em Salvar e reiniciar.
  3. Leia a confirmação e toque em OK.

A confirmação diz: Isto salvará todas as alterações e reiniciará o sistema. O dispositivo ficará offline por ~10 segundos. Qualquer gravação de histórico/log em andamento será interrompida. Continuar? Depois de OK, aparece Salvo! Reiniciando sistema… (Saved! Restarting system…) e a página se recarrega sozinha cerca de 12 s depois (O que um reinício custa).

Se há uma calibração preparada (capítulo 6), Salvar e reiniciar primeiro envia a calibração ao aparelho e só depois grava o resto. Se a calibração falha, nada é gravado e aparece Erro na calibração: seguido do motivo, ou Tempo esgotado na calibração. Tente novamente.

Figura 18. Uma alteração que se aplica sem reinício: o selo diz Não exige reinício e os três botões aparecem.
Figura 19. A confirmação de Salvar e reiniciar, que avisa quanto tempo o aparelho fica fora do ar.

Os grupos de configuração

O aparelho classifica cada alteração comparando a configuração de antes com a de depois, campo por campo. Um grupo só se aplica sem reinício quando o firmware relê aqueles campos a cada uso, ou tem uma função que empurra o valor novo para quem o usa. Todo o resto reinicia. Um campo que não pertence a nenhum grupo conhecido cai em unclassified e também reinicia. Quatro campos que nenhuma parte do firmware lê são a exceção: Amostra (ms), Registro Local e dois que só o arquivo de configuração carrega. O aparelho os reconhece, eles não entram em grupo nenhum e gravam sem reiniciar, desde a v2.7.4.

Grupo O que inclui Onde se altera Sem reinício?
alarms Limites de alarme por canal e alarmes ligados por slot Alarmes e Sons (capítulo 7) Sim
maint Janelas de manutenção Alarmes e Sons (capítulo 7) Sim
alarm_tel Linha de alarmes: ligada, fila, formato, modelos, Content-Type e caminho Telemetria (capítulo 22) Sim
telemetry Telemetria pelo lado HTTP: servidor, porta, caminho, chave, lote mínimo e máximo, formato, modelos e Content-Type Telemetria (capítulo 21) Sim
users Política de PIN do painel Configurações (Hardware) Sim
users Contas Usuários (capítulo 8) Sim, sem Testar
display Tema e idioma do painel Nenhuma página grava estes campos por aqui Sim
identity Nome do aparelho Configurações Não
time Fuso horário e servidor NTP Configurações, Rede Não
sensing Resolução do DS18B20 Configurações Não
slots Tipo, GPIOs, identificação e nome dos slots de sensor Configurações (capítulo 6) Não: o ensaio é recusado
net Wi-Fi, DHCP, IP estático, DNS primário Rede (capítulo 9) Não
mqtt Transporte, conta, senha e opções MQTT, e o TLS da telemetria Telemetria (capítulo 21) Não
web A área de extensão da configuração: porta web, conexões persistentes, sons, intervalo do histórico, NTP ligado, DNS automático e secundário, syslog e Home Assistant Várias Não
unclassified Qualquer diferença fora dos grupos acima — Não

O tema do painel tem gravação própria, pelo Painel de Controle, e não passa por estes botões (capítulo 13).

Valores recusados

O aparelho confere cada campo antes de gravar. Um valor fora da faixa ou com formato errado é descartado: o campo mantém o valor anterior, e o resto da gravação continua.

  • Depois de Testar ou Aplicar agora, o aviso Campos não aplicados: (Fields not applied) lista as chaves recusadas, como s_int ou net.dns2.
  • Depois de Salvar e reiniciar, a página se recarrega sem esse aviso. Confira os campos alterados depois do reinício.

Alguns erros recusam a gravação inteira, e nada muda. O aviso é Falha ao salvar. (Save failed.) seguido do motivo e, quando existe, da seção entre parênteses. Os casos:

Resposta Motivo
Alarm limit outside channel range Um limite de alarme fora da faixa possível do canal (capítulo 7)
Alarm limit is not a number Um limite de alarme que não é número. Só chega por um cliente da API: a página sempre manda números
O slot e o GPIO recusados, como slot 4: GP2 already used by slot 2 Conflito na atribuição de GPIO (capítulo 6)
Forbidden (<seção>) A conta não tem a permissão daquela seção (tabela abaixo)
Password change required A conta ainda precisa trocar a senha (capítulo 13)
Display in use. Retry shortly. Alguém tocou no painel há menos de 5 s. Espere e tente de novo
Bad payload O conjunto preparado passou de 6.144 bytes. Grave em partes

Cada seção do conjunto exige a sua permissão, e a gravação é tudo ou nada: se uma seção é proibida, nenhuma é gravada.

Seção Páginas que a preparam Permissão
sys Configurações e Telemetria Sistema PERM_SYS_CONFIG
slots, calib Configurações (sensores) Sistema PERM_SYS_CONFIG
alarms Alarmes e Sons Sistema PERM_SYS_CONFIG
net Rede Rede PERM_NET_CONFIG
users Usuários Usuários PERM_USER_MGR

O que um reinício custa

Um Salvar e reiniciar leva o aparelho para fora do ar por cerca de 10 s. Na ordem:

  1. O painel mostra Aplicando configurações… e depois Reiniciando o sistema…, cerca de 1,5 s cada.
  2. O aparelho grava a configuração, registra o evento e responde à página.
  3. O aparelho reinicia. Uma gravação de histórico ou de log em andamento é interrompida.
  4. A página se recarrega cerca de 12 s depois e mostra a página de entrada, porque um reinício encerra todas as sessões (capítulo 13).

Dois casos mudam o passo 4:

  • Porta web alterada: a página avisa Salvo. Redirecionando para nova porta… e, cerca de 15 s depois, abre o endereço com a porta nova (capítulo 9).
  • Conta criada ou senha redefinida: antes de recarregar, a página mostra a senha provisória de cada conta. Anote-a: ela não aparece de novo (capítulo 8).

Depois do reinício, o aparelho se reconecta ao Wi-Fi, acerta o relógio de novo (capítulo 10) e retoma a telemetria.

O log de eventos registra cada gravação com o código 303 (Config alterada), com um destes textos:

Texto Botão
Admin committed changes — rebooting Salvar e reiniciar, ou Aplicar agora quando algum grupo exigiu reinício
Admin committed changes — applied live Aplicar agora
Admin committed changes — applied live [nosave] Testar

No SIMUT Air

air

O Air recusa o ensaio e o Testar: a imagem do Air está no limite de memória de programa, e os dois caminhos que trabalham numa cópia da configuração ficaram de fora. Na barra de topo do Air, o selo fica em Alterações não salvas e só Salvar e reiniciar aparece. Toda gravação pela web reinicia o Air.

Lembre que a interface web do Air só existe enquanto ele está acordado em M0 (capítulo 13, capítulo 19).

Pela API

Os três botões usam a mesma rota, POST /api/commit_all, com o conjunto preparado no campo _payload. O que muda é o parâmetro extra:

Botão Parâmetro
Ensaio da página _dry=1
Testar _nosave=1
Aplicar agora nenhum
Salvar e reiniciar _reboot=1

A resposta diz o que aconteceu. Um ensaio de fuso horário, por exemplo:

{"status":"dry","reboot":true,"applied":["time"],"reboot_for":["time"]}

Um integrador pode usar o ensaio para validar uma configuração antes de mandá-la a vários aparelhos. O formato completo está no capítulo 26.

A página Configurações

A página Configurações (System Config, rota /config) exige a permissão Sistema. Ela tem sete seções, nesta ordem; a alpha e o Air não têm a sexta:

  1. Identidade (General Identity)
  2. Data e Hora (Date & Time)
  3. Hardware (Hardware & Sampling)
  4. Sensores e GPIO (Sensors & GPIO)
  5. Syslog Remoto (Auditoria) (Remote Syslog (Audit Trail))
  6. release Calibração do Touch (Touch Calibration)
  7. Reiniciar (Restart)

As cinco primeiras preparam alterações para os botões da barra de topo. A página não tem botão de gravar próprio. Calibração do Touch e Reiniciar agem na hora, cada uma com botão próprio.

Se a página não consegue ler a configuração do aparelho, ela mostra uma faixa vermelha: Não foi possível carregar as configurações atuais. Os campos estão desabilitados para evitar salvar valores em branco sobre a sua configuração. Os campos ficam desabilitados, de propósito. Toque em Tentar novamente (Retry). A página já tenta três vezes antes de mostrar a faixa.

A página Configurações aberta, com as seções Identidade e Data e Hora.
Figura 20. A página Configurações aberta, com as seções Identidade e Data e Hora.
Figura 21. A faixa de erro de carga: os campos ficam desabilitados para que nada em branco seja gravado.

Identidade

Campo O que faz Faixa e formato Fábrica Aplicação Chave
Nome (Device Name) Nome do aparelho 1 a 31 caracteres, sem aspas " nem barra invertida \; espaços nas pontas são removidos simut Reinicia (identity) name
Fuso Horário (Timezone Offset (Hours)) Diferença do horário local para o UTC, em horas inteiras −12 a +14 −3 Reinicia (time) tz
Registro Local (Enable Local Logging) Preferência de registro local, sem efeito Ligado ou desligado Ligado Grava sem reiniciar log

O Nome aparece em vários lugares:

  • no nome da rede do ponto de acesso de configuração, seguido de _SETUP (capítulo 9);
  • no endereço mDNS, seguido de .local (release, capítulo 9);
  • no nome Bluetooth (alpha air, capítulo 14);
  • no campo de origem das mensagens de syslog (capítulo 25) e no rótulo das métricas Prometheus (capítulo 24);
  • na etiqueta {DEV} da telemetria (capítulo 21);
  • em show system info, no console.

Como o nome vira endereço de rede e nome de rede Wi-Fi, prefira letras sem acento, números e hífen.

O Fuso Horário não tem horário de verão nem frações de hora. Detalhes, e um efeito colateral de digitar neste campo, estão no capítulo 10.

Data e Hora

Campo O que faz Faixa e formato Fábrica Aplicação Chave
Sincronizar automaticamente via NTP (Synchronize automatically via NTP) Liga o acerto do relógio pela rede Ligado ou desligado Ligado Reinicia (web) ntp_enabled
Data (Date) Data para o acerto manual A partir de 01/01/2026 A data do aparelho ao abrir a página Na hora, pelo botão Aplicar Agora —
Hora (Time) Hora para o acerto manual, com segundos hh:mm:ss A hora do aparelho ao abrir a página Na hora, pelo botão Aplicar Agora —

O botão Aplicar Agora (Apply Now) desta seção acerta o relógio imediatamente, sem passar pela barra de topo e sem reiniciar. Ele interpreta a data e a hora digitadas no fuso do campo Fuso Horário, como ele está na página. A resposta aparece abaixo do botão: Hora aplicada. (Time applied.), Falhou ao aplicar. (Failed to apply.) ou, com um campo vazio, Preencha data e hora. (Fill date and time.).

Com o NTP ligado, os campos de data e hora ficam esmaecidos, mas continuam editáveis: o acerto manual vale até a próxima sincronização. A dica abaixo do botão lembra: Usa fuso horário do dispositivo. Salve e Reinicie para persistir o toggle do NTP.

O funcionamento do relógio, do NTP e do acerto manual está no capítulo 10.

Figura 22. A seção Data e Hora com o NTP desligado, depois de um acerto manual.

Hardware

Campo O que faz Faixa e formato Fábrica Aplicação Chave
Resolução DS18B20 (DS18B20 Resolution) Resolução das sondas DS18B20 9-bit, 10-bit, 11-bit ou 12-bit 12 bits Reinicia (sensing) res
Amostra (ms) (Sample Interval (ms)) Sem efeito: o ritmo de leitura é fixo por tipo de sensor (capítulo 6) 1.000 a 60.000 ms 2.000 ms Grava sem reiniciar s_int
Intervalo Histórico (min) (History Recording Interval (min)) Intervalo entre registros gravados no histórico 1 a 1.440 min 1 min Reinicia (web) h_int
Teclado do painel: glifos por tecla (Panel keypad: glyphs per key) Quantos caracteres cada tecla do PIN mostra 1, 2 ou 3 3 Reinicia (users) pin_kb
Caracteres do PIN (PIN characters) Alfabeto do PIN 0-9 ou 0-9 A-Z 0-9 Reinicia (users) pin_alpha
Tamanho mínimo do PIN (Minimum PIN length) Menor PIN aceito 4 até o teto do teclado: 16 com 1 glifo, 12 com 2, 8 com 3 4 Reinicia (users) pin_min

Sobre a resolução: nesta versão, o aparelho espera 750 ms por leitura do DS18B20 em qualquer resolução. Baixar a resolução reduz a precisão sem encurtar a leitura. Detalhes no capítulo 6.

A dica abaixo de Intervalo Histórico (min) diz: 1 a 1440 min (24h). Padrão: 1. air No Air, esse intervalo é também o intervalo entre despertares, porque a tarefa principal de cada despertar é gravar um registro (capítulo 19).

release Os três campos do PIN formam a política de PIN do painel e só aparecem na imagem release, que é a única com painel de toque. Eles se validam juntos: o teto do tamanho mínimo muda com o teclado, e a dica abaixo do campo mostra a faixa permitida, como 4 – 8. Pela web, salvar uma política nova reinicia o aparelho, porque ela pertence à classe users. Pelo painel (Configurações, linha 11), a mesma mudança vale na próxima tela de PIN, sem reinício. Uma política mais exigente marca as contas com PIN para escolher um PIN novo. O significado de cada teclado está no capítulo 8.

A seção Hardware na imagem release, com a política de PIN do painel.
Figura 23. A seção Hardware na imagem release, com a política de PIN do painel.

Sensores e GPIO

A seção Sensores e GPIO (Sensors & GPIO) configura os 16 slots de sensor. Ela é descrita inteira no capítulo 6. Em resumo:

  • a dica GP0–GP15 estão disponíveis para sensores; GP16 em diante pertencem ao display, ao touch e ao buzzer.;
  • um mapa dos GPIOs em uso;
  • a tabela dos slots, com as colunas Slot, Tipo, GPIOs, ID de Hardware e Nome;
  • os botões + Adicionar slot de sensor e Procurar sondas;
  • o editor de slot, com Tipo, Nome, ID de Hardware, Estado (Ativo e Alarmes habilitados), Atribuição de GPIO, Calibração, Gravação no histórico e Hardware, e os botões Liberar slot, Descartar alterações e Concluído.

Alterações de slot e de calibração só se gravam com Salvar e reiniciar. Com os 16 slots em uso, a página diz Os 16 slots estão em uso. Libere um para adicionar outro.

A seção Sensores e GPIO, com o mapa de GPIOs e a tabela de slots. O editor de slot está no capítulo 6.
Figura 24. A seção Sensores e GPIO, com o mapa de GPIOs e a tabela de slots. O editor de slot está no capítulo 6.

Syslog Remoto (Auditoria)

Esta seção envia os eventos do log a um coletor syslog na rede, para que a trilha de auditoria exista também fora do aparelho. A dica diz que o envio segue a RFC 5424 sobre UDP, que o servidor é um IPv4 da rede local e não um nome, e que não há garantia de entrega.

Campo O que faz Faixa e formato Fábrica Aplicação Chave
Habilitar encaminhamento syslog (Enable syslog forwarding) Liga o envio Ligado ou desligado Desligado Reinicia (web) slog_en
IP do Coletor (Collector IP) Endereço do coletor IPv4, como 192.0.2.10; vazio desliga Vazio Reinicia (web) slog_srv
Porta UDP (UDP Port) Porta do coletor 1 a 65535 514 Reinicia (web) slog_port
Nível Mínimo (Minimum Level) Menor nível enviado Debug, Info, Warning, Error ou Fatal Info Reinicia (web) slog_lvl

Com o interruptor ligado e o IP do Coletor vazio, nada é enviado. O formato das mensagens e a configuração do coletor estão no capítulo 25.

As duas últimas seções da página: o syslog e a calibração do touch.
Figura 25. As duas últimas seções da página: o syslog e a calibração do touch.

Calibração do Touch

release

O botão Resetar Calibração (Reset Touch Calibration) apaga a calibração do toque guardada e abre o assistente de calibração no painel. Ele age na hora, sem passar pela barra de topo:

  1. Toque em Resetar Calibração.
  2. Confirme em Resetar calibração do touch para padrão de fábrica?
  3. Vá até o painel e siga os passos do assistente (capítulo 11).

O aviso Calibração resetada. Recalibre pelo display. confirma. Se alguém tocou no painel há menos de 5 s, aparece Display em uso. Tente novamente em alguns segundos. O log de eventos registra Touch calibration reset via web com o código 303.

A seção só aparece na imagem release, a única com painel de toque. Até a v2.7.3 ela aparecia também na alpha e no Air, onde o botão apagava o registro de calibração guardado e dizia que o assistente estava rodando num painel que não existe.

Reiniciar

Desde a v2.7.3, a última seção da página tem o botão Reiniciar sem salvar (Restart without saving). Ele reinicia o aparelho sem gravar nada: o que está pendente na barra de topo é descartado, e o que foi aplicado com Testar também se desfaz, porque o aparelho volta com a configuração gravada. Ele age na hora, sem passar pela barra de topo:

  1. Toque em Reiniciar sem salvar.
  2. Confirme em Reiniciar agora SEM salvar? O aviso lembra que as alterações não salvas nesta página serão perdidas e que o aparelho fica fora do ar por cerca de 10 s.

O aviso Reiniciando… confirma, e a página se recarrega cerca de 12 s depois, na página de entrada, porque o reinício encerra as sessões. Medido em 25/09/2026: o aparelho saiu do ar 3,3 s depois do clique e voltou a responder aos 26,4 s. O log de eventos registra o código 2 (Reboot solicitado pelo usuário).

Se alguém tocou no painel há menos de 5 s, aparece Display em uso. Tente novamente em alguns segundos. e nada acontece. Se o aparelho recusar o pedido, aparece Não foi possível reiniciar. e ele continua no ar.

Referência rápida

Todos os campos da página Configurações que passam pela barra de topo, na seção sys de POST /api/commit_all. Os campos da página Telemetria estão no capítulo 21 e no capítulo 22; os da página Rede, no capítulo 9.

Chave Campo Faixa Fábrica Grupo
name Nome 1 a 31 caracteres simut identity, reinicia
tz Fuso Horário −12 a +14 −3 time, reinicia
log Registro Local 1 ou 0 1 nenhum, grava sem reiniciar
ntp_enabled Sincronizar automaticamente via NTP 1 ou 0 1 web, reinicia
res Resolução DS18B20 9 a 12 12 sensing, reinicia
s_int Amostra (ms) 1000 a 60000 2000 nenhum, grava sem reiniciar
h_int Intervalo Histórico (min) 1 a 1440 1 web, reinicia
pin_kb Teclado do painel: glifos por tecla 1 a 3 3 users, reinicia
pin_alpha Caracteres do PIN 0 (0-9) ou 1 (0-9 A-Z) 0 users, reinicia
pin_min Tamanho mínimo do PIN 4 ao teto do teclado 4 users, reinicia
slog_en Habilitar encaminhamento syslog 1 ou 0 0 web, reinicia
slog_srv IP do Coletor IPv4 ou vazio vazio web, reinicia
slog_port Porta UDP 1 a 65535 514 web, reinicia
slog_lvl Nível Mínimo 0 (Debug) a 4 (Fatal) 1 (Info) web, reinicia

As três chaves pin_* só existem na imagem release. Nas outras, a página não as envia.

Voltar ao sumário

Capítulo 6

Sensores e calibração

Este capítulo mostra como dizer ao aparelho quais sensores estão ligados e em quais pinos, como ele valida cada leitura e como corrigir um sensor contra um instrumento de referência. É para quem instala e mantém o aparelho; os limites de alarme de cada grandeza estão no capítulo 7.

Onde os sensores são configurados

Os sensores ficam na página Configurações (System Config, rota /config), em duas seções:

  • Hardware (Hardware & Sampling): a resolução do DS18B20, o intervalo do histórico e a política de PIN do painel;
  • Sensores e GPIO (Sensors & GPIO): a lista de slots e o editor de cada um.

A página exige a permissão Sistema PERM_SYS_CONFIG. A calibração, dentro do editor de slot, exige também a permissão Calibração PERM_CALIB; sem ela, o editor abre sem o bloco de calibração e não mostra erro (Requisitos da calibração).

Tudo o que você muda nestas seções fica preparado na aba do navegador até você gravar. Os três botões de gravação estão no capítulo 5. Mudanças de slot e de calibração só são gravadas com Salvar e reiniciar (Save & restart): o aparelho não aceita testá-las nem aplicá-las sem reiniciar.

A seção Hardware

A seção Hardware com os valores de fábrica: resolução de 12 bits, amostra de 2000 ms, histórico a cada 1 min e a política de PIN.
Figura 26. A seção Hardware com os valores de fábrica: resolução de 12 bits, amostra de 2000 ms, histórico a cada 1 min e a política de PIN.
Campo O que faz Faixa Fábrica Reinicia
Resolução DS18B20 (DS18B20 Resolution) Resolução da conversão de temperatura das sondas DS18B20 9-bit, 10-bit, 11-bit, 12-bit 12-bit Sim
Amostra (ms) (Sample Interval (ms)) Gravado, mas sem efeito (Amostra (ms)) 1000 a 60000 2000 Não, desde a v2.7.4
Intervalo Histórico (min) (History Recording Interval (min)) De quantos em quantos minutos o histórico grava um registro 1 a 1440 1 Sim
Teclado do painel: glifos por tecla Política de PIN do painel 1, 2 ou 3 3 Não, desde a v2.10.0
Caracteres do PIN Política de PIN do painel 0-9 ou 0-9 A-Z 0-9 Não, desde a v2.10.0
Tamanho mínimo do PIN Política de PIN do painel 4 até o teto do teclado 4 Não, desde a v2.10.0

Os três campos de PIN estão explicados no capítulo 8. Nas imagens alpha e Air, que não têm painel com toque, a página esconde esses três campos.

Resolução DS18B20

A resolução define o menor passo da temperatura medida pelo DS18B20: 9 bits é o passo mais grosso e 12 bits o mais fino. O aparelho envia a resolução na partida, pelo GPIO do primeiro slot DS18B20 ativo. Uma sonda DS18B20 ligada a outro GPIO não recebe o ajuste.

O aparelho sempre espera 750 ms pela conversão, que é o tempo da resolução de 12 bits. Uma resolução menor, portanto, não deixa a leitura mais rápida.

Amostra (ms)

Intervalo Histórico (min)

É o intervalo entre dois registros do histórico, de 1 min a 1440 min (24 h). O valor de fábrica é 1 min. O que o histórico grava em cada registro está em Leitura e histórico, e o histórico em si no capítulo 15.

A seção Sensores e GPIO

A seção Sensores e GPIO. A faixa de GP0 a GP15 mostra quais pinos estão ocupados e por qual slot; a tabela lista só os slots em uso.
Figura 27. A seção Sensores e GPIO. A faixa de GP0 a GP15 mostra quais pinos estão ocupados e por qual slot; a tabela lista só os slots em uso.

A seção mostra, de cima para baixo:

  • o aviso GP0–GP15 estão disponíveis para sensores; GP16 em diante pertencem ao display, ao touch e ao buzzer.;
  • a faixa de pinos, de GP0 a GP15. Um pino ocupado aparece destacado, com o número do slot dono ao lado;
  • a tabela de slots;
  • os botões + Adicionar slot de sensor (+ Add sensor slot) e Procurar sondas (Scan for probes).

A faixa e a tabela mostram o estado que o aparelho terá depois de gravar, e não o estado gravado: um slot com alteração pendente aparece com fundo destacado.

A tabela tem uma linha por slot em uso:

Coluna O que mostra
Slot O número do slot, de 0 a 15, e um ponto verde quando o slot está ativo
Tipo O tipo do sensor
GPIOs Os pinos atribuídos, como GP4 GP5
ID de Hardware A chave do sensor no histórico e na telemetria
Nome O nome dado ao slot

Toque numa linha para abrir o editor daquele slot. Sem nenhum slot em uso, a tabela diz Nenhum slot de sensor configurado ainda. Com os 16 slots em uso, o botão de adicionar some e aparece Os 16 slots estão em uso. Libere um para adicionar outro. Se a página não conseguir ler os slots do aparelho, mostra Não foi possível carregar os slots de sensores.; recarregue a página.

Slots

O aparelho tem 16 slots, numerados de 0 a 15. Um slot é uma posição da configuração, não um pino: ele guarda o tipo do sensor, os GPIOs que o sensor usa (de 1 a 4), a identificação e os limites de alarme. O número do slot é a identidade do sensor para o histórico, para o console serial e para a linha de alarmes, por isso a página o mostra.

De fábrica, os 16 slots estão vazios e nenhum GPIO está ocupado.

Tipos de sensor

Todas as imagens (release, alpha e Air) trazem os quatro tipos:

Tipo Pinos no editor Grandezas
DS18B20 1: 1-Wire Temperatura
DHT22 1: Data Temperatura e umidade
BME280 2: SDA e SCL Temperatura, umidade e pressão
BMP280 2: SDA e SCL Temperatura e pressão

Sobre os sensores I²C (BME280 e BMP280):

  • Um por par de pinos. A leitura aceitaria dois sensores no mesmo par SDA/SCL, em 0x76 e 0x77, mas a gravação recusa dois slots ativos no mesmo GPIO. Dê a cada sensor o seu par, e siga as regras do I²C do capítulo 2: um segundo sensor em outro par do mesmo periférico é lido pelo PIO, mais devagar.
  • O aparelho confere o chip. Se você escolheu BME280 e o chip é um BMP280, ou o contrário, o aparelho corrige o tipo na partida pelo identificador do chip e grava a correção.
  • Pares do periférico I²C. Com SDA e SCL num par que o periférico I²C do RP2040 aceita, a leitura usa esse periférico. Em outros pares, o aparelho lê o sensor pelo PIO do RP2040, sem o periférico. A ligação está no capítulo 2.

O editor de slot

Figura 28. O editor de um slot DS18B20: tipo, nome, ID de hardware, estado, o pino 1-Wire, o bloco de calibração e as operações de hardware.

O editor abre sobre a página. Para fechá-lo, toque no × do canto, toque fora da caixa ou toque em Concluído (Done). Fechar não descarta nada: as edições continuam preparadas.

Campo O que é Regras
Tipo (Type) O tipo do sensor. — vazio — deixa o slot sem sensor Os tipos da tabela acima
Nome (Name) Nome livre, mostrado no painel, na página e nos gráficos Até 31 caracteres, sem aspas, sem barra invertida e sem caracteres de controle
ID de Hardware (Hardware ID) A chave do sensor no histórico e na telemetria De 1 a 15 caracteres: letras sem acento, dígitos, _ e -. Obrigatório num slot ativo
Ativo (Active) Liga o slot. Só um slot ativo ocupa GPIOs e é lido Exige tipo, todos os pinos e o ID de hardware
Alarmes habilitados (Alarms enabled) Liga os alarmes de limite do slot (capítulo 7) Ligado de fábrica
Atribuição de GPIO (GPIO assignment) Um seletor por pino do tipo, como Pino 0 — SDA GP0 a GP15. Um GPIO de outro slot ativo aparece desativado, como GP7 (slot 3)

Abaixo dos campos, o editor mostra, nesta ordem:

  • o bloco Calibração (Calibration), só para slots ativos já gravados e só para contas com a permissão Calibração (Calibração);
  • Gravação no histórico (History recording), com o botão Recompor o histórico agora (Recompor o histórico);
  • Hardware, com Adotar a sonda ligada aqui (só para DS18B20) e Resetar época do histórico (Operações de hardware);
  • uma linha de aviso em vermelho, quando há um problema;
  • os botões Liberar slot (Free slot), Descartar alterações (Discard staged) e Concluído;
  • o lembrete As edições são acumuladas conforme você digita e gravadas ao Salvar e Reiniciar.

Se você ativar um slot sem digitar o ID de hardware, o aparelho recusa a gravação (Erros ao gravar). Um slot ativo que chegue à partida sem ID, gravado por outro caminho que não esta página, recebe um ID automático: o tipo seguido do número do slot com dois dígitos, como DHT2202 para um DHT22 no slot 2. Se o nome também estiver vazio, ele vira o tipo e o slot, como DHT22 #2.

Adicionar um sensor

  1. Abra Configurações e role até Sensores e GPIO.
  2. Toque em + Adicionar slot de sensor. O editor abre no slot livre de menor número.
  3. Escolha o Tipo. O formulário ganha um seletor para cada pino do tipo.
  4. Escolha o GPIO de cada pino em Atribuição de GPIO.
  5. Digite o ID de Hardware, por exemplo FREEZER-1.
  6. Digite o Nome, por exemplo Freezer da sala 2.
  7. Ligue Ativo.
  8. Confira se a linha de aviso vermelha está vazia.
  9. Toque em Concluído.
  10. Toque em Salvar e reiniciar na barra de topo e confirme.

O aparelho reinicia, e a página se recarrega sozinha. O sensor aparece no Painel de Controle e no painel logo depois das primeiras leituras.

Figura 29. Um slot novo de BME280 no celular: dois seletores de pino, SDA e SCL.

Um DS18B20 criado pela página não conhece ainda o número de série da sonda. Na partida seguinte, o aparelho lê esse número (a ROM) no pino, liga o slot a ele e grava. A partir da partida seguinte a essa, o aparelho passa a conferir a sonda (Como o aparelho valida as leituras).

Editar um sensor

  1. Na tabela, toque na linha do slot.
  2. Mude os campos.
  3. Toque em Concluído.
  4. Toque em Salvar e reiniciar.

Para desistir das mudanças de um slot antes de gravar, abra o editor dele e toque em Descartar alterações. O botão descarta também as mudanças de calibração desse slot e relê o que está gravado no aparelho.

Ao trocar o Tipo de um slot, o aparelho trata o sensor como outro: grava a data da troca como a época do slot (Resetar época do histórico) e apaga a ROM guardada.

Desligar sem apagar

Para parar de ler um sensor sem perder sua configuração, desligue Ativo e grave com Salvar e reiniciar. O slot continua na tabela, sem o ponto verde, e seus GPIOs ficam livres para outros slots.

Remover um sensor

  1. Na tabela, toque na linha do slot.
  2. Toque em Liberar slot.
  3. Confirme a pergunta Liberar este slot? Tipo, GPIOs e identificação serão apagados.
  4. Toque em Salvar e reiniciar.

O slot volta a ficar vazio e sai da tabela. O histórico já gravado continua no aparelho. As correções de calibração do sensor continuam no arquivo calib.csv.

Erros ao gravar

O editor confere as regras enquanto você digita e mostra o primeiro problema na linha vermelha:

Aviso no editor O que fazer
Escolha um tipo antes de ativar este slot. Escolha o Tipo ou desligue Ativo
Atribua um GPIO ao pino 0 (SDA). Escolha o GPIO do pino indicado
GP4 já está em uso pelo slot 2. Escolha outro GPIO, ou libere o pino no outro slot

Na gravação, o aparelho confere as mesmas regras e mais algumas. Se alguma falhar, nada é gravado, o aparelho não reinicia, e a página mostra Falha ao salvar. (Save failed.) seguido do motivo, em inglês:

Motivo mostrado Causa
slot N: set a type before enabling Slot ativo sem tipo
slot N: pin K (SDA) not assigned Falta o GPIO de um pino do tipo
slot N: GPx already used by slot M Dois slots ativos no mesmo GPIO
slot N: GPx not a sensor pin (0-15) GPIO acima de GP15, enviado por outro meio que não a página
slot N: hardware ID cannot be empty on an active slot Slot ativo sem ID de Hardware
slot N: invalid hwId O ID tem caractere fora de letras, dígitos, _ e -, ou mais de 15 caracteres
slot N: invalid name O nome tem aspas, barra invertida ou caractere de controle
slot N: driver not in firmware Tipo que esta imagem não traz
Figura 30. O editor avisando um conflito de GPIO antes da gravação.

Procurar sondas

O botão Procurar sondas varre os pinos do aparelho em busca de sensores ligados. Ele só informa o que encontrou: não cria nem muda nenhum slot.

  1. Toque em Procurar sondas. O botão fica desativado e a página mostra Procurando… (Scanning…).
  2. Espere o resultado, que chega em poucos segundos. A página espera no máximo 10 s.
  3. Leia a lista, como 2 encontrada(s): GP2 (28FF641E8716045C), GP3.
Resultado O que é
GPn ( ROM ) Um DS18B20 no pino n; o código entre parênteses é a ROM da sonda
GPn sem ROM Um sensor que respondeu como DHT22 no pino n
GP255 Um BME280 ou BMP280 nos pinos GP4 (SDA) e GP5 (SCL)
Nenhuma sonda respondeu. (No probes answered.) Nada respondeu, ou a busca não terminou em 10 s
Falha na ação. (Action failed.) O aparelho recusou ou não respondeu

A busca por BME280 e BMP280 olha só o par GP4/GP5. Um sensor I²C em outros pinos não aparece na busca, mas funciona se você configurar o slot à mão.

Figura 31. O resultado da busca: a ROM identifica o DS18B20; o DHT22 aparece só com o pino.

Grandezas e unidades

Cada slot informa uma ou mais grandezas, que o aparelho chama de canais:

Grandeza Chave Unidade Faixa aceita na calibração Limites de alarme de fábrica
Temperatura temp °C −327,68 a 327,66 0 a 40
Umidade hum % 0 a 102,3 20 a 80
Pressão press hPa 0 a 1.638,3 a faixa inteira
Luminosidade lux lx 0 a 167.772,15 a faixa inteira

A chave é o nome da grandeza na interface de programação, na telemetria e no arquivo de calibração. Na página, os rótulos curtos são Temp, Umid, Press e Luz.

A luminosidade existe na tabela de grandezas, mas nenhum dos quatro tipos de sensor a informa na v2.7.1.

Leitura e histórico

O aparelho lê cada sensor no seu próprio ritmo e grava o histórico no ritmo do Intervalo Histórico. São duas coisas diferentes.

Ritmo de leitura. É fixo por tipo:

Tipo Pausa entre leituras
DS18B20 1 s, mais os 750 ms da conversão
DHT22 2 s
BME280 e BMP280 5 s

Média. Cada grandeza guarda as últimas 10 leituras. Com as 10 guardadas, o aparelho descarta as 2 menores e as 2 maiores e tira a média das 6 restantes. Antes disso, logo depois da partida, usa a média simples do que tem. A correção de calibração é aplicada sobre essa média. O resultado é o valor que o painel, a página e a telemetria mostram.

Histórico. A cada Intervalo Histórico, o aparelho grava um registro com o valor corrigido de cada grandeza naquele instante. Um sensor em erro entra no registro sem valor. O primeiro registro depois de um reinício não espera o intervalo inteiro, desde que o relógio já esteja acertado.

air No Air, o aparelho lê os sensores a cada despertar (capítulo 19).

Como o aparelho valida as leituras

Uma leitura falha quando o sensor não responde, quando a conferência dos dados falha ou quando o valor está fora do que o aparelho aceita:

Tipo O que o aparelho confere
DS18B20 O CRC da leitura. Temperatura fora de −50 a 150 °C é recusada. A cada 5 leituras, confere se a sonda no pino é a mesma cuja ROM está gravada
DHT22 A soma de verificação. Sem resposta em 150 ms, a leitura falha
BME280 e BMP280 Temperatura fora de −40 a 85 °C faz a leitura falhar. Umidade fora de 0 a 100 % e pressão fora de 300 a 1.100 hPa são descartadas, só naquela grandeza

Um valor que não é número (infinito, indefinido) nunca entra na média.

Estado de erro. Um sensor entra em erro depois de 3 falhas seguidas e sai dele depois de 5 leituras boas seguidas. Enquanto está em erro, o aparelho não usa as leituras dele.

Sonda trocada. Um DS18B20 com ROM gravada só é lido se a sonda no pino for a mesma. Se outra sonda aparecer, o slot entra em erro na hora, em quarentena. A cada 10 ciclos de leitura, o aparelho relê a ROM do pino. Quando a sonda certa volta, a quarentena acaba sozinha e o log registra Hardware match restored. Para aceitar a sonda nova, use Adotar a sonda ligada aqui (Operações de hardware). Um DS18B20 sem ROM gravada aceita qualquer sonda no pino.

O log de eventos registra a entrada em erro, com o GPIO do sensor (capítulo 16):

Código Evento Causa típica
101 Timeout de sensor DHT22 sem resposta
102 Erro de checksum DHT22 com dados corrompidos
103 Erro de CRC DS18B20 com dados corrompidos ou sem resposta
104 Sensor fora de range DS18B20 fora de −50 a 150 °C
105 Divergência de hardware Outra sonda no pino de um DS18B20
999 Erro desconhecido Falha de leitura de um BME280 ou BMP280, ou falha ao ler a ROM do DS18B20
100 Sensor recuperado 5 leituras boas depois de um erro

Como o erro aparece

  • Painel release: o cartão do sensor mostra Erro (ERROR) em letras grandes, no lugar do valor. O alarme de falha deixa o cartão âmbar (capítulo 7).
  • LCD alpha: quando o LCD chega ao sensor em erro, mostra ERRO em letras grandes. O mesmo ERRO aparece quando não há nenhum sensor ativo.
  • Interface web: na tabela de sensores do Painel de Controle, o ponto fica vermelho e a leitura mostra Error (capítulo 13).
  • Histórico: os registros do período em erro ficam sem valor para aquele sensor.
Figura 32. A tela inicial do painel com dois sensores lendo normalmente.
Figura 33. Um sensor em erro no painel: o cartão mostra Erro no lugar da temperatura e fica âmbar pelo alarme de falha.
Figura 34. O LCD do alpha com o sensor em erro.

Operações de hardware

As operações da seção Hardware do editor agem no aparelho na hora. Elas não passam por Salvar e reiniciar.

Adotar a sonda ligada aqui

Só aparece em slots DS18B20. Use depois de trocar uma sonda, quando o slot está em quarentena por divergência de hardware.

  1. Abra o editor do slot.
  2. Toque em Adotar a sonda ligada aqui (Adopt the probe wired here).

O aparelho lê a ROM da sonda no GPIO do slot, liga o slot a ela, grava e recarrega os sensores: a leitura segue com a sonda nova na hora, sem reiniciar. O GPIO do slot não muda. Se a ROM já constar do arquivo calib.csv, o slot recebe o ID de hardware e o nome guardados para ela; se não constar, recebe o ID LIB_SENS. Quando o ID muda, o aparelho grava a data como a época do slot (Resetar época do histórico).

Mensagem Significado
Slot vinculado à sonda encontrada nele. A sonda foi adotada
Nenhuma sonda respondeu neste GPIO. Nada respondeu no GPIO do slot
A sonda respondeu com uma ROM inválida. A ROM lida falhou na conferência
Salve antes este slot como um DS18B20 ativo. O slot gravado no aparelho não é um DS18B20 ativo: por exemplo, o tipo foi escolhido no editor e ainda não foi salvo

Resetar época do histórico

Grava o instante atual como a época do slot: a data em que o sensor atual começou nele. Use quando trocar o sensor físico de um slot, para registrar a troca.

  1. Abra o editor do slot.
  2. Toque em Resetar época do histórico (Reset history epoch).
  3. Confirme a pergunta. A página mostra Época do histórico resetada.

Recompor o histórico

O botão Recompor o histórico agora (Rebind history now) vale para o aparelho inteiro, não só para o slot aberto. Ele reescreve o arquivo de histórico do dia para os slots gravados, mantém os registros já feitos e reinicia o aparelho no fim. O histórico está no capítulo 15.

  1. Grave antes as mudanças pendentes. Com alguma pendente, a página recusa e mostra Salve e Reinicie antes — recompor agora usaria a configuração anterior.
  2. Toque em Recompor o histórico agora e confirme.
  3. Espere a mensagem Histórico reescrito seguida da contagem. A página se recarrega cerca de 25 s depois.

Se o arquivo do dia não puder ser lido, a página pergunta se deve recriá-lo vazio. Recriar perde os registros de hoje; os dias anteriores ficam intactos. Se o aparelho não responder, a página mostra Sem resposta do dispositivo. Recarregue a página e confira o log antes de tentar de novo.

Calibração

A calibração corrige a leitura de um sensor para que ela coincida com a de um instrumento de referência. Cada grandeza de cada sensor tem a sua correção: um BME280 tem três, uma para temperatura, uma para umidade e uma para pressão.

A correção é feita por pontos. Cada ponto liga um valor bruto, o que o sensor leu, ao valor de referência, o que o instrumento confiável mostrou no mesmo momento. Uma grandeza aceita até 5 pontos.

Pontos O que o aparelho faz
Nenhum Nenhuma correção. Vale a leitura do sensor
1 Soma uma diferença constante, o offset, a toda leitura
2 a 5 Muda a correção entre os pontos, conforme a interpolação escolhida

Abaixo do menor valor bruto e acima do maior, a correção fica igual à do ponto da ponta. O aparelho nunca projeta uma inclinação para fora da faixa medida.

Reta ou Suave

A Interpolação (Interpolation) define como a correção passa de um ponto ao outro:

  • Reta (Straight): linhas retas entre os pontos. É a escolha de fábrica.
  • Suave (Smooth): uma curva cúbica monótona, do tipo PCHIP. Ela passa por todos os pontos sem ultrapassar nenhum deles entre um ponto e o seguinte.

A escolha Suave precisa de 3 pontos ou mais. Com menos, ela se comporta como Reta, e a página avisa: Suave é uma cúbica monótona: dobra pelas âncoras sem jamais ultrapassá-las. Precisa de 3+ pontos; com menos, comporta-se como reta.

Requisitos

  • Permissões. A conta precisa de Sistema PERM_SYS_CONFIG, para abrir a página, e de Calibração PERM_CALIB, para ver e gravar o bloco.
  • Relógio acertado. Sem o relógio acertado, por NTP ou à mão (capítulo 10), o aparelho recusa a gravação da calibração, e o bloco avisa em vermelho: NTP não sincronizado. Até a v2.8.0 a recusa nunca acontecia, porque o aparelho dava o relógio por sincronizado mesmo sem acerto.
  • Slot ativo e gravado. O bloco só aparece em slots ativos já gravados no aparelho. Num slot novo, grave o slot primeiro e calibre depois.
  • Uma leitura ao vivo, para os pontos em que você deixar o valor bruto vazio.
  • Uma gravação a cada 5 s. O aparelho recusa uma segunda gravação de calibração antes disso.

Calibrar um sensor

Figura 35. O bloco Calibração de um DHT22. Cada grandeza tem sua linha de leitura, o mini gráfico da correção e seus pontos.

Para cada grandeza, o bloco mostra:

  • uma linha com o nome da grandeza, a leitura Bruto (Raw) e a leitura corrigido (corrected), como Temp — Bruto: 23.61 °C → corrigido: 23.40 °C;
  • um mini gráfico da correção: a linha do zero, que é o sensor sem correção, e a curva com os pontos;
  • sem pontos, Sem correção — padrão do sensor. (No correction — sensor default.), ou Offset constante (Constant offset) seguido do valor, quando a correção é um offset antigo gravado sem ponto de origem;
  • os pontos, um por linha, cada um com Bruto, Referência (Reference), o botão ↻ (Usar a leitura bruta atual) e o botão × (Remover este ponto);
  • + Adicionar ponto (Add point), até 5 pontos;
  • Remover correção (Remove correction);
  • Interpolação: com Reta e Suave.

Para calibrar:

  1. Ponha o sensor e o instrumento de referência no mesmo ambiente e espere os dois estabilizarem.
  2. Abra o editor do slot.
  3. Na grandeza a corrigir, toque em + Adicionar ponto.
  4. Toque em ↻ para copiar a leitura bruta atual para Bruto. Se preferir, deixe Bruto vazio: o aparelho capta a leitura bruta no momento da gravação.
  5. Digite em Referência o valor que o instrumento mostra.
  6. Para mais pontos, mude o ambiente (por exemplo, outra temperatura), espere estabilizar e repita os passos 3 a 5.
  7. Escolha Reta ou Suave.
  8. Confira se a linha de aviso vermelha do bloco está vazia.
  9. Toque em Concluído e depois em Salvar e reiniciar.

Os pontos não precisam estar em ordem: o aparelho os ordena pelo valor bruto. Na gravação, o aparelho grava a calibração primeiro e aplica a correção aos sensores; em seguida grava o resto e reinicia. O log de eventos registra o código 407, Sensores calibrados.

Para tirar a correção de uma grandeza, toque em Remover correção e grave.

Figura 36. Uma correção Suave com três pontos: o mini gráfico mostra a curva passando pelos pontos sem ultrapassá-los.
Figura 37. Sem NTP, o bloco avisa em vermelho que a gravação será recusada.

Erros da calibração

O bloco confere os pontos enquanto você digita e mostra o primeiro problema, precedido do nome da grandeza:

Aviso O que fazer
no máximo 5 pontos. Remova um ponto
todo ponto precisa de bruto e referência numéricos. Preencha Referência com um número; Bruto vazio ou numérico
sem leitura ao vivo para captar — preencha o valor bruto. O sensor não tem leitura agora. Digite o valor bruto
ponto fora da faixa plausível seguido da faixa Corrija o valor; as faixas estão em Grandezas e unidades
dois pontos com o mesmo valor bruto. Dois pontos com o mesmo bruto, até a segunda casa decimal. Remova um

Na gravação, uma recusa do aparelho aparece como Erro na calibração: (Calibration error:) seguido do motivo, e nada é gravado:

Motivo Causa
NTP not synced Relógio não sincronizado por NTP
rate limited Menos de 5 s desde a gravação de calibração anterior
slot N temp: point out of range Ponto fora da faixa da grandeza
slot N temp: duplicate calibration points Dois pontos com o mesmo valor bruto
slot N temp: no live reading to capture Bruto vazio e o sensor sem leitura
Forbidden A conta não tem a permissão Calibração

Se a gravação da calibração demorar mais de 30 s, a página mostra Tempo esgotado na calibração. Tente novamente.

O arquivo calib.csv

As correções ficam no arquivo /calib.csv, na raiz do sistema de arquivos do aparelho, e não na configuração. O arquivo aparece na página Arquivos (capítulo 17).

A primeira linha é VERSION, seguida de um número que cresce a cada gravação. As outras linhas têm uma correção cada:

VERSION,1790000000
28FF641E8716045C,FREEZER-1,Freezer da sala 2,-18.40,-18.00,4.10,4.00
E6614103E7512B29,tSALA-1,Sala,cub,15.20,15.00,22.80,22.50,30.10,30.00
E6614103E7512B29,uSALA-1,Sala,55.00,52.00
Coluna Conteúdo
1 A ROM do DS18B20; para os outros tipos, o número de série da placa
2 O ID de hardware; para os outros tipos, a letra da grandeza (t, u, p) seguida do ID
3 O nome
4 cub quando a interpolação é Suave; ausente quando é Reta
Resto Os pares bruto e referência, um número por coluna

Uma linha de DS18B20 sem pontos continua no arquivo: ela guarda a associação entre a ROM, o ID e o nome, que a adoção de sonda consulta.

Você pode enviar um calib.csv pela página Arquivos. O aparelho só o aceita se o número de VERSION for maior que o do arquivo atual; caso contrário, descarta o envio.

Voltar ao sumário

Capítulo 7

Alarmes, sons e janelas de manutenção

Este capítulo mostra quando o aparelho dispara um alarme, o que acontece no painel, na cigarra e na interface web, e como silenciar, desligar e suspender alarmes com uma janela de manutenção. É para quem opera o aparelho no dia a dia e para quem define os limites; o envio dos alarmes a um servidor está no capítulo 22.

Os dois tipos de alarme

O aparelho tem dois alarmes por sensor, independentes um do outro:

Alarme Quando dispara Pode ser desligado
Limite Uma grandeza do sensor sai da faixa entre o mínimo e o máximo configurados Sim, por sensor (Ligar e desligar)
Falha O sensor entra em estado de erro: 3 leituras seguidas falharam, ou outra sonda apareceu no pino de um DS18B20 (capítulo 6) Não. Pode ser suspenso por uma janela de manutenção ou calado até o sensor voltar

Nenhum dos dois dispara num slot inativo, nem num slot com a janela de manutenção aberta (Janelas de manutenção).

air O Air não tem painel nem cigarra. Nele, os alarmes só saem pela linha de alarmes (capítulo 22).

Limites por grandeza

Cada grandeza de cada sensor tem um mínimo e um máximo. O alarme de limite dispara quando qualquer grandeza do sensor fica abaixo do mínimo ou acima do máximo. Um BME280, por exemplo, tem três pares de limites: temperatura, umidade e pressão.

O valor comparado é o valor corrigido que o painel mostra, depois da média e da calibração (capítulo 6).

Limites de fábrica, em todo slot novo:

Grandeza Mínimo Máximo
Temperatura 0 °C 40 °C
Umidade 20 % 80 %
Pressão 0 hPa 1.638,3 hPa
Luminosidade 0 lx 167.772,15 lx

As regras dos limites:

  • Mínimo abaixo do máximo. Se o mínimo ficar igual ou maior que o máximo, o aparelho sobe o máximo para o mínimo mais 0,1.
  • Dentro da faixa da grandeza. Cada grandeza aceita limites só dentro da sua faixa plausível (capítulo 6). Pela web, um limite fora dela faz o aparelho recusar a gravação inteira, com Alarm limit outside channel range.
  • Uma casa decimal. A página e o painel ajustam os limites em passos de 0,1.

Os limites podem ser mudados na página Alarmes e Sons (A página Alarmes e Sons) e no painel (Limites no painel).

Ligar e desligar os alarmes de um sensor

Desligar os alarmes de um sensor desliga só o alarme de limite dele. O alarme de falha continua ativo: uma falha de comunicação não é um limite que se possa desligar.

Há quatro lugares para isso:

Onde Como Grava
Página Alarmes e Sons A chave no topo do cartão do sensor Com os botões de gravação, sem reiniciar
Editor de slot, em Configurações Alarmes habilitados Só com Salvar e reiniciar
Painel, menu do sensor A linha Alarmes Na hora
Painel, tela de alarme Desativar, com PIN Na hora

De fábrica, os alarmes de todo slot vêm ligados. Religar os alarmes de um sensor, pela web ou pelo painel, também desfaz o silêncio do alarme de falha dele (Desativar).

O que acontece quando um alarme dispara

Quando um alarme dispara, o aparelho:

  • toca a cigarra, com a melodia e o volume de alarme (Sons);
  • no painel, pisca o cartão do sensor: em vermelho para limite, em âmbar para falha;
  • no painel, leva o sensor em alarme para o cartão de baixo, a menos que ele já esteja fixado no cartão de cima;
  • registra no log de eventos o código 470, Alarme disparado;
  • se a linha de alarmes estiver ligada, envia o registro ao servidor (capítulo 22).

Quando nenhum sensor está mais em alarme, a cigarra para, os cartões param de piscar e o log registra o código 471, Alarme zerado.

Um alarme de limite no painel: o cartão do sensor pisca em vermelho.
Figura 38. Um alarme de limite no painel: o cartão do sensor pisca em vermelho.
Figura 39. Um alarme de falha no painel: o cartão pisca em âmbar e mostra Erro no lugar do valor.

No painel

release Toque no cartão que pisca para abrir a tela de alarme daquele sensor. O título mostra ! seguido do nome do sensor, e três botões:

Botão O que faz Exige
Silenciar 120s (Silence 120s) Cala a cigarra e para a piscada por 120 s (Silenciar) Nada
Desativar (Deactivate) Desliga o alarme daquele sensor (Desativar) PIN de uma conta com a permissão Bloqueio (painel)
Min/Max Volta à tela inicial com o cartão do sensor mostrando o mínimo e o máximo do dia Nada
A tela de alarme de um sensor, com Silenciar 120s, Desativar e Min/Max.
Figura 40. A tela de alarme de um sensor, com Silenciar 120s, Desativar e Min/Max.

No LCD

alpha A imagem alpha tem cigarra, mas o LCD não mostra alarmes e não há como silenciar no aparelho. A cigarra toca até o valor voltar à faixa, até alguém desligar os alarmes do sensor pela web, ou até alguém ligar o Mudo Global (Sons pela web). O LCD mostra ERRO para um sensor em falha (capítulo 6).

Na interface web

A interface web não mostra alarmes de limite. No Painel de Controle, um sensor em falha aparece com o ponto vermelho e Error (capítulo 13); um sensor fora dos limites aparece com a leitura normal.

release O espelho do painel, no Painel de Controle, mostra o painel como ele está, inclusive o cartão piscando (capítulo 13).

Para acompanhar alarmes de longe, use a linha de alarmes (capítulo 22).

Silenciar

Silenciar 120s cala o alarme por 120 s. Durante esse tempo:

  • a cigarra para;
  • os cartões param de piscar;
  • a barra de cima do painel mostra Silenciado: seguido dos segundos que faltam, como Silenciado: 97s;
  • nenhum alarme toca, nem um alarme novo de outro sensor.

O silêncio vale para todos os sensores, mesmo tocado a partir da tela de um só. Ele não exige PIN. O log registra o código 447, Alarme silenciado via UI, e a linha de alarmes recebe um registro de silêncio do sensor da tela (alarm_sil ou err_sil).

Quando os 120 s acabam, o log registra o código 448, Silenciamento de alarme expirou. Se algum sensor ainda estiver em alarme, a cigarra volta a tocar e o cartão volta a piscar. Se todos os alarmes acabarem antes, o silêncio é cancelado (código 472, Silenciamento cancelado).

O painel durante o silêncio: a contagem na barra de cima e o cartão parado.
Figura 41. O painel durante o silêncio: a contagem na barra de cima e o cartão parado.

Desativar

Desativar desliga o alarme do sensor da tela, e só dele. O efeito depende do alarme que está ativo:

  • Limite: desliga os alarmes do sensor, como a linha Alarmes do menu do sensor. A mudança é gravada e continua valendo depois de um reinício. O log registra o código 456, Alarmes do sensor bloqueados pelo painel.
  • Falha: cala só a falha daquele sensor, e o limite continua armado. O silêncio da falha dura até o sensor voltar a ler; se ele falhar de novo, o alarme volta. Religar os alarmes do sensor também o desfaz, e um reinício também. O log registra o código 449, Todos alarmes desativados (RAM).

Para desativar:

  1. Toque no cartão que pisca.
  2. Toque em Desativar.
  3. Escolha a conta na lista Quem está usando o painel? (capítulo 8).
  4. Digite o PIN.

Se a conta não tiver a permissão Bloqueio (painel) PERM_ALARM_BLOCK, o painel mostra Sem permissão e toca o som de erro; o log registra o código 458, Ação do painel recusada: sem permissão. Com a permissão, a cigarra para, o painel volta à tela inicial e a linha de alarmes recebe um registro alarm_off ou err_off com o nome da conta.

A página Alarmes e Sons

A página Alarmes e Sons (Alarms & Sounds, rota /alarms) exige a permissão Sistema PERM_SYS_CONFIG. Ela tem duas seções: Limites de Alarme e Configuração de Sons.

A página não tem botão próprio de gravar. As mudanças ficam preparadas na aba e são gravadas pelos botões da barra de topo (capítulo 5):

  • limites e chaves de alarme valem sem reiniciar: Testar e Aplicar agora funcionam para eles;
  • mudanças de som exigem reinício, e a barra oferece só Salvar e reiniciar.
A seção Limites de Alarme: um cartão por sensor ativo, com a chave de alarme e um par de campos por grandeza.
Figura 42. A seção Limites de Alarme: um cartão por sensor ativo, com a chave de alarme e um par de campos por grandeza.

Limites de Alarme

A seção mostra um cartão por sensor ativo. Sem sensores ativos, mostra Nenhum sensor configurado. (No sensors configured.); os sensores são criados na página Configurações (capítulo 6).

Cada cartão tem:

Elemento O que é
Chave, à esquerda do nome Liga ou desliga os alarmes de limite do sensor
Nome O nome do slot
Tipo e slot Como BME280 · slot 4
Temp MIN e Temp MAX Os limites de temperatura, em °C
Umid MIN e Umid MAX Os limites de umidade, em %, só em sensores com umidade
Press MIN e Press MAX Os limites de pressão, em hPa, só em sensores com pressão

Ao digitar um mínimo igual ou maior que o máximo, a página sobe o máximo para o mínimo mais 0,1; ao digitar um máximo igual ou menor que o mínimo, desce o mínimo.

Para mudar um limite:

  1. Abra Alarmes e Sons.
  2. Digite o novo valor no campo.
  3. Toque em Aplicar agora na barra de topo.

O aparelho passa a usar o limite novo na verificação seguinte, sem reiniciar.

Configuração de Sons

A seção Configuração de Sons com os valores de fábrica: todos os sons ligados, volumes em 70 %.
Figura 43. A seção Configuração de Sons com os valores de fábrica: todos os sons ligados, volumes em 70 %.
Linha Controles Fábrica
Toque (Touch) Melodia, botão de teste, chave Ligado, Click
Confirmação (Confirm) Melodia, botão de teste, chave Ligado, Ascendente
Erro (Error) Melodia, botão de teste, chave Ligado, Descendente
Alarme (Alarm) Melodia, botão de teste, chave Ligado, Dual Beep
Sons Web (Web Sounds) Chave Ligado
Atenção (Attention) Melodia, botão de teste, chave Ligado, Notify
Mudo Global (Global Mute) Chave Desligado
Vol. Sistema (System Volume) Controle deslizante, de 0 a 100 %, em passos de 5 70 %
Vol. Alarme (Alarm Volume) Controle deslizante, de 0 a 100 %, em passos de 5 70 %

O botão de teste toca a melodia escolhida no navegador, não na cigarra do aparelho, no volume do controle correspondente. Os detalhes de cada som estão em Sons.

Ligar Mudo Global desliga as outras seis chaves; ligar qualquer uma delas desliga Mudo Global.

O menu de alarmes do painel

release No painel, os alarmes ficam no item Limites de Alarme do menu de configurações. O item aparece para contas com pelo menos uma das três permissões de painel:

Permissão Nome na página Usuários Libera
PERM_ALARM_LIMITS Limites (painel) A linha Limites de alarme do menu do sensor
PERM_ALARM_BLOCK Bloqueio (painel) A linha Alarmes e o botão Desativar da tela de alarme
PERM_MAINT Manut. (painel) A linha Manutenção

Para abrir o menu, toque no botão de configurações da tela inicial, escolha a conta e digite o PIN (capítulo 8). O que cada conta pode fazer é decidido pelas permissões da conta que o PIN identificou.

A lista de sensores

A tela Limites de Alarme lista os sensores ativos, quatro por página, cada um com o nome e o estado dos alarmes: SIM (ligados) ou NÃO (desligados). As setas do rodapé mudam a seleção e SAIR volta ao menu.

Toque num sensor para selecioná-lo; toque de novo para abrir o menu dele.

A lista de sensores do menu de alarmes, com o estado SIM ou NÃO de cada um.
Figura 44. A lista de sensores do menu de alarmes, com o estado SIM ou NÃO de cada um.

O menu do sensor

O título é o nome do sensor. O menu tem três linhas:

Linha À direita O que faz
Limites de alarme Uma seta Abre o editor de limites
Alarmes SIM ou NÃO Liga ou desliga os alarmes de limite do sensor, na hora
Manutenção NÃO, ou o tempo que falta, como 1h45 Abre a janela de manutenção

Uma linha cuja permissão a conta não tem aparece apagada, com um cadeado. Tocar nela só toca o som de erro. O menu abre na primeira linha que a conta pode usar: uma conta só com Manut. (painel) abre em Manutenção.

O rodapé tem as setas, SAIR, que volta à lista, e ENTRAR, que abre a linha selecionada.

Tocar em Alarmes grava na hora. O log registra o código 456 ao desligar e 457 ao religar, com o nome da conta, e a linha de alarmes recebe alarm_off ou alarm_on.

O menu de um sensor para uma conta com as três permissões de painel.
Figura 45. O menu de um sensor para uma conta com as três permissões de painel.
Figura 46. O mesmo menu para uma conta só com Manut. (painel): as duas primeiras linhas apagadas, com cadeado, e a seleção em Manutenção.

Limites no painel

O título é o nome do sensor. O editor mostra uma barra por limite, quatro por página, com o nome da grandeza seguido de MIN ou MAX, como Temperatura MIN e Umidade MAX, o valor e a unidade. As setas nas pontas de cada barra diminuem e aumentam o valor.

  1. Toque na barra do limite.
  2. Toque nas setas das pontas para ajustar. Um toque muda 0,1. Segurando, o passo cresce: 0,5 depois de 2 s, 1 depois de 4 s e 10 depois de 6 s.
  3. Toque em SALVAR.

As setas do rodapé mudam a barra selecionada, e SAIR volta ao menu do sensor sem gravar. O editor não deixa o mínimo passar do máximo: ao empurrar um, ele empurra o outro.

SALVAR exige a permissão Limites (painel) PERM_ALARM_LIMITS. O aparelho grava, passa a usar os limites novos na hora, registra no log o código 442, Limites de alarme salvos via UI, e envia um registro alarm_lim por grandeza alterada, com os limites novos e o nome da conta.

O editor de limites de um DHT22: temperatura e umidade, mínimo e máximo.
Figura 47. O editor de limites de um DHT22: temperatura e umidade, mínimo e máximo.

Janelas de manutenção

A janela de manutenção suspende os alarmes de um sensor por um tempo definido, enquanto alguém mexe nele. Durante a janela, aquele sensor:

  • não dispara alarme de limite;
  • não dispara alarme de falha, então desligar o cabo do sensor não faz a cigarra tocar;
  • não gera registros de limite nem de falha na linha de alarmes.

O sensor continua sendo lido e gravado no histórico normalmente.

A janela guarda a hora em que termina, não um estado ligado ou desligado. Ela sobrevive a reinícios e fecha sozinha no prazo, e a duração máxima é de 30 dias. Um pedido maior é cortado para 30 dias.

A linha de alarmes recebe dois registros por janela: maint_on ao abrir, com a hora prevista do fim e o nome de quem abriu, e maint_off ao fechar, por comando ou por prazo. Um reinício no meio da janela não gera um maint_on novo. Se o sensor ainda estiver fora da faixa quando a janela fecha, o alarme dispara de novo.

Pelo painel

  1. No menu do sensor, toque em Manutenção e depois em ENTRAR.
  2. Na tela Manutenção, ajuste Horas e Minutos com as setas das pontas. A tela abre com 1 h e 0 min. As horas vão de 0 a 720; os minutos mudam de 5 em 5, de 0 a 55.
  3. Toque em INICIAR.

A janela precisa ter pelo menos 5 min: com 0 h e 0 min, INICIAR só toca o som de erro. A ação exige a permissão Manut. (painel) PERM_MAINT. O log registra o código 454, Manutenção aberta pelo painel, com o nome da conta.

Com a janela aberta, a mesma tela mostra o nome do sensor e o tempo que falta, como 1h45 restantes, e o botão FECHAR. Toque em FECHAR para encerrar a janela antes do prazo; o log registra o código 455, Manutenção encerrada pelo painel. SAIR volta ao menu do sensor sem mudar nada.

Figura 48. A tela Manutenção com a janela fechada: horas, minutos e INICIAR.
Figura 49. A tela Manutenção com a janela aberta: o tempo que falta e FECHAR.

Pela web e por um servidor

A interface web não tem controle de janela de manutenção. Um servidor, ou um script, abre e fecha janelas pela interface de programação, com uma conta que tenha a permissão Sistema:

  • o pedido diz em quantos segundos a partir de agora a janela termina; 0 fecha a janela;
  • um valor negativo é recusado, e um valor acima de 30 dias é cortado; nos dois casos o campo volta na lista rejected da resposta;
  • a consulta de alarmes informa, por sensor, quantos segundos faltam para a janela fechar, e 0 quando não há janela.

O formato do pedido está no capítulo 26; o uso a partir de um servidor de alarmes, no capítulo 22.

Sons

release alpha A cigarra toca cinco tipos de som. Cada tipo tem seis melodias à escolha e pode ser ligado ou desligado:

Som Quando toca Melodias
Toque A cada toque no painel Click, Bubble, Tick, Snap, Drop, Chirp
Confirmação Quando uma ação dá certo Ascendente, Fanfare, Chime, Triumph, Sparkle, Resolve
Erro Quando uma ação é recusada Descendente, Buzz, Low, Harsh, Decline, Blip
Alarme Enquanto um alarme está ativo Dual Beep, Sirene, Rapid, Pulse, Escalate, Staccato
Atenção Ao abrir uma tela de confirmação no painel Notify, Bell, Pulse, Chime Low, Rise, Soft Ding

Os ajustes gerais:

  • Dois volumes. O volume de alarme vale só para o som de alarme; o volume do sistema vale para os outros quatro.
  • Sons Web. Quando ligado, o aparelho toca o som de confirmação a cada entrada na interface web e o som de erro a cada senha errada (capítulo 13).
  • Mudo Global. Cala todos os sons, inclusive o de alarme.

Com o som de alarme desligado, ou com Mudo Global, um alarme continua disparando no painel, no log e na linha de alarmes, mas a cigarra não toca.

air O Air não tem cigarra. A seção de sons existe na página, mas não tem efeito.

Sons no painel

release O item Sons de Alarme do menu de configurações exige a permissão Sistema PERM_SYS_CONFIG. A tela Config. de Sons tem nove linhas, em três páginas:

Linha Como mudar
Vol. Sistema Com a linha selecionada, toque na metade esquerda para baixar e na direita para subir, de 10 em 10
Vol. Alarme Igual, e o painel toca a melodia de alarme como amostra
Toque na Tela, Confirmação, Erro, Alarme, Atenção Com o som ligado, um toque o desliga. Com o som desligado, um toque abre a escolha de melodia
Acesso Web Um toque liga ou desliga os sons de entrada pela web
Mudo Global Ligar pede confirmação; desligar é direto

Na escolha de melodia, o painel lista as seis melodias numeradas e toca cada uma ao ser selecionada. SALVAR liga o som com a melodia escolhida e desliga o Mudo Global; SAIR volta sem mudar.

Ao ligar Mudo Global, o painel toca o som de atenção e pergunta: Todos os sons serão desabilitados. Tem certeza? Confirmar liga o mudo e desliga todos os sons; SAIR volta sem mudar.

As mudanças só valem depois de SALVAR, no rodapé da tela. O painel grava na hora, sem reiniciar, e o log registra o código 446, Config de som salva.

A tela Config. de Sons, primeira página: os dois volumes, Toque na Tela e Confirmação.
Figura 50. A tela Config. de Sons, primeira página: os dois volumes, Toque na Tela e Confirmação.
Figura 51. A escolha de melodia do som de alarme, com as seis opções.
Figura 52. A confirmação do Mudo Global.

A linha de alarmes

Além do painel e da cigarra, o aparelho pode enviar cada mudança de alarme a um servidor, pela linha de alarmes, uma segunda linha da telemetria, desligada de fábrica. Ela envia um registro por transição, não um por leitura: limite ultrapassado (alarm), falha (err), silêncio (alarm_sil, err_sil), desativação e reativação (alarm_off, err_off, alarm_on), limites alterados no painel (alarm_lim) e janelas de manutenção (maint_on, maint_off). Os registros de ações feitas com PIN ou pela web levam o nome da conta. Para evitar picos isolados, um limite só vira registro depois de duas verificações seguidas com o valor fora da faixa; o painel e a cigarra reagem já na primeira. Os registros esperam numa fila na memória até o servidor confirmar o recebimento. Tudo isso está no capítulo 22.

Voltar ao sumário

Capítulo 8

Contas, permissões e PIN

Este capítulo explica quem pode fazer o quê no aparelho: as contas, as 13 permissões, a página Usuários, as senhas da interface web e o PIN com que cada pessoa se identifica no painel. É para quem administra o aparelho, e é a referência de permissões do manual inteiro.

O modelo de contas

O aparelho guarda até 32 contas. Cada conta tem:

  • um nome, de 1 a 15 caracteres, único sem diferenciar maiúsculas de minúsculas;
  • uma senha, para a interface web;
  • um conjunto de permissões, uma por ação (As 13 permissões);
  • release um PIN opcional, para se identificar no painel (Identidade no painel).

A mesma conta serve à web e ao painel. Uma pessoa que usa os dois tem uma conta só, com uma senha para a web e um PIN para o painel.

As contas de fábrica

Conta Permissões Senha inicial PIN inicial
admin Todas, inclusive as exclusivas do administrador 8 caracteres aleatórios, mostrados uma vez no console serial USB na primeira partida (capítulo 4) 1234, com troca obrigatória
viewer Painel e Histórico Não divulgada: gere uma com Reset antes de usar a conta Nenhum

As duas contas precisam trocar a senha no primeiro acesso pela web (capítulo 13). Para usar a conta viewer, toque em Reset na página Usuários e entregue a senha de uso único que aparece; se não for usá-la, exclua a conta.

A conta admin ocupa sempre a primeira posição da tabela e não pode ser excluída, nem pela web nem pelo painel. Nenhuma conta nova pode se chamar admin.

Como a senha é guardada

O aparelho nunca guarda a senha. Ele guarda um resumo feito com HMAC-SHA256 em 5.000 rodadas, com um sal aleatório de 8 bytes gerado pelo hardware para cada conta e com o número de série da placa misturado à chave.

Contas antigas, gravadas no formato anterior de 2.500 rodadas, são convertidas sozinhas para o formato atual na primeira entrada certa.

O PIN do painel também é guardado só como resumo, com um sal próprio do aparelho e o número de série da placa.

As 13 permissões

Cada permissão libera um grupo de ações. O aparelho confere a permissão em cada página, em cada consulta da interface de programação e em cada ação do painel: esconder um item da tela é só conforto.

Permissão Nome na página Na interface web No painel Na interface de programação
PERM_DASHBOARD 0x0001 Painel Páginas Painel de Controle e Licença Nada GET /api/status, /api/themes (release); /metrics (capítulo 24)
PERM_HISTORY 0x0002 Histórico Página Histórico e Logs: gráficos, calendário e exportação Nada Consultas e exportação do histórico; baixar arquivos de /history
PERM_LOGS 0x0004 Logs Página Histórico e Logs: eventos. Limpar o log exige também Sistema Nada Consulta e exportação do log de eventos
PERM_SYS_CONFIG 0x0008 Sistema Páginas Alarmes e Sons, Telemetria e Configurações; no Painel de Controle, captura, espelho e tema do painel Itens Temas Visuais, Sons de Alarme, Idioma do Sistema, Calibrar Touch e Alinhamento da Tela Configuração, alarmes, sensores, hora, envio e cursor da telemetria, reinício, captura e toque remoto do painel
PERM_NET_CONFIG 0x0010 Rede Página Rede Item Modo de Configuração Configuração de rede e busca de redes Wi-Fi
PERM_FILE_READ 0x0020 Leitura Página Arquivos: listar e baixar Nada Listar e baixar arquivos; validar um backup
PERM_FILE_UPLOAD 0x0040 Upload Página Arquivos: enviar arquivos e criar pastas Nada Envio de arquivo e criação de pasta
PERM_FILE_DELETE 0x0080 Excluir Página Arquivos: apagar arquivos Nada Exclusão de arquivo
PERM_USER_MGR 0x0100 Usuários Página Usuários Itens Usuários e Segurança do PIN; definir o PIN de outra conta Lista de contas, estado dos bloqueios de entrada, gravação de contas
PERM_CALIB 0x0200 Calibração Bloco Calibração do editor de slot, que exige também Sistema Nada Leitura e gravação da calibração
PERM_ALARM_LIMITS 0x0400 Limites (painel) Nada Editor de limites do sensor Nada
PERM_ALARM_BLOCK 0x0800 Bloqueio (painel) Nada Linha Alarmes do menu do sensor e Desativar na tela de alarme Nada
PERM_MAINT 0x1000 Manut. (painel) Nada Linha Manutenção do menu do sensor Nada

Detalhes que a tabela não mostra:

  • Histórico e Logs abre com Histórico ou com Logs, mas cada metade da página consulta o aparelho com a sua própria permissão (capítulo 13).
  • Baixar um arquivo de /history exige Leitura e Histórico; baixar um arquivo de log de eventos exige Leitura e Logs.
  • No painel, o item Limites de Alarme aparece com qualquer uma das três permissões de painel, e cada linha do menu do sensor exige a sua (capítulo 7).
  • Sem nenhuma permissão, a conta entra na web mas não tem página para abrir (capítulo 13).
  • Os itens Alterar Senha (o próprio PIN), Licença e Status do Sistema do painel valem para qualquer conta identificada.
  • Os gráficos, o calendário e o mínimo e máximo do painel não exigem PIN.

As rotas exatas de cada permissão estão no capítulo 26.

O administrador e as ações exclusivas

Além das 13 permissões, existe o nível de administrador completo, que só a conta admin tem de fábrica. Quatro ações exigem exatamente esse nível, e nenhuma combinação das 13 permissões as libera:

Ação Onde
Baixar o backup completo Página Arquivos (capítulo 17)
Restaurar um backup Página Arquivos (capítulo 17)
Enviar e aplicar uma atualização de firmware Página Arquivos (capítulo 17)
release Instalar o certificado HTTPS Capítulo 9

A página Usuários concede no máximo as 13 permissões. Uma conta criada pela web, mesmo com todas elas marcadas, não faz backup nem atualiza o firmware. O nível completo só se concede pelo console completo, com user perm <nome> admin. As imagens release e alpha vêm com o console de emergência, que não tem esse comando: nelas, só a conta admin tem o nível completo (capítulo 14).

Ninguém concede o que não tem

Desde a v2.7.0, quem cria uma conta pela web só pode marcar permissões que a própria conta tem. Uma conta com Usuários e Painel, por exemplo, cria contas com Painel, com Usuários ou com as duas, e nada além disso.

Pelo mesmo motivo, só a própria conta admin, ou uma conta com o nível completo, define ou apaga o PIN do admin pela web.

A página Usuários

A página Usuários (Users, rota /users) exige a permissão Usuários PERM_USER_MGR. O título é Gestão de Acessos (Access Management). Ela tem a tabela de contas e o formulário Adicionar (Add New User).

Toda mudança nesta página fica preparada na aba e só vale quando você grava. Aplicar agora grava e aplica sem reiniciar; Salvar e reiniciar grava e reinicia. Testar não aparece quando há contas preparadas: uma conta não se testa. Depois de gravar, a página se recarrega sozinha. Até a v2.9.0, toda gravação de contas reiniciava o aparelho.

Figura 53. A página Usuários: a tabela de contas e, abaixo, o formulário Adicionar.

A tabela de contas

Coluna O que mostra
# A posição da conta, de 0 a 31. A conta admin é a 0
Usuário (User) O nome, seguido do selo PIN quando a conta tem PIN de painel
Permissões (Permissions) Um selo com o número de permissões. Toque nele para ver os nomes. A conta admin mostra Super
Ações (Actions) Os botões da conta

Os botões de cada conta:

Botão O que prepara
PIN Definir ou apagar o PIN de painel da conta (PIN pela web)
Reset Uma senha nova de uso único; a conta troca a senha na próxima entrada
Excluir (Del) A exclusão da conta

A linha da conta admin tem só PIN e o selo Protegido (Protected): ela não pode ser resetada nem excluída pela página. A senha do admin se troca pela própria conta (capítulo 13) ou, em recuperação, pelo console (capítulo 18).

Uma ação preparada aparece na linha até a gravação: Pendente: PIN, Pendente: Reset, Pendente: Excluir, ou uma linha nova com Pendente: Novo e o botão ↶, que desfaz a última ação preparada.

Figura 54. No celular, o selo de permissões aberto mostra os nomes de cada permissão da conta.

Criar uma conta

O formulário Adicionar tem:

  • Nome (Username): de 1 a 15 caracteres, sem aspas nem barra invertida;
  • as 13 caixas de permissão, com os nomes da tabela de permissões;
  • PIN do painel (opcional) (Panel PIN (optional)), só na imagem release;
  • o botão Criar (Create User).

Para criar uma conta:

  1. Digite o Nome.
  2. Marque as permissões.
  3. Se a pessoa vai usar o painel, digite um PIN em PIN do painel (opcional).
  4. Toque em Criar. A conta aparece na tabela com Pendente: Novo.
  5. Toque em Aplicar agora na barra de topo.
  6. Copie a senha que aparece na janela Senha temporária (Temporary password).
  7. Toque em Guardei — recarregar (I saved it — reload).
Figura 55. Uma conta preparada e ainda não gravada.

A janela Senha temporária lista cada conta criada ou resetada nessa gravação, com a senha de uso único ao lado. A senha tem 8 caracteres, entre letras maiúsculas e dígitos, sem O, 0, I e 1. Ela aparece só nessa janela: o aparelho guarda apenas o resumo. A janela não fecha com Esc, e a página só recarrega depois de Guardei — recarregar.

Entregue a senha à pessoa. Na primeira entrada, ela é levada à troca de senha obrigatória (capítulo 13).

Figura 56. A janela Senha temporária, com a senha de uso único da conta criada.

Mudar as permissões de uma conta

A página Usuários não edita as permissões de uma conta existente. Para mudá-las pela web:

  1. Toque em Excluir na conta e confirme Excluir?.
  2. Crie a conta de novo, com o mesmo nome e as permissões novas.
  3. Toque em Aplicar agora.
  4. Entregue a nova senha de uso único.

As duas ações podem ir na mesma gravação. O aparelho as aplica na ordem em que foram preparadas; por isso, prepare a exclusão antes da criação, ou o nome ainda estará em uso. O PIN de painel da conta excluída se perde com ela; defina-o de novo na criação.

Outros caminhos:

  • as três permissões de painel de uma conta mudam no painel, sem apagar a conta (Usuários no painel);
  • qualquer permissão muda pelo console completo, com user perm, que vem instalado só no Air (capítulo 14).

Excluir uma conta

  1. Toque em Excluir na linha da conta.
  2. Confirme a pergunta Excluir?.
  3. Toque em Aplicar agora.

O aparelho apaga o registro inteiro da conta, inclusive o resumo da senha e o PIN. Uma sessão web aberta da conta termina no pedido seguinte, e uma identificação no painel, na ação seguinte; o log registra o código 312, Sessão encerrada: conta alterada. A exclusão é feita pela posição da conta na tabela. O log de eventos guarda o nome da conta nas entradas antigas.

Resetar a senha de uma conta

  1. Toque em Reset na linha da conta.
  2. Confirme a pergunta Forçar reset?.
  3. Toque em Aplicar agora.
  4. Copie a nova senha na janela Senha temporária.

O reset troca só a senha. As permissões e o PIN continuam como estavam. Uma sessão web aberta da conta termina no pedido seguinte; a identificação no painel continua, porque o painel identifica pelo PIN.

PIN pela web

release O botão PIN abre uma pergunta do navegador com a regra, PIN: 4 a 8 de 0-9. Vazio remove o PIN.

  1. Toque em PIN na linha da conta.
  2. Digite o PIN, ou deixe vazio para apagar o PIN da conta.
  3. Toque em OK. A linha mostra Pendente: PIN.
  4. Toque em Aplicar agora.

Pela web, o PIN tem sempre de 4 a 8 dígitos, qualquer que seja a política de PIN do aparelho. O aparelho recusa um PIN que outra conta já use.

Motivos de recusa

A página não mostra estas recusas: a gravação continua e a ação recusada não aparece. Um script que grava contas pela interface de programação recebe a lista em rejected (capítulo 26).

Motivo Causa
users.name Nome vazio, com mais de 15 caracteres, com aspas, barra invertida ou caractere de controle, ou igual a admin
users.dup Já existe uma conta com esse nome
users.perms Permissões fora das 13, ou alguma que a sua conta não tem
users.full As 32 posições estão ocupadas
users.pin PIN fora da regra ou já usado por outra conta
users.id Conta inexistente, a conta admin numa exclusão ou reset, ou o PIN do admin pedido por quem não é administrador

Senhas e sessões da web

A entrada, as mensagens, a troca de senha e as sessões estão no capítulo 13. Em resumo:

Regra Valor
Senha nova, na página Pelo menos 8 caracteres, com letra, dígito e símbolo (capítulo 13)
Senha nova, conferida pelo aparelho Só em HTTPS: pelo menos 8 caracteres, com letra e dígito
Troca obrigatória Contas de fábrica, contas novas, contas resetadas e o admin depois de system admin reset (capítulo 13)
Sessões Três ao todo, uma por conta; expiram depois de 15 min sem uso; um reinício encerra todas (capítulo 13)
Sair Sair, na gaveta de navegação
Bloqueio por senha errada Por endereço de computador: 2 s na primeira, dobrando a cada erro, até 300 s (capítulo 13)

O bloqueio guarda até 8 endereços ao mesmo tempo. A contagem de erros de um endereço para de subir em 12, o que mantém a espera em 300 s. Se os 8 lugares estiverem ocupados por bloqueios ainda ativos, o aparelho recusa uma entrada de um endereço novo com o código HTTP 429 e diz quanto esperar. Quem tem a permissão Usuários consulta esses bloqueios pela interface de programação.

Identidade no painel

release O painel não usa senha. Para abrir as configurações, a pessoa escolhe a própria conta numa lista e digita o PIN dela. A partir daí, o que o painel deixa fazer depende das permissões dessa conta. Cada vez que alguém toca no botão de configurações da tela inicial, o painel pede a identificação de novo; e depois de 30 s sem toque, ele volta sozinho à tela inicial.

Só contas com PIN conseguem se identificar. Uma conta sem PIN não aparece na lista.

Entrar

  1. Na tela inicial, toque em CFG, na barra de botões de baixo, logo depois do último sensor (capítulo 11).
  2. Na tela Quem está usando o painel?, toque na sua conta para selecioná-la e toque de novo, ou toque em ENTRAR.
  3. Digite o PIN no teclado (O teclado).
  4. Toque em ENTRAR.

Com o PIN certo, o painel toca o som de confirmação e abre o menu de configurações. O título mostra Configurações > seguido do nome da conta, e o menu lista só os itens que as permissões da conta alcançam. Com o menu filtrado, os itens aparecem sem os números.

A lista mostra quatro contas por página. As setas do rodapé andam uma conta por vez; com mais de oito contas, andam uma página por vez. SAIR volta à tela inicial. Uma conta bloqueada por tentativas erradas aparece com bloqueado em vermelho e não abre o teclado.

Figura 57. A tela Quem está usando o painel?, com as contas que têm PIN.
O menu de uma conta só com permissões de painel: Limites de Alarme, Status do Sistema, Alterar Senha e Licença, sem numeração, e o nome da conta no título.
Figura 58. O menu de uma conta só com permissões de painel: Limites de Alarme, Status do Sistema, Alterar Senha e Licença, sem numeração, e o nome da conta no título.

O teclado

O teclado depende da política de PIN (A política de PIN) e da finalidade da tela.

Para se identificar, com 2 ou 3 caracteres por tecla, o painel mostra cartões embaralhados. Cada cartão traz 2 ou 3 caracteres, e um toque no cartão vale por qualquer um deles: o painel nunca pergunta qual. Depois de cada toque, os caracteres são distribuídos de novo, então quem olha a tela não descobre o PIN pelos cartões tocados, nem se dois caracteres do PIN são iguais. O aparelho confere todas as combinações possíveis contra o PIN da conta escolhida.

Política Cartões na tela Caracteres por cartão
0-9, 3 por tecla 4 3, com 2 símbolos de enfeite entre eles
0-9, 2 por tecla 6 2, com 2 símbolos de enfeite entre eles
0-9 A-Z, 3 por tecla 12 3
0-9 A-Z, 2 por tecla 18 2

Os símbolos de enfeite completam os cartões para que todos tenham o mesmo número de caracteres. Eles nunca fazem parte de um PIN.

Com 1 caractere por tecla, o painel mostra um teclado ordenado, que não embaralha:

  • com 0-9, um teclado numérico: 1 a 9 em três linhas e o 0 sozinho no meio da quarta;
  • com 0-9 A-Z, nove teclas de grupo, 0-9, ABC, DEF, GHI, JKL, MNO, PQRS, TUV e WXYZ. O primeiro toque abre o grupo; o segundo escolhe o caractere. Um toque fora da janela do grupo a fecha sem digitar nada.

Para definir um PIN, o painel usa sempre o teclado ordenado do alfabeto da política, qualquer que seja o número de caracteres por tecla. Escolher um PIN é o oposto de esconder um: o embaralhamento só custaria toques.

Em todos os teclados, a linha de pontos mostra quantos caracteres já foram digitados, e o rodapé tem:

  • a tecla de apagar, que tira o último caractere;
  • SAIR, que abandona a tela e funciona até durante uma espera;
  • ENTRAR, que envia o PIN.
Figura 59. O teclado embaralhado da política de fábrica: quatro cartões de três caracteres.
Figura 60. O teclado ordenado alfanumérico, com a janela de um grupo aberta.
Figura 61. O teclado numérico ordenado, usado para definir um PIN.

PIN errado e bloqueios

Um PIN errado faz o painel mostrar PIN inválido!, tocar o som de erro e distribuir os cartões de novo. Para identificar, o painel confere qualquer PIN a partir de 4 caracteres, mesmo abaixo do mínimo da política: um PIN assim pode ter sido definido antes de a política mudar, ou pela web. Se ele estiver certo, a conta vai direto para a troca (O PIN de fábrica). Com menos de 4 caracteres, o painel mostra PIN muito curto (mín. 4) e não confere. Até a v2.11.0, um PIN mais curto que o mínimo da política nunca era conferido, e a conta ficava sem o painel.

As tentativas erradas são contadas por conta:

Tentativa errada da conta O que acontece
1ª e 2ª Nada; pode tentar de novo na hora
3ª Espera de 5 s
4ª Espera de 15 s
5ª Espera de 60 s
6ª A conta fica bloqueada no painel até o aparelho reiniciar

Durante uma espera, o teclado some e a tela mostra Tentativas Excedidas e Aguarde N segundos…. A espera vale para o teclado inteiro, não só para a conta que errou. Uma entrada certa zera a contagem daquela conta.

Além disso, o painel inteiro trava depois de 20 tentativas erradas somadas entre todas as contas, contadas desde a última entrada certa. A tela fica vermelha, com ACESSO BLOQUEADO e Reinicialização requerida, e só um reinício destrava. As contagens ficam só na memória: um reinício zera todas.

A web não é afetada por nenhum desses bloqueios.

Figura 62. Um PIN recusado: a mensagem PIN inválido! e os cartões distribuídos de novo.
Figura 63. A espera depois da terceira tentativa errada.
Figura 64. O painel travado: só um reinício libera o teclado.

O PIN de fábrica

A conta admin sai de fábrica com o PIN 1234. Na primeira identificação com ele, o painel abre direto a tela Novo PIN, e o log registra o código 302 com o texto PIN padrão detectado; forçando troca. A troca fica pendente até o admin escolher um PIN diferente de 1234; escolher 1234 de novo não a desfaz.

Da mesma forma, quando a política de PIN fica mais exigente, toda conta com PIN é marcada para trocá-lo, e o painel abre Novo PIN na próxima identificação de cada uma (A política de PIN).

Nos dois casos, a conta já está identificada quando a tela Novo PIN abre, mas o menu só abre depois da troca. SAIR volta à tela inicial sem trocar, e a tela volta na identificação seguinte. Até a v2.11.0, SAIR levava ao menu sem trocar, inclusive com o 1234 de fábrica.

O próprio PIN

Qualquer conta identificada troca o próprio PIN pelo item Alterar Senha do menu (o 5º, Change Password).

  1. Toque em Alterar Senha.
  2. Na tela Novo PIN, digite o PIN novo no teclado ordenado e toque em ENTRAR.
  3. Na tela Confirme o PIN, digite de novo e toque em ENTRAR.
Mensagem Significado
PIN salvo! Gravado; vale na próxima identificação
Os PINs não coincidem! As duas digitações diferem; o painel volta a Novo PIN
PIN muito curto (mín. N) Menos caracteres que o mínimo da política, que a mensagem diz no lugar de N. Até a v2.11.0, ela dizia 4 com qualquer mínimo
PIN inválido! Fora da política
PIN já em uso! Outra conta já tem esse PIN. Nada é gravado

Cada mensagem de resultado tem o botão ENTENDI, que volta à tela de onde a ação partiu. O log registra o código 445, PIN do display alterado.

O PIN precisa ser único porque dois PINs iguais deixariam de identificar quem está no painel. Por isso o aparelho recusa um PIN já usado, sem dizer de quem é.

Figura 65. A recusa de um PIN que outra conta já tem.

A política de PIN

A política define como são os PINs de todas as contas. Ela tem três ajustes, que dependem um do outro:

Ajuste Painel Página Configurações Valores Fábrica
Caracteres por tecla Teclado Teclado do painel: glifos por tecla 1, 2 ou 3 3
Alfabeto Caracteres Caracteres do PIN 0-9 ou 0-9 A-Z 0-9
Tamanho mínimo Tamanho mínimo Tamanho mínimo do PIN De 4 até o teto do teclado 4

O teto de tamanho depende dos caracteres por tecla: 8 com 3, 12 com 2 e 16 com 1. Com 2 ou 3 caracteres por tecla, o aparelho confere todas as combinações que os toques podem formar, e mais caracteres custariam tempo demais. Um toque além do teto não é aceito.

Como escolher:

  • Mais caracteres por tecla escondem melhor o PIN de quem olha a tela, mas facilitam um chute às cegas.
  • O alfabeto 0-9 A-Z torna um chute às cegas muito mais difícil sem custo nenhum. As letras são sempre maiúsculas.
  • Um PIN mais longo é a defesa principal contra chutes.

No painel. O item Segurança do PIN (o 7º, PIN security) exige a permissão Usuários PERM_USER_MGR.

  1. Toque numa linha para selecioná-la e toque de novo para mudar o valor. Tamanho mínimo sobe até o teto e volta a 4; Teclado mostra o teto ao lado, como 3 (max 8); Caracteres alterna entre 0-9 e 0-9 A-Z.
  2. Toque em SALVAR. O painel mostra PIN salvo!.

Ao mudar um ajuste, o painel corrige os outros para uma combinação possível. SAIR descarta. A política vale na próxima tela de PIN, sem reiniciar, e o log registra o código 459, Política de PIN alterada pelo painel.

Na web. Os três campos ficam na seção Hardware da página Configurações, que exige a permissão Sistema (capítulo 6). A dica do tamanho mínimo mostra a faixa permitida, como 4 – 8. Pela web, a mudança vale com Aplicar agora, sem reiniciar (até a v2.9.0, exigia Salvar e reiniciar). O log registra o mesmo código 459, com a marca [web].

Quando a política fica mais exigente em qualquer ajuste (mínimo maior, alfabeto menor ou teto menor), toda conta com PIN é marcada para trocá-lo, e é levada a Novo PIN logo depois de se identificar (O PIN de fábrica). Afrouxar a política não marca ninguém.

  • Mínimo maior: a conta se identifica com o PIN antigo, mesmo mais curto que o mínimo novo. Até a v2.11.0, o teclado recusava esse PIN como curto, e a conta ficava sem o painel.
  • Alfabeto menor ou teto menor: um PIN antigo com uma letra que saiu dos cartões, ou mais longo que o teto novo, não pode mais ser digitado: o teto não sobe para um PIN antigo, porque é o tempo de conferir. Defina um PIN novo para essa conta no item Usuários do painel, na página Usuários da web ou no console.
Figura 66. A tela Segurança do PIN, com a política de fábrica: tamanho mínimo 4, 3 caracteres por tecla (máximo 8) e só dígitos.
Figura 67. Os campos da política de PIN na página Configurações.

Usuários no painel

O item Usuários (o 6º, Users) exige a permissão Usuários PERM_USER_MGR. Ele lista todas as contas menos a admin, com:

  • um ponto depois do nome, quando a conta tem PIN;
  • as letras L, B e M à direita, acesas para as permissões Limites (painel), Bloqueio (painel) e Manut. (painel) que a conta tem.

O rodapé tem SAIR e NOVO. Toque numa conta para selecioná-la e de novo para abrir o editor dela.

Figura 68. A lista de contas do painel, com o ponto de quem tem PIN e as letras L, B e M.

Criar uma conta no painel:

  1. Toque em NOVO.
  2. Digite o nome no teclado de texto, com até 15 caracteres, e toque em OK. O X do título volta à lista.
  3. Na tela seguinte, marque as permissões de painel: toque em Editar limites, Bloquear alarmes e Manutenção para alternar entre SIM e NÃO.
  4. Toque em SEGUIR.
  5. Digite o PIN da conta em Novo PIN e de novo em Confirme o PIN, tocando em ENTRAR a cada vez.

O painel mostra Usuário salvo! e grava na hora, sem reiniciar. O log registra o código 450, Usuário criado pelo painel, com o nome de quem criou e da conta nova.

Mensagem Causa
Nome inválido ou repetido Nome com aspas, barra invertida ou caractere de controle, já usado por outra conta, ou admin
Sem vaga para conta nova As 32 posições estão ocupadas
PIN já em uso! Outra conta tem esse PIN; a conta não é criada
Sem permissão A conta identificada não tem mais a permissão Usuários, ou marcou uma permissão de painel que ela mesma não tem

Uma conta criada no painel tem só as três permissões de painel e uma senha web aleatória que ninguém conhece. Ela não abre nenhuma página web até um administrador recriá-la pela página Usuários com permissões web e entregar a senha de uso único (Mudar as permissões de uma conta).

Figura 69. O teclado de texto para o nome da conta nova.
Figura 70. As três permissões de painel da conta nova, antes de SEGUIR.
Figura 71. O PIN da conta nova, digitado duas vezes no teclado ordenado.

Editar uma conta no painel. O editor mostra o nome da conta no título e cinco linhas:

Linha O que faz
Editar limites Alterna a permissão Limites (painel)
Bloquear alarmes Alterna a permissão Bloqueio (painel)
Manutenção Alterna a permissão Manut. (painel)
Definir PIN Define um PIN novo para a conta, digitado duas vezes
Excluir usuário Exclui a conta, depois de confirmar

As três primeiras linhas só mudam na tela; SALVAR grava, e o painel mostra Usuário salvo! (código 453, Permissões alteradas pelo painel). As permissões web da conta ficam como estavam.

O painel só concede as permissões de painel que a conta identificada tem. Marcar, numa conta nova ou numa existente, uma permissão que ela não tem é recusado com Sem permissão, e nada é gravado: o log registra o código 458, Ação do painel recusada: sem permissão. Desmarcar é sempre possível, e uma permissão que a conta editada já tinha pode ficar. A regra é a mesma da página Usuários da web, e vale também para a própria conta. Até a v2.11.0, quem tinha a permissão Usuários concedia as três a qualquer conta, inclusive a si mesmo. Definir PIN grava ao fim da confirmação (código 452, PIN do painel definido).

Excluir uma conta no painel:

  1. No editor da conta, toque em Excluir usuário.
  2. Na pergunta Excluir este usuário?, com o nome da conta embaixo, toque em EXCLUIR. CANCELAR volta ao editor.

O painel mostra Usuário excluído e grava na hora, sem reiniciar (código 451, Usuário removido pelo painel). O painel não exclui a conta admin nem a conta que está identificada no momento.

Figura 72. A confirmação antes de excluir uma conta no painel.

Auditoria

O aparelho registra quem fez cada ação:

Onde O que fica registrado
Log de eventos, web Entrada aceita (Login OK: <conta>, código 300), recusada (301), página sem permissão (302), sessão expirada (304) e gravações de configuração (303)
Log de eventos, painel PIN aceito (308), com o nome da conta e o tempo que a conferência levou; PIN recusado (309); conta bloqueada (310)
Log de eventos, ações do painel Códigos 442, 445 e 450 a 459. Todos levam a posição da conta no contexto, e a maioria leva também o nome no texto
Linha de alarmes O nome da conta nos registros de ações feitas com PIN (desativar, bloquear, limites, manutenção) e nas janelas de manutenção abertas pela web (capítulo 22)
Painel O nome da conta no título do menu de configurações

O código 311, Entrada do teclado casa com duas contas, era de uma versão em que o PIN identificava a conta sozinho. Desde que a conta é escolhida antes do PIN, ele não ocorre mais.

Como as posições da tabela de contas são reaproveitadas, o que identifica a pessoa num registro antigo é o nome no texto, e não o número da posição. A leitura do log de eventos está no capítulo 16.

O que existe em cada imagem

Recurso release alpha Air
Contas, senhas e sessões da web Sim Sim Sim, enquanto a interface web está no ar (capítulo 19)
As 13 permissões Sim Sim Sim
Permissões de painel Usadas no painel Existem na página, sem efeito Existem na página, sem efeito
PIN, lista de contas e teclado do painel Sim Não Não
Campo e botão PIN na página Usuários Sim Escondidos Escondidos
Política de PIN em Configurações Sim Escondida Escondida
Senha conferida pelo aparelho em HTTPS Sim, com certificado instalado Não Não

Nas imagens alpha e Air, o aparelho recusa um PIN enviado pela interface de programação (users.pin), mas cria a conta normalmente.

Recuperação

Situação Onde está a saída
Ninguém sabe a senha do admin system admin reset no console serial (capítulo 18)
Painel travado por tentativas erradas Reinicie o aparelho (capítulo 18)
Uma conta bloqueada no painel Reinicie o aparelho, ou identifique-se com outra conta
O PIN do admin foi esquecido O admin define outro pelo botão PIN da página Usuários. Sem a senha web do admin, use antes system admin reset (capítulo 18)
Nenhuma conta com PIN Defina um PIN pela página Usuários: sem conta com PIN, a lista do painel fica vazia e ENTRAR só toca o som de erro
Conta sem nenhuma página web Dê a ela a permissão Painel (capítulo 13)

Voltar ao sumário

Capítulo 9

Rede, Wi-Fi e HTTPS

Este capítulo cobre a página Rede, a escolha da rede Wi-Fi, o que o aparelho faz quando perde a rede, o ponto de acesso de configuração durante a operação, o IP estático, o DNS, a porta web, o mDNS e o HTTPS com certificado próprio. É para quem instala o aparelho numa rede e para a equipe de TI que cuida dessa rede. A primeira configuração da rede, no primeiro boot, está no capítulo 4.

A página Rede

A página Rede (Network, rota /network) exige a permissão Rede PERM_NET_CONFIG. Ela tem duas partes:

  • Status da Conexão (Current Connection Status): o estado da rede agora, só para leitura;
  • Configuração (Network Configuration): o formulário, com as seções Wi-Fi, IPv4, Configuração de DNS, Servidor de Hora (NTP) e Servidor Web.

Como nas outras páginas de configuração, cada alteração fica preparada e só vale depois de gravada pelos botões da barra de topo (capítulo 5). Quase tudo nesta página exige reinício: com uma alteração da página Rede preparada, conte com Salvar e reiniciar.

A página Rede: à esquerda, o estado da conexão; à direita, o formulário de configuração.
Figura 73. A página Rede: à esquerda, o estado da conexão; à direita, o formulário de configuração.

Status da Conexão

Linha O que mostra
Status Conectado (Connected), em verde, ou Desconectado (Disconnected), em vermelho
IP O endereço IPv4 em uso. No ponto de acesso de configuração, 192.168.4.1
Máscara A máscara de sub-rede em uso
Gateway O gateway em uso
DNS O servidor DNS em uso
MAC O endereço MAC do rádio

Os valores são os que estão em uso agora, não os configurados: com DHCP, são os que o roteador entregou.

Conectado quer dizer que o aparelho terminou de entrar na rede. Com o NTP ligado, isso inclui o primeiro acerto do relógio: até lá, a linha diz Desconectado mesmo com um IP na linha de baixo (capítulo 10).

Wi-Fi

Campo O que faz Faixa e formato Fábrica Aplicação Chave
SSID (SSID (Network Name)) Nome da rede Wi-Fi 1 a 31 caracteres, sem caracteres de controle Vazio Reinicia (net) ssid
Senha (Password (Leave empty to keep current)) Senha da rede Até 31 caracteres; vazio mantém a senha atual Vazio Reinicia (net) pass
  • O botão Buscar (Scan), ao lado do SSID, lista as redes ao alcance (Escolher a rede pela busca).
  • O botão com o olho, ao lado da Senha, mostra ou esconde o que você digitou (Mostrar senha / Ocultar senha).
  • O campo Senha sempre abre vazio. O aparelho nunca devolve a senha gravada, nem para um administrador.
  • Um SSID vazio na gravação é ignorado: o aparelho mantém a rede atual.

O rádio do Pico W só opera em 2,4 GHz. Uma rede só de 5 GHz não aparece na busca e não aceita o aparelho.

IPv4

Campo O que faz Faixa e formato Fábrica Aplicação Chave
DHCP (Obtain IP automatically (DHCP)) Pede o endereço ao roteador Ligado ou desligado Ligado Reinicia (net) use_dhcp
IP Estático (Static IP Address) Endereço fixo do aparelho IPv4, como 192.0.2.10 192.168.1.100 Reinicia (net) ip
Máscara (Subnet Mask) Máscara da sub-rede IPv4, como 255.255.255.0 255.255.255.0 Reinicia (net) mask
Gateway Roteador da sub-rede IPv4 192.168.1.1 Reinicia (net) gw

Com DHCP ligado, os três campos de baixo ficam esmaecidos e não são gravados. Para usar IP fixo:

  1. Desligue DHCP.
  2. Preencha IP Estático, Máscara e Gateway.
  3. Na seção Configuração de DNS, desligue Obter DNS automaticamente (DHCP) e preencha DNS Primário (DNS).
  4. Toque em Salvar e reiniciar.
  5. Depois do reinício, abra a interface pelo endereço novo.

Um endereço que não é um IPv4 válido é recusado (net.ip, net.mask ou net.gw), e o aparelho mantém o anterior (capítulo 5). O aparelho não confere se o endereço está livre na rede: reserve-o no roteador ou escolha um fora da faixa do DHCP.

Figura 74. A seção IPv4 com o DHCP desligado e os campos do IP fixo preenchidos.

DNS

Campo O que faz Faixa e formato Fábrica Aplicação Chave
Obter DNS automaticamente (DHCP) (Obtain DNS automatically (DHCP)) Usa o DNS que o roteador entrega Ligado ou desligado Ligado Reinicia (web) dns_auto
DNS Primário (Primary DNS) Primeiro servidor DNS IPv4 8.8.8.8 Reinicia (net) dns1
DNS Secundário (Secondary DNS) Segundo servidor DNS IPv4, ou vazio para não usar Vazio Reinicia (web) dns2

Com Obter DNS automaticamente (DHCP) ligado, os dois campos ficam esmaecidos. O DNS que vale em cada combinação:

DHCP DNS automático DNS primário em uso DNS secundário em uso
Ligado Ligado O do roteador O do roteador
Ligado Desligado DNS Primário DNS Secundário, se preenchido
Desligado Desligado DNS Primário DNS Secundário, se preenchido
Desligado Ligado DNS Primário Nenhum

Com IP fixo não há roteador para entregar DNS: o DNS Primário vale sempre. Desligue o DNS automático para poder editá-lo e para o secundário valer.

O aparelho precisa de DNS para achar servidores por nome: o NTP (capítulo 10) e o coletor da telemetria, quando configurado por nome (capítulo 21).

Um DNS Primário inválido é ignorado sem aviso, e o aparelho mantém o anterior. Um DNS Secundário inválido é recusado com net.dns2.

Servidor de Hora (NTP)

Campo O que faz Faixa e formato Fábrica Aplicação Chave
Endereço do Servidor (Server Address) Servidor NTP preferido Nome ou IP, até 31 caracteres; vazio usa pool.ntp.org Vazio Reinicia (time) ntp_server

A dica abaixo do campo diz Deixe vazio para usar o padrão (pool.ntp.org). Se o NTP estiver desligado na página Configurações, a seção mostra a faixa NTP está desabilitado. com o atalho Habilite em Configurações do Sistema →. Como o aparelho escolhe e troca de servidor está no capítulo 10.

Servidor Web

Campo O que faz Faixa e formato Fábrica Aplicação Chave
Porta HTTP (HTTP Port) Porta do servidor web 1 a 65535 80 Reinicia (web) web_port
Conexões persistentes (keep-alive) (Persistent connections (keep-alive)) Reaproveita a conexão entre pedidos Ligado ou desligado Ligado Reinicia (web) web_ka

A dica da porta diz Padrão: 80. Após salvar, o navegador redireciona automaticamente para a nova porta. Depois de Salvar e reiniciar, a página avisa Salvo. Redirecionando para nova porta… e abre o endereço novo cerca de 15 s depois. Guarde a porta: sem ela, o endereço sem porta não responde. A porta vale também para o HTTPS, com uma exceção: com a porta 80, o HTTPS atende na 443 (HTTPS).

Conexões persistentes (keep-alive) está ligado de fábrica desde a v2.3.0 e vale para HTTP e HTTPS. Em HTTPS, ele evita uma negociação TLS a cada pedido, e a dica diz que as páginas carregam cerca de 60 % mais rápido. O interruptor só aparece quando há um certificado HTTPS instalado. Desligue-o apenas se um proxy ou um cliente se comportar mal com conexões persistentes.

Figura 75. A seção Servidor Web num aparelho com certificado instalado: o interruptor de conexões persistentes só aparece nesse caso.

Escolher a rede pela busca

O botão Buscar lista as redes Wi-Fi ao alcance do aparelho, para você escolher sem digitar o nome.

  1. Toque em Buscar. O botão muda para Buscando….
  2. Espere a lista, normalmente em cerca de 1 s.
  3. Toque na rede desejada. O nome vai para o campo SSID, a lista se fecha e o cursor vai para Senha.
  4. Digite a senha e toque em Salvar e reiniciar.

Cada linha da lista mostra:

  • um cadeado, se a rede é protegida; nada, se é aberta;
  • o nome da rede;
  • quatro barras de sinal;
  • o sinal em dBm.

Pare o ponteiro sobre a linha para ver Rede protegida ou Rede aberta e o sinal.

Barras Sinal
4 −55 dBm ou mais
3 De −67 a −56 dBm
2 De −78 a −68 dBm
1 −78 dBm ou abaixo

A lista tem no máximo 12 redes, da mais forte para a mais fraca. Uma rede com vários pontos de acesso, como uma rede mesh, aparece uma vez só, com o sinal do ponto mais forte. Redes ocultas não aparecem: digite o nome delas no campo SSID.

A busca funciona também de dentro do ponto de acesso de configuração. O aparelho liga a interface de estação ao lado do AP só para buscar, e o AP continua no ar.

Mensagens possíveis:

Mensagem Quando
Nenhuma rede encontrada (No networks found) A busca terminou sem nenhuma rede visível
Rádio ocupado — tente de novo em instantes (Radio busy — try again in a moment) O aparelho está buscando a própria rede para se reconectar, ou o rádio recusou a busca
A busca falhou (The scan failed) A busca não terminou. O aparelho desiste depois de 15 s, e a página, depois de cerca de 18 s
Figura 76. A lista de redes depois de Buscar: cadeado, nome, barras e sinal em dBm, da mais forte para a mais fraca.

A mesma busca está disponível para integradores em GET /api/wifi/scan, com a permissão Rede: a primeira chamada, com ?again=1, dispara a busca e responde {"scanning":true}; as seguintes devolvem a lista quando ela fica pronta (capítulo 26).

Quando a rede cai: a escada de reconexão

O aparelho nunca desiste da rede configurada. Quando não consegue entrar, ele tenta de novo com intervalos crescentes, e descansa quando as tentativas se esgotam. É a escada de reconexão.

Os degraus

Uma tentativa de entrar na rede leva até 20 s. Antes de cada tentativa, o aparelho busca a rede para conferir se ela está no ar. Se a rede não aparece em duas buscas seguidas, o aparelho tenta entrar assim mesmo: é assim que uma rede oculta, que nunca aparece em busca, volta a conectar. Cada busca tem 15 s de prazo.

Depois de cada tentativa que falha, a espera até a próxima dobra:

Falha Espera antes da próxima busca
Queda da conexão (ponto de partida) 5 s
1ª 10 s
2ª 20 s
3ª 40 s
4ª 80 s
5ª Dormência: 10 min

O intervalo tem teto de 120 s, que a escada não chega a atingir: a 5ª falha já leva à dormência.

Na dormência, a espera antes de cada busca passa a ser de 10 min. O aparelho cumpre três dormências. Se a rede não voltar, ele volta ao primeiro degrau e registra Dormancy over — back to fast retries. Uma conexão bem-sucedida, a qualquer momento, zera a escada.

Durante a escada, o aparelho continua medindo, gravando o histórico e atendendo o painel. A telemetria pendente espera a rede voltar (capítulo 21). A escada não abre o AP de configuração: o aparelho tenta a rede configurada pelo tempo que for preciso, e o AP só abre quando alguém pede (Quando o AP abre). Da v2.7.1 à v2.8.0, a escada também abria o AP sozinha.

Figura 77. A escada de reconexão: esperas que dobram, três dormências de 10 min e o recomeço, até a rede voltar.

Quando o rádio recusa o pedido

Um sinal fraco não impede o pedido de conexão: o rádio aceita o pedido, e a associação falha depois, como uma tentativa comum da escada. Mas o rádio pode recusar o próprio pedido, quando o chip ou o driver entra num estado do qual um pedido novo não o tira. Cada recusa vira o evento Conectando WiFi (10) com contexto 2, e a escada segue.

Três recusas seguidas, com o aparelho ligado há mais de 30 min, fazem o aparelho reiniciar para recuperar o rádio. Antes, ele grava o evento 10 com contexto 3. Nos primeiros 30 min depois de um boot, ele não reinicia por esse motivo, então um rádio que continua quebrado custa no máximo um reinício a cada meia hora.

Até a v2.8.0, uma recusa prendia o aparelho por até 15 s dentro do pedido, e o watchdog, que reinicia o aparelho depois de 8,4 s sem resposta, o reiniciava. O log mostrava só a autópsia de um travamento no módulo WIFI, contexto 202 (Como ler um travamento).

Quando o rádio não responde à busca

A escada mede quanto tempo o pedido de busca leva para voltar. Num rádio que responde, ele volta em milissegundos. Num rádio que parou de responder, só volta depois do tempo-limite do driver, perto de 1 s. Uma busca assim que passa do prazo de 15 s é de um rádio mudo.

Logo depois de o rádio emudecer, os primeiros pedidos ainda voltam em milissegundos, com erro. Por isso, quando uma busca que voltou rápido passa do prazo, o aparelho faz uma leitura curta ao rádio. Se o rádio responde, a busca só se perdeu e a escada segue como sempre. Se não responde, é um rádio mudo.

Depois de uma busca de rádio mudo, a escada não tenta entrar na rede às cegas: num rádio mudo, esse pedido de conexão prendia o aparelho além dos 8,4 s do watchdog.

Duas buscas seguidas de um rádio mudo, com o aparelho ligado há mais de 30 min, fazem o aparelho reiniciar para recuperar o rádio. Antes, ele grava o evento 10 com contexto 4. Nos primeiros 30 min depois de um boot, ele segue buscando, sem reiniciar e sem tentar entrar na rede.

Até a v2.11.1, a escada tentava entrar às cegas depois de duas buscas sem resposta, e o watchdog reiniciava o aparelho. O log mostrava só a autópsia de um travamento no módulo WIFI, contexto 202 (Como ler um travamento).

Outros motivos para reconectar

Conectado, o aparelho confere o sinal uma vez por minuto. Um sinal impossível, 0 dBm ou mais, ou abaixo de −120 dBm, ou uma leitura que o rádio não responde, indica que o rádio parou de responder de verdade, mesmo que o Wi-Fi ainda se diga conectado. Duas leituras assim seguidas fazem o aparelho derrubar a conexão e entrar na escada, com o evento Implausible RSSI twice — link presumed dead, reconnecting.

Como ler a escada no log de eventos

A página Histórico e Logs mostra os eventos (capítulo 16). Os que contam a história da rede:

Código Texto do evento Quando
522 Gerenciador WiFi iniciando No boot, com rede configurada
520 ou 521 Modo DHCP ativado ou Modo IP estático ativado No boot
523 SSID WiFi não configurado No boot, sem rede configurada
12 Scanning for SSID (backoff=<n>s) Cada busca da escada
10 SSID found, connecting... A rede apareceu na busca
10 SSID not in scan — associating anyway Tentativa sem ver a rede, depois de duas buscas
10 The radio refused the join O rádio recusou o pedido; o contexto é 2 (Quando o rádio recusa o pedido)
10 The radio refused 3 joins in a row - restarting to recover it Três recusas seguidas: o aparelho reinicia; o contexto é 3
10 Radio silent on two scans (start took <n> ms) - restarting to recover it Duas buscas seguidas sem resposta do rádio: o aparelho reinicia; o contexto é 4 (Quando o rádio não responde à busca)
525 Retry in <n>s Uma tentativa falhou; o contexto é o número de falhas seguidas
526 Dormant: retry in 600s Início de uma dormência
526 Dormancy over — back to fast retries Fim das três dormências
14 IP: <endereço> Entrou na rede
11 WiFi signal lost, entering stealth scan A conexão caiu
11 Implausible RSSI twice — link presumed dead, reconnecting O rádio parou de responder; o contexto é a leitura, ou −999 quando o rádio não respondeu à leitura
12 Scan never finished — abandoning it (start took <n> ms, read <r>) Uma busca passou do prazo de 15 s; o tempo é o que o pedido da busca levou para voltar, e a leitura, quando houve, é a resposta do rádio: 0 quando respondeu
403 AP iniciado O AP de configuração abriu (O AP durante a operação)

O log de eventos não grava cada repetição. Uma falha que se repete, como Retry in <n>s, é gravada na primeira vez e depois só a cada hora, enquanto durar. A volta da rede (IP: ...) é gravada porque encerra a falha. Por isso, uma escada longa aparece no log como poucas linhas. O filtro está explicado no capítulo 16.

O AP de configuração durante a operação

release alpha

O ponto de acesso de configuração é uma rede Wi-Fi que o próprio aparelho cria, quando alguém pede, para ser configurado sem outra rede: num aparelho novo, ou num que não consegue entrar na sua rede. O primeiro uso, num aparelho novo, está no capítulo 4.

A rede do AP:

Item Valor
Nome da rede O nome do aparelho seguido de _SETUP, como simut_SETUP
Segurança WPA2, com uma chave de 10 caracteres
Endereço do aparelho http://192.168.4.1
Qualquer outro endereço Leva ao aparelho (capítulo 13)

A chave é derivada da identidade do chip e é sempre a mesma para aquele aparelho, mesmo depois de um reset de fábrica. Ela usa letras maiúsculas e algarismos, sem O, 0, I e 1, para ser lida em voz alta sem confusão. A chave aparece:

  • no console serial, quando o AP abre;
  • no painel, quando o AP abre: no boot, pelo gesto, ou em operação, pelo menu ou pelo comando ap;
  • no LCD do alpha, na terceira das páginas do AP (capítulo 12);
  • na resposta do comando ap do console (capítulo 14).

Anote a chave do seu aparelho na primeira configuração.

Quando o AP abre

O AP só abre quando alguém pede:

Quem pede Quando abre
release Item 12 do menu do painel, Modo de Configuração, com a permissão Rede no painel (capítulo 11) Na hora
Comando ap no console, pelo USB ou pelo Bluetooth (capítulo 14) Na hora
release Gesto de toque no boot (capítulo 11) No boot

O aparelho nunca troca a rede dele pelo AP sozinho. Sem rede configurada, ele liga, mede e grava como sempre, e a release pergunta a data e a hora no fim do boot (capítulo 10). Com a rede fora do ar, ele segue a escada de reconexão até ela voltar (Quando a rede cai).

Da v2.7.1 à v2.8.0, a release e o alpha também abriam o AP sozinhos: no boot de um aparelho sem rede configurada, e pela escada de reconexão. A escada abria o AP na primeira dormência de um aparelho que nunca tinha obtido IP desde que ligou, cerca de 6 a 7 min depois de ligar (medido em bancada em 22/09/2026, com uma rede que não existe), ou ao fim de uma volta inteira da escada num aparelho que já tinha obtido IP, cerca de 68 min pela aritmética da escada.

O log de eventos registra quem pediu no contexto do evento 403: 0 para o comando ap ou o painel, 1 para o gesto no boot. Os contextos 2 (aparelho sem rede configurada) e 3 (a escada) só aparecem em logs gravados da v2.7.1 à v2.8.0.

Enquanto o AP está aberto

Com o AP aberto, o aparelho continua medindo. Ele lê os sensores, confere os limites dos alarmes e grava o histórico com o AP de configuração no ar. Só a telemetria e o syslog esperam a rede voltar; a linha de alarmes guarda os eventos na fila e os envia depois. O painel fica na tela do AP, com a rede, a chave e o endereço: um alarme soa pelo buzzer, mas não aparece no vidro enquanto essa tela estiver aberta. No alpha, o LCD mostra as páginas do AP: o endereço, a rede e a chave (capítulo 12).

  • A telemetria e o syslog esperam a rede voltar.
  • O aparelho não tenta a rede configurada enquanto o AP está aberto.
  • Num aparelho com rede configurada, o AP dura 15 min, aberto pelo painel, pelo comando ap ou pelo gesto no boot. Depois disso o aparelho reinicia para tentar a rede de novo, com ou sem alguém conectado ao AP. O evento é Timeout na conexão WiFi (525) com o texto AP mode timeout, rebooting to STA. Se a rede ainda não estiver lá, o aparelho segue a escada de reconexão, e o AP só volta se alguém o abrir de novo.
  • Num aparelho sem rede configurada, o AP fica aberto até alguém gravar uma rede ou reiniciar o aparelho.
  • Até a v2.11.0, o prazo do AP aberto pelo gesto no boot lia um nome de rede que nada tinha gravado. Esse AP podia ficar aberto para sempre num aparelho com rede, ou fechar em 15 min num aparelho sem rede, conforme o que estivesse na memória. Na bancada, em 04/10/2026, ele fechou em 15 min num aparelho com rede.

Para sair do AP com a rede certa:

  1. Conecte o celular ou o computador à rede <nome>_SETUP, com a chave.
  2. Abra http://192.168.4.1 e entre com uma conta que tenha a permissão Rede.
  3. Na página Rede, toque em Buscar, escolha a rede e digite a senha.
  4. Toque em Salvar e reiniciar.

O aparelho reinicia e tenta a rede nova.

air O Air não tem painel: o AP dele só abre pelo comando ap, e ele nunca o abriu sozinho, nem da v2.7.1 à v2.8.0. O rádio do Air só existe durante um despertar, e ninguém está diante de um aparelho hibernando para usar o AP. O jeito indicado de configurar a rede do Air é o console, por USB ou Bluetooth (capítulo 19).

mDNS: o endereço pelo nome

release

Na imagem release, o aparelho responde pelo nome <nome>.local na rede local, como http://simut.local. O nome é o campo Nome da página Configurações (capítulo 5). Não há nada a configurar.

O aparelho também se anuncia como um serviço _simut._tcp, para que um programa descubra todos os aparelhos da rede sem saber os endereços. O anúncio leva a porta do servidor web e quatro campos de texto:

Campo Conteúdo
uid Identidade do chip, 16 algarismos hexadecimais
ver Versão do firmware, como 2.11.1
env Imagem: release
tls 1 com HTTPS, 0 com HTTP

Com HTTPS na porta padrão, o anúncio leva a porta 443.

O nome e o serviço passam a responder quando o aparelho termina de entrar na rede. Com o NTP ligado, isso inclui o primeiro acerto do relógio (capítulo 10). Uma falha registra Falha ao iniciar mDNS (528).

Para procurar os aparelhos num computador com Linux:

avahi-browse -rt _simut._tcp

As imagens alpha e Air não têm mDNS. Use o endereço IP.

HTTPS

release

Só a imagem release tem servidor HTTPS. Sem certificado instalado, ela atende em HTTP, como as outras. Com um par de certificado e chave instalado, ela passa a atender só em HTTPS a partir do reinício seguinte.

Como o HTTPS se comporta

  • Porta: com a Porta HTTP em 80, o HTTPS atende na 443, e https://192.0.2.10 funciona. Com outra porta configurada, o HTTPS atende nela.
  • Um protocolo só: o endereço http:// deixa de responder. O aparelho nunca serve os dois ao mesmo tempo.
  • Um cliente seguro por vez: o aparelho atende uma conexão TLS por vez. As páginas enfileiram as próprias consultas (capítulo 13).
  • Protocolo e cifras: só TLS 1.2, com troca de chaves ECDHE e cifra AES-GCM de 128 ou 256 bits. Um cliente que só fale TLS 1.1 ou menos, ou só cifras CBC ou ChaCha20, não conecta.
  • Sessão: o cookie de sessão ganha a marca Secure (capítulo 13).
  • AP: ligado já no AP, o aparelho atende em HTTP (Enquanto o AP está aberto).
  • Falha segura: se o par está ausente, vazio, maior que 8 KB ou não pode ser lido, o aparelho sobe em HTTP na porta configurada e registra Certificado web inválido (HTTP) (576). Um certificado ruim nunca tranca você do lado de fora.

Gerar um par autoassinado

Gere um par para cada aparelho, num computador com OpenSSL 1.1.1 ou mais novo. Ponha no certificado os nomes pelos quais o aparelho será acessado: o IP e, se usar mDNS, o nome .local. Sem isso, o navegador trata o certificado como de nenhum endereço, mesmo depois de você confiar nele.

Com chave EC P-256, a recomendada:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -keyout web_key.pem -out web_cert.pem -days 3650 -nodes \
  -subj "/CN=simut" \
  -addext "subjectAltName=IP:192.0.2.10,DNS:simut.local"

Com chave RSA de 2048 bits:

openssl req -x509 -newkey rsa:2048 \
  -keyout web_key.pem -out web_cert.pem -days 3650 -nodes \
  -subj "/CN=simut" \
  -addext "subjectAltName=IP:192.0.2.10,DNS:simut.local"

Troque 192.0.2.10 e simut pelo IP e pelo nome do seu aparelho. -days 3650 dá dez anos de validade.

O aparelho aceita:

  • chave EC ou RSA; a EC precisa ser de uma curva que o firmware conheça, e a P-256 é a recomendada;
  • a chave nos três formatos PEM: PRIVATE KEY, EC PRIVATE KEY e RSA PRIVATE KEY;
  • uma cadeia de certificados de uma autoridade certificadora, com o certificado do aparelho primeiro.

A chave não pode ter senha. Para tirar a senha de uma chave:

openssl pkey -in key.pem -out plain_key.pem

Instalar o par

O par se instala pela rota POST /api/tls. Nenhuma página da interface web usa essa rota, e a página Arquivos recusa enviar qualquer arquivo para /config, onde o par fica. Há dois caminhos: o script do repositório ou o curl.

A rota exige uma conta de administrador completo, com todas as permissões. Outra conta recebe 403.

Pelo script tools/install_tls_cert.py, que entra no aparelho, envia o par e, com --reboot, reinicia:

export SIMUT_WEB_USER=admin
read -rsp 'Senha do admin: ' SIMUT_WEB_PASS; echo; export SIMUT_WEB_PASS
python3 tools/install_tls_cert.py --host 192.0.2.10 \
  --cert web_cert.pem --key web_key.pem --reboot

Pelo curl. Primeiro abra uma sessão, depois envie os dois blocos PEM juntos no corpo do pedido, em qualquer ordem, com um tipo de conteúdo que não seja de formulário:

H=192.0.2.10
NONCE=$(curl -s -c jar http://$H/api/login_init | sed 's/.*"nonce":"\([^"]*\)".*/\1/')
HASH=$(printf '%s' 'sua-senha' | sha256sum | cut -d' ' -f1)
curl -s -b jar -c jar -X POST http://$H/api/login \
  --data-urlencode user=admin --data-urlencode pass=$HASH \
  --data-urlencode nonce=$NONCE
cat web_cert.pem web_key.pem | curl -s -b jar -X POST --data-binary @- \
  -H 'Content-Type: application/x-pem-file' http://$H/api/tls

A página de entrada envia a senha já resumida em SHA-256, e o curl precisa fazer o mesmo. Este exemplo vale para senhas só com caracteres ASCII. O processo de entrada está no capítulo 26.

Com o par aceito, a resposta é:

{"ok":true,"installed":true,"key":"EC (curve 23)","serving":"http","nextBoot":"https","rebootRequired":true,"note":"setup AP mode always serves HTTP"}

key descreve a chave: EC (curve 23) é a P-256, e uma chave RSA aparece como RSA (2048 bits). serving é o protocolo em uso agora e nextBoot, o do próximo boot. O servidor em execução não muda: o par vale a partir do próximo reinício. Para reiniciar:

curl -s -b jar -X POST "http://$H/api/action?op=reboot"

Depois do reinício, abra https://192.0.2.10. O log de eventos registra Par de certificados web instalado (579) na instalação e, no boot seguinte, Cert SSL carregado (34) com o texto HTTPS server (provisioned cert) e a porta no contexto.

O aparelho confere o par antes de gravar qualquer coisa: ele deriva a chave pública da chave privada e a compara com a do certificado. Um par trocado é recusado agora, com o par anterior intacto, em vez de subir quebrado no próximo boot. A gravação usa arquivos temporários e só depois os renomeia, para que uma falha no meio não apague um par que funcionava.

Respostas de erro:

Resposta Motivo
400 empty body - send the certificate and key PEM blocks Corpo vazio. Confira o Content-Type: um corpo de formulário não chega à rota
400 no CERTIFICATE block in the body Falta o certificado
400 no PRIVATE KEY block in the body Falta a chave
400 the private key is passphrase-encrypted; decrypt it first: ... A chave tem senha
400 the key does not belong to this certificate Chave e certificado não são do mesmo par
400 certificate and key are on different curves Chave e certificado EC de curvas diferentes
400 this firmware's EC implementation does not know that curve Curva EC que o firmware não conhece. Use P-256
400 unsupported RSA key size Chave RSA maior que 8192 bits
403 Forbidden — admin only A conta não é administrador completo
413 payload too large (8 KB) O corpo passou de 8.192 bytes
429 rate limited Menos de 5 s desde a tentativa anterior
500 could not write the pair to /config Falha de gravação. O par anterior continua lá

Um par recusado registra Certificado web inválido (HTTP) (576) com o contexto 3.

O que o navegador mostra

Um certificado autoassinado não foi emitido por uma autoridade que o navegador conheça. No primeiro acesso, o navegador mostra uma página de aviso dizendo que a conexão não é particular ou que o certificado não é confiável. Para seguir:

  1. Confira que o endereço é o do seu aparelho.
  2. Abra os detalhes do aviso, geralmente em Avançado.
  3. Escolha continuar para o endereço.

O navegador lembra a exceção por um tempo, conforme o navegador. Para não ver mais o aviso, importe o web_cert.pem como certificado confiável no sistema operacional ou no navegador de cada computador que acessa o aparelho. Isso só funciona se o certificado tiver o IP e o nome no campo subjectAltName.

Figura 78. O aviso do navegador no primeiro acesso a um aparelho com certificado autoassinado.

Voltar para HTTP

Para desligar o HTTPS, use o console serial (capítulo 14):

system https off confirm

O aparelho apaga o par, registra HTTPS disabled via serial (cert deleted) com o código 303 e reinicia em HTTP. O comando existe também no console de emergência da release. Ele é a saída quando um par entra, mas toda negociação TLS falha e a interface fica inalcançável.

Depois de voltar para HTTP, o primeiro acesso pelo mesmo navegador pode voltar direto para a página de entrada, por causa do cookie Secure antigo. A página avisa e diz o que fazer (capítulo 13).

O par e a atualização de firmware

A atualização de firmware reformata o sistema de arquivos e só preserva a configuração principal (/config/system.bin). O par de certificados não é preservado pela atualização: depois dela, o aparelho volta a atender em HTTP.

O backup .bkp, que a página Arquivos baixa antes de atualizar, contém todos os arquivos, inclusive o par. Para voltar ao HTTPS depois de atualizar, restaure esse backup ou instale o par de novo (capítulo 17).

O comando system format também apaga o par. A chave privada nunca é servida pela rota de download de arquivos.

CORS para o gestor de frota

O gestor de frota é uma página que roda no navegador do operador e fala com vários aparelhos ao mesmo tempo (capítulo 27). O navegador bloqueia essas chamadas, a menos que o aparelho autorize a origem da página: é o CORS.

A origem se configura pelo console serial, inclusive no console de emergência da release:

system cors http://gestor.exemplo.com.br:8080
reload confirm

A origem vale depois do reinício. Para desligar:

system cors off
reload confirm

Regras da origem:

  • começa com http:// ou https://;
  • tem só o nome ou IP e, opcionalmente, :porta;
  • não tem barra no fim, caminho nem *;
  • tem no máximo 64 caracteres.

A origem fica em /config/cors.txt. No boot, o aparelho registra CORS ligado para a origem (577) ou, se o arquivo for inválido, Origem CORS inválida (CORS desligado) (578). Um integrador também pode gravar a origem pela chave cors da seção sys de POST /api/commit_all; ela também só vale depois do reinício.

Referência rápida

Os campos da página Rede, na seção net de POST /api/commit_all:

Chave Campo Faixa Fábrica Grupo
ssid SSID 1 a 31 caracteres; vazio mantém vazio net, reinicia
pass Senha até 31 caracteres; vazio mantém vazio net, reinicia
use_dhcp DHCP 1 ou 0 1 net, reinicia
ip IP Estático IPv4; só com DHCP desligado 192.168.1.100 net, reinicia
mask Máscara IPv4; só com DHCP desligado 255.255.255.0 net, reinicia
gw Gateway IPv4; só com DHCP desligado 192.168.1.1 net, reinicia
dns_auto Obter DNS automaticamente (DHCP) 1 ou 0 1 web, reinicia
dns1 DNS Primário IPv4 8.8.8.8 net, reinicia
dns2 DNS Secundário IPv4 ou vazio vazio web, reinicia
ntp_server Endereço do Servidor até 31 caracteres; vazio = pool.ntp.org vazio time, reinicia
web_port Porta HTTP 1 a 65535 80 web, reinicia
web_ka Conexões persistentes (keep-alive) 1 ou 0 1 web, reinicia

Os limites de sinal que o aparelho usa:

Limite Efeito
−78 dBm ou abaixo A telemetria e os envios pesados esperam o sinal melhorar (capítulo 21); a métrica simut_wifi_connected fica em 0 (capítulo 24). As leituras e o painel continuam
0 dBm ou mais, ou abaixo de −120 dBm Leitura impossível. Duas seguidas, com um minuto entre elas, forçam uma reconexão
Sem conexão O sinal é informado como −100 dBm

As barras de sinal do painel usam limites próprios (capítulo 11), e o ícone do LCD, os seus (capítulo 12).

Voltar ao sumário

Capítulo 10

Data e hora

Este capítulo explica de onde vem a hora do aparelho: o NTP, o fuso horário, o acerto manual, pela web, pelo painel ou pelo console, e o relógio provisório que vale até o primeiro acerto. Mostra também o que acontece com o histórico quando o relógio é corrigido. É para quem instala o aparelho, sobretudo numa rede sem acesso à internet ou num lugar sem Wi-Fi.

De onde vem a hora

O aparelho não guarda a hora quando é desligado ou reiniciado; o Air é uma exceção parcial (O relógio do Air através do sono). Toda vez que liga, ele precisa descobrir que horas são. Há três fontes, nesta ordem de preferência:

  1. NTP: a hora certa, pela rede. É o padrão de fábrica (NTP).
  2. Acerto manual: a hora que alguém digitou, pela interface web, pelo painel ou pelo console (Acerto manual).
  3. Relógio provisório: uma estimativa feita a partir do histórico, usada até uma das duas primeiras chegar (O relógio provisório).

Internamente, o aparelho conta o tempo em UTC. O fuso horário só entra na hora de mostrar a hora e de decidir em qual arquivo diário do histórico cada registro cai (Fuso horário).

NTP

O NTP vem ligado de fábrica. Ele se liga e desliga na página Configurações, seção Data e Hora, pelo interruptor Sincronizar automaticamente via NTP, e o servidor se escolhe na página Rede, seção Servidor de Hora (NTP), campo Endereço do Servidor. As duas alterações exigem Salvar e reiniciar (capítulo 5, capítulo 9).

Os servidores

O aparelho consulta dois servidores:

Posição Servidor
Primeiro O Endereço do Servidor da página Rede; vazio, pool.ntp.org
Segundo time.nist.gov, sempre

O servidor pode ser um nome ou um IP, com até 31 caracteres. Um nome exige DNS funcionando (capítulo 9). O NTP usa a porta UDP 123: numa rede com firewall, libere essa porta até o servidor escolhido.

Tentativas e troca de servidor

O aparelho pede a hora assim que entra na rede. Se ela não chega, ele pede de novo, e a espera entre os pedidos triplica até o teto de 15 min:

Tentativa Espera antes dela
1ª — (ao entrar na rede)
2ª 20 s
3ª 1 min
4ª 3 min
5ª 9 min
6ª em diante 15 min

Depois de três esperas sem resposta, cerca de 4 min 20 s depois do primeiro pedido, o aparelho troca o primeiro servidor por pool.ntp.org, se ele já não for esse. A troca vale até o próximo reinício. O log de eventos registra NTP fallback: <servidor> -> pool.ntp.org.

Uma queda da rede Wi-Fi zera a contagem: na volta, as esperas recomeçam de 20 s.

Sem servidor NTP alcançável

O que o log mostra

Os eventos do relógio, na página Histórico e Logs (capítulo 16):

Código Texto do evento Quando
524 Hora provisória do flash: Provisional: <data> <hora> No boot, ao ligar o relógio provisório
13 NTP sincronizado: NTP OK: <data> <hora> O relógio está acertado e o aparelho terminou de entrar na rede. Aparece também a cada reconexão
13 NTP fallback: <servidor> -> pool.ntp.org Troca de servidor; o contexto é o número de falhas
13 NTP disabled — manual RTC mode O aparelho entrou na rede com o NTP desligado
13 RTC set manually Acerto manual. O contexto diz por onde: 1 interface web (POST /api/set_time), 2 console (time), 3 painel, item 4 do menu, 4 painel, pergunta do boot
408 NTP corrigindo timestamps: NTP correction: <n>s O primeiro acerto, pelo NTP ou à mão, corrigiu o relógio provisório em mais de 5 s; o contexto é a correção, em segundos
409 Timestamps corrigidos O histórico foi corrigido; o contexto é o número de blocos
410 Caches de gráfico invalidados Os gráficos serão refeitos com as horas corrigidas

O log grava só o código e o contexto, não o texto (capítulo 16). No evento 13, o contexto separa as origens: 0 é NTP OK ou o NTP desligado; de 1 a 4, um acerto à mão; a troca de servidor é um aviso (WRN), com o número de falhas. Até a v2.8.0, o acerto à mão também gravava o contexto 0.

Uma correção maior que 1 h aparece como aviso, e não como informação. Depois de uma falta de energia, uma correção grande é normal: ela mede quanto tempo o aparelho ficou desligado (O relógio provisório). Uma correção grande com o aparelho sempre ligado indica um relógio provisório mal semeado. O contexto do evento 408 vai até 32.767 s, cerca de 9 h; um valor travado nesse número indica uma correção ainda maior.

Figura 79. Os eventos de um boot com NTP: a hora provisória, o acerto e a correção do histórico.

Fuso horário

O fuso se configura na página Configurações, seção Identidade, campo Fuso Horário (capítulo 5).

Item Valor
Formato Diferença para o UTC em horas inteiras, com sinal: -3 para Brasília, 9 para Tóquio
Faixa −12 a +14
Fábrica −3
Aplicação Exige reinício (grupo time)

O fuso é um número fixo. Não há horário de verão nem fusos com meia hora ou 45 min, como os da Índia (+5:30) ou do Nepal (+5:45). Onde há horário de verão, mude o Fuso Horário nas datas de troca. Desde a v2.4.9-beta, o aparelho guarda o fuso só como esse número; nada no firmware lê a variável de ambiente TZ.

O fuso decide:

  • a hora mostrada no painel e no console;
  • o arquivo diário do histórico em que cada registro entra, pela data local (capítulo 15);
  • a conversão da data e da hora digitadas no acerto manual pela web.

Os registros do histórico guardam o instante em UTC. Mudar o fuso não altera os registros já gravados.

Acerto manual

Com o NTP desligado, ou sem rede, a hora do aparelho vem do acerto manual. Há três caminhos: a interface web, o painel da release e o console, em todas as imagens. Os três valem na hora, sem reinício, e o primeiro acerto depois do boot corrige a hora dos blocos do histórico que o boot começou sob o relógio provisório (Quando o primeiro acerto corrige o relógio).

Com o NTP ligado, um acerto manual vale até a próxima sincronização.

Pela interface web

  1. Abra Configurações e vá até Data e Hora.
  2. Preencha Data e Hora, na hora local do fuso configurado.
  3. Toque em Aplicar Agora.

O aviso Hora aplicada. aparece abaixo do botão. O acerto vale na hora, sem reinício e sem passar pelos botões da barra de topo (capítulo 5). O seletor de data começa em 01/01/2026.

Figura 80. O acerto manual com o NTP desligado: data, hora e o botão Aplicar Agora da seção.

Para integradores, a rota é POST /api/set_time com o corpo {"epoch": <segundos UTC>}, com a permissão Sistema (capítulo 26).

No painel

release A tela Data e hora abre de dois jeitos:

  • No fim do boot, sozinha, num aparelho sem rede configurada e com o relógio provisório. Sem rede não há NTP, e o histórico leva a hora do relógio provisório, que perde o tempo em que o aparelho ficou desligado (O relógio provisório).
  • Pelo menu, no item 4, Data e hora, a qualquer momento, com a permissão Sistema PERM_SYS_CONFIG no painel, a mesma da rota POST /api/set_time (capítulo 11).

A tela tem cinco colunas, dd / mm / aaaa hh : mm, que começam na data e na hora do relógio em uso. Acima de cada valor há uma seta que soma 1; abaixo, uma seta que subtrai 1. Segurada, a seta repete a cada 300 ms. O dia fica dentro do mês: mudar o mês ou o ano ajusta o dia, e 31/03 menos um mês dá 28/02, ou 29/02 num ano bissexto. O dia, o mês, a hora e o minuto dão a volta; o ano para em 2026 e em 2099. Os segundos ficam em zero.

Botão Na pergunta do boot Pelo menu
Esquerdo PULAR: vai à tela inicial e não muda o relógio SAIR: volta ao menu e não muda o relógio
Direito SALVAR: acerta o relógio e vai à tela inicial SALVAR: acerta o relógio e volta ao menu

Na pergunta do boot, a linha Sem Wi-Fi, os dados levam esta hora. aparece em âmbar acima dos botões. A tela está na figura do capítulo 4.

  • Quem pode salvar. Pelo menu, o aparelho confere a permissão Sistema da conta identificada no painel. A pergunta do boot não pede conta nem PIN: o aparelho aceita SALVAR sem conta enquanto não houver rede configurada nem relógio acertado. O primeiro acerto, por qualquer caminho, encerra essa exceção; depois dele, um SALVAR sem conta toca o som de erro e não muda nada.
  • Ninguém responde. Depois de 30 s sem toque, o painel volta à tela inicial, como em qualquer tela (capítulo 11), e o relógio continua o provisório. Um aparelho que volta de uma falta de energia sem ninguém por perto mostra as leituras, não uma pergunta.
  • A pergunta volta a cada boot. O acerto à mão não sobrevive a um reinício, então um aparelho sem rede pergunta de novo sempre que liga.

No mesmo boot, toda imagem escreve no console Sem rede, relogio provisorio: conf time AAAA-MM-DD HH:MM:SS ou, com o aparelho em inglês, No network, provisional clock: conf time YYYY-MM-DD HH:MM:SS. O Air escreve a linha num boot acordado (M0), não num despertar do ciclo. O comando que a linha cita funciona em todas as imagens (No console); no alpha e no Air, que não têm painel, é o jeito de responder à pergunta.

No console

O console de todas as imagens acerta o relógio, pelo USB ou pelo Bluetooth, com time <AAAA-MM-DD> <HH:MM:SS> na hora local; conf time é o mesmo comando (capítulo 14). No console completo, ele vale no modo EXEC e no privilegiado. O comando confere a data como um calendário: o ano vai de 2026 a 2099, e o dia tem de existir no mês. Uma data que o calendário não tem é recusada, e o relógio não muda:

SIMUT> time 2026-02-31 12:00:00
ERROR: Data ou hora invalida (ano >= 2026)

Até a v2.8.0, o comando existia só no console completo, o do Air e das imagens de teste, e conferia cada campo só pela faixa: aceitava qualquer dia de 1 a 31 e levava 2026-02-31 a 03/03/2026, sem aviso. Um campo fora da faixa respondia Valores fora de range (ano >= 2026).

O relógio provisório

Até o primeiro acerto, o aparelho precisa de uma hora para carimbar as medições. Ele usa um relógio provisório:

  • No boot: o relógio parte do carimbo do registro mais recente do histórico. O log registra Hora provisória do flash (524) com a data e a hora escolhidas.
  • Sem nenhum registro no histórico (aparelho novo ou histórico apagado): o relógio parte de uma data fixa gravada no firmware, 30/07/2026 às 00:00, hora de Brasília.
  • Depois: o relógio provisório anda com o oscilador do próprio aparelho.

O relógio provisório fica atrasado pelo tempo em que o aparelho ficou desligado, mais o intervalo entre o último registro gravado e o desligamento. Para um reinício de poucos segundos, o erro é pequeno. Para uma falta de energia de horas, é de horas, e o primeiro acerto corrige (Quando o primeiro acerto corrige o relógio).

Na cópia em flash do bloco aberto, o arquivo /history/.wip, o aparelho guarda se o relógio que carimbou aquele bloco estava acertado ou era provisório. Os blocos selados nos arquivos do dia não guardam essa marca, e a página de histórico, o CSV e os gráficos não distinguem as duas horas. No boot seguinte, um bloco aberto carimbado com o relógio acertado é aceito como semente. Um carimbado com o relógio provisório só é aceito se o carimbo couber no dia do arquivo dele. Isso impede que um relógio provisório errado semeie o próximo e o erro se acumule de um boot para outro.

release Enquanto o relógio em uso é o provisório, o painel marca a data e a hora da barra de cima com ? e as pinta de âmbar (Onde a hora aparece).

Quando o primeiro acerto corrige o relógio

No primeiro acerto depois de um boot, pelo NTP ou à mão (pela interface web, pelo painel ou pelo console), o aparelho compara a hora certa com a do relógio provisório. Se a diferença passa de 5 s:

  1. Registra NTP corrigindo timestamps (408), com a diferença em segundos. O texto diz NTP também num acerto à mão.
  2. Corrige a hora de cada bloco do histórico que este boot começou, no arquivo do dia e, se um bloco atravessou a meia-noite, no do dia anterior.
  3. Registra Timestamps corrigidos (409), com o número de blocos corrigidos. Um número negativo indica falha, e aparece como aviso.
  4. Registra Caches de gráfico invalidados (410): gráficos e mínimos e máximos são refeitos com as horas corrigidas.

O resultado é um histórico sem buraco e sem salto: as medições feitas antes do acerto aparecem na hora em que realmente aconteceram.

Detalhes:

  • Blocos gravados em sessões anteriores não são tocados: o relógio que os carimbou já tinha sido acertado naquela sessão.
  • O bloco aberto que o boot retomou da sessão anterior, a partir do .wip, é selado antes da correção e não é deslocado, nem nos registros que este boot acrescentou a ele: deslocar só uma parte do bloco poderia desordená-lo. A correção vale para os blocos que este boot começou.
  • Se alguém está usando o painel, a correção espera 5 s sem toques para começar.
  • Se a correção acontece ainda durante o boot, o painel mostra Corrigindo timestamps (NTP)….
  • Só o primeiro acerto depois do boot corrige. Um acerto seguinte, à mão ou pelo NTP, muda o relógio dali em diante e não mexe no que já foi gravado.
  • Até a v2.8.0, o acerto à mão não corrigia o histórico: os registros gravados antes dele ficavam com as horas do relógio provisório, e só o NTP corrigia.

Com o NTP ligado, a telemetria só começa depois do primeiro acerto, porque o aparelho só termina de entrar na rede depois dele (Sem servidor NTP alcançável).

Figura 81. O que o primeiro acerto por NTP faz com as medições gravadas sob o relógio provisório.

Onde a hora aparece

Lugar Formato Fuso
Painel, no topo do painel principal dd/mm/aa - hh:mm:ss; com o relógio provisório, dd/mm/aa ? hh:mm:ss, em âmbar O do aparelho
LCD do alpha O LCD não mostra a hora —
Interface web, cartão Data e Hora do Painel de Controle dd/mm/aaaa hh:mm:ss O do computador (capítulo 13)
Interface web, exportação CSV da página Histórico e Logs ISO 8601 com o deslocamento, como 2026-09-23T14:05:00-03:00 O do computador (capítulo 15)

O painel marca o relógio provisório. Enquanto nem o NTP nem uma pessoa acertaram o relógio desde o boot, o separador entre a data e a hora passa de - a ?, e a data e a hora ficam em âmbar, como 01/10/26 ? 09:58:12. A marca some no primeiro acerto. Até a v2.8.0, o painel mostrava o relógio provisório do mesmo jeito que o acertado.

Se o fuso do computador é diferente do fuso do aparelho, a hora da interface web difere da do painel. Para comparar, use um computador no mesmo fuso do aparelho.

A data e a hora no topo do painel principal, no fuso do aparelho.
Figura 82. A data e a hora no topo do painel principal, no fuso do aparelho.
Figura 83. O relógio provisório no topo do painel: a data e a hora em âmbar, separadas por ?.

O relógio do Air através do sono

air

O Air passa a maior parte do tempo hibernando, e o rádio só liga em alguns despertares (capítulo 19). Nos despertares sem rádio, não há NTP: a hora que o histórico grava é a que o próprio Air reconstrói.

Desde a v2.7.2, o Air carrega o relógio através do sono. Ao dormir, ele guarda o instante em que armou o alarme, com milissegundos. Ao acordar, soma a esse instante a duração do sono, medida pelo relógio de hardware, e o tempo de boot já decorrido, incluindo cerca de 140 ms antes de o firmware começar a contar. A hora sai com erro de cerca de ±0,09 s por despertar (medido em bancada em 23/09/2026). Isso vale também no boot com o carregador conectado.

Na v2.7.1, e quando o sono não trouxe uma hora plausível, o Air reconstrói a hora a partir do registro mais recente mais a duração do sono. Esse método perde o fim do despertar anterior e até cerca de 1 s por despertar, e o erro se acumula até o próximo acerto por NTP.

Nos despertares com rádio, o NTP acerta o relógio e corrige o histórico como em qualquer imagem (Quando o primeiro acerto corrige o relógio).

Voltar ao sumário

Parte III

Usar

Capítulo 11

O painel

release Este capítulo percorre o painel de toque da imagem release, tela por tela: a tela inicial, os gestos, o gráfico, o menu de configurações, as telas de boot e as mensagens. É para quem opera o aparelho na bancada ou no laboratório.

O painel em resumo

O painel é uma tela de 320 × 240 pixels com toque resistivo. Ele mostra as leituras, os alarmes e o histórico sem exigir conta nem PIN. O menu de configurações pede a identificação de quem está no painel (capítulo 8).

Três regras valem para todas as telas:

  • Um toque é uma ação. Quase tudo responde ao encostar do dedo; a exceção é o toque curto no cartão de cima, que age ao soltar, porque o mesmo dedo pode estar começando o gesto de 3 s. Para repetir, levante o dedo e toque de novo. As setas dos rodapés e do gráfico repetem a cada 300 ms enquanto você segura.
  • Um toque pertence à tela onde começou. Se a tela muda com o dedo ainda encostado, o resto do toque é ignorado até você levantar o dedo.
  • Sem toque, o painel volta à tela inicial. Depois de 30 s sem nenhum toque, qualquer tela volta à tela inicial (A volta à tela inicial).

O painel não existe nas imagens alpha, que têm um LCD de 16 × 2 (capítulo 12), nem no Air, que não tem tela (capítulo 19).

A tela inicial

A tela inicial tem quatro faixas, de cima para baixo:

Faixa Altura O que mostra
Barra de cima 29 px SIMUT, data e hora, pendentes da telemetria e sinal do Wi-Fi
Cartão de cima 75 px Um sensor: o fixado, ou o selecionado no modo de seleção
Cartão de baixo 75 px O sensor selecionado na barra de botões
Barra de botões 41 px Um botão por sensor, CFG e, se preciso, o botão de página
Figura 84. A tela inicial: a barra de cima, os dois cartões e a barra de botões com S1, S2 e CFG.

A barra de cima

Da esquerda para a direita:

Elemento O que é
SIMUT O nome do produto, fixo
Data e hora dd/mm/aa - hh:mm:ss, no fuso do aparelho. Com o relógio provisório, dd/mm/aa ? hh:mm:ss, em âmbar (capítulo 10)
Pendentes Quantos registros esperam envio pela telemetria, seguidos de uma seta
Sinal do Wi-Fi Quatro barras, que acendem da esquerda para a direita

Pendentes. A contagem aparece só quando há registros esperando envio. Até 999 ela mostra o número; de 1.000 em diante, os milhares com um k: 1.500 registros aparecem como 1k. O aparelho atualiza a contagem a cada 10 s. A cor diz como foi o último envio:

Cor do número e da seta Significado
Azul O último envio deu certo, ou nenhum envio foi tentado desde que o aparelho ligou
Seta piscando entre azul e branco por 1 s Um envio acabou de dar certo
Vermelho O último envio falhou

A telemetria está no capítulo 21.

Sinal do Wi-Fi. O número de barras acesas segue a intensidade do sinal (RSSI):

Barras acesas RSSI
4 acima de −55 dBm
3 de −65 a −55 dBm
2 de −75 a −65 dBm
1 abaixo de −75 dBm
Nenhuma Sem conexão, ou leitura de sinal impossível

O que substitui a data e a hora. Dois avisos ocupam o lugar do relógio enquanto duram:

  • Silenciado: e os segundos que faltam, como Silenciado: 97s, durante os 120 s de silêncio de um alarme (capítulo 7).
  • Web: e o nome da conta, como Web: admin, por 5 s depois de uma entrada bem-sucedida na interface web. O silêncio tem prioridade sobre esse aviso.
Figura 85. A contagem de pendentes em vermelho: o último envio falhou.
Figura 86. O aviso de entrada pela web, no lugar da data e da hora.

Os cartões

Cada cartão mostra um sensor. O nome dele fica no alto, centralizado; um slot sem nome aparece como Sensor seguido do número do slot. O conteúdo depende do tipo do sensor:

Tipo O cartão mostra
DS18B20 Temperatura, com uma casa decimal, em °C
DHT22 Temperatura e umidade relativa, esta em inteiro com %UR
BME280 Temperatura e pressão, esta em inteiro com hPa
BMP280 Temperatura e pressão

O BME280 mede umidade, mas o cartão mostra a pressão no lugar dela; a umidade dele aparece no gráfico, no detalhe e na interface web. Enquanto não há leitura, o valor aparece como --.-. Um sensor em erro mostra Erro (Error) em letras grandes (capítulo 6).

Mínimo e máximo. Um toque no cartão troca o valor atual pelo mínimo e o máximo do dia: MIN e MAX da temperatura e, no DHT22 e no BME280, também da umidade. No DS18B20 e no BMP280, só da temperatura. À direita aparece o botão de gráfico, com o desenho de três barras, que abre o histórico do sensor (O gráfico). Outro toque fora do botão volta ao valor atual, e o cartão volta sozinho depois de 30 s sem toque.

Os valores de mínimo e máximo vêm do histórico do dia, lido quando o aparelho liga, e das leituras seguintes. Eles não zeram à meia-noite: continuam contando desde o começo do dia em que o aparelho ligou, até o próximo reinício.

O cartão de baixo em mínimo e máximo: temperatura e umidade, e o botão de gráfico à direita.
Figura 87. O cartão de baixo em mínimo e máximo: temperatura e umidade, e o botão de gráfico à direita.

O cartão de cima: fixado ou em seleção. O cartão de cima tem dois modos:

  • Fixado: mostra sempre o mesmo sensor, que some da barra de botões para não aparecer duas vezes. De fábrica, o cartão de cima fica fixado no slot 0.
  • Em seleção: fica cinza, com texto e borda brancos, e mostra o mesmo sensor do cartão de baixo. Serve para escolher qual sensor fixar.

Para fixar outro sensor:

  1. Segure o dedo no cartão de cima por 3 s. O painel toca o som de toque e o cartão fica cinza.
  2. Toque no botão do sensor na barra de botões.
  3. Segure o dedo no cartão de cima por 3 s de novo. O cartão volta à cor normal com o sensor escolhido, e o cartão de baixo passa para outro sensor.

Depois do gesto de 3 s, o cartão de cima ignora toques por 600 ms, enquanto o dedo sobe. O aparelho grava o sensor fixado e o selecionado alguns segundos depois da mudança, e os dois voltam depois de um reinício.

Figura 88. O cartão de cima em seleção: cinza, espelhando o sensor do cartão de baixo.

Cartões em alarme. Um sensor em alarme pisca: em vermelho para limite e em âmbar para falha, com a borda alternando. Tocar no cartão que pisca abre a tela de alarme em vez do mínimo e máximo (A tela de alarme). Durante o silêncio de 120 s, os cartões param de piscar e o toque volta ao normal. Com dois ou mais sensores em alarme, o cartão de baixo passa de um para outro a cada 3 s, sem contar o sensor fixado no cartão de cima; essa rotação percorre os slots de 0 a 9. As figuras estão no capítulo 7.

A barra de botões

A barra de botões tem até cinco posições, da esquerda para a direita:

Botão O que faz
S e o número do slot, como S1 Seleciona o sensor para o cartão de baixo. O selecionado fica na cor de destaque
CFG Abre as configurações: primeiro a escolha da conta, depois o PIN (capítulo 8)
Página, como 1/2 Aparece quando os botões não cabem numa linha; mostra a próxima página

Um sensor ativo ganha um botão, menos o fixado no cartão de cima. CFG vem logo depois do último sensor, então a posição dele muda com o número de sensores. Com mais de cinco botões, a barra se divide em páginas de quatro, e o botão de página fica sempre na quinta posição, à direita.

Nos alarmes, o botão do sensor pisca junto com o cartão. Se um sensor em alarme está noutra página, o botão de página pisca em vermelho; durante o silêncio, ele fica parado, com a borda vermelha.

Figura 89. A barra de botões com páginas: quatro botões e o botão de página à direita.

Quando a web ocupa o aparelho

Algumas operações da interface web leem a memória por vários segundos: os gráficos do histórico, a exportação em CSV, a leitura e a exportação do log de eventos. Enquanto uma delas corre, a barra de cima mostra, em âmbar, WEB ' e o nome da conta, seguidos de ' - toque bloqueado, e a tela inicial ignora os toques. As leituras continuam atualizando. O aviso some sozinho, até um segundo depois de a operação terminar.

O texto desse aviso está sempre em português, seja qual for o idioma do painel.

Figura 90. O aviso de web ocupada: WEB ‘admin’ - toque bloqueado.

Gestos e navegação

Na tela inicial:

Onde Gesto Resultado
Cartão de cima Toque Mínimo e máximo, ou volta ao valor
Cartão de cima Segurar 3 s Fixa o sensor selecionado, ou entra em seleção
Cartão de cima ou de baixo, em mínimo e máximo Toque no botão de gráfico Abre o gráfico do sensor, em 1H
Cartão de baixo Toque Mínimo e máximo, ou volta ao valor
Cartão em alarme, sem silêncio Toque Abre a tela de alarme do sensor
Botão S Toque Seleciona o sensor
CFG Toque Abre a escolha da conta
Botão de página Toque Mostra a próxima página de botões

O toque curto no cartão de cima vale no cartão inteiro e nos dois modos. Enquanto o sensor do cartão de cima está em alarme sem silêncio, o toque abre a tela de alarme e o gesto de 3 s não começa.

O botão de gráfico abre o histórico dos slots 0 a 10. Nos slots 11 a 15, ele só volta o cartão ao valor atual.

Nas outras telas, a navegação segue o mesmo padrão:

  • Listas (menu, temas, idiomas): toque numa linha para selecioná-la. As setas do rodapé movem a seleção e dão a volta no fim da lista.
  • Rodapé padrão: seta para cima, seta para baixo, SAIR e o botão de ação à direita (ENTRAR, APLICAR ou SALVAR).
  • Telas de consulta (gráfico, detalhe, calendário): o X no canto de cima, à direita, fecha.

O gráfico

O gráfico mostra o histórico de um sensor numa janela de tempo. Para abri-lo, ponha o cartão em mínimo e máximo e toque no botão de gráfico. Ele abre na janela de 1 hora que termina agora.

Ao abrir, o painel mostra Carregando… (Loading…) enquanto lê o histórico. Dentro do gráfico, trocar de janela não apaga a tela: uma linha fina na cor de destaque, no alto, avisa que a leitura está em curso, e o gráfico novo substitui o antigo.

Figura 91. A tela Carregando…, ao abrir um gráfico.
O gráfico de 24H de um DHT22: faixa de mínimo e máximo, linha de temperatura, curva de umidade e marcadores.
Figura 92. O gráfico de 24H de um DHT22: faixa de mínimo e máximo, linha de temperatura, curva de umidade e marcadores.

O cabeçalho

Elemento O que mostra
Etiqueta à esquerda A janela: 1H, 6H, 12H, 24H ou 7D
Centro O começo e o fim da janela, como 23/09/26 14:00 - 15:00, ou 22/09/26 15:00 - 23/09 15:00 quando a janela atravessa a meia-noite
X, à direita Fecha o gráfico e volta à tela inicial

Um toque no centro do cabeçalho mostra o nome do sensor por 3 s. Sem dados na janela, o texto do centro fica apagado.

A área do gráfico

O aparelho divide a janela em intervalos iguais de tempo, até 200 por janela e nunca menos de 40. Com o histórico gravado a cada minuto, a janela de 1H tem 60 intervalos. Em cada intervalo, ele calcula a média, o mínimo e o máximo das leituras. Na tela:

  • Faixa sombreada: vai do mínimo ao máximo de cada intervalo. É a variação real da temperatura dentro dele.
  • Linha grossa: a média da temperatura.
  • Linha fina: a segunda grandeza, com a escala à direita. É a umidade, no DHT22 e no BME280, ou a pressão, no BMP280.
  • Lacunas: um intervalo sem leitura fica em branco, com a largura real do tempo sem dados. Uma leitura isolada entre duas lacunas aparece como um ponto.
  • Losangos: um marca o máximo da janela, no alto da faixa, e outro o mínimo, embaixo.
  • Círculo no fim: o último valor da temperatura.
  • Eixo da esquerda: o máximo, no alto, e o mínimo, embaixo.
  • Eixo de baixo: três horários (começo, meio e fim) em hh:mm, ou datas em dd/mm na janela de 7D.

Sem nenhuma leitura na janela, o centro mostra Sem Dados (No Data).

A barra de botões do gráfico

Posição Botão O que faz
1 Setas duplas para a esquerda Recua uma janela inteira no tempo
2 Setas duplas para a direita Avança uma janela; apagado quando a janela já termina agora
3 Calendário Abre o calendário (O calendário)
4 Lupa com + e a janela seguinte Encurta a janela: 7D, 24H, 12H, 6H, 1H. Apagado em 1H
5 Lupa com − e a janela seguinte Alonga a janela. Apagado em 7D

Os botões de lupa mostram a janela para onde levam: em 24H, a lupa de + mostra 12H e a de − mostra 7D. As setas e as lupas repetem se você segurar. O aparelho não mostra o futuro: avançar para além de agora para no agora.

Um toque na área do gráfico abre o detalhe numérico.

O detalhe numérico

O detalhe mostra os números da mesma janela do gráfico, uma grandeza por página. O cabeçalho e a barra de botões são os do gráfico, e funcionam do mesmo jeito.

Cada página tem um título com a grandeza e a unidade, como Temperatura (°C), e quatro linhas:

Linha Valor À direita
MAX O máximo da janela Data e hora do máximo, em dd/mm/aa hh:mm
MIN O mínimo da janela Data e hora do mínimo
MÉDIA (AVG) A média da janela A diferença entre o último e o primeiro valor da janela, com sinal, como +0.3; 0.0 quando é menor que 0,05
DESVIO (STD DEV) O desvio padrão, com duas casas n= e o número de leituras

As páginas são temperatura, umidade (DHT22 e BME280) e pressão (BME280 e BMP280). Pontos no título mostram em qual página você está. Um toque no centro passa para a próxima página; na última, volta ao gráfico. A umidade aparece em inteiros.

Figura 93. O detalhe numérico, página de temperatura: máximo, mínimo, média e desvio.
Figura 94. A página de umidade do detalhe.
Figura 95. A página de pressão do detalhe.

O calendário

O calendário mostra um mês e marca os dias que têm histórico. Abra pelo terceiro botão da barra do gráfico.

  • Título: o mês abreviado e o ano, como Set 2026.
  • Grade: as colunas D S T Q Q S S, de domingo a sábado.
  • Dia com histórico: número normal com um ponto embaixo.
  • Dia sem histórico: número apagado; tocar nele não faz nada.
  • Hoje: número sobre um fundo na cor de destaque.

Toque num dia com histórico para abrir o gráfico daquele dia, em 24H, da meia-noite à meia-noite. O rodapé tem < Mês, Hoje e Mês >. Hoje volta ao gráfico, na janela que estava aberta. O X do título volta ao gráfico.

O calendário está sempre em português, seja qual for o idioma do painel.

O calendário: os dias com histórico têm um ponto, e o dia de hoje fica destacado.
Figura 96. O calendário: os dias com histórico têm um ponto, e o dia de hoje fica destacado.

O menu de configurações

Para entrar, toque em CFG, escolha a sua conta e digite o PIN (capítulo 8). O menu abre com o título Configurações > seguido do nome da conta e lista só os itens que as permissões dela alcançam.

O menu tem até 13 itens, quatro por página, com uma barra de rolagem à direita. Toque num item para selecioná-lo, ou mova a seleção com as setas do rodapé, e toque em ENTRAR. SAIR volta à tela inicial.

Os itens seguem a frequência de uso. No menu completo, cada página é um grupo: a primeira tem o que se usa no dia a dia (alarmes, sons, status e relógio); a segunda, o acesso (o próprio PIN, as contas, a política de PIN e o AP de configuração); a terceira, os ajustes da tela, feitos uma vez; a quarta, a licença. Até a v2.9.0, os itens seguiam a ordem em que foram criados, de Temas Visuais (1) a Data e hora (13).

Quando a conta vê os 13 itens, eles aparecem numerados, de 1. a 13.. Com o menu filtrado, os números somem, para a lista não começar por um número salteado.

Nº Item Permissão O que abre
1 Limites de Alarme (Alarm Limits) Uma das três de painel Alarmes
2 Sons de Alarme (Alarm Sounds) Sistema PERM_SYS_CONFIG Sons
3 Status do Sistema (System Status) Nenhuma Status
4 Data e hora (Date and time) Sistema Data e hora
5 Alterar Senha (Change Password) Nenhuma O próprio PIN (capítulo 8)
6 Usuários (Users) Usuários PERM_USER_MGR Usuários
7 Segurança do PIN (PIN security) Usuários A política de PIN (capítulo 8)
8 Modo de Configuração (Configuration Mode) Rede PERM_NET_CONFIG O AP de configuração
9 Idioma do Sistema (System Language) Sistema Idioma
10 Temas Visuais (Visual Themes) Sistema Temas
11 Calibrar Touch (Touch Calibration) Sistema Calibração do toque
12 Alinhamento da Tela (Display Alignment) Sistema Alinhamento
13 Licença (License) Nenhuma Licença

As três permissões de painel do item 1 são Limites (painel) PERM_ALARM_LIMITS, Bloqueio (painel) PERM_ALARM_BLOCK e Manut. (painel) PERM_MAINT. O aparelho confere a permissão de novo quando recebe o pedido do painel: esconder o item é só conforto.

O menu completo, primeira página: Limites de Alarme, Sons de Alarme, Status do Sistema e Data e hora, numerados de 1 a 4.
Figura 97. O menu completo, primeira página: Limites de Alarme, Sons de Alarme, Status do Sistema e Data e hora, numerados de 1 a 4.
A segunda página do menu completo, com Alterar Senha, Usuários, Segurança do PIN e Modo de Configuração.
Figura 98. A segunda página do menu completo, com Alterar Senha, Usuários, Segurança do PIN e Modo de Configuração.
A terceira página do menu completo, com Idioma do Sistema, Temas Visuais, Calibrar Touch e Alinhamento da Tela.
Figura 99. A terceira página do menu completo, com Idioma do Sistema, Temas Visuais, Calibrar Touch e Alinhamento da Tela.
A quarta página do menu completo, só com Licença.
Figura 100. A quarta página do menu completo, só com Licença.

O menu filtrado de uma conta só com permissões de painel está na figura do capítulo 8.

Limites de Alarme

O item abre a lista de sensores, com o estado dos alarmes de cada um. Da lista, um sensor abre o menu dele, com três linhas: Limites de alarme, Alarmes e Manutenção. Cada linha exige a sua permissão de painel.

Tudo isso, com as telas e as figuras, está no capítulo 7: a lista, o menu do sensor, o editor de limites e a janela de manutenção.

Sons de Alarme

A tela Config. de Sons (Sound Settings) tem nove linhas em três páginas: os dois volumes, os sons de toque, confirmação, erro, alarme e atenção, os sons da web e o Mudo Global. A escolha de melodia e a confirmação do Mudo Global são telas próprias. Tudo está no capítulo 7.

Status do Sistema

A tela Status do Sistema (System Status) mostra o estado do aparelho em quatro páginas, atualizadas a cada segundo. As setas do rodapé trocam a página e SAIR volta ao menu. Os rótulos das linhas estão em inglês.

Página Linha O que mostra
1 Device O nome do aparelho
1 Firmware A versão
1 Serial O número de série da placa, em 16 dígitos hexadecimais
1 Uptime Tempo desde o último reinício, em Nd hh:mm:ss
1 Heap Free Memória livre, em bytes; vermelho abaixo de 20.000
1 Flash Used Bytes ocupados no sistema de arquivos
1 Board Temp Temperatura do chip, em °C
1 Timezone O fuso, como GMT-3
2 WiFi Connected em verde ou Disconnected em vermelho
2 SSID A rede configurada
2 IP e MAC Os endereços do aparelho
2 RSSI O sinal, em dBm: verde acima de −60, na cor de destaque até −80, vermelho abaixo
2 NTP Synced em verde ou Not synced em vermelho
2 NTP Server O servidor de hora configurado
3 Active Quantos slots estão ativos
4 Transport HTTP ou MQTT
4 Server O coletor da telemetria
4 Pending Registros esperando envio; vermelho acima de 50
4 Fails Sempre 0 na v2.7.1: o aparelho não preenche esse campo
4 Min batch O lote mínimo da telemetria, como 10 rec, ou off
4 MQTT Só com transporte MQTT: Connected ou Disconnected

O número de série é a chave da linha do sensor no arquivo calib.csv para sensores sem ROM (capítulo 6).

Status do Sistema, página 1: o aparelho.
Figura 101. Status do Sistema, página 1: o aparelho.
Status do Sistema, página 2: rede e hora.
Figura 102. Status do Sistema, página 2: rede e hora.
Status do Sistema, página 3: sensores.
Figura 103. Status do Sistema, página 3: sensores.
Status do Sistema, página 4: telemetria.
Figura 104. Status do Sistema, página 4: telemetria.

Data e hora

O item Data e hora acerta o relógio do aparelho, com a permissão Sistema no painel. Ele abre a mesma tela que um aparelho sem rede configurada mostra no fim do boot (capítulo 10):

  • cinco colunas, dd / mm / aaaa hh : mm, que começam na data e na hora do relógio em uso;
  • uma seta acima de cada valor, que soma 1, e uma abaixo, que subtrai 1; segurada, a seta repete a cada 300 ms;
  • SAIR, que volta ao menu sem mudar o relógio, e SALVAR, que acerta o relógio e volta ao menu.

O dia fica dentro do mês, e o ano vai de 2026 a 2099. Os segundos ficam em zero. O aparelho confere a permissão Sistema quando recebe o SALVAR, e o log registra o código 13, RTC set manually, com o contexto 3. O primeiro acerto depois do boot corrige a hora dos blocos do histórico que o boot começou (capítulo 10).

Na pergunta do boot, o botão da esquerda é PULAR, que vai à tela inicial, e uma linha em âmbar diz Sem Wi-Fi, os dados levam esta hora. A figura dessa tela está no capítulo 4.

Usuários e Segurança do PIN

O item Usuários abre a lista de contas do painel, com NOVO para criar uma conta e o editor de cada conta: as três permissões de painel, Definir PIN e Excluir usuário. O nome de uma conta nova se digita no teclado de texto, que tem as letras em oito grupos (abc a wxyz), uma tecla de algarismos, uma de símbolos, espaço e apagar; tocar num grupo abre as letras dele em minúsculas e maiúsculas.

O item Segurança do PIN define o tamanho mínimo, o teclado e os caracteres do PIN.

Tudo isso está no capítulo 8 e na política de PIN.

O teclado de texto com o grupo pqrs aberto, em minúsculas e maiúsculas.
Figura 105. O teclado de texto com o grupo pqrs aberto, em minúsculas e maiúsculas.

Modo de Configuração

O item Modo de Configuração abre o ponto de acesso de configuração com o aparelho em operação. Use para pôr na rede um aparelho novo ou para trocar a rede Wi-Fi: o AP não abre sozinho (capítulo 9).

  1. Toque em Modo de Configuração e em ENTRAR.
  2. A tela de confirmação diz: O aparelho sai da rede e abre a rede de setup. Tem certeza?
  3. Toque em Confirmar para abrir o AP, ou em SAIR para voltar ao menu.

O aparelho confere a permissão Rede antes de abrir o AP e registra no log o código 403, AP iniciado, com o contexto 0.

Depois de Confirmar, o painel passa ao terminal da tela de boot, com Iniciando Ponto de Acesso (AP)…, e em poucos segundos mostra o que é preciso para entrar no AP: o nome da rede (o nome do aparelho seguido de _SETUP), a chave, numa linha que começa com PSK, Acesse no celular: 192.168.4.1 e AP Ativo! Reinicie a placa para sair. O comando ap do console também responde com a chave (capítulo 14). Se o AP não abrir, o painel mostra Erro e o aparelho continua medindo.

A confirmação do Modo de Configuração.
Figura 106. A confirmação do Modo de Configuração.

Idioma do Sistema

A tela Configurações > Idioma (Settings > Language) tem até duas linhas:

Linha Código Quando aparece
English EN Sempre
O nome do pacote de idioma instalado, como Portugues O código do pacote, como pt-BR Só com um pacote .lng carregado
  1. Toque no idioma.
  2. Toque em APLICAR.

O painel toca o som de confirmação e volta à tela inicial no idioma novo. O aparelho grava na hora, e o log registra o código 441, Idioma alterado via UI. O console serial passa a usar o mesmo idioma a partir do próximo reinício. De fábrica, o idioma é o do pacote; sem pacote carregado, o painel fica em inglês.

Algumas telas não seguem o idioma escolhido: o aviso de web ocupada, o calendário e o LCD do alpha estão sempre em português, e as linhas da tela Status do Sistema estão sempre em inglês.

A escolha de idioma: English e o pacote instalado.
Figura 107. A escolha de idioma: English e o pacote instalado.

Temas Visuais

A tela Configurações > Temas (Settings > Themes) lista os temas instalados, quatro por página. Cada linha tem o nome do tema e três amostras de cor: o fundo, o cartão e o destaque. O tema de fábrica é o Simut Default; os outros vêm de arquivos .thm na pasta /themes do aparelho.

  1. Toque no tema, ou mova a seleção com as setas.
  2. Toque em APLICAR.

O painel mostra Aplicando Tema… e volta à tela inicial com as cores novas. O aparelho grava na hora, sem reiniciar, e o log registra o código 440, Tema alterado via UI. SAIR volta ao menu sem mudar nada.

O tema do painel também muda pela interface web (capítulo 13).

A escolha de tema, com as amostras de cor de cada um.
Figura 108. A escolha de tema, com as amostras de cor de cada um.

Calibrar Touch

A calibração acerta o toque em duas etapas seguidas: primeiro a pressão, depois a posição. Faça com o dedo ou com a caneta que vai usar no dia a dia.

Etapa 1, sensibilidade. A tela Sensibilidade do Toque (Touch Sensitivity) mostra uma mira no centro, a frase Toque na mira (Touch the crosshair), uma barra vertical à direita e, embaixo dela, o limite de pressão encontrado.

  1. Encoste o dedo na mira e mantenha, com pressão leve e constante.
  2. Espere a barra encher. Ela sobe enquanto a pressão fica estável e desce devagar quando oscila. Com pressão estável, enche em cerca de 2 s.

Quando a barra enche, a mira fica verde e a tela mostra Calibração Concluída!. O aparelho grava o limite de pressão (código 444, Sensibilidade do touch salva) e, 1,5 s depois, passa sozinho à etapa 2. CANCELAR, embaixo à esquerda, volta ao menu.

Etapa 2, posição. A tela Calibração do Touch (Touch Calibration) mostra uma mira por vez, nos quatro cantos: em cima à esquerda, em cima à direita, embaixo à esquerda e embaixo à direita. A frase diz qual é a mira, como Toque na mira (1/4), e [ 1 / 2 ] diz a volta.

  1. Segure o dedo na mira até ela ficar verde, cerca de 0,4 s.
  2. Solte. A próxima mira aparece.
  3. Repita nos quatro cantos, duas voltas: oito toques.

O aparelho compara as duas voltas. Se algum canto diferir demais entre elas, a tela mostra Toques imprecisos! Tente novamente.; ENTENDI recomeça as oito miras. Se as voltas concordarem, a tela mostra Calibração Concluída!, o aparelho grava na hora (código 443, Calibração do touch salva) e ENTENDI volta ao menu. A etapa 2 não tem botão para cancelar.

A calibração também começa pela interface web, pela página Configurações (capítulo 5), e pelo console. Esse caminho existe porque um toque descalibrado pode não alcançar o menu.

A etapa de sensibilidade: a mira, a barra de estabilidade e o limite de pressão.
Figura 109. A etapa de sensibilidade: a mira, a barra de estabilidade e o limite de pressão.
Figura 110. A etapa de posição: a primeira mira, Toque na mira (1/4) e a volta [ 1 / 2 ].
Figura 111. O fim de uma calibração aceita: Calibração Concluída! e ENTENDI.
Figura 112. Uma calibração recusada: Toques imprecisos! Tente novamente.

Alinhamento da Tela

Alguns painéis mostram a imagem deslocada alguns pixels, cortando a borda de um lado. A tela Alinhamento da Tela (Display Alignment) move a imagem inteira até 4 px em cada direção.

Controle O que faz
Setas para cima e para baixo Movem a imagem 1 px na vertical, de −4 a +4
Setas para a esquerda e para a direita Movem 1 px na horizontal, de −4 a +4
Quadrado no centro Volta a X +0 e Y +0
SAIR Volta ao menu e desfaz o que não foi aplicado
APLICAR Grava o deslocamento

A imagem se move enquanto você ajusta, e os valores aparecem à direita, como X +2 e Y -1. Ao tocar em APLICAR, o aparelho grava, descarta a calibração do toque, porque ela dependia da posição antiga da imagem, e abre a calibração do toque na hora. Faça a calibração até o fim.

Figura 113. O alinhamento da tela, com as quatro setas, o quadrado de zerar e os valores X e Y.

Licença

A tela Licença MIT (MIT License) tem as mesmas três partes da página Licença da interface web (capítulo 13), na mesma ordem: uma explicação no idioma do pacote instalado (as mesmas frases da página), o texto da licença MIT em inglês, porque é a versão original e a que tem valor legal, e a lista de todo o software de terceiros das imagens, com o titular e a licença de cada um. São 17 linhas por página e sete páginas. Acentos aparecem sem o sinal (licença vira licenca), porque a tela usa a fonte de 5×7 pontos. Pontos no título mostram a página. Um toque na metade de cima do texto volta uma página; na metade de baixo, avança. O rodapé tem seta para cima, seta para baixo e SAIR, que volta ao menu.

A primeira página da licença.
Figura 114. A primeira página da licença.

A tela de alarme

Um toque no cartão de um sensor em alarme, sem silêncio, abre a tela de alarme daquele sensor. O título, sobre fundo de alarme, é ! seguido do nome do sensor, ou ! Slot e o número quando o slot não tem nome. Os três botões:

Botão O que faz
Silenciar 120s Cala a cigarra e a piscada de todos os alarmes por 120 s, e volta à tela inicial
Desativar Pede a conta e o PIN; desliga o alarme daquele sensor
Min/Max Volta à tela inicial com o cartão em mínimo e máximo

A tela não tem SAIR: para voltar sem agir, toque em Min/Max ou espere 30 s. O que cada botão faz, o registro no log e a permissão de Desativar estão no capítulo 7, com a figura da tela.

A confirmação do Mudo Global, que parte da tela de sons, está no capítulo 7, com a figura.

As mensagens do painel

Depois de uma ação que o aparelho precisa validar, o painel mostra o resultado numa tela própria: um visto verde para sucesso ou um X âmbar para recusa, a mensagem e o botão ENTENDI, que volta à tela de onde a ação partiu. Na recusa, o painel toca o som de erro.

Mensagem Tipo Quando
PIN salvo! Sucesso O próprio PIN ou o PIN de outra conta foi gravado
Usuário salvo! Sucesso Uma conta foi criada ou alterada no painel
Usuário excluído Sucesso Uma conta foi excluída
Sem permissão Recusa A conta identificada não tem a permissão da ação
PIN inválido! Recusa O PIN não segue a política
PIN já em uso! Recusa Outra conta já tem esse PIN
Nome inválido ou repetido Recusa O nome de uma conta nova não serve
Sem vaga para conta nova Recusa As 32 contas estão ocupadas

As causas e o que fazer estão no capítulo 8 e em Usuários no painel. As telas de calibração do toque têm mensagens próprias, no mesmo formato (Calibrar Touch).

Figura 115. Uma mensagem de sucesso: PIN salvo! e ENTENDI.

A figura de uma recusa está no capítulo 8.

A tela de atualização

Uma atualização de firmware pela web (capítulo 17) toma o painel desde o primeiro byte da imagem, de qualquer tela em que ele esteja, e mostra cada etapa sob o título Atualização de firmware:

Etapa O que a tela diz Quanto dura
Recebendo Recebendo a nova versão, a barra e a porcentagem Cerca de 30 s para uma imagem de 1 MB
Conferindo Conferindo a assinatura e a barra cheia Cerca de 2 s
Conferida Imagem conferida e a barra cheia Cerca de 2 s: a página pede a instalação logo em seguida, e a assinatura é conferida de novo
Instalando Instalando a nova versão e O aparelho reinicia sozinho em cerca de 30 s Cerca de 25 s de cópia e o reinício
Recusada Atualização recusada, o motivo e Continua na versão atual 12 s, ou até um toque
Interrompida Atualização interrompida e Continua na versão atual 8 s, ou até um toque

Da recepção à instalação, a linha de baixo diz, em âmbar, Não desligue o aparelho, e a tela não sai por toque nem pelos 30 s sem toque: um dedo no vidro não muda nada. A porcentagem para em 99 %: a contagem inclui os separadores do envio, e o fim de verdade só se sabe na conferência. Uma recusa ou uma interrupção sai sozinha para a tela inicial, ou antes, com um toque em qualquer ponto.

Os motivos de uma recusa são os da página Arquivos (capítulo 17), pelo código v da resposta:

v Motivo na tela
7 A imagem é de outro modelo
8 A imagem não é assinada
9 A assinatura não confere
10 Assinada com uma chave aposentada
11 Abaixo do nível de segurança instalado
12 Assinada com a chave de bancada
1 a 6, ou um arquivo maior que o espaço da imagem Não é uma imagem de firmware válida

A conferência roda de novo quando a página pede a instalação; se a imagem guardada não confere mais, a tela mostra a recusa com o motivo, e a instalação não começa. Interrompida aparece quando o envio para no meio, quando a gravação na memória falha ou quando a instalação não chega a começar. Nos dois casos o aparelho segue na versão que tinha.

Depois da instalação, quando a imagem gravada confere com a recebida, a caixa do boot mostra Update installed: e a versão nova, em inglês: o envio da imagem apaga o pacote de idioma junto com os outros arquivos (O que sobrevive e o que se perde).

O envio da imagem: a barra, a porcentagem e o aviso para não desligar.
Figura 116. O envio da imagem: a barra, a porcentagem e o aviso para não desligar.
A cópia da imagem: a tela fica assim até o aparelho reiniciar.
Figura 117. A cópia da imagem: a tela fica assim até o aparelho reiniciar.
Uma recusa: o motivo e a versão que fica.
Figura 118. Uma recusa: o motivo e a versão que fica.
Um envio cortado no meio: nada mudou no aparelho.
Figura 119. Um envio cortado no meio: nada mudou no aparelho.

As telas de boot

Ao ligar, o painel mostra SIMUT em letras grandes, a versão e uma caixa com > system_init( ) e as cinco últimas etapas do boot, em letras pequenas e sem acentos. Cada etapa nova empurra as antigas para cima. As etapas, na ordem:

Etapa Quando aparece
Montando Sistema de Arquivos… Sempre, primeiro
Mantenha a tela pressionada: Modo AP… Sempre; abre a janela do gesto do AP (O gesto do AP no boot)
Iniciando Gerenciador de Log…, Iniciando Interface de Comando…, Carregando Tema & Idioma…, Carregando Periféricos & Sensores… Sempre
Update installed: e a versão Na primeira partida depois de uma atualização pela web, entre Iniciando Gerenciador de Log… e Iniciando Interface de Comando…; em inglês (A tela de atualização)
Iniciando Ponto de Acesso (AP)… e as linhas do AP Só quando o gesto abre o AP no boot
Iniciando Interface Wi-Fi… Quando o aparelho não abre o AP
Aguardando roteador e pontos Até entrar na rede, com o botão PULAR; só com rede configurada
Sincronizando Relógio Global e pontos Até acertar o relógio, com o botão PULAR
Rede Conectada & Sincronizada! Rede e hora prontas
Conexão Ignorada pelo Usuário. Depois de PULAR; sem rede configurada, logo, sem esperar o roteador
Timeout de rede. Iniciando Offline… Depois de 30 s sem rede ou sem hora
Iniciando Servidor de Telemetria…, Iniciando Servidor Web…, Registrando Callbacks… Sempre
Carregando cache diário Min/Max…, Aquecendo sensores… Quando o aparelho não abre o AP
Corrigindo timestamps (NTP)…, Recarregando cache Min/Max… Quando o relógio foi acertado durante o boot
Preparando dados do painel…, Todos os subsistemas iniciados. Sempre, no fim
Sistema Pronto! Entrando no Painel. 0,8 s antes da tela inicial

PULAR (SKIP) aparece enquanto o aparelho espera o roteador ou o relógio. Um toque nele segue o boot sem rede; o aparelho continua tentando a rede depois (capítulo 9).

Num aparelho sem rede configurada e com o relógio provisório, o boot não termina na tela inicial: logo depois da última etapa, o painel abre a tela Data e hora, com PULAR e SALVAR (Data e hora).

Figura 120. A tela de boot com as últimas etapas e o botão PULAR.

O gesto do AP no boot

O gesto abre o AP de configuração no boot, para quando o aparelho não consegue entrar na rede e você não tem outro acesso.

  1. Ligue o aparelho.
  2. Espere aparecer Mantenha a tela pressionada: Modo AP…. A janela do gesto só abre depois que essa linha está na tela.
  3. Em até 3,5 s, encoste o dedo na tela e mantenha.
  4. A tela passa a Modo de Configuração com uma barra de progresso. Mantenha o dedo até a barra encher, 3 s.

Se você levantar o dedo antes, a tela mostra Modo AP Cancelado. e o boot segue normal. Um dedo encostado desde antes de ligar também vale: a janela o encontra no primeiro instante.

Com o AP aberto pelo gesto, a caixa mostra Iniciando Ponto de Acesso (AP)…, Conecte à rede SIMUT_SETUP seguido de PSK e a chave, Acesse no celular: 192.168.4.1 e, no fim, o nome real da rede, PSK com a chave e AP Ativo! Reinicie a placa para sair. O log registra o código 403 com o contexto 1. O gesto é o único jeito de abrir o AP no boot: um aparelho sem rede configurada não o abre sozinho. Da v2.7.1 à v2.8.0, abria, e o log registrava o contexto 2.

Figura 121. O convite do gesto do AP no boot.
Figura 122. O gesto em curso: Modo de Configuração e a barra enchendo.
Figura 123. O gesto cancelado: Modo AP Cancelado.
Figura 124. O boot no AP: o nome da rede, a chave e AP Ativo!.

A volta à tela inicial

Depois de 30 s sem nenhum toque, qualquer tela volta à tela inicial, inclusive o menu, o gráfico, a tela de alarme e a tela Data e hora, também quando o boot a abriu. No mesmo prazo, um cartão em mínimo e máximo volta ao valor atual. As telas de boot não contam, nem a de atualização, que fica enquanto a atualização corre e tem prazos próprios (A tela de atualização).

Uma alteração ainda não aplicada numa tela de lista, como um tema selecionado sem APLICAR, se perde na volta. O que já foi gravado continua gravado. Para voltar ao menu depois disso, toque em CFG e se identifique de novo.

Referência das telas

As 31 telas do painel, com o modo interno que o console e as ferramentas usam, o título em português, como chegar e a figura. A coluna Tag é o argumento do comando screen do console completo (capítulo 14), que existe só nas imagens de teste; screen entra como administrador.

Modo Título na tela Como chegar Tag Figura
MODE_DASHBOARD Sem título: barra de cima Ao fim do boot; SAIR do menu; 30 s sem toque dash 11-principal
MODE_GRAPH_LOADING Carregando… Ao abrir um gráfico — 11-carregando
MODE_GRAPH_VIEW A janela e o período Cartão em mínimo e máximo, botão de gráfico gra 11-grafico
MODE_GRAPH_DETAIL A janela e o período Toque na área do gráfico — 11-detalhe-temp
MODE_AUTH Autenticação de Segurança, Novo PIN ou Confirme o PIN Escolha da conta; Alterar Senha; Definir PIN — 08-teclado-3
MODE_SETTINGS_MAIN Configurações > e a conta PIN certo depois de CFG set 11-menu
MODE_SETTINGS_THEMES Configurações > Temas Menu, item 10 thm 11-temas
MODE_SETTINGS_ALARMS Limites de Alarme Menu, item 1 alm 07-lista-sensores
MODE_SETTINGS_ALARM_EDIT O nome do sensor Menu do sensor, Limites de alarme — 07-editor-limites
MODE_SETTINGS_LANG Configurações > Idioma Menu, item 9 lng 11-idioma
MODE_SETTINGS_PASSWORD Nome do usuário Usuários, NOVO; screen pwd abre a variante antiga, Nova Senha pwd 08-novo-nome
MODE_SETTINGS_TOUCH_CAL Calibração do Touch Fim da etapa de sensibilidade — 11-mira
MODE_SETTINGS_TOUCH_SENS Sensibilidade do Toque Menu, item 11; APLICAR do alinhamento touchsens, touchcal 11-sensibilidade
MODE_SETTINGS_SOUNDS Config. de Sons Menu, item 2 — 07-sons-painel
MODE_SETTINGS_LICENSE Licença MIT Menu, item 13 lic 11-licenca
MODE_SETTINGS_STATUS Status do Sistema Menu, item 3 sts 11-status-1
MODE_SETTINGS_DISPLAY_OFFSET Alinhamento da Tela Menu, item 12 offset 11-alinhamento
MODE_ALARM_ACTION ! e o nome do sensor Toque no cartão em alarme — 07-tela-alarme
MODE_CALENDAR O mês e o ano Terceiro botão do gráfico — 11-calendario
MODE_CONFIRM_MUTE_ALL Mudo Global Config. de Sons, Mudo Global desligado — 07-mudo-confirmar
MODE_SETTINGS_ALARM_SENSOR O nome do sensor Limites de Alarme, sensor — 07-menu-sensor
MODE_SETTINGS_MAINT Manutenção Menu do sensor, Manutenção — 07-manutencao-entrada
MODE_SETTINGS_USERS Usuários Menu, item 6 usr 08-usuarios-lista
MODE_SETTINGS_USER_EDIT O nome da conta Usuários, conta; ou o nome de uma conta nova — 08-novo-permissoes
MODE_SETTINGS_USER_CONFIRM_DEL Excluir usuário Editor da conta, Excluir usuário — 08-excluir
MODE_PANEL_MESSAGE Sem título: ícone e mensagem Resultado de uma ação — 11-mensagem-ok
MODE_AUTH_USER Quem está usando o painel? CFG; Desativar na tela de alarme pin 08-quem
MODE_SETTINGS_PIN_POLICY Segurança do PIN Menu, item 7 — 08-politica
MODE_CONFIRM_AP Modo de Configuração Menu, item 8 — 11-ap-confirmar
MODE_SET_CLOCK Data e hora Fim do boot, sem rede configurada e com o relógio provisório; menu, item 4 clk 04-painel-data-hora
MODE_OTA_UPDATE Atualização de firmware Uma atualização pela web otarx, otachk, otardy, otainst, otaref, otacut 11-ota-recebendo

As tags touchcal e touchsens abrem as duas a etapa de sensibilidade; a de posição vem depois dela. As da atualização mostram a etapa sem atualizar nada: otarx com a barra em 42 %, otaref seguido do código v da recusa (otaref8, sem assinatura; sem número, imagem inválida); qualquer outra tag a tira da tela. A tela de boot e a de progresso do gesto do AP não são modos: o painel as desenha antes da tela inicial, e GET /api/screenshot não as captura.

Voltar ao sumário

Capítulo 12

O LCD do alpha

alpha A imagem alpha troca o painel de toque por um LCD de caracteres de 16 colunas e 2 linhas. Este capítulo mostra tudo o que esse LCD exibe, do boot às leituras e ao ponto de acesso de configuração, para quem instala e opera um SIMUT alpha.

O que o LCD faz e o que não faz

O LCD só mostra; ele não tem botões nem toque. Tudo o que se configura num alpha passa pela interface web (capítulo 13), pelo console serial ou pelo Bluetooth (capítulo 14).

O LCD mostra O LCD não mostra
O boot, com uma barra de progresso A data e a hora (capítulo 10)
O resultado da conexão Wi-Fi e o endereço IP Os alarmes de limite (capítulo 7)
As leituras, uma grandeza por vez O mínimo, o máximo e o histórico
ERRO para sensor em falha O estado do Bluetooth
O sinal do Wi-Fi Menus
A contagem de pendentes da telemetria
O endereço, o nome e a chave do AP de configuração (O ponto de acesso de configuração)
As etapas de uma atualização do firmware (A atualização do firmware)

O LCD fala só português, seja qual for o idioma da interface web ou do console.

O layout

O LCD tem 16 colunas (0 a 15) e 2 linhas (0 e 1). Nas leituras, ele se divide assim:

Área Linha Colunas O que mostra
Canto de cima 0 0 e 1 W e o ícone do sinal do Wi-Fi
Canto de baixo 1 0 a 2 O slot na tela, como S2, ou a contagem de pendentes
Valor 0 e 1 3 a 13 O número em algarismos grandes, de duas linhas
Unidade 0 e 1 13 a 15 o e C, ou %UR

Os algarismos grandes são desenhados com caracteres especiais do LCD: cada um ocupa 3 colunas e as 2 linhas.

O boot

Ao ligar, o LCD mostra por 1,2 s:

SIMUT 2.7.1
  Inicializando

Em seguida, a linha de baixo vira uma barra de 14 posições entre colchetes. Ela avança uma posição a cada etapa nova do boot, ou a cada 0,8 s se nenhuma etapa nova chegar, e se completa no fim do boot:

SIMUT 2.7.1
[#######       ]
Figura 125. A abertura do LCD, com a versão.
Figura 126. A barra de progresso do boot.

O resultado da rede

No fim do boot, o LCD mostra o resultado da conexão:

Linha de cima Linha de baixo Situação Por quanto tempo
Conectado! O endereço IP, como 192.0.2.10 Na rede, com IP 3 s depois de o IP aparecer
Conectado! Obtendo IP... Associado à rede, esperando o endereço Até 10 s
Sem WiFi Offline Sem rede 3 s

Depois disso, o LCD passa às leituras, também num alpha sem rede configurada: o boot não abre o AP de configuração (O ponto de acesso de configuração). Sem rede configurada, o boot não espera a rede e chega logo a Sem WiFi; no fim dele, o console escreve Sem rede, relogio provisorio: conf time AAAA-MM-DD HH:MM:SS. O LCD não mostra a hora: responda com esse comando, pelo console USB ou pelo Bluetooth, como conf time 2026-10-01 14:30:00 (capítulo 10).

 Conectado!
192.0.2.10
Figura 127. O fim do boot com a rede: Conectado! e o endereço IP.
Figura 128. Associado à rede, esperando o endereço.
Figura 129. O fim do boot sem rede.

As leituras

O LCD mostra uma grandeza de um sensor por vez e passa para a próxima a cada 3 s. A ordem segue os slots ativos, do menor para o maior, e, dentro de cada sensor, as grandezas dele:

Tipo Grandezas, na ordem
DS18B20 Temperatura
DHT22 Temperatura, umidade
BME280 Temperatura, umidade, pressão
BMP280 Temperatura, pressão

Com um DHT22 no slot 0 e um BME280 no slot 2, o ciclo é: temperatura do slot 0, umidade do slot 0, temperatura do slot 2, umidade do slot 2, pressão do slot 2, e de novo. A tela atualiza a cada 0,5 s.

Como cada grandeza aparece:

Grandeza Formato
Temperatura Algarismos grandes com uma casa decimal e vírgula, como 23,4, e o e C à direita. Um valor negativo leva um traço antes dos algarismos
Umidade Algarismos grandes, inteiros, como 58, com %UR embaixo, à direita
Pressão Caracteres normais, na linha de cima, com uma casa decimal e ponto, como 1013.2 hPa

A dezena de uma temperatura abaixo de 10 °C fica em branco: 5,3 °C aparece como 5,3.

Qual sensor está na tela. Com mais de um sensor ativo, o canto de baixo à esquerda mostra S e o número do slot, como S2. Com um só, o canto fica livre para a contagem de pendentes. O LCD não mostra o nome do sensor.

Figura 130. Uma temperatura em algarismos grandes, com o slot no canto de baixo.
Figura 131. A umidade em algarismos grandes, com %UR.
Figura 132. A pressão, em caracteres normais na linha de cima.
Figura 133. Uma temperatura negativa: o traço antes dos algarismos.

Erro e ausência de sensor

O LCD mostra ERRO em letras grandes, nas colunas 3 a 14, em dois casos:

  • Sensor em falha: quando chega a vez de um sensor que não está lendo (capítulo 6). O ciclo continua: os outros sensores aparecem normalmente na vez deles.
  • Nenhum sensor ativo: sem nenhum slot ativo, ERRO fica fixo, com o ícone de Wi-Fi no canto.

Com mais de um sensor, o canto de baixo diz qual está em falha. Uma grandeza sem valor, como a umidade de um sensor que ainda não fez a primeira leitura, também aparece como ERRO na vez dela.

A figura do sensor em falha está no capítulo 6.

Figura 134. ERRO fixo: nenhum sensor ativo.

Alarmes

O LCD não muda durante um alarme de limite: ele segue o ciclo, mostrando os valores normalmente. A cigarra do alpha toca, e não há como silenciar pelo aparelho (capítulo 7). Um alarme de falha aparece só como o ERRO do sensor na vez dele.

Para acompanhar alarmes num alpha, use a linha de alarmes (capítulo 22).

O sinal do Wi-Fi

O canto de cima à esquerda mostra W seguido de um ícone de sinal com seis estados:

Ícone RSSI
5 barras −50 dBm ou mais
4 barras de −60 a −51 dBm
3 barras de −70 a −61 dBm
2 barras de −80 a −71 dBm
1 barra de −90 a −81 dBm
Um X abaixo de −90 dBm, ou sem conexão

Desde a v2.7.2, as barras são uma escada de cinco degraus, cada um um pixel mais alto que o da esquerda, e acendem da esquerda para a direita, como no painel da imagem release e no celular.

Na v2.7.1, cada nível acende uma linha a mais, de baixo para cima: com sinal fraco, o ícone é uma linha reta na largura toda, e ele cresce para cima.

Figura 135. Os seis estados do ícone de sinal: a escada da v2.7.2 e as linhas da v2.7.1.

Os pendentes da telemetria

Desde a v2.7.2, com um único sensor ativo, o canto de baixo à esquerda mostra quantos registros esperam envio pela telemetria, do mesmo jeito que o painel da imagem release:

  • nada, quando não há pendentes;
  • o número, até 999, como 37;
  • os milhares com k, de 1.000 em diante: 2.500 registros aparecem como 2k.

O aparelho atualiza a contagem a cada 10 s. Com mais de um sensor, o canto mostra o slot, e a contagem não aparece no LCD; ela continua no cartão Registros Pendentes do Painel de Controle da interface web (capítulo 13).

Na v2.7.1, o LCD não mostra os pendentes.

Figura 136. A contagem de pendentes no canto de baixo, com um único sensor.
Figura 137. Mais de mil pendentes: a contagem em milhares.

O ponto de acesso de configuração

O ponto de acesso de configuração do alpha só abre pelo comando ap, no console USB ou pelo Bluetooth (capítulo 14); o alpha não tem painel, nem o gesto do boot. Com o AP aberto, o LCD tem três páginas, que se alternam (capítulo 9):

Página Linha de cima Linha de baixo
1 Modo AP 1 de 3 192.168.4.1
2 Rede: 2 de 3 O nome da rede, como simut_SETUP
3 Senha: 3 de 3 A chave, de 10 caracteres, ou (aberta) numa rede sem senha

Cada página fica 3 s. Um valor com mais de 16 caracteres rola para a esquerda, uma coluna a cada 300 ms, com dois espaços entre o fim e o recomeço; nesse caso a página dura uma volta inteira. O nome de rede mais longo, com 37 caracteres, leva cerca de 12 s para passar.

Para usar o AP num alpha:

  1. Abra o AP com o comando ap, pelo console USB ou pelo Bluetooth (capítulo 14), e pegue o nome da rede e a chave:
    • na resposta do comando, que traz a chave; o nome da rede é o nome do aparelho seguido de _SETUP;
    • no console USB, que mostra as linhas [AP] SSID, [AP] PSK e [AP] URL quando o AP abre; ou
    • nas páginas do AP, no LCD.
  2. No celular ou no computador, conecte-se a essa rede com essa chave.
  3. Abra http://192.168.4.1.

O restante está no capítulo 9.

Senha:   3 de 3
K7PX4MRW2A
Figura 138. A página 1 do AP: o endereço.
Figura 139. A página 2 do AP: o nome da rede.
Figura 140. A página 3 do AP: a chave.

A atualização do firmware

Uma atualização pela web (capítulo 17) toma o LCD, à frente das leituras e das páginas do AP, com as etapas da tela do painel (capítulo 11) em duas linhas:

Etapa Linha de cima Linha de baixo
Recebendo e conferindo Atualizando... Nao desligue!
Conferida Imagem conferida aguarda instalar
Instalando Instalando... Nao desligue!
Recusada Atualiz.recusada O motivo: outro modelo, sem assinatura, assin. invalida, chave aposentada, versao bloqueada, chave de bancada ou imagem invalida
Interrompida Atualiz.cortada versao mantida

O LCD não tem barra nem porcentagem. Do primeiro byte ao fim da conferência, a parte do aparelho que escreve no LCD fica parada, por causa da gravação da imagem na memória, e o LCD guarda Atualizando.... Uma recusa fica 12 s, e uma interrupção 8 s; depois o LCD volta às leituras. Isso vem da leitura do código; estas linhas não foram conferidas num LCD.

Referência dos estados

Estado Linha de cima Linha de baixo Figura
Abertura SIMUT 2.7.1 Inicializando 12-splash
Boot SIMUT 2.7.1 Barra [##...] 12-boot
Rede com IP Conectado! O IP 12-conectado
Esperando IP Conectado! Obtendo IP... 12-obtendo-ip
Sem rede Sem WiFi Offline 12-offline
Temperatura W, ícone e algarismos Slot ou pendentes, algarismos, C 12-temperatura
Umidade W, ícone e algarismos Slot ou pendentes, algarismos, %UR 12-umidade
Pressão W, ícone e 1013.2 hPa Slot ou pendentes 12-pressao
Sensor em falha W, ícone e ERRO Slot ou pendentes, ERRO 06-lcd-erro
Nenhum sensor W, ícone e ERRO ERRO 12-sem-sensor
AP, página 1 Modo AP 1 de 3 192.168.4.1 12-ap-1
AP, página 2 Rede: 2 de 3 O nome da rede 12-ap-2
AP, página 3 Senha: 3 de 3 A chave 12-ap-3
Atualização Atualizando... e as outras etapas Nao desligue!, o motivo de uma recusa — (A atualização do firmware)

Voltar ao sumário

Capítulo 13

A interface web no dia a dia

Este capítulo mostra como entrar na interface web do SIMUT, como andar entre as páginas e como ler a página Painel de Controle, inclusive o espelho do painel. Ele é para quem usa o aparelho pelo navegador todos os dias; a configuração de cada página está nos capítulos indicados no fim.

O que é a interface web

O próprio aparelho serve a interface web. Ela não depende de internet: as páginas, a folha de estilo, os ícones e o desenho dos gráficos saem do aparelho, então tudo funciona numa rede local isolada. Toda imagem que vai a campo leva a interface inteira dentro do firmware.

A interface tem 11 páginas e dois arquivos comuns:

Página Rota Para que serve
Entrada /login Entrar e trocar a própria senha
Troca de senha obrigatória /force_chpass Definir a senha no primeiro acesso
Painel de Controle / Leituras, estado do aparelho e espelho do painel
Histórico e Logs /history Gráficos, calendário e eventos
Alarmes e Sons /alarms Limites de alarme e sons
Telemetria /telemetry Envio de medições e linha de alarmes
Configurações /config Identidade, hora, sensores e syslog
Rede /network Wi-Fi, IP, DNS, NTP e servidor web
Usuários /users Contas e permissões
Arquivos /files Arquivos, backup, restauração e atualização
Licença /license A licença do software

Os dois arquivos comuns são /style.css, a aparência das páginas internas, e /lang.js, que cuida do tema, do idioma, da barra de topo, da gaveta de navegação e dos botões de gravação.

O aparelho envia as páginas com Cache-Control: no-store. O navegador sempre pede a versão atual, e o botão Voltar do navegador recarrega a página em vez de mostrar uma cópia antiga. Os dois arquivos comuns ficam guardados no navegador por até 7 dias, mas cada página os pede com uma marca da versão no endereço; depois de uma atualização de firmware, as páginas novas buscam os arquivos novos sozinhas.

HTTP e HTTPS

release

Na imagem release, com um certificado instalado, o aparelho atende só em HTTPS: na porta 443 quando a porta configurada é a padrão (80), ou na porta configurada, se ela foi mudada. Nessa situação o endereço http:// deixa de responder, porque o aparelho nunca serve os dois ao mesmo tempo. As imagens alpha e Air atendem só em HTTP. A instalação do certificado está no capítulo 9.

Em HTTPS o aparelho atende uma conexão segura por vez. Por isso as páginas enfileiram as próprias consultas, uma de cada vez, com 8 s de limite para cada uma, e carregam mais devagar que em HTTP. A opção Conexões persistentes (keep-alive), na página Rede, reduz esse custo (capítulo 9).

No SIMUT Air

air

No Air, a interface web só existe enquanto o aparelho está em M0: logo depois de ligar, com o carregador conectado ou depois de air stop no console. Um despertar para medir ou transmitir não sobe o servidor web.

Toda consulta feita com uma sessão aberta reinicia a contagem de ociosidade do Air. Uma aba aberta no Painel de Controle consulta o aparelho a cada 3 s e, portanto, o mantém acordado. Feche a aba quando terminar. O ciclo do Air está no capítulo 19.

Como abrir a interface

  1. Conecte o computador ou o celular à mesma rede do aparelho.
  2. No navegador, digite o endereço do aparelho, por exemplo http://192.0.2.10.
  3. Se a porta do servidor web foi mudada, acrescente-a ao endereço, por exemplo http://192.0.2.10:8080.

Sem sessão aberta, o aparelho leva você para a página de entrada.

O nome também serve, se o mDNS estiver ativo: é o nome do aparelho seguido de .local, como http://simut.local. Onde descobrir o endereço está no capítulo 4 e no capítulo 9. No ponto de acesso de configuração, o endereço é http://192.168.4.1, e qualquer outro endereço digitado leva à página Rede (capítulo 4).

Um caminho que não existe responde 404: Not Found.

A página de entrada

A página de entrada. Note o seletor de idioma no rodapé e o link Trocar senha abaixo do botão Entrar.
Figura 141. A página de entrada. Note o seletor de idioma no rodapé e o link Trocar senha abaixo do botão Entrar.

A página mostra, de cima para baixo:

  • o logotipo SIMUT e a legenda “Sistema de Monitoramento Universal e Telemetria”, sempre em português;
  • a versão do firmware, como v2.11.1, abaixo da legenda (desde a v2.7.3);
  • Usuário (Username): o nome da conta;
  • Senha (Password);
  • Mostrar senha (Show password): mostra a senha digitada;
  • Entrar (Sign In);
  • uma linha de mensagens;
  • o link Trocar senha (Change password);
  • no rodapé, o seletor de idioma, com English e Português (Idioma).

Para entrar:

  1. Digite o nome da conta em Usuário.
  2. Digite a senha em Senha.
  3. Toque em Entrar.

A página transforma a senha num resumo SHA-256 antes de enviá-la: a senha que você digitou não viaja pela rede. Cada tentativa leva também um código de uso único, que a página pede ao aparelho quando abre. Esse código vale 60 s.

Com a senha certa, o aparelho abre o Painel de Controle. Se a conta precisa trocar a senha, abre antes a troca de senha obrigatória.

release A cada entrada, o painel do aparelho mostra Web: <conta> na barra de cima por 5 s.

Se a opção Sons Web estiver ligada (capítulo 7), o aparelho toca o som de confirmação a cada entrada e o som de erro a cada senha errada.

Mensagens e bloqueio

Mensagem Quando aparece O que fazer
Bloqueado por Ns. Tentativas excessivas. (Locked for Ns. Too many attempts.) Depois de cada senha errada, com contagem regressiva Espere a contagem terminar e tente de novo
Limite de sessões atingido. Tente mais tarde. (System is full. Try again later.) Três outras contas já têm sessão aberta Veja Sessões
Usuário ou senha incorretos. (Invalid credentials.) O aparelho recusou a tentativa sem aplicar bloqueio, por exemplo com um código de uso único que já tinha sido usado Tente de novo
Erro de conexão. (Connection error.) A página não conseguiu falar com o aparelho Confira a rede e o endereço

Toda senha errada bloqueia novas tentativas por um tempo que dobra a cada erro seguido: 2 s no primeiro, depois 4, 8, 16, 32, 64, 128 e 256 s, e 300 s a partir do nono erro. Durante a contagem, o botão Entrar fica desativado; quando ela termina, a página prepara sozinha a tentativa seguinte. Se você reabrir a página no meio de um bloqueio, a contagem aparece com o tempo que falta.

O bloqueio vale para o endereço do computador, não para a conta. A contagem de erros só volta a zero quando uma entrada, ou uma troca de senha, dá certo a partir daquele endereço. O mesmo bloqueio vale para a conta e a senha usadas no endereço /metrics (capítulo 24).

Tentar de novo durante a contagem não adianta: o aparelho recusa sem conferir a senha e informa o tempo que falta.

Figura 142. O bloqueio depois de uma senha errada. O botão Entrar volta sozinho quando a contagem termina.

Trocar a senha pela página de entrada

O link Trocar senha troca a senha de qualquer conta que saiba a senha atual, sem abrir sessão.

  1. Toque em Trocar senha.
  2. Preencha Usuário, Senha Atual (Current Password) e Nova Senha (New Password).
  3. Acompanhe a barra de força e a lista de requisitos: Mínimo 8 caracteres (At least 8 characters), Letra (Letter), Dígito (Digit) e Símbolo (Symbol). Cada requisito atendido fica verde.
  4. Repita a senha nova em Repetir Nova Senha (Repeat New Password).
  5. Toque em Salvar Nova Senha (Save New Password).

O botão Salvar Nova Senha só fica ativo quando os quatro requisitos estão atendidos e as duas senhas novas são iguais. Para a página:

  • letra é uma letra de A a Z, maiúscula ou minúscula, sem acento;
  • símbolo é qualquer caractere que não seja letra de A a Z nem dígito, então um espaço ou uma letra acentuada contam como símbolo.

A marca Mostrar senha desta tela mostra os três campos de uma vez. O link ← Voltar ao Login volta ao formulário de entrada.

Resultado O que a página mostra
Senhas novas diferentes entre si As senhas não coincidem.
Senha nova igual à atual A nova senha deve ser diferente da atual.
Senha atual errada Volta ao formulário de entrada e mostra o bloqueio, porque conta como uma tentativa errada
Sucesso Senha trocada. Faça login. Depois de 1,5 s, volta ao formulário de entrada com o nome da conta preenchido

Em HTTP, a página envia só os resumos SHA-256 das senhas, e o aparelho não tem como conferir a força da senha nova: valem apenas as regras da página. Em HTTPS, a página envia as senhas dentro da conexão cifrada, e o aparelho também exige pelo menos 8 caracteres com uma letra e um dígito.

Trocar a senha por aqui também cumpre a troca obrigatória da conta. Nenhuma sessão é aberta: entre em seguida com a senha nova.

Figura 143. O formulário de troca de senha. Três requisitos estão verdes e Símbolo ainda não; o botão Salvar Nova Senha continua desativado.

O aviso de sessão segura antiga

Às vezes a entrada dá certo e o navegador volta para a página de entrada logo em seguida. Quando isso acontece em menos de 30 s, a página mostra uma faixa amarela: Login aceito, mas o navegador guarda uma sessão segura de uma visita HTTPS anterior. Abra uma janela anônima ou limpe os cookies deste site e entre de novo.

A causa é um cookie de sessão marcado como seguro, deixado por uma visita anterior em HTTPS ao mesmo endereço. Uma página http:// não pode enviar nem substituir esse cookie. Isso acontece, por exemplo, quando o certificado foi removido e o aparelho voltou a atender em HTTP.

Para resolver, abra uma janela anônima ou apague os cookies do endereço do aparelho no navegador, e entre de novo.

Figura 144. A faixa amarela que aparece quando o navegador não consegue guardar a sessão nova.

A troca de senha obrigatória

Algumas contas precisam trocar a senha antes de usar a interface:

  • as contas de fábrica, no primeiro acesso;
  • as contas criadas ou resetadas por um administrador na página Usuários, que recebem uma senha temporária mostrada uma única vez (capítulo 8);
  • a conta admin, depois do comando system admin reset no console (capítulo 14).

Enquanto a troca estiver pendente, toda página interna leva a esta. É a própria página de entrada, com a marca SIMUT no alto, mostrando só o formulário de senha nova: Bem-vindo! (Welcome!) e o texto Defina uma nova senha forte para acessar o sistema.

  1. Digite a senha nova em Nova Senha (New Password).
  2. Acompanhe a barra de força e as quatro exigências embaixo dela — Mínimo 8 caracteres, Letra, Dígito e Símbolo —, que se marcam uma a uma conforme a senha as atende.
  3. Repita a senha em Repetir Nova Senha (Repeat New Password).
  4. Toque em Salvar e Entrar (Save & Login).

A marca Mostrar senha (Show password) mostra os campos. O botão Salvar e Entrar só fica ativo com as quatro exigências atendidas — pelo menos 8 caracteres, uma letra de A a Z, um dígito e um símbolo — e as duas senhas iguais. A barra fica vermelha, depois amarela, e verde quando a senha atende às quatro.

A página não pede a senha atual: a sessão já provou quem você é. Com a senha salva, o aparelho abre o Painel de Controle, na mesma sessão.

Se o aparelho recusar a senha, a página mostra Error updating password. embaixo do botão, sempre em inglês. Há duas causas:

  • em HTTPS, a senha tem menos de 8 caracteres, ou falta letra ou dígito;
  • alguém tocou no painel do aparelho nos últimos 5 s. Espere e toque em Salvar e Entrar de novo.

O seletor de idioma é o mesmo da página de entrada. Não há como seguir para outra página antes de trocar a senha. Para desistir, feche o navegador ou abra o endereço /logout.

Figura 145. A troca de senha obrigatória. Com as duas senhas iguais e as quatro regras atendidas, a barra fica verde e o botão Salvar e Entrar fica ativo.

Sessões

Ao entrar, o aparelho abre uma sessão e grava no navegador o cookie SIMUTSESS. O cookie não é legível por scripts da página (HttpOnly), só viaja em pedidos feitos pela própria página do aparelho (SameSite=Strict) e, em HTTPS, só viaja por conexão cifrada (Secure).

As regras das sessões:

  • Três sessões ao todo. O aparelho mantém no máximo três sessões abertas. Navegadores, scripts e o gestor de frota, que usa o mesmo tipo de sessão pelo cabeçalho Authorization: Bearer (capítulo 27), dividem essas três vagas. Uma quarta conta recebe Limite de sessões atingido. Tente mais tarde.
  • Uma sessão por conta. Entrar de novo com a mesma conta, em qualquer navegador, substitui a sessão anterior dessa conta. A aba antiga perde o acesso: a tabela de sensores do Painel de Controle passa a mostrar Connection Error, e a próxima página aberta nela leva à entrada.
  • 15 min de ociosidade. Uma sessão sem nenhuma consulta por 15 min expira. Toda consulta renova a sessão, e o Painel de Controle consulta o aparelho a cada 3 s: enquanto ele estiver aberto, a sessão não expira e ocupa uma vaga.
  • Um reinício encerra todas. As sessões ficam só na memória do aparelho. Depois de Salvar e reiniciar, a página se recarrega sozinha cerca de 12 s depois e mostra a entrada.

Para sair, abra a gaveta de navegação e toque em Sair (Logout). O aparelho encerra a sessão, o navegador apaga o cookie e a página de entrada volta.

Alterações preparadas e ainda não gravadas ficam guardadas na aba do navegador enquanto você passa de uma página a outra (capítulo 5). Sair as descarta, e uma entrada nova também.

O log de eventos registra as sessões (capítulo 16):

Código Quando
300 Entrada aceita (Login OK: <conta>) e saída (Logout: <conta>)
301 Tentativa de entrada recusada
302 Uma sessão pediu uma página sem ter a permissão
304 Sessão expirada por ociosidade

A barra de topo

Toda página interna começa com a mesma barra. Da esquerda para a direita:

  • Menu: o botão com três traços abre a gaveta de navegação. Ela é a única navegação da interface, em qualquer largura de tela.
  • Marca e versão: SIMUT seguido da versão do firmware, por exemplo SIMUT 2.7.1. Até o aparelho responder, aparece SIMUT IoT.
  • Gravação: um selo e os botões Testar (Test), Aplicar agora (Apply now) e Salvar e reiniciar (Save & restart). Eles só aparecem quando há alterações preparadas e ainda não gravadas. O selo diz Alterações não salvas (Unsaved changes), Não exige reinício (No restart needed) ou Reinicia por: seguido do motivo. O que cada botão faz está no capítulo 5.
  • Tema: o botão redondo alterna entre o tema claro e o escuro. Ele mostra o sol quando a página está escura e a lua quando está clara, isto é, o tema para onde ele leva (Tema claro e escuro).
  • Estado: um ponto e o endereço IP do aparelho. O ponto fica cinza enquanto a página carrega, verde quando o aparelho respondeu à consulta da sessão e vermelho quando não respondeu. O endereço só aparece para contas com a permissão Painel; para as outras, fica --.

Abaixo da barra, uma trilha mostra onde você está: SIMUT › Painel de Controle, por exemplo.

Os avisos da interface aparecem logo abaixo da barra, sem cobri-la, e somem sozinhos depois de alguns segundos.

Figura 146. A barra de topo com uma alteração preparada: o selo, os botões de gravação, o botão de tema e o endereço do aparelho.

A gaveta de navegação

Toque no botão de menu para abrir a gaveta. Ela desliza da esquerda, com 280 pixels de largura, e escurece o resto da página. Para fechá-la, toque no X, toque fora dela ou pressione Esc. Com a gaveta aberta, a página atrás não rola.

De cima para baixo, a gaveta mostra:

  • os itens de navegação, nesta ordem: Painel de Controle (Dashboard), Histórico e Logs (History & Logs), Alarmes e Sons (Alarms & Sounds), Telemetria (Telemetry), Configurações (System Config), Rede (Network), Usuários (Users) e Arquivos (Files);
  • a versão do firmware, por exemplo SIMUT 2.7.1;
  • Licença (License);
  • uma saudação com o nome da conta, o seletor de idioma e Sair.

A página atual aparece destacada na cor de acento.

A saudação é Olá (Hello) seguida do nome da conta. Quando o relógio do aparelho está acertado, ela muda com a hora do dia, contada no fuso do seu computador: Bom dia das 5h às 11h59, Boa tarde das 12h às 17h59 e Boa noite no resto do dia.

A gaveta aberta para a conta admin, com os oito itens, a versão, Licença, a saudação, o seletor de idioma e Sair.
Figura 147. A gaveta aberta para a conta admin, com os oito itens, a versão, Licença, a saudação, o seletor de idioma e Sair.

O que cada permissão mostra

A gaveta esconde os itens que a conta não pode abrir. O aparelho confere de novo em cada página e em cada consulta, então esconder é só conforto: uma conta sem a permissão recebe recusa mesmo digitando o endereço.

Permissão Itens que ela mostra na gaveta Observação
Painel PERM_DASHBOARD Painel de Controle e Licença É a página aberta depois da entrada
Histórico PERM_HISTORY Histórico e Logs Gráficos, calendário e exportação
Logs PERM_LOGS Histórico e Logs Eventos do sistema
Sistema PERM_SYS_CONFIG Alarmes e Sons, Telemetria e Configurações No Painel de Controle, também libera a captura, o espelho e o tema do painel
Rede PERM_NET_CONFIG Rede
Leitura PERM_FILE_READ Arquivos A página Arquivos só abre com esta
Upload PERM_FILE_UPLOAD Arquivos Sem Leitura, o item aparece e a página recusa
Excluir PERM_FILE_DELETE Arquivos Sem Leitura, o item aparece e a página recusa
Usuários PERM_USER_MGR Usuários
Calibração PERM_CALIB Nenhum item próprio A calibração fica no editor de slot de Configurações, que exige também Sistema (capítulo 6)
Limites (painel) PERM_ALARM_LIMITS, Bloqueio (painel) PERM_ALARM_BLOCK, Manut. (painel) PERM_MAINT Nenhum Valem só no painel (capítulo 8)

A página Histórico e Logs abre com Histórico ou com Logs, mas cada metade consulta o aparelho com a própria permissão: a de gráficos exige Histórico, e a de eventos exige Logs (capítulo 15, capítulo 16).

Figura 148. A gaveta de uma conta com Painel e Histórico: só Painel de Controle, Histórico e Logs e Licença aparecem.
Figura 149. A resposta Access Denied, que uma conta sem a permissão Painel recebe ao entrar.

O Painel de Controle

O Painel de Controle (rota /) é a primeira página depois da entrada e exige a permissão Painel. Ele consulta o aparelho a cada 3 s e mostra:

  • uma faixa de cartões de estado;
  • uma faixa de cartões de métricas;
  • a tabela de sensores;
  • release o bloco Tela (Display Capture), com o espelho do painel (O espelho do painel).

Em telas com mais de 900 pixels de largura, o bloco Tela ocupa uma coluna à direita, de 360 pixels. Em telas mais estreitas, ele desce para baixo da tabela. As imagens alpha e Air não têm painel com toque nem o bloco Tela, e a página fica numa coluna só.

O Painel de Controle na imagem release: cartões de estado, cartões de métricas, tabela de sensores e, à direita, o bloco Tela.
Figura 150. O Painel de Controle na imagem release: cartões de estado, cartões de métricas, tabela de sensores e, à direita, o bloco Tela.
Figura 151. O Painel de Controle numa imagem sem painel com toque: uma coluna só, sem o bloco Tela.

Cartões de estado

Cartão Valor Linha de baixo
Data e Hora (System Date & Time) Data e hora do relógio do aparelho, no formato dd/mm/aaaa hh:mm:ss; antes de o relógio ser acertado, Falha NTP Sincronizado, em verde; antes do acerto, Conectando…, em vermelho
Tempo Ativo (System Uptime) Tempo desde o último reinício, como 2d 05h 13m 09s —
Sinal Wi-Fi (WiFi Signal) Intensidade do sinal agora, em dBm min <pior> / <melhor> max: o pior e o melhor sinal vistos desde o último reinício
Registros Pendentes (Pending Records) Registros do histórico que ainda não foram enviados pela telemetria, como 12 pkts O estado da telemetria (tabela abaixo)
Uso de RAM (RAM Usage) Porcentagem da memória em uso, com uma barra <livre> KB Livre / <total> KB Total
Armazenamento (Flash Storage) Porcentagem do sistema de arquivos em uso, com uma barra <livre> KB Livre / <total> KB Total

As barras de Uso de RAM e Armazenamento ficam amarelas acima de 70 % e vermelhas acima de 85 %. O espaço do sistema de arquivos é relido no máximo a cada 10 s.

A linha de baixo de Registros Pendentes:

Linha Quando
Telemetria desligada (Telemetry disabled) O lote mínimo da telemetria é 0 (capítulo 21)
Sincronizado (Synchronized) Telemetria ligada e nada pendente
Aguardando sinc. (Waiting telemetry sync) Telemetria ligada e registros esperando envio
Telemetria indisponível (Telemetry unavailable) O aparelho não informou a contagem; o valor mostra Avaliando… (Evaluating…)

Data e Hora mostra o relógio do aparelho convertido para o fuso horário do seu computador, não para o fuso configurado no aparelho. Se os dois fusos forem diferentes, a hora da página difere da hora do painel. O fuso do aparelho está no capítulo 10.

Cartões de métricas

Os números desta faixa são contados desde o último reinício e voltam a zero a cada reinício.

Cartão Valor Linha de baixo
Maior Bloco (Largest Block) O maior bloco contínuo de memória livre, em KB min: o menor valor visto
Heap Mín. (Heap Min Seen) A menor quantidade de memória livre já vista, em KB menor livre
Reconexões Rede (Net Reconnects) <wifi> / <mqtt>: quantas vezes o aparelho obteve IP no Wi-Fi e quantas vezes se conectou ao broker MQTT wifi / mqtt
Telemetria Env. (Telemetry Sent) Envios de telemetria aceitos, como 1.2k ok <n> falhas · <n> retry: envios que falharam e novas tentativas agendadas
Dados Telemetria (Telemetry Data) Soma dos tamanhos dos envios, em KB últ. <n> ms: o tempo do último envio
Leituras Sensor (Sensor Reads) Leituras de sensor bem-sucedidas, somando todos os sensores <n> erro: leituras que falharam
Saves Config (Config Saves) Pedidos de gravação da configuração, inclusive os que não mudaram nada para flash

Contagens a partir de mil aparecem abreviadas: 1.2k, 3.45M. A primeira conexão ao Wi-Fi já conta em Reconexões Rede. Maior Bloco menor que Heap Mín. indica memória fragmentada; os dois ajudam a diagnosticar um aparelho que reinicia sozinho (capítulo 30).

Tabela de sensores

A tabela lista os sensores ativos, um por linha:

Coluna O que mostra
Status Ponto verde, ou vermelho quando o sensor está em erro
Slot O número do slot, de 0 a 15
Tipo (Type) O tipo do sensor e, embaixo, quantos pinos ele usa e a função de cada um, como 1p · 1-Wire ou 2p · SDA,SCL
ID (ID Sensor) O identificador de hardware do slot
Leitura (Reading) O valor atual, com as grandezas do sensor separadas por barras
Nome (Sensor Name) O nome dado ao slot

A leitura segue o formato do navegador, com ponto decimal: a temperatura com duas casas e ºC, a umidade com uma casa e %, e a pressão com uma casa e hPa. Um BME280, por exemplo, aparece como 23.45 ºC | 55.2% | 1013.2 hPa. Um sensor em erro mostra Error; um sensor que ainda não tem leitura mostra --.

Enquanto carrega, a tabela mostra Carregando sensores… (Loading sensors…). Sem sensores ativos, mostra No active sensors.; os sensores são criados na página Configurações (capítulo 6). Quando a consulta falha, a tabela mostra Connection Error em vermelho: o aparelho está fora do ar, reiniciando, ou a sessão acabou. Recarregue a página.

Figura 152. O Painel de Controle no celular: os cartões em duas colunas e a tabela de sensores, que rola para o lado.

O espelho do painel

release

Na imagem release, o bloco Tela do Painel de Controle mostra o painel do aparelho no navegador. Ele tem uma área de imagem, uma linha de estado e três controles:

  • a lista de temas do painel;
  • Capturar (Capture screen): uma foto da tela;
  • Ao vivo (Live view): o espelho contínuo, que também aceita cliques como toques no painel.

Antes do primeiro uso, a área de imagem mostra Clique para capturar (Click Capture to view screen).

Os três controles exigem a permissão Sistema. Uma conta só com Painel vê o bloco, mas o aparelho recusa a captura, o espelho e a troca de tema.

Ver o painel ao vivo

  1. Toque em Ao vivo. O botão passa a dizer Parar (Stop), e a linha de estado mostra Clique no espelho para tocar no painel (Click the mirror to touch the panel).
  2. Acompanhe o painel na área de imagem. A cada quadro, a linha de estado mostra a taxa, o tamanho e o tempo do quadro, no formato <quadros> fps · <tamanho> kB · <tempo> s.
  3. Toque em Parar para encerrar.

A página pede um quadro por vez e só pede o seguinte depois de desenhar o anterior. Cada quadro chega em 30 faixas de 8 linhas, comprimidas por paleta quando isso compensa. Na bancada, um quadro levou 213 ms dentro do aparelho, com o Painel de Controle na tela (medido em 19/09/2026, v2.5.0-beta). O tempo que a página mostra inclui também a rede.

A imagem é ampliada sem suavização, para mostrar as cores que o painel de 320 × 240 pixels de fato mostra.

Com a aba escondida, o espelho não pede quadros; ele volta quando você retorna à aba.

Figura 153. O espelho ao vivo. O botão mostra Parar e a linha de estado dá a taxa, o tamanho e o tempo de cada quadro.

Tocar no painel pelo espelho

Com o espelho ao vivo, clique na imagem (ou toque nela, no celular) no ponto que você tocaria no painel. A página converte o ponto para as coordenadas do painel, de 0 a 319 na horizontal e de 0 a 239 na vertical, e o aparelho trata o clique como um toque de dedo.

  • Um círculo vermelho marca o ponto na hora. O quadro seguinte o apaga.
  • Depois de um clique, a página espera 600 ms antes de pedir o próximo quadro, para o painel terminar de redesenhar.
  • Se o aparelho recusar o toque, a linha de estado mostra Toque recusado (Touch refused) com o código da resposta, por exemplo Toque recusado (403) para uma conta sem Sistema.
  • Um clique conta como atividade no painel: reinicia a contagem de 30 s que devolve o painel à tela inicial.

O espelho não pula a proteção do painel. Para abrir as configurações do painel, você escolhe a conta e digita o PIN no teclado do painel pelo espelho, como faria com o dedo. O que se pode fazer ali depende das permissões da conta que o PIN identificou, não da sua sessão web (capítulo 8, capítulo 11).

Capturar a tela

  1. Toque em Capturar. Se o espelho estiver ao vivo, ele para, porque os dois não podem ler o painel ao mesmo tempo.
  2. Espere a área de imagem sair de Capturando… (Capturing Display…).

A captura é uma imagem BMP de 320 × 240 pixels e 230.454 bytes, em que cada linha da tela é lida três vezes e vale a leitura que se repete. Por isso ela é mais lenta que um quadro do espelho: 1,69 s na bancada (medido em 18/09/2026, v2.4.10-beta). Use a captura quando precisar de uma imagem fiel para registro. Para guardá-la, use o menu do navegador sobre a imagem.

Se a captura falhar, a área de imagem mostra Falha na leitura (Read Failed) por 2 s. As causas são um toque no painel nos últimos 5 s, inclusive um clique no espelho, outra captura em andamento ou uma conta sem Sistema.

Figura 154. Uma captura da tela do painel, exibida no bloco Tela.

Trocar o tema do painel

A lista do bloco Tela traz os temas do painel: os de fábrica e os instalados em /themes. Escolha um tema na lista, e o painel troca de tema na hora e grava a escolha, sem reiniciar. A cada 3 s, a lista volta a mostrar o tema que o painel está usando. Por isso, numa conta sem Sistema, a escolha volta atrás sozinha. Os temas do painel estão no capítulo 11.

Esta lista muda o painel do aparelho. O tema da interface web é outro, e fica no botão da barra de topo (Tema claro e escuro).

Quando o espelho espera ou para

Situação O que a linha de estado mostra O que acontece
Alguém tocou no painel com o dedo nos últimos 5 s Display em uso. Tente novamente em alguns segundos. A página tenta de novo a cada 1,5 s e volta sozinha
Outra captura em andamento, de outra aba ou de outra pessoa Display em uso. Tente novamente em alguns segundos. A página tenta de novo a cada 1,5 s
O aparelho recusou o quadro por outro motivo, ou a conexão caiu Falha na leitura O espelho para; toque em Ao vivo para recomeçar

Quem está diante do painel tem prioridade. Mesmo no meio de um quadro, o aparelho deixa passar o toque de um dedo; a partir desse toque, o espelho espera os 5 s.

Figura 155. O espelho esperando: alguém usa o painel com o dedo, e a página tenta de novo sozinha.

Tema claro e escuro

A interface tem um tema escuro e um tema claro. Sem escolha guardada, ela segue a preferência do sistema operacional: claro se o sistema pede claro, escuro nos outros casos.

Para trocar, toque no botão redondo da barra de topo. O botão mostra o tema para onde ele leva: o sol quando a página está escura, a lua quando está clara.

A escolha fica guardada no navegador, não no aparelho nem na conta. Ela vale para todas as páginas daquele navegador, inclusive a de entrada e a de troca de senha obrigatória, que não têm o botão. Em outro navegador ou em outro computador, a escolha é outra.

Figura 156. O Painel de Controle no tema claro. Compare com a figura do tema escuro no início da seção do Painel de Controle.

Idioma

A interface traz o inglês embutido e pode mostrar mais um idioma: o do pacote de idioma que o aparelho carregou.

O aparelho carrega um pacote no boot, e só quando o idioma do aparelho não é o inglês. O pacote é um arquivo language_<código>.lng na pasta /lang, como language_pt-BR.lng. Se houver mais de um, vale o primeiro em ordem alfabética. Depois de trocar o idioma do aparelho (capítulo 11, capítulo 14) ou o arquivo do pacote (capítulo 17), reinicie o aparelho para a interface web oferecê-lo.

Há dois seletores:

  • Na gaveta de navegação: EN e o código curto do pacote carregado, como PT ou ES. Sem pacote carregado, só EN aparece.
  • Na página de entrada: English e Português, sempre com esses nomes. Português usa o pacote carregado, qualquer que seja o idioma dele; sem pacote, os textos continuam em inglês.

Os dois seletores gravam a mesma escolha no navegador. Ela vale para todas as páginas daquele navegador e muda os textos na hora, sem recarregar. Na primeira visita de um navegador sem escolha guardada, a interface usa o pacote do aparelho, se houver um.

O idioma do navegador muda os textos da interface web; nos nomes dos eventos, ele escolhe entre o inglês e o idioma do pacote do aparelho (capítulo 16). O idioma do painel e das respostas do console é o do aparelho; as linhas do log que o console e o syslog mostram saem em inglês (capítulo 16).

Alguns textos aparecem sempre em inglês, qualquer que seja a escolha: por exemplo No active sensors., Connection Error, Access Denied, Error updating password. e a unidade pkts dos registros pendentes.

No celular

A interface se ajusta a telas de até 640 pixels de largura:

  • A barra de topo esconde a versão para o endereço do aparelho caber inteiro; a versão continua na gaveta.
  • Os botões e os campos têm pelo menos 44 pixels de altura, para o dedo.
  • A gaveta ocupa no máximo 84 % da largura da tela.
  • Os botões de gravação saem da barra de topo e viram uma barra fixa no rodapé, com os botões lado a lado. Quando os três aparecem, Salvar e reiniciar fica com o dobro da largura. O selo de estado não aparece.
  • Ao digitar num campo, a página rola para mantê-lo acima do teclado da tela e da barra do rodapé.
  • No Painel de Controle, os cartões ficam em duas colunas fixas, e a tabela de sensores rola para o lado.
Figura 157. No celular, os botões de gravação ficam numa barra fixa no rodapé.

A página Licença

A página Licença (rota /license) exige a permissão Painel e fica no pé da gaveta. Ela tem quatro blocos:

  • Licença de Software (Software License), com a frase Software livre. Abaixo, o que isso significa na prática.;
  • Em resumo (In short): um resumo da licença em linguagem simples, com o aviso de que ele não substitui o texto da licença;
  • Licença MIT (MIT License): o texto da licença, em inglês, porque é a versão original e a que tem valor legal;
  • Avisos de Terceiros (Third-Party Notices): os 25 componentes de terceiros que entram nas imagens de firmware, com o titular do copyright, a licença, as imagens que levam cada um e o endereço. Os textos completos das licenças ficam no THIRD_PARTY_NOTICES.md e na pasta LICENSES do repositório, publicados com cada versão.

Dois componentes têm licença própria em vez de uma licença livre comum: o driver do rádio (cyw43-driver), em todas as imagens, e o BTstack, a pilha Bluetooth das imagens alpha e Air. A Raspberry Pi concede os dois a quem monta produtos sobre o Pico W e o Pico 2 W, inclusive para uso comercial; fora desses chips eles não valem. Confira a lista antes de distribuir o aparelho.

A página Licença, com o resumo em linguagem simples e o texto original da licença MIT.
Figura 158. A página Licença, com o resumo em linguagem simples e o texto original da licença MIT.

Onde cada página está documentada

Página Rota Permissão para abrir Onde está
Entrada /login Nenhuma Este capítulo
Troca de senha obrigatória /force_chpass Sessão com troca pendente Este capítulo
Painel de Controle / Painel Este capítulo
Histórico e Logs /history Histórico ou Logs Gráficos, calendário e exportação: capítulo 15. Eventos: capítulo 16
Alarmes e Sons /alarms Sistema Capítulo 7
Telemetria /telemetry Sistema Capítulo 21. Linha de alarmes: capítulo 22. Home Assistant: capítulo 23
Configurações /config Sistema A página e os três botões: capítulo 5. Sensores e calibração: capítulo 6. Política de PIN: capítulo 8. Data e hora: capítulo 10. Syslog: capítulo 25
Rede /network Rede Capítulo 9
Usuários /users Usuários Capítulo 8
Arquivos /files Leitura Arquivos, backup, restauração e atualização: capítulo 17
Licença /license Painel Este capítulo

As rotas que as páginas usam para consultar e gravar dados estão no capítulo 26. O que cada permissão libera está no capítulo 8.

Voltar ao sumário

Capítulo 14

O console serial e o Bluetooth

O console serial (a CLI) é a porta de entrada por texto do aparelho: pelo cabo USB em todas as imagens e pelo Bluetooth no alpha e no Air. Este capítulo mostra como se conectar, os 15 comandos do console de emergência, o console completo e os comandos do Air, para quem instala, recupera ou opera o aparelho sem a interface web.

Os dois consoles

Toda configuração do dia a dia fica na interface web (capítulo 5). O console existe para quando a web não serve: descobrir o endereço, ler o log de eventos, recuperar a senha do administrador, trocar a rede Wi-Fi, reiniciar. Por isso a imagem release e a alpha trazem só o console de emergência. O console completo, com modos e dezenas de comandos, vem no Air, que não tem tela nem web fora do modo acordado, e nas imagens de teste, compiladas da fonte.

Imagem Console Bluetooth
release Emergência, 15 comandos Não
alpha Emergência, 15 comandos Sim
Air Completo, com os comandos air Sim, com o aparelho acordado em operação
Imagens de teste (pico_w_test, pico_w_test_https) Completo, com os comandos do painel e do PIN Não

Os comandos e as palavras-chave são sempre em inglês. As respostas saem no idioma do aparelho, o mesmo do painel, lido no boot; em português, elas vêm sem acentos, para qualquer terminal mostrar. De fábrica, o idioma é o português.

Conectar pelo USB

O Pico W aparece no computador como uma porta serial USB. Use 115200 baud, 8 bits, sem paridade, 1 bit de parada (8N1).

Sistema Nome da porta Programas
Linux /dev/ttyACM0 (ou ACM1, …) picocom, screen, minicom, pio device monitor
Windows COM3, COM4, … (veja no Gerenciador de Dispositivos) PuTTY (tipo de conexão Serial), monitor serial do Arduino IDE
macOS /dev/cu.usbmodem... screen, picocom
# Linux
picocom -b 115200 /dev/ttyACM0
# macOS (o nome exato aparece com: ls /dev/cu.usbmodem*)
screen /dev/cu.usbmodem1101 115200

No Linux, o seu usuário precisa pertencer ao grupo que controla a porta (dialout ou uucp, conforme a distribuição).

Como o console se comporta:

  • Eco: o aparelho repete cada caractere que recebe. Desligue o eco local do terminal, ou cada letra sai duas vezes.
  • Enter: tanto CR quanto LF encerram a linha. Uma linha vazia só mostra o prompt de novo.
  • Apagar: Backspace e Delete apagam o último caractere.
  • Tamanho: uma linha tem no máximo 256 caracteres; uma linha maior é descartada inteira.
  • Início: no alpha e no Air acordado em operação, o console mostra um cabeçalho durante o boot, logo depois da etapa do Wi-Fi. Na release e nas imagens de teste, ele não mostra nada até você teclar Enter; então aparece o prompt SIMUT>.
  • Boot: com o terminal aberto durante o boot, aparecem algumas linhas de diagnóstico que começam por [DBG]. Elas não são erros.
===========================================
 SIMUT IoT CLI 2.11.1
 Digite 'help' (ou 'ajuda', '?')
 For English: 'language en'
===========================================
SIMUT> 

Conectar pelo Bluetooth

alpha air O alpha e o Air oferecem o mesmo console por Bluetooth clássico, no perfil de porta serial (SPP). O aparelho aparece com o nome configurado para ele, como simut.

Parear

O aparelho fica visível nas buscas por 5 minutos depois que o Bluetooth liga, durante o boot, logo depois da etapa do Wi-Fi. Depois disso, ele some das buscas, mas um celular ou computador que já pareou continua conectando. Para parear um aparelho novo depois dos 5 minutos, reinicie o SIMUT e pareie logo em seguida.

  1. Ligue o SIMUT e, nos primeiros 5 minutos, procure dispositivos Bluetooth no celular ou no computador.
  2. Pareie com o nome do aparelho. O SIMUT não pede confirmação no pareamento.
  3. Abra um aplicativo de terminal serial Bluetooth (SPP) e conecte ao aparelho, ou abra a porta serial que o sistema criou para ele.

O fechamento da janela de descoberta vai para o log de eventos com o código 307, Bloqueio Bluetooth, e o texto BT discovery window closed.

Entrar

A senha do console por Bluetooth é a senha da conta admin da interface web.

  1. Conecte e tecle Enter. O aparelho responde com o pedido de senha.
  2. Digite a senha do admin e tecle Enter. Cada caractere aparece como *.
--- Conexao Bluetooth estabelecida ---
Senha do admin: **********

===========================================
 SIMUT IoT CLI 2.11.1
 Acesso concedido. Digite 'help'.
 (For English: 'language en')
===========================================
SIMUT> 

A entrada vai para o log com o código 300, Login bem-sucedido (BT admin login). A senha tem no máximo 64 caracteres. Se você trocar a senha do admin pela web, a do Bluetooth muda junto.

Senha errada e bloqueio

Cada senha errada responde Acesso negado. e bloqueia o Bluetooth por um tempo que dobra a cada erro seguido:

Erro seguido Bloqueio
1º 2 s
2º 4 s
3º 8 s
4º 16 s
5º 32 s
6º 64 s
7º 128 s
8º 256 s
9º em diante 300 s

Durante o bloqueio, o aparelho descarta tudo o que chega pelo Bluetooth e avisa uma vez: Bloqueado. Tente mais tarde. O bloqueio continua valendo se você desconectar e conectar de novo; só a senha certa, depois do prazo, zera a contagem. Cada erro vai para o log com o código 301, Falha de login, e cada bloqueio com o código 307, com os segundos no contexto.

Sessão

  • Inatividade: depois de 5 minutos sem nada digitado, a sessão termina com [SEGURANCA] Sessao encerrada (5 min inativo). (código 304, Sessão expirada). Tecle Enter para pedir a senha de novo.
  • Desconexão: desconectar encerra a sessão na hora. Quem conectar depois precisa da senha.
  • Mesma saída nos dois canais: o console escreve a mesma saída no USB e no Bluetooth. Quem está no cabo vê o que se faz pelo Bluetooth, e o contrário.
  • Comandos só pelo USB: system factory, system format, system admin reset e system https off são recusados pelo Bluetooth, inclusive dentro de do, com ERROR: Comando so pela USB (cabo serial). O log registra o código 302, Acesso não autorizado. O comando ap funciona pelo Bluetooth: abrir o AP a partir do celular, quando a senha do Wi-Fi está errada, é o motivo de o Bluetooth existir.

air O Air não liga o Bluetooth nos despertares do ciclo de hibernação, só quando está acordado em operação (capítulo 19).

O console de emergência

release alpha O console de emergência tem um só modo, com o prompt SIMUT>, e 15 comandos:

Comando O que faz
help (ou ajuda, ?) Lista os comandos
show net status Mostra o endereço IP, o sinal do Wi-Fi e contadores de envios interrompidos da web
show system info Mostra nome, versão, número de série, resolução do DS18B20, rede Wi-Fi, fuso, servidor NTP e estado do log
show system log Despeja o log de eventos gravado, até 2.000 registros
debug on, debug off, debug Liga ou desliga a transmissão do log ao vivo; sem argumento, mostra o estado
system admin reset confirm Gera uma senha nova para o admin e a mostra uma vez
system format confirm Formata o sistema de arquivos e reinicia
system factory confirm Volta a configuração de fábrica e reinicia
system https off confirm Apaga o certificado HTTPS e reinicia em HTTP
system ssid <nome> Grava o nome da rede Wi-Fi
system pass <senha> Grava a senha da rede Wi-Fi
system cors <origem> ou system cors off Grava a origem liberada para o gestor de frota
ap (ou apmode, ap-mode) Abre o ponto de acesso de configuração
time <AAAA-MM-DD> <HH:MM:SS> Acerta o relógio, na hora local (time)
reload confirm Reinicia o aparelho

Um comando que não está na lista responde ERROR: Comando desconhecido. As configuracoes ficam na interface web; 'help' lista o que resta aqui. e vai para o log com o código 585, Comando desconhecido.

Confirmar comandos destrutivos

Os comandos que apagam dados ou reiniciam exigem a palavra confirm no fim da linha. Sem ela, o aparelho só avisa e diz a linha exata:

SIMUT> reload
ATENCAO: vai reiniciar o dispositivo.
Use 'reload confirm' para prosseguir.
SIMUT> reload confirm

Exigem confirm: reload, system admin reset, system format, system factory e system https off. O aviso de alguns deles sugere a forma conf system ... confirm; o prefixo conf é aceito e ignorado, então as duas formas valem.

O que fica gravado

O console de emergência não tem write memory. Cada comando que precisa sobreviver a um reinício grava por conta própria:

Comando Quando vale
system ssid, system pass Gravados na hora; valem na próxima conexão, depois de reload confirm
system admin reset Gravado na hora; a senha nova vale já
system cors Gravado em /config/cors.txt na hora; vale no próximo boot
system factory, system format, system https off Na hora, com reinício
debug on, debug off Só nesta sessão: Vale para esta sessao; nao persiste apos reiniciar.
time Só até o próximo reinício: o relógio não é gravado

help

Em português, a lista vem do pacote de idioma instalado; sem pacote, ou em inglês, vem do texto embutido no firmware. O começo:

===========================================
    SIMUT - CONSOLE DE EMERGENCIA
===========================================
 As configuracoes ficam na interface web.
 Este console e o caminho de volta quando
 a web nao pode ser alcancada.
 Comandos destrutivos exigem ' confirm'
 (ex.: 'reload confirm').

show net status
  IP, RSSI, hora - encontrar o dispositivo
show system info
  Nome, firmware, serial, SSID do WiFi
...

show net status

Mostra o endereço IP e o sinal. Sem conexão, o sinal aparece como -100 dBm; com o AP aberto, o endereço é 192.168.4.1. O comando também registra o endereço no log (código 527, Mostrar IP).

As outras linhas servem para diagnóstico e contam desde o boot:

  • PBUF pool e Segmentos TCP: a memória da pilha de rede para receber e para enviar: quanto está em uso, o pico e as falhas de alocação. tcp_write sem memoria conta as vezes em que a pilha recusou um envio por falta de memória; o envio espera a confirmação do navegador e tenta de novo. Cada resposta sai em pacotes cheios, e com uma página aberta ele fica em 0: na bancada, 0 em 6.000 respostas. Até a v2.11.1, que mandava cada resposta em dezenas de pacotes pequenos, ele subia aos milhares.
  • Abortos de envio: respostas da interface web interrompidas, por prazo, por trava, por desconexão do navegador ou por escrita curta. Escrita curta é um envio que não terminou dentro do prazo: o aparelho encerra a resposta ali, e o navegador a vê cortada. Até a v2.11.1, essas respostas chegavam com um trecho faltando no meio, sem mexer em contador nenhum.
SIMUT> show net status

--- Status da Rede ---
 IP: 192.0.2.10
 RSSI: -58 dBm
 PBUF pool: 0 em uso / pico 2 / 24 total, 0 falhas
 Segmentos TCP: 0 em uso / pico 1 / 32 total, 0 falhas | tcp_write sem memoria 0
 Abortos de envio: prazo 0 | latch 0 | desconexao 0 | escrita curta 0
-------------------------------------------

O comando não mostra o estado do NTP, embora o texto de ajuda diga “hora”. Para ver se o relógio está acertado, use a interface web (capítulo 10).

show system info

SIMUT> show system info
-------------------------------------------
 [SISTEMA]
 Dispositivo:
 simut
 Firmware: 2.11.1
 Serial: E66138935F2C1A2B
 [SENSORES]
 Precisao DS18: 12-bit
 [CONECTIVIDADE]
 WiFi SSID:
 MinhaRede
 Fuso: GMT-3
 Servidor NTP:
 pool.ntp.org (default)
 Logging: ATIVO
-------------------------------------------

O Serial é o número de série da placa, a chave da calibração dos sensores sem ROM no arquivo calib.csv (capítulo 6). Sem rede configurada, a linha do SSID mostra <nao configurado>. Sem servidor NTP configurado, aparece pool.ntp.org (default).

show system log

Despeja o log de eventos gravado na memória, do arquivo antigo para o atual, até 2.000 registros. Cada linha tem:

Campo Exemplo O que é
Hora 1790164800 O instante, em segundos desde 1970 (UTC)
up up2h05m O tempo desde o boot, quando o evento aconteceu
C C0 O núcleo do processador (0 ou 1)
Nível [INF] DBG, INF, WRN, ERR ou FTL
Origem [NET ] O subsistema: APP, NET, SEC, STO, WEB, …
code code=527 O código do evento (apêndice B)
ctx ctx=0 O contexto, um número que o evento carrega
SIMUT> show system log

--- SYSTEM LOG START ---
1790164800 up2h05m   C0 [INF][NET   ] code=527 ctx=0
1790165112 up2h10m   C0 [WRN][SEC   ] code=301 ctx=0
--- SYSTEM LOG END ---

O log de eventos está no capítulo 16.

debug on e debug off

debug on transmite cada evento do log para o console no momento em que acontece, inclusive durante um boot que nunca chega a subir a web. Cada linha traz a hora, o tempo desde o boot, o núcleo, o nível, a origem e a descrição do evento:

SIMUT> debug on
OK: Debug: LIGADO
Vale para esta sessao; nao persiste apos reiniciar.
[14:05:12][UP 02:05:40][C0][INF][NET] Show IP: 192.0.2.10

A resposta do comando sai no idioma do aparelho; a linha do evento sai em inglês (capítulo 16).

debug off para a transmissão. O log continua sendo gravado com o debug ligado ou desligado.

system admin reset

Gera uma senha aleatória de 8 caracteres para a conta admin (letras maiúsculas e algarismos, sem O, 0, I e 1), grava na hora e marca a troca obrigatória no próximo acesso pela web (capítulo 13). A senha aparece uma única vez:

SIMUT> system admin reset confirm
Senha admin resetada. Nova senha (unica vez):
 K4XW7PQA
Trocar no 1o login via web (forcado).

Se a gravação falhar, o aparelho avisa ERROR: NAO SALVOU: vale so ate reiniciar.: a senha funciona até o próximo reinício. Pelo Bluetooth, o comando é recusado. A recuperação completa está no capítulo 18.

system format, system factory e system https off

Comando O que apaga Depois do reinício
system format confirm O sistema de arquivos inteiro: configuração, contas, histórico, log de eventos, pacote de idioma, temas e certificado. O firmware fica O aparelho volta como novo; sem pacote de idioma, a interface fica em inglês
system factory confirm A configuração: contas, rede, sensores, telemetria e o resto. O histórico e os arquivos ficam Configuração de fábrica. A senha nova do admin não é mostrada: rode system admin reset confirm depois do reinício (capítulo 17)
system https off confirm O certificado e a chave do HTTPS A interface web volta a responder em HTTP (capítulo 9)

Sem rede configurada depois do reinício, o aparelho não abre o AP de configuração sozinho: abra-o com ap (ap) ou grave a rede com system ssid e system pass. O boot também pede a data e a hora: na release, no painel; em todas as imagens, com a linha que cita o time (time). O system format mostra OK: Formatando LittleFS... reboot em seguida. antes de começar; o system factory reinicia sem mensagem; o system https off diz OK: HTTPS desligado. Reiniciando em HTTP..., ou OK: Nenhum certificado presente. Reiniciando... quando não havia certificado.

system ssid e system pass

SIMUT> system ssid MinhaRede
OK: SSID salvo. Use 'reload confirm' para reconectar.
SIMUT> system pass senha-da-rede
OK: Senha salva. Use 'reload confirm' para reconectar.
SIMUT> reload confirm

O nome da rede tem de 1 a 31 caracteres e a senha, até 31, sem caracteres de controle. system pass sem senha grava uma senha vazia, para rede aberta.

system cors

Libera a página do gestor de frota a consultar o aparelho pelo navegador (capítulo 9). A origem é esquema://servidor[:porta], sem barra no fim, com até 64 caracteres; off desliga.

SIMUT> system cors http://coletor.exemplo.com.br:8080
OK: Origem salva. Use 'reload confirm' para aplicar.

Sem argumento, o comando só mostra o uso: system cors vazio não apaga a origem gravada.

ap

Abre o ponto de acesso de configuração na hora e responde com a chave da rede. É, com o item 8 do menu e o gesto no boot da release, o único jeito de abrir o AP: o aparelho não o abre sozinho (capítulo 9).

SIMUT> ap
OK: Modo AP iniciado (WPA2). Senha: K7PX4MRW2A
Conecte-se ao AP e acesse http://192.168.4.1

O nome da rede é o nome do aparelho seguido de _SETUP. O log registra o código 403, AP iniciado, com o contexto 0. Com uma rede configurada, o AP fecha sozinho em 15 minutos, com um reinício; sem rede configurada, fica aberto até alguém gravar uma rede ou reiniciar o aparelho (capítulo 9). Se o AP não abrir, a resposta é ERROR: O modo AP nao iniciou. e o aparelho continua medindo.

time

Acerta o relógio na hora, na hora local do fuso do aparelho. Funciona pelo USB e pelo Bluetooth, e conf time é o mesmo comando. Num aparelho sem rede configurada e com o relógio provisório, o boot termina com uma linha que cita o comando:

Sem rede, relogio provisorio: conf time AAAA-MM-DD HH:MM:SS
SIMUT> conf time 2026-10-01 14:30:00
OK: Hora aplicada (imediato, nao persiste em reboot)
  • A data é conferida como num calendário. O ano vai de 2026 a 2099, e o dia tem de existir no mês. time 2026-02-31 12:00:00 responde ERROR: Data ou hora invalida (ano >= 2026), e o relógio não muda. Um formato errado responde ERROR: Formato invalido. Use: conf time AAAA-MM-DD HH:MM:SS.
  • O acerto não é gravado. Ele vale até o próximo reinício; um aparelho sem rede pede a hora de novo a cada boot.
  • O histórico é corrigido. O primeiro acerto depois do boot corrige a hora dos blocos do histórico que o boot começou, e o log registra o código 13, RTC set manually, com o contexto 2 (capítulo 10).

Até a v2.8.0, o time existia só no console completo, e no console de emergência ele respondia “Comando desconhecido”.

O console completo

air O console completo segue o modelo dos roteadores: modos em camadas, com prompts diferentes, e alterações que ficam na memória até write memory. Ele existe no Air e nas imagens de teste. A lista exaustiva, com todos os apelidos, está em docs/CLI-Manual.md; esta seção mostra a estrutura e os comandos mais úteis, conferidos no código da v2.7.1.

Os modos

Modo Prompt Como entrar Para quê
EXEC SIMUT> É o modo inicial Consultas, debug, language, time, operações de telemetria
Privilegiado SIMUT# enable Gravar, reiniciar, recuperar, operar sensores
Configuração SIMUT(config)# configure terminal (ou config terminal), a partir do privilegiado Alterar a configuração
Sensor SIMUT(config-sensor-N)# sensor <N>, a partir da configuração ou do privilegiado Configurar um slot, sem repetir o número
Comando Efeito
enable Do EXEC ao privilegiado. Não pede senha: quem tem o cabo tem o aparelho
disable Do privilegiado ao EXEC
exit Sobe um nível: do sensor à configuração, da configuração ao privilegiado, do privilegiado ao EXEC
end Da configuração ou do sensor direto ao privilegiado
do <comando> Na configuração ou no sensor, executa um comando do EXEC ou do privilegiado, como do show sensors ou do write memory
? ou help Lista os comandos do modo atual

Um comando fora do seu modo responde com o modo que ele exige, como ERROR: Comando requer modo configuracao. Use 'configure terminal'.. O prefixo conf (ou configure) antes de um comando é aceito e ignorado: conf system name x é o mesmo que system name x.

Gravar: write memory

A maior parte das alterações vale na hora, mas só na memória. Depois de cada uma, o console lembra:

SIMUT(config)# system name laboratorio2
RAM OK. Use 'write memory' para salvar.
SIMUT(config)# do write memory
OK: Config salva no Flash!

write memory grava a configuração, relê os sensores e ajusta o histórico ao conjunto novo de sensores, sem reiniciar. Alterações não gravadas se perdem no próximo reinício.

Gravam por conta própria, sem write memory: system ssid, system pass, wifi ssid, wifi pass, system cors, system admin reset, os comandos air idle e air charger, e as recuperações que reiniciam. O comando time acerta o relógio na hora e não é gravado.

Algumas alterações só valem depois de reload confirm: a porta web, a origem do CORS, a rede Wi-Fi e o nome do aparelho no Bluetooth.

Consultas: show

Valem no EXEC, no privilegiado e na configuração; no modo sensor, use do show ....

Comando O que mostra
show sensors Os slots ativos: GPIOs, tipo, grandezas, nome, ROM, identificação e limites de alarme
show sensor types Os tipos de sensor compilados, com os pinos e as grandezas
show gpio (ou gpio) O mapa dos GPIOs em uso
show system info Como no console de emergência
show net status Como no console de emergência
show system log Como no console de emergência
show storage stats O uso do sistema de arquivos
show metrics Tempo ligado, memória livre e as métricas de rede, telemetria, alarmes, sensores, armazenamento e do núcleo 1
show themes Os temas instalados, com o número e o identificador
SIMUT> show sensors

--- Sensores Configurados ---
 [Slot 00] GPIO=2 | DS18B20  | T     | Freezer
          ROM: 28FF641E0F16047A
          ALARMES: LIGADO  [T: -25.0 .. -15.0]
 [Slot 01] GPIO=4,SDA/5 | BME280   | T+H+P | Sala
          ALARMES: DESL

Sistema e rede

Na configuração (SIMUT(config)#), salvo indicação:

Comando Efeito Faixa
system name <nome> Nome do aparelho, que também dá nome ao AP e ao Bluetooth 1 a 31 caracteres
system timezone <horas> Fuso em horas inteiras, aplicado na hora −12 a +14
system ntp <servidor> Servidor de hora; vazio usa o padrão Até 31 caracteres
ntp on, ntp off Liga ou desliga o acerto por NTP
system history_interval <min> Intervalo de gravação do histórico 1 a 1440 min
system theme <nº ou id> Tema do painel, aplicado na hora Veja show themes
ds18b20 resolution <bits> Resolução dos DS18B20 9 a 12
system ssid <nome>, wifi ssid <nome> Rede Wi-Fi, gravada na hora 1 a 31 caracteres
system pass <senha>, wifi pass <senha> Senha do Wi-Fi, gravada na hora Até 31 caracteres
ip dhcp, ip static Endereço por DHCP ou fixo
ip addr <ipv4>, ip mask <ipv4>, ip gateway <ipv4>, ip dns <ipv4> Os campos do endereço fixo
dns auto, dns manual <ip1> [ip2] DNS pelo DHCP ou manual
web port <porta> Porta do servidor web, depois de reload 1 a 65535
system cors <origem>, system cors off Como no console de emergência
system touch reset confirm release Descarta a calibração do toque e abre o assistente no painel (capítulo 11); vale também no privilegiado

E, no EXEC ou no privilegiado:

Comando Efeito
time AAAA-MM-DD HH:MM:SS Como no console de emergência (time)
language pt, language en Troca o idioma do console, do painel e do log na hora; write memory grava. language sozinho mostra o atual
debug on, debug off Como no console de emergência; aqui, write memory grava o estado

As recuperações system admin reset, system factory, system format e system https off funcionam no privilegiado e na configuração, com confirm, e são recusadas pelo Bluetooth como no console de emergência.

Telemetria: tel

Na configuração:

Comando Efeito Faixa
tel server <endereço> Servidor do coletor Até 63 caracteres
tel port <porta> Porta do coletor 1 a 65535
tel path <caminho> Caminho no coletor, como /api/v1/dados Até 31 caracteres
tel batch <n> Máximo de registros por envio 1 a 250
tel interval <n> Lote mínimo: quantos registros esperam antes de um envio; 0 desliga 0 a 20000
tel crypto on, tel crypto off Liga ou desliga o TLS
tel mode json, tel mode csv, tel mode custom Formato do payload

O texto de help do console completo ainda descreve tel batch com “max 50” e tel interval em milissegundos; valem as faixas acima. Ele também sugere conf sensor ds18b20 resolution, que o console não entende: a forma certa é ds18b20 resolution <bits>. O transporte (HTTP ou MQTT) e os modelos de payload se configuram pela web (capítulo 21).

Operações:

Comando Modo Efeito
tel sync EXEC ou privilegiado Força um envio agora
tel dump EXEC ou privilegiado Mostra no console o próximo payload enviado, uma vez
tel reset Privilegiado Volta o cursor da telemetria: os próximos envios cobrem até 30 dias para trás. Não pede confirm

Linha de alarmes: alarm

Comando Modo Efeito
alarm show EXEC, privilegiado ou configuração Estado, modo, fila, descartes, caminho e modelos
alarm dump EXEC ou privilegiado Mostra no console o próximo envio de alarmes
alarm flush Privilegiado Esvazia a fila sem confirmação do servidor. Não pede confirm
alarm set on, alarm set off Configuração Liga ou desliga a linha de alarmes
alarm set mode json\|csv\|custom Configuração Formato
alarm set qmax <n> Configuração Tamanho da fila, de 1 a 64; de fábrica, 32
alarm set path <caminho> Configuração Caminho no coletor; vazio usa o da telemetria com /alarm
alarm set glob <modelo>, alarm set line <modelo>, alarm set sep <separador> Configuração Modelos do modo custom, sem espaços
SIMUT> alarm show
Alarmes: LIGADO | modo json | fila 0/32 | descartados 0
PATH: (telPath+/alarm)

Os alarm set valem na hora e precisam de write memory para ficar. A linha de alarmes está no capítulo 22.

Sensores: sensor

A forma mais cômoda é o modo sensor: na configuração, sensor <N> entra no slot N, e os comandos seguintes dispensam o prefixo sensor <N>. Fora dele, no privilegiado, use a forma completa, como sensor 3 name Sala.

No modo sensor Forma completa Efeito
create <tipo> sensor <N> create <tipo> Cria o slot do zero: ds18b20, dht22, bme280 ou bmp280, e lista os pinos que ele exige
type <tipo> sensor <N> type <tipo> Troca só o tipo
pin <índice>,<gpio> sensor <N> pin <índice>,<gpio> Liga o pino do sensor a um GPIO de 0 a 15
name <nome> sensor <N> name <nome> Nome, de 1 a 31 caracteres
hwid <id> sensor <N> hwid <id> Identificação, de 1 a 15 caracteres: letras, algarismos, _ e -
active on, active off sensor <N> active on\|off Liga ou desliga o slot; ligar exige o tipo e todos os pinos
alarm on, alarm off sensor <N> alarm on\|off Liga ou desliga os alarmes do slot
tmin <valor>, tmax, hmin, hmax sensor <N> tmin <valor> Limites de temperatura e umidade; tempmin, hummax e afins também valem
pressmin <valor>, pressmax sensor <N> pressmin <valor> Limites de pressão, em hPa
SIMUT(config)# sensor 2
Slot 2 nao configurado. Use 'create <tipo>' para configurar.
Entrando configuracao do sensor — Slot 2 (Unknown)
SIMUT(config-sensor-2)# create dht22
OK: Slot 2: DHT22 — 1 pino(s) necessarios:
  pin[0] = Data (pull-up)
GPIOs disponiveis: 0,1,3,6,7,8,9,10,11,12,13,14,15
Atribua com: sensor 2 pin <idx>,<gpio>
RAM OK. Use 'write memory' para salvar.
SIMUT(config-sensor-2)# pin 0,6
OK: Slot 2 pin[0]=GPIO 6 (Data)
Todos os pinos atribuidos. Proximo: sensor 2 name "<nome>"
RAM OK. Use 'write memory' para salvar.
SIMUT(config-sensor-2)# name Estufa
OK: Slot 2 name=Estufa
RAM OK. Use 'write memory' para salvar.
SIMUT(config-sensor-2)# tmax 30
OK: Slot 2 tmax=30
RAM OK. Use 'write memory' para salvar.
SIMUT(config-sensor-2)# end
SIMUT# write memory
OK: Config salva no Flash!

O console recusa um GPIO que outro slot ativo já usa. Os limites aceitam a faixa física da grandeza: temperatura de −327,68 a 327,66, umidade de 0 a 102,3 e pressão de 0 a 1638,3.

Operações, no privilegiado:

Comando Efeito
sensor scan Procura sensores nos GPIOs e lista o que achou (também no EXEC)
sensor accept <n> Lê o DS18B20 ligado ao GPIO n e o grava no slot de mesmo número, na hora (capítulo 6)
sensor wipe <slot> confirm Recomeça a época do histórico do slot (capítulo 6)
sensor remove <slot> confirm Desliga e limpa o slot
sensor reschema confirm Reescreve o esquema do histórico de hoje a partir dos slots atuais, sem perder registros (capítulo 6)

sensor wipe e sensor remove precisam de write memory para ficar; sensor accept grava na hora, e sensor reschema age no histórico na hora.

Contas: user

Na configuração:

Comando Efeito
user add <nome> <senha> Cria uma conta web com as permissões Painel, Histórico e Calibração
user del <nome> Exclui uma conta; o nome é comparado com maiúsculas e minúsculas; admin não pode ser excluída
user pass <nome> <senha> Troca a senha de uma conta, sem troca obrigatória depois
user perm <nome> <papel> Troca as permissões: admin, operator, viewer, none ou uma máscara como 0x1C03
user pin <nome> <PIN> release Define o PIN de painel de uma conta; off remove
user policy <mín> <teclado> <alfabeto> release Define a política de PIN

As senhas precisam de pelo menos 8 caracteres, com uma letra e um algarismo, e no máximo 64. Os papéis de user perm:

Papel Também aceito Máscara Permissões
admin full 0xFFFF Todas as 13
operator operador 0x0207 Painel, Histórico, Logs e Calibração
viewer leitor 0x0003 Painel e Histórico
none nenhum 0x0000 Nenhuma

A máscara soma os valores das permissões da tabela do capítulo 8. O console não aplica a regra de que ninguém concede o que não tem (capítulo 8): quem está no cabo já pode tudo.

user pin e user policy existem só nas imagens de teste, que têm painel. user pin diz qual conta já usa um PIN repetido, o que o painel nunca diz (ERRO: PIN ja pertence a operador1). user policy 4 3 0 grava tamanho mínimo 4, teclado com 3 caracteres por tecla e só algarismos, e responde quantas contas vão precisar renovar o PIN, como OK: Politica: 4/3/0 - renovar: 2. O tamanho máximo depende do teclado: 16, 12 ou 8 caracteres para o teclado 1, 2 ou 3. A política está no capítulo 8.

Todos os comandos user precisam de write memory para ficar.

O painel pelo console

release Nas imagens de teste, quatro comandos do privilegiado servem para automação e para capturar telas:

Comando Efeito
screen <tag> Abre uma tela do painel direto, como administrador: dash, set, thm, lng, pwd, lic, sts, alm, gra, touchcal, touchsens, offset, usr, clk, pin (referência das telas)
touch sim <X> <Y> Simula um toque no ponto (X de 0 a 319, Y de 0 a 239)
touch hold <X> <Y> [ms] Simula um toque mantido por ms milissegundos (padrão 3500, de 100 a 15000) e depois solta: alcança os gestos de toque longo, como o de 3 s que fixa o cartão de cima, que o touch sim não alcança
show display keypad Mostra o que cada tecla do teclado de PIN embaralhado tem na tela agora

Manutenção

No privilegiado:

Comando Efeito
write memory Grava a configuração
clear log confirm Apaga o log de eventos
reload confirm Reinicia, gravando antes o histórico em memória
ap Abre o AP de configuração

Os comandos do Air

air O Air acrescenta cinco comandos, válidos em qualquer modo:

Comando Efeito
air status Uma linha com o estado do ciclo de hibernação
air hibernate (ou air sleep) Arma o ciclo e começa a hibernar agora; o USB some quando o aparelho dorme
air stop (ou air wake) Cancela o ciclo e volta à operação acordada
air idle <segundos> Tempo sem comando antes de hibernar sozinho, de 10 a 65535 s; de fábrica, 300 s
air charger <gpio> ou air charger off GPIO que fica em nível alto com o carregador ligado; de fábrica, GP17

air idle e air charger gravam na hora, em /config/air.bin, sem write memory. air charger aceita os GPIOs 0 a 22 e 26 a 28 e recusa um GPIO que um sensor ativo ou a alimentação dos sensores (GP16) usam. As respostas desses dois estão sempre em inglês:

SIMUT> air idle 600
OK: air idle set
SIMUT> air charger 17
OK: charger sense on GP17 (now on battery)

Durante um despertar do ciclo, o Air só lê o console USB: air stop digitado pelo Bluetooth nessa hora não tem efeito. Pelo USB, ele funciona em qualquer despertar. O ciclo está no capítulo 19.

air status

SIMUT> air status
Air: phase=0 wake=60s hist=60s backoff=0s idle=300s armed=1 dirty=0 tel=12/10 skip=0 radio=1 chg=0 bat=250 cyc=1830ms wip=1
Campo O que é
phase A fase do ciclo: 0 acordado em operação; 1 aquecendo os sensores; 2 lendo e conectando; 3 decidindo; 4 sem uso; 5 esperando a hora; 6 enviando a telemetria; 7 indo dormir
wake O próximo intervalo de sono, em segundos: o maior entre o intervalo do histórico e a espera da telemetria
hist O intervalo do histórico, em segundos
backoff Quanto falta da espera da telemetria depois de uma falha, em segundos
idle O tempo sem comando antes de hibernar, em segundos; mais curto depois de um ciclo interrompido por um reinício
armed 1 quando o ciclo está armado e sobrevive a reinícios
dirty Quantos boots seguidos retomaram o ciclo depois de um reinício inesperado; zera no primeiro sono bom
tel Registros pendentes da telemetria, seguidos do lote mínimo (tel interval)
skip Despertares que ainda vão pular a telemetria depois de uma falha
radio 1 com o rádio Wi-Fi ligado
chg 1 com o carregador ligado: o Air não hiberna enquanto está no carregador
bat O tamanho de lote que a telemetria ajustou sozinha
cyc A duração do último envio, em milissegundos
wip Quantas vezes o bloco aberto do histórico foi gravado neste boot; o esperado num despertar é 1

Consultado de dentro de um despertar, antes de o registro ser gravado, wip aparece como 0.

Voltar ao sumário

Parte IV

Operar e manter

Capítulo 15

Histórico

Este capítulo explica o que o aparelho grava no histórico, como guarda, quanto cabe e o que acontece quando a memória enche. Mostra também a página Histórico e Logs de ponta a ponta, com o gráfico, o calendário e a exportação em CSV. É para quem opera o aparelho e para quem precisa tirar os dados dele.

O que o aparelho grava

A cada Intervalo Histórico, o aparelho grava um registro. O intervalo vai de 1 min a 1440 min, e o de fábrica é 1 min (capítulo 6).

Cada registro tem:

  • a hora, em segundos;
  • um valor para cada grandeza de cada sensor ativo: temperatura, umidade ou pressão, conforme o tipo do sensor.

O valor gravado é a média das últimas leituras, já com a correção de calibração. É o mesmo valor que o painel e a página mostram naquele instante (Leitura e histórico).

Grandeza Resolução gravada
Temperatura 0,01 °C
Umidade 0,1 %
Pressão 0,1 hPa

Regras do registro:

  • Sensor em erro ou ausente: as grandezas dele entram no registro sem valor, e as dos outros sensores são gravadas normalmente. No gráfico, uma falta mais longa que 3,5 intervalos aparece como um trecho interrompido (O gráfico).
  • Nenhum sensor com valor: o aparelho não grava o registro. O log de eventos registra Histórico pulado: schema não cobre sensor ativo (515) uma vez, e o mesmo código de novo quando a gravação volta.
  • Nenhum sensor ativo: o aparelho não grava e registra Histórico pulado: schema V4 vazio (514).
  • A hora: o aparelho sempre carimba o registro com a hora que tem, seja a do NTP, a de um acerto manual ou a do relógio provisório (capítulo 10).
  • O primeiro registro depois de um reinício não espera o intervalo inteiro, desde que o relógio já esteja acertado (Leitura e histórico).

air No SIMUT Air, o aparelho grava um registro a cada despertar (capítulo 19).

Como o histórico é guardado

O histórico fica no sistema de arquivos do próprio aparelho, na pasta /history:

Arquivo O que é
AAAAMMDD.h5 Um arquivo por dia, como 20260923.h5. A data é a do fuso do aparelho (capítulo 10)
.wip Uma cópia do bloco aberto, que ainda está na RAM

O formato se chama V5. Ele é compacto e se descreve sozinho: cada arquivo começa com uma descrição dos canais gravados, com a grandeza e a escala de cada um. Quem tem o arquivo lê os valores sem precisar saber qual firmware o escreveu.

Blocos

Os registros são agrupados em blocos de até 60. Cada bloco leva o próprio código de verificação (CRC) e o mínimo e o máximo de cada canal. Um bloco corrompido custa só aquele bloco, e não o dia inteiro: com o intervalo de fábrica de 1 min, é 1 h de dados.

O caminho de um registro é este:

  1. O registro entra no bloco aberto, na RAM.
  2. Logo depois, o aparelho copia o bloco aberto inteiro para /history/.wip. Se o painel está sendo tocado ou uma operação pesada está em andamento, a cópia espera e é tentada de novo 2 s depois.
  3. Quando o bloco chega a 60 registros, o aparelho o sela: acrescenta o bloco ao arquivo do dia e apaga o .wip. O log registra Bloco de histórico selado (566), com o número de registros.

O bloco também é selado antes de completar 60 registros quando o dia muda, porque um bloco nunca atravessa dois arquivos, e quando o NTP corrige o relógio (capítulo 10).

Com o intervalo de fábrica, um bloco cobre 1 h. Com intervalos maiores, cobre mais: 60 registros de 10 min são 10 h. A página do histórico busca o bloco aberto à parte, então o gráfico e o CSV chegam sempre ao registro mais recente (De onde vêm os dados).

Figura 159. Legenda: o registro nasce na RAM, é copiado para o .wip na hora e vai para o arquivo do dia quando o bloco sela.

Falta de energia e reinício

Como o bloco aberto é copiado a cada registro, uma falta de energia perde no máximo o último registro. No boot seguinte, o aparelho confere o .wip:

  • Válido e com espaço: o aparelho retoma o bloco de onde parou, e os registros novos continuam nele.
  • Válido e cheio: o aparelho o acrescenta ao arquivo do dia dele.
  • Corrompido: o aparelho o descarta e registra um aviso Snapshot de histórico gravado (567) com contexto −1.

Um reinício pedido, como Salvar e reiniciar, grava o bloco aberto antes de reiniciar. A exceção é a restauração de um backup, que substitui o sistema de arquivos inteiro (O histórico e a atualização de firmware).

Quando o conjunto de sensores muda

Quando você liga, desliga ou troca um sensor e o aparelho reinicia, o arquivo do dia recebe uma descrição nova dos canais, e os registros seguem nele. O que foi gravado antes continua legível com a descrição antiga. O log registra Schema de histórico divergente (568) com o número de canais novo.

Cada canal é identificado pelo slot e pela grandeza, e não pelo ID de hardware do sensor. Veja o efeito disso na página em Nomes dos sensores. Para refazer o arquivo do dia pela configuração atual, use Recompor o histórico agora (capítulo 6).

Capacidade e limpeza automática

O sistema de arquivos tem 1 MiB. Ele guarda o histórico e também a configuração, o log de eventos, os pacotes de idioma, os temas, a calibração e o par de certificados do HTTPS.

Quanto cabe. Medido em 31/07/2026, em arquivos de bancada: 5,38 bytes por registro com 11 canais a um registro por minuto. Isso dá cerca de 7,6 KiB por dia, e 116 dias em 86 % de 1 MiB. O número real depende do seu caso:

  • mais canais ocupam mais espaço por registro;
  • valores que mudam pouco comprimem melhor que valores que oscilam;
  • um intervalo maior grava menos registros por dia e estica a retenção.

Limpeza automática. O aparelho confere a ocupação uma vez por minuto e toda vez que cria o arquivo de um dia novo. Acima de 86 %:

  1. Apaga o arquivo de dia mais antigo, pela data do nome.
  2. Apaga no máximo dois arquivos por vez, para não prender o rádio. Se ainda estiver acima do limite, registra Budget de limite de storage excedido (562) e continua apagando um arquivo a cada 15 s.
  3. Para quando a ocupação volta a 86 % ou menos.

O arquivo do dia corrente nunca é apagado. Se ele for o mais antigo que restou, o aparelho para e registra Pulando arquivo de log ativo (563). O nome do evento fala em log, mas o arquivo em questão é o do histórico.

A página Histórico e Logs

Abra a gaveta de navegação e toque em Histórico e Logs (History & Logs). O endereço é /history, por exemplo http://192.0.2.10/history.

A página tem duas partes:

  • em cima, os gráficos do histórico, sob o título Telemetria (Sensor Telemetry), com o seletor de sensores, o calendário, o gráfico e a exportação;
  • embaixo, Eventos do Sistema (System Event Logs), o log de eventos, descrito no capítulo 16.

Permissões. A página abre com Histórico PERM_HISTORY ou com Logs PERM_LOGS. Os gráficos exigem Histórico. Como a página baixa os arquivos de cada dia, ver os dias anteriores exige também Leitura PERM_FILE_READ (capítulo 8).

A página Histórico e Logs: à esquerda, o seletor de sensores e o calendário; à direita, os mínimos e máximos, o gráfico e os controles de período; embaixo, os eventos do sistema.
Figura 160. A página Histórico e Logs: à esquerda, o seletor de sensores e o calendário; à direita, os mínimos e máximos, o gráfico e os controles de período; embaixo, os eventos do sistema.

Escolher os sensores

O botão Origem: (Sensors) abre a lista dos sensores configurados. Cada linha tem uma caixa de marcar, um ponto com a cor da série no gráfico, o ID de hardware e o nome.

  • Ao abrir a página, só o primeiro sensor da lista vem marcado.
  • Marque outros para compará-los no mesmo gráfico. Cada mudança recarrega o gráfico.
  • Pelo menos um sensor fica marcado: desmarcar o último marca o primeiro de novo.
  • O botão mostra o ID e o nome do sensor quando só um está marcado, e N selecionados quando há mais de um.
  • A escolha não é lembrada: ao recarregar a página, volta só o primeiro sensor.
Figura 161. A lista de sensores aberta. O ponto colorido é a cor da série no gráfico.

O período

O seletor abaixo do gráfico escolhe o tamanho da janela:

Opção Janela
1h 1 hora
6h 6 horas
24h 24 horas, a opção de entrada
7d 7 dias
1M 30 dias
1A 365 dias
MAX Todo o histórico guardado no aparelho

A janela termina na hora atual do aparelho, e não na do computador. As setas dos dois lados do seletor movem a janela um período para trás ou para a frente. A seta para a frente não passa da hora atual.

Acima do gráfico, o título mostra a janela: dd/mm hh:mm - hh:mm quando ela começa e termina no mesmo dia, e dd/mm - dd/mm quando não.

O calendário

O Calendário (Monthly Calendar) mostra um mês. As setas ao lado do nome do mês trocam de mês.

  • Os dias que têm arquivo no aparelho aparecem destacados. Só eles respondem ao toque.
  • Toque num dia destacado para ver aquele dia inteiro, da 0h às 24h, em 24h.
  • Um dia destacado pode ter só parte das horas: o destaque diz que o arquivo existe, não que o dia está completo.
Figura 162. O calendário com os dias que têm dados destacados. O dia tocado fica selecionado, e o gráfico mostra as 24 horas dele.

O gráfico

Eixos. A temperatura usa o eixo da esquerda, em °C. A umidade usa um eixo à direita, em %RH, e a pressão, um segundo eixo à direita, em hPa. Os eixos da direita só aparecem quando há série daquela grandeza.

Cores. Cada sensor tem uma cor quente para a temperatura. A umidade é sempre azul, e a pressão, roxa. Com mais de um sensor, a umidade e a pressão de cada um ganham um tracejado diferente, para que a série não se identifique só pela cor.

Legenda. Com mais de uma série, a legenda aparece no topo do gráfico. Toque num item da legenda para esconder ou mostrar aquela série.

Leitura de um ponto. Passe o mouse sobre o gráfico, ou toque nele no celular. Aparece a data e a hora, dd/mm/aaaa hh:mm:ss, e o valor de cada série naquele instante. Quando o ponto resume vários registros, o valor vem seguido da faixa [mínimo … máximo] daquele trecho.

Lacunas. Um trecho sem registros aparece interrompido, e não ligado por uma reta. O gráfico interrompe a linha quando dois registros seguidos estão separados por mais de 3,5 vezes o Intervalo Histórico, com o mínimo de 90 s.

Mínimos e máximos. Com um só sensor marcado, a faixa acima do gráfico mostra o máximo e o mínimo de cada grandeza na janela, como Max Temp: e Min Temp:, com uma casa decimal. Eles são calculados sobre todos os registros da janela, e não só sobre os pontos desenhados. Com mais de um sensor marcado, a faixa some.

Figura 163. Dois sensores no mesmo gráfico: temperatura no eixo da esquerda, umidade tracejada no da direita, e a legenda no topo.

Baldes: como meses cabem na tela

O gráfico desenha no máximo um ponto por pixel de largura. Para isso, divide a janela em baldes: tantos quantos são os pixels de largura do gráfico, com o mínimo de 300 e o máximo de 1200.

  • Poucos registros: até 1,6 registro por balde, o gráfico desenha cada registro como ele é.
  • Muitos registros: cada balde guarda o mínimo, o máximo e a média dos registros que caíram nele. A linha é a média, e uma faixa sombreada vai do mínimo ao máximo.

Assim, um pico de um minuto num gráfico de um mês continua visível na faixa. O registro mais recente é sempre desenhado com a própria hora.

Figura 164. Uma semana em baldes: a linha é a média de cada balde, e a faixa sombreada vai do mínimo ao máximo. O pico do degelo aparece mesmo resumido.

De onde vêm os dados

A página não pede ao aparelho um gráfico pronto. Ela baixa os arquivos .h5 dos dias da janela e decodifica tudo no navegador. Depois, se a janela chega até os últimos 75 min, ela busca o bloco aberto, que ainda não está em arquivo nenhum.

  • Ordem: do dia mais novo para o mais antigo. Uma barra mostra Arquivos: N/M e os kilobytes recebidos.
  • Cancelar: o botão Cancelar (Cancel), dentro da barra, interrompe a carga. O gráfico mostra o que já chegou, que é a parte mais recente.
  • Falhas: cada arquivo tem até 3 tentativas. Se algum não chega, ou se você cancela, aparece o aviso Parcial: N perdidas, em que N é o número de arquivos que faltaram.
  • Memória da página: um dia fechado não muda, então a página guarda os arquivos que já baixou. Trocar o período ou os sensores não baixa de novo o que ela já tem. O arquivo do dia corrente e o bloco aberto são buscados a cada vez.

Mensagens no lugar do gráfico:

Mensagem Quando aparece
Carregando… Durante a carga
Sem dados. Nenhum registro dos sensores marcados na janela. Escolha outro período ou outro dia no calendário
Erro. A página não conseguiu ler o estado do aparelho antes de começar. Recarregue a página
Conexão perdida. A carga falhou no meio. Confira a rede e toque de novo no período
Figura 165. A carga de um período longo: a barra conta os arquivos baixados, e Cancelar deixa na tela a parte mais recente.

Nomes dos sensores

Os arquivos do histórico não guardam o nome nem o ID de hardware dos sensores. Eles guardam o slot e a grandeza de cada canal. A página rotula os dados de cada slot com o ID e o nome que o slot tem agora.

Consequências:

  • Se você renomeia um sensor ou troca o ID de hardware dele, os dias anteriores aparecem com o nome e o ID novos.
  • Se você troca o sensor físico de um slot, os dados dos dois sensores aparecem como uma série só. Para ver só um deles, escolha a janela pelo período ou pelo calendário.
  • Os dados de um slot que não está mais configurado não aparecem na página, nem no gráfico, nem no CSV. Eles continuam nos arquivos .h5 e podem ser lidos no computador (Ferramentas para o computador).

Fuso do computador

A página mostra as horas no fuso do computador, e o aparelho nomeia os arquivos pelo fuso dele. Use um computador no mesmo fuso do aparelho: com fusos diferentes, o dia do calendário e as horas do gráfico e do CSV não coincidem com os do painel (capítulo 10).

No celular

Na largura de um celular, os dois cartões ficam um sobre o outro: primeiro o seletor e o calendário, depois o gráfico. Toque no gráfico para ler um ponto. O toque não impede a rolagem da página.

Figura 166. A página no celular, com o gráfico abaixo do calendário e a leitura de um ponto aberta pelo toque.

Exportar o histórico em CSV

A exportação leva para um arquivo CSV exatamente a janela e os sensores que estão no gráfico.

  1. Escolha os sensores em Origem:.
  2. Escolha o período, ou toque num dia do calendário, e espere o gráfico carregar.
  3. Toque em ⤓ CSV, abaixo do gráfico.
  4. Espere a caixa Exporting… terminar. Ela mostra a porcentagem, o tempo estimado e quantos dias chegaram (OK) ou falharam (err). O botão Cancelar interrompe a exportação e salva o que já chegou.
  5. O navegador salva o arquivo, e um aviso mostra o número de linhas.

Se você tocar em ⤓ CSV antes de carregar o gráfico, a página avisa Carregue um intervalo no gráfico. Se a janela não tem registros, o aviso é Sem dados neste período.

Enquanto a exportação roda, os controles do gráfico ficam travados. A exportação aproveita os arquivos que o gráfico já baixou e só vai ao aparelho pelo que falta, pelo arquivo do dia corrente e pelo bloco aberto.

Figura 167. A caixa da exportação em andamento. Cancelar salva o CSV com o que já chegou, com _partial no nome.

O arquivo

Situação Nome do arquivo
Um sensor simut_history_s<slot>_<AAAAMMDD>.csv
Vários sensores simut_history_n<quantidade>_<AAAAMMDD>.csv
Exportação cancelada _partial antes da data, como simut_history_s2_partial_20260916.csv

A data no nome é a do começo da janela.

O aviso final diz N linhas. Se você cancelou, diz cancelado: N linhas. Se algum dia falhou, diz com falha: N linhas (K chunks falhos), em que K é o número de dias que não chegaram.

As colunas

O arquivo tem uma linha por grandeza por registro: um DHT22 gera duas linhas por registro, uma de temperatura e uma de umidade.

Coluna Conteúdo
timestamp_iso Data e hora no fuso do computador, em ISO 8601 com o deslocamento, como 2026-09-23T14:05:00-03:00
sensor_id O ID de hardware atual do slot
sensor_name O nome atual do slot, entre aspas duplas. Aspas duplas no nome viram aspas simples
value O valor, com ponto decimal: duas casas para temperatura e umidade, uma para pressão
unit °C, %RH ou hPa

Exemplo, com um DHT22 chamado Câmara fria e um intervalo de 1 min:

timestamp_iso,sensor_id,sensor_name,value,unit
2026-09-23T14:05:00-03:00,camara1,"Câmara fria",4.25,°C
2026-09-23T14:05:00-03:00,camara1,"Câmara fria",81.30,%RH
2026-09-23T14:06:00-03:00,camara1,"Câmara fria",4.31,°C
2026-09-23T14:06:00-03:00,camara1,"Câmara fria",81.20,%RH

Detalhes do formato:

  • As linhas saem em ordem cronológica.
  • Um canal sem valor naquele registro não gera linha.
  • O separador é a vírgula e o decimal é o ponto. Numa planilha em português, importe o arquivo indicando esses dois caracteres.
  • O arquivo começa com a marca de UTF-8 (BOM), para que as planilhas leiam os acentos dos nomes.

Baixar os arquivos .h5

Os arquivos do dia também podem ser baixados um a um, como estão na flash:

  1. Abra a página Arquivos (capítulo 17).
  2. Toque na pasta history.
  3. Toque no nome do arquivo, como 20260923.h5.

Baixar da pasta /history exige Leitura e Histórico.

O arquivo do dia corrente não tem o bloco aberto. Para ter também os últimos minutos, use o CSV. O .wip pode ser baixado, mas é só a cópia do bloco aberto.

Ferramentas para o computador

O repositório do SIMUT traz, em tools/, dois programas em Python 3 que leem os arquivos .h5 sem o aparelho. Os dois usam só a biblioteca padrão do Python.

history_v5.py: de .h5 para CSV

python3 tools/history_v5.py --dump-csv 20260923.h5 --out 20260923.csv
python3 tools/history_v5.py --dump-csv 20260923.h5 --interval 300 > 20260923.csv
  • --interval é o Intervalo Histórico do aparelho em segundos. O padrão, 60, serve para o intervalo de fábrica de 1 min. Com o valor errado, as horas de cada registro saem erradas.
  • A primeira coluna é epoch: a hora em segundos Unix, em UTC.
  • As outras colunas são uma por canal, com a grandeza, um número e a unidade, como temp0 [°C], hum1 [%] e temp8 [°C]. O número é o slot vezes 8 mais o canal: 0 para temperatura, 1 para umidade e 2 para pressão. temp8 é a temperatura do slot 1.
  • Célula vazia quer dizer canal sem valor naquele registro.
  • Bloco corrompido: o programa pula o bloco e avisa na saída de erro, com # skipped chunk at <posição>: <motivo>. A última linha da saída de erro diz quantos registros foram lidos, como # 1440 records.

h5_day_merge.py: juntar duas cópias do mesmo dia

python3 tools/h5_day_merge.py 20260923.h5 copia-do-backup/20260923.h5 copia-do-aparelho/20260923.h5

Junta duas ou mais versões do arquivo do mesmo dia num arquivo só, no computador. Serve, por exemplo, para juntar a cópia do dia que está num backup com a cópia baixada do aparelho depois de uma atualização (O histórico e a atualização de firmware).

  • Copia cada bloco sem alterá-lo e ordena os blocos pela hora.
  • Blocos idênticos entram uma vez só.
  • Recusa arquivos de dias diferentes, arquivos com descrições de canais diferentes e arquivos com mais de uma descrição.
  • Recusa um bloco corrompido, a não ser com --skip-bad.
  • Recusa dois blocos diferentes com a mesma hora de início, a não ser com --on-conflict keep-longer, que fica com o de mais registros.

O gráfico no painel

release

O painel também desenha o histórico de cada sensor, com os mínimos e máximos. Como chegar e o que ele mostra está no capítulo 11. O LCD do alpha não tem gráfico: no alpha e no Air, o histórico se vê pela interface web.

As horas do histórico

O histórico é carimbado com a hora do aparelho, qualquer que seja a fonte dela. Quando o primeiro acerto depois de um boot, pelo NTP ou à mão, encontra o relógio provisório errado, o aparelho corrige a hora dos blocos que aquele boot começou (capítulo 10). Até a v2.8.0, só o acerto pelo NTP corrigia.

O histórico e a atualização de firmware

Uma atualização de firmware reformata o sistema de arquivos, e o histórico inteiro vai junto. Só a configuração principal atravessa a atualização (capítulo 17).

Para não perder o histórico:

  1. Atualize pela página Arquivos. Ela baixa um backup .bkp para o seu computador antes de começar, com todos os arquivos do histórico e o bloco aberto.
  2. Depois da atualização, restaure esse backup logo, pela mesma página.

Códigos do log de eventos

Os eventos do histórico no log (capítulo 16):

Código Evento Quando aparece
510 Registro de histórico salvo Um registro foi gravado. É um evento de rotina: vai para o log só em transições e uma vez por hora (capítulo 16)
514 Histórico pulado: schema V4 vazio Nenhum sensor ativo
515 Histórico pulado: schema não cobre sensor ativo Nenhum sensor deu valor para o registro. O mesmo código, como informação, marca a volta
560 Falha em escrever histórico Uma gravação falhou. Se a falha é ao selar um bloco, o aparelho recusa o registro seguinte e tenta de novo; na quinta falha seguida, desiste do bloco e recomeça num bloco novo
562 Budget de limite de storage excedido A limpeza automática não terminou de uma vez e continua aos poucos
563 Pulando arquivo de log ativo O arquivo mais antigo é o do dia corrente, que não é apagado
566 Bloco de histórico selado Um bloco foi para o arquivo do dia. O contexto é o número de registros. Evento de rotina
567 Snapshot de histórico gravado A cópia do bloco aberto foi gravada; o contexto é o número de registros no bloco. No boot, diz o que foi feito com o .wip: descartado vem como aviso, com contexto −1
568 Schema de histórico divergente O conjunto de sensores mudou e o arquivo do dia ganhou uma descrição nova
569 Histórico legado apagado O boot apagou de /history arquivos que não são do histórico
408, 409, 410 Correção de horas pelo NTP Capítulo 10

A lista completa está no apêndice B.

Voltar ao sumário

Capítulo 16

Log de eventos

O log de eventos é o registro do que o aparelho fez: entradas, mudanças de configuração, falhas de rede e de telemetria, reinícios e travamentos. Este capítulo explica o que entra no log, o que fica de fora, onde lê-lo e como interpretar o registro de um travamento. É para quem opera o aparelho e para quem investiga um problema.

O que é o log de eventos

Cada evento é um registro de 12 bytes gravado na flash, com estes campos:

Campo O que guarda
Data A hora do aparelho no momento do evento, em segundos. Fica vazia quando o relógio ainda não tinha hora
Tempo Há quanto tempo o aparelho estava ligado, em segundos, até cerca de 194 dias
Código O número do evento, como 300 para uma entrada bem-sucedida. São 170 códigos
Contexto Um número que complementa o código, como o número da conta ou uma contagem
Nível A gravidade do evento
Módulo A parte do firmware que registrou o evento
Núcleo Qual dos dois núcleos do processador registrou o evento, 0 ou 1

O registro na flash guarda o código e o contexto, e não um texto. A descrição que você lê na página é o nome do código, que a página pede ao aparelho (Na interface web). O texto completo de cada evento, com detalhes como o nome de um arquivo, só existe no console, no momento em que o evento acontece, e no syslog, e sai em inglês (Onde ler o log).

A lista completa dos 170 códigos está no apêndice B.

Níveis

Nível Sigla O que indica Vai para a flash
Depuração DBG Detalhe para desenvolvimento Nunca
Informação INF Funcionamento normal Sim, com o filtro de rotina (Persistência por transição)
Aviso WRN Algo fora do normal que o aparelho contornou Sim
Erro ERR Uma operação falhou Sim
Fatal FTL O aparelho travou e reiniciou Sempre

Módulos

Módulo Parte do firmware
APP Aplicação: boot, alarmes, gráficos, SIMUT Air
NET Rede: Wi-Fi, IP, NTP, mDNS
TEL Telemetria e linha de alarmes
STO Sistema de arquivos e histórico
WEB Servidor web
CFG Configuração
CLI Console serial e Bluetooth
SENSOR Sensores
HIST Gravação do histórico
SYS Sistema: boot, reinício, memória, autópsia de travamento
DSP Painel e LCD
SEC Segurança: entradas, permissões, mudanças de configuração
OTA Atualização, backup e restauração
I18N Pacote de idioma: o carregamento no boot e os avisos sobre o pacote

O que o log guarda

O log guarda dois arquivos, /system.blog e /system.old.blog, de 800 registros cada. Quando o arquivo atual chega a 800 registros, o aparelho apaga o antigo, renomeia o atual para antigo e começa um novo. O primeiro registro do arquivo novo é Storage rotacionado (22), com contexto 800.

Assim, o log tem sempre entre 800 e 1.600 registros: os mais recentes. O que é mais antigo que isso se perde. Para guardar o log por mais tempo, envie-o a um coletor syslog (capítulo 25).

Persistência por transição

Um aparelho que envia telemetria a cada poucos segundos gastaria o log inteiro em uma hora dizendo que tudo continua bem. Para evitar isso, os eventos de rotina só vão para a flash quando o estado muda.

Os eventos de rotina são agrupados em famílias:

Família Eventos de sucesso Eventos de falha
Telemetria Telemetria enviada (30), MQTT publicado (37), MQTT conectado (35) 31, 32, 33, 36, 547, 543, 544
Linha de alarmes 550, 552 551, 553
Histórico Registro de histórico salvo (510), 566, 567, 513 20, 512, 514, 515, 560, 568
Rede Conectando WiFi (10), IP obtido (14) 11, 525, 528, 523
Busca de redes Varredura WiFi (12) —

As regras:

  1. O primeiro sucesso de cada família depois do boot vai para a flash. É a prova de que aquela parte funciona.
  2. A primeira falha de uma família saudável vai para a flash. As falhas seguintes da mesma família não vão, mesmo que sejam de outro código da família.
  3. O primeiro sucesso depois de uma falha vai para a flash. É o registro da recuperação.
  4. Uma vez por hora, cada família grava mais um registro, de sucesso ou de falha, conforme o estado dela. Um log quieto continua mostrando que a parte está viva.
  5. Uma vez por hora, se algo foi deixado de fora, o aparelho grava Registros de rotina suprimidos (5), com o número de registros suprimidos no contexto.

Tudo o que está fora da tabela vai sempre para a flash, com nível de informação ou acima.

O filtro vale só para a flash. O console, com debug on, e o syslog recebem todos os eventos, inclusive os que ficaram de fora (Onde ler o log).

Figura 168. Legenda: o console vê todos os eventos; a flash guarda as transições e um registro por hora de cada família.

No SIMUT Air

air

No Air, todo despertar é um boot completo, e a sequência de partida gravaria os mesmos oito registros a cada minuto. Por isso, num boot que veio da hibernação, essa sequência não vai para a flash. Sobra um registro por ciclo: Snapshot de histórico gravado (567), com o número de registros do bloco no contexto.

Um boot que não veio da hibernação grava a sequência inteira e o evento Boot frio, não veio da hibernação (412). Num aparelho que deveria estar dormindo, ele indica uma falta de energia ou um reinício. O ciclo do Air está no capítulo 19.

Registros na RAM

Enquanto o painel está sendo tocado ou uma operação pesada está em andamento, o aparelho segura os registros na RAM, até 32, e os grava logo depois. Um reinício nesse intervalo perde esses registros. Se chegarem mais de 32, os excedentes se perdem, e só o console avisa.

Onde ler o log

Onde O que mostra Permissão
Página Histórico e Logs, seção Eventos do Sistema O log inteiro, com filtros e exportação em CSV Logs PERM_LOGS
Console serial, show system log O log inteiro, em texto Acesso ao console (capítulo 14)
Console serial, debug on Cada evento no momento em que acontece, com o texto completo, inclusive os filtrados Acesso ao console (capítulo 14)
Coletor syslog Cada evento com o texto completo, a partir do nível mínimo configurado, inclusive os filtrados Configuração em capítulo 5 e capítulo 25

Na interface web

A seção Eventos do Sistema (System Event Logs) fica embaixo da página Histórico e Logs (capítulo 15). Ela não carrega sozinha: até você pedir, mostra Clique em ‘Carregar’ para exibir os logs.

  1. Toque em Carregar (Load). Uma barra mostra os kilobytes recebidos.
  2. Marque os níveis que quer ver. De entrada, só ERR vem marcado.
  3. Para procurar, digite em Filtrar… (Filter events…). A tabela mostra só as linhas que contêm o texto.
  4. Para ler de novo, toque em Atualizar (Refresh), que substitui Carregar depois da primeira carga.

As caixas de nível:

Caixa Mostra
INF Informação e depuração
WRN Avisos
ERR Erros e registros FTL

A tabela mostra o registro mais recente primeiro, com estas colunas:

Coluna Conteúdo
Data (Date & Time) dd/mm/aaaa hh:mm:ss, no fuso do computador. Sem hora gravada, mostra Boot + e o tempo desde a partida
Tempo (Uptime) Há quanto tempo o aparelho estava ligado: hh:mm:ss, ou Nd hh:mm:ss a partir de um dia
Nível (Level) INF, WRN, ERR ou FTL
Módulo (Module) O módulo, como SEC ou TEL
Descrição (Event Description) O nome do evento, seguido de [ctx: N] quando o contexto não é zero

Os nomes dos eventos vêm do aparelho. Com a página em EN, saem em inglês; em qualquer outro idioma, saem no idioma do pacote instalado — português com acentos num aparelho em pt-BR, espanhol num em es-ES. Um evento que o pacote ainda não conhece — um código que chegou com uma atualização de firmware antes de o pacote ser trocado — aparece em inglês. Só um código que nem o firmware conhece aparece como # e o número.

Se a leitura falha, a tabela mostra Error fetching logs. Isso acontece, por exemplo, quando alguém está usando o painel naquele momento. Espere alguns segundos e toque de novo.

A seção Eventos do Sistema com os três níveis marcados. O registro mais recente fica no topo.
Figura 169. A seção Eventos do Sistema com os três níveis marcados. O registro mais recente fica no topo.
Figura 170. A tabela de eventos no celular, com o filtro de entrada: só erros.

Exportar o log em CSV

  1. Carregue o log com Carregar.
  2. Ajuste as caixas de nível e o Filtrar…: a exportação leva só as linhas que a tabela mostra.
  3. Toque em Exportar CSV (Export CSV).

O navegador salva simut_logs_<AAAAMMDD>.csv, com a data de hoje, e um aviso mostra o número de linhas. Se nenhuma linha passa pelos filtros, o aviso é Sem dados neste período. Sem carregar antes, o aviso é Clique em ‘Carregar’ primeiro.

As colunas:

Coluna Conteúdo
timestamp_iso Data e hora em ISO 8601 com o deslocamento, no fuso do computador. Sem hora gravada, o mesmo Boot + da tabela
level INF, WRN, ERR ou FTL
module O módulo
code O código do evento
message O nome do evento, entre aspas, no mesmo idioma da tabela
context O contexto
uptime_sec O tempo ligado, em segundos

As linhas saem em ordem cronológica, do mais antigo para o mais recente, ao contrário da tabela.

Limpar o log

O botão Limpar (Clear) apaga os dois arquivos do log. Ele exige as permissões Logs e Sistema PERM_SYS_CONFIG.

  1. Toque em Limpar.
  2. Confirme a pergunta Limpar logs?.
  3. A página mostra Logs limpos. e recarrega a tabela.

O log novo começa com um registro de segurança: Config alterada (303), nível WRN, módulo SEC, com o número da conta que limpou no contexto. Limpar o log deixa rastro de quem limpou.

A página mostra Falha ao limpar logs. quando a conta não tem as duas permissões ou tem uma troca de senha pendente. Com o painel em uso, mostra Display em uso. Tente novamente em alguns segundos.

No console

O comando show system log imprime o log inteiro, do registro mais antigo para o mais recente, entre as linhas --- SYSTEM LOG START --- e --- SYSTEM LOG END ---. Cada linha tem este formato:

1790412345 up3h04m   C0 [INF][SEC   ] code=300 ctx=0
Parte Significado
1790412345 A data, em segundos Unix (UTC). 0 quando o relógio não tinha hora
up3h04m O tempo ligado: Ns, NmNNs, NhNNm ou NdNNh
C0 O núcleo
[INF] O nível
[SEC ] O módulo
code=300 ctx=0 O código e o contexto

O show system log não traduz os códigos: use o apêndice B.

Com debug on, o console mostra cada evento no momento em que acontece, inclusive os que o filtro deixa fora da flash, neste formato:

[hh:mm:ss][UP hh:mm:ss][C0][INF][SEC] <nome do evento>: <texto> (<contexto>)

O nome do evento e o texto saem em inglês, qualquer que seja o idioma do aparelho. O : <texto> só aparece quando o evento tem texto, e o (<contexto>) só quando o contexto não é zero. Antes de o relógio ter hora, o primeiro campo é [BOOT+Ns]. O console está no capítulo 14.

Como ler um travamento

Quando o aparelho trava, um vigia de hardware (watchdog) o reinicia. No boot seguinte, o aparelho faz uma autópsia: lê os vestígios que o travamento deixou em registradores que sobrevivem ao reinício e grava o veredito no log como Boot do sistema (1) com nível FTL. O contexto diz qual foi o travamento.

O contexto do veredito

Contexto Nível Veredito
0 INF Reinício forçado de fora do firmware, como a gravação de um firmware pelo picotool. Não é travamento
100 FTL O núcleo 0 parou de dar sinal de vida, e o núcleo 1 reiniciou o aparelho
200 a 229 FTL O núcleo 0 parou dentro de um módulo, e o watchdog de hardware reiniciou o aparelho. O módulo é o contexto menos 200
455 FTL O mesmo, sem o registro do módulo
300 a 322 FTL O núcleo 1 congelou numa fase, e o núcleo 0 reiniciou o aparelho. A fase é o contexto menos 300
400 FTL O núcleo 1 parou por uma exceção de hardware

Uma falta de energia ou o botão de reinício não deixam registro FTL: o log mostra só a sequência normal de boot.

Os registros irmãos

Desde a v2.7.0, o veredito do watchdog de hardware (contexto de 200 a 229, ou 455) vem seguido de mais três registros do mesmo código, gravados em sequência. Eles se distinguem pela faixa do contexto:

Faixa O que diz Como ler
1000 a 1255 O módulo em que o núcleo 1 estava Contexto menos 1000. 1255 quer dizer sem registro
2000 a 2999 Onde estava o servidor web, a posição hp= do console Contexto menos 2000. 2740: o servidor já tinha terminado de atender. 2000: ele atendia, antes de qualquer etapa marcada, ou não tinha atendido nada desde o boot
4000 a 32000 Há quanto tempo o aparelho estava ligado quando travou Contexto menos 4000, em minutos

Os vereditos de contexto 100, de 300 a 322 e 400 não têm registros irmãos.

Até a v2.8.0, a faixa 2000 dizia, errado, a memória livre em KB. As posições são todas menores que 1024, então o registro saía sempre 2000, e não dizia nada.

Os módulos

Os números de módulo das faixas 200 e 1000:

Nº Módulo Nº Módulo Nº Módulo
0 BOOT 10 SAVE_CFG 20 WEB_HIST
1 IDLE 11 LOG_FLASH 21 WEB_SEND
2 WIFI 12 HIST_FLASH 22 WEB_HSCAN
3 WEB_SERVER 13 CORE1_LOCK 23 TEL_COLLECT
4 STORAGE_RD 14 C1_ENDLOCK 24 TEL_BUILD
5 STORAGE_WR 15 C1_RESET 25 TEL_SEND
6 SENSOR 16 C1_LAUNCH 26 STO_MAINT
7 TELEMETRY 17 C1_KILLED 27 HIST_SAMPLE
8 DISPLAY 18 LOOP 28 HIST_WIP
9 CLI 19 WEB_POLL 29 HIST_SEAL

As fases do núcleo 1, da faixa 300: 0 INIT, 1 RESUME_MTX, 2 LOOP_TOP, 3 PARK, 4 TOUCH_RD, 5 TOUCH_HDL, 6 THEME_MTX, 7 DASH_MTX, 8 SNAPSHOT, 9 RENDER, 10 ALARM_FLASH, 11 R_BOOT, 12 R_FULL, 13 R_TOPBAR, 14 R_TOP_PANEL, 15 R_MINMAX, 16 R_BOT_PANEL, 17 R_ALARM, 18 LOOP_TAIL, 19 LOOP_DELAY, 20 W_WFE, 21 UI_GRAPH, 22 UI_SETTINGS.

Um exemplo

O show system log de um aparelho que travou atendendo a interface web:

1790412281 up3h04m   C0 [INF][WEB   ] code=575 ctx=0
         0 up2s      C0 [FTL][SYS   ] code=1 ctx=219
         0 up2s      C0 [FTL][SYS   ] code=1 ctx=1008
         0 up2s      C0 [FTL][SYS   ] code=1 ctx=4184
         0 up2s      C0 [FTL][SYS   ] code=1 ctx=2721

A leitura:

  1. ctx=219: o watchdog de hardware reiniciou o aparelho, com o núcleo 0 parado no módulo 19, WEB_POLL, que atende a interface web.
  2. ctx=1008: o núcleo 1 estava no módulo 8, DISPLAY, desenhando o painel.
  3. ctx=4184: o aparelho estava ligado havia 184 min, 3 h 04 min, quando travou. Isso confere com o up3h04m do último registro antes do travamento.
  4. ctx=2721: o atendimento web estava na posição 721, logo depois de entregar um pedaço da resposta. As posições são marcas no código-fonte (HPOS), e servem a quem for investigar o travamento.

Na página, os mesmos quatro registros aparecem no topo da tabela, em ordem inversa, como Boot do sistema com [ctx: 2721], [ctx: 4184], [ctx: 1008] e [ctx: 219], nível FTL e módulo SYS. Marque ERR para vê-los.

Se o log mostra travamentos repetidos, anote os contextos, exporte o log e siga o capítulo 30.

Eventos que valem acompanhar

Evento O que indica Onde saber mais
Boot do sistema (1) com FTL Um travamento Como ler um travamento
Login bem-sucedido (300) Uma entrada na web, com o número da conta no contexto. O mesmo código, com contexto 0, marca uma saída por Sair Capítulo 13
Falha de login (301) e Acesso não autorizado (302) Tentativas de entrada e acessos recusados Capítulo 8, capítulo 29
Config alterada (303) Uma mudança de configuração, um backup, uma restauração ou uma atualização, com o número da conta no contexto Capítulo 17
Falha de telemetria (31) O coletor não recebeu Capítulo 21
WiFi desconectado (11) A rede caiu Capítulo 9
Conectando WiFi (10) com contexto 2 ou 3 O rádio recusou um pedido de conexão; no contexto 3, recusou três seguidos e o aparelho reiniciou para recuperá-lo Capítulo 9
Evento de toque (200) O toque do painel chegou por outro caminho que não a interrupção. Contexto 1: a interrupção do toque estava desligada no núcleo 1. Contexto 2: um toque só chegou pela consulta à linha do toque. Contexto 3: um toque só chegou pela leitura periódica. Cada um é gravado uma vez por boot Capítulo 30
NTP corrigindo timestamps (408) O relógio foi corrigido e o histórico, ajustado Capítulo 10
Registros de rotina suprimidos (5) Quantos eventos de rotina ficaram fora da flash na última hora Persistência por transição
Boot frio, não veio da hibernação (412) air Uma falta de energia ou reinício num Air Capítulo 19

Voltar ao sumário

Capítulo 17

Atualização, backup e restauração

Este capítulo explica como atualizar o firmware pela interface web, o que sobrevive a uma atualização, como fazer e restaurar um backup e como voltar o aparelho à configuração de fábrica. Descreve também a página Arquivos, onde tudo isso acontece. É para o administrador do aparelho.

A página Arquivos

Abra a gaveta de navegação e toque em Arquivos (Files). O endereço é /files. A página exige a permissão Leitura PERM_FILE_READ e tem o título Sistema de Arquivos (Flash Filesystem).

A página lista o conteúdo do sistema de arquivos do aparelho, pasta por pasta. Acima da lista, uma trilha mostra a pasta atual; toque num nome da trilha para voltar a ela. Na lista, as pastas vêm primeiro, e Subir (Parent) volta à pasta de cima.

  • Para abrir uma pasta, toque no nome dela.
  • Para baixar um arquivo, toque no nome dele.
  • Para ler um arquivo de texto, toque no olho ao lado do nome (Ver um arquivo de texto).
  • Um cadeado no lugar da caixa de marcar indica um arquivo protegido: o firmware o reescreve a cada boot, e ele não pode ser apagado.

Os botões

Cada botão só aparece para a conta que pode usá-lo:

Botão O que faz Quem vê
Baixar (Download) Baixa os arquivos marcados Toda conta que abre a página
Backup Baixa o backup completo, .bkp (Backup) Só o administrador completo
Restaurar (Restore) Restaura um backup (Restauração) Só o administrador completo
Firmware Atualiza o firmware (Atualizar o firmware) Só o administrador completo
Excluir (Delete) Apaga os arquivos marcados Excluir PERM_FILE_DELETE
Enviar (Upload Here) Envia arquivos do computador para a pasta atual Upload PERM_FILE_UPLOAD

O administrador completo é a conta com todas as permissões (capítulo 8).

A página Arquivos na raiz, vista pelo administrador: os seis botões, as pastas e os arquivos. O cadeado marca o README.txt, que não pode ser apagado.
Figura 171. A página Arquivos na raiz, vista pelo administrador: os seis botões, as pastas e os arquivos. O cadeado marca o README.txt, que não pode ser apagado.
Figura 172. A mesma página para uma conta só com Leitura: resta o botão Baixar.

O que há no sistema de arquivos

Caminho O que é Onde está descrito
/history/ O histórico, um arquivo por dia Capítulo 15
/lang/ Os pacotes de idioma, .lng Capítulo 13
/themes/ Temas do painel, .thm Capítulo 11
/web/ Páginas servidas do disco. Em geral, vazia —
/calib.csv A calibração dos sensores Capítulo 6
/cert.pem O certificado da telemetria, quando instalado Capítulo 21
/system.blog e /system.old.blog O log de eventos Capítulo 16
/README.txt Um mapa do sistema de arquivos, escrito pelo firmware —
/config/ A configuração, as contas, o cursor da telemetria e o par HTTPS Não aparece na página

A pasta /config guarda as senhas e as chaves. A página não a lista, e o aparelho recusa baixar, enviar ou apagar qualquer coisa dentro dela.

Baixar

  1. Marque os arquivos.
  2. Toque em Baixar. Com mais de um arquivo, confirme a pergunta Baixar N?.

O navegador baixa um arquivo de cada vez. Baixar da pasta /history exige também a permissão Histórico, e baixar o log de eventos exige também Logs (capítulo 8).

Ver um arquivo de texto

Um arquivo de texto de até 64 KB tem um olho ao lado do nome: .json, .jsonl, .ndjson, .txt, .csv, .tsv, .lng, .thm, .log, .cfg, .conf, .ini, .pem, .crt, .md, .xml, .yml e .yaml. Toque no olho para abrir o arquivo numa janela sobre a página. Ler exige as mesmas permissões que baixar.

A janela abre em Organizado (Organized):

  • JSON aparece indentado. Cada objeto e cada lista de mais de uma linha tem uma marca à esquerda: ▾ quando está aberto, ▸ quando está recolhido. Toque na linha para abrir ou recolher. Recolhido, o bloco ocupa uma linha, com {…} ou […] e o número de itens. A janela abre com os dois primeiros níveis abertos.
  • Um pacote de idioma ou de tema mostra as linhas numeradas, e cada seção (@DICT, @COLORS, ou [nome] num arquivo INI) se recolhe até a seção seguinte. Uma linha que é um JSON inteiro, como a do @WEBDICT, aparece como um bloco.
  • Um arquivo com um JSON por linha (NDJSON) mostra cada linha como um bloco.
  • Qualquer outro texto aparece com as linhas numeradas.

Expandir tudo (Expand all) abre todos os blocos. Recolher tudo (Collapse all) recolhe todos, menos o bloco de fora de um JSON.

Original mostra o texto exatamente como está no arquivo. O organizado só muda os espaços entre as partes do texto: um número continua escrito como está no arquivo. Baixar (Download) baixa o arquivo original.

Um JSON cortado ou com erro também é organizado, pela posição das chaves e dos colchetes, e a janela avisa JSON incompleto ou inválido. Um arquivo que não é texto mostra Este arquivo não é texto: baixe-o para abrir.

Feche a janela com o X ou com a tecla Esc.

Enviar

  1. Abra a pasta de destino.
  2. Toque em Enviar e escolha um ou mais arquivos.
  3. A página mostra Upload concluído. e atualiza a lista.

Um arquivo com o mesmo nome de outro da pasta o substitui. O aparelho recusa um nome de arquivo inválido, um envio maior que o espaço livre e qualquer destino dentro de /config.

Alguns arquivos têm tratamento próprio:

  • calib.csv: o aparelho só aceita o arquivo se a linha VERSION for maior que a do arquivo atual (capítulo 6).
  • Temas, .thm: entram em uso na hora.
  • Pacotes de idioma, .lng: o aparelho só lê o pacote no boot. Reinicie depois de enviar.

Excluir

  1. Marque os arquivos.
  2. Toque em Excluir e confirme a pergunta Excluir N?.
  3. A página mostra Arquivos excluídos.

Se algum arquivo não pôde ser apagado, a página mostra Alguns arquivos não puderam ser excluídos. Com o painel em uso naquele momento, mostra Display em uso. Tente novamente em alguns segundos.

Cada envio e cada exclusão ficam no log de eventos, com o número da conta no contexto. O caminho do arquivo só aparece no console e no syslog (capítulo 16).

Backup

O backup é uma cópia de todos os arquivos do aparelho num único arquivo .bkp: a configuração, as contas, o histórico, o log de eventos, os pacotes de idioma, os temas, a calibração, o cursor da telemetria, o certificado da telemetria e o par do HTTPS.

Proteções do arquivo:

  • um cabeçalho de 40 bytes com um CRC32 próprio;
  • um CRC32 sobre todo o conteúdo;
  • a identidade do chip do aparelho que o gerou. O backup só é restaurado no mesmo aparelho.

Para fazer um backup:

  1. Entre com o administrador completo.
  2. Abra a página Arquivos e toque em Backup.
  3. O navegador salva o arquivo backup_<chip>_<data>.bkp, em que <chip> é a identidade do chip em hexadecimal e <data> é a hora do aparelho em segundos Unix.

A página mostra Download do backup iniciado. Se o painel estiver em uso ou outra operação pesada estiver em andamento, o aparelho recusa o pedido: tente de novo em alguns segundos.

O log de eventos registra cada backup como Config alterada (303), módulo SEC, com o número da conta no contexto.

Restauração

A restauração grava de volta, no aparelho, os arquivos de um backup feito nele. Ela exige o administrador completo.

  1. Abra a página Arquivos e toque em Restaurar.
  2. Escolha o arquivo .bkp. Um arquivo com outra extensão é recusado com Selecione um arquivo .bkp de backup.
  3. A página mostra Etapa 1/3: Validando backup (CRC + chip ID)… e envia o arquivo para conferência, sem gravar nada.
  4. Leia a pergunta de confirmação e toque em OK para seguir.
  5. A página mostra Etapa 2/3: Aplicando restore (pode levar ~15 s)… e envia o arquivo de novo, agora para gravar.
  6. A página mostra Etapa 3/3: Reiniciando dispositivo (~25 s)…, e o aparelho reinicia sozinho.
  7. Quando o aparelho volta, a página abre a entrada. Entre de novo.

O texto da confirmação, com o número de arquivos e o tamanho:

Backup válido — N arquivos (X bytes).

Isto SOBRESCREVE os arquivos atuais do dispositivo (history, configs, sensores, themes).
A configuração de Wi-Fi e a senha de admin do backup serão restauradas.

Prosseguir com a restauração?

Se o aparelho não volta em 90 s, a página mostra Dispositivo offline após 90 s. Verifique conexão e ligue manualmente se necessário.

Figura 173. A confirmação da restauração, depois da validação: o número de arquivos, o tamanho e o aviso do que será sobrescrito.
Figura 174. A última etapa da restauração: a página espera o aparelho voltar e abre a entrada.

O que a restauração faz

  • Cada arquivo do backup substitui o arquivo de mesmo nome. Os arquivos que existem no aparelho e não estão no backup ficam como estão.
  • A configuração volta à do backup, com a rede Wi-Fi, as contas e a senha do administrador daquela data. Se a senha do administrador mudou depois do backup, a antiga volta a valer.
  • O arquivo do dia corrente volta à versão do backup, e o bloco aberto na RAM é descartado. As medições feitas entre o backup e a restauração se perdem (capítulo 15).
  • O aparelho reinicia para ler tudo de novo.
  • O log de eventos registra a restauração como Arquivo enviado (574), módulo OTA, nível WRN, com o resultado no contexto.

Motivos de recusa

Uma recusa aparece como Validação falhou: ou Falha ao aplicar:, seguido do motivo, em inglês:

Motivo O que quer dizer O que fazer
magic invalid O arquivo não é um backup do SIMUT Escolha o arquivo .bkp certo
unsupported schema O backup tem um formato que este firmware não conhece Use um backup feito por este firmware
header CRC mismatch O cabeçalho está corrompido Use outra cópia do backup
payload truncated O arquivo está incompleto Baixe o backup de novo
payload CRC mismatch O conteúdo está corrompido Use outra cópia do backup
chip ID mismatch (backup is from another device) O backup é de outro aparelho Use um backup deste aparelho
invalid path ou path too long Um caminho dentro do backup é inválido Use outra cópia do backup
I/O error A gravação na flash falhou Veja a atenção abaixo
internal error Erro inesperado Tente de novo; se persistir, veja o log de eventos

Atualizar o firmware

Antes de começar

Você precisa de:

  • o arquivo .bin da imagem certa. Cada versão publica três imagens: simut_v<versão>_release.bin, simut_v<versão>_alpha.bin e simut_v<versão>_air.bin. Use a mesma variante que está no aparelho. O .uf2 com o mesmo nome é para a gravação pelo USB (capítulo 3), não para esta página;
  • uma conta de administrador completo;
  • o aparelho ligado numa fonte estável durante cerca de 1,5 min;
  • uma conexão estável entre o computador e o aparelho. Se envios longos pela porta 80 caem na sua rede, use uma porta alternativa do servidor web (capítulo 9).

A variante do aparelho aparece na resposta de /api/status, no campo sys.env, e na de /api/perms, no campo env: release, alpha ou air (capítulo 26).

O que sobrevive e o que se perde

A área onde a imagem nova é recebida é a mesma partição da flash que guarda o sistema de arquivos. Por isso, a atualização reformata o sistema de arquivos. Antes de começar, o aparelho guarda uma cópia da configuração principal numa área separada e a devolve no primeiro boot da imagem nova.

Desde a v2.8.0, essa cópia é gravada logo no início do envio. Se o envio é cortado no meio por uma queda da rede, ou recusado no fim, o aparelho grava a configuração de volta no sistema de arquivos em seguida; se a energia cai no meio do envio, o boot seguinte a devolve a partir da cópia. Nos dois casos se mantém o que a coluna Sobrevive da tabela abaixo lista, e o resto do sistema de arquivos se perde do mesmo jeito (Falta de energia durante a atualização). A cópia serve uma vez: o boot seguinte ao envio a apaga, e um system format também. Até a v2.7.4, a cópia só era gravada no fim do envio e só era lida no boot que segue a aplicação, e um envio interrompido deixava o aparelho com a configuração de fábrica.

Sobrevive Se perde
A rede Wi-Fi e o IP O histórico inteiro
As contas, as senhas e os PINs O log de eventos
A configuração dos sensores e os limites de alarme Os pacotes de idioma: a interface e o painel voltam ao inglês
A telemetria e a linha de alarmes A calibração dos sensores, /calib.csv
O fuso, o NTP e as demais opções das páginas de configuração Os temas enviados e as páginas em /web
A calibração do toque do painel O par do HTTPS: o aparelho volta a atender em HTTP (capítulo 9)
O cursor da telemetria e o certificado /cert.pem
A origem do CORS (capítulo 9)
air As opções do Air: air idle e air charger voltam ao padrão (capítulo 19)

Tudo o que se perde está no backup que a página baixa antes de começar. Restaurá-lo depois da atualização devolve tudo (Depois da atualização).

Passo a passo

  1. Entre com o administrador completo e abra a página Arquivos.
  2. Toque em Firmware. A página mostra o aviso abaixo. Leia e toque em OK.
  3. Escolha o arquivo .bin. Um arquivo com outra extensão é recusado com Selecione um arquivo .bin de firmware.
  4. A página mostra Etapa 1/4: Baixando backup .bkp…. Ela baixa o backup, confere o cabeçalho dele e o salva no seu computador como simut_pre-ota_<número>.bkp.
  5. A página pergunta se deve iniciar a atualização. Confira que o backup está salvo e toque em OK. Se tocar em Cancelar, nada muda no aparelho.
  6. A página mostra Etapa 2/4: Enviando firmware (~30 s)… e envia a imagem. O aparelho grava e confere a imagem.
  7. A página mostra Etapa 3/4: Aplicando firmware…. O aparelho aceita a aplicação e desliga a rede.
  8. A página mostra Etapa 4/4: Aguardando boot (~25 s)… e, 5 s depois, abre a página de entrada. Ela ainda não responde: o aparelho está gravando a imagem.
  9. Espere cerca de 1 min e recarregue a página de entrada.
  10. Entre e confira a versão (Conferir a versão).
  11. Restaure o backup (Depois da atualização).

Não desligue o aparelho entre os passos 6 e 9. O painel acompanha: do passo 6 ao 8 ele mostra a etapa, com Não desligue o aparelho, e, numa recusa, o motivo (capítulo 11).

O aviso do passo 2, na íntegra:

Atualização de firmware via OTA.

A partição de arquivos é REFORMATADA — a área de staging divide a partição com ela.

Só a configuração sobrevive (capturada antes, restaurada depois):
  • Wi-Fi, senha de administrador, telemetria
  • Mapeamento de sensores e limites de alarme

Todo o resto que está no dispositivo se perde:
  • Histórico de leituras (/history)
  • Pacotes de idioma (/lang)
  • Temas customizados (/themes)
  • Calibração de touch (/calib)
  • Arquivos em /web
  • O log de eventos

Um backup .bkp será baixado automaticamente — restaure depois para recuperar tudo.

Prosseguir?

A pergunta do passo 5:

Backup salvo no seu computador.

Iniciar a atualização?
  • Upload do firmware: ~30 s
  • Aplicação + reboot: ~25 s
  • Boot completo: ~25 s

Total: ~80 s. Não desligue o dispositivo durante o processo.
Figura 175. O aviso que abre a atualização: o que sobrevive e o que se perde.
Figura 176. A segunda confirmação, depois de o backup chegar ao computador. Cancelar aqui não muda nada no aparelho.
Figura 177. O envio da imagem. Até a v2.8.x o painel do aparelho ficava parado até o reinício; agora ele mostra a etapa (capítulo 11).
Figura 178. Legenda: as etapas de uma atualização e o que um corte de energia em cada uma custa.

Tempos medidos

Medição Resultado
Envio e conferência da imagem 34,9 a 35,9 s (v2.7.0, 22/09/2026, 6 atualizações)
Da aplicação até o aparelho voltar 52 a 56 s (v2.7.0, 22/09/2026, 6 de 6 atualizações bem-sucedidas)
Interface web fora do ar 48,4 s em média, em 21 atualizações seguidas na bancada, todas bem-sucedidas (agosto de 2026, imagem de 957.500 B)

Os tempos dependem do tamanho da imagem e da rede. Para confirmar uma atualização, não conte com os tempos: confira a versão.

O que o aparelho confere

Quando O que é conferido Se falhar
Antes de tudo A conta é o administrador completo O aparelho recusa com HTTP 403. A página só mostra o botão Firmware ao administrador completo
Antes da etapa 1 O arquivo termina com a assinatura Este .bin não é assinado, e o aparelho só instala imagem assinada. A página não envia o arquivo, e nada muda no aparelho
Etapa 1 O cabeçalho do backup confere com o que o aparelho anunciou Backup corrompido (CRC). Abortado. Nada muda no aparelho
Durante o envio A imagem, com a assinatura, não passa de 1016 KiB (1.040.384 bytes) O envio para no ponto em que passa, e a recusa aparece sem número, como v=undefined. Até a v2.7.4, uma imagem de até 1 MiB só era recusada no fim, como v=5
Fim do envio O tamanho é de pelo menos 100 KiB Recusa, v=4
Fim do envio Os primeiros 256 bytes formam um início de imagem válido para o RP2040, com o CRC que a ROM do chip confere Recusa, v=6
Fim do envio A imagem traz a etiqueta da variante (SIMUT-ENV) igual à do aparelho Recusa, v=7
Fim do envio A assinatura (A assinatura) Recusa, v=8 a v=12
Aplicação A assinatura de novo, sobre a imagem gravada naquele momento HTTP 409, e a imagem é descartada
Primeiro boot O CRC da imagem gravada confere com o da imagem recebida O log registra o erro (Conferir a versão)

Até a v2.8.x, o aparelho aceitava uma imagem sem assinatura e uma sem etiqueta de variante, anterior à etiqueta. Hoje as duas são recusadas com v=8.

Uma recusa aparece como Falha no envio (validação v=N). Cancelled., seguida do motivo de v=6 a v=12. Um arquivo maior que 1016 KiB não chega a ser conferido e aparece como v=undefined.

O .bin do Pico 2 W (simut_vX.Y.Z_releasetwo.bin, desde a v2.11.0), mandado a um Pico W, é recusado com v=6: os primeiros 256 bytes dele não são um início de imagem do RP2040. A página diz A imagem é de outro chip, ou está danificada. O Pico 2 W usa o .bin releasetwo, e o Pico W os outros. Até a v2.11.0, ela não dava motivo para o v=6.

A assinatura

Pelo ar, o aparelho só instala imagem assinada pelo projeto: os .bin das releases no GitHub e as builds do configurador. A assinatura são 241 bytes no fim do arquivo. Ela prova quem gerou a imagem e que nenhum byte mudou depois.

v Motivo O que fazer
8 A imagem não é assinada Use um .bin de release do GitHub ou uma build do configurador. Um build local só entra pelo USB (capítulo 18)
9 A assinatura não confere: o arquivo mudou depois de assinado, ou foi assinado por uma chave em que o aparelho não confia Baixe o .bin de novo, da página da release
10 A chave que assinou foi aposentada Use uma release mais nova
11 A imagem está abaixo do nível de segurança instalado Use a versão instalada ou uma mais nova. Voltar para antes de uma correção de segurança só pelo USB
12 A imagem foi assinada com a chave de bancada, que só as imagens de teste aceitam Use um .bin de release do GitHub

A página confere o fim do arquivo antes do backup: um arquivo sem assinatura é recusado ali, e nada muda no aparelho. As recusas de v=8 a v=12 vêm no fim do envio, quando o sistema de arquivos já foi sobrescrito: restaure o backup.

A primeira versão assinada se instala pelo ar num aparelho na v2.8.x como qualquer outra, porque a v2.8.x não confere assinatura. Dali em diante, o aparelho só aceita imagem assinada. O USB não confere assinatura: o BOOTSEL grava qualquer .uf2.

Conferir a versão

A única prova de uma atualização é o aparelho informar a versão nova. Confira em qualquer um destes lugares:

  • na gaveta de navegação da interface web, abaixo dos itens, como SIMUT 2.7.1;
  • na resposta de /api/status, no campo sys.ver;
  • no console, com show system info.

O log de eventos começa vazio depois da atualização, e os primeiros registros contam o que aconteceu. Marque INF, WRN e ERR para vê-los:

Registro O que quer dizer
Config alterada (303), módulo OTA, nível WRN O boot que se seguiu a uma aplicação
Config alterada (303), módulo OTA, nível INF A imagem gravada foi conferida e está íntegra
Config alterada (303), módulo OTA, nível ERR O CRC da imagem gravada não confere. Grave a imagem de novo pelo USB (capítulo 18)
Figura 179. O log de eventos logo depois de uma atualização: o boot pós-aplicação (WRN) e a conferência da imagem (INF).

Depois da atualização

  1. Entre de novo. A sessão anterior não sobrevive ao reinício.
  2. Se o aparelho usava HTTPS, ele volta em HTTP até o par ser restaurado (capítulo 9).
  3. Restaure o backup simut_pre-ota_<número>.bkp (Restauração). Faça isso logo: as medições entre a atualização e a restauração se perdem.
  4. Depois do reinício da restauração, confira o idioma, o histórico e a calibração dos sensores.

Se preferir não restaurar o backup inteiro, envie só o que faltou pela página Arquivos: o pacote de idioma, publicado junto de cada versão como arquivo .lng, e o calib.csv. Reinicie depois de enviar um pacote de idioma.

Se a aplicação for recusada

Depois de um envio aceito, a página pede a aplicação. Se o aparelho recusar, a página mostra Aplicação recusada (HTTP N)., com o motivo:

HTTP Motivo O que fazer
403 A conta não é o administrador completo Entre com o administrador completo e recomece
409 Não há imagem aceita esperando Recomece a atualização
409, com v no motivo A imagem gravada não confere mais com a assinatura: outro envio começou depois dela. O aparelho a descarta Recomece a atualização
503 O painel estava em uso naquele instante Não reinicie o aparelho: a imagem gravada está esperando. Repita a aplicação pela API, com POST /api/ota/apply e a sessão do administrador (capítulo 26)

Enquanto a imagem espera a aplicação, o sistema de arquivos está fora de uso. Um reinício nesse estado descarta a imagem e o sistema de arquivos. Desde a v2.8.0, o aparelho volta com a configuração guardada no início do envio; até a v2.7.4, voltava com a configuração de fábrica. Nos dois casos, os demais arquivos só voltam pelo backup. O log registra Config alterada (303), módulo OTA, nível WRN; no console, a linha traz o texto Staged update discarded: device rebooted before apply.

Falta de energia durante a atualização

Uma campanha de testes em 11/09/2026 interrompeu atualizações em cada etapa, com um reinício pelo pino RUN no papel de corte de energia. A coluna Configuração mostra o que mudou na v2.8.0 (O que sobrevive e o que se perde):

Etapa interrompida Firmware Configuração Como recuperar
Download do backup Intacto Intacta Nada a fazer
Envio da imagem Intacto, versão antiga Intacta desde a v2.8.0; perdida até a v2.7.4. Os demais arquivos se perdem Restaure o backup. Até a v2.7.4, pegue antes a senha do administrador pelo console USB e configure a rede (capítulo 18)
Entre o envio e a aplicação Intacto, versão antiga Idem Idem
Aplicação, os cerca de 25 s em que a imagem é copiada Corrompido: o aparelho não liga — BOOTSEL e cabo USB (capítulo 18)
Boot da imagem nova Atualizado Intacta Nada a fazer

Em 30/09/2026, na bancada, um envio cortado aos 400 kB e seguido de reinício deixou a v2.7.3 com a configuração de fábrica e a v2.8.0 com a configuração inteira. A linha Entre o envio e a aplicação da v2.8.0 vem da leitura do código e não foi repetida no aparelho.

A aplicação é a única janela em que um corte deixa o aparelho sem firmware. Nas outras etapas, o pior caso é perder os arquivos, que o backup devolve; até a v2.7.4, também a configuração.

Atualização no alpha e no Air

alpha O procedimento é o mesmo, com a imagem simut_v<versão>_alpha.bin.

air O Air só atualiza em M0, o modo acordado, porque em M1 não há servidor web (capítulo 19):

  1. Ligue o carregador no pino configurado, GP17 de fábrica. Com o carregador, o Air fica em M0 enquanto a atualização durar.
  2. Sem carregador, ponha o Air em M0 de outro jeito: ligue-o de novo, ou rode air stop pelo console USB durante um despertar. Cada pedido autenticado da página renova o tempo de ociosidade.
  3. Atualize com a imagem simut_v<versão>_air.bin, como nos passos acima.
  4. Restaure o backup. Sem ele, o air idle volta a 300 s e o air charger volta ao GP17.

Depois do boot da imagem nova, o Air fica em M0 e volta a hibernar sozinho quando o tempo de ociosidade acaba.

Reset de fábrica, formatação e senha do administrador

Três comandos do console serial devolvem o aparelho a um estado conhecido. Eles só funcionam pelo cabo USB: pelo Bluetooth, o aparelho responde ERROR: Comando so pela USB (cabo serial). e registra a tentativa. Cada um pede confirm no fim; sem ele, o aparelho só explica o que o comando faz.

Comando O que apaga O que mantém
system admin reset confirm A senha do administrador, que vira uma senha aleatória de 8 caracteres Todo o resto
system factory confirm A configuração inteira: rede, contas, sensores, alarmes, telemetria Os arquivos: histórico, log, pacotes de idioma, calibração, par do HTTPS
system format confirm Todo o sistema de arquivos, com a configuração e todos os arquivos Só o firmware

air No Air, que tem o console completo, entre antes no modo privilegiado com enable (capítulo 14). Os comandos também estão descritos no capítulo 14.

A senha do administrador

SIMUT> system admin reset confirm
Senha admin resetada. Nova senha (unica vez):
 K7M2QX9A
Trocar no 1o login via web (forcado).
  • A senha nova usa letras maiúsculas e algarismos, sem O, 0, I e 1. O exemplo acima é ilustrativo.
  • Ela é gravada na hora e vale depois de reiniciar.
  • Ela aparece uma única vez. Anote antes de fechar o console.
  • A interface web obriga a trocá-la no primeiro login (capítulo 13).
  • O comando não muda as permissões nem o PIN do painel do administrador.

Se a gravação falhar, o console avisa ERROR: NAO SALVOU: vale so ate reiniciar.: a senha nova vale até o próximo reinício. Rode o comando de novo.

Reset de fábrica

system factory confirm grava a configuração de fábrica e reinicia. Depois dele:

  • o aparelho não tem rede Wi-Fi configurada e não abre o ponto de acesso sozinho: abra-o com o comando ap ou pelo menu do painel (capítulo 9). Na release, o painel pergunta a data e a hora no fim do boot (capítulo 10);
  • só existe a conta admin, com uma senha aleatória;
  • o histórico, o log, os pacotes de idioma, a calibração e o par do HTTPS continuam no sistema de arquivos.

A senha aleatória desse reset não é mostrada. Depois do reinício, rode system admin reset confirm para ter uma senha do administrador.

Formatação

system format confirm reformata o sistema de arquivos inteiro e reinicia. O aparelho volta como novo, mas com o mesmo firmware:

  • a configuração, as contas, o histórico, o log, os pacotes de idioma, a calibração e o par do HTTPS se perdem;
  • no boot seguinte, o aparelho cria a configuração de fábrica e mostra a senha inicial do administrador no console USB, uma única vez, na moldura SEC-003: FACTORY DEFAULTS ATIVADO, seguida de Senha ADMIN inicial: e da senha.

Se você perder essa moldura, rode system admin reset confirm.

A formatação é o caminho para um sistema de arquivos corrompido (capítulo 18). Se você tem um backup, restaure-o depois de configurar a rede.

Voltar ao sumário

Capítulo 18

Recuperação

Este capítulo diz o que fazer quando o aparelho não responde como deveria: a interface web não abre, ninguém sabe a senha, o painel travou, a rede de configuração não funciona, a imagem é a errada, o firmware ficou pela metade ou o sistema de arquivos corrompeu. Cada seção começa pelo sintoma. É para quem está diante do aparelho com um computador e um cabo USB.

Antes de precisar

Quatro coisas tornam qualquer recuperação curta. Tenha-as antes de instalar o aparelho:

  • Um backup recente, o .bkp da página Arquivos (capítulo 17).
  • O .uf2 da versão instalada, publicado junto de cada versão como simut_v<versão>_release.uf2, _alpha.uf2 ou _air.uf2. Guarde também o da versão anterior.
  • A chave da rede de configuração, que é própria de cada aparelho (capítulo 9).
  • Um cabo USB de dados e um programa de terminal serial no computador (capítulo 14).

O console USB é o caminho de maior confiança. Os comandos que devolvem o acesso ao aparelho, system admin reset, system factory, system format e system https off, só funcionam por ele: o Bluetooth os recusa (capítulo 29). No Air, que tem o console completo, entre antes no modo privilegiado com enable.

Por sintoma

Sintoma Seção
O navegador não abre a interface web A interface web não abre
Ninguém sabe a senha do administrador Senha do administrador esquecida
Um PIN esquecido, ou o painel mostra ACESSO BLOQUEADO PIN esquecido e painel bloqueado
A rede <nome>_SETUP não aparece, não aceita a conexão ou não sai do ar A rede de configuração
O aparelho voltou sem rede, sem contas e com outra senha Voltou com a configuração de fábrica
O visor não acende depois de gravar pelo USB Imagem errada
O aparelho não liga depois de uma atualização Firmware pela metade
Erros de gravação, arquivos que somem, histórico que não grava Sistema de arquivos corrompido
air O Air não acorda ou não aparece SIMUT Air

A interface web não abre

Siga a lista na ordem. Cada item descarta uma causa.

  1. air O Air está hibernando? Em M1, o Air não tem servidor web. Ligue o carregador, desligue e ligue a alimentação, ou rode air stop pelo console USB durante um despertar (capítulo 19).
  2. O aparelho está na rede? Pelo console USB, rode show net status. Sem IP, o aparelho não entrou na rede: veja A rede de configuração. Com IP, use exatamente esse endereço no navegador.
  3. HTTP ou HTTPS? Com um par de certificados instalado, o aparelho atende em https://. Tente os dois (capítulo 9).
  4. O HTTPS não responde em nenhum dos dois? Um par em que o certificado e a chave não combinam deixa o servidor web mudo nas duas portas. Pelo console USB, rode system https off confirm. O aparelho apaga o par e reinicia em HTTP.
  5. A página abre, mas a entrada falha? Veja a mensagem (capítulo 13):
    • Bloqueado por Ns. Tentativas excessivas.: espere a contagem terminar;
    • Limite de sessões atingido. Tente mais tarde.: três contas já têm sessão; espere 15 min sem uso de uma delas, ou reinicie o aparelho;
    • Usuário ou senha incorretos.: veja Senha do administrador esquecida.
  6. Entrou, e a página mostra só Access Denied? A conta não tem a permissão Painel (capítulo 13).
  7. As páginas abrem, mas o backup ou a atualização caem no meio? Até a v2.10.0, isso acontecia com outra página do aparelho aberta no navegador: feche as outras abas do aparelho e tente de novo. A porta do servidor web não faz diferença.

Senha do administrador esquecida

A senha da web do administrador só se recupera pelo console USB. Ninguém a lê de volta: o aparelho gera outra.

  1. Ligue o computador ao aparelho pelo cabo USB e abra o console (capítulo 14).
  2. air No Air, rode enable.
  3. Rode system admin reset confirm.
  4. Anote a senha de 8 caracteres que aparece depois de Nova senha (unica vez):. Ela não aparece de novo.
  5. Entre na interface web com a conta admin e essa senha.
  6. Troque a senha na tela que abre (capítulo 13).

A senha nova é gravada na hora e vale também depois de reiniciar. O comando não mexe nas outras contas, nas permissões nem no PIN do painel (capítulo 17).

PIN esquecido e painel bloqueado

release

Situação O que fazer
Uma pessoa esqueceu o PIN Um administrador define outro pela página Usuários, botão PIN (capítulo 8)
O admin esqueceu o próprio PIN O admin define outro pela mesma página. Sem a senha da web, recupere-a antes (Senha do administrador esquecida)
Uma conta errou o PIN seis vezes e ficou bloqueada no painel Reinicie o aparelho, ou identifique-se com outra conta
O painel mostra ACESSO BLOQUEADO e Reinicialização requerida Vinte tentativas erradas somadas travaram o painel. Reinicie o aparelho

Para reiniciar sem tocar no painel:

  • desligue e ligue a alimentação;
  • pelo console USB, rode reload confirm;
  • pela API, com a operação de reinício de /api/action (capítulo 26).

As contagens de erro ficam só na memória, e o reinício zera todas. A interface web não é afetada por nenhum bloqueio do painel. Os detalhes dos bloqueios estão no capítulo 8.

A rede de configuração

release alpha

O que é a rede <nome>_SETUP, quando ela abre e como sair dela estão no capítulo 9. Esta seção trata dos problemas.

O aparelho não entra na rede

O AP não abre sozinho: nem num aparelho sem rede configurada, nem quando a rede cai. Abra-o:

  • pelo console USB ou Bluetooth, com o comando ap. A resposta traz a chave: OK: Modo AP iniciado (WPA2). Senha: ...;
  • release pelo painel, no item 8 do menu de configurações, com a permissão Rede no painel (capítulo 11);
  • release segurando a tela durante o boot, quando o painel pede Mantenha a tela pressionada: Modo AP… (capítulo 11).

Se o console mostrar [AP] FAILED to start, o AP não subiu, e o log registra AP iniciado (15) com contexto −1. A causa mais comum é um nome de aparelho longo demais: o nome da rede é o nome do aparelho com _SETUP, e o total não pode passar de 32 caracteres. Encurte o nome para até 26 caracteres (capítulo 9).

O celular vê a rede, mas não conecta

  1. Confira a chave. Ela tem 10 caracteres, maiúsculas e algarismos, sem O, 0, I e 1. Leia-a no console USB, na linha [AP] PSK :, na resposta do comando ap, na tela de boot do painel ou no LCD do alpha.
  2. Confira a versão. Até a v2.7.0, um AP aberto enquanto o aparelho procurava uma rede inexistente ficava visível e não aceitava conexões. A v2.7.1 corrigiu isso. Numa versão anterior, desligue e ligue o aparelho e abra o AP de novo.
  3. Abra o endereço certo. Com o celular na rede, abra http://192.168.4.1. Um AP aberto com o aparelho em operação mantém o protocolo do servidor web: com HTTPS instalado, use https://192.168.4.1 (capítulo 9).

A rede configurada está errada

Sintoma: show net status não mostra IP, e o log de eventos repete as tentativas da escada de reconexão. A rede configurada está errada ou fora de alcance. O aparelho continua medindo e tentando a rede, e não abre o AP sozinho. Da v2.7.1 à v2.8.0, um aparelho que nunca tinha obtido IP desde que ligou voltava sozinho para o AP, na primeira dormência da escada, cerca de 6 a 7 min depois de ligar (capítulo 9).

Corrija a rede por um destes caminhos:

  • Pelo AP: abra-o (O aparelho não entra na rede), conecte-se à rede <nome>_SETUP, abra http://192.168.4.1, entre com uma conta que tenha a permissão Rede e grave a rede certa na página Rede (capítulo 9).

  • Pelo console USB, na release e no alpha:

    SIMUT> system ssid MinhaRede
    SIMUT> system pass <senha do Wi-Fi>
    SIMUT> reload confirm

    Os dois primeiros comandos gravam na hora. O nome e a senha têm até 31 caracteres.

O AP não sai do ar

Um AP aberto no boot, pelo gesto no painel, ou aberto num aparelho sem rede configurada, fica aberto até alguém gravar uma rede ou reiniciar o aparelho. O painel mostra AP Ativo! Reinicie a placa para sair. Grave a rede pelo AP ou pelo console e reinicie.

Com uma rede configurada, um AP aberto com o aparelho em operação fecha sozinho depois de 15 min, e o aparelho reinicia para tentar a rede de novo (capítulo 9).

air No Air, o AP só abre pelo comando ap. Configure a rede dele pelo console (SIMUT Air).

Voltou com a configuração de fábrica

Sintoma: o aparelho liga sem rede Wi-Fi, e a senha do administrador não funciona. Na release, o painel pergunta a data e a hora no fim do boot, porque não há rede configurada; em todas as imagens, o console escreve Sem rede, relogio provisorio: ... (capítulo 10). Da v2.7.1 à v2.8.0, a release e o alpha abriam a rede de configuração sozinhos nesse caso.

Causas possíveis:

  • uma atualização interrompida no envio da imagem, ou recusada, seguida de um reinício, num aparelho com a v2.7.4 ou anterior. Desde a v2.8.0, a configuração volta nesse caso, e só os arquivos se perdem (capítulo 17);
  • o sistema de arquivos não montou no boot, e o aparelho o reformatou;
  • alguém rodou system factory ou system format (capítulo 17);
  • o firmware foi gravado depois de apagar a flash inteira.

Para recuperar:

  1. Pegue a senha do administrador pelo console USB. No boot que cria a configuração de fábrica, o console mostra a senha inicial numa moldura:

    ==============================================
     SEC-003: FACTORY DEFAULTS ATIVADO
     Senha ADMIN inicial: <8 caracteres>
     Trocar no primeiro login (forcado).
    ==============================================

    Se você não viu a moldura, rode system admin reset confirm (Senha do administrador esquecida).

  2. Configure a rede. Pelo AP, aberto com ap ou pelo menu do painel, ou pelo console (A rede configurada está errada).

  3. Entre na interface web com admin e a senha, e troque a senha.

  4. Restaure o último backup (capítulo 17). Ele devolve a configuração, as contas, o histórico e os demais arquivos da data do backup.

Sem backup, configure o aparelho de novo a partir do capítulo 4.

Imagem errada

Cada placa usa uma imagem: release para o painel de toque, alpha para o LCD 16×2, air para o SIMUT Air.

  • Pela página Arquivos, o aparelho recusa uma imagem de outra variante com v=7 e uma sem assinatura com v=8 (capítulo 17). A recusa reformata o sistema de arquivos: restaure o backup antes de reiniciar.
  • Pelo USB, o modo BOOTSEL grava qualquer .uf2, assinado ou não: é o caminho de um build local até um aparelho. Uma imagem de outra variante não aciona o visor da sua placa, e a imagem do Air hiberna depois de 5 min sem uso.

Para saber qual imagem está no aparelho, consulte /api/status (campo sys.env) ou /api/perms (campo env).

Para corrigir, grave o .uf2 certo pelo BOOTSEL (Gravar pelo BOOTSEL). A gravação de um .uf2 substitui só o firmware: a configuração e os arquivos continuam lá.

Firmware pela metade

Sintoma: depois de uma atualização, o aparelho não volta. O console USB não aparece no computador, a rede não responde, o painel fica apagado.

A causa é uma interrupção nos cerca de 25 s da aplicação, quando a imagem nova é copiada sobre a antiga (capítulo 17). O espaço do firmware ficou pela metade, e não há o que executar. O modo BOOTSEL fica na ROM do chip e não pode ser apagado: o aparelho sempre se recupera por ele, mas é preciso estar diante dele com um cabo USB.

Grave pelo BOOTSEL o .uf2 da versão que você estava instalando (Gravar pelo BOOTSEL).

Gravar pelo BOOTSEL

O BOOTSEL é o modo de gravação da ROM do RP2040. Ele não depende do firmware instalado.

Entrar no BOOTSEL

Pelo botão, sempre funciona:

  1. Desligue o cabo USB do Pico W.
  2. Segure o botão BOOTSEL, o único botão do Pico W.
  3. Ligue o cabo USB com o botão segurado.
  4. Solte o botão.

O computador mostra uma unidade de disco chamada RPI-RP2. No Linux, lsusb lista a placa como 2e8a:0003.

Figura 180. O botão BOOTSEL do Pico W, segurado enquanto o cabo é ligado, e a unidade RPI-RP2 que aparece no computador.

Pela porta serial a 1200 bps, sem abrir a caixa: funciona quando o firmware roda e o console USB aparece no computador, mas o aparelho não responde direito. Abra a porta serial a 1200 bps e feche-a: o aparelho reinicia em BOOTSEL.

import serial, time
s = serial.Serial('/dev/ttyACM0', 1200, timeout=0.5)
time.sleep(0.1)
s.close()

Troque /dev/ttyACM0 pela porta do aparelho no seu computador. Esse caminho não funciona com o firmware pela metade, nem com o Air dormindo, porque nos dois casos o console USB não existe.

Gravar

Arrastando o arquivo: copie o .uf2 para a unidade RPI-RP2. O Pico W grava e reinicia sozinho.

Com o picotool:

picotool info
picotool load -x simut_v2.7.1_release.uf2

O picotool info confirma que o aparelho está em BOOTSEL. O -x reinicia o aparelho depois de gravar. Espere cerca de 30 s e confira a versão com show system info no console.

Apagar a flash inteira

Se, depois de gravar, o aparelho se comportar de forma estranha, apague a flash inteira e grave de novo:

picotool erase
picotool load -x simut_v2.7.1_release.uf2

O picotool erase só funciona em BOOTSEL. Ele apaga o firmware, a configuração, a cópia guardada pela atualização e todos os arquivos. O aparelho volta como novo: siga Voltou com a configuração de fábrica.

Sistema de arquivos corrompido

O aparelho se protege sozinho de boa parte das corrupções:

O que corrompeu O que o aparelho faz
O arquivo da configuração Usa a cópia de segurança /config/system.bak. Com as duas corrompidas, volta à configuração de fábrica
Um bloco do histórico Pula aquele bloco: perde-se no máximo o bloco, e não o dia (capítulo 15)
A cópia do bloco aberto, .wip Descarta a cópia no boot (capítulo 15)
O sistema de arquivos inteiro, que não monta no boot Reformata e volta à configuração de fábrica (Voltou com a configuração de fábrica)

Se o aparelho funciona, mas o log mostra Falha no storage (20) ou Falha em escrever histórico (560) repetidos, ou arquivos somem e voltam:

  1. Baixe o que puder pela página Arquivos, a começar pelo histórico, e faça um backup se a página deixar (capítulo 17).
  2. Pelo console USB, rode system format confirm. O aparelho reformata o sistema de arquivos e reinicia com a configuração de fábrica.
  3. Siga Voltou com a configuração de fábrica: pegue a senha, configure a rede e restaure o backup.

Se a formatação não resolver, apague a flash inteira pelo BOOTSEL e grave o firmware de novo (Apagar a flash inteira).

SIMUT Air

air

O Air passa a maior parte do tempo dormindo, e dormindo ele some do USB. Para qualquer recuperação, traga-o para M0, o modo acordado (capítulo 19):

  • Com o carregador: ligue o carregador no pino configurado, GP17 de fábrica. O Air sobe em M0 no despertar seguinte e fica acordado enquanto o carregador estiver ligado.
  • Desligando e ligando: um boot pela alimentação é um boot limpo, e o Air fica em M0 pelo tempo de ociosidade inteiro, 300 s de fábrica.
  • Pelo console USB, durante um despertar: rode air stop enquanto o console aparece, nos segundos em que o Air está acordado. Pelo Bluetooth, air stop não funciona em M1.

Configurar a rede do Air pelo console completo:

SIMUT> enable
SIMUT# configure terminal
SIMUT(config)# wifi ssid MinhaRede
SIMUT(config)# wifi pass <senha do Wi-Fi>
SIMUT(config)# end
SIMUT# reload confirm

Os comandos wifi ssid e wifi pass gravam na hora. O modo de configuração do console está no capítulo 14.

O Air não acordou. Um único sono nunca terminou num teste longo em 10/09/2026, depois de 119 ciclos normais. Desde então, um vigia de hardware cobre o despertar e reinicia o aparelho se ele travar ali. Se ainda assim o Air ficar mudo por mais que um período de despertar, desligue e ligue a alimentação. No boot seguinte, o log registra Wake anterior do Air não completou (414) quando o despertar anterior não chegou ao fim, e Boot frio, não veio da hibernação (412). Guarde esse log e relate o caso (capítulo 19).

O Air fica acordado e não hiberna. Veja capítulo 19.

Voltar ao sumário

Capítulo 19

SIMUT Air

O SIMUT Air é a imagem do SIMUT para funcionar com bateria, num lugar sem tomada e sem ninguém por perto: ele acorda pelo relógio, lê os sensores, grava a leitura e volta a dormir. Este capítulo explica os dois modos do Air, o ciclo de hibernação, a telemetria a bateria, os tempos medidos, o que não existe nele e como instalá-lo. É para quem vai instalar e operar um Air.

air

O que é o Air, e por que ele é experimental

O Air é o mesmo firmware das outras imagens, sem painel, sem LCD e sem buzzer, com um ciclo de hibernação acrescentado. Ele roda num Pico W comum e é publicado como simut_v<versão>_air.uf2 e simut_v<versão>_air.bin.

Os dois modos

M0, acordado M1, o ciclo
Para que serve Configurar, consultar, atualizar Medir com o menor consumo
Sensores e histórico Sim, no Intervalo Histórico Sim, uma leitura por despertar
Rádio Wi-Fi Ligado Só nos despertares de telemetria
Interface web e API Sim Não
Bluetooth Sim Não
Console USB Sim, o console completo Só durante os poucos segundos de cada despertar
Alarmes e linha de alarmes Sim Não (Alarmes no Air)
USB no computador Presente Some durante o sono e volta a cada despertar

Entrar em M1

O Air passa de M0 para M1 de dois jeitos:

  • Pelo comando air hibernate, ou air sleep, no console. O console responde Entrando em hibernacao (SIMUT Air)....
  • Pela ociosidade: depois de air idle segundos sem atividade, 300 s de fábrica, e sem o carregador ligado (O tempo de ociosidade).

Os dois caminhos gravam na flash que o ciclo está armado, e o air status passa a mostrar armed=1. Antes de dormir, o Air grava o bloco aberto do histórico e o cursor da telemetria.

Sair de M1

Como O que acontece
air stop, ou air wake, no console USB durante um despertar O Air volta a M0, liga o rádio e a interface web, e desarma o ciclo na flash. O console responde Hibernacao cancelada. Voltando ao modo operacional (M0)...
O carregador ligado, lido num despertar Aquele boot sobe em M0 completo. O ciclo continua armado: ao desligar o carregador, o Air volta a dormir quando o tempo de ociosidade acaba
Um boot limpo: alimentação, pino RUN, reload, atualização M0 pelo tempo de ociosidade inteiro, para quem está diante do aparelho. Com o ciclo armado, o Air volta a dormir sozinho depois
Um reinício pelo vigia (watchdog) com o ciclo armado M0 por só 10 s, e volta ao ciclo
Três reinícios pelo vigia seguidos O Air fica em M0 pelo tempo de ociosidade inteiro, para que alguém consiga entrar, e registra Ciclo Air retido em M0 (411), com o número de reinícios no contexto

Pelo Bluetooth, air stop não funciona em M1: durante um despertar, o Air só atende o console USB. Pelo Bluetooth, use o carregador para trazer o Air a M0.

Figura 181. Legenda: como o Air entra e sai do ciclo de hibernação.

O ciclo de hibernação

Em M1, cada despertar é um boot completo do processador. O Air dorme pelo alarme do relógio de tempo real do RP2040 e, ao acordar, percorre estas fases:

  1. Aquecimento: espera 0,4 s com os sensores alimentados. O GP16, que alimenta os sensores, já sobe no começo do boot (O GP16).
  2. Amostragem: lê os sensores sem intervalo entre as leituras, até cada sensor juntar as 10 leituras da média, ou até 30 s. Num despertar de telemetria, conecta o Wi-Fi ao mesmo tempo.
  3. Decisão: grava o registro no histórico, sempre. É a razão de existir do despertar. Aproveita para aplicar a limpeza automática do histórico, com até 4 arquivos por despertar (capítulo 15).
  4. Conexão: só num despertar de telemetria com o Wi-Fi de pé. Espera o enlace até 30 s; não espera o NTP.
  5. Envio: esvazia a fila da telemetria, lote atrás de lote, até acabar, até o coletor falhar, até o Wi-Fi cair ou até o tempo do despertar acabar.
  6. Sono: desliga o rádio e a alimentação dos sensores, arma o alarme e dorme.

O Air dorme o Intervalo Histórico menos o tempo que ficou acordado, para que o período de despertar a despertar seja o intervalo configurado. O sono mínimo é de 5 s. Se a espera da telemetria depois de uma falha for maior, ele dorme pela espera.

Figura 182. Legenda: as fases de um despertar. O rádio só liga nos despertares de telemetria.

O limite de 24 h

O alarme do relógio do RP2040 é uma hora do dia. Um sono de 24 h inteiras cairia na hora atual, então o Air dorme no máximo 1 s a menos que 24 h. Um sono pedido maior que isso é encurtado, e o Air registra Sono limitado a menos de 24 h (alarme é por hora do dia) (413), com os minutos pedidos no contexto. Isso acontece com o Intervalo Histórico em 1440 min, o valor máximo, no primeiro sono depois de M0: nos despertares seguintes, o tempo acordado já é descontado do sono.

O relógio através do sono

Nos despertares sem rádio não há NTP: a hora que o histórico grava é a que o Air reconstrói. Desde a v2.7.2, o Air carrega o relógio através do sono, com erro de cerca de ±0,09 s por despertar (de −0,085 a +0,030 s em 10 despertares, medido em 23/09/2026). Na v2.7.1, a hora perde até cerca de 1 s por despertar até o próximo acerto por NTP. Os detalhes estão no capítulo 10.

O tempo de ociosidade

Em M0, o Air conta o tempo sem atividade e hiberna quando ele passa de air idle segundos, 300 s de fábrica.

SIMUT> air idle 600
OK: air idle set

A faixa é de 10 a 65535 s. Fora dela, o console responde ERROR: air idle <10..65535> (seconds) e não muda nada. O valor fica gravado em /config/air.bin.

O que renova a contagem:

Atividade Renova?
Qualquer comando no console, USB ou Bluetooth Sim
Um pedido à interface web ou à API com uma sessão válida Sim
Uma entrada bem-sucedida na interface web Sim
Uma leitura de /metrics com conta e senha válidas (capítulo 24) Sim
Uma leitura de /api/status?quiet=1 Não, de propósito: é para o gestor de frota consultar sem manter o Air acordado
A página de entrada, antes de entrar Só três vezes por boot. Uma entrada bem-sucedida devolve as três
Qualquer pedido sem sessão válida Não
O carregador ligado Sim, continuamente

O carregador

O Air lê num pino se o carregador está ligado. Um divisor de tensão leva os 5 V do carregador ao nível lógico do pino, que fica em nível alto enquanto o carregador está ligado. De fábrica, o pino é o GP17.

Com o carregador ligado, não há bateria a poupar:

  • em M0, a ociosidade não conta, e o Air fica acordado;
  • um despertar que encontra o carregador sobe M0 completo, com interface web e Bluetooth;
  • o ciclo continua armado: ao desligar o carregador, o Air volta a dormir quando o tempo de ociosidade acaba.

O Air só detecta a presença da fonte. Ele não mede a corrente de carga nem a tensão da bateria.

Para mudar o pino:

SIMUT> air charger 17
OK: charger sense on GP17 (now on battery)
SIMUT> air charger off
OK: charger sense off
  • Aceita GP0 a GP22 e GP26 a GP28. Os pinos GP23, GP24, GP25 e GP29 são do rádio do Pico W e são recusados com ERROR: air charger <0..22|26..28|off>.
  • Recusa um pino já usado pela alimentação dos sensores ou por um sensor ativo, com ERROR: GP em uso (alimentacao de sensor ou sensor ativo).
  • off desliga a leitura: o Air passa a hibernar mesmo ligado a uma fonte.
  • O valor fica gravado em /config/air.bin.

O GP16: acordado e alimentação dos sensores

O Air põe o GP16 em nível alto durante todo o tempo em que está acordado, do começo do boot até a entrada no sono, e em nível baixo enquanto dorme. Esse pino serve para duas coisas:

  • Alimentar os sensores só quando preciso: ligue a alimentação dos sensores por uma chave do lado positivo, como um MOSFET de canal P ou o pino de habilitação de um regulador de 3,3 V, comandada pelo GP16. Não alimente os sensores direto do GP16: um pino fornece pouca corrente.
  • Saber se o Air está acordado: um analisador lógico ou um LED com resistor no GP16 mostra cada despertar.

O LED da placa não serve para isso: no Pico W, ele é ligado pelo chip do rádio, e o Air só o acende quando o rádio está de pé.

O esquema de ligação está no capítulo 2.

A telemetria a bateria

O rádio é a coisa mais cara que um despertar pode fazer. Por isso, o Air decide no começo de cada despertar se liga o rádio, pela quantidade de registros esperando, e não pelo relógio:

  • O Lote mínimo (t_int) conta registros, não tempo (capítulo 21). O rádio liga quando os registros pendentes, contando o que o despertar vai gravar, chegam ao Lote mínimo. Com o Lote mínimo em N e todos os envios bem-sucedidos, o rádio liga uma vez a cada N despertares.
  • Lote mínimo em 0 desliga a telemetria: o rádio nunca liga em M1.
  • O Lote máximo (t_bat) é o teto de registros por envio. A memória livre pode reduzir o lote abaixo dele: num Air em M0, com t_bat=250, os lotes saíram com cerca de 190 registros (medido em 23/09/2026). Uma fila grande sai em vários lotes no mesmo despertar, até o tempo dele acabar (capítulo 21).
  • Um envio que falha reserva 5 despertares de silêncio: nos 5 seguintes, o rádio não liga, mesmo com registros esperando. Sem isso, com o coletor fora do ar, o rádio ligaria em todo despertar e gastaria a bateria sem ninguém para receber.
  • Uma rede que não aparece não prende o despertar: depois de duas tentativas de conexão, o Air desiste naquele despertar, grava o registro e dorme. O despertar seguinte tenta de novo.

Os registros esperam na flash, e o histórico guarda meses deles (capítulo 15). O que não sai num despertar sai num dos seguintes.

Desde a v2.7.2, cada lote leva só registros inteiros, e o cursor avança só até o último registro que foi no corpo (capítulo 21).

Tempos medidos e consumo

Medido em bancada em 08/09/2026, na v2.4.1-beta, com o Intervalo Histórico de 1 min e um DS18B20 a 12 bits:

Medição Resultado
Despertar de leitura, do boot até a decisão 9,31 s, dos quais 6,83 s são a conversão do sensor
Despertar de telemetria cerca de 12,7 s
Dormindo, por ciclo cerca de 51 s
Período real 60,5 a 60,6 s, para 60 s configurados
Fração do tempo acordado cerca de 13 %

Para onde vai o tempo. A maior parte de um despertar é a média de 10 leituras enchendo do zero, e o DS18B20 leva 750 ms por conversão. O firmware espera 750 ms por conversão qualquer que seja a Resolução DS18B20: baixar a resolução hoje reduz a precisão e não encurta o despertar (capítulo 6).

Consumo, como conta. Com as correntes de referência de bancada de 25 mA acordado lendo, 80 mA transmitindo e 2 mA dormindo, com uma leitura por minuto e telemetria a cada quinto despertar, a conta dá cerca de 8,2 mA de média, ou 17 dias numa célula 18650 de 3400 mAh. É aritmética sobre os tempos medidos; a corrente do Air não foi medida com um instrumento. Meça na sua montagem antes de dimensionar a bateria.

Alarmes no Air

O Air só confere limites de alarme em M0. Num despertar de M1, ele lê os sensores e grava o histórico, mas não compara os valores com os limites e não gera registros da linha de alarmes (capítulo 22).

  • Um valor fora da faixa durante o ciclo fica no histórico e sai pela telemetria, mas não dispara nada.
  • A fila da linha de alarmes fica na RAM, e cada despertar começa com um reinício: o que não foi entregue antes de o Air dormir se perde.
  • O Air não tem buzzer nem visor: em M0, um alarme aparece na interface web e na linha de alarmes.

Para vigiar limites com um Air, faça a conferência no coletor da telemetria.

O que não existe no Air

Recurso Situação no Air
Painel, LCD e buzzer Não existem
Espelho, captura e tema do painel na interface web Não existem
PIN do painel e bloqueios do painel Não existem: não há painel
Rede de configuração que abre sozinha Não existe no Air, nem existiu da v2.7.1 à v2.8.0, quando a release e o alpha a tinham. O comando ap abre o AP (capítulo 9), mas configure a rede pelo console
Nome .local (mDNS) Não existe, nem em M0: saiu da imagem para caber no limite de tamanho da atualização. Use o IP
Interface web, API, Bluetooth e atualização Só em M0 (capítulo 17)
Alarmes e linha de alarmes Só em M0 (Alarmes no Air)
air stop pelo Bluetooth Não funciona em M1

O Air tem o console completo, com os modos e os comandos de configuração (capítulo 14). É a única imagem publicada com ele. Os comandos air estão também no capítulo 14.

O comando air status

SIMUT> air status
Air: phase=0 wake=60s hist=60s backoff=0s idle=300s armed=1 dirty=0 tel=31/5 skip=0 radio=1 chg=0 bat=50 cyc=4038ms wip=1
Campo O que mostra
phase A fase do ciclo: 0 é M0; em M1, 1 aquecimento, 2 amostragem, 3 decisão, 5 conexão, 6 envio e 7 sono
wake O sono pedido entre despertares, em segundos: o Intervalo Histórico, ou a espera da telemetria se for maior
hist O Intervalo Histórico, em segundos
backoff A espera da telemetria depois de uma falha, em segundos
idle O tempo de ociosidade em vigor, em segundos. Mostra 10 durante a graça depois de um reinício pelo vigia
armed 1 quando o ciclo está armado na flash e volta sozinho depois de um reinício
dirty Quantos reinícios pelo vigia seguidos o ciclo sofreu. Em 3, o Air fica retido em M0
tel Registros pendentes e o Lote mínimo, como 31/5. /0 quer dizer telemetria desligada
skip Quantos despertares de silêncio ainda faltam depois de um envio que falhou
radio 1 quando este boot ligou o rádio
chg 1 quando o carregador está ligado
bat O tamanho de lote que o ajuste automático da telemetria está usando. Não é a bateria
cyc A duração, em ms, do último ciclo completo de envio de um lote
wip Quantas vezes a cópia do bloco aberto do histórico foi gravada desde o boot. Num despertar, o esperado é 1

Dentro de um despertar, o console responde antes de o registro ser gravado, então wip aparece como 0. O número de cada despertar sai na última linha que o Air imprime antes de dormir:

[AIR] alarm: 00:00:52 wakeSec=51 awake=9342ms target=60000ms wip=1

O sufixo OVERRUN nessa linha indica que o despertar não coube no intervalo: o Air dormiu o mínimo de 5 s. Aumente o Intervalo Histórico ou reduza o que o despertar faz.

No começo de cada despertar, o console mostra também se o rádio vai ligar, como [AIR] wake: radio=off (pending=3 min=5 skip=0). Desde a v2.7.2, a linha [AIR] clock= mostra, antes de gravar o registro, a hora com milissegundos e se ela veio do NTP (ntp) ou do relógio carregado (prov).

Receita de instalação

  1. Grave a imagem do Air pelo BOOTSEL: simut_v<versão>_air.uf2 (capítulo 3).

  2. Ligue os sensores e, se for usar, a chave de alimentação dos sensores no GP16 e o divisor do carregador no GP17 (capítulo 2).

  3. Abra o console USB e pegue a senha do administrador: a moldura SEC-003 do primeiro boot, ou enable seguido de system admin reset confirm (capítulo 18).

  4. Configure o Wi-Fi pelo console:

    SIMUT> enable
    SIMUT# configure terminal
    SIMUT(config)# wifi ssid MinhaRede
    SIMUT(config)# wifi pass <senha do Wi-Fi>
    SIMUT(config)# end
    SIMUT# reload confirm

    Sem rede configurada, o boot do Air escreve também Sem rede, relogio provisorio: conf time AAAA-MM-DD HH:MM:SS. Num Air que vai funcionar sem Wi-Fi, acerte a hora com o comando time (capítulo 10).

  5. Ligue o carregador durante a configuração, para o Air não hibernar no meio dela. Sem carregador, cada comando e cada pedido da página renovam os 300 s de ociosidade.

  6. Descubra o IP com show net status e entre na interface web com admin. Troque a senha.

  7. Configure os sensores e o Intervalo Histórico, que é o período entre despertares (capítulo 6). Com o DS18B20, um despertar leva cerca de 9 s: um intervalo de 1 min deixa o Air acordado cerca de 13 % do tempo.

  8. Configure a telemetria (capítulo 21): o coletor, o Lote mínimo, que define de quantos em quantos despertares o rádio liga, e o Lote máximo. Confira o NTP (capítulo 10).

  9. Ajuste o Air, se precisar: air idle e air charger.

  10. Faça um backup pela página Arquivos (capítulo 17).

  11. Feche a página, desligue o carregador e rode air hibernate, ou deixe a ociosidade acabar.

  12. Confira o ciclo: acompanhe no coletor as chegadas no ritmo esperado. No primeiro dia, confira no log de eventos se aparece Boot frio, não veio da hibernação (412), que num Air instalado indica falta de energia ou reinício.

Figura 183. Um Air montado. O GP16 mostra quando ele está acordado e pode alimentar os sensores; o GP17 detecta o carregador.
Figura 184. O Painel de Controle de um Air em M0: sem o espelho do painel, que não existe nesta imagem.

Limitações

  • Experimental. O único teste longo do ciclo falhou em 10/09/2026, com um sono que nunca terminou depois de 119 ciclos. O vigia no despertar reduz o problema a um reinício, mas a causa não foi confirmada (O que é o Air).
  • Consumo não medido. Os 8,2 mA e 17 dias são uma conta (Tempos medidos e consumo).
  • Sem alarmes em M1 (Alarmes no Air).
  • A hora dos despertares sem rádio é reconstruída. Na v2.7.1, ela perde até cerca de 1 s por despertar até o próximo NTP (capítulo 10).
  • Atualização só em M0, e o Air está perto do limite de tamanho da atualização.
  • Uma janela curta no console em M1: alguns segundos por despertar, só pelo USB.
  • Baixar a resolução do DS18B20 não encurta o despertar (Tempos medidos e consumo).
  • As opções do Air ficam fora da configuração principal, em /config/air.bin. Uma atualização as apaga; o backup as guarda (capítulo 17).

Códigos do log de eventos

Código Evento Quando aparece
411 Ciclo Air retido em M0 Três reinícios pelo vigia seguidos; o contexto é o número deles
412 Boot frio, não veio da hibernação Um boot que não foi um despertar. Contexto 1: boot limpo (alimentação, RUN, reload, atualização); 0: o vigia chegou antes
413 Sono limitado a menos de 24 h (alarme é por hora do dia) Um sono de 24 h pedido; o contexto são os minutos pedidos
414 Wake anterior do Air não completou O despertar anterior travou antes do fim e foi reiniciado
567 Snapshot de histórico gravado O registro de cada ciclo, com o número de registros do bloco no contexto

Num despertar, a sequência de partida não vai para o log, e sobra um registro por ciclo (capítulo 16).

Solução de problemas

Sintoma Causa provável O que fazer
O Air não hiberna O carregador está ligado ou o pino lê nível alto (chg=1) Confira o air status. Se não há carregador, confira o divisor, ou use air charger off
O Air não hiberna, com chg=0 Uma aba do Painel de Controle aberta, um gestor de frota consultando sem quiet=1, ou comandos no console Feche a aba; use /api/status?quiet=1 no gestor
O Air nunca liga o rádio Lote mínimo em 0, pendentes abaixo do Lote mínimo, ou skip maior que 0 Confira tel= e skip= no air status
O coletor recebe menos que o esperado depois de uma queda Depois de um envio que falha, 5 despertares ficam sem rádio Normal. Os registros esperam na flash e saem depois
A interface web do Air não abre O Air está em M1 Ligue o carregador ou desligue e ligue a alimentação
air stop não tem efeito Foi digitado pelo Bluetooth, ou fora da janela do despertar Use o USB durante um despertar, ou o carregador
A linha [AIR] alarm: termina com OVERRUN O despertar não cabe no Intervalo Histórico Aumente o intervalo
O log mostra Ciclo Air retido em M0 (411) Três reinícios pelo vigia seguidos Entre, exporte o log e relate; o Air espera em M0
O log mostra Wake anterior do Air não completou (414) Um despertar travou e foi reiniciado Guarde o log e relate (Limitações)
O log mostra Boot frio, não veio da hibernação (412) sem ninguém ter mexido Falta de energia ou reinício Confira a bateria e a alimentação
As horas dos registros derivam cerca de 1 s por despertar v2.7.1, sem o relógio carregado através do sono Garanta despertares de telemetria para o NTP corrigir (capítulo 10)
Depois de atualizar, o Air voltou a hibernar em 300 s e o carregador voltou ao GP17 A atualização apagou o /config/air.bin Restaure o backup, ou ajuste air idle e air charger de novo

Voltar ao sumário

Parte V

Integrar com servidores

Capítulo 20

Visão geral da integração

Este capítulo mostra tudo o que o SIMUT troca com outros sistemas: o que ele envia por conta própria, o que ele oferece para ser consultado e como cada peça identifica o aparelho. Ele é para o integrador e para a equipe de TI que vão escolher o mecanismo, abrir as portas na rede e escrever o servidor.

Os dois sentidos do tráfego

O aparelho conversa com servidores de dois jeitos, e eles não dependem um do outro.

  • O aparelho empurra. Ele abre a conexão e manda dados para um servidor que você indica: as medições, os eventos de alarme, o log de eventos e as mensagens de descoberta do Home Assistant. O servidor que recebe não precisa entrar no aparelho nem ter conta nele.
  • O servidor consulta ou comanda. O aparelho atende pedidos na porta da interface web: a API REST, as métricas do Prometheus e o anúncio na rede local por mDNS. Para comandar o aparelho, o servidor usa uma conta do aparelho, com sessão.

Um receptor de telemetria, portanto, não comanda nada, e quem comanda não precisa receber telemetria. São dois componentes do seu lado.

Figura 185. Legenda: os dois sentidos do tráfego. As setas que saem do aparelho são conexões que ele mesmo abre; as que chegam usam a porta da interface web.

O que o aparelho envia

Mecanismo Para onde Transporte Onde configurar Detalhes
Telemetria de medições Coletor HTTP ou HTTPS (POST); MQTT ou MQTTS (publish) Página Telemetria Capítulo 21
Linha de alarmes Coletor O mesmo da telemetria, com confirmação de recebimento Página Telemetria Capítulo 22
Home Assistant Broker MQTT Mensagens de descoberta retidas, mais a telemetria em JSON Página Telemetria, transporte MQTT Capítulo 23
Syslog Coletor de syslog RFC 5424 sobre UDP, porta 514 de fábrica Página Configurações, Syslog Remoto (Auditoria) Capítulo 25

A telemetria manda os registros do histórico: um registro por intervalo do histórico, com a hora e o valor de cada canal ativo. A linha de alarmes manda eventos: um limite ultrapassado, um sensor em falha, uma janela de manutenção aberta ou fechada, uma ação feita no painel. As duas usam o mesmo servidor, a mesma porta, a mesma chave de acesso e o mesmo TLS; só o formato e o caminho são próprios de cada uma.

O syslog não é um terceiro transporte de telemetria. Ele manda as linhas do log de eventos a partir de um nível mínimo, uma vez cada, por UDP, sem confirmação e sem nova tentativa.

O que o aparelho oferece

Mecanismo Quem pede Onde Detalhes
API REST O servidor de gestão, com uma conta do aparelho Porta da interface web, rotas /api/... Capítulo 26
Métricas do Prometheus O Prometheus, com sessão ou HTTP Basic GET /metrics, na porta da interface web Capítulo 24
Anúncio mDNS Qualquer máquina da rede local Serviço _simut._tcp, com uid, ver, env e tls no registro TXT Capítulo 27

As métricas mostram o estado de agora. O aparelho não guarda nem reenvia nada por esse caminho: quem guarda a série é o Prometheus.

Em cada imagem

Recurso release alpha Air
Telemetria e linha de alarmes Sim Sim Sim, nos despertares de transmissão (capítulo 19)
Interface web, API REST e /metrics HTTP, ou só HTTPS com certificado instalado Só HTTP Só em M0 (capítulo 19)
Anúncio mDNS Sim Não Não

No Air, os alarmes só são avaliados com o aparelho acordado (M0). Num despertar do ciclo (M1), ele lê os sensores e grava o histórico, mas não confere limites nem gera eventos da linha de alarmes. E cada despertar termina num reinício do processador, então a fila, que vive na RAM, não atravessa o sono.

Identidade do aparelho

Cinco valores dizem quem é o aparelho. Só um deles serve de chave.

Valor Exemplo De onde vem Muda quando
uid E6614C311B7A2F2D Número de série da placa, 16 dígitos hexadecimais em maiúsculas Não muda com configuração, atualização ou restauração
Nome simut Campo Nome da página Configurações Alguém edita
MAC 28:cd:c1:0a:1b:2c Endereço Wi-Fi, em minúsculas e com dois-pontos Não muda
Versão 2.7.1 O firmware gravado A cada atualização
Variante release, alpha ou air A imagem gravada Ao trocar de imagem

Use o uid como chave primária do aparelho no seu banco. O endereço IP vem do DHCP e muda; o nome é editável e pode se repetir entre aparelhos.

O mesmo uid aparece:

  • no cabeçalho X-SIMUT-Uid de todo POST de telemetria e da linha de alarmes;
  • na resposta de GET /api/status, campo uid;
  • no registro TXT do anúncio mDNS, campo uid;
  • no marcador {DHT_ID} do formato Dinâmico da telemetria (capítulo 21).

Os cabeçalhos X-SIMUT

Todo POST HTTP ou HTTPS que o aparelho faz, de telemetria ou da linha de alarmes, leva quatro cabeçalhos de identidade. O corpo não muda por causa deles.

X-SIMUT-Uid: E6614C311B7A2F2D
X-SIMUT-Ver: 2.7.1
X-SIMUT-Env: release
X-SIMUT-Cfg: 3F2A91C4
Cabeçalho O que é
X-SIMUT-Uid O número de série da placa: a chave do aparelho
X-SIMUT-Ver A versão do firmware
X-SIMUT-Env A variante da imagem: release, alpha ou air
X-SIMUT-Cfg O CRC-32 da configuração em uso, em 8 dígitos hexadecimais em maiúsculas

Se o X-SIMUT-Cfg de um aparelho mudou desde o último POST, alguém mudou a configuração dele. Se X-SIMUT-Ver mudou, a atualização entrou. Você descobre as duas coisas sem abrir sessão no aparelho, só guardando os cabeçalhos do POST que já ia chegar.

Compare o X-SIMUT-Cfg de um aparelho com os valores anteriores dele mesmo, não com os de outro aparelho. A configuração inclui as contas, e cada aparelho gera sementes aleatórias para elas: dois aparelhos ajustados do mesmo jeito quase nunca têm o mesmo valor.

No MQTT

Uma mensagem MQTT não tem cabeçalhos, e o corpo da telemetria não traz o uid. No MQTT, o que identifica o aparelho é o tópico. Por isso, dê a cada aparelho um Tópico próprio, por exemplo fabrica/camara1/data. A mensagem de estado que o aparelho publica ao conectar traz o nome e o IP (capítulo 21).

Com o Client ID em branco, o aparelho se apresenta ao broker como simut_ seguido dos seis últimos dígitos do MAC, como simut_0a1b2c.

Qual mecanismo usar

Você precisa de Use Capítulo
Guardar todas as medições num banco, sem buracos Telemetria, em HTTP e JSON 21
Falar com um receptor que já existe e tem formato fixo Telemetria no formato Dinâmico 21
Saber em segundos que um sensor passou do limite ou falhou Linha de alarmes 22
Saber quem desligou um alarme, mudou um limite ou abriu uma manutenção no painel Linha de alarmes 22
Distinguir um sensor em manutenção de um sensor com defeito Linha de alarmes (maint_on e maint_off) 22
O aparelho no Home Assistant, sem YAML MQTT com Home Assistant Discovery 23
Gráficos e alertas no Prometheus e no Grafana GET /metrics 24
Trilha de auditoria fora do aparelho Syslog 25
Criar contas, mudar limites ou abrir manutenção a partir do servidor API REST 26
Inventário de muitos aparelhos, versão e configuração de cada um mDNS, GET /api/status e os cabeçalhos X-SIMUT 27

A telemetria e a linha de alarmes se completam. A telemetria entrega tudo, no ritmo do lote, e não perde medição: o registro fica na flash até o coletor confirmar. A linha de alarmes entrega pouco e rápido, mas vive na RAM: um reinício perde o que não foi confirmado.

Rede e portas

O aparelho é cliente na telemetria, na linha de alarmes, no syslog e no NTP. Para esses, a rede só precisa deixar o aparelho sair; nada precisa entrar nele.

Tráfego Quem abre Protocolo e porta Observação
Telemetria e linha de alarmes O aparelho TCP, na Porta da página Telemetria De fábrica, 80. O usual é 80 (HTTP), 443 (HTTPS), 1883 (MQTT) e 8883 (MQTTS)
Syslog O aparelho UDP, 514 de fábrica O coletor é um endereço IPv4, não um nome
NTP O aparelho UDP 123 Servidor de fábrica: pool.ntp.org
DNS O aparelho UDP 53 Só quando o servidor é um nome, como coletor.exemplo.com.br
Interface web, API REST e /metrics O seu servidor TCP 80 (HTTP); 443 (HTTPS, imagem release com certificado); ou a porta configurada Capítulo 9
mDNS Anúncio local UDP 5353, multicast Só na imagem release

Três regras valem para a telemetria e a linha de alarmes:

  • Sinal fraco adia o envio. Com o sinal Wi-Fi em −78 dBm ou abaixo, o aparelho não envia telemetria nem a linha de alarmes. As medições continuam gravadas e saem quando o sinal melhora.
  • O coletor tem 4 s para responder. O aparelho espera a resposta por 4 s. Um coletor mais lento que isso vira falha, e o lote é reenviado.
  • Um envio por vez. O aparelho não abre conexões paralelas para o mesmo coletor.

Hora certa: por que o NTP importa

Toda a integração conta o tempo pela hora do aparelho. Cada registro de telemetria e cada evento da linha de alarmes leva um ts: segundos desde 01/01/1970, em UTC, lidos do relógio do aparelho.

Uma hora errada estraga a integração de quatro jeitos:

  • Sem referência de hora, o histórico não grava. O aparelho pula a gravação e registra o evento 512, Histórico pulado: sem referência de hora. Sem histórico, a telemetria não tem o que mandar. O evento 513, Histórico retomado: referência de hora obtida, marca a volta.
  • A hora provisória pode carimbar errado. Até a primeira sincronização, o aparelho usa uma hora provisória guardada na flash (evento 524, Hora provisória do flash). O capítulo 10 explica os limites dessa hora.
  • O cursor da telemetria segue a gravação, não a hora. Um registro gravado depois sai depois, mesmo com hora anterior. Registros com hora anterior a 13/09/2020, ou mais de 1 dia à frente do relógio do aparelho, não saem pela telemetria (capítulo 21).
  • O seu banco ordena por ts. Um aparelho adiantado ou atrasado grava fora de ordem e duplica ou esconde medições na chave (uid, ts).

Mantenha a sincronização ligada: página Configurações, bloco Data e Hora, opção Sincronizar automaticamente via NTP. Numa rede sem acesso à internet, aponte o aparelho para um servidor NTP local, no campo Endereço do Servidor do bloco Servidor de Hora (NTP) da página Rede. O capítulo 10 cobre o assunto.

Segurança, em resumo

  • A telemetria pode levar uma chave de acesso. O campo API Key vira um cabeçalho Authorization: Bearer ... ou um cabeçalho com o nome que você escolher (capítulo 21). Recuse no coletor o POST que não a trouxer.
  • O TLS cifra e, com certificado, autentica o coletor. Com Usar TLS / SSL ligado e o arquivo /cert.pem enviado, o aparelho confere o certificado do coletor. Sem o arquivo, a conexão é cifrada, mas o aparelho aceita qualquer certificado.
  • O aparelho não tem certificado de cliente. O coletor só reconhece o aparelho pela chave de acesso e pelo uid.
  • Mantenha aparelhos e coletor numa rede fechada. Não exponha o aparelho à internet, nem com porta redirecionada.

O capítulo 29 trata da segurança por inteiro.

Voltar ao sumário

Capítulo 21

Telemetria de medições

Este capítulo explica como o SIMUT envia as medições do histórico para um coletor: cada campo da página Telemetria, quando e como o aparelho envia, o formato exato de cada modo e o que ele faz com cada resposta. Ele é para quem configura o aparelho e para quem escreve o coletor que vai receber os dados.

Como a telemetria funciona

O aparelho grava uma medição por intervalo do histórico: um registro com a hora e o valor de cada canal ativo (capítulo 15). A telemetria envia esses registros, em lotes, para o coletor que você indicar.

Três ideias explicam todo o comportamento:

  • O registro nasce na flash. A telemetria só lê o histórico. Se o coletor está fora do ar, nada se perde: os registros esperam na flash e saem quando ele volta.
  • Um cursor marca o que já foi entregue. O cursor é um lugar no histórico: o arquivo do dia, o bloco e a posição no bloco do último registro que o coletor confirmou. Cada lote leva os registros gravados depois desse lugar, qualquer que seja a hora que eles carregam.
  • Só uma confirmação avança o cursor. No HTTP, a confirmação é uma resposta 2xx. No MQTT, é a publicação aceita com a conexão ainda viva. Qualquer outra coisa deixa o cursor onde está, e o mesmo trecho sai de novo.

A telemetria vem desligada de fábrica.

Figura 186. Legenda: o cursor separa o que o coletor já confirmou do que ainda falta. Só uma confirmação o move.

A página Telemetria

Abra o menu da interface web e escolha Telemetria (Telemetry). A página exige a permissão Sistema PERM_SYS_CONFIG.

A página tem três blocos:

  • Telemetria (Telemetry Engine): transporte, servidor, acesso e lotes;
  • Construtor (Payload Builder): o formato do corpo;
  • Payload de Alarmes — 2ª Linha de Telemetria (Alarm Payload — 2nd Telemetry Line): a linha de alarmes, descrita no capítulo 22.

As edições ficam pendentes até você usar um dos botões de gravação: Testar, Aplicar agora ou Salvar e reiniciar. O capítulo 5 explica os três. A coluna Reinício das tabelas abaixo diz se o campo exige reiniciar o aparelho.

Os botões Enviar agora e Resetar cursor de envio são diferentes: eles agem na hora, sobre o aparelho em funcionamento, e não passam pelos botões de gravação.

Legenda: a página Telemetria com o transporte HTTP. Note a chave mascarada no campo API Key e os botões Enviar agora e Resetar cursor de envio logo abaixo dos lotes.
Figura 187. Legenda: a página Telemetria com o transporte HTTP. Note a chave mascarada no campo API Key e os botões Enviar agora e Resetar cursor de envio logo abaixo dos lotes.

Transporte e servidor

Campo Chave na API Faixa De fábrica Reinício
Transporte (Transport Protocol) t_transport HTTP(S) = 0; MQTT(S) = 1 HTTP(S) Sim
IP Servidor (Server Domain / IP) t_srv Endereço IP ou nome, até 63 caracteres Vazio Não (veja a nota)
Porta (Port) t_port 1 a 65535 80 Não (veja a nota)
Usar TLS / SSL (Use TLS / SSL) t_sec Ligado ou desligado Desligado Sim
Endpoint (Endpoint Path (URL)) t_path Até 31 caracteres /api.php Não
API Key (API Key / Token) t_key Até 63 caracteres Vazio Não
  • Transporte. Escolhe entre POST HTTP e publicação MQTT. O TLS vem do campo Usar TLS / SSL: HTTP com TLS é HTTPS, e MQTT com TLS é MQTTS. Com o MQTT escolhido, o rótulo do TLS vira Usar MQTTS (TLS), e os campos Endpoint e API Key dão lugar aos campos do MQTT.
  • IP Servidor. Apesar do rótulo, aceita um nome, como coletor.exemplo.com.br. Sem servidor, nada é enviado.
  • Porta. Continua em 80 quando você troca para MQTT. Ajuste-a: o usual é 80 para HTTP, 443 para HTTPS, 1883 para MQTT e 8883 para MQTTS.
  • Endpoint. O caminho do POST, começando com /, como /api/telemetria. O endereço completo é http:// ou https://, o servidor, :, a porta e o caminho.
  • API Key. A chave de acesso que o aparelho põe em todo POST (A chave de acesso).

A chave de acesso

O valor do campo API Key vira um cabeçalho HTTP em todo POST de telemetria e da linha de alarmes. O aparelho tira os espaços das pontas e escolhe a forma assim:

Você digita O aparelho envia
troque-este-segredo Authorization: Bearer troque-este-segredo
X-Api-Key: 9f2c41d7 X-Api-Key: 9f2c41d7
Authorization: Basic c2ltdXQ6c2VncmVkbw== Authorization: Basic c2ltdXQ6c2VncmVkbw==
Nada Nenhum cabeçalho de acesso

A regra: se o valor tem : depois do primeiro caractere, o que vem antes é o nome do cabeçalho e o que vem depois é o valor. Sem :, o valor vai como Bearer. Os nomes Connection, User-Agent e Host não podem ser usados: o aparelho os ignora.

Depois de gravada, a chave aparece mascarada: os 4 primeiros caracteres seguidos de ***, ou só *** para chaves de até 4 caracteres. Enquanto o campo mostrar a máscara, o aparelho mantém a chave gravada. Para trocar, apague o campo e digite a nova. Para remover, apague o campo e grave.

A chave de acesso não vale para o MQTT, que usa Usuário e Senha.

Campos do MQTT

Aparecem com Transporte em MQTT(S).

Campo Chave na API Faixa De fábrica Reinício
Tópico (MQTT Topic) m_topic Até 63 caracteres simut/data Sim
Client ID m_cid Até 23 caracteres Vazio Sim
Usuário (MQTT User) m_user Até 31 caracteres Vazio Sim
Senha (MQTT Password) m_pass Até 31 caracteres Vazio Sim
QoS (QoS Level) m_qos Só 0 0 Sim
Keep-Alive (Keep-Alive (s)) m_ka 10 a 300 s 60 s Sim
Reter (Retain Message) m_retain Ligado ou desligado Desligado Sim
Home Assistant Discovery m_had Ligado ou desligado Desligado Sim
  • Tópico. O tópico das medições. Os outros tópicos derivam dele (MQTT). Em branco, o aparelho usa simut/data.
  • Client ID. Em branco, o aparelho usa simut_ seguido dos seis últimos dígitos do MAC, como simut_0a1b2c.
  • Usuário e Senha. Com o usuário em branco, o aparelho conecta sem usuário e senha. A senha nunca volta para a página: o campo aparece vazio, com o texto Leave empty to keep. Deixe-o vazio para manter a senha gravada.
  • QoS. O aparelho publica sempre com QoS 0. A página só oferece 0, e o aparelho recusa outro valor.
  • Keep-Alive. O intervalo de vida combinado com o broker.
  • Reter. Publica as medições como mensagens retidas: o broker guarda a última e a entrega a quem assinar depois.
  • Home Assistant Discovery. Exige o formato JSON. Está no capítulo 23.
Legenda: com o transporte MQTT, os campos Endpoint e API Key saem e entram os do broker. Note que a Porta não muda sozinha.
Figura 188. Legenda: com o transporte MQTT, os campos Endpoint e API Key saem e entram os do broker. Note que a Porta não muda sozinha.

Lote mínimo e lote máximo

Campo Chave na API Faixa De fábrica Reinício
Lote mínimo (registros) (Minimum batch (records)) t_int 0 a 20.000 0 (desligada) Não
Lote máximo (registros) (Maximum batch (records)) t_bat 1 a 250 10 Não
  • Lote mínimo. Quantos registros precisam estar esperando para o aparelho transmitir. 0 desliga a telemetria. Com o valor em 0, a página mostra a faixa Telemetria desabilitada (lote mínimo = 0). Defina um valor para ativar.
  • Lote máximo. O máximo de registros num envio. Uma fila maior sai em vários lotes, um atrás do outro, até acabar.

O ritmo dos registros vem do Intervalo Histórico (min), na página Configurações (1 a 1440 min; de fábrica, 1). Com o histórico a cada minuto:

Lote mínimo Resultado
1 Um envio por minuto, com o registro novo
60 Um envio por hora, com a hora inteira
1440 Um envio por dia

Um lote mínimo maior economiza rádio e conexões; um menor entrega mais cedo. Para eventos que não podem esperar, use a linha de alarmes (capítulo 22).

Enviar agora e Resetar cursor de envio

Enviar agora (Send now) começa um envio na hora, sem esperar o lote mínimo, e zera a espera de uma falha anterior. A página responde Envio disparado. Acompanhe o resultado no log. e o aparelho registra o evento 546, Forçando sync de telemetria.

  • O resultado aparece no log de eventos, não na página (Códigos do log de eventos).
  • Com o Lote mínimo em 0, Enviar agora manda um único lote e para.
  • Se o sinal estiver fraco ou outro envio estiver em andamento, nada sai, embora a página diga que o envio foi disparado.

Resetar cursor de envio (Reset send cursor) apaga o cursor. A página pede confirmação: Resetar o cursor de telemetria? O dispositivo vai reenviar até 30 dias de histórico no próximo envio. Espere uma rajada de tráfego. Depois do reset, os envios recomeçam 30 dias antes do registro mais novo. O aparelho registra o evento 303, Config alterada, com o texto Telemetry cursor reset via web.

Use o reset depois que o coletor perdeu dados, ou ao apontar o aparelho para um coletor novo que precisa do histórico.

Construtor

Campo Chave na API Faixa De fábrica Reinício
Formato (Format) t_mode JSON = 0; CSV = 1; Dinâmico = 2 JSON Não
1. Global (1. Global Template (The Envelope)) t_glob Até 255 caracteres {"dev":"{DEV}","mac":"{MAC}","data":[{DATA}]} Não
2. Linha (2. Row Template (Single Reading)) t_line Até 511 caracteres {"ts":{TS},"t0_ID":{t0},"u0_ID":{u0}} Não
3. Separador (3. Separator) t_sep Até 7 caracteres , Não
Cabeçalho Content-Type (Content-Type Header) t_ct Até 31 caracteres: um tipo de mídia, como application/json Vazio, que vale application/json Não

Os três modelos e o Cabeçalho Content-Type só aparecem, e só valem, no formato Dinâmico (O cabeçalho Content-Type). As opções do Formato têm, em inglês, os nomes JSON Array (Standard), CSV Raw (Standard) e Dynamic Builder (Advanced).

A Prévia ao Vivo (Live Preview) mostra o corpo que o aparelho envia, montado com os dados dele: o nome em {DEV}, o MAC em {MAC}, o número de série da placa em {DHT_ID}, os sensores configurados com as leituras de agora e a hora do aparelho. São dois registros, um Intervalo Histórico um do outro:

  • o segundo traz as leituras atuais;
  • o primeiro mostra o primeiro sensor ativo em falha, para você ver o que o coletor recebe quando um sensor para. No JSON, a chave dele some. No CSV, a coluna fica vazia. Num modelo do Dinâmico, a forma composta tira a chave, e um marcador solto vira null.

Os três formatos saem como o aparelho os monta, inclusive as 34 colunas do CSV (Formato CSV). Uma legenda acima da prévia diz quando ela usa os dados do aparelho. Uma conta sem a permissão de ver o painel não lê o estado dele: aí a prévia usa valores de exemplo nos sensores configurados, e a legenda não aparece.

A prévia abre em Organizado (Organized), o mesmo visor da página Arquivos (Ver um arquivo de texto). Um JSON aparece indentado, e cada objeto e cada lista de mais de uma linha abre e recolhe ao toque na linha; Expandir tudo (Expand all) e Recolher tudo (Collapse all) fazem isso com todos. O que não é JSON, como o CSV, aparece com as linhas numeradas. Original mostra o corpo exatamente como o aparelho o envia. Os blocos recolhidos continuam recolhidos enquanto você edita os modelos, até o corpo ganhar ou perder linhas; aí tudo abre de novo.

Quando o corpo parece JSON mas não é válido, a prévia o organiza pela posição das chaves e dos colchetes e avisa JSON incompleto ou inválido.

Legenda: o construtor no formato Dinâmico, com o quadro de tags e a prévia, montada com os dados do aparelho.
Figura 189. Legenda: o construtor no formato Dinâmico, com o quadro de tags e a prévia, montada com os dados do aparelho.

Quando o aparelho envia

  1. Cada registro novo do histórico soma 1 ao contador de pendentes, que o Painel de Controle mostra em Registros Pendentes (capítulo 13).
  2. Quando os pendentes chegam ao Lote mínimo, começa um esvaziamento. Depois de ligar, o primeiro espera pelo menos 8 s.
  3. Cada lote leva os registros gravados depois do cursor, até o limite do lote. Isso inclui a hora ainda aberta na RAM: o aparelho não espera o bloco do histórico fechar para enviar.
  4. Com a confirmação, o cursor avança até o último registro que o lote levou.
  5. O aparelho repete até não sobrar nada e volta a esperar o lote mínimo.

O aparelho não envia:

  • com o Lote mínimo em 0;
  • com o sinal Wi-Fi em −78 dBm ou abaixo;
  • durante a espera depois de uma falha (Falhas e novas tentativas);
  • enquanto o painel está no teclado de PIN ou num menu, e até 5 s depois do último toque na tela;
  • com menos de 24 KB de memória livre (com TLS) ou 14 KB (sem TLS). Essa falta de memória conta como falha.

O tamanho de cada lote

Três limites decidem quantos registros vão num lote, e vale o menor:

  • o Lote máximo que você configurou;
  • a memória livre. O aparelho reserva 12 KB (sem TLS) ou 32 KB (com TLS) e conta 350 bytes por registro no JSON e no Dinâmico, ou 160 bytes no CSV;
  • o ajuste automático. Começa no Lote máximo, cai pela metade a cada falha, até o mínimo de 10, e cresce 50 % a cada sucesso, até voltar ao Lote máximo.

Um registro inteiro por vez

Desde a v2.7.2, o aparelho monta o corpo um registro inteiro por vez: cada registro entra completo, com o separador e o fechamento garantidos, ou fica para o lote seguinte. O cursor avança só até o registro mais novo que o corpo levou de fato.

Até a v2.7.1, um lote montado com pouca memória livre podia chegar ao coletor como JSON inválido, com registros faltando no fim, e o cursor passava por cima dos registros que ficaram de fora. Medido em 23/09/2026 num Air v2.7.1, esvaziando a fila para um coletor que guardava todo corpo recebido: 68 de 69 lotes chegaram como JSON inválido, cada um com cerca de nove registros a menos.

O ritmo entre lotes

Durante um esvaziamento, quem dita o ritmo é o coletor. O aparelho mede o ciclo inteiro de cada lote (ler, montar, conectar, enviar e fechar) e decide a pausa até o próximo:

Ciclo do lote Pausa até o próximo lote
Até 0,4 s sem TLS, ou até 2,5 s com TLS Nenhuma
Mais lento que isso Igual ao próprio ciclo
Mais de 25 % pior que a média recente Dobra a cada lote que piora

A pausa nunca passa de 10 s. Com o sinal Wi-Fi abaixo de −75 dBm, ela cresce 50 %.

Falhas e novas tentativas

Conta como falha:

  • uma resposta HTTP fora da faixa 200 a 299;
  • nenhuma resposta em 4 s;
  • um erro de conexão, de DNS ou de TLS;
  • no MQTT, a conexão recusada pelo broker, a publicação recusada ou a conexão caindo logo depois dela;
  • a falta de memória antes do envio.

Depois de uma falha, o cursor não se move, o lote seguinte cai pela metade e o aparelho espera antes de tentar de novo. A espera começa em 5 s e dobra a cada falha seguida, até 300 s. Cada espera varia 25 % para mais ou para menos, para que vários aparelhos não voltem todos no mesmo instante.

Falha seguida Espera aproximada
1ª 5 s
2ª 10 s
3ª 20 s
4ª 40 s
5ª 80 s
6ª 160 s
7ª em diante 300 s

O primeiro sucesso zera a sequência.

O que conta como entrega

No HTTP, só um código de 200 a 299 é entrega. O aparelho lê apenas o código de status: o corpo da resposta é descartado, e a conexão é fechada logo depois.

O coletor responde O aparelho faz Evento
200 a 299 Avança o cursor e segue para o próximo lote 30, Telemetria enviada
1xx ou 3xx Falha. O aparelho não segue redirecionamentos 31, Falha de telemetria, com o código, e 32
4xx ou 5xx Falha; espera e reenvia o mesmo trecho 31, com o código, e 32
Nada em 4 s Falha por tempo esgotado 31, com o contexto −11, e 32
Conexão recusada, nome não resolvido ou TLS recusado Falha de conexão 31, com o contexto −1, e 32

Um coletor que redireciona HTTP para HTTPS faz toda tentativa falhar com o código 301 ou 302. Aponte o aparelho direto para o endereço final e, para HTTPS, ligue o TLS.

No MQTT, a entrega é a publicação aceita. O aparelho publica com QoS 0, que não tem confirmação do broker. Ele considera o lote entregue quando todas as mensagens foram escritas e a conexão continua viva 60 ms depois. Se a conexão cai nesse intervalo, o cursor não avança e o trecho sai de novo.

Anatomia do POST HTTP

Um lote de 3 registros, em JSON, para um coletor na porta 8080:

POST /api/telemetria HTTP/1.1
Host: coletor.exemplo.com.br:8080
User-Agent: Pico
Accept-Encoding: identity;q=1,chunked;q=0.1,*;q=0
Connection: keep-alive
Content-Type: application/json
Authorization: Bearer troque-este-segredo
X-SIMUT-Uid: E6614C311B7A2F2D
X-SIMUT-Ver: 2.7.1
X-SIMUT-Env: release
X-SIMUT-Cfg: 3F2A91C4
Content-Length: 265

[{"ts":1790168400,"tSTM0001":4.25,"tBME28001":22.81,"uBME28001":55.2,"pBME28001":1013.4},{"ts":1790168460,"tSTM0001":4.31,"tBME28001":22.84,"uBME28001":55.0,"pBME28001":1013.4},{"ts":1790168520,"tSTM0001":4.28,"tBME28001":22.90,"uBME28001":54.9,"pBME28001":1013.3}]
Parte Valor
Método Sempre POST
Caminho O campo Endpoint
Host O IP Servidor; a porta só aparece quando não é 80 nem 443
User-Agent, Accept-Encoding, Connection Fixos, da biblioteca HTTP do aparelho
Content-Type application/json (JSON), text/csv (CSV) ou o Cabeçalho Content-Type (Dinâmico; vazio, application/json)
Chave de acesso O cabeçalho montado a partir da API Key, se houver
X-SIMUT-* A identidade do aparelho (capítulo 20)
Content-Length O tamanho do corpo. O corpo nunca vai em partes (chunked)
Corpo Em UTF-8, sem espaços nem quebras de linha no JSON

Embora o cabeçalho diga keep-alive, o aparelho fecha a conexão logo depois de ler o código de status. Cada lote abre uma conexão nova, e com TLS isso inclui uma negociação completa.

A linha de alarmes usa o mesmo formato de requisição, no caminho dela (capítulo 22).

Formato JSON

O corpo é um array. Cada elemento é um registro: um objeto com ts e uma chave por canal medido.

[{"ts":1790168400,"tSTM0001":4.25,"tBME28001":22.81,"uBME28001":55.2,"pBME28001":1013.4},{"ts":1790168460,"tSTM0001":4.31,"tBME28001":22.84,"uBME28001":55.0,"pBME28001":1013.4},{"ts":1790168520,"tSTM0001":4.28,"tBME28001":22.90,"uBME28001":54.9,"pBME28001":1013.3}]

O exemplo vem de um aparelho com dois sensores: um DS18B20 com o identificador STM0001, no slot 0, e um BME280 com o identificador BME28001, no slot 1.

Chave Conteúdo Unidade Casas decimais
ts Hora do registro, em segundos desde 01/01/1970, UTC s 0
t + identificador Temperatura °C 2
u + identificador Umidade relativa % 1
p + identificador Pressão hPa 1

Regras das chaves:

  • O identificador é o do sensor, definido no provisionamento do slot (capítulo 6). Sem identificador, a chave usa o número do slot, como t0 ou u3. Na prática, o aparelho dá um identificador a todo sensor ativo ao iniciar.
  • Chave ausente quer dizer “sem leitura” naquele instante. Não é zero nem nulo: a chave não aparece. Não preencha com 0 o que não veio.
  • Só sensores ativos entram, na ordem dos slots: a temperatura e depois a umidade de cada um, e a pressão no fim.
  • Cada registro leva uma pressão, no máximo. A chave usa o identificador do primeiro sensor ativo que mede pressão. Com dois sensores de pressão ativos, o valor enviado é o do último canal de pressão lido do histórico (em geral, o do slot mais alto), mas a chave leva o identificador do primeiro: a pressão sai com o rótulo trocado. Se a telemetria precisa da pressão, use um só sensor de pressão.
  • A ordem das chaves não é contrato. Leia por nome.

Formato CSV

O corpo é uma linha de cabeçalho seguida de uma linha por registro. Toda linha termina com uma quebra de linha (\n). O separador é ; e o separador decimal é o ponto.

timestamp;s0_STM0001;s1_BME28001;s2;s3;s4;s5;s6;s7;s8;s9;s10;s11;s12;s13;s14;s15;h0_STM0001;h1_BME28001;h2;h3;h4;h5;h6;h7;h8;h9;h10;h11;h12;h13;h14;h15;press
1790168400;4.25;22.81;;;;;;;;;;;;;;;;55.2;;;;;;;;;;;;;;;1013.4
1790168460;4.31;22.84;;;;;;;;;;;;;;;;55.0;;;;;;;;;;;;;;;1013.4
1790168520;4.28;22.90;;;;;;;;;;;;;;;;54.9;;;;;;;;;;;;;;;1013.3

As colunas são sempre 34, na mesma ordem:

Coluna Conteúdo Casas decimais
1 Hora do registro (epoch, UTC) 0
2 a 17 Temperatura dos slots 0 a 15 2
18 a 33 Umidade dos slots 0 a 15 1
34 Pressão 1
  • Célula vazia quer dizer “sem leitura”. Um slot inativo, ou um sensor sem aquela grandeza, deixa a célula vazia.
  • O cabeçalho dá nome aos slots ativos com o identificador, como s0_STM0001 e h0_STM0001, mesmo quando o sensor não mede umidade. Os demais ficam s2, h2 e assim por diante.
  • Leia por posição, não pelos nomes do cabeçalho. Os nomes mudam quando um slot é ativado ou o identificador muda; as posições não.

Formato Dinâmico

O formato Dinâmico existe para falar com um receptor que já existe e cujo formato você não pode mudar. Ele monta o corpo com três peças:

  • 2. Linha: o modelo de um registro, repetido para cada registro do lote;
  • 3. Separador: o que vai entre um registro e o próximo;
  • 1. Global: o envelope. O marcador {DATA} recebe as linhas unidas pelo separador.

O Content-Type do POST é o do campo Cabeçalho Content-Type (O cabeçalho Content-Type).

O cabeçalho Content-Type

O campo Cabeçalho Content-Type diz ao receptor o que o corpo é. O aparelho o põe no POST como está gravado, sem os espaços das pontas. Vazio, manda application/json. Escreva o tipo que o receptor espera, como application/json, application/x-ndjson, text/csv, text/plain ou application/json; charset=utf-8.

  • O campo só vale no Dinâmico e no HTTP. No formato JSON o aparelho manda sempre application/json, e no CSV sempre text/csv, seja qual for o campo. O MQTT não tem cabeçalhos.
  • O valor tem de ser um tipo de mídia: tipo/subtipo, só com letras sem acento, algarismos e sinais como ., + e -, e os parâmetros opcionais depois de um ;. O aparelho recusa, ao gravar, um valor sem a barra, como json, um com acento, como aplicação/json, e um com mais de 31 caracteres. O valor recusado não é gravado. Com Testar ou Aplicar agora, a página avisa Campos não aplicados: t_ct; Salvar e reiniciar reinicia sem mostrar o aviso.
  • Um valor inválido que chegue por outro caminho, como um backup restaurado, não sai no cabeçalho: o aparelho manda application/json no lugar dele.
  • Mudar o campo não reinicia o aparelho. O valor novo vale a partir do envio seguinte.

Até a v2.7.4, o Dinâmico mandava sempre text/plain, mesmo quando o resultado era JSON, e um receptor que exige JSON recusava o corpo. A linha de alarmes tem um campo igual e independente (capítulo 22).

Marcadores

Marcador Onde Vira
{DEV} 1. Global O nome do aparelho
{MAC} 1. Global O MAC, como 28:cd:c1:0a:1b:2c
{DATA} 1. Global As linhas do lote, unidas pelo separador
{TS} 2. Linha A hora do registro (epoch, UTC)
{DHT_ID} 2. Linha O uid do aparelho, como E6614C311B7A2F2D
{t0} a {t15} 2. Linha Temperatura do slot, com 2 casas
{u0} a {u15} 2. Linha Umidade do slot, com 1 casa
{p0} a {p15} 2. Linha Pressão, com 1 casa, só se aquele slot for o sensor de pressão

Apesar do nome, {DHT_ID} não tem relação com sensores DHT: é o número de série da placa. Os marcadores {tAMB}, {uAMB} e {pAMB} não existem mais; use os marcadores numerados. Um { que não abre um marcador conhecido é copiado como está, então chaves de JSON no modelo funcionam normalmente.

As três formas de um marcador de canal

Você escreve Com leitura Sem leitura
"t0_ID":{t0} "tSTM0001":4.25 (a chave vira t + identificador) A chave inteira some
"t0":{t0} "t0":4.25 A chave inteira some
"camara":{t0}, ou {t0} fora de uma chave "camara":4.25 "camara":null

A forma com _ID reproduz as chaves do formato JSON. Depois de montar a linha, o aparelho limpa as vírgulas que sobraram, em sequências como ,,, {,, [,, ,} e ,].

Para uma quebra de linha no 3. Separador, digite só \n: a barra e a letra, e nada mais no campo. Com o separador vazio, as linhas saem coladas.

Exemplos

Todos os exemplos usam os mesmos três registros do formato JSON; no terceiro, o sensor do slot 0 ficou sem leitura.

Com os modelos de fábrica:

{"dev":"simut","mac":"28:cd:c1:0a:1b:2c","data":[{"ts":1790168400,"tSTM0001":4.25},{"ts":1790168460,"tSTM0001":4.31},{"ts":1790168520}]}

O modelo de fábrica da linha só fala do slot 0. Para os dois sensores, use 2. Linha = {"ts":{TS},"t0_ID":{t0},"t1_ID":{t1},"u1_ID":{u1},"p1_ID":{p1}}:

{"dev":"simut","mac":"28:cd:c1:0a:1b:2c","data":[{"ts":1790168400,"tSTM0001":4.25,"tBME28001":22.81,"uBME28001":55.2,"pBME28001":1013.4},{"ts":1790168460,"tSTM0001":4.31,"tBME28001":22.84,"uBME28001":55.0,"pBME28001":1013.4},{"ts":1790168520,"tBME28001":22.90,"uBME28001":54.9,"pBME28001":1013.3}]}

Com nomes próprios, 1. Global = {"device":"{DEV}","payload":[{DATA}]} e 2. Linha = {"time":{TS},"camara":{t0},"ambiente":{t1},"umidade":{u1},"placa":"{DHT_ID}"}:

{"device":"simut","payload":[{"time":1790168400,"camara":4.25,"ambiente":22.81,"umidade":55.2,"placa":"E6614C311B7A2F2D"},{"time":1790168460,"camara":4.31,"ambiente":22.84,"umidade":55.0,"placa":"E6614C311B7A2F2D"},{"time":1790168520,"camara":null,"ambiente":22.90,"umidade":54.9,"placa":"E6614C311B7A2F2D"}]}

Um texto simples, uma linha por registro: 1. Global = {DATA}, 2. Linha = {TS};{t0};{t1};{u1};{p1} e 3. Separador = \n:

1790168400;4.25;22.81;55.2;1013.4
1790168460;4.31;22.84;55.0;1013.4
1790168520;null;22.90;54.9;1013.3

Nesse último, a última linha não termina com quebra de linha: o separador só vai entre os registros.

MQTT

Tópicos

Todos os tópicos derivam do campo Tópico. Com o valor fabrica/camara1/data:

Tópico Uso Retida Quem publica
fabrica/camara1/data Medições Conforme Reter O aparelho
fabrica/camara1/status Estado da conexão Sim O aparelho e o broker
fabrica/camara1/data/alarm Linha de alarmes Não O aparelho (capítulo 22)
fabrica/camara1/data/alarm/ack Confirmação dos alarmes — O seu coletor (capítulo 22)

O tópico de estado troca o último nível do Tópico por status: simut/data vira simut/status. Sem nenhuma / no tópico, o aparelho acrescenta /status.

O Home Assistant usa tópicos próprios, sob homeassistant/ (capítulo 23).

Mensagens de estado

Ao conectar, o aparelho registra no broker uma última vontade (Last Will) e publica a mensagem de conexão, as duas no tópico de estado, retidas, com QoS 0:

{"device":"simut","status":"online","ip":"192.0.2.10"}

Se o aparelho some sem se despedir, o broker publica a última vontade:

{"device":"simut","status":"offline"}

Mensagens de medição

O formato de cada mensagem depende do tamanho do lote:

Lote Mensagens Conteúdo de cada uma
Até 5 registros Uma por registro JSON: um objeto, sem os colchetes. CSV: uma linha, sem cabeçalho. Dinâmico: a linha, sem o envelope
Mais de 5 registros Uma só, com o lote inteiro O mesmo corpo do POST HTTP
Corpo acima de cerca de 8 KB Uma por registro Como no lote pequeno

Com o lote mínimo em 1 e o aparelho em dia, cada mensagem é um único objeto:

{"ts":1790168400,"tSTM0001":4.25,"tBME28001":22.81,"uBME28001":55.2,"pBME28001":1013.4}

Depois de uma parada, a fila sai em mensagens com arrays, como no HTTP.

As mensagens de medição não trazem o uid nem o nome do aparelho. No MQTT, o tópico é a identidade (capítulo 20).

Conexão

  • O aparelho tenta conectar no máximo uma vez a cada 5 s.
  • Cada operação de rede do MQTT tem 4 s de limite.
  • Uma conexão recusada registra o evento 36, MQTT desconectado, com o motivo no texto: Connection timeout (−4), Connection lost (−3), Connect failed (−2), Disconnected (−1), Bad protocol (1), Client ID rejected (2), Server unavailable (3), Bad credentials (4) ou Not authorized (5).
  • O aparelho só assina um tópico: o de confirmação da linha de alarmes, e só com a linha ligada (capítulo 22).

TLS e o arquivo /cert.pem

Com Usar TLS / SSL ligado, o aparelho fala HTTPS ou MQTTS com o coletor, na Porta configurada. Ajuste a porta: 443 para HTTPS e 8883 para MQTTS são o usual.

O que o aparelho oferece na negociação:

  • TLS 1.2, e nenhuma outra versão;
  • ECDHE com AES-GCM: ECDHE-ECDSA ou ECDHE-RSA, com AES-128-GCM-SHA256 ou AES-256-GCM-SHA384;
  • fragmentos de até 4.096 bytes, pela extensão Maximum Fragment Length (RFC 6066).

Um servidor que só aceite CBC, ChaCha20-Poly1305, TLS 1.1 ou troca de chave RSA estática não conecta. Um servidor que ignore o pedido de fragmento e mande um registro TLS maior que 4.096 bytes derruba a conexão: o aparelho não tem memória para um registro de 16 KB.

No HTTPS, a negociação tem 15 s de limite. Como o aparelho fecha a conexão depois de cada lote, cada lote paga uma negociação completa, que leva segundos neste processador.

Com e sem /cert.pem

O arquivo /cert.pem é o certificado, em PEM, da autoridade (CA) que assinou o certificado do coletor.

  1. Obtenha o certificado da CA, em formato PEM.
  2. Salve-o com o nome cert.pem.
  3. Na página Arquivos, envie o arquivo para a raiz do sistema de arquivos (capítulo 17).
  4. Ligue Usar TLS / SSL e use Salvar e reiniciar.

Não confunda com o certificado da interface web do aparelho, instalado pela página Rede (capítulo 9).

Situação O que acontece Evento no início
/cert.pem válido, até 16 KB O aparelho confere o certificado do coletor contra ele 34, Cert SSL carregado, com o tamanho
Sem /cert.pem Conexão cifrada, mas o aparelho aceita qualquer certificado 545, Sem cert.pem, modo inseguro, e 544 com o contexto 1
Arquivo vazio Como sem arquivo 543, cert.pem vazio, modo inseguro, e 544 com o contexto 1
Arquivo acima de 16 KB Recusado; como sem arquivo 544, Erro de leitura de cert.pem, com o tamanho, e 544 com o contexto 1

Sem certificado válido, a página mostra a faixa TLS sem validação de certificado — a conexão é cifrada mas não autenticada (MITM possível). Envie /cert.pem em Arquivos para validar o servidor.

  • O aparelho lê o arquivo só ao iniciar, e só com o TLS ligado. Depois de enviar ou trocar o arquivo, reinicie.
  • Cadeias assinadas com MD5 ou SHA-1 não passam na verificação.
  • Use um certificado emitido para o nome ou o endereço que você digitou em IP Servidor, dentro do prazo de validade, e mantenha o relógio do aparelho sincronizado. Assim a verificação não depende de nenhum detalhe de como o aparelho compara nome e data.

Filas longas

Quando o coletor volta de uma parada, o aparelho esvazia a fila em lotes, no ritmo do coletor (O ritmo entre lotes), até alcançar o presente.

  • A janela é de 30 dias. Sem cursor, depois de Resetar cursor de envio, ou na primeira vez que a telemetria é ligada, o aparelho começa 30 dias antes do registro mais novo. O que é mais antigo que isso não sai pela telemetria; recupere pelo histórico (capítulo 15).
  • Ligar a telemetria pela primeira vez envia até 30 dias de histórico. Prepare o coletor para essa primeira carga.
  • O contador de pendentes segue a mesma janela, e para de contar em 65.535.

Registros com hora fora de ordem

O cursor é uma posição no arquivo, não um instante. Um registro sai na ordem em que foi gravado, qualquer que seja a hora que carrega:

  • Um bloco gravado depois de outro, mas com hora anterior, sai normalmente. É o que acontece quando o relógio volta: a hora provisória do boot corrigida pelo NTP, um acerto manual.
  • Um registro com hora mais de 1 dia à frente do relógio do aparelho não sai pela telemetria. Continua no histórico.
  • Um bloco gravado num arquivo de dia com mais de 3 dias não sai pela telemetria. Para isso o relógio precisa voltar mais de três dias. O bloco continua no histórico.
  • Quando o aparelho não consegue saber o que já saiu de um arquivo de dia, ele manda o arquivo inteiro de novo e registra o evento 554, Arquivo do dia reenviado pela telemetria. Isso acontece quando o aparelho perde energia logo depois de enviar registros que ainda estavam só na RAM, quando um arquivo de dia é apagado e quando uma restauração de backup o traz de volta.

Até a v2.9.0, o cursor era um instante, e um bloco gravado com hora anterior ao último registro enviado não saía mais. Depois da atualização, o cursor antigo continua valendo para os arquivos de dia até o do último registro enviado, até a primeira entrega em cada um; a posição vale para todo o resto. Se esse cursor antigo estiver à frente do relógio, o relógio voltou depois do último envio:

  • até 1 h à frente, com o relógio confiável (NTP ou acerto à mão), o aparelho deixa o cursor antigo de lado e manda o arquivo do dia de novo, inteiro, com o evento 554;
  • mais de 1 h à frente do registro mais novo, ou do relógio, ele zera o cursor e registra um aviso com o texto Telemetry cursor ahead of data — reset to 0. Os envios recomeçam pela janela de 30 dias.

Duplicatas e idempotência

O aparelho prefere enviar duas vezes a deixar um buraco. Duplicatas acontecem por desenho:

  • a resposta 2xx se perde no caminho de volta, e o aparelho reenvia o lote;
  • o aparelho perde energia antes de gravar o cursor na flash, o que ele faz no máximo a cada 5 s;
  • no MQTT, a conexão cai logo depois da publicação;
  • o aparelho não consegue saber o que já saiu de um arquivo de dia e o manda inteiro (Registros com hora fora de ordem);
  • alguém usa Resetar cursor de envio.

Por isso, o coletor precisa ser idempotente. A chave natural de uma medição é o aparelho, a hora e o canal: (X-SIMUT-Uid, ts, chave do canal). Grave com “insira se não existir”:

CREATE TABLE leitura (
  uid   TEXT    NOT NULL,
  ts    INTEGER NOT NULL,
  canal TEXT    NOT NULL,
  valor REAL    NOT NULL,
  PRIMARY KEY (uid, ts, canal)
);

-- SQLite
INSERT OR IGNORE INTO leitura (uid, ts, canal, valor) VALUES (?, ?, ?, ?);

-- PostgreSQL
INSERT INTO leitura (uid, ts, canal, valor) VALUES ($1, $2, $3, $4)
ON CONFLICT (uid, ts, canal) DO NOTHING;

Receptores mínimos

Os receptores abaixo gravam, sem duplicar, e só então confirmam. Todos esperam a configuração:

  • Transporte: HTTP(S), com TLS desligado;
  • IP Servidor: o endereço da máquina do receptor;
  • Porta: 8080;
  • Endpoint: /api/telemetria;
  • API Key: troque-este-segredo;
  • Formato: JSON. O receptor em Python puro também aceita CSV.

Os receptores leem o token da variável de ambiente SIMUT_TOKEN, que deve ter o mesmo valor do campo API Key do aparelho. Use um valor diferente para cada aparelho, e não o escreva no código.

Python, só com a biblioteca padrão

Este receptor atende a telemetria em JSON e em CSV e também a linha de alarmes em JSON, no caminho de fábrica dela, /api/telemetria/alarm (capítulo 22). Ele grava num arquivo SQLite e só responde 204 depois de gravar.

#!/usr/bin/env python3
"""Coletor minimo do SIMUT: telemetria (JSON ou CSV) e linha de alarmes (JSON)."""
import csv
import io
import json
import os
import sqlite3
import threading
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

TOKEN = os.environ["SIMUT_TOKEN"]       # o mesmo valor do campo API Key
PORTA = 8080

banco = sqlite3.connect("simut.db", check_same_thread=False)
trava = threading.Lock()
banco.executescript("""
CREATE TABLE IF NOT EXISTS leitura (
  uid TEXT NOT NULL, ts INTEGER NOT NULL, canal TEXT NOT NULL, valor REAL NOT NULL,
  PRIMARY KEY (uid, ts, canal));
CREATE TABLE IF NOT EXISTS alarme (
  uid TEXT NOT NULL, ts INTEGER NOT NULL, seq INTEGER NOT NULL, id TEXT NOT NULL,
  codigo TEXT, usuario TEXT, registro TEXT NOT NULL,
  PRIMARY KEY (uid, ts, seq, id));
""")


def leituras_json(corpo):
    dados = json.loads(corpo)
    if isinstance(dados, dict):          # um registro sozinho
        dados = [dados]
    for registro in dados:
        ts = int(registro.pop("ts"))
        for canal, valor in registro.items():
            yield ts, canal, float(valor)


def leituras_csv(corpo):
    linhas = csv.reader(io.StringIO(corpo), delimiter=";")
    cabecalho = next(linhas, None)
    if cabecalho is None:
        raise ValueError("CSV vazio")
    for linha in linhas:
        if not linha:
            continue
        ts = int(linha[0])
        for coluna, valor in zip(cabecalho[1:], linha[1:]):
            if valor != "":              # vazio = sem leitura
                yield ts, coluna, float(valor)


class Coletor(BaseHTTPRequestHandler):
    def responder(self, codigo):
        self.send_response(codigo)
        self.send_header("Content-Length", "0")
        self.end_headers()

    def do_POST(self):
        if self.path not in ("/api/telemetria", "/api/telemetria/alarm"):
            return self.responder(404)
        if self.headers.get("Authorization") != "Bearer " + TOKEN:
            return self.responder(401)
        uid = self.headers.get("X-SIMUT-Uid", "desconhecido")
        tamanho = int(self.headers.get("Content-Length", "0"))
        corpo = self.rfile.read(tamanho).decode("utf-8")
        tipo = self.headers.get("Content-Type", "")
        try:
            with trava, banco:           # grava tudo ou nada
                if self.path == "/api/telemetria":
                    origem = leituras_csv(corpo) if tipo.startswith("text/csv") else leituras_json(corpo)
                    banco.executemany(
                        "INSERT OR IGNORE INTO leitura VALUES (?, ?, ?, ?)",
                        [(uid, ts, canal, valor) for ts, canal, valor in origem])
                else:
                    for r in json.loads(corpo):
                        codigo = r.get("alarm") or r.get("err") or r.get("maint")
                        banco.execute(
                            "INSERT OR IGNORE INTO alarme VALUES (?, ?, ?, ?, ?, ?, ?)",
                            (uid, r["ts"], r["seq"], r["id"], codigo, r.get("user"),
                             json.dumps(r)))
        except (ValueError, KeyError, TypeError, AttributeError) as erro:
            self.log_error("corpo recusado de %s: %s", uid, erro)
            return self.responder(400)   # nao confirma: o aparelho reenvia
        self.responder(204)              # gravado: pode confirmar


if __name__ == "__main__":
    print(f"Coletor SIMUT na porta {PORTA}")
    ThreadingHTTPServer(("0.0.0.0", PORTA), Coletor).serve_forever()

Salve como coletor.py, ponha o token na variável SIMUT_TOKEN e rode com python3 coletor.py. O programa precisa do Python 3.7 ou mais novo.

Flask

# pip install flask
import os
import sqlite3
from contextlib import closing

from flask import Flask, abort, request

TOKEN = os.environ["SIMUT_TOKEN"]
app = Flask(__name__)

with closing(sqlite3.connect("simut.db")) as con:
    con.execute("""CREATE TABLE IF NOT EXISTS leitura (
        uid TEXT NOT NULL, ts INTEGER NOT NULL, canal TEXT NOT NULL, valor REAL NOT NULL,
        PRIMARY KEY (uid, ts, canal))""")


@app.post("/api/telemetria")
def telemetria():
    if request.headers.get("Authorization") != f"Bearer {TOKEN}":
        abort(401)
    uid = request.headers.get("X-SIMUT-Uid", "desconhecido")
    dados = request.get_json(force=True, silent=True)   # formato JSON
    if dados is None:
        abort(400)                       # nao confirma: o aparelho reenvia
    if isinstance(dados, dict):
        dados = [dados]
    linhas = []
    for registro in dados:
        ts = registro.pop("ts")
        linhas += [(uid, ts, canal, valor) for canal, valor in registro.items()]
    with closing(sqlite3.connect("simut.db")) as con, con:
        con.executemany("INSERT OR IGNORE INTO leitura VALUES (?, ?, ?, ?)", linhas)
    return "", 204                       # gravado: pode confirmar


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Node.js e Express

// npm install express
const express = require("express");

const TOKEN = process.env.SIMUT_TOKEN;
const app = express();
app.use(express.text({ type: "*/*", limit: "1mb" }));  // corpo cru, qualquer Content-Type

const gravados = new Set();  // troque por um banco com chave unica (uid, ts, canal)

app.post("/api/telemetria", (req, res) => {
  if (req.get("Authorization") !== `Bearer ${TOKEN}`) return res.sendStatus(401);
  const uid = req.get("X-SIMUT-Uid") || "desconhecido";

  let dados;
  try {
    dados = JSON.parse(req.body);            // formato JSON
  } catch {
    return res.sendStatus(400);              // nao confirma: o aparelho reenvia
  }
  if (!Array.isArray(dados)) dados = [dados];

  for (const { ts, ...canais } of dados) {
    for (const [canal, valor] of Object.entries(canais)) {
      const chave = `${uid}|${ts}|${canal}`;
      if (gravados.has(chave)) continue;     // duplicata: ignora
      gravados.add(chave);
      console.log(uid, ts, canal, valor);
    }
  }
  res.sendStatus(204);                       // gravado: pode confirmar
});

app.listen(8080, () => console.log("Coletor SIMUT na porta 8080"));

MQTT com mosquitto

Uma configuração mínima do broker mosquitto, com senha:

# /etc/mosquitto/conf.d/simut.conf
listener 1883
allow_anonymous false
password_file /etc/mosquitto/senhas
  1. Crie o usuário do aparelho: sudo mosquitto_passwd -c /etc/mosquitto/senhas simut.
  2. Crie o usuário do coletor: sudo mosquitto_passwd /etc/mosquitto/senhas coletor.
  3. Reinicie o broker: sudo systemctl restart mosquitto.
  4. No aparelho, use Porta 1883, Usuário simut e a senha criada no passo 1.

Para MQTTS, acrescente um segundo listener com o certificado do broker:

listener 8883
certfile /etc/mosquitto/certs/broker.crt
keyfile /etc/mosquitto/certs/broker.key
cafile /etc/mosquitto/certs/ca.crt

No aparelho, use Porta 8883, ligue Usar MQTTS (TLS) e envie o ca.crt como /cert.pem.

Para ver tudo o que o aparelho publica, com o nome do tópico antes de cada mensagem:

mosquitto_sub -h coletor.exemplo.com.br -p 1883 -u coletor -P 'senha-do-coletor' -v -t 'simut/#'
simut/status {"device":"simut","status":"online","ip":"192.0.2.10"}
simut/data {"ts":1790168400,"tSTM0001":4.25,"tBME28001":22.81,"uBME28001":55.2,"pBME28001":1013.4}

O mosquitto_sub só mostra. Um programa que grave as medições precisa das mesmas regras do HTTP: aceitar objeto e array, e gravar sem duplicar. O capítulo 22 traz um assinante completo em Python, que também confirma os alarmes.

Testar a integração

Antes de ligar um aparelho, teste o coletor com o curl, mandando exatamente o que o aparelho manda:

curl -i http://coletor.exemplo.com.br:8080/api/telemetria \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer troque-este-segredo' \
  -H 'X-SIMUT-Uid: E6614C311B7A2F2D' \
  -H 'X-SIMUT-Ver: 2.7.1' \
  -H 'X-SIMUT-Env: release' \
  -H 'X-SIMUT-Cfg: 3F2A91C4' \
  --data-binary '[{"ts":1790168400,"tSTM0001":4.25,"tBME28001":22.81,"uBME28001":55.2,"pBME28001":1013.4}]'

A primeira linha da resposta deve trazer o código 204, ou outro código 2xx. Mande o mesmo comando duas vezes e confira que o banco não duplicou a medição. Mande também um corpo inválido, como --data-binary '[{', e confira que o coletor responde 400 sem gravar nada.

Depois, com o aparelho:

  1. Rode o receptor numa máquina da mesma rede e anote o endereço dela.
  2. Na página Telemetria, preencha IP Servidor, Porta, Endpoint e API Key.
  3. Ponha Lote mínimo (registros) em 1.
  4. Use Aplicar agora.
  5. Toque em Enviar agora.
  6. Confira no receptor o POST recebido.
  7. No Painel de Controle, confira Registros Pendentes caindo até Sincronizado, e Telemetria Env. subindo (capítulo 13).
  8. Na página Histórico e Logs, em Eventos do Sistema, confira o evento 30, Telemetria enviada.

Nas imagens com o console completo (capítulo 14), o comando tel dump imprime no console o próximo corpo montado, entre === PAYLOAD SYNC (<n> B) === e === END ===, quebrado em linhas a cada vírgula.

Códigos do log de eventos

Código Evento Quando
30 Telemetria enviada Lote aceito com 2xx; o contexto é o código HTTP
31 Falha de telemetria Cada resposta fora de 2xx (contexto = código) ou erro de conexão (contexto negativo). Depois do 547, também uma vez por hora, com o texto Still failing (#n)
32 Retry de telemetria Nova tentativa agendada, com o texto Upload failed (#n). Retry in <s>s; até a 10ª falha seguida
33 Telemetria enfileirada MQTT: corpo grande demais, publicado registro a registro
34 Cert SSL carregado Início, com /cert.pem válido
35 MQTT conectado Conexão com o broker
36 MQTT desconectado Conexão recusada, ou perdida logo depois de uma publicação
37 MQTT publicado Mensagens de medição publicadas
303 Config alterada Cursor apagado por Resetar cursor de envio
540 Transporte HTTP inicializado Início, transporte HTTP; o contexto é a porta
541 Transporte MQTT inicializado Início, transporte MQTT; o contexto é a porta
542 MQTT conectando Cada tentativa de conexão, com o Client ID
543 cert.pem vazio, modo inseguro Início, com TLS e arquivo vazio
544 Erro de leitura de cert.pem Início, com TLS: arquivo ilegível ou grande demais; com o contexto 1, aviso de TLS sem validação
545 Sem cert.pem, modo inseguro Início, com TLS e sem o arquivo
546 Forçando sync de telemetria Enviar agora; o contexto é a conta
547 Logs de retry suprimidos A partir da 11ª falha seguida
554 Arquivo do dia reenviado pela telemetria O cursor não confere mais com o que o arquivo do dia guarda, e o arquivo sai inteiro de novo; o contexto é o mês e o dia (MMDD)

O log de eventos guarda transições, não repetições. Da família da telemetria, ele grava a primeira falha depois de um período saudável, o primeiro sucesso depois de uma falha e um registro por hora enquanto nada muda. O console serial mostra todas as linhas (capítulo 16).

Contexto negativo do evento 31

Contexto Significado
−1 Conexão falhou: servidor fora do ar, porta fechada, nome não resolvido ou TLS recusado
−2 Falha ao enviar os cabeçalhos
−3 Falha ao enviar o corpo
−4 Sem conexão
−5 Conexão perdida
−7 O servidor não respondeu como HTTP
−8 Memória insuficiente
−11 Tempo esgotado: nenhuma resposta em 4 s

Solução de problemas

Sintoma Causa provável O que fazer
Registros Pendentes cresce e nada sai Lote mínimo em 0, ou sinal em −78 dBm ou abaixo Defina o Lote mínimo; melhore o sinal
Evento 31 com o contexto −1 Servidor, porta ou nome errado; firewall; TLS incompatível Confira IP Servidor e Porta; teste com curl da mesma rede
Evento 31 com o contexto −11 O coletor leva mais de 4 s para responder Grave mais rápido ou responda assim que gravar
Evento 31 com o contexto 301 ou 302 O coletor redireciona, e o aparelho não segue Aponte para o endereço final; para HTTPS, ligue o TLS
Evento 31 com o contexto 401 ou 403 Chave de acesso errada ou ausente Confira a API Key e a forma do cabeçalho (A chave de acesso)
Evento 31 com o contexto 404 Endpoint errado Confira o caminho, começando com /
HTTP funciona, HTTPS falha com o contexto −1 Versão de TLS, cifras ou fragmento de 4.096 bytes não aceitos O servidor precisa de TLS 1.2 com ECDHE-GCM e da extensão Maximum Fragment Length
A faixa TLS sem validação de certificado aparece Sem /cert.pem válido Envie o certificado da CA como /cert.pem e reinicie
MQTT: evento 36 com Bad credentials ou Not authorized Usuário ou Senha errados, ou falta de permissão no broker Confira o usuário, a senha e a lista de acesso do broker
MQTT: nada chega e a porta é 80 A Porta não muda ao trocar o transporte Use 1883 (MQTT) ou 8883 (MQTTS)
O assinante MQTT quebra com um array Depois de uma parada, a fila sai em lotes com array Aceite objeto e array (Mensagens de medição)
O coletor recebe "camara":null Forma simples do marcador, com o sensor sem leitura Use "t0_ID":{t0} ou "t0":{t0} para a chave sumir
JSON inválido no formato Dinâmico Modelo mal escrito Confira a Prévia ao Vivo e o primeiro corpo recebido
O coletor recusa o corpo do formato Dinâmico (evento 31 com o contexto 400 ou 415), embora ele seja válido O Content-Type não é o que o coletor exige. Até a v2.7.4, o Dinâmico mandava sempre text/plain Preencha o Cabeçalho Content-Type com o tipo que o coletor espera (O cabeçalho Content-Type)
Campos não aplicados: t_ct O valor não é um tipo de mídia: falta a barra, tem acento ou passa de 31 caracteres Escreva tipo/subtipo, como application/json
Medições repetidas no banco Duplicatas por desenho Grave com chave única (uid, ts, canal)
Buraco nas medições depois de horas sem coletor Registros com mais de 30 dias antes do mais novo, ou hora fora de ordem Recupere pelo histórico do aparelho (capítulo 15)
Primeira ativação manda milhares de registros O aparelho começa 30 dias antes do registro mais novo Esperado; prepare o coletor para a carga inicial
Aviso Telemetry cursor ahead of data — reset to 0 O relógio andou para trás, e o cursor ficou no futuro Nada a fazer; confira o NTP (capítulo 10)
Os envios param enquanto alguém usa o painel O painel tem prioridade Esperado; os envios voltam 5 s depois do último toque

Voltar ao sumário

Capítulo 22

Linha de alarmes

Este capítulo explica a segunda linha de telemetria do SIMUT: os eventos de alarme, falha, manutenção e ação no painel, entregues em segundos e com confirmação de recebimento. Ele é para quem configura a linha e para quem escreve o coletor que vai receber e confirmar os eventos.

Para que serve

A telemetria de medições entrega tudo, no ritmo do lote (capítulo 21). Com um lote mínimo de 60 registros, um limite ultrapassado agora só chega ao coletor daqui a uma hora. A linha de alarmes resolve isso: cada evento vai para o coletor assim que acontece, separado das medições.

A linha manda eventos, não medições:

  • um canal saiu dos limites de alarme;
  • um sensor entrou em falha;
  • alguém silenciou, desligou ou religou um alarme, ou mudou um limite, no painel;
  • uma janela de manutenção abriu ou fechou.

As duas linhas se completam. A telemetria diz quanto; a linha de alarmes diz o que aconteceu e quem fez.

Telemetria Linha de alarmes
O que manda Registros do histórico Eventos
Quando Ao juntar o lote mínimo Assim que o evento acontece
Onde espera Na flash Numa fila na RAM
Um reinício Não perde nada Perde o que não foi confirmado
Confirmação 2xx (HTTP) ou publicação aceita (MQTT) 2xx (HTTP) ou mensagem de confirmação (MQTT)

A linha de alarmes vem desligada de fábrica.

Como a linha funciona

  1. Um evento entra na fila, com um número de sequência, seq.
  2. O aparelho envia a fila inteira ao coletor, na mesma passada.
  3. O coletor confirma os registros que recebeu.
  4. O aparelho tira da fila só os registros confirmados.
  5. Enquanto sobrar algo na fila, o aparelho envia de novo a cada 15 s. Um evento novo dispara um envio imediato.

A linha usa o transporte, o servidor, a porta, a chave de acesso e o TLS da telemetria de medições. Só o formato e o caminho são próprios dela.

Figura 190. Legenda: no HTTP, a resposta 2xx confirma o lote. No MQTT, a publicação não confirma nada: só a mensagem de confirmação do coletor tira os registros da fila.

Os códigos

Cada registro pertence a um só domínio, e o domínio dá o nome do campo que carrega o código:

Campo Código Significa Traz também
alarm alarm Um canal saiu dos limites val
alarm alarm_sil Alguém silenciou o alarme de limite no painel —
alarm alarm_off Os alarmes do sensor foram desligados no painel user
alarm alarm_on Os alarmes do sensor foram religados no painel user
alarm alarm_lim Um limite foi mudado no painel lo, hi, user
err err O sensor entrou em falha —
err err_sil Alguém silenciou o alarme de falha no painel —
err err_off O alarme de falha do sensor foi desativado no painel user
maint maint_on Uma janela de manutenção abriu until, e user quando alguém a abriu
maint maint_off A janela fechou, por comando ou por prazo user quando alguém a fechou

Quando cada código aparece

  • alarm. Um canal ficou fora da faixa entre o limite mínimo e o máximo em duas verificações seguidas. Só com os alarmes do sensor ligados e fora de manutenção. Sai um registro por saída da faixa, por canal: enquanto o valor continua fora, nada mais sai. O val é o valor lido naquela hora.
  • err. O sensor parou de responder ou foi trocado por outro (divergência de hardware). Sai mesmo com os alarmes de limite do sensor desligados, mas não com a falha desativada (err_off) nem em manutenção.
  • alarm_sil e err_sil. Alguém tocou em Silenciar 120s no aviso de alarme do painel. O código depende do alarme ativo no sensor: falha ou limite. O registro não traz user.
  • alarm_off e err_off. Alguém tocou em Desativar no aviso de alarme do painel, depois do PIN, com a permissão PERM_ALARM_BLOCK. Em falha, isso desativa só o alarme de falha (err_off), e os limites continuam armados; em limite, desliga os alarmes de limite do sensor (alarm_off).
  • alarm_off e alarm_on também saem quando alguém desliga ou religa os Alarmes do sensor no menu do painel, com a mesma permissão.
  • alarm_lim. Alguém gravou o editor de Limites de alarme do sensor no painel, com a permissão PERM_ALARM_LIMITS. Sai um registro por canal cujo par de limites mudou.
  • maint_on e maint_off. Uma janela de manutenção abriu ou fechou, pelo painel, com a permissão PERM_MAINT, ou pela interface web (capítulo 7). A saída por prazo gera maint_off sem user.

Manutenção evita o falso alarme

Enquanto a janela de manutenção de um sensor está aberta, ele não gera alarm nem err. O coletor recebe exatamente dois registros, maint_on na entrada e maint_off na saída, e sabe que o silêncio entre eles é intencional. Ao sair da janela com o valor ainda fora da faixa, o sensor volta a alarmar e gera um alarm novo.

Depois de um reinício

O aparelho volta sem memória das bordas. Depois de cada reinício, e também ao ligar a linha:

  • um canal que já está fora da faixa gera um alarm novo;
  • um sensor que já está em falha gera um err novo;
  • uma janela de manutenção ainda aberta gera um maint_on novo, sem user.

A fila da RAM se perdeu no reinício, então esses registros refazem o estado para o coletor. Trate-os como a confirmação do estado, não como eventos novos.

O registro

Campo Sempre? Conteúdo
ts Sim A hora do evento, em segundos desde 01/01/1970, UTC
id Sim A letra da grandeza e o identificador do sensor, como tSTM0001
seq Sim O número de sequência desde o último reinício. É a chave da confirmação
val Só em alarm O valor que saiu da faixa
alarm, err ou maint Um deles O código do evento
lo e hi Só em alarm_lim Os limites novos, mínimo e máximo
until Só em maint_on A hora prevista do fim da janela, com precisão de 1 minuto
user Quando houve uma pessoa O nome da conta que agiu
  • id. A letra vem da grandeza: t temperatura, u umidade, p pressão, l luminosidade. Num evento de limite, é a grandeza que saiu da faixa, e num alarm_lim, a que mudou. Nos demais códigos, é a primeira grandeza do sensor: t para todos os tipos atuais. Sem identificador, vem o número do slot, como t3.
  • Números. val, lo e hi usam 2 casas para temperatura e 1 casa para as demais grandezas.
  • seq. Começa em 1 a cada reinício e só cresce, até 65.535, quando volta a 1. Não use o seq sozinho como chave: use (X-SIMUT-Uid, ts, seq).
  • user. O nome fica gravado no registro no momento da ação. Se a conta for apagada, ou o nome for reaproveitado, o registro que já está na fila continua com o nome de quem agiu.
  • Campos ausentes somem. Um campo que não se aplica ao código não aparece: não vem vazio nem nulo.

Formatos

Os exemplos usam seis eventos de um aparelho com dois sensores: um DS18B20 com o identificador STM0001, no slot 0, e um BME280 com o identificador BME28001, no slot 1.

  1. A temperatura do slot 0 passou do máximo, com 8,52 °C.
  2. Alguém tocou em Silenciar 120s.
  3. O BME280 parou de responder.
  4. A conta joao abriu 2 h de manutenção no slot 0.
  5. A conta joao mudou os limites de umidade do slot 1 para 30,0 e 70,0.
  6. A janela do slot 0 venceu.

Na página, a Prévia ao Vivo da linha mostra os três formatos com os dados deste aparelho: um registro de cada um dos dez códigos, na ordem da tabela Os códigos, com os sensores, os limites, a conta e a hora dele.

  • O alarm traz a leitura de agora do primeiro sensor ativo.
  • O alarm_lim traz os limites de umidade de um sensor que mede umidade, ou os de temperatura quando nenhum mede.
  • O maint_on abre uma janela de 2 h.

Os eventos são exemplos. Os campos e o formato são os que o coletor recebe.

JSON

O corpo é um array, com um objeto por registro, montado pelo modelo 2. Linha da linha de alarmes. Com o modelo de fábrica:

[{"ts":1790168700,"id":"tSTM0001","val":8.52,"alarm":"alarm","seq":1},{"ts":1790168760,"id":"tSTM0001","alarm":"alarm_sil","seq":2},{"ts":1790169000,"id":"tBME28001","err":"err","seq":3},{"ts":1790169300,"id":"tSTM0001","maint":"maint_on","until":1790176500,"user":"joao","seq":4},{"ts":1790169420,"id":"uBME28001","alarm":"alarm_lim","lo":30.0,"hi":70.0,"user":"joao","seq":5},{"ts":1790176500,"id":"tSTM0001","maint":"maint_off","seq":6}]

O modelo de fábrica da linha é:

{"ts":{TS},"id":"{ID}","val":{val},"alarm":{alarm},"err":{err},"maint":{maint},"lo":{lo},"hi":{hi},"until":{until},"user":{user},"seq":{seq}}

CSV

Um cabeçalho fixo e uma linha por registro, separados por ;, cada linha terminada por \n:

seq;ts;id;v;user;lo;hi;until
1;1790168700;tSTM0001;8.52;;;;
2;1790168760;tSTM0001;alarm_sil;;;;
3;1790169000;tBME28001;err;;;;
4;1790169300;tSTM0001;maint_on;joao;;;1790176500
5;1790169420;uBME28001;alarm_lim;joao;30.0;70.0;
6;1790176500;tSTM0001;maint_off;;;;

A coluna v traz o valor num alarm e o código em todos os outros registros. As colunas user, lo, hi e until ficam vazias quando não se aplicam. O CSV não usa os modelos.

Dinâmico

O corpo é o modelo 1. Global, com {DATA} trocado pelas linhas unidas pelo 3. Separador. Com os modelos de fábrica:

{"dev":"simut","mac":"28:cd:c1:0a:1b:2c","alarms":[{"ts":1790168700,"id":"tSTM0001","val":8.52,"alarm":"alarm","seq":1},{"ts":1790168760,"id":"tSTM0001","alarm":"alarm_sil","seq":2},{"ts":1790169000,"id":"tBME28001","err":"err","seq":3},{"ts":1790169300,"id":"tSTM0001","maint":"maint_on","until":1790176500,"user":"joao","seq":4},{"ts":1790169420,"id":"uBME28001","alarm":"alarm_lim","lo":30.0,"hi":70.0,"user":"joao","seq":5},{"ts":1790176500,"id":"tSTM0001","maint":"maint_off","seq":6}]}

O 1. Global aceita {DEV}, {MAC} e {DATA}, como na telemetria. O 2. Linha aceita:

Marcador Vira Forma composta
{TS} A hora do evento Não
{ID} Letra da grandeza e identificador, sem aspas Não
{HWID} O identificador do sensor, sem aspas Não
{SLOT} O número do slot, de 0 a 15 Não
{CH} A letra da grandeza: t, u, p ou l Não
{VAL} ou {val} O valor, só em alarm Sim
{ALARM} ou {alarm} O código de limite, com aspas Sim
{ERR} ou {err} O código de falha, com aspas Sim
{MAINT} ou {maint} O código de manutenção, com aspas Sim
{LO} ou {lo}, {HI} ou {hi} Os limites novos, só em alarm_lim Sim
{UNTIL} ou {until} O fim previsto, só em maint_on Sim
{USER} ou {user} O nome da conta, com aspas Sim
{SEQ} ou {seq} O número de sequência Sim

A forma composta é uma chave com o mesmo nome do marcador, escrito do mesmo jeito, seguida do marcador sem aspas: "val":{val}, "ALARM":{ALARM}, "user":{user}. Quando o marcador não tem valor naquele registro, a chave inteira some. Depois de montar a linha, o aparelho limpa as vírgulas que sobraram.

Fora da forma composta, um marcador sem valor vira texto vazio, e não null, como na telemetria. "valor":{VAL} num registro de falha produz "valor":,, que é JSON inválido. Use a forma composta para todo campo que pode faltar.

Os códigos já vêm com aspas: escreva "alarm":{alarm}, e não "alarm":"{alarm}".

No HTTP, o corpo sai com o Content-Type do campo Cabeçalho Content-Type da linha de alarmes, que vazio vale application/json (Entrega por HTTP).

Entrega por HTTP

O aparelho faz um POST com a fila inteira, no máximo 64 registros, para:

  • o Caminho HTTP da linha, se estiver preenchido;
  • senão, o Endpoint da telemetria seguido de /alarm. Com o Endpoint /api/telemetria, o caminho é /api/telemetria/alarm; com o de fábrica, /api.php/alarm.

A requisição tem a mesma forma da telemetria (capítulo 21): mesmos cabeçalhos de identidade, mesma chave de acesso, Content-Type conforme o formato da linha: application/json no JSON, text/csv no CSV e, no Dinâmico, o Cabeçalho Content-Type da linha de alarmes, que vazio vale application/json. Até a v2.7.4, o Dinâmico saía sempre como text/plain.

O coletor responde O aparelho faz Evento
200 a 299 Tira da fila todos os registros daquele corpo 550 e 552
Outro código Mantém a fila e tenta de novo em 15 s 551, com o código
Nada em 4 s, ou erro de conexão Mantém a fila e tenta de novo em 15 s 551, com o contexto negativo
  • A linha de alarmes não tem espera crescente: um coletor fora do ar recebe uma tentativa a cada 15 s, e mais uma a cada evento novo.
  • Um coletor que responde 2xx sem gravar perde os eventos: depois da confirmação, eles não voltam.
  • Com pouca memória livre, o aparelho pode mandar só uma parte da fila; o resto vai no envio seguinte.

Entrega por MQTT

Com o Tópico simut/data:

Tópico Quem publica Conteúdo
simut/data/alarm O aparelho A fila inteira, numa mensagem, com QoS 0, não retida
simut/data/alarm/ack O seu coletor A confirmação

A publicação não confirma nada: com QoS 0, o broker não avisa o aparelho. Os registros continuam na fila até o coletor publicar a confirmação:

{"seq":[1,2,3]}
  • Publique no tópico da mensagem recebida, seguido de /ack. O aparelho assina esse tópico com QoS 1, a cada conexão.
  • Liste os seq que você gravou. O aparelho tira da fila os registros com esses números e ignora os que não conhece. Uma mensagem de confirmação vale para até 64 números.
  • Escreva a lista compacta, com números sem aspas. O aparelho lê a primeira lista entre colchetes da mensagem e para no primeiro caractere inesperado. Aspas em volta dos números, ou uma quebra de linha logo depois de um número, cortam a leitura ali.
  • Nunca publique a confirmação como retida. O seq recomeça em 1 a cada reinício. Uma confirmação retida seria entregue de novo depois do reinício e apagaria registros novos com os mesmos números.
  • Confirme em menos de 15 s. Enquanto a confirmação não chega, o aparelho publica a fila inteira de novo a cada 15 s, e o coletor recebe os mesmos registros repetidos.

Vários aparelhos no mesmo broker precisam de tópicos diferentes. Com o mesmo Tópico, eles dividiriam o tópico de confirmação, e a confirmação de um tiraria da fila do outro os registros com os mesmos números.

A fila

  • Capacidade. O Tamanho da fila (RAM), de 1 a 64; de fábrica, 32.
  • Fila cheia. O evento novo é recusado, e os mais antigos ficam. O aparelho registra o evento 553, Estouro da fila de alarmes, com o total recusado desde o último reinício. O registro mais antigo é o que mais provavelmente ainda descreve um alarme em curso, e descartá-lo esconderia um alarme nunca confirmado.
  • Um alarme recusado volta quando houver espaço. Uma borda de limite ou de falha recusada com a fila cheia é oferecida de novo assim que a fila tiver espaço, se a condição ainda estiver ativa. O registro sai com a hora e o valor daquele momento, e o evento 553 conta a recusa uma vez só. Uma condição que terminou antes disso não gera registro. Ações (silenciar, desativar) e bordas da janela de manutenção recusadas não voltam. Até a v2.8.0, a borda recusada ficava marcada como enviada e só voltava depois de um reinício.
  • Diminuir a capacidade com a fila cheia descarta os registros mais antigos até caber.
  • Reinício. A fila vive na RAM: um reinício perde tudo o que não foi confirmado. Os registros de estado depois do reinício (Depois de um reinício) refazem o que ainda vale.
  • Linha desligada. Com a linha desligada, nada entra na fila e nada sai. O que já estava nela volta a sair quando a linha é religada.
  • Sinal e memória. Como na telemetria, nada sai com o sinal Wi-Fi em −78 dBm ou abaixo, com menos de 24 KB livres (com TLS) ou 14 KB (sem TLS), ou enquanto o painel está num menu. A fila espera.

No Air, os alarmes só são avaliados com o aparelho acordado (M0). Num despertar do ciclo (M1), ele lê os sensores e grava o histórico, mas não confere limites nem gera eventos da linha de alarmes. E cada despertar termina num reinício do processador, então a fila, que vive na RAM, não atravessa o sono.

Os campos

Os campos ficam no bloco Payload de Alarmes — 2ª Linha de Telemetria (Alarm Payload — 2nd Telemetry Line), no fim da página Telemetria (capítulo 21). Nenhum deles exige reinício.

Campo Chave na API Faixa De fábrica
Habilitar linha de telemetria de alarmes (Enable alarm telemetry line) a_en Ligado ou desligado Desligado
Formato (Format) a_mode JSON = 0; CSV = 1; Dinâmico = 2 JSON
Tamanho da fila (RAM) (Queue size (RAM)) a_qmax 1 a 64 32
Caminho HTTP (HTTP path) a_path Até 31 caracteres; vazio = Endpoint + /alarm Vazio
1. Global (1. Global Template (The Envelope)) a_glob Até 255 caracteres {"dev":"{DEV}","mac":"{MAC}","alarms":[{DATA}]}
2. Linha (2. Row Template (Single Alarm)) a_line Até 511 caracteres O modelo de fábrica (JSON)
3. Separador (3. Separator) a_sep Até 7 caracteres ,
Cabeçalho Content-Type (Content-Type Header) a_ct Até 31 caracteres: um tipo de mídia, como application/json Vazio, que vale application/json
  • O Formato da linha de alarmes é independente do Formato da telemetria.
  • O texto do bloco mostra Pendentes: (Pending:) e o tamanho da fila no momento em que a página abriu. Para atualizar o número, recarregue a página.
  • Os três modelos e o Cabeçalho Content-Type só aparecem no formato Dinâmico, mas o 2. Linha também vale no JSON (JSON).
  • O Cabeçalho Content-Type é independente do da telemetria e segue as mesmas regras: só vale no Dinâmico e no HTTP, e um valor que não é um tipo de mídia é recusado com o aviso Campos não aplicados: a_ct (capítulo 21).
  • A linha precisa de um IP Servidor preenchido na telemetria; sem ele, nada sai.
Legenda: o bloco da linha de alarmes, no fim da página Telemetria. Note o número de Pendentes no texto do bloco e o Caminho HTTP vazio, que usa o Endpoint da telemetria seguido de /alarm.
Figura 191. Legenda: o bloco da linha de alarmes, no fim da página Telemetria. Note o número de Pendentes no texto do bloco e o Caminho HTTP vazio, que usa o Endpoint da telemetria seguido de /alarm.

Códigos do log de eventos

Código Evento Quando
549 Linha de telemetria de alarmes ligada Início, com a linha ligada; o contexto é a capacidade da fila
550 Payload de alarmes enviado HTTP aceito, ou MQTT publicado; o contexto é o número de registros
551 Falha no envio de alarmes Resposta fora de 2xx (contexto = código), erro de conexão (contexto negativo) ou publicação MQTT recusada (contexto = estado do cliente MQTT)
552 Recebimento de alarmes confirmado Registros tirados da fila; o contexto é quantos. Também ao assinar o tópico de confirmação, com o contexto 0
553 Estouro da fila de alarmes Evento recusado com a fila cheia; o contexto é o total recusado

Como na telemetria, o log de eventos guarda as transições da família da linha de alarmes, e não cada repetição (capítulo 16).

Não confunda com os eventos 470, Alarme disparado, e 471, Alarme zerado: eles registram o alarme do próprio aparelho, com som e tela, e não a linha de alarmes.

Receptores

Por HTTP

O receptor em Python do capítulo 21 já atende a linha de alarmes em JSON, no caminho /api/telemetria/alarm. Ele grava cada registro com a chave (uid, ts, seq, id), ignora as duplicatas e só responde 204 depois de gravar. O 204 é a confirmação: o aparelho tira da fila todos os registros daquele corpo.

Por MQTT

Este assinante grava os eventos e publica a confirmação. Ele usa a biblioteca paho-mqtt, versão 2 ou mais nova (pip install "paho-mqtt>=2").

#!/usr/bin/env python3
"""Coletor da linha de alarmes do SIMUT por MQTT: grava e confirma."""
import json
import sqlite3

import paho.mqtt.client as mqtt

BROKER = "coletor.exemplo.com.br"
ASSINATURA = "simut/data/alarm"      # varios aparelhos: "fabrica/+/data/alarm"

banco = sqlite3.connect("alarmes.db")
banco.execute("""CREATE TABLE IF NOT EXISTS alarme (
    topico TEXT NOT NULL, ts INTEGER NOT NULL, seq INTEGER NOT NULL, id TEXT NOT NULL,
    codigo TEXT, usuario TEXT, registro TEXT NOT NULL,
    PRIMARY KEY (topico, ts, seq, id))""")


def ao_conectar(cliente, dados, flags, motivo, propriedades):
    cliente.subscribe(ASSINATURA, qos=1)


def ao_receber(cliente, dados, msg):
    try:
        registros = json.loads(msg.payload)
        if not isinstance(registros, list):
            raise ValueError("esperava um array: use o formato JSON")
        with banco:                              # grava tudo ou nada
            for r in registros:
                codigo = r.get("alarm") or r.get("err") or r.get("maint")
                banco.execute(
                    "INSERT OR IGNORE INTO alarme VALUES (?, ?, ?, ?, ?, ?, ?)",
                    (msg.topic, r["ts"], r["seq"], r["id"], codigo, r.get("user"),
                     json.dumps(r)))
    except (ValueError, KeyError, TypeError, AttributeError) as erro:
        print(f"alarme recusado em {msg.topic}: {erro}")
        return                                   # sem confirmacao: volta em 15 s
    confirmacao = json.dumps({"seq": [r["seq"] for r in registros]},
                             separators=(",", ":"))
    cliente.publish(msg.topic + "/ack", confirmacao, qos=1, retain=False)


cliente = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="coletor-alarmes")
cliente.username_pw_set("coletor", "senha-do-coletor")
cliente.on_connect = ao_conectar
cliente.on_message = ao_receber
cliente.connect(BROKER, 1883)
cliente.loop_forever()

Com vários aparelhos, cada um com o seu Tópico, assine com um curinga, como fabrica/+/data/alarm: o programa responde sempre no tópico de confirmação do aparelho que mandou. A chave de gravação usa o tópico porque, no MQTT, é ele que identifica o aparelho.

Testar a linha

Para testar o coletor antes de ligar um aparelho, mande o que o aparelho mandaria.

Por HTTP:

curl -i http://coletor.exemplo.com.br:8080/api/telemetria/alarm \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer troque-este-segredo' \
  -H 'X-SIMUT-Uid: E6614C311B7A2F2D' \
  -H 'X-SIMUT-Ver: 2.7.1' \
  -H 'X-SIMUT-Env: release' \
  -H 'X-SIMUT-Cfg: 3F2A91C4' \
  --data-binary '[{"ts":1790168700,"id":"tSTM0001","val":8.52,"alarm":"alarm","seq":1}]'

Por MQTT, com o assinante acima rodando, publique um evento como se fosse o aparelho e confira a confirmação numa segunda janela de comandos:

mosquitto_sub -h coletor.exemplo.com.br -u coletor -P 'senha-do-coletor' -v -t 'simut/data/alarm/ack'
mosquitto_pub -h coletor.exemplo.com.br -u coletor -P 'senha-do-coletor' -t 'simut/data/alarm' \
  -m '[{"ts":1790168700,"id":"tSTM0001","val":8.52,"alarm":"alarm","seq":1}]'

A janela do mosquitto_sub deve mostrar simut/data/alarm/ack {"seq":[1]}.

Depois, com o aparelho:

  1. Na página Telemetria, ligue Habilitar linha de telemetria de alarmes e use Aplicar agora. No MQTT, confira também que o Lote mínimo (registros) está acima de 0.
  2. Provoque um evento. Três jeitos simples:
    • na página Alarmes e Sons, ponha o limite máximo de um sensor abaixo da leitura atual: sai um alarm em segundos;
    • abra uma janela de manutenção de poucos minutos num sensor: sai um maint_on agora e um maint_off no fim do prazo (capítulo 7);
    • desconecte um sensor: sai um err.
  3. Confira o registro no coletor.
  4. Na página Histórico e Logs, em Eventos do Sistema, confira os eventos 550 e 552.
  5. Recarregue a página Telemetria e confira Pendentes: 0.
  6. Desfaça o que fez no passo 2.

Nas imagens com o console completo (capítulo 14), alarm show mostra a configuração e a fila, alarm dump imprime o próximo corpo e dispara o envio, e alarm flush esvazia a fila sem confirmar.

Solução de problemas

Sintoma Causa provável O que fazer
Nenhum evento chega Linha desligada, ou IP Servidor vazio Ligue Habilitar linha de telemetria de alarmes e confira o servidor
Evento 551 com 404 Caminho errado Confira o Caminho HTTP; vazio, ele vale Endpoint + /alarm
Os mesmos eventos chegam a cada 15 s O coletor não confirma: HTTP fora de 2xx, ou falta a mensagem de confirmação no MQTT Responda 2xx depois de gravar, ou publique {"seq":[...]} em <tópico>/alarm/ack
MQTT: a fila nunca esvazia, embora o coletor confirme Telemetria de medições desligada; o aparelho não lê as confirmações Ponha o Lote mínimo acima de 0
MQTT: evento 551 com o contexto 0 a cada tentativa A fila não cabe numa mensagem de 2 KB Use um Tamanho da fila (RAM) de até 16 e confirme rápido; em último caso, reinicie o aparelho, o que esvazia a fila
MQTT: registros somem da fila sem terem chegado Confirmação retida no broker, ou dois aparelhos no mesmo Tópico Publique a confirmação sem retenção e apague a retida; dê um Tópico a cada aparelho
Evento 553 Fila cheia: o coletor não confirma há tempo Resolva a confirmação; aumente o Tamanho da fila (RAM) se o volume for real
Eventos se perdem depois de uma queda de energia A fila vive na RAM Esperado; confirme rápido para a fila ficar curta
alarm_lim não chega quando o limite muda pela web Só o painel gera alarm_lim, alarm_on e alarm_off Consulte o estado pela API (capítulo 26)
Um novo alarm ou maint_on chega depois de um reinício O aparelho refaz o estado das bordas ao iniciar Trate como confirmação de estado
maint_on e alarm_lim chegam sem until, lo, hi ou user Modelo próprio anterior à configuração versão 23 Acrescente "maint":{maint}, "lo":{lo}, "hi":{hi}, "until":{until} e "user":{user} ao 2. Linha
JSON inválido com "valor":, Marcador fora da forma composta, sem valor naquele registro Use a forma composta, como "val":{val}
O JSON da linha não é o do exemplo O 2. Linha foi editado e vale também no formato JSON Confira o 2. Linha no formato Dinâmico

Voltar ao sumário

Capítulo 23

Home Assistant

Este capítulo mostra como fazer o SIMUT aparecer sozinho no Home Assistant, com um dispositivo e uma entidade por medição, sem escrever YAML. É para quem já tem um broker MQTT e um Home Assistant funcionando e quer ver as medições do aparelho neles.

Como funciona

O aparelho não conversa com o Home Assistant diretamente. Os dois se encontram no broker MQTT:

  1. O aparelho conecta ao broker com a telemetria no transporte MQTT (capítulo 21).
  2. Logo depois de conectar, ele publica uma mensagem de descoberta para cada medição, retida no broker, sob o tópico homeassistant/.
  3. O Home Assistant lê essas mensagens e cria o dispositivo e as entidades.
  4. Daí em diante, cada mensagem de telemetria atualiza os valores, e a mensagem de estado do aparelho diz se ele está disponível.

A descoberta não é um canal novo: ela usa a mesma conexão, o mesmo servidor, a mesma conta e o mesmo TLS da telemetria. O recurso existe nas três imagens: release, alpha e Air. No Air, veja as ressalvas em No SIMUT Air.

Figura 192. Legenda: o caminho das mensagens. O aparelho só publica; o Home Assistant só assina. Tudo passa pelo broker.

O que aparece no Home Assistant

O dispositivo

Neste capítulo, dispositivo é o registro que o Home Assistant cria, e aparelho continua sendo o SIMUT. Cada aparelho vira um dispositivo, com estes dados:

Dado no Home Assistant Valor De onde vem
Nome simut Campo Nome da página Configurações (capítulo 5)
Fabricante SIMUT Fixo
Modelo Raspberry Pi Pico W Fixo
Versão do firmware 2.7.1 A versão gravada
Link de configuração http://192.0.2.10 O IP do aparelho e a Porta HTTP; a porta só aparece quando não é 80
Identificador simut_0a1b2c O Client ID do MQTT

O identificador é o Client ID do aparelho, com todo caractere fora de letras, dígitos, _ e - trocado por _. Com o Client ID em branco, ele vale simut_ seguido dos seis últimos dígitos do MAC (capítulo 20). Neste capítulo, ele se chama nó.

As entidades

Cada slot ativo gera uma entidade de temperatura e, se o sensor mede umidade, uma de umidade. A pressão gera uma entidade só, para o aparelho inteiro.

Grandeza Sensores Unidade Classe Casas decimais sugeridas Chave no JSON
Temperatura DS18B20, DHT22, BME280, BMP280 °C temperature 1 t + ID de hardware
Umidade DHT22, BME280 % humidity 0 u + ID de hardware
Pressão BME280, BMP280 hPa pressure 1 p + ID de hardware
  • Uma entidade de pressão por aparelho. A telemetria leva um único valor de pressão por registro, atribuído ao primeiro slot ativo com sensor de pressão (capítulo 21). A descoberta segue a mesma regra.
  • Todas as entidades são medições. O aparelho declara a classe de estado measurement, e o Home Assistant guarda as estatísticas de longo prazo delas.
  • Nada além disso. O aparelho não cria entidades de alarme, de sinal Wi-Fi nem de estado do sensor, e não aceita comandos do Home Assistant.

O nome de cada entidade é o nome do slot seguido do nome da grandeza, em inglês: Temperature, Humidity ou Pressure. Sem nome no slot, vale o ID de hardware. O Home Assistant costuma mostrar o nome do dispositivo antes do nome da entidade.

Com dois slots, um DS18B20 chamado Câmara 1 (ID STM0001) e um BME280 chamado Sala (ID BME28001), aparecem quatro entidades:

Nome da entidade Chave no JSON ID único (unique_id)
Câmara 1 Temperature tSTM0001 simut_0a1b2c_tSTM0001
Sala Temperature tBME28001 simut_0a1b2c_tBME28001
Sala Humidity uBME28001 simut_0a1b2c_uBME28001
Sala Pressure pBME28001 simut_0a1b2c_pBME28001

O ID único é o nó, um _ e a chave. O entity_id, como sensor.…, é o Home Assistant quem escolhe, a partir dos nomes, na primeira descoberta; depois disso ele não muda sozinho. Para mudar o nome que aparece no painel do Home Assistant, renomeie a entidade lá ou mude o nome do slot no aparelho (capítulo 6).

A disponibilidade

As entidades ficam disponíveis enquanto a mensagem de estado do aparelho diz online e indisponíveis quando ela diz offline (capítulo 21):

  • o aparelho publica online, retida, a cada conexão;
  • o broker publica offline, retida, quando o aparelho some sem se despedir, pela última vontade registrada na conexão.

O aparelho nunca se despede do broker: um reinício, uma falta de energia ou o sono do Air terminam a conexão sem aviso. O broker só percebe quando o prazo do Keep-Alive vence (pela regra do MQTT, uma vez e meia o valor; com os 60 s de fábrica, 90 s) ou quando a conexão cai por outro motivo. Até lá, as entidades continuam disponíveis com o último valor.

Antes de começar

Você precisa de:

  • Um broker MQTT que o aparelho e o Home Assistant alcancem, como o Mosquitto. A configuração mínima de um Mosquitto com senha está no capítulo 21.
  • A integração MQTT do Home Assistant ligada a esse broker, com a descoberta ativa e o prefixo homeassistant. Esse é o padrão do Home Assistant. O prefixo do aparelho é fixo e não pode ser mudado.
  • A telemetria do aparelho no transporte MQTT, com servidor, porta, conta e TLS configurados como no capítulo 21.
  • O formato JSON. Na página Telemetria, seção Construtor, o Formato tem de ser JSON. Com CSV ou Dinâmico, o aparelho não publica a descoberta e apaga a que já tinha publicado.
  • O Lote mínimo entre 1 e 5. Veja o quadro abaixo.
  • Um Client ID e um Tópico próprios para cada aparelho, quando houver mais de um no mesmo broker (capítulo 20).

Ligue também Reter (Retain Message) se quiser que o Home Assistant mostre o último valor logo depois de reiniciar, sem esperar a próxima medição: o broker guarda a última mensagem de medição e a entrega a quem assinar depois (capítulo 21).

Ligar a descoberta

A opção fica na página Telemetria, no bloco do MQTT, que só aparece com Transporte em MQTT(S).

Campo Chave em commit_all Console Faixa Fábrica Aplicação
Home Assistant Discovery m_had, na seção sys Não há comando Ligado ou desligado Desligado Reinicia (grupo web)

Abaixo da opção, a página explica: Publica mensagens de configuração retidas para o Home Assistant criar o dispositivo e seus sensores automaticamente. Exige payload JSON; as entidades aparecem no próximo envio.

Para ligar:

  1. Abra a página Telemetria.
  2. Em Transporte, escolha MQTT(S) e preencha o broker como no capítulo 21.
  3. Em Construtor, deixe o Formato em JSON.
  4. Em Lote mínimo (registros), digite 1.
  5. Ligue Home Assistant Discovery.
  6. Toque em Salvar e reiniciar na barra de topo e confirme.
  7. Espere o primeiro envio de telemetria depois do reinício.
  8. Na página Histórico e Logs, carregue os Eventos do Sistema e procure o evento 548, Discovery HA atualizado. O contexto é o número de mensagens publicadas.

As entidades não aparecem no momento em que o aparelho volta. Ele só conecta ao broker quando tem algo a enviar: a primeira telemetria depois do reinício ou um evento da linha de alarmes (capítulo 22). Com o Lote mínimo em 1, isso acontece no primeiro registro do histórico, em até um Intervalo Histórico (min) (capítulo 6).

Pela API, a mesma opção vai na seção sys de POST /api/commit_all (capítulo 26):

{"sys":{"t_transport":1,"t_mode":0,"t_int":1,"m_had":true}}
Legenda: a opção Home Assistant Discovery no bloco do MQTT. Note a dica embaixo dela: a descoberta exige o formato JSON e só acontece no próximo envio.
Figura 193. Legenda: a opção Home Assistant Discovery no bloco do MQTT. Note a dica embaixo dela: a descoberta exige o formato JSON e só acontece no próximo envio.
Figura 194. Legenda: o evento 548 confirma a publicação. O contexto 4 é o número de entidades publicadas.

No Home Assistant, passo a passo

Os menus citados aqui são os do Home Assistant, não os do aparelho.

  1. No Home Assistant, abra Configurações, depois Dispositivos e serviços.
  2. Se a integração MQTT não estiver lá, adicione-a e informe o endereço, a porta, o usuário e a senha do broker.
  3. Confira, nas opções da integração MQTT, que a descoberta está ativa e o prefixo é homeassistant.
  4. Configure o aparelho como em Ligar a descoberta.
  5. Depois do primeiro envio do aparelho, abra a integração MQTT e a lista de dispositivos. O aparelho aparece com o Nome dele, por exemplo simut.
  6. Abra o dispositivo. As entidades aparecem com os nomes da tabela de As entidades, já com unidade e classe.
  7. Adicione as entidades a um painel do Home Assistant, se quiser.

Para ver as mensagens de descoberta direto no broker, com o tópico antes de cada uma:

mosquitto_sub -h broker.exemplo.com.br -p 1883 -u coletor -P 'senha-do-coletor' -v -t 'homeassistant/sensor/#'

Se o broker restringe tópicos por conta, a conta do aparelho precisa publicar nos tópicos de medição e de estado e em homeassistant/sensor/<nó>/#, e a conta do Home Assistant precisa ler homeassistant/# e os tópicos do aparelho. Um exemplo de lista de acesso do Mosquitto, com o Tópico simut/data:

user simut
topic write simut/#
topic read simut/data/alarm/ack
topic write homeassistant/sensor/simut_0a1b2c/#

user homeassistant
topic read simut/#
topic readwrite homeassistant/#

A linha simut/data/alarm/ack só importa com a linha de alarmes ligada (capítulo 22).

Tópicos e mensagens

Tópico Retida Conteúdo
homeassistant/sensor/<nó>/<objeto>/config Sim Uma mensagem de descoberta por entidade
O Tópico, como simut/data Conforme Reter As medições, de onde saem os valores
O tópico de estado, como simut/status Sim online ou offline, de onde sai a disponibilidade

O <objeto> é a chave da medição no JSON da telemetria, como tSTM0001, com todo caractere fora de letras, dígitos, _ e - trocado por _. Como o ID de hardware só aceita esses caracteres (capítulo 6), o objeto costuma ser igual à chave.

A mensagem de descoberta da entidade Câmara 1 Temperature, como o aparelho a publica, numa linha só:

{"name":"Câmara 1 Temperature","uniq_id":"simut_0a1b2c_tSTM0001","stat_t":"simut/data","val_tpl":"{{ value_json['tSTM0001'] }}","unit_of_meas":"°C","dev_cla":"temperature","stat_cla":"measurement","sug_dsp_prc":1,"avty_t":"simut/status","avty_tpl":"{{ value_json.status }}","pl_avail":"online","pl_not_avail":"offline","dev":{"ids":["simut_0a1b2c"],"name":"simut","mf":"SIMUT","mdl":"Raspberry Pi Pico W","sw":"2.7.1","cu":"http://192.0.2.10"}}

O aparelho usa as abreviações que o Home Assistant aceita nas mensagens de descoberta:

Chave Nome completo Valor no exemplo
name name Nome da entidade
uniq_id unique_id Nó + _ + objeto
stat_t state_topic O Tópico das medições
val_tpl value_template Lê a chave da medição no JSON
unit_of_meas unit_of_measurement °C, % ou hPa
dev_cla device_class temperature, humidity ou pressure
stat_cla state_class Sempre measurement
sug_dsp_prc suggested_display_precision 1, 0 ou 1
avty_t availability_topic O tópico de estado
avty_tpl availability_template Lê o campo status
pl_avail, pl_not_avail payload_available, payload_not_available online, offline
dev device O bloco do dispositivo
ids, mf, mdl, sw, cu identifiers, manufacturer, model, sw_version, configuration_url Os dados do dispositivo

A entidade de umidade traz "unit_of_meas":"%", "dev_cla":"humidity" e "sug_dsp_prc":0. A de pressão traz "unit_of_meas":"hPa", "dev_cla":"pressure" e "sug_dsp_prc":1. O campo cu leva o IP que o aparelho tinha ao conectar; se o DHCP der outro IP, o link se corrige na conexão seguinte.

Os valores chegam pela telemetria comum, no tópico das medições:

homeassistant/sensor/simut_0a1b2c/tSTM0001/config {"name":"Câmara 1 Temperature","uniq_id":"simut_0a1b2c_tSTM0001",...}
simut/status {"device":"simut","status":"online","ip":"192.0.2.10"}
simut/data {"ts":1790168400,"tSTM0001":4.25,"tBME28001":22.81,"uBME28001":55.2,"pBME28001":1013.4}

O Home Assistant ignora o ts: cada valor entra no histórico dele com a hora em que chegou.

O que o aparelho faz em cada situação

O aparelho confere a descoberta a cada conexão com o broker. Com a opção ligada e o formato JSON, ele publica de novo todas as mensagens, retidas, mesmo que nada tenha mudado. Isso cobre um broker que reiniciou e perdeu as mensagens retidas. Um registro gravado na configuração lembra se há mensagens publicadas no broker, para que ele saiba o que apagar depois.

Situação O que acontece no Home Assistant
Descoberta ligada, formato JSON Na próxima conexão, dispositivo e entidades aparecem ou são atualizados
Descoberta desligada Na próxima conexão, o aparelho publica uma mensagem vazia e retida em cada tópico de descoberta, e as entidades somem
Formato trocado para CSV ou Dinâmico Igual a desligar a descoberta
Transporte trocado para HTTP(S) Nada é apagado. O aparelho não conecta mais ao broker, e as entidades ficam indisponíveis
Nome do slot mudado Na próxima conexão, a entidade recebe o nome novo, a menos que você a tenha renomeado no Home Assistant
ID de hardware mudado Surge uma entidade nova. A antiga fica, sem valores
Slot removido ou desligado A entidade dele fica, sem valores
Client ID mudado Surge um dispositivo novo. O antigo fica, indisponível
Tópico mudado As entidades passam a ler o tópico novo na próxima conexão
Nome do aparelho mudado O dispositivo recebe o nome novo na próxima conexão
Sensor em falha A medição sai do JSON, e a entidade fica sem valor novo
Aparelho reiniciado ou sem energia As entidades ficam indisponíveis quando o broker publica a última vontade, e voltam na próxima conexão

Remover um aparelho

A ordem importa: o aparelho só apaga as entidades dele enquanto ainda está no MQTT, no formato JSON e com os mesmos slots.

  1. Na página Telemetria, desligue Home Assistant Discovery, sem mudar mais nada.
  2. Toque em Salvar e reiniciar e confirme.
  3. Espere o próximo envio de telemetria.
  4. Confira o evento 548, Discovery HA atualizado, nos Eventos do Sistema. No console e no syslog, o texto do evento diz HA discovery cleared seguido do número de mensagens apagadas.
  5. Confira no Home Assistant que o dispositivo sumiu.
  6. Só então troque o transporte, remova slots ou desligue o aparelho.

Para tirar do Home Assistant a entidade de um slot que você vai remover, faça o mesmo em três gravações: desligue a descoberta e espere o evento 548, remova o slot, e ligue a descoberta de novo.

Para apagar uma mensagem que ficou no broker, publique uma mensagem vazia e retida no tópico dela:

mosquitto_pub -h broker.exemplo.com.br -p 1883 -u simut -P 'senha-do-aparelho' -r -n -t 'homeassistant/sensor/simut_0a1b2c/tSTM0003/config'

O -r pede a retenção e o -n manda a mensagem vazia. Para achar os tópicos que sobraram, assine homeassistant/sensor/<nó>/# com o mosquitto_sub e anote os que aparecem.

No SIMUT Air

air

O Air dorme entre as leituras e só liga o rádio nos despertares de transmissão (capítulo 19). Com a descoberta ligada:

  • A descoberta se repete a cada transmissão. Cada despertar de transmissão é uma conexão nova, e o aparelho publica todas as mensagens de descoberta de novo antes das medições. Isso soma alguns pacotes ao tempo de rádio de cada despertar.
  • As entidades ficam indisponíveis entre os despertares. O despertar termina num reinício do processador, sem despedida. O broker publica offline quando o Keep-Alive vence, e as entidades ficam indisponíveis até o despertar seguinte. Um Keep-Alive maior, até 300 s, adia o offline.
  • Os valores chegam em rajadas. As medições guardadas durante o sono saem juntas no despertar, e o Home Assistant as registra com a hora da chegada, não com a hora da medição.
  • O Lote mínimo manda o formato. Com o Lote mínimo acima de 5, toda transmissão sai em array, e o Home Assistant não lê nenhum valor (Antes de começar).

Para acompanhar um Air com histórico fiel à hora da medição, receba a telemetria num coletor que use o ts de cada registro (capítulo 21).

Limites

  • Só sensores de medição. Temperatura, umidade e pressão. A luminosidade não é publicada, porque a telemetria não a leva.
  • Uma entidade de pressão por aparelho, mesmo com vários sensores de pressão.
  • Só leitura. O Home Assistant não comanda o aparelho: não reconhece alarme, não abre janela de manutenção, não muda configuração. Para isso existe a API REST (capítulo 26).
  • Só o formato JSON, e só mensagens com um registro. Mensagens em array não atualizam as entidades.
  • A hora é a da chegada. O Home Assistant não usa o ts do registro nem recupera o que ficou para trás quando ele estava fora do ar.
  • Prefixo fixo homeassistant.
  • Nomes de grandeza em inglês: Temperature, Humidity e Pressure, qualquer que seja o idioma do aparelho.
  • Link de configuração sempre em http://. Com o HTTPS ligado na imagem release, o aparelho não atende em HTTP, e o link do Home Assistant não abre a página. Troque para https:// no navegador (capítulo 9).
  • QoS 0. Todas as mensagens, inclusive as de descoberta, saem com QoS 0 (capítulo 21).
  • Sobras no broker. O aparelho não apaga mensagens de slots removidos, de IDs antigos nem de um Client ID antigo.
  • Nada durante o AP de configuração. Enquanto o ponto de acesso de configuração está aberto, o aparelho não envia telemetria, e o Home Assistant não recebe valores (capítulo 9).
  • Nada sem envio. O aparelho só conecta ao broker quando tem algo a enviar. Com o Lote mínimo em 0 e a linha de alarmes desligada, ele nunca conecta, nem para apagar a descoberta.

Códigos do log de eventos

Código Descrição Nível Contexto e texto
548 Discovery HA atualizado INF Contexto: mensagens publicadas ou apagadas. Texto: HA discovery published N ou HA discovery cleared N, com (skipped M) quando alguma entidade foi pulada
542 MQTT conectando INF Texto: o Client ID
35 MQTT conectado INF Texto: o servidor
36 MQTT desconectado ERR ao conectar; WRN quando a conexão cai durante um envio Motivo no texto (capítulo 21)

O evento 548 vai sempre para a flash, sem o filtro de rotina (capítulo 16). O texto só aparece no console e no syslog (capítulo 25).

Uma entidade é pulada quando a chave dela tem aspas ou barra invertida, o que só acontece com um ID de hardware gravado por uma versão antiga, ou quando a mensagem de descoberta passaria de 895 bytes.

Voltar ao sumário

Capítulo 24

Prometheus

Este capítulo mostra como coletar os números do aparelho com o Prometheus: a rota /metrics, a conta que ela exige, a lista completa de métricas e exemplos de configuração, consultas e alertas para cadeia fria. É para a equipe de TI que já usa Prometheus e Grafana.

Como funciona

O aparelho oferece a rota GET /metrics, na porta da interface web, no formato de texto do Prometheus. O Prometheus consulta a rota em intervalos regulares e guarda a série.

  • É uma foto do agora. O aparelho responde com os valores do momento e não guarda nada para depois. Se o Prometheus não consultar, aquele instante se perde; o aparelho não reenvia nada.
  • Não precisa de configuração no aparelho. Não há opção para ligar ou desligar a rota. Basta uma conta com a permissão certa.
  • Existe nas três imagens. Na imagem release, a rota segue o protocolo da interface web: HTTP, ou só HTTPS com certificado instalado. Nas imagens alpha e Air, só HTTP. No Air, só com o aparelho acordado (No SIMUT Air).

Para guardar as medições com a hora exata de cada registro, sem buracos, use a telemetria (capítulo 21). O Prometheus serve para painéis, tendências e alertas.

Figura 195. Legenda: uma leitura do Prometheus. O aparelho confere a senha a cada pedido, e as senhas erradas alimentam o mesmo bloqueio da página de entrada.

Endereço e autenticação

Situação Endereço
HTTP, porta de fábrica http://192.0.2.10/metrics
HTTP, outra Porta HTTP http://192.0.2.10:8080/metrics
release HTTPS com certificado instalado https://192.0.2.10/metrics (porta 443)

As regras de porta e protocolo são as da API REST (capítulo 26).

A rota aceita duas formas de entrar:

  • HTTP Basic, com a conta e a senha de uma conta do aparelho. É o que o Prometheus usa, porque ele não faz a entrada em dois passos da interface web. A senha vai como foi digitada, e o aparelho calcula o resumo e confere.
  • A sessão da interface web, pelo cookie ou pelo cabeçalho Authorization: Bearer (capítulo 26). Serve para abrir a rota no navegador já logado, mas não para o Prometheus: a sessão expira com 15 min sem uso e some a cada reinício.

A conta precisa da permissão Painel PERM_DASHBOARD.

Resposta Quando
200, text/plain; version=0.0.4; charset=utf-8 Conta e senha certas, numa conta com Painel
401 unauthorized, com WWW-Authenticate: Basic realm="SIMUT metrics" Sem conta e senha, cabeçalho malformado ou senha errada
403 forbidden Conta certa, mas sem Painel
429 {"ok":false,"err":2,"lockSec":42} O endereço de origem está bloqueado por senhas erradas; lockSec é o que falta, em segundos

A resposta de bloqueio não traz o cabeçalho Retry-After: leia o lockSec do corpo.

A conta do Prometheus

Crie uma conta só para o Prometheus, com a permissão Painel e nenhuma outra. Assim, uma senha vazada dá acesso de leitura ao estado do aparelho e a mais nada.

  1. Na página Usuários, crie a conta metricas com a permissão Painel e sem PIN (capítulo 8).
  2. Toque em Salvar e reiniciar e anote a senha da janela Senha temporária.
  3. Entre uma vez na interface web com a conta metricas e defina a senha definitiva na troca obrigatória (capítulo 13). Escolha uma senha longa: o HTTP Basic aceita até 128 caracteres.
  4. Saia da interface web.
  5. Grave a senha num arquivo legível só pelo Prometheus, por exemplo /etc/prometheus/simut_senha.
Figura 196. Legenda: a conta do Prometheus, com a permissão Painel e nenhuma outra.

A senha temporária já funciona no HTTP Basic, sem a troca. Troque-a mesmo assim: ela tem só 8 caracteres e apareceu numa janela da interface web.

Para testar do servidor do Prometheus:

curl -s -u "metricas:$SIMUT_METRICS_PASS" http://192.0.2.10/metrics | head -4
# TYPE simut_build_info gauge
simut_build_info{version="2.7.1",device="simut"} 1
# TYPE simut_uptime_seconds gauge
simut_uptime_seconds 86412

O bloqueio por senha errada

A conta do HTTP Basic passa pelo mesmo bloqueio da página de entrada (capítulo 26):

  • cada senha errada bloqueia o endereço de origem por 2 s, 4 s, 8 s e assim por diante, até 300 s a partir do nono erro;
  • durante o bloqueio, todo pedido desse endereço recebe 429, mesmo com a senha certa, e o aparelho nem confere a senha;
  • a contagem de erros só volta a zero com uma entrada bem-sucedida pela interface web a partir daquele endereço. Uma leitura bem-sucedida do /metrics não zera a contagem;
  • o bloqueio vale para o endereço, não para a conta: o servidor do Prometheus e quem abre a interface web a partir da mesma máquina, ou atrás do mesmo NAT, dividem o bloqueio.

Cada senha errada grava o evento 301, Falha de login, no log de eventos. O nome da conta vai no texto do evento, que só aparece no console e no syslog (capítulo 25). Com uma senha errada no Prometheus, depois do nono erro isso vira um evento a cada 300 s, mais ou menos, sem parar, até alguém corrigir a senha. Os pedidos recusados durante o bloqueio não gravam evento. As leituras bem-sucedidas não gravam nada no log.

Depois de corrigir uma senha errada no Prometheus, entre uma vez na interface web a partir do servidor do Prometheus para zerar a contagem. Só o tempo não zera a contagem: enquanto ela estiver alta, uma única senha errada nova já bloqueia por 300 s.

Intervalo de coleta

Use scrape_interval de 60 s. Não use menos de 15 s.

  • Cada leitura com HTTP Basic confere a senha inteira, com as mesmas 5.000 rodadas da página de entrada (capítulo 8). Medido: cerca de 0,69 s por leitura, seis leituras seguidas (v2.2.13, 19/08/2026).
  • Durante esse tempo, o aparelho não atende outro pedido. Ele atende um pedido por vez (capítulo 26); uma página aberta na interface web espera a leitura acabar.
  • Os valores mudam devagar. As medições vêm da média filtrada dos sensores; consultar muito mais rápido que isso não traz informação nova.
  • Dois servidores de Prometheus dobram a carga. Num par redundante, conte as duas leituras.

Deixe o scrape_timeout em 10 s, o padrão do Prometheus. Em HTTPS, o aparelho atende uma conexão segura por vez; as conexões persistentes, ligadas de fábrica, evitam refazer o TLS a cada leitura (capítulo 9).

Configurar o Prometheus

Um trabalho de coleta com dois aparelhos em HTTP:

scrape_configs:
  - job_name: simut
    scrape_interval: 60s
    scrape_timeout: 10s
    metrics_path: /metrics
    scheme: http
    basic_auth:
      username: metricas
      password_file: /etc/prometheus/simut_senha
    static_configs:
      - targets: ['192.0.2.10:80']
        labels:
          local: camara-fria-1
      - targets: ['192.0.2.11:80']
        labels:
          local: camara-fria-2

Para um aparelho release em HTTPS, mude o esquema e indique o certificado:

    scheme: https
    tls_config:
      ca_file: /etc/prometheus/simut_ca.pem

O certificado instalado no aparelho precisa valer para o endereço usado no alvo. Se ele foi emitido para um nome, use o nome no alvo, ou indique-o em tls_config.server_name (capítulo 9).

Dê a cada aparelho um endereço fixo, por reserva no DHCP ou IP estático (capítulo 9): o alvo do Prometheus é o endereço. O uid do aparelho não aparece nas métricas; o rótulo device de simut_build_info traz o Nome, que pode se repetir entre aparelhos.

As métricas

A resposta tem 45 famílias de métricas. Cada uma vem com a linha # TYPE, sem # HELP. Os contadores (counter) começam em zero a cada reinício do aparelho; as funções rate() e increase() do Prometheus já tratam essa volta a zero.

Aparelho

Métrica Tipo Unidade O que é
simut_build_info{version,device} gauge — Sempre 1. Os rótulos trazem a versão do firmware e o Nome do aparelho
simut_uptime_seconds gauge s Tempo desde o último reinício
simut_ntp_synced gauge 0 ou 1 Veja o aviso abaixo

Memória e armazenamento

Métrica Tipo Unidade O que é
simut_heap_free_bytes gauge bytes Memória RAM livre agora
simut_heap_total_bytes gauge bytes Tamanho total da área de memória dinâmica
simut_heap_min_bytes gauge bytes Menor memória livre vista desde o reinício
simut_heap_largest_block_bytes gauge bytes Maior bloco livre contínuo agora
simut_heap_largest_block_min_bytes gauge bytes Menor valor do maior bloco desde o reinício
simut_fs_used_bytes gauge bytes Espaço usado no sistema de arquivos
simut_fs_total_bytes gauge bytes Tamanho do sistema de arquivos

O aparelho relê o sistema de arquivos no máximo a cada 10 s; entre uma leitura e outra, as duas métricas simut_fs_* repetem o último valor.

Rede

Métrica Tipo Unidade O que é
simut_wifi_connected gauge 0 ou 1 1 com Wi-Fi conectado e sinal acima de −78 dBm, a mesma condição que a telemetria exige para enviar
simut_wifi_rssi_dbm gauge dBm Sinal Wi-Fi agora
simut_wifi_reconnects_total counter — Vezes que o aparelho obteve IP desde o reinício, contando a primeira
simut_mqtt_reconnects_total counter — Conexões ao broker MQTT desde o reinício, contando a primeira
simut_mqtt_connected gauge 0 ou 1 1 com o cliente MQTT conectado. No transporte HTTP, sempre 0

Telemetria

Métrica Tipo Unidade O que é
simut_telemetry_enabled gauge 0 ou 1 1 com o Lote mínimo (registros) acima de 0 (capítulo 21)
simut_telemetry_pending_records gauge registros Registros esperando envio, os Registros Pendentes do Painel de Controle
simut_telemetry_sent_total counter — Envios bem-sucedidos
simut_telemetry_failed_total counter — Envios que falharam
simut_telemetry_retries_total counter — Novas tentativas
simut_telemetry_sent_bytes_total counter bytes Bytes de medição enviados
simut_telemetry_last_latency_seconds gauge s Duração do último envio, com 3 casas

Linha de alarmes

Métrica Tipo Unidade O que é
simut_alarm_line_enabled gauge 0 ou 1 1 com a linha de alarmes ligada (capítulo 22)
simut_alarm_pending_records gauge registros Registros na fila da linha, esperando confirmação
simut_alarm_queued_total counter — Registros aceitos na fila
simut_alarm_sent_total counter — Registros enviados
simut_alarm_acked_total counter — Confirmações recebidas do coletor
simut_alarm_failed_total counter — Ciclos de envio que falharam
simut_alarm_dropped_total counter — Registros perdidos porque a fila estava cheia
simut_alarm_error_records_total counter — Registros gerados por sensor em falha

Sensores e configuração

Métrica Tipo Unidade O que é
simut_sensor_reads_ok_total counter — Leituras bem-sucedidas, somando todos os sensores
simut_sensor_reads_error_total counter — Leituras com erro, somando todos os sensores
simut_config_saves_total counter — Pedidos de gravação da configuração, inclusive os que não mudavam nada

Diagnóstico interno

Estas métricas acompanham a gravação na flash, o segundo núcleo do processador e os pedidos web interrompidos. Servem ao suporte, num teste longo de estabilidade; no dia a dia, não precisam de alerta.

Métrica Tipo Rótulos O que é
simut_flash_ops_total counter — Operações de gravação na flash
simut_flash_op_max_seconds gauge — A operação de flash mais longa, em segundos
simut_flash_ops_over50ms_total counter — Operações de flash com mais de 50 ms
simut_flash_unguarded_ops_total counter — Operações de flash feitas com o segundo núcleo ativo
simut_core1_heartbeat_age_seconds gauge — Tempo desde o último sinal de vida do segundo núcleo
simut_core1_launches_total counter — Partidas do segundo núcleo
simut_core1_kills_total counter cause: lockout, health, quiet Paradas forçadas do segundo núcleo, por motivo
simut_web_aborts_total counter cause: deadline, guard, disconnect, short_write Respostas web interrompidas, por motivo. short_write é um envio que não terminou dentro do prazo

Medições por slot

Métrica Tipo Unidade Casas O que é
simut_sensor_ok gauge 0 ou 1 — 0 com o sensor em falha, 1 nos outros casos
simut_temperature_celsius gauge °C 2 Temperatura
simut_humidity_percent gauge % 1 Umidade relativa
simut_pressure_hpa gauge hPa 1 Pressão

As quatro têm os mesmos rótulos:

Rótulo Valor Exemplo
slot Número do slot, de 0 a 15 "0"
hwid ID de hardware do slot (capítulo 6) "STM0001"
name Nome do slot "Câmara 1"
  • O valor é o que o aparelho mostra. É a média filtrada das leituras, já com a calibração, a mesma que o Painel de Controle mostra (capítulo 6).
  • Cada slot ativo aparece em simut_sensor_ok. Só os slots com o sensor em bom estado aparecem nas outras três. Um sensor em falha fica com simut_sensor_ok em 0 e some das métricas de medição até se recuperar. Um valor ainda não lido também não aparece.
  • A pressão aparece por slot. Ao contrário da telemetria, que leva um único valor de pressão, cada BME280 e cada BMP280 tem a sua linha.
  • Sem sensores ativos, as linhas # TYPE das quatro famílias continuam lá, sem valores.

Um exemplo completo

A resposta de um aparelho com um DS18B20 no slot 0 (Câmara 1, STM0001) e um BME280 no slot 1 (Sala, BME28001), com telemetria MQTT e a linha de alarmes desligada:

# TYPE simut_build_info gauge
simut_build_info{version="2.7.1",device="simut"} 1
# TYPE simut_uptime_seconds gauge
simut_uptime_seconds 86412
# TYPE simut_ntp_synced gauge
simut_ntp_synced 1
# TYPE simut_heap_free_bytes gauge
simut_heap_free_bytes 40796
# TYPE simut_heap_total_bytes gauge
simut_heap_total_bytes 229376
# TYPE simut_heap_min_bytes gauge
simut_heap_min_bytes 31204
# TYPE simut_heap_largest_block_bytes gauge
simut_heap_largest_block_bytes 29390
# TYPE simut_heap_largest_block_min_bytes gauge
simut_heap_largest_block_min_bytes 17680
# TYPE simut_fs_used_bytes gauge
simut_fs_used_bytes 385024
# TYPE simut_fs_total_bytes gauge
simut_fs_total_bytes 1048576
# TYPE simut_wifi_connected gauge
simut_wifi_connected 1
# TYPE simut_wifi_rssi_dbm gauge
simut_wifi_rssi_dbm -61
# TYPE simut_wifi_reconnects_total counter
simut_wifi_reconnects_total 1
# TYPE simut_mqtt_reconnects_total counter
simut_mqtt_reconnects_total 2
# TYPE simut_mqtt_connected gauge
simut_mqtt_connected 1
# TYPE simut_telemetry_enabled gauge
simut_telemetry_enabled 1
# TYPE simut_telemetry_pending_records gauge
simut_telemetry_pending_records 0
# TYPE simut_telemetry_sent_total counter
simut_telemetry_sent_total 1440
# TYPE simut_telemetry_failed_total counter
simut_telemetry_failed_total 3
# TYPE simut_telemetry_retries_total counter
simut_telemetry_retries_total 3
# TYPE simut_telemetry_sent_bytes_total counter
simut_telemetry_sent_bytes_total 129600
# TYPE simut_telemetry_last_latency_seconds gauge
simut_telemetry_last_latency_seconds 0.412
# TYPE simut_alarm_line_enabled gauge
simut_alarm_line_enabled 0
# TYPE simut_alarm_pending_records gauge
simut_alarm_pending_records 0
# TYPE simut_alarm_queued_total counter
simut_alarm_queued_total 0
# TYPE simut_alarm_sent_total counter
simut_alarm_sent_total 0
# TYPE simut_alarm_acked_total counter
simut_alarm_acked_total 0
# TYPE simut_alarm_failed_total counter
simut_alarm_failed_total 0
# TYPE simut_alarm_dropped_total counter
simut_alarm_dropped_total 0
# TYPE simut_alarm_error_records_total counter
simut_alarm_error_records_total 0
# TYPE simut_sensor_reads_ok_total counter
simut_sensor_reads_ok_total 172788
# TYPE simut_sensor_reads_error_total counter
simut_sensor_reads_error_total 12
# TYPE simut_config_saves_total counter
simut_config_saves_total 1
# TYPE simut_flash_ops_total counter
simut_flash_ops_total 3120
# TYPE simut_flash_op_max_seconds gauge
simut_flash_op_max_seconds 0.046
# TYPE simut_flash_ops_over50ms_total counter
simut_flash_ops_over50ms_total 0
# TYPE simut_flash_unguarded_ops_total counter
simut_flash_unguarded_ops_total 0
# TYPE simut_core1_heartbeat_age_seconds gauge
simut_core1_heartbeat_age_seconds 0.012
# TYPE simut_core1_launches_total counter
simut_core1_launches_total 1
# TYPE simut_core1_kills_total counter
simut_core1_kills_total{cause="lockout"} 0
simut_core1_kills_total{cause="health"} 0
simut_core1_kills_total{cause="quiet"} 0
# TYPE simut_web_aborts_total counter
simut_web_aborts_total{cause="deadline"} 0
simut_web_aborts_total{cause="guard"} 0
simut_web_aborts_total{cause="disconnect"} 0
simut_web_aborts_total{cause="short_write"} 0
# TYPE simut_sensor_ok gauge
simut_sensor_ok{slot="0",hwid="STM0001",name="Câmara 1"} 1
simut_sensor_ok{slot="1",hwid="BME28001",name="Sala"} 1
# TYPE simut_temperature_celsius gauge
simut_temperature_celsius{slot="0",hwid="STM0001",name="Câmara 1"} 4.25
simut_temperature_celsius{slot="1",hwid="BME28001",name="Sala"} 22.81
# TYPE simut_humidity_percent gauge
simut_humidity_percent{slot="1",hwid="BME28001",name="Sala"} 55.2
# TYPE simut_pressure_hpa gauge
simut_pressure_hpa{slot="1",hwid="BME28001",name="Sala"} 1013.4

Os números acima são ilustrativos; a ordem, os nomes, os rótulos e as casas decimais são os que o aparelho usa.

Consultas úteis

Pergunta Consulta
Temperatura agora, por sensor simut_temperature_celsius
Máxima das últimas 24 h de um sensor max_over_time(simut_temperature_celsius{hwid="STM0001"}[24h])
Fração das últimas 24 h acima de 8 °C avg_over_time((simut_temperature_celsius{hwid="STM0001"} > bool 8)[24h:1m])
Aparelhos por versão count by (version) (simut_build_info)
Falhas de telemetria por hora increase(simut_telemetry_failed_total[1h])
Leituras com erro por hora, por aparelho increase(simut_sensor_reads_error_total[1h])
Menor memória livre desde o reinício simut_heap_min_bytes

A fração acima de 8 °C vai de 0 a 1: multiplique por 1.440 para ter os minutos fora da faixa num dia.

Alertas para cadeia fria

Um arquivo de regras com os alertas mais comuns. Ajuste a faixa, o hwid e os tempos ao seu caso.

groups:
  - name: simut-cadeia-fria
    rules:
      - alert: SimutTemperaturaForaDaFaixa
        expr: |
          simut_temperature_celsius{hwid="STM0001"} > 8
          or simut_temperature_celsius{hwid="STM0001"} < 2
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.name }} em {{ $value }} °C, fora de 2 a 8 °C"

      - alert: SimutForaDoAr
        expr: up{job="simut"} == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "O aparelho {{ $labels.instance }} não responde ao /metrics"

      - alert: SimutSensorEmFalha
        expr: simut_sensor_ok == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Sensor {{ $labels.hwid }} ({{ $labels.name }}) em falha"

      - alert: SimutLeituraAusente
        expr: absent_over_time(simut_temperature_celsius{hwid="STM0001"}[10m])
        labels:
          severity: warning
        annotations:
          summary: "Nenhuma temperatura válida de STM0001 em 10 min"

      - alert: SimutLeiturasParadas
        expr: increase(simut_sensor_reads_ok_total[10m]) == 0
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} não faz leitura válida há 10 min"

      - alert: SimutTelemetriaAtrasada
        expr: simut_telemetry_enabled == 1 and simut_telemetry_pending_records > 60
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} com {{ $value }} registros sem envio"

      - alert: SimutReiniciou
        expr: simut_uptime_seconds < 600
        labels:
          severity: info
        annotations:
          summary: "{{ $labels.instance }} reiniciou há menos de 10 min"

      - alert: SimutSinalFraco
        expr: simut_wifi_rssi_dbm <= -78
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Sinal Wi-Fi de {{ $labels.instance }} em {{ $value }} dBm"
  • Temperatura fora da faixa. O for: 5m evita alarme por uma porta aberta por um instante. Um alarme que precisa de segundos, com registro de quem agiu, é papel da linha de alarmes (capítulo 22).
  • Fora do ar. A métrica up é do próprio Prometheus: vale 0 quando a leitura falha, inclusive por senha errada ou bloqueio.
  • Leitura ausente. Dispara quando o valor some das métricas: sensor em falha, sensor ainda sem leitura válida, ou aparelho fora do ar. O alerta SimutForaDoAr separa o último caso.
  • Leituras paradas. Olha o contador de todas as leituras do aparelho; se ele não sobe em 10 min, nenhum sensor está sendo lido.
  • Telemetria atrasada. Registros acumulando no aparelho significam que o coletor não está recebendo. Com o histórico a cada minuto, 60 registros são uma hora de atraso.
  • Sinal fraco. Com −78 dBm ou menos, o aparelho segura a telemetria (capítulo 20).

No SIMUT Air

air

O Air só atende na rede quando está acordado em M0 (capítulo 19). Nos despertares do ciclo (M1) e durante o sono, a rota não responde, e o Prometheus registra o alvo como fora do ar.

Uma leitura com conta e senha certas conta como uso do aparelho e reinicia o prazo de inatividade que leva o Air de volta ao sono (de fábrica, 300 s). Um Prometheus que consulta um Air em M0 com intervalo menor que esse prazo o mantém acordado, com o rádio ligado, até a bateria acabar. Ligado ao carregador, o Air não dorme de qualquer forma. Para acompanhar um Air, use a telemetria (capítulo 21) e deixe-o fora do Prometheus, ou só o consulte ligado ao carregador.

Limites

  • Só o agora. Não há histórico nem reenvio por esta rota. O que o Prometheus não consultou, perdeu.
  • Uma conferência de senha por leitura. Cerca de 0,69 s de aparelho ocupado a cada leitura com HTTP Basic.
  • Sem uid nas métricas. Identifique o aparelho pelo alvo ou por rótulos que você mesmo põe na configuração.
  • simut_ntp_synced sempre 1 até a v2.8.0 (Aparelho).
  • Sem # HELP, só # TYPE.
  • Contadores zerados a cada reinício.
  • Nenhuma métrica de alarme por slot. O estado de alarme de cada sensor não sai por aqui; compare os valores com a sua faixa nas regras do Prometheus, ou use a linha de alarmes.
  • Com o AP de configuração aberto, o aparelho só atende pela rede do próprio AP, e o Prometheus da rede local não o alcança (capítulo 9).

Voltar ao sumário

Capítulo 25

Syslog

Este capítulo mostra como mandar o log de eventos do aparelho para um coletor syslog, no formato RFC 5424 sobre UDP, e como receber, guardar e filtrar essas linhas com rsyslog, syslog-ng ou journald. É para a equipe de TI que precisa de uma trilha de auditoria fora do aparelho.

O que o syslog manda

O aparelho manda uma cópia de cada evento do log de eventos (capítulo 16), a partir do nível mínimo escolhido, como uma linha de texto num datagrama UDP. Não há confirmação, nova tentativa nem fila na flash.

  • Não é telemetria. O syslog leva eventos, como uma entrada, uma falha de rede ou uma mudança de configuração. As medições saem pela telemetria (capítulo 21).
  • Não passa pelo filtro de rotina. O log de eventos só grava um evento de rotina quando o estado muda (capítulo 16). O syslog manda todas as ocorrências: com o nível Info, cada envio de telemetria vira uma linha.
  • Leva o texto do evento. O registro na flash guarda só o código e o contexto. A linha do syslog traz também a descrição e o detalhe, como o nome da conta numa falha de entrada.
  • Existe nas três imagens. No Air, só com o aparelho acordado (No SIMUT Air).
Figura 197. Legenda: o caminho de uma linha de syslog e os pontos onde ela pode se perder. O log de eventos local segue por outro caminho e não depende do syslog.

O formato da linha

Cada datagrama leva uma linha:

<PRI>1 TIMESTAMP HOSTNAME APP-NAME - MSGID [simut@32473 ctx="…" core="…" up="…"] MSG
Campo Valor
PRI Facilidade local0 (16) × 8 + a severidade: <135> a <130>
1 Versão do formato RFC 5424
TIMESTAMP Data e hora em UTC, com Z e segundos inteiros, como 2026-09-23T13:01:00Z. Antes de o aparelho acertar a hora, -
HOSTNAME O Nome do aparelho (capítulo 5)
APP-NAME O módulo que registrou o evento, como SEC, NET ou TEL
PROCID Sempre -
MSGID O código do evento, em números, como 301
Dados estruturados ctx: o contexto do evento; core: o núcleo, 0 ou 1; up: segundos desde o último reinício
MSG A descrição do evento e, quando há, : e o detalhe

Os níveis do log viram severidades do syslog assim:

Nível no aparelho Severidade PRI
Depuração (DBG) 7, Debug <135>
Informação (INF) 6, Informational <134>
Aviso (WRN) 4, Warning <132>
Erro (ERR) 3, Error <131>
Fatal (FTL) 2, Critical <130>

Detalhes que importam para o coletor:

  • O MSGID é a chave. O código não muda com o idioma, e a lista completa está no apêndice B. Filtre por ele, não pelo texto.
  • O texto sai em inglês. A descrição e o detalhe saem em inglês, qualquer que seja o idioma do aparelho. Os nomes traduzidos ficam na página de histórico (capítulo 16).
  • O HOSTNAME é um nome, não uma chave. Espaços, letras acentuadas e qualquer caractere fora do ASCII visível viram -: Câmara 1 sai como C--mara-1. Com o Nome vazio, sai -. O uid do aparelho não vai na linha (capítulo 20); dê nomes únicos aos aparelhos ou identifique-os pelo IP de origem.
  • simut@32473 é um identificador de exemplo. O número 32473 é o que a IANA reserva para documentação. Os coletores o aceitam como identificador de dados estruturados válido.
  • Tamanho. A linha tem no máximo 255 bytes, e o MSG, no máximo 191. Um detalhe mais longo é cortado.
  • Caracteres de controle no texto viram espaço. Acentos passam como UTF-8.
  • Sem hora certa, -. Enquanto o relógio do aparelho não foi acertado pelo NTP ou à mão, o campo TIMESTAMP sai como -, e não com uma data provisória. Nesse caso, use a hora de chegada ao coletor (capítulo 10).

Exemplos

Com o Nome simut:

<134>1 2026-09-23T13:00:05Z simut TEL - 30 [simut@32473 ctx="200" core="0" up="86412"] Telemetry sent: HTTP OK: 1834 bytes, code 200
<132>1 2026-09-23T13:01:00Z simut SEC - 301 [simut@32473 ctx="0" core="0" up="86467"] Login failed: Login Failed: metricas
<132>1 2026-09-23T13:02:10Z simut SEC - 303 [simut@32473 ctx="0" core="0" up="86537"] Config changed: Admin committed changes — rebooting
<134>1 2026-09-23T13:04:41Z simut TEL - 548 [simut@32473 ctx="4" core="0" up="42"] HA discovery refreshed: HA discovery published 4
<132>1 - simut SEC - 301 [simut@32473 ctx="0" core="0" up="95"] Login failed: Login Failed: metricas
  • A primeira linha é um envio de telemetria por HTTP; o contexto é o código HTTP da resposta.
  • A segunda é uma senha errada no /metrics (capítulo 24); o nome da conta só existe nesta linha e no console.
  • A terceira é uma gravação pela interface web que reiniciou o aparelho; o contexto é o número da conta que gravou, 0 para o admin.
  • A quarta é a descoberta do Home Assistant (capítulo 23).
  • A última mostra um aparelho sem hora acertada.

Configurar

As opções ficam na página Configurações, seção Syslog Remoto (Auditoria) (Remote Syslog (Audit Trail)), descrita no capítulo 5.

Campo Chave em commit_all Console Faixa Fábrica Aplicação
Habilitar encaminhamento syslog (Enable syslog forwarding) slog_en Não há comando Ligado ou desligado Desligado Reinicia (grupo web)
IP do Coletor (Collector IP) slog_srv Não há comando IPv4, como 192.0.2.10; vazio desliga Vazio Reinicia (grupo web)
Porta UDP (UDP Port) slog_port Não há comando 1 a 65535 514 Reinicia (grupo web)
Nível Mínimo (Minimum Level) slog_lvl Não há comando Debug (0), Info (1), Warning (2), Error (3) ou Fatal (4) Info Reinicia (grupo web)
  • O coletor é um endereço IPv4. O aparelho não aceita nome, como coletor.exemplo.com.br, porque guarda o endereço em 4 bytes e não faz consulta de DNS para o syslog. Um valor que não é IPv4 volta como recusado (capítulo 5).
  • O interruptor e o endereço são independentes. Com o interruptor ligado e o IP do Coletor vazio, nada sai. O interruptor continua ligado, e basta preencher o endereço depois.
  • As quatro chaves vão na seção sys. Uma chave que não vem no pedido mantém o valor gravado. O nível é o número entre parênteses.
  • Não há comando no console para estas opções. Use a interface web ou POST /api/commit_all (capítulo 26).

Para ligar:

  1. Abra a página Configurações e vá até Syslog Remoto (Auditoria).
  2. Ligue Habilitar encaminhamento syslog.
  3. Em IP do Coletor, digite o IPv4 do coletor, por exemplo 192.0.2.10.
  4. Em Porta UDP, deixe 514 ou use a porta do seu coletor.
  5. Em Nível Mínimo, escolha o nível (Qual nível usar).
  6. Toque em Salvar e reiniciar e confirme.

Pela API:

{"sys":{"slog_en":true,"slog_srv":"192.0.2.10","slog_port":514,"slog_lvl":2}}

GET /api/config devolve as mesmas quatro chaves, com slog_srv vazio ("") quando não há coletor.

Qual nível usar

Nível O que chega Volume
Debug Tudo, inclusive eventos de depuração que o log de eventos nunca grava Alto
Info Funcionamento normal e todos os problemas: entradas e saídas, cada envio de telemetria, cada conexão Alto: uma linha por envio de telemetria, no mínimo
Warning Problemas e recusas: senhas erradas, acessos negados, mudanças de configuração, falhas de rede Baixo
Error Só falhas Muito baixo
Fatal Nada. Os únicos eventos fatais são os registros de partida, gravados antes de o encaminhamento começar Nenhum

Para uma trilha de auditoria completa, use Info: as entradas bem-sucedidas (código 300) são de nível Informação. Com Warning, você perde as entradas bem-sucedidas, mas guarda as senhas erradas (301), os acessos negados (302) e as mudanças de configuração (303).

Receber com rsyslog

O rsyslog reconhece o formato RFC 5424 sem módulo extra. Um arquivo /etc/rsyslog.d/30-simut.conf que recebe na porta 514 e grava um arquivo por aparelho:

module(load="imudp")
input(type="imudp" port="514" ruleset="simut")

template(name="SimutPorAparelho" type="string" string="/var/log/simut/%HOSTNAME%.log")

ruleset(name="simut") {
    action(type="omfile" dynaFile="SimutPorAparelho" template="RSYSLOG_SyslogProtocol23Format")
}
  1. Crie o arquivo acima.
  2. Reinicie o rsyslog: sudo systemctl restart rsyslog.
  3. Libere a porta UDP 514 no firewall do coletor, só para os endereços dos aparelhos.
  4. Ligue o encaminhamento no aparelho e espere o reinício.
  5. Acompanhe: sudo tail -f /var/log/simut/simut.log.

O modelo RSYSLOG_SyslogProtocol23Format grava a linha no mesmo formato RFC 5424 em que ela chegou. Se o TIMESTAMP veio como -, a hora de chegada está na propriedade timegenerated do rsyslog.

Receber com syslog-ng

O syslog() do syslog-ng lê o formato RFC 5424 e separa os dados estruturados. Um arquivo /etc/syslog-ng/conf.d/simut.conf:

source s_simut {
    syslog(ip("0.0.0.0") port(514) transport("udp"));
};

destination d_simut {
    file("/var/log/simut/${HOST}.log" create-dirs(yes)
         template("${R_ISODATE} ${HOST} ${PROGRAM} ${MSGID} ctx=${.SDATA.simut@32473.ctx} ${MESSAGE}\n"));
};

log { source(s_simut); destination(d_simut); };
  • ${PROGRAM} é o módulo, e ${MSGID} é o código do evento.
  • ${.SDATA.simut@32473.ctx} é o contexto; troque ctx por core ou up para os outros campos.
  • ${R_ISODATE} é a hora de chegada ao coletor; ${ISODATE} é a hora que veio na linha.

Ver no journald

O journald não recebe syslog pela rede. Para ver as linhas com journalctl, receba-as com o rsyslog e repasse-as ao journal com o módulo omjournal:

module(load="imudp")
module(load="omjournal")
input(type="imudp" port="514" ruleset="simut-journal")

ruleset(name="simut-journal") {
    action(type="omjournal")
}

Depois de reiniciar o rsyslog, journalctl -f mostra as linhas chegando. Guarde uma cópia em arquivo também, como na seção do rsyslog: o arquivo mantém a linha RFC 5424 completa, com os dados estruturados.

Filtrar por código

Filtre pelo MSGID, que é o código do evento e não muda com o idioma. Alguns códigos úteis numa trilha de auditoria:

Código Descrição
300 Login bem-sucedido (também as saídas; o detalhe diz qual)
301 Falha de login
302 Acesso não autorizado
303 Config alterada
31 Falha de telemetria
36 MQTT desconectado
512 Histórico pulado: sem referência de hora
513 Histórico retomado: referência de hora obtida

A lista completa está no apêndice B.

No rsyslog, separe os eventos de segurança num arquivo próprio, dentro do ruleset:

if $msgid == "301" or $msgid == "302" or $msgid == "303" then {
    action(type="omfile" file="/var/log/simut/seguranca.log" template="RSYSLOG_SyslogProtocol23Format")
}

Outras propriedades úteis do rsyslog: $app-name (o módulo), $hostname (o Nome), $fromhost-ip (o endereço de origem) e $syslogseverity (a severidade, de 0 a 7).

No syslog-ng, o mesmo filtro:

filter f_simut_seguranca { match("^30[1-3]$" value("MSGID")); };
destination d_simut_seguranca { file("/var/log/simut/seguranca.log"); };
log { source(s_simut); filter(f_simut_seguranca); destination(d_simut_seguranca); };

O que se perde, e quando a linha sai

Quando sai. O aparelho guarda a linha numa fila de 8 linhas na RAM e a manda na passada seguinte do laço principal, que roda o tempo todo, inclusive com um menu aberto no painel. Cada passada manda até 8 linhas. Ao contrário da telemetria, o syslog não espera sinal forte: basta o Wi-Fi estar conectado.

O que se perde:

  • Os eventos do começo do boot. O encaminhamento só começa depois que a rede e a telemetria sobem. Os registros de partida, inclusive o que explica o reinício (código 1, Boot do sistema, com a autópsia de um travamento), ficam só no log de eventos local (capítulo 16).
  • O excesso da fila. Se mais de 8 linhas esperam, a mais antiga sai para dar lugar à nova. Isso acontece no boot, com o Wi-Fi fora do ar ou com o AP de configuração aberto: nesses casos, só as 8 linhas mais novas chegam quando a rede volta.
  • Um envio que falha. A linha é descartada, sem nova tentativa.
  • O que a rede perde. O UDP não confirma a entrega. Um datagrama perdido no caminho não deixa rastro no aparelho nem no coletor.
  • A fila num travamento ou falta de energia. A fila está na RAM. Na maioria dos reinícios pedidos, como Salvar e reiniciar, o aparelho esvazia a fila antes de reiniciar. Ao formatar o sistema de arquivos e ao restaurar um backup com arquivos, ele reinicia sem esvaziar. Num travamento ou numa queda de energia, a fila se perde.
  • O que acontece com o AP de configuração aberto. Enquanto o ponto de acesso de configuração está aberto, o aparelho não manda nada (capítulo 9).
  • Texto longo. O que passa de 255 bytes na linha é cortado.

O syslog e o log de eventos

Log de eventos (flash) Syslog
Onde fica No aparelho, de 800 a 1.600 eventos No coletor, pelo tempo que você quiser
Filtro de rotina Sim: rotina só na mudança de estado Não: toda ocorrência
Eventos de depuração Nunca Com Nível Mínimo em Debug
Texto do evento Não: só código e contexto Sim: descrição e detalhe
Registros do começo do boot Sim Não
Entrega Garantida enquanto a flash funciona Melhor esforço, sem confirmação
Códigos Os do apêndice B Os mesmos, no MSGID

O capítulo 16 explica o log de eventos e como ler um travamento. O apêndice B lista todos os códigos, com a descrição em português.

Segurança

  • O UDP não autentica nada. Qualquer máquina da rede pode mandar ao coletor uma linha que parece vir do aparelho. Aceite no coletor só os endereços dos aparelhos, pelo firewall ou por uma regra como if $fromhost-ip != "192.0.2.10" then stop no rsyslog.
  • O texto viaja aberto. As linhas levam nomes de contas e de arquivos. Mantenha o coletor na mesma rede local dos aparelhos.
  • O aparelho não cifra o syslog. Não há syslog sobre TLS.

No SIMUT Air

air

O Air só manda syslog acordado em M0 (capítulo 19). Nos despertares do ciclo (M1), o laço principal não esvazia a fila e o despertar termina num reinício do processador sem passar pelo esvaziamento: as linhas desses despertares não saem. Os eventos continuam no log de eventos local (capítulo 16).

Limites

  • Só IPv4, sem nome de servidor.
  • Só UDP, sem TCP nem TLS.
  • Um coletor só. Para mais destinos, repasse a partir do coletor.
  • Facilidade fixa local0.
  • Sem os registros do começo do boot, inclusive a autópsia de um travamento. Por isso, com o Nível Mínimo em Fatal, nada é enviado.
  • Sem garantia de entrega e sem aviso de perda.
  • Sem hora (-) até o aparelho acertar o relógio.
  • Nada com o AP de configuração aberto nem nos despertares do Air.

Voltar ao sumário

Capítulo 26

API REST

Este capítulo é a referência da interface de programação do aparelho: como abrir sessão, o que cada uma das 62 rotas faz, que permissão ela exige e o que ela responde. É para quem escreve um cliente, um script ou um servidor de gestão que fala com o aparelho.

Antes de começar

A interface de programação é a mesma que a interface web usa. Toda página do navegador busca os dados em rotas /api/..., e tudo que a página faz um cliente seu também pode fazer, com a mesma conta e as mesmas permissões.

Endereço e porta

Situação Endereço base
HTTP, porta de fábrica http://192.0.2.10
HTTP, outra porta http://192.0.2.10:8080 (o campo Porta HTTP, capítulo 9)
release HTTPS, com o par de certificados instalado https://192.0.2.10 (porta 443)
release HTTPS com outra porta configurada https://192.0.2.10:8443, na porta configurada
Ponto de acesso de configuração Sempre HTTP (capítulo 9)
release Pelo nome http://simut.local, com o Nome do aparelho (capítulo 9)

O aparelho atende um protocolo por vez. Com o par de certificados instalado, a imagem release sobe só em HTTPS e não abre um HTTP ao lado. Quando a porta configurada é a de fábrica, 80, o HTTPS usa a 443; qualquer outra porta configurada é usada como está, já com TLS. Sem par, ou no ponto de acesso de configuração, tudo é HTTP. O capítulo 9 explica a instalação do par (Instalar o par).

O que existe em cada imagem

Imagem Rotas Diferença
release 62 Todas
alpha 54 Sem as 5 rotas do painel, sem GET /api/themes e POST /api/reset_touch_cal, e sem POST /api/tls
Air 54 As mesmas da alpha, e só enquanto o Air está acordado em M0 (capítulo 19)

Até a v2.7.3 a alpha e o Air tinham 56: GET /api/themes e POST /api/reset_touch_cal respondiam também nelas, sem painel para usar. Uma rota que não existe na imagem responde como qualquer caminho desconhecido (Convenções).

Um pedido por vez

O aparelho é um microcontrolador e atende um pedido de cada vez. Pedidos em paralelo ao mesmo aparelho esperam na fila e podem estourar o tempo do cliente. Mande um pedido, espere a resposta e só então mande o seguinte. As conexões persistentes (keep-alive) vêm ligadas de fábrica (capítulo 9) e evitam refazer a conexão a cada pedido, o que pesa principalmente em HTTPS.

Use um tempo de espera generoso no cliente: 10 s para leituras simples, 30 s para exportações, listagens e histórico, e 60 s para envio de arquivo e atualização de firmware.

Formatos do corpo

Forma Rotas
Formulário (application/x-www-form-urlencoded) login, login_chpass, force_chpass, commit_all, action, delete, mkdir, history_rebind, save_sys, touch
JSON cru no corpo, com Content-Type: application/json calib, set_time
Texto PEM cru, com um Content-Type que não seja de formulário tls
multipart/form-data upload, restore
Sem corpo clear_logs, reset_touch_cal, ota/apply

Uma rota que espera JSON cru não enxerga um corpo enviado como formulário, e responde como se o corpo estivesse vazio.

Autenticação

A entrada, passo a passo

Entrar leva dois pedidos: um para pegar um código de uso único, outro para enviar a conta, a senha e o código.

  1. Peça o código com GET /api/login_init.
  2. Calcule o SHA-256 da senha, em hexadecimal minúsculo (A senha em SHA-256).
  3. Envie POST /api/login com os campos de formulário user, pass e nonce.
  4. Guarde o token de sessão que volta no cabeçalho Set-Cookie.
  5. Mande o token em todos os pedidos seguintes, como cookie ou como Authorization: Bearer.
H=http://192.0.2.10
HASH=$(printf '%s' "$SIMUT_WEB_PASS" | sha256sum | cut -d' ' -f1)
NONCE=$(curl -s "$H/api/login_init" | sed 's/.*"nonce":"\([^"]*\)".*/\1/')
curl -s -c jar -X POST "$H/api/login" \
  --data-urlencode "user=$SIMUT_WEB_USER" \
  --data-urlencode "pass=$HASH" \
  --data-urlencode "nonce=$NONCE"
{"ok":true,"redirect":"/"}

Depois disso, curl -b jar ... leva o cookie em cada pedido. Mantenha a senha numa variável de ambiente, nunca no script.

Figura 198. A entrada em dois pedidos. O código de uso único vale 60 s e serve para uma única tentativa.

GET /api/login_init responde:

{"nonce":"9f2c4e1a7b3d5f60a1c2e3f4a5b6c7d8","locked":false,"lockSec":0}
Campo Significado
nonce Código de uso único, 32 algarismos hexadecimais
locked true se o seu endereço está bloqueado por senha errada
lockSec Segundos que faltam para o bloqueio acabar

Regras do código:

  • ele pertence ao endereço IP de quem pediu, não a um cookie;
  • vale 60 s;
  • serve para uma única tentativa, certa ou errada: peça outro código antes de cada tentativa;
  • um segundo login_init do mesmo endereço gera um código novo, e o anterior continua valendo até vencer. Um terceiro pedido descarta o primeiro.

Sem um login_init antes, o POST /api/login é recusado.

POST /api/login responde:

Status Corpo Quando
200 {"ok":true,"redirect":"/"} Entrada aceita
200 {"ok":true,"redirect":"/force_chpass"} Entrada aceita, mas a conta precisa trocar a senha (Troca de senha)
400 {"ok":false,"err":1} Falta o campo user ou pass
401 {"ok":false,"err":1} Código ausente, errado, já usado ou vencido; ou nome e senha fora do tamanho
401 {"ok":false,"err":2,"lockSec":2} Conta ou senha errada. lockSec é a espera antes da próxima tentativa
403 {"ok":false,"err":2,"lockSec":37} O endereço está bloqueado. A senha nem foi conferida
403 {"ok":false,"err":3} As três vagas de sessão estão ocupadas por outras contas

O destino vem no corpo, em redirect. A resposta não tem cabeçalho Location: um cliente que procura o destino ali nunca vê a troca de senha obrigatória.

Conferir a senha leva cerca de 0,4 s no aparelho, porque o resumo guardado é recalculado com 5000 rodadas (capítulo 29).

A senha em SHA-256

O campo pass do POST /api/login não é a senha: é o SHA-256 dela, em 64 algarismos hexadecimais minúsculos. É o que a página de entrada calcula no navegador, e vale igual em HTTP e em HTTPS.

O resumo é calculado sobre os bytes da senha em Latin-1 (ISO-8859-1), um byte por caractere. Para senhas só com caracteres ASCII, isso é o mesmo que calcular sobre o UTF-8, e printf '%s' | sha256sum dá o valor certo. Para uma senha com acentos, codifique em Latin-1 antes de calcular. Caracteres fora do Latin-1, como emojis, não funcionam nem na página de entrada: para contas usadas por programas, prefira senhas ASCII.

Cookie ou Bearer

A sessão é um token de 32 algarismos hexadecimais. Ele chega no cabeçalho da resposta de entrada:

Set-Cookie: SIMUTSESS=5d0c9e7a41b2f3e8c6a9d0b1e2f3a4b5; Path=/; HttpOnly; SameSite=Strict

Em HTTPS, o cookie ganha também o atributo Secure. O cookie não tem prazo: ele vale enquanto a sessão existir no aparelho.

O mesmo token funciona de dois jeitos:

Forma Cabeçalho do pedido Para quem
Cookie Cookie: SIMUTSESS=<token> Navegador, curl -b, bibliotecas com pote de cookies
Bearer Authorization: Bearer <token> Clientes sem pote de cookies e o gestor de frota no navegador (capítulo 27)

Os dois são a mesma sessão, com as mesmas vagas e o mesmo prazo.

Um cliente fora do navegador lê o token no próprio Set-Cookie:

TOKEN=$(curl -s -D - -o /dev/null -X POST "$H/api/login" \
  --data-urlencode "user=$SIMUT_WEB_USER" \
  --data-urlencode "pass=$HASH" \
  --data-urlencode "nonce=$NONCE" \
  | sed -n 's/^[Ss]et-[Cc]ookie: SIMUTSESS=\([0-9a-f]*\).*/\1/p')
curl -s -H "Authorization: Bearer $TOKEN" "$H/api/status"

Uma página de outra origem não consegue ler o Set-Cookie. Para ela, o aparelho põe o token no corpo da resposta, mas só quando o pedido vem da origem autorizada no CORS (CORS):

{"ok":true,"redirect":"/","token":"5d0c9e7a41b2f3e8c6a9d0b1e2f3a4b5"}

Sessões

Regra Valor
Sessões ao mesmo tempo 3, divididas entre navegadores, scripts e o gestor de frota
Sessões por conta 1. Entrar de novo com a mesma conta substitui a sessão anterior, e o token antigo para de valer
Ociosidade 15 min sem nenhum pedido autenticado encerram a sessão
O que renova Qualquer pedido autenticado, em qualquer rota
Reinício Encerra todas as sessões
Vagas cheias Uma quarta conta recebe 403 {"ok":false,"err":3}. Ninguém é despejado

Duas consequências para quem escreve um cliente:

  • Não abra uma sessão por pedido. Entre uma vez, guarde o token e só entre de novo quando a sessão morrer (401 e 403).
  • Não compartilhe uma conta entre dois processos. Cada entrada derruba a sessão do outro. Dê uma conta a cada processo, lembrando o teto de três sessões.

Uma conta sem nenhuma permissão consegue entrar, mas o aparelho a trata como sem sessão em todas as rotas.

Sair

GET /logout encerra a sessão cujo token vem no pedido, e só ela.

Pedido Resposta
Com Authorization: Bearer e sem cookie 204, sem corpo
Com cookie 302 para /login, com um Set-Cookie que apaga o cookie

A rota não exige autenticação: apresentar o token já é a prova, e a única coisa que ele permite é encerrar a própria sessão. Saia ao terminar, para devolver a vaga sem esperar os 15 min.

curl -s -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN" "$H/logout"
204

Troca de senha

As contas de fábrica, uma conta nova, uma conta resetada e o administrador depois de um reset pelo console precisam trocar a senha antes de configurar (capítulo 13). O cliente fica sabendo de três jeitos:

  • a entrada responde "redirect":"/force_chpass";
  • GET /api/perms traz "mc":1;
  • POST /api/commit_all, POST /api/action?op=reboot e POST /api/clear_logs respondem 409:
{"error":"Password change required","next":"/api/force_chpass"}

As leituras continuam funcionando enquanto a troca está pendente. As páginas da interface web levam para /force_chpass.

Há duas rotas de troca:

Rota Sessão Campos
POST /api/force_chpass Exige a sessão da conta, com a troca pendente p1 e p2, a senha nova duas vezes
POST /api/login_chpass Não exige sessão; usa o código de login_init user, oldpass, newpass, nonce

O formato das senhas nessas duas rotas depende do protocolo, ao contrário da entrada:

Protocolo O que enviar Regra da senha nova
HTTP O SHA-256 hexadecimal de cada senha, 64 caracteres O aparelho não consegue conferir a força; a página confere antes de enviar (capítulo 8)
HTTPS A senha em texto, sem resumo Pelo menos 8 caracteres, com letra e algarismo. O aparelho confere e calcula o resumo

Respostas de POST /api/force_chpass:

Status Corpo Quando
200 {"status":"ok"} Senha trocada. A sessão continua
400 {"error":"Invalid payload"} HTTP: p1 sem 64 caracteres, ou diferente de p2
400 {"error":"Weak password: min 8 chars with a letter and a digit"} HTTPS: senha fraca, ou p1 diferente de p2
403 Forbidden (texto) Sem sessão, ou a conta não tem troca pendente
503 {"error":"Display in use. Retry shortly."} Alguém tocou no painel há menos de 5 s

Respostas de POST /api/login_chpass:

Status Corpo Quando
200 {"ok":true} Senha trocada. Nenhuma sessão é aberta: entre de novo
400 {"ok":false,"err":1} Falta um campo
400 {"ok":false,"err":5} A senha nova é igual à atual
401 {"ok":false,"err":1} Código inválido, ou senha nova fora da regra
401 {"ok":false,"err":2,"lockSec":2} Senha atual errada, com bloqueio
403 {"ok":false,"err":2,"lockSec":37} O endereço está bloqueado

Trocar a senha pela web não reinicia o aparelho.

Bloqueio por tentativas

Cada senha errada bloqueia o endereço IP de origem por um tempo que dobra a cada erro: 2 s, 4 s, 8 s e assim por diante, até 300 s a partir do nono erro. A contagem só volta a zero com uma entrada, ou uma troca de senha, bem-sucedida a partir daquele endereço (capítulo 13).

  • O bloqueio vale para POST /api/login, POST /api/login_chpass e a conta e senha do HTTP Basic de /metrics (capítulo 24).
  • Um código vencido também conta como erro.
  • O aparelho guarda o estado de até 8 endereços. Se os 8 estiverem bloqueados, um endereço novo recebe, já no login_init:
HTTP/1.1 429 Too Many Requests
Retry-After: 42

{"ok":false,"err":3,"retryAfter":42}

Consulte locked e lockSec no login_init antes de tentar de novo. Tentar durante o bloqueio não adianta: o aparelho responde sem conferir a senha.

Quem tem a permissão Usuários PERM_USER_MGR vê a tabela de bloqueios em GET /api/sec_status:

{"slots":[{"ip":"192.0.2.55","fails":3,"lockSec":5,"ageSec":3}]}
Campo Significado
ip Endereço de origem
fails Erros seguidos. Para de subir em 12
lockSec Segundos de bloqueio que faltam; 0 = livre
ageSec Segundos desde o último pedido de entrada desse endereço

CORS

Uma página hospedada em outro servidor, como o gestor de frota (capítulo 27), só fala com o aparelho se ele autorizar a origem dela. A origem se configura pelo console serial ou pela chave cors da seção sys do commit_all, e vale depois de um reinício (capítulo 9).

Com uma origem configurada:

  • toda resposta, inclusive as de erro, leva Access-Control-Allow-Origin: <a origem>;
  • o pedido de verificação do navegador (OPTIONS, a preflight) recebe 204, sem pedir autenticação, com:
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600
  • a resposta de entrada traz o token no corpo quando o cabeçalho Origin do pedido é exatamente a origem configurada.

Sem origem configurada, um OPTIONS recebe 405 com o texto CORS disabled. Isso separa “este aparelho não foi liberado para o gestor” de “caminho errado”.

O aparelho não envia Access-Control-Allow-Credentials. Por isso a página de outra origem não usa cookie: ela guarda o token e manda Authorization: Bearer em cada pedido.

const base = 'http://192.0.2.10';
async function status(token) {
  const r = await fetch(base + '/api/status', {
    headers: { 'Authorization': 'Bearer ' + token }
  });
  if (r.status === 401) throw new Error('sessão encerrada: entre de novo');
  return r.json();
}

O aparelho também não envia Access-Control-Expose-Headers. Uma página de outra origem lê o status e o corpo, mas não lê cabeçalhos como Retry-After ou os X-Backup-* do backup.

Respostas e erros

Códigos HTTP

Status Significado O que fazer
200 Feito. Em commit_all, leia rejected, reboot e applied no corpo —
202 Aceito e em andamento (busca de sensores, atualização de firmware) Acompanhe pela rota indicada
204 Nada a devolver (bloco aberto vazio, saída com Bearer, preflight) —
302 Página que exige sessão, pedida sem sessão; ou saída com cookie Siga só se for um navegador
400 Pedido malformado ou parâmetro fora da regra. Nada foi aplicado Corrija o pedido
401 Sem sessão viva (401 e 403) Entre de novo, uma vez, e repita
403 Sessão viva sem a permissão; ou, em várias rotas, sem sessão Veja 401 e 403
404 Caminho inexistente, arquivo inexistente, ou sensor não encontrado —
405 OPTIONS com o CORS desligado Configure a origem (capítulo 9)
409 Estado errado: troca de senha pendente, captura de tela em andamento, atualização sem imagem preparada, ou alteração que exige reinício num _nosave Leia o error do corpo
413 Corpo acima do teto: 8.192 bytes em calib e tls Divida o pedido
416 Pedaço de captura fora de 0 a 14 —
422 Arquivo recusado na validação: backup, imagem de firmware, sonda com endereço inválido Leia st ou v no corpo
429 Limite de ritmo ou bloqueio de entrada Espere o que o corpo ou o Retry-After indicar
500 Falha interna: gravação na flash, sem painel, resposta longa demais Tente de novo; se repetir, veja o log de eventos
501 Recurso fora desta imagem (aceitar sonda DS18B20 sem o driver) —
503 Ocupado agora (Ocupado) Tente de novo em alguns segundos

401 e 403: nem toda rota distingue

Parte das rotas distingue “sem sessão” (401) de “sessão sem a permissão” (403). As demais respondem 403 nos dois casos.

Respondem 401 sem sessão Respondem 403 também sem sessão
/api/status, /api/perms, /api/config, /api/network, /api/wifi/scan, /api/users, /api/themes, /api/alarms, /api/sec_status, /api/action, /api/commit_all, /api/set_time, /api/screen_stream, /api/touch, /api/keypad, /metrics Todas as outras rotas protegidas: histórico, log de eventos, arquivos, calibração, sensores, backup, restauração, atualização, TLS, captura de tela, save_sys, reset_touch_cal, history_rebind, clear_logs, force_chpass

Receita para um cliente:

  1. Recebeu 401: entre de novo uma vez e repita o pedido.
  2. Recebeu 403: pergunte GET /api/perms.
  3. Se /api/perms responde 401, a sessão morreu: entre de novo e repita.
  4. Se /api/perms responde 200, a conta não tem a permissão. Não insista: entrar de novo não muda nada.

As páginas HTML não usam nenhum dos dois: sem sessão, elas respondem 302 para /login; sem permissão, 403 com uma página curta.

O corpo de erro

A maioria das rotas responde erro em JSON, com um campo error:

{"error":"Forbidden"}

Não conte com isso sempre. Confira o Content-Type antes de interpretar:

Formato Onde aparece
{"error":"..."} A maioria das rotas /api/...
{"ok":false,"err":N} Entrada e troca de senha
Texto puro, como Forbidden, Too Fast, System Busy, File Not Found. Arquivos, log de eventos, backup, restauração, capturas e /metrics
Corpo vazio GET /api/history_days sem a permissão

Os códigos err da entrada:

err Significado
1 Pedido inválido: campo ausente, código errado ou vencido, tamanho fora da regra
2 Senha errada ou endereço bloqueado. Vem com lockSec
3 Sem vaga: sessões cheias, ou os 8 bloqueios ocupados (com retryAfter)
5 Troca de senha: a nova é igual à atual

Limites de ritmo

Quatro rotas exigem um intervalo mínimo entre pedidos:

Rota Intervalo Resposta quando rápido demais
GET /api/logs 200 ms 429 Too Fast (texto)
GET /api/ls 200 ms 429 {"error":"Too Fast"}
POST /api/calib 5 s 429 {"error":"rate limited"}, com Retry-After: 5
POST /api/tls 5 s 429 {"error":"rate limited"}, com Retry-After: 5

O intervalo conta por endereço IP de origem, e as quatro rotas dividem o mesmo relógio: um GET /api/ls seguido, menos de 5 s depois, de um POST /api/calib recebe 429 no segundo pedido. Um pedido recusado não reinicia a contagem. A permissão é conferida antes do ritmo.

Ocupado: 503

Corpo Causa Espera sugerida
{"error":"Display in use. Retry shortly."} Alguém tocou no painel, ou mandou POST /api/touch, há menos de 5 s. Vale para commit_all, op=reboot, a troca de senha obrigatória, apagar arquivo, criar pasta, restaurar, atualizar, limpar o log, capturas de tela, gráficos e exportações do histórico e a leitura do log de eventos O Retry-After do cabeçalho: 5 s nas gravações, 3 s nas leituras
System Busy ou {"error":"System Busy"} Outra tarefa pesada ocupa a flash Alguns segundos
{"error":"Already processing"} Outro pedido de histórico está em andamento Espere o outro terminar
{"scanning":false,"error":"busy"} O rádio está ocupado (Busca de redes) Alguns segundos
{"error":"NTP not synced"} A calibração exige o relógio acertado Acerte o relógio (capítulo 10)
{"error":"no memory"} Sem memória para a cópia do ensaio Tente de novo

Convenções

  • Horários são segundos desde 1970 em UTC (epoch), como 1790164800. A exceção é uptime, em milissegundos.
  • Tamanhos são em bytes.
  • Valores lógicos chegam como true e false na maioria das respostas, e como 1 e 0 em alguns campos, como ntp, tel e cap; confira a tabela de cada rota. Nos pedidos, o aparelho aceita true, false, 1 e 0, com ou sem aspas.
  • O tipo do corpo decide como ele é lido. Com Content-Type: application/x-www-form-urlencoded, que é o padrão do curl -d, o aparelho lê campos de formulário. Com qualquer outro tipo, ele guarda o corpo cru e não lê campos. Por isso set_time e calib precisam de -H 'Content-Type: application/json', e commit_all precisa ir como formulário.
  • Texto com acento vai em UTF-8 direto no JSON. O aparelho não decodifica a forma \uXXXX: um nome enviado como "Cozinha \u00e7" é gravado com a barra e os seis caracteres. Em Python, use json.dumps(dados, ensure_ascii=False).
  • Campo desconhecido num pedido é ignorado em silêncio. Confira o efeito lendo o estado de volta.
  • Caminho inexistente responde 404 com o texto 404: Not Found. Se o cabeçalho Host do pedido não é o IP do aparelho nem termina em .local, a resposta é um 302 para http://<ip>/network, o comportamento de portal do ponto de acesso. Uma rota com o método errado, como GET /api/commit_all, conta como caminho inexistente.

As 62 rotas

As tabelas usam o nome do bit de cada permissão. O nome que a página Usuários mostra e o que cada bit libera estão no capítulo 8. “Administrador completo” é a conta com todas as permissões, 0xFFFF (capítulo 8); nenhuma combinação das 13 permissões substitui esse nível.

Páginas

Método Rota Permissão O que faz
GET /login Pública Página de entrada
GET / PERM_DASHBOARD Página Painel de Controle
GET /history PERM_HISTORY ou PERM_LOGS Página Histórico e Logs
GET /config PERM_SYS_CONFIG Página Configurações
GET /alarms PERM_SYS_CONFIG Página Alarmes e Sons
GET /telemetry PERM_SYS_CONFIG Página Telemetria
GET /network PERM_NET_CONFIG Página Rede
GET /users PERM_USER_MGR Página Usuários
GET /files PERM_FILE_READ Página Arquivos
GET /license PERM_DASHBOARD Página Licença
GET /force_chpass Sessão com troca de senha pendente Página de troca de senha obrigatória

Arquivos estáticos

Método Rota Permissão O que faz
GET /lang.js Pública Script de tradução das páginas
GET /style.css Pública Folha de estilo
GET /favicon.ico Pública Ícone do site
GET /apple-touch-icon.png Pública Responde 204, sem conteúdo
GET /api/lang Pública Dicionário de textos da interface web do pacote de idioma ativo; {} sem pacote

Sessão e senha

Método Rota Permissão O que faz
GET /api/login_init Pública Entrega o código de uso único e o estado do bloqueio
POST /api/login Pública, com bloqueio Confere conta e senha e abre a sessão
POST /api/login_chpass Pública, com bloqueio Troca a senha sem sessão, com a senha atual
POST /api/force_chpass Sessão com troca pendente Conclui a troca de senha obrigatória
GET /logout Pública Encerra a sessão do token apresentado
GET /api/perms Qualquer sessão Conta, permissões, versão e idioma da sessão
GET /api/sec_status PERM_USER_MGR Tabela de bloqueios de entrada

Estado e configuração

Método Rota Permissão O que faz
GET /api/status PERM_DASHBOARD Identidade, saúde e leituras atuais
GET /api/themes PERM_DASHBOARD release Temas do painel disponíveis
GET /metrics PERM_DASHBOARD, por sessão ou HTTP Basic Métricas no formato do Prometheus (capítulo 24)
GET /api/config PERM_SYS_CONFIG Configuração geral, telemetria, linha de alarmes, syslog e política de PIN
GET /api/alarms PERM_SYS_CONFIG Limites, alarmes ligados e janelas de manutenção por slot, e os sons
GET /api/sensors PERM_SYS_CONFIG Tipos de sensor e o mapa completo dos 16 slots
GET /api/network PERM_NET_CONFIG Estado e configuração de rede
GET /api/wifi/scan PERM_NET_CONFIG Busca de redes Wi-Fi
GET /api/users PERM_USER_MGR Contas, permissões e se cada uma tem PIN
GET /api/calib PERM_CALIB Curvas de calibração dos sensores
POST /api/commit_all PERM_SYS_CONFIG, PERM_NET_CONFIG ou PERM_USER_MGR, e a de cada seção Grava configuração, alarmes, rede e contas
POST /api/calib PERM_CALIB Grava curvas de calibração (capítulo 6)
POST /api/action PERM_SYS_CONFIG Reinício, telemetria e sondas, pelo parâmetro op
POST /api/set_time PERM_SYS_CONFIG Acerta o relógio na hora
POST /api/save_sys PERM_SYS_CONFIG Troca o tema do painel na hora
POST /api/reset_touch_cal PERM_SYS_CONFIG release Apaga a calibração do toque e abre o assistente no painel

Histórico e log de eventos

Método Rota Permissão O que faz
GET /api/history_days PERM_HISTORY Lista os dias com histórico
GET /api/history_multi PERM_HISTORY Séries de vários slots em JSON, para gráficos
GET /api/history/open PERM_HISTORY O bloco aberto, ainda não selado
GET /api/export/history.bin PERM_HISTORY Exporta até 31 dias num pacote .simx
POST /api/history_rebind PERM_SYS_CONFIG Adapta o dia corrente ao esquema atual e reinicia
GET /api/logs PERM_LOGS O log de eventos inteiro, em registros binários
GET /api/logcodes PERM_LOGS Os nomes dos eventos, em texto: no idioma do pacote e em inglês
GET /api/export/logs.bin PERM_LOGS Exporta até 31 dias do log num pacote .simx
POST /api/clear_logs PERM_LOGS e PERM_SYS_CONFIG Apaga o log de eventos

Arquivos

Método Rota Permissão O que faz
GET /api/ls PERM_FILE_READ Lista uma pasta
GET /download PERM_FILE_READ; mais PERM_HISTORY em /history e PERM_LOGS em .blog Baixa um arquivo
POST /api/upload PERM_FILE_UPLOAD Envia um arquivo
POST /api/mkdir PERM_FILE_UPLOAD Cria uma pasta
POST /api/delete PERM_FILE_DELETE Apaga um arquivo

Backup, atualização e certificado

Método Rota Permissão O que faz
GET /api/backup Administrador completo Baixa o backup .bkp do sistema de arquivos inteiro
POST /api/restore?op=validate PERM_FILE_READ Confere um .bkp sem gravar
POST /api/restore?op=apply Administrador completo Restaura um .bkp e reinicia
POST /api/restore?op=stage Administrador completo Recebe e valida uma imagem de firmware
POST /api/ota/apply Administrador completo Aplica a imagem preparada e reinicia
POST /api/tls Administrador completo release Instala o par de certificados HTTPS (capítulo 9)

As três operações de /api/restore são uma única rota com o parâmetro op, e contam como uma rota no total de 61.

Painel

release

Método Rota Permissão O que faz
GET /api/screenshot PERM_SYS_CONFIG Captura da tela do painel em BMP
GET /api/screenshot_chunk PERM_SYS_CONFIG Um pedaço da captura, com CRC
GET /api/screen_stream PERM_SYS_CONFIG Um quadro do painel no formato compacto do espelho
POST /api/touch PERM_SYS_CONFIG Um toque no painel, ou um toque longo com ms
GET /api/keypad PERM_SYS_CONFIG As faces do teclado de PIN na tela

São 62 rotas: 52 exigem uma permissão ou uma sessão, e 10 são públicas por projeto. O repositório confere essa lista a cada mudança, e nenhuma rota fica sem portão (capítulo 29).

Receitas

Os exemplos usam curl, as variáveis de A entrada, passo a passo e o pote de cookies jar. Os valores nas respostas são ilustrativos; os nomes e a forma dos campos são os do aparelho.

Estado do aparelho

GET /api/status é a rota de monitoramento. Ela exige só a permissão Painel PERM_DASHBOARD e responde em três blocos: sys, metr e sensors.

curl -s -b jar "$H/api/status"
{"sys":{"name":"simut","ver":"2.7.1","env":"release","uid":"E6614C311B7A2F2D",
 "mac":"28:cd:c1:0a:1b:2c","cfg":"3F2A91C4","uptime":29260512,"rssi":-58,
 "ip":"192.0.2.10","theme":0,"heap_f":61240,"heap_t":230400,"heap_lb":40960,
 "fs_u":413696,"fs_t":1048576,"time":1790164800,"ntp":1,"pending":0,"tel":1,
 "hi":1,"cap":1,"feat":262026,"clk_peri":133000000,"tft_hz":66500000},
 "metr":{"lb":40960,"lbm":33792,"hm":52112,"wf":0,"mq":0,"rmn":-63,"rmx":-55,
 "ts":135,"tf":0,"tr":0,"tb":412345,"tl":180,"so":24000,"se":2,"cs":3,
 "fo":210,"fom":38,"fot":2100,"f50":0,"fx":0,"ad":0,"c1a":12,"c1n":1,
 "c1kl":0,"c1kh":0,"c1kq":0,"c1s":0,"cgd":0,"cgg":0,"cgx":0,"cgw":0},
 "sensors":[
  {"slot":0,"gpio":2,"id":"FRIDGE","name":"Geladeira","type":"DS18B20","ch":1,
   "pc":1,"pr":"1-Wire","val":4.25},
  {"slot":1,"gpio":4,"id":"AMB","name":"Sala","type":"BME280","ch":3,"pc":2,
   "pr":"SDA,SCL","val":23.10,"hum":55.2,"press":1012.8}]}

O bloco sys:

Campo Significado
name Nome do aparelho
ver Versão do firmware
env Imagem: release, alpha ou air
uid Número de série da placa, 16 algarismos hexadecimais. Use como chave do aparelho (capítulo 20)
mac Endereço MAC do Wi-Fi
cfg CRC-32 da configuração em uso, o mesmo valor do cabeçalho X-SIMUT-Cfg da telemetria
uptime Milissegundos desde o boot. Volta a zero a cada 49,7 dias sem reinício
rssi Sinal Wi-Fi agora, em dBm; −100 sem conexão ou com leitura impossível
ip Endereço IP
theme Índice do tema do painel (Temas)
heap_f, heap_t Memória livre e total, em bytes
heap_lb Maior bloco de memória livre, em bytes
fs_u, fs_t Sistema de arquivos usado e total, em bytes. Atualiza a cada 10 s
time Relógio do aparelho, em epoch UTC
ntp 1 se o relógio foi acertado pela rede
pending Estimativa de registros de telemetria ainda não entregues. Para em 65535; -1 sem telemetria
tel 1 se a telemetria está ligada (lote mínimo acima de 0)
hi Intervalo do histórico, em minutos
cap 1 se a imagem tem painel
feat Com que chaves do configurador a imagem foi compilada: um bit por chave, ligado se a chave está ligada. O número de cada chave é o campo bit dela no model.json do configurador e nunca muda. Serve para não chamar o que a imagem não tem — a página de histórico (web_history, bit 13), a API de exportação (web_export_api, bit 14), o /metrics (web_metrics, bit 15), o MQTT (tel_mqtt, bit 12), o TLS da telemetria (tel_tls, bit 11). O SIMUT publicado responde 262026. Um firmware anterior ao campo não o manda: trate a ausência como “tudo o que a variante sempre teve”
clk_peri, tft_hz Só nas imagens com painel release. clk_peri: clock dos periféricos, em Hz, do qual o SPI do painel tira a sua velocidade; é o clock do processador, 133000000 no Pico W e 150000000 no Pico 2 W. tft_hz: velocidade que o SPI do painel recebeu na última escrita de pixels, em Hz, lida dos registradores do SPI; 66500000 no Pico W e 37500000 no Pico 2 W, e 0 até a primeira escrita
slot, trial, reverted Só no Pico 2 W. slot: de que slot da tabela de partições a imagem subiu, A ou B, ou - numa placa sem a tabela. trial: 1 enquanto a atualização instalada está em teste. Ela se confirma depois de rodar saudável por um minuto; se reiniciar antes disso, ou não tiver esse minuto em cinco, o aparelho volta para a imagem anterior. reverted: a versão de uma atualização que não se confirmou, e da qual o aparelho voltou neste boot; vazio no resto do tempo. O painel e a página Arquivos mostram os dois últimos

O bloco metr traz contadores de diagnóstico, zerados a cada boot:

Campo Significado
lb, lbm Maior bloco livre agora e o menor já visto, em bytes
hm Menor memória livre já vista, em bytes
wf, mq Reconexões do Wi-Fi e do MQTT
rmn, rmx Menor e maior sinal Wi-Fi vistos, em dBm; 0 = ainda sem amostra
ts, tf, tr Envios de telemetria aceitos pelo coletor, envios que falharam e novas tentativas
tb, tl Bytes dos envios aceitos, e a latência do último, em ms
so, se Leituras de sensor boas e com erro
cs Gravações da configuração
fo, fom, fot, f50 Gravações na flash: quantidade, a mais longa em ms, o total em ms e quantas passaram de 50 ms
fx Gravações na flash feitas sem pausar o núcleo do painel. Qualquer valor acima de 0 é um defeito a relatar
ad Respostas longas interrompidas e fechadas à força
c1a Idade, em ms, do último sinal de vida do núcleo que desenha o painel. Dezenas de ms é normal; segundos indicam o núcleo parado
c1n, c1kl, c1kh, c1kq, c1s Partidas desse núcleo e interrupções por três causas diferentes; c1s conta travamentos na pausa
cgd, cgg, cgx, cgw Respostas cortadas por prazo, por proteção, por desconexão do cliente e por escrita curta: um envio que não terminou dentro do prazo, e o aparelho encerrou a resposta ali

O bloco sensors lista só os slots ativos:

Campo Significado
slot Número do slot, 0 a 15
gpio Primeiro GPIO do sensor
id Identificador de hardware (hwId), que vira a chave da telemetria
name Nome do sensor
type DS18B20, DHT22, BME280 ou BMP280
ch, pc, pr Número de grandezas, número de pinos e o papel de cada pino
val Temperatura média, com 2 casas. "Error" com o sensor em falha; "--" antes da primeira leitura
hum, press Umidade (%) e pressão (hPa), só nos tipos que medem e com leitura válida

Quem sou eu

GET /api/perms responde para qualquer sessão, com qualquer permissão. Use-a para conferir se a sessão está viva e o que a conta pode fazer.

{"user":"servidor","perms":7433,"ntp":1,"time":1790164800,"version":"2.7.1",
 "env":"release","mc":0,"langCode":"pt-BR","langName":"Portugues"}
Campo Significado
user Conta da sessão
perms Máscara de permissões, em decimal (capítulo 8)
ntp, time Relógio acertado e a hora atual
version, env Versão e imagem do firmware
mc 1 se a conta precisa trocar a senha
langCode, langName Pacote de idioma ativo; vazios sem pacote

Ler a configuração

GET /api/config exige Sistema PERM_SYS_CONFIG e devolve um único objeto JSON. As chaves são as mesmas que a seção sys do commit_all aceita, com algumas só de leitura. O significado, a faixa e o valor de fábrica de cada campo estão nos capítulos de cada página:

Chaves Assunto Onde está cada campo
name, tz, log, res, s_int, h_int, ntp_enabled Identidade, hora e amostragem Capítulo 5
pin_min, pin_max, pin_kb, pin_alpha release Política de PIN do painel. pin_max é só de leitura Capítulo 8
t_transport, t_sec, t_srv, t_port, t_path, t_key, t_int, t_bat, t_mode, t_glob, t_line, t_sep, t_ct Telemetria Capítulo 21
m_topic, m_cid, m_user, m_qos, m_retain, m_ka MQTT Capítulo 21
m_had Home Assistant Discovery Capítulo 23
a_en, a_mode, a_qmax, a_path, a_glob, a_line, a_sep, a_ct Linha de alarmes Capítulo 22
slog_en, slog_srv, slog_port, slog_lvl Syslog Capítulo 5 e capítulo 25

Chaves só de leitura:

Chave Significado
t_cert true se o arquivo /cert.pem da telemetria foi carregado no boot (capítulo 21)
now_epoch Hora do aparelho
a_pending Registros na fila da linha de alarmes agora
serial Número de série da placa, o mesmo uid do /api/status
sensors Os 16 slots, em ordem: hwid, active e se o tipo mede umidade (hum) e pressão (press)

Dois segredos não voltam inteiros:

  • t_key, a chave de acesso da telemetria, volta mascarada: os 4 primeiros caracteres e ***, ou só *** para chaves de até 4 caracteres. Ao gravar, um valor com *** é ignorado e a chave atual fica.
  • A senha do MQTT e a senha do Wi-Fi não aparecem em nenhuma rota. Na gravação, m_pass vazio mantém a senha atual.

A configuração de rede está em GET /api/network, com a permissão Rede PERM_NET_CONFIG:

{"connected":true,"ip":"192.0.2.10","mask":"255.255.255.0","gw":"192.0.2.1",
 "dns":"192.0.2.1","mac":"28:cd:c1:0a:1b:2c","ssid":"MinhaRede","use_dhcp":true,
 "static_ip":"192.168.1.100","static_mask":"255.255.255.0",
 "static_gw":"192.168.1.1","static_dns":"8.8.8.8","dns_auto":true,"dns2":"",
 "ntp_server":"","ntp_enabled":true,"web_port":80,"web_ka":true,"web_tls":false}

ip, mask, gw e dns são os valores em uso agora; os static_* são os configurados para quando o DHCP está desligado. web_tls diz se o par de certificados está instalado, não se o servidor subiu em HTTPS: um par instalado só vale depois do reinício. Os campos e as chaves de gravação estão no capítulo 9.

Gravar com commit_all

POST /api/commit_all grava quase toda a configuração. É a rota dos três botões da interface web (capítulo 5). O pedido tem um único campo de formulário, _payload, com um JSON de uma ou mais seções, e até 6.144 bytes:

curl -s -b jar -X POST "$H/api/commit_all" \
  --data-urlencode '_payload={"alarms":{"sensors":[{"idx":0,"temp":[2.0,8.0]}]}}'
{"status":"ok","reboot":false,"applied":["alarms"]}

Use --data-urlencode: o JSON tem caracteres que um formulário precisa codificar.

As seções. Cada seção exige a sua permissão, e a gravação é tudo ou nada: com uma seção proibida, nada é gravado.

Seção Permissão Conteúdo Chaves
sys PERM_SYS_CONFIG Identidade, hora, amostragem, política de PIN, telemetria, MQTT, linha de alarmes, syslog e a origem cors Capítulo 5, 21, 22, 9
net PERM_NET_CONFIG Wi-Fi, IP, DNS, NTP e o servidor web Capítulo 9
alarms PERM_SYS_CONFIG Limites, alarmes ligados, janelas de manutenção e sons Alarmes pela API
users PERM_USER_MGR Contas e PIN Contas pela API
slots PERM_SYS_CONFIG Tipo, pinos, identificação, nome, limites e alarme de cada slot Slots pela API
calib PERM_SYS_CONFIG Calibração, como a página a envia Capítulo 6

Para entrar na rota, a conta precisa de pelo menos uma entre Sistema, Rede e Usuários. Uma conta só com Usuários, por exemplo, grava a seção users e nada mais.

Os modos. Um parâmetro extra, ao lado de _payload, muda o que a gravação faz:

Parâmetro O que faz Botão da página
Nenhum Grava e aplica. Reinicia só se algum grupo alterado exigir Aplicar agora
_dry=1 Ensaio: roda todas as verificações numa cópia e responde o que mudaria. Não grava nada O ensaio automático da página
_nosave=1 Aplica na memória, sem gravar. Um reinício desfaz. Recusa com 409 se a mudança exigir reinício Testar
_reboot=1 Grava e reinicia sempre, mesmo sem necessidade Salvar e reiniciar

_dry aceita as seções sys, net, alarms e users; _nosave, só sys, net e alarms. Com outra, a resposta é 400 {"error":"accepts sys, net and alarms only, and users in a dry run"}. air O Air recusa os dois com 400 {"error":"dry run not available on this build"}: no Air, toda gravação é real e reinicia (capítulo 5).

A resposta. Ela diz o que aconteceu. Leia sempre o corpo: um campo recusado volta com status 200.

{"status":"ok","reboot":false,"applied":["alarms","maint"]}
{"status":"ok","reboot":true,"reboot_for":["identity"]}
{"status":"ok","reboot":true,"reboot_for":["net"],"newPort":8080}
{"status":"ok","reboot":true,"reboot_for":["requested"]}
{"status":"ok","reboot":false,"applied":[],"rejected":["t_port"]}
{"status":"ok","reboot":false,"saved":false,"applied":["alarms"]}
{"status":"dry","reboot":true,"applied":["time"],"reboot_for":["time"]}
{"status":"ok","reboot":false,"applied":["users"],"creds":[{"u":"operador1","p":"K7M2QX9A"}]}
Campo Significado
status ok numa gravação ou num _nosave; dry num ensaio
reboot true se o aparelho vai reiniciar, ou reiniciaria no ensaio
applied Os grupos alterados que se aplicaram sem reinício. Só aparece quando não há reinício, e no ensaio
reboot_for Os grupos que obrigam o reinício. Com _reboot=1 sobre uma mudança que não exigia, vem ["requested"]
rejected Campos recusados, que ficaram com o valor anterior (Recusas)
saved Só com _nosave=1, e sempre false
newPort A porta web nova, quando ela mudou. Reconecte nela depois do reinício
creds As senhas de uso único das contas criadas ou resetadas. Só nesta resposta

O que reinicia. O aparelho decide comparando a configuração de antes com a de depois, campo por campo. Um campo reenviado com o valor atual não conta como mudança.

Grupos Efeito
alarms, maint, alarm_tel, telemetry, display, users Aplicam sem reiniciar
net, identity, slots, sensing, mqtt, time, web, unclassified Reiniciam

Quatro campos sem efeito, s_int, log e dois que só o arquivo de configuração carrega, não entram em grupo nenhum e gravam sem reiniciar, desde a v2.7.4. Até a v2.7.3 eles caíam em sensing, logging, net e display_pin, e reiniciavam o aparelho. O que cada grupo inclui está em Os grupos de configuração. Qualquer alteração de conta ou de PIN, e também da política de PIN, cai em users, que se aplica sem reiniciar desde a v2.10.0 (até a v2.9.0, reiniciava). Não copie essa tabela para o seu cliente: use o ensaio, que responde pela regra do próprio aparelho.

Quando há reinício, a resposta chega antes dele. O aparelho fica fora do ar por alguns segundos e encerra todas as sessões. Para saber quando ele voltou, repita GET /api/login_init a cada 3 s até ele responder, e entre de novo.

O ensaio. Use _dry=1 para validar uma configuração antes de gravá-la, por exemplo antes de mandá-la a vários aparelhos (capítulo 27). Ele roda numa cópia e não mexe no aparelho: não grava e não aplica nada.

Até a v2.9.0, o ensaio tinha três limites, corrigidos na v2.10.0:

  • não enxergava h_int, ntp_enabled, slog_*, m_had, dns_auto, dns2 e web_ka, e respondia "reboot":false onde a gravação real reiniciava pelo grupo web;
  • aplicava o fuso horário de verdade;
  • aplicava os sons de verdade, inclusive o silêncio.

O _nosave=1 tinha os mesmos três efeitos. Com um desses campos e outro que exigisse reinício, ele respondia 409 com a memória já alterada.

Erros que recusam a gravação inteira. Nesses casos, nada muda:

Status Corpo Causa
400 {"error":"Missing _payload"} Falta o campo _payload
400 {"error":"Bad payload"} _payload vazio ou acima de 6.144 bytes
400 {"error":"No section"} Nenhuma seção reconhecida no corpo
400 {"error":"Alarm limit outside channel range"} Um limite fora da faixa possível do canal (capítulo 7)
400 {"error":"Alarm limit is not a number"} Um limite de alarme que não é número, como "abc" ou true. null não é recusado: mantém o limite
400 O slot e o GPIO, como slot 4: GP2 already used by slot 2 Conflito de GPIO na seção slots (capítulo 6)
400 {"error":"accepts sys, net and alarms only, and users in a dry run"} _dry ou _nosave com outra seção (users só no _dry)
403 {"error":"Forbidden"} A conta não tem nenhuma das três permissões de entrada
403 {"error":"Forbidden","section":"users"} A conta não tem a permissão da seção indicada
409 {"error":"Password change required","next":"/api/force_chpass"} Troca de senha pendente
409 {"error":"needs a restart; cannot be applied without saving","reboot_for":["time"]} _nosave=1 com uma mudança que exige reinício
500 {"error":"save failed"} A gravação na flash falhou. Tente de novo
503 {"error":"Display in use. Retry shortly."} Alguém tocou no painel há menos de 5 s

Recusas campo a campo

Um valor fora da faixa, ou em formato errado, é descartado sozinho: o campo mantém o valor anterior, o resto da gravação segue e o nome do campo aparece em rejected. Os nomes seguem a seção:

Seção Forma do nome Exemplos
sys O nome da chave t_port, m_qos, h_int, cors, pin_min
net net. e a chave net.ssid, net.dns2, net.web_port, net.ntp_server
alarms maint Janela negativa, ou acima de 30 dias
users users. e o motivo users.perms, users.id, users.pin (Contas pela API)

A lista em rejected tem espaço limitado. Numa gravação com muitos campos errados, alguns nomes podem faltar: confira o resultado lendo o estado de volta.

Contas pela API

A seção users recebe uma lista de ações, executadas na ordem em que chegam, até 16 por pedido. Ela exige Usuários PERM_USER_MGR. As regras de cada campo e o que a página mostra estão no capítulo 8.

Ação Forma
Criar {"type":"add","name":"operador1","perms":6144,"pin":"482913"}. pin é opcional
Apagar {"type":"del","id":3}
Nova senha {"type":"reset","id":3}
Definir ou apagar o PIN {"type":"pin","id":3,"pin":"482913"}. "" apaga o PIN

Listar. Leia as contas e os id antes de apagar ou resetar:

curl -s -b jar "$H/api/users"
[{"id":0,"name":"admin","perms":65535,"pin":true},
 {"id":1,"name":"servidor","perms":7433,"pin":false},
 {"id":3,"name":"operador1","perms":6144,"pin":true}]

id é a posição da conta na tabela, de 0 a 31, e pode ter buracos. pin diz só se a conta tem PIN, nunca qual. alpha air Sem painel, a chave pin não aparece.

Criar.

curl -s -b jar -X POST "$H/api/commit_all" --data-urlencode \
  '_payload={"users":{"actions":[{"type":"add","name":"operador1","perms":6144,"pin":"482913"}]}}'
{"status":"ok","reboot":false,"applied":["users"],"creds":[{"u":"operador1","p":"K7M2QX9A"}]}

A senha de uso único vem em creds, só nesta resposta: o aparelho guarda apenas o resumo. Guarde-a ou entregue-a na hora. Ela tem 8 caracteres, entre letras maiúsculas e algarismos, sem O, 0, I e 1. Na primeira entrada, a conta nova precisa trocar a senha (Troca de senha).

Apagar e resetar são sempre por id. Uma ação com name no lugar do id não apaga nada e volta com "rejected":["users.id"]. A conta admin, id 0, não pode ser apagada nem resetada pela API.

Definir o PIN. O PIN pela API segue sempre a regra fixa de 4 a 8 algarismos, qualquer que seja a política de PIN do aparelho. Esse é um defeito conhecido, e o comportamento é este:

  • um PIN com letras, ou com mais de 8 caracteres, é recusado mesmo que a política o aceite no painel;
  • um PIN mais curto que o mínimo da política é aceito pela API, mas o painel o recusa na hora de entrar.

Para um PIN que funcione nos dois lados, use só algarismos, com um comprimento entre o maior de 4 e pin_min e o menor de 8 e pin_max, lidos em GET /api/config. Se a política exige mais de 8 caracteres, defina o PIN no próprio painel (capítulo 8).

users se aplica sem reiniciar desde a v2.10.0. Criar, apagar, resetar e definir PIN valem na hora: a sessão de uma conta apagada ou resetada termina na requisição seguinte (401), e as outras continuam. A exceção é o primeiro PIN do admin, que também apaga a marca de troca obrigatória, na área de extensão: esse pedido reinicia pelo grupo web. Até a v2.9.0, toda gravação de contas reiniciava o aparelho e encerrava todas as sessões.

Recusas. Uma ação recusada não impede as outras. A resposta traz o motivo em rejected, com status 200:

Motivo Causa
users.name Nome vazio, com mais de 15 bytes, com aspas, barra invertida ou caractere de controle, ou igual a admin
users.dup Já existe uma conta com esse nome, sem diferença entre maiúsculas e minúsculas
users.perms perms fora de 0 a 8191, ou com uma permissão que a conta que pede não tem. A conta não é criada
users.full As 32 posições estão ocupadas
users.pin PIN fora da regra de 4 a 8 algarismos, ou já usado por outra conta. Numa criação, a conta entra sem PIN. alpha air Todo PIN é recusado
users.id id ausente ou de conta inexistente; o admin numa exclusão ou reset; ou o PIN do admin pedido por quem não é o admin nem administrador completo
users.type Ação desconhecida

Uma resposta de recusa, sem nenhuma outra mudança:

{"status":"ok","reboot":false,"applied":[],"rejected":["users.perms"]}

Mudar as permissões de uma conta existente não tem ação própria. Apague e crie de novo, no mesmo pedido, com a exclusão antes da criação (capítulo 8).

Alarmes pela API

A seção alarms exige Sistema PERM_SYS_CONFIG, e tudo nela se aplica sem reiniciar. Cada item de sensors altera um slot:

{"alarms":{"sensors":[
  {"idx":0,"active":true,"temp":[2.0,8.0],"hum":[20,80]},
  {"idx":3,"maint":7200}
]}}
Campo Efeito
idx Slot, de 0 a 15. Obrigatório. Um slot inativo é ignorado em silêncio
active Liga ou desliga os alarmes de limite do slot (bloquear)
temp, hum, press, lux Limites [mínimo, máximo] do canal. null num dos dois mantém aquele limite como está; um valor que não é número recusa a gravação inteira com 400 (até a v2.9.0, os dois viravam 0)
tmin, tmax, hmin, hmax Nomes antigos dos limites de temperatura e umidade. Se os dois estilos vierem, vale o de canal
maint Janela de manutenção em segundos a partir de agora. 0 encerra

Campo ausente mantém o valor atual. Uma banda invertida, com mínimo igual ou acima do máximo, é corrigida sozinha: o máximo passa a ser o mínimo mais 0,1. Um limite fora da faixa possível do canal recusa a gravação inteira com 400 (capítulo 7).

Janela de manutenção. O valor é uma duração, e não uma hora, para não depender de o relógio do servidor e o do aparelho concordarem.

# slot 3 em manutenção por 2 h
curl -s -b jar -X POST "$H/api/commit_all" \
  --data-urlencode '_payload={"alarms":{"sensors":[{"idx":3,"maint":7200}]}}'
# encerrar agora
curl -s -b jar -X POST "$H/api/commit_all" \
  --data-urlencode '_payload={"alarms":{"sensors":[{"idx":3,"maint":0}]}}'
{"status":"ok","reboot":false,"applied":["maint"]}

O teto é 30 dias, 2.592.000 s. Um pedido acima disso é cortado para 30 dias e o campo aparece em rejected. Um valor negativo é recusado e nada muda. A janela fica gravada, sobrevive a reinícios e se encerra sozinha no prazo. O que ela faz com os alarmes e com a linha de alarmes está no capítulo 7 e no capítulo 22.

Sons. O objeto sounds, dentro da seção alarms, altera só as chaves que vierem: touch, confirm, error, alarm, web, attention e mute (ligado ou desligado), volume e alarmVolume (0 a 100) e melTouch, melConfirm, melError, melAlarm e melAttention (melodia 0 a 5) (capítulo 7).

Ler o estado. GET /api/alarms lista só os slots ativos, em ordem de slot:

{"sensors":[
  {"idx":0,"name":"Geladeira","type":"DS18B20","gpio":2,"has_hum":false,
   "tmin":2.0,"tmax":8.0,"hmin":20.0,"hmax":80.0,"active":true,
   "lim":{"temp":[2.0,8.0]},"maint":0},
  {"idx":3,"name":"Câmara","type":"DHT22","gpio":5,"has_hum":true,
   "tmin":-20.0,"tmax":-10.0,"hmin":20.0,"hmax":80.0,"active":true,
   "lim":{"temp":[-20.0,-10.0],"hum":[20.0,80.0]},"maint":7140}],
 "sounds":{"touch":true,"confirm":true,"error":true,"alarm":true,"web":false,
  "attention":true,"mute":false,"volume":70,"alarmVolume":100,"melTouch":0,
  "melConfirm":1,"melError":2,"melAlarm":3,"melAttention":4}}

lim traz os limites de todo canal que o sensor mede. maint é quanto falta da janela, em segundos; 0 fora dela. active é o alarme de limite ligado, não “o sensor existe”: um sensor que funciona com o alarme bloqueado vem com active:false.

Silenciar um alarme que está tocando não tem rota: é uma ação local, no painel (capítulo 7). Pela API, use active:false para bloquear ou maint para uma pausa com prazo.

Slots pela API

A seção slots altera a configuração dos sensores. Mudar a, t, p, hwId ou name reinicia o aparelho (grupo slots); lim e al sozinhos se aplicam sem reiniciar (grupo alarms). Mande só os slots e só os campos alterados: campo ausente mantém o valor.

{"slots":{"s":[{"i":0,"name":"Câmara fria 1"}]}}
Campo Significado
i Slot, de 0 a 15. Obrigatório
a Ativo
t Tipo: 1 DS18B20, 2 DHT22, 3 BME280, 5 BMP280
p Até 4 GPIOs, como [2,255,255,255] (255 = sem pino)
hwId Identificador de hardware, que vira a chave da telemetria
name Nome mostrado no painel e na web
lim Limites por canal, como {"temp":[2,8],"hum":[20,80]}
al Alarme de limite ligado

tmin, tmax, hmin e hmax não valem nesta seção e são ignorados em silêncio. Use lim ou a seção alarms. Mudar hwId muda as chaves da telemetria daquele sensor; para mudar só o que as pessoas veem, mude name (capítulo 6).

O mapa completo dos slots, com os tipos que a imagem aceita e os papéis de cada pino, está em GET /api/sensors (capítulo 6).

Ações pontuais

POST /api/action reúne operações que não são configuração. O parâmetro op escolhe a operação:

op Efeito Resposta
reboot Reinicia o aparelho 200 {"ok":true} e reinicia; 409 com troca de senha pendente; 503 com o painel em uso
tel_sync Dispara um envio de telemetria agora (capítulo 21) 200 {"ok":true}
tel_reset Volta o cursor da telemetria para reenviar até 30 dias (capítulo 21) 200 {"ok":true}
sensor_scan Começa a busca de sondas nos GPIOs (capítulo 6) 202 {"started":true}; 200 {"busy":true} se já está buscando
scan_results Resultado da busca {"scanning":true} enquanto busca; depois {"scanning":false,"found":[{"pin":2,"type":1,"rom":"28FF641E8016034A"}]}
sensor_wipe Com slot=N: grava a hora atual como início do histórico do slot, sem apagar o slot nem os arquivos 200 {"ok":true}
sensor_accept Com slot=N: adota a sonda DS18B20 encontrada no GPIO de mesmo número 200 {"ok":true,"epoch_moved":false}; 404 nosensor; 422 badrom

Um op desconhecido responde 400 {"error":"op"}, e um slot ausente ou fora de 0 a 15, 400 {"error":"slot"}.

curl -s -b jar -X POST "$H/api/action?op=reboot"

Não existe uma rota /api/reboot. Para reiniciar, use op=reboot, ou _reboot=1 junto de uma gravação. O commit_all sempre exige uma seção: para reiniciar por ele sem mudar nada, mande uma seção vazia que a conta possa gravar, como _payload={"sys":{}} com _reboot=1. A resposta é {"status":"ok","reboot":true,"reboot_for":["requested"]}.

Outras três rotas agem na hora, sem reiniciar:

Rota Corpo Resposta
POST /api/set_time JSON {"epoch":1790164800}, com Content-Type: application/json {"ok":true,"now":1790164800}. Recusa valores até 1600000000 (13/09/2020) com 400 {"error":"epoch too low"}. Com o NTP ligado, o próximo acerto sobrescreve. O primeiro acerto depois do boot corrige a hora dos blocos do histórico que o boot começou, e o log registra o evento 13 com o contexto 1 (capítulo 10)
POST /api/save_sys Formulário theme=<índice> {"status":"ok"}; 400 com índice fora da lista
POST /api/reset_touch_cal Nenhum release {"status":"ok","wizard":true}. O painel abre o assistente de calibração do toque

POST /api/history_rebind adapta o dia corrente do histórico ao esquema atual dos sensores, mantendo os registros, e reinicia. Com force=1, recria o esquema e descarta o dia. Use-a só quando o log de eventos indicar esquema de histórico diferente (capítulo 15).

Temas

release GET /api/themes lista os temas do painel na ordem do índice:

[{"id":0,"name":"Simut Default"},{"id":1,"name":"Janeiro Branco"},{"id":2,"name":"Fevereiro Roxo"}]

O índice é o que theme do /api/status mostra e o que POST /api/save_sys recebe (capítulo 13).

Histórico

O histórico fica em arquivos por dia, /history/AAAAMMDD.h5, no formato binário do aparelho (capítulo 15). Cada arquivo só tem os blocos já selados; as medições mais recentes ficam num bloco aberto, na memória, até o selo. Quem reconcilia histórico precisa ler os dois.

Listar os dias. GET /api/history_days devolve os nomes dos arquivos sem a extensão, sem ordem garantida:

["20260921","20260922","20260923"]

Baixar um dia. Use /download com o caminho do arquivo. Exige Leitura PERM_FILE_READ e Histórico PERM_HISTORY:

curl -s -b jar -o 20260922.h5 "$H/download?file=/history/20260922.h5"

Ler o bloco aberto. GET /api/history/open devolve o bloco ainda não selado, no mesmo formato, como open.h5. Sem nada aberto, a resposta é 204, sem corpo:

curl -s -b jar -o open.h5 -w '%{http_code}\n' "$H/api/history/open"

Séries para gráfico. GET /api/history_multi devolve JSON pronto para desenhar:

Parâmetro Significado
sensors Slots separados por vírgula, como 0,3. Sem ele, o primeiro slot ativo
range Período para trás a partir de end: 0 1 h, 1 6 h, 2 24 h (padrão), 3 7 dias, 4 30 dias, 5 1 ano, 6 tudo
end Fim do período, em epoch. Padrão: agora
from, to Janela explícita, em epoch. Quando os dois vêm, valem no lugar de range e end
probe 1 responde só a estimativa de tamanho, sem dados
{"cutoff":1790078400,"end":1790164800,"now":1790164800,"rangeUsed":2,
 "sensors":[{"id":0,"hwId":"FRIDGE","name":"Geladeira","type":"DS18B20",
  "hasH":false,"hasP":false}],
 "data":[{"t":1790078460,"v":{"tFRIDGE":4.31}},{"t":1790078520,"v":{"tFRIDGE":4.28}}],
 "minT":3.95,"maxT":4.62,"tsMinT":1790101200,"tsMaxT":1790089200}

Cada ponto traz t, o horário, e v, com uma chave por grandeza: a letra do canal (t temperatura, u umidade, p pressão, l luz) seguida do hwId. O aparelho reduz os pontos para cerca de 600 por resposta. Um pedido grande demais para uma resposta só não é atendido: volta a estimativa, com "sliceRequired":1, e o cliente deve pedir o período em fatias com from e to. Um pedido de histórico por vez: um segundo em paralelo recebe 503 {"error":"Already processing"}.

Exportar. GET /api/export/history.bin?from=<epoch>&to=<epoch> devolve um pacote .simx com os registros do período, até 31 dias. A página Histórico e Logs não usa esta rota: ela baixa os arquivos .h5 do dia por /download e monta o CSV no navegador. Fora da regra, a resposta é 400 com Missing from/to params, Invalid range ou Range exceeds 31 days.

Log de eventos

GET /api/logs devolve o log de eventos inteiro, do mais antigo ao mais novo, como uma sequência de registros binários de 12 bytes. Exige Logs PERM_LOGS e respeita o intervalo de 200 ms.

curl -s -b jar -o eventos.bin "$H/api/logs"

Cada registro, em little-endian:

Bytes Tipo Campo
0 a 3 inteiro de 32 bits sem sinal Horário, em epoch
4 e 5 inteiro de 16 bits sem sinal Tempo desde o boot, em segundos: os 16 bits baixos
6 e 7 inteiro de 16 bits sem sinal Código do evento (apêndice B)
8 e 9 inteiro de 16 bits com sinal Contexto do evento
10 byte Nível nos bits 7 a 5 (0 depuração, 1 informação, 2 aviso, 3 erro, 4 fatal), núcleo no bit 4 e subsistema nos bits 3 a 0
11 byte Tempo desde o boot: os 8 bits altos

Os subsistemas, de 0 a 13: APP, NET, TEL, STO, WEB, CFG, CLI, SENSOR, HIST, SYS, DSP, SEC, OTA, I18N; 15 é desconhecido. O registro binário não traz o texto do evento: a página o busca pelo código em GET /api/logcodes, descrito abaixo.

import struct
TAGS = ["APP","NET","TEL","STO","WEB","CFG","CLI","SENSOR","HIST","SYS","DSP","SEC","OTA","I18N"]
with open("eventos.bin", "rb") as f:
    dados = f.read()
for i in range(0, len(dados) - 11, 12):
    ts, up_lo, code, ctx, flags, up_hi = struct.unpack_from("<IHHhBB", dados, i)
    nivel, tag = flags >> 5, flags & 0x0F
    print(ts, code, ctx, nivel, TAGS[tag] if tag < len(TAGS) else "?", (up_hi << 16) | up_lo)

GET /api/logcodes devolve os nomes dos eventos em texto puro, uma linha <código> <nome> por evento. Exige Logs PERM_LOGS. Com um pacote de idioma instalado, vêm primeiro os nomes do pacote e depois os nomes em inglês de todos os códigos: fique com o primeiro nome de cada código, e um evento que o pacote ainda não conhece sai em inglês. Com ?l=en, ou sem pacote, só inglês.

curl -s -b jar "$H/api/logcodes" | head -3

GET /api/export/logs.bin?from=<epoch>&to=<epoch>&level=<all|inf|err> exporta um período de até 31 dias num pacote .simx, filtrado por nível. POST /api/clear_logs apaga o log e exige Logs e Sistema ao mesmo tempo; a própria limpeza fica registrada.

Arquivos

Listar. GET /api/ls?dir=/lang:

{"path":"/lang","entries":[{"n":"README.txt","t":"f","s":212,"p":1},
 {"n":"language_pt-BR.lng","t":"f","s":61234}]}
Campo Significado
n Nome
t f arquivo, d pasta
s Tamanho em bytes; 0 nas pastas
p 1 num arquivo protegido contra exclusão

Uma listagem que passa do tempo termina com "truncated":true. dir com .. ou % recebe 400, e /config recebe 403.

Baixar. GET /download?file=/pasta/arquivo. Um arquivo em /history exige também Histórico, e um arquivo .blog exige também Logs. Arquivo inexistente: 404.

Enviar. POST /api/upload, em multipart/form-data. A pasta de destino vai no campo uploadDir, ou no endereço como ?uploadDir=/lang:

curl -s -b jar -F uploadDir=/lang -F file=@language_pt-BR.lng "$H/api/upload"
{"status":"ok"}

O nome do arquivo tem até 64 caracteres, sem .., sem \ " : < > | ? * % e sem caracteres de controle. Um destino dentro de /config é recusado. Um envio recusado, por nome inválido, destino inválido ou falta de espaço, responde 400 {"error":"Invalid upload"}. Um pacote de idioma novo só vale depois de um reinício (capítulo 13).

Criar pasta. POST /api/mkdir com dir=/dados. No máximo dois níveis, como /a/b. O aparelho põe na pasta nova um README.txt, que a mantém visível na listagem.

Apagar. POST /api/delete com file=/pasta/arquivo. O parâmetro é file, não path.

Resposta Quando
200 {"status":"ok"} Apagado
403 {"error":"Forbidden"} Caminho com .. ou %, ou dentro de /config
403 {"error":"Protected file — the firmware rewrites it on boot"} Arquivo protegido
404 {"error":"Not found"} O arquivo não existe

Caminhos protegidos.

Caminho Regra
/config e tudo dentro Não se lista, não se baixa, não se envia e não se apaga pela rede. Ali ficam a configuração, as contas, o par de certificados e a origem CORS
/README.txt, /themes/README.txt, /web/README.txt, /lang/README.txt Não se apagam. O aparelho os reescreve no boot

Backup e restauração

GET /api/backup baixa o sistema de arquivos inteiro num arquivo .bkp, inclusive /config, com as contas e os segredos. Só o administrador completo pode (capítulo 17).

curl -s -b jar -OJ "$H/api/backup"

O arquivo se chama backup_<id do chip>_<epoch>.bkp. A resposta traz cabeçalhos para conferir a integridade antes de usar o arquivo:

Cabeçalho Significado
X-Backup-Files Número de arquivos
X-Backup-Schema Versão do formato
X-Backup-PSize Tamanho da carga, em bytes
X-Backup-PCrc CRC-32 da carga, em decimal

No arquivo, os 4 primeiros bytes são BKP1, o tamanho da carga fica no byte 24 e o CRC no byte 28, os dois em inteiros de 32 bits little-endian. A interface web compara esses dois valores com os cabeçalhos e descarta um backup que não bate.

A restauração tem dois passos, os dois em multipart/form-data:

# 1. conferir, sem gravar (permissão Leitura)
curl -s -b jar -F bkp=@backup.bkp "$H/api/restore?op=validate"
# 2. restaurar (administrador completo); o aparelho reinicia
curl -s -b jar -F bkp=@backup.bkp "$H/api/restore?op=apply"

O segundo passo só aceita o arquivo que passou no primeiro. Um apply sem validate antes, ou de outro arquivo, volta com 409 e st 11, sem gravar nada (desde a v2.10.0; antes, aplicava assim mesmo).

{"st":0,"chip":"e6614c311b7a2f2d","fwv":132865,"psz":913408,"fc":57,"fsm":0}
Campo Significado
st Resultado: 0 bom; os outros códigos na tabela abaixo
chip Identificador do chip que gerou o backup
fwv Versão do firmware que gerou o backup: maior × 65536 + menor × 256 + correção; 132865 é a 2.7.1
psz, fc Tamanho da carga e número de arquivos
fsm 1 se o sistema de arquivos foi alterado
st Significado
1 Não é um backup
2 Formato não suportado
3 Cabeçalho corrompido
4 Arquivo truncado
5 Carga corrompida
6 O backup é de outro aparelho
7 Caminho inválido dentro do backup
8 Caminho longo demais
9 Erro de leitura ou gravação
10 Erro interno
11 O arquivo não é o validado por último: valide antes

Um resultado ruim volta com 422; um erro de gravação, com 500; um apply sem a validação, com 409. Um apply que falha no meio mantém os arquivos que terminou e apaga só o que ficou pela metade; fsm volta 1 quando algum arquivo mudou, e repetir o apply completa o resto. Até a v2.9.0, a falha apagava tudo o que tinha gravado, inclusive a configuração. Um backup só restaura no mesmo aparelho que o gerou. A restauração bem-sucedida reinicia o aparelho logo depois de responder, e a conexão pode cair antes de a resposta chegar: confirme depois do reinício.

Atualização de firmware pela API

A atualização exige o administrador completo e segue quatro passos. A interface web faz exatamente estes passos (capítulo 17).

Figura 199. A atualização pela API. O único comprovante de sucesso é a versão nova informada pelo próprio aparelho.
  1. Baixe o backup. A atualização reformata o sistema de arquivos. Só a configuração principal, o arquivo /config/system.bin, sobrevive: Wi-Fi, contas, slots de sensor, limites, telemetria e os demais campos de configuração. O histórico, os pacotes de idioma, os temas personalizados, a calibração dos sensores (/calib.csv), a pasta /web, o log de eventos, o par de certificados HTTPS e a origem CORS se perdem até você restaurar o backup.

    curl -s -b jar -o antes.bkp "$H/api/backup"
  2. Envie a imagem. O campo do formulário leva o .bin da mesma imagem do aparelho (release, alpha ou air, o env do /api/status), assinado: os das releases e os do configurador são (capítulo 17). commit=1 deixa a imagem pronta para aplicar.

    curl -s -b jar -F file=@simut_v2.7.1_release.bin \
      "$H/api/restore?op=stage&commit=1"
    {"st":5,"bytes":982844,"crc32":"1A2B3C4D","v":0,"dsize":982844,"dcrc":"1A2B3C4D","committed":1,"env":"release"}

    Siga só com "st":5, "v":0 e "committed":1. Uma imagem recusada volta com 422:

    v Motivo
    4 Imagem pequena demais
    5 Imagem grande demais
    6 Início da imagem inválido
    7 A imagem é de outra variante. env diz qual
    8 A imagem não é assinada
    9 A assinatura não confere, ou o trailer da assinatura está malformado
    10 A chave que assinou foi aposentada
    11 A imagem está abaixo do nível de segurança instalado
    12 A imagem foi assinada com a chave de bancada

    Se o envio não terminou, a resposta traz só st, bytes e crc32, com st diferente de 5: 1 falha ao começar, 2 envio incompleto, 3 imagem maior que a área de preparo, 4 falha de gravação, 6 envio abortado.

    O envio leva cerca de 30 s para uma imagem de 1 MB. Ele grava a imagem na mesma área da flash que guarda o sistema de arquivos: a partir daqui, os arquivos já se perderam. Para desistir de uma imagem preparada, reinicie o aparelho e restaure o backup.

  3. Aplique.

    curl -s -b jar -X POST "$H/api/ota/apply"
    {"accepted":true,"mode":"apply"}

    A resposta 202 chega antes de o aparelho desligar o Wi-Fi. Sem imagem preparada, a resposta é 409 {"error":"no committed update pending"}; com o painel em uso, 503. Antes de aplicar, o aparelho confere a assinatura de novo, sobre a imagem gravada naquele momento: se outro envio começou depois do passo 2, a resposta é 409 com "v", e a imagem é descartada.

  4. Confirme. Espere o aparelho voltar, repetindo GET /api/login_init a cada 3 s. Entre e leia ver em GET /api/status, ou version em GET /api/perms. Um status HTTP ou um tempo decorrido não provam nada: só a versão nova informada pelo aparelho prova a atualização. Depois, restaure o backup para recuperar o histórico e o resto (Backup e restauração).

Até a v2.10.0, o envio de uma imagem grande caía aos 12–15 s quando outra página do aparelho estava aberta no navegador: o próprio aparelho cortava a conexão mais antiga para admitir as consultas da página. Não era a rede nem a porta 80. Nessas versões, feche as outras abas do aparelho antes de enviar (capítulo 18).

Certificado HTTPS

release

POST /api/tls recebe o certificado e a chave privada juntos, em PEM, e exige o administrador completo. A receita completa, as respostas e os erros estão no capítulo 9. O par vale depois do próximo reinício.

Busca de redes

GET /api/wifi/scan exige Rede PERM_NET_CONFIG. A busca leva alguns segundos, então a rota trabalha em dois tempos:

  1. Peça GET /api/wifi/scan?again=1 para começar uma busca nova. A resposta é {"scanning":true}.
  2. Repita GET /api/wifi/scan, sem again, a cada segundo, até scanning ser false.
{"scanning":false,"nets":[{"ssid":"MinhaRede","rssi":-48,"enc":4,"ch":6},
 {"ssid":"Visitantes","rssi":-71,"enc":0,"ch":11}]}
Campo Significado
ssid Nome da rede
rssi Sinal, em dBm
enc Tipo de proteção informado pelo rádio; 0 = rede aberta
ch Canal

A lista traz até 12 redes. Uma busca que não terminou volta como {"scanning":false,"error":"failed","nets":[]}. Com o rádio ocupado, por exemplo reconectando à própria rede, a rota responde 503 {"scanning":false,"error":"busy"}: espere alguns segundos. A busca funciona também de dentro do ponto de acesso de configuração (capítulo 9).

Métricas

GET /metrics entrega os números do aparelho no formato de texto do Prometheus. Aceita a sessão normal ou HTTP Basic com conta e senha, porque um coletor do Prometheus não faz a entrada em dois passos. No Basic, a senha vai em texto, e o aparelho calcula o resumo. A rota exige Painel PERM_DASHBOARD e divide o bloqueio de senha errada com a entrada. A configuração do Prometheus e a lista de métricas estão no capítulo 24.

curl -s -u "metricas:$SIMUT_METRICS_PASS" "$H/metrics"

As rotas do painel

release

As cinco rotas do painel exigem Sistema PERM_SYS_CONFIG. A interface web as usa no espelho do painel e na captura de tela (capítulo 13).

Rota Resposta
GET /api/screenshot Um BMP de 320 × 240 pixels e 24 bits, 230.454 bytes
GET /api/screenshot_chunk?n=N Um pedaço de 16 linhas, n de 0 a 14: 12 bytes de cabeçalho (índice, tamanho e CRC-32, cada um em 32 bits big-endian) e 15.360 bytes de pixels BGR
GET /api/screen_stream Um quadro inteiro no formato compacto do espelho, em 30 faixas de 8 linhas. O formato é interno e pode mudar entre versões
POST /api/touch Com x de 0 a 319 e y de 0 a 239, em coordenadas do painel, um toque. Com ms, o toque fica pressionado esse tempo antes de soltar — é o toque longo, como o de 3 s que fixa o cartão de cima; de 100 a 15000, e um valor fora disso é levado à borda. Responde {"ok":true,"x":160,"y":120,"ms":100}; x ou y fora da faixa, ou ms que não é número, 400
GET /api/keypad As faces do teclado de PIN que está na tela, a geometria das teclas e a política de PIN
curl -s -b jar -o tela.bmp "$H/api/screenshot"
curl -s -b jar -X POST "$H/api/touch" -d 'x=160&y=120'

Regras que um cliente precisa seguir:

  • O toque não espera a tela mudar. A resposta sai antes de o painel redesenhar, e o aparelho só redesenha entre dois pedidos. Espere entre o toque e a captura seguinte, sem mandar nada: o espelho da interface web espera 600 ms.
  • Um toque ocupa o painel por 5 s. Depois de um toque no vidro ou de um POST /api/touch, a captura em BMP e as gravações de configuração respondem 503 por 5 s. O espelho, GET /api/screen_stream, continua respondendo depois de um toque enviado pela web.
  • Uma captura por vez. Uma segunda captura enquanto a primeira corre responde 409 e cancela a primeira.
  • O PIN continua valendo. Um toque remoto passa pelo mesmo teclado de PIN que um dedo. A rota não dá acesso a nada que a conta não tenha.

GET /api/keypad responde, por exemplo:

{"faces":["123","456","789","0"],"up":true,"kb":"num",
 "grid":[4,3,2,2,20,60,130,60,150,70],"policy":[4,8,3,0]}

faces descreve as teclas como estão desenhadas, sem dizer qual caractere é o do PIN. up diz se o teclado está na tela; kb é cards (teclado embaralhado), num ou groups. grid traz a geometria das teclas em pixels, e policy traz o mínimo, o máximo, os glifos por tecla e o alfabeto da política de PIN.

Um cliente em Python

Este cliente usa a biblioteca requests. Ele entra, lê o estado, sai e trata a sessão vencida do jeito descrito em 401 e 403. A conta e a senha vêm do ambiente.

#!/usr/bin/env python3
"""Cliente mínimo da API REST do SIMUT: entra, lê o estado e sai.

Uso:
  export SIMUT_URL=http://192.0.2.10
  export SIMUT_WEB_USER=servidor
  export SIMUT_WEB_PASS='...'
  python3 simut_status.py
"""
import hashlib
import json
import os

import requests  # pip install requests


class SimutError(Exception):
    pass


class Simut:
    def __init__(self, base, user, password, verify=True, timeout=30):
        self.base = base.rstrip("/")
        self.user = user
        # A senha vai como SHA-256 hexadecimal dos bytes Latin-1,
        # igual ao que a página de entrada calcula.
        try:
            raw = password.encode("latin-1")
        except UnicodeEncodeError:
            raise SimutError("a senha tem caracteres fora do Latin-1")
        self.pw_hash = hashlib.sha256(raw).hexdigest()
        self.timeout = timeout
        self.http = requests.Session()   # guarda o cookie SIMUTSESS
        self.http.verify = verify        # em HTTPS autoassinado: o caminho do .pem

    def login(self):
        r = self.http.get(self.base + "/api/login_init", timeout=self.timeout)
        if r.status_code == 429:
            raise SimutError("bloqueios cheios; tente em %s s" % r.json().get("retryAfter"))
        r.raise_for_status()
        init = r.json()
        if init.get("locked"):
            raise SimutError("endereço bloqueado por %d s" % init["lockSec"])
        r = self.http.post(self.base + "/api/login", timeout=self.timeout,
                           data={"user": self.user, "pass": self.pw_hash,
                                 "nonce": init["nonce"]})
        body = r.json()
        if not body.get("ok"):
            raise SimutError("entrada recusada: HTTP %d %s" % (r.status_code, body))
        if body.get("redirect") == "/force_chpass":
            raise SimutError("a conta precisa trocar a senha antes de usar a API")

    def _session_alive(self):
        r = self.http.get(self.base + "/api/perms", timeout=self.timeout)
        return r.status_code != 401

    def request(self, method, path, **kw):
        kw.setdefault("timeout", self.timeout)
        r = self.http.request(method, self.base + path, **kw)
        # 401 = sessão morta. 403 pode ser sessão morta nas rotas que não
        # distinguem; /api/perms desempata.
        if r.status_code == 401 or (r.status_code == 403 and not self._session_alive()):
            self.login()
            r = self.http.request(method, self.base + path, **kw)
        return r

    def status(self, quiet=False):
        r = self.request("GET", "/api/status", params={"quiet": "1"} if quiet else None)
        r.raise_for_status()
        return r.json()

    def commit(self, payload, mode=None):
        """mode: None, "dry", "nosave" ou "reboot"."""
        data = {"_payload": json.dumps(payload, ensure_ascii=False, separators=(",", ":"))}
        if mode:
            data["_" + mode] = "1"
        r = self.request("POST", "/api/commit_all", data=data)
        body = r.json()
        if r.status_code != 200:
            raise SimutError("commit recusado: HTTP %d %s" % (r.status_code, body))
        return body   # leia body.get("rejected") e body.get("reboot")

    def logout(self):
        try:
            self.http.get(self.base + "/logout", allow_redirects=False, timeout=self.timeout)
        except requests.RequestException:
            pass   # o aparelho pode estar reiniciando; a sessão morre com ele


if __name__ == "__main__":
    dev = Simut(os.environ.get("SIMUT_URL", "http://192.0.2.10"),
                os.environ["SIMUT_WEB_USER"], os.environ["SIMUT_WEB_PASS"])
    dev.login()
    try:
        st = dev.status()
        s = st["sys"]
        print("%s  v%s (%s)  uid=%s  cfg=%s" % (s["name"], s["ver"], s["env"], s["uid"], s["cfg"]))
        print("ligado há %.1f h, sinal %d dBm, %d registros pendentes"
              % (s["uptime"] / 3.6e6, s["rssi"], s["pending"]))
        for x in st["sensors"]:
            print("  slot %2d  %-16s %s" % (x["slot"], x["name"], x["val"]))
    finally:
        dev.logout()

Saída:

simut  v2.7.1 (release)  uid=E6614C311B7A2F2D  cfg=3F2A91C4
ligado há 8.1 h, sinal -58 dBm, 0 registros pendentes
  slot  0  Geladeira        4.25
  slot  1  Sala             23.1

O método commit já monta o JSON em UTF-8 direto, como o aparelho espera, e devolve o corpo da resposta para você conferir rejected e reboot.

Referência rápida

Assunto Valor
Rotas 62 na release, 56 na alpha e no Air
Porta 80 de fábrica; 443 em HTTPS com a porta de fábrica
Entrada GET /api/login_init, depois POST /api/login com user, pass = SHA-256 hexadecimal minúsculo, nonce
Código de uso único 32 algarismos hexadecimais, 60 s, uma tentativa, por endereço IP
Token 32 algarismos hexadecimais, no cookie SIMUTSESS ou em Authorization: Bearer
Sessões 3 ao todo, 1 por conta, 15 min de ociosidade, encerradas por reinício
Bloqueio 2 s dobrando até 300 s, por IP, 8 endereços
Ritmo 200 ms em /api/logs e /api/ls; 5 s em POST /api/calib e /api/tls
commit_all Campo _payload até 6.144 bytes; modos _dry, _nosave, _reboot
Corpo de calib e tls Até 8.192 bytes
Janela de manutenção Segundos a partir de agora, até 2.592.000 (30 dias)
Contas Até 32; nome até 15 bytes; perms até 8191; PIN pela API de 4 a 8 algarismos
Histórico exportado Até 31 dias por pedido
Toque no painel Ocupa o painel por 5 s

Voltar ao sumário

Capítulo 27

Gestão de frota

Este capítulo mostra como cuidar de muitos aparelhos a partir de um ponto central: encontrar cada um na rede, configurar todos com o mesmo modelo, acompanhar o estado, atualizar o firmware em ondas e fazer isso com segurança. É para quem escreve ou opera o servidor de gestão. As rotas e os formatos estão no capítulo 26.

O desenho de uma frota

Numa frota, o tráfego corre nos dois sentidos (capítulo 20):

  • Do aparelho para o servidor, sem que ninguém peça: a telemetria (capítulo 21) e a linha de alarmes (capítulo 22). Todo POST HTTP leva a identidade do aparelho nos cabeçalhos X-SIMUT-*.
  • Do servidor para o aparelho, quando o servidor quer: a interface de programação (capítulo 26) para ler o estado, configurar, criar contas e atualizar; e as métricas do Prometheus (capítulo 24).

O gestor de frota é o programa que faz o segundo sentido para todos os aparelhos. Ele pode ser um serviço no servidor, um script agendado ou uma página no navegador.

Figura 200. Os caminhos de uma frota. Os aparelhos empurram medições e alarmes; o gestor e o Prometheus perguntam.
Tarefa Mecanismo Seção
Saber quais aparelhos existem mDNS, cabeçalhos da telemetria, GET /api/status Descobrir os aparelhos
Configurar vários de uma vez POST /api/commit_all, com ensaio Configuração em lote
Cadastrar pessoas no painel Seção users do commit_all Receita completa
Acompanhar a saúde /metrics, GET /api/status Monitoramento
Receber alarmes na hora Linha de alarmes Monitoramento
Atualizar o firmware manifest.json da release e a sequência de atualização Atualização da frota

Descobrir os aparelhos

A chave de cada aparelho

Use o uid como chave primária de cada aparelho no seu cadastro: são os 16 algarismos hexadecimais do número de série da placa, que não mudam com configuração, atualização nem restauração (capítulo 20). O IP vem do DHCP e muda; o nome é editável e pode se repetir.

O mesmo uid aparece em quatro lugares, e o gestor pode cruzá-los:

Onde Campo
Cada POST de telemetria e da linha de alarmes Cabeçalho X-SIMUT-Uid
GET /api/status sys.uid
GET /api/config serial
release Anúncio mDNS Campo uid do registro TXT

Pelo mDNS

release

A imagem release se anuncia na rede local como o serviço _simut._tcp, com a porta do servidor web e quatro campos de texto (capítulo 9):

Campo Conteúdo
uid Número de série da placa
ver Versão do firmware
env release
tls 1 com HTTPS, 0 com HTTP

Com HTTPS na porta de fábrica, o anúncio leva a porta 443. O endereço do aparelho sai do próprio anúncio.

avahi-browse -rpt _simut._tcp

Em Python, com a biblioteca zeroconf:

import time
from zeroconf import ServiceBrowser, Zeroconf  # pip install zeroconf

class Ouvinte:
    def add_service(self, zc, tipo, nome):
        info = zc.get_service_info(tipo, nome)
        if not info:
            return
        txt = {k.decode(): v.decode() for k, v in info.properties.items() if v}
        esquema = "https" if txt.get("tls") == "1" else "http"
        for ip in info.parsed_addresses():
            print(txt.get("uid"), txt.get("ver"), "%s://%s:%d" % (esquema, ip, info.port))
    def update_service(self, zc, tipo, nome):
        pass
    def remove_service(self, zc, tipo, nome):
        pass

zc = Zeroconf()
ServiceBrowser(zc, "_simut._tcp.local.", Ouvinte())
time.sleep(5)
zc.close()

O mDNS só atravessa a rede local: ele não passa por roteadores nem VLANs diferentes, a não ser que a rede tenha um repetidor de mDNS. O nome <nome>.local vem do campo Nome: dê a cada aparelho um nome único, ou dois aparelhos vão disputar o mesmo endereço.

Pela telemetria

As imagens alpha e Air não têm mDNS. Para elas, e para aparelhos em outras redes, o caminho é o coletor: cada POST de telemetria chega com X-SIMUT-Uid, X-SIMUT-Ver, X-SIMUT-Env e X-SIMUT-Cfg, e com o endereço IP de origem na conexão (capítulo 20).

Guarde, para cada uid:

  • o IP de origem do último POST, que é o endereço para falar com o aparelho, se não houver NAT no caminho;
  • X-SIMUT-Ver e X-SIMUT-Env, para saber que imagem instalar;
  • X-SIMUT-Cfg: se mudou desde o último POST, alguém mudou a configuração;
  • a hora do último POST, para saber quem ficou em silêncio.

Um aparelho novo aparece no coletor no primeiro envio de telemetria. No MQTT não há cabeçalhos: o tópico de cada aparelho é que o identifica (capítulo 20).

Confirmar quem responde

Antes de mandar qualquer configuração para um endereço, confirme que ali está o aparelho certo: entre e compare sys.uid de GET /api/status com o cadastro. Um IP reaproveitado pelo DHCP pode apontar para outro aparelho.

curl -s -b jar "$H/api/status?quiet=1" | python3 -c \
  'import sys, json; s = json.load(sys.stdin)["sys"]; print(s["uid"], s["ver"], s["env"], s["cfg"])'

Contas de serviço

Uma conta para o gestor

Não use a conta admin para a automação do dia a dia. Crie em cada aparelho uma conta só para o gestor, com as permissões de que ele precisa e nada mais (capítulo 8).

As permissões são bits independentes, sem hierarquia (capítulo 8). Combinações úteis:

Uso Permissões perms
Só monitorar (/api/status, /metrics) PERM_DASHBOARD 1
Configurar, cadastrar pessoas no painel e abrir manutenção PERM_DASHBOARD PERM_SYS_CONFIG PERM_USER_MGR PERM_ALARM_LIMITS PERM_ALARM_BLOCK PERM_MAINT 7433
O mesmo, e também baixar o histórico As de cima, mais PERM_HISTORY e PERM_FILE_READ 7467
Mudar a rede Acrescente PERM_NET_CONFIG +16

A conta de 7433 não mexe na rede, não lê arquivos, não calibra e não vê o log de eventos. Acrescente só o que o gestor for de fato usar.

Ninguém concede o que não tem

Uma conta só cria outra com permissões que ela mesma tem (capítulo 8). Um pedido com qualquer bit a mais volta com status 200 e "rejected":["users.perms"], e a conta não é criada.

É por isso que a conta de 7433 leva as três permissões de painel, Limites, Bloqueio e Manutenção (0x0400, 0x0800 e 0x1000), mesmo sem nunca usar o painel. Elas estão ali para que o gestor possa repassá-las às pessoas que vai cadastrar. Uma conta de serviço sem elas cria contas, mas não cria a conta de painel que o gestor existe para cadastrar.

Consequências para o gestor:

  • a tela que monta as permissões de uma conta nova deve oferecer no máximo os bits da conta de serviço, lidos em GET /api/perms;
  • o PIN do admin só pode ser definido pelo próprio admin ou por um administrador completo; a conta de serviço recebe "rejected":["users.id"];
  • o nível de administrador completo nunca se concede pela API.

O que só o administrador completo faz

Backup, restauração, atualização de firmware e instalação do certificado HTTPS exigem o administrador completo (capítulo 8). Nas imagens release e alpha, só a conta admin tem esse nível. air No Air, o console completo pode dar o nível a outra conta com user perm <nome> admin (capítulo 14).

Na prática, a atualização da frota usa a conta admin de cada aparelho. Guarde essas senhas num cofre de segredos, uma por aparelho, e use-as só nas janelas de atualização.

Sessões numa frota

Cada aparelho tem três vagas de sessão, uma por conta (capítulo 26). Numa frota, isso pede disciplina:

  • Uma sessão por aparelho, reaproveitada. Entre uma vez, guarde o token e entre de novo só quando a sessão morrer.
  • Uma conta por processo. Dois processos com a mesma conta derrubam a sessão um do outro a cada entrada. Se o gestor tem vários trabalhadores, dê uma conta a cada um, ou faça um único trabalhador falar com cada aparelho.
  • Saia ao terminar. GET /logout devolve a vaga. Sem isso, ela fica ocupada por 15 min.
  • Deixe vagas para as pessoas. O gestor não deve ocupar mais de uma vaga por aparelho. As outras duas são dos operadores.
  • Monitorar pelo /metrics não ocupa vaga. O HTTP Basic confere conta e senha a cada coleta, sem abrir sessão.

A primeira entrada da conta de serviço

Uma conta criada pela página Usuários ou pela API nasce com uma senha de uso único e precisa trocá-la (capítulo 26). A troca pode ser feita pelo próprio gestor:

H=http://192.0.2.10
TEMP_HASH=$(printf '%s' "$SENHA_TEMPORARIA" | sha256sum | cut -d' ' -f1)
NOVA_HASH=$(printf '%s' "$SIMUT_SERVER_PASS" | sha256sum | cut -d' ' -f1)
NONCE=$(curl -s "$H/api/login_init" | sed 's/.*"nonce":"\([^"]*\)".*/\1/')
curl -s -c jar -X POST "$H/api/login" --data-urlencode user=servidor \
  --data-urlencode "pass=$TEMP_HASH" --data-urlencode "nonce=$NONCE"
# {"ok":true,"redirect":"/force_chpass"}
curl -s -b jar -X POST "$H/api/force_chpass" \
  --data-urlencode "p1=$NOVA_HASH" --data-urlencode "p2=$NOVA_HASH"
# {"status":"ok"}

Este exemplo vale para HTTP. Em HTTPS, p1 e p2 levam a senha nova em texto, com pelo menos 8 caracteres, letra e algarismo.

Gestão central

Um serviço no servidor

O caminho mais simples é um programa no servidor que fala com cada aparelho: um script em Python, um serviço agendado, uma rotina do seu sistema. Ele não depende de CORS, guarda o cookie ou o token como quiser e não tem as restrições do navegador. O cliente em Python do capítulo 26 é um ponto de partida.

Regras para esse programa:

  • fale com um aparelho de cada vez, ou no máximo com um pedido de cada vez por aparelho (capítulo 26);
  • ponha um limite de tempo em cada pedido e siga para o próximo aparelho quando um não responder;
  • trate 401 entrando de novo uma vez, e 403 perguntando GET /api/perms (capítulo 26);
  • registre cada gravação com o uid, o que foi pedido e a resposta inteira, inclusive rejected.

Uma página no navegador

Uma página hospedada no seu servidor, como http://gestor.exemplo.com.br:8080, também pode falar com os aparelhos direto do navegador do operador. Para isso:

  1. Configure em cada aparelho a origem exata da página, pelo console serial ou pela chave cors do commit_all (capítulo 9).
  2. Reinicie cada aparelho: a origem só vale depois do reinício.
  3. Na página, entre com POST /api/login. Como o pedido sai da origem autorizada, a resposta traz o token no corpo, em token.
  4. Mande o token em Authorization: Bearer em cada pedido. A página não usa cookie.
  5. Saia com GET /logout e o mesmo cabeçalho quando o operador fechar a página.
async function entrar(base, usuario, senhaHash) {
  const ini = await (await fetch(base + '/api/login_init')).json();
  if (ini.locked) throw new Error('bloqueado por ' + ini.lockSec + ' s');
  const corpo = new URLSearchParams({ user: usuario, pass: senhaHash, nonce: ini.nonce });
  const r = await fetch(base + '/api/login', { method: 'POST', body: corpo });
  const j = await r.json();
  if (!j.ok) throw new Error('entrada recusada: ' + r.status);
  if (!j.token) throw new Error('sem token: a origem desta página não está no CORS do aparelho');
  return j.token;
}

A página calcula senhaHash como o SHA-256 hexadecimal da senha, do mesmo jeito que a página de entrada do aparelho (capítulo 26).

O que o navegador impõe:

  • A origem precisa bater exatamente: esquema, nome e porta. https://gestor.exemplo.com.br e http://gestor.exemplo.com.br são origens diferentes.
  • Página em HTTPS não fala com aparelho em HTTP. O navegador bloqueia o conteúdo misto. Uma página servida em HTTPS exige aparelhos em HTTPS, com certificados em que o navegador confie. O jeito prático é uma autoridade certificadora da própria empresa, instalada nos navegadores dos operadores, assinando o certificado de cada aparelho (capítulo 9).
  • Cabeçalhos da resposta ficam invisíveis. O aparelho não libera cabeçalhos extras para outras origens: a página lê status e corpo, mas não Retry-After nem os X-Backup-*.
  • Uma atualização de firmware apaga a origem CORS, junto com o certificado HTTPS. Depois de atualizar, a página perde o acesso ao aparelho até o backup ser restaurado. Faça atualizações e restaurações por um serviço no servidor, ou pela página Arquivos do próprio aparelho (Atualização da frota).

Configuração em lote

O modelo e os campos de cada aparelho

Separe a configuração em duas partes:

Parte Exemplos Como tratar
Modelo, igual em toda a frota Servidor e caminho da telemetria, formato, lotes, modelos de payload, linha de alarmes, fuso, NTP, syslog, política de PIN Um único JSON, validado uma vez
Próprio de cada aparelho name, t_key (uma chave por aparelho), m_topic e m_cid no MQTT, hwId e nomes dos slots, limites de cada sensor Tirado do cadastro, pelo uid

Monte o _payload de cada aparelho juntando o modelo com os campos dele. Mande só as chaves que você quer definir: campo ausente mantém o valor (capítulo 26).

O ciclo por aparelho

  1. Entre e confirme o uid (Confirmar quem responde).
  2. release alpha Mande o _payload com _dry=1. Leia rejected, reboot e reboot_for.
  3. Se o ensaio recusou algum campo, pare e corrija o modelo ou o cadastro.
  4. Mande o mesmo _payload sem _dry, ou com _reboot=1 se você já espera reiniciar.
  5. Se a resposta traz "reboot":true, espere o aparelho voltar e entre de novo.
  6. Leia o estado de volta (GET /api/config, GET /api/alarms ou GET /api/network) e confira os campos.
  7. Guarde o novo cfg de GET /api/status. Ele passa a ser a referência daquele aparelho.

Um exemplo em Python

O script usa a classe Simut do capítulo 26, salva como simut_status.py. O inventário é um arquivo JSON com o endereço, o uid esperado e os campos próprios de cada aparelho. A senha da conta de serviço vem do ambiente.

#!/usr/bin/env python3
"""Aplica um modelo de configuração a uma lista de aparelhos, um de cada vez."""
import json
import os
import sys
import time

import requests
from simut_status import Simut, SimutError

MODELO = {
    "sys": {
        "t_srv": "coletor.exemplo.com.br", "t_port": 443, "t_path": "/telemetria",
        "t_sec": 1, "t_mode": 0, "t_int": 10, "t_bat": 250, "tz": -3,
    },
    "alarms": {"sensors": []},
}

def esperar_volta(dev, limite=120):
    fim = time.time() + limite
    while time.time() < fim:
        time.sleep(3)
        try:
            if dev.http.get(dev.base + "/api/login_init", timeout=5).ok:
                return True
        except requests.RequestException:
            pass
    return False

def aplicar(item, senha):
    dev = Simut(item["url"], "servidor", senha)
    dev.login()
    try:
        s = dev.status(quiet=True)["sys"]
        if s["uid"] != item["uid"]:
            raise SimutError("uid %s no lugar de %s" % (s["uid"], item["uid"]))
        payload = json.loads(json.dumps(MODELO))
        payload["sys"].update(item.get("sys", {}))           # name, t_key...
        payload["alarms"]["sensors"] = item.get("limites", [])
        if s["env"] != "air":
            ensaio = dev.commit(payload, mode="dry")
            if ensaio.get("rejected"):
                raise SimutError("o ensaio recusou %s" % ensaio["rejected"])
        r = dev.commit(payload)
        if r.get("reboot"):
            if not esperar_volta(dev):
                raise SimutError("não voltou depois do reinício")
            dev.login()
        if r.get("rejected"):
            raise SimutError("gravado, mas recusou %s" % r["rejected"])
        return dev.status(quiet=True)["sys"]["cfg"], r
    finally:
        dev.logout()

if __name__ == "__main__":
    senha = os.environ["SIMUT_SERVER_PASS"]
    for item in json.load(open(sys.argv[1], encoding="utf-8")):
        try:
            cfg, r = aplicar(item, senha)
            print("%s ok cfg=%s reboot=%s" % (item["uid"], cfg, r.get("reboot")))
        except (SimutError, requests.RequestException) as e:
            print("%s FALHOU: %s" % (item["uid"], e))

Um item do inventário:

{"uid": "E6614C311B7A2F2D", "url": "http://192.0.2.10",
 "sys": {"name": "camara-01", "t_key": "chave-desta-unidade"},
 "limites": [{"idx": 0, "temp": [2.0, 8.0]}]}

A seção alarms se aplica sem reiniciar. As chaves de sys deste modelo incluem tz, que reinicia (grupo time), e t_sec, que reinicia (grupo mqtt); a resposta diz isso em reboot_for (capítulo 5). Um aparelho que já tem os mesmos valores não reinicia, porque um campo igual ao atual não conta como mudança.

Reinícios em lote

Uma gravação que reinicia tira o aparelho do ar por alguns segundos e encerra todas as sessões dele, inclusive as dos operadores. Numa frota:

  • agrupe numa única gravação tudo o que vai para o mesmo aparelho: duas gravações que reiniciam custam dois reinícios;
  • prefira os grupos que se aplicam sem reiniciar (alarms, maint, alarm_tel, telemetry) para as mudanças frequentes;
  • faça as mudanças que reiniciam fora do horário de uso, e nunca em todos os aparelhos de uma vez;
  • toda gravação de contas reinicia: cadastre várias pessoas num único pedido.

Configuração que muda por fora

Guarde o cfg de cada aparelho depois de cada gravação sua. Se o valor mudar sem uma gravação do gestor, alguém mudou a configuração pela página, pelo painel ou pelo console. O cfg chega também em cada POST de telemetria, no cabeçalho X-SIMUT-Cfg, então o coletor percebe a mudança sem perguntar nada ao aparelho.

Compare o cfg de um aparelho só com os valores anteriores dele mesmo. Dois aparelhos com a mesma configuração quase nunca têm o mesmo cfg, porque as contas levam sementes aleatórias (capítulo 20). Para comparar aparelhos entre si, compare os campos de GET /api/config.

Monitoramento

Saúde pelo Prometheus

GET /metrics entrega os números de cada aparelho no formato do Prometheus, com HTTP Basic (capítulo 24). Para a frota:

  • crie em cada aparelho uma conta só com Painel PERM_DASHBOARD para o Prometheus;
  • use a mesma conta e a mesma senha em toda a frota só se aceitar que vazar uma é vazar todas; o mais seguro é uma senha por aparelho;
  • use um intervalo de coleta de 60 s, e nunca menos de 15 s. Cada coleta confere a senha do zero, e isso ocupa o aparelho por cerca de 0,69 s (medido na v2.2.13, 19/08/2026; capítulo 24);
  • uma senha errada no Prometheus bloqueia o endereço dele, e o bloqueio vale também para a entrada na interface web a partir do mesmo endereço (capítulo 26).

A lista de métricas, a configuração do Prometheus e as regras de alerta estão no capítulo 24.

Estado pela API

Para um painel próprio, leia GET /api/status?quiet=1 de cada aparelho (capítulo 26). Os campos que importam numa frota:

Campo Para quê
sys.ver, sys.env Versão e imagem: quem precisa de atualização
sys.cfg Configuração alterada por fora
sys.uptime Reinícios inesperados: o valor volta a zero. Lembre que ele também volta a zero a cada 49,7 dias
sys.rssi Sinal fraco. Com −78 dBm ou menos, o aparelho adia a telemetria (capítulo 9)
sys.ntp Relógio sem acerto pela rede (capítulo 10)
sys.pending Telemetria acumulada sem entrega
sys.fs_u, sys.fs_t Sistema de arquivos enchendo
sensors[].val "Error" indica sensor em falha

?quiet=1 não adia a hibernação do Air. Um intervalo de 60 s por aparelho basta para um painel de frota; a página Painel de Controle pergunta a cada 3 s porque mostra um aparelho só.

Alarmes pela linha de alarmes

Para saber em segundos que um sensor passou do limite, falhou ou entrou em manutenção, não pergunte: deixe o aparelho avisar pela linha de alarmes (capítulo 22). Numa frota:

  • aponte a linha de alarmes de todos os aparelhos para o mesmo coletor, com um caminho próprio (a_path) diferente do caminho da telemetria;
  • identifique o aparelho pelo X-SIMUT-Uid do POST, ou pelo tópico no MQTT;
  • responda 2xx rápido: a fila da linha de alarmes vive na memória, e um reinício perde o que não foi confirmado (capítulo 22).

Aparelhos em silêncio

Um aparelho que parou de mandar telemetria não avisa que parou. Para cada uid, compare a hora do último POST com o ritmo esperado dele (capítulo 21). Um silêncio muito maior que o intervalo de envio pede uma verificação: rede, energia ou um aparelho parado. No Prometheus, a própria métrica up da coleta cumpre esse papel para os aparelhos que ele coleta.

Atualização da frota

O manifest.json

Cada release do projeto publica, nos ativos da página de releases no GitHub (https://github.com/angeloINTJ/simut/releases), as imagens de cada variante, os pacotes de idioma e um manifest.json que as descreve:

{
  "version": "2.7.1",
  "min_from": "1.6.2",
  "images": {
    "release": {
      "file": "simut_v2.7.1_release.bin",
      "size": 982844,
      "sha256": "9b1f…e07a",
      "uf2": {"file": "simut_v2.7.1_release.uf2", "size": 1966080, "sha256": "44c2…91d0"}
    }
  }
}

O exemplo mostra só a entrada release; as entradas alpha e air têm a mesma forma, com os arquivos simut_v2.7.1_alpha.bin e simut_v2.7.1_air.bin. Os tamanhos e os resumos são ilustrativos e aparecem abreviados; cada release traz os seus, com os 64 algarismos do SHA-256.

Campo Significado
version A versão desta release
min_from A versão mais antiga que consegue receber esta release pela rede
images.<env> A imagem de cada variante, com a mesma chave que sys.env do aparelho: release, alpha ou air, e, desde a v2.11.0, releasetwo (o Pico 2 W)
file, size, sha256 Nome do .bin, tamanho em bytes e SHA-256 em hexadecimal
uf2 O mesmo firmware em .uf2, para gravar pelo cabo com o botão BOOTSEL (capítulo 3). Não serve para a atualização pela rede. No releasetwo, é a imagem de fábrica: a tabela de partições e o programa, sem a marca de teste que o .bin leva

Os pacotes de idioma da mesma release, como language_pt-BR.lng, vêm nos mesmos ativos.

A release só publica o manifesto quando a imagem de cada variante traz a etiqueta da própria variante e da versão. O aparelho também confere a etiqueta: uma imagem de outra variante é recusada no envio com "v":7 (capítulo 26).

Antes de atualizar um aparelho

Para cada aparelho, o gestor confere:

  1. A imagem certa. Leia sys.env e escolha images[env]. Nunca escolha pela versão ou pelo nome do arquivo.
  2. O arquivo inteiro. Calcule o SHA-256 do .bin baixado e compare com sha256. Confira também size.
  3. A etiqueta. O .bin contém o texto SIMUT-ENV:<env>;v=<versão>;. Confira que <env> é o do aparelho e <versão> é a do manifesto.
  4. A assinatura. O .bin termina com os 8 bytes SIMUTSIG. Sem eles, o aparelho recusa a imagem com "v":8, depois de o envio já ter sobrescrito o sistema de arquivos.
  5. A versão de partida. A versão atual do aparelho precisa ser igual ou mais nova que min_from. Firmwares anteriores à 1.6.2 tinham um aplicador que dizia ter atualizado sem instalar nada; eles precisam de uma gravação pelo cabo uma vez. No Pico 2 W, a primeira versão publicada entra pelo cabo: uma imagem compilada antes dela pode recusar a atualização pela rede.
  6. A conta. A atualização exige o administrador completo (O que só o administrador completo faz).
import hashlib, json, re

man = json.load(open("manifest.json"))
env = "release"                                  # sys.env do aparelho
img = man["images"][env]
dados = open(img["file"], "rb").read()
assert len(dados) == img["size"], "tamanho diferente do manifesto"
assert hashlib.sha256(dados).hexdigest() == img["sha256"], "SHA-256 diferente"
m = re.search(rb"SIMUT-ENV:([a-z]+);v=([^;]+);", dados)
assert m and m.group(1).decode() == env and m.group(2).decode() == man["version"], "etiqueta errada"
assert dados[-8:] == b"SIMUTSIG", "imagem sem assinatura"

A sequência em cada aparelho

A sequência é a do capítulo 26, com dois passos a mais no fim:

  1. Baixe o backup .bkp e confira a integridade.
  2. Envie a imagem com POST /api/restore?op=stage&commit=1 e confira "v":0 e "committed":1.
  3. Aplique com POST /api/ota/apply.
  4. Espere o aparelho voltar e confirme a versão nova em sys.ver.
  5. Confira o backup com POST /api/restore?op=validate e restaure-o com POST /api/restore?op=apply; espere o reinício. O aparelho só aplica o backup que acabou de conferir (capítulo 26).
  6. Envie os pacotes de idioma da release nova para /lang e reinicie, para que os textos novos apareçam traduzidos (capítulo 13).

Uma imagem de 1 MB leva cerca de 30 s para chegar. Não desligue nem reinicie o aparelho entre os passos 2 e 4: há um único espaço de firmware, e uma falha na gravação exige o cabo USB (capítulo 18).

Em ondas

Nunca atualize a frota inteira de uma vez.

Figura 201. A atualização em ondas. Cada onda só começa depois de a anterior se provar estável.
  1. Onda 0. Um aparelho de bancada de cada imagem em uso. Confira a versão, a telemetria, a linha de alarmes, o painel e o histórico restaurado.
  2. Onda 1. Poucos aparelhos em uso real. Espere um período de trabalho normal e confira que todos voltaram a mandar telemetria.
  3. Onda 2. O resto, em grupos pequenos, um aparelho de cada vez dentro de cada grupo.

Pare tudo ao primeiro aparelho que não voltar ou que voltar com a versão antiga. Um status HTTP de sucesso não prova nada: só a versão nova informada pelo aparelho prova a atualização.

air Um Air só atende enquanto está acordado em M0. Atualize um Air com ele na bancada, ligado ao carregador, ou dentro de uma janela em que ele esteja acordado (capítulo 19).

Segurança numa frota

As recomendações gerais estão no capítulo 29. Numa frota, somam-se estas:

  1. Rede fechada. Ponha aparelhos, coletor e gestor numa rede ou VLAN própria, sem rota para a internet. Nunca exponha um aparelho à internet, nem com porta redirecionada.
  2. HTTPS onde a rede não é sua. Em HTTP, quem escuta a rede lê as leituras, os PINs enviados num commit_all e o token de sessão, e o resumo da senha basta para entrar (capítulo 26). Instale um par de certificados em cada aparelho release (capítulo 9).
  3. Uma conta por função, com o mínimo de permissões. Monitoramento com Painel; configuração com a conta de serviço; atualização com o admin, só nas janelas de atualização.
  4. Senhas diferentes em cada aparelho, guardadas num cofre de segredos e lidas do ambiente pelos scripts, nunca escritas neles.
  5. Uma chave de telemetria por aparelho (t_key), conferida pelo coletor. Os cabeçalhos X-SIMUT-* identificam, mas não autenticam: qualquer máquina da rede pode imitá-los (capítulo 20).
  6. Backups são segredos. Um .bkp contém a configuração inteira, com as contas e as chaves. Guarde-os cifrados e com acesso restrito.
  7. Trilha fora do aparelho. Mande o log de eventos de cada aparelho para um servidor syslog (capítulo 25). As gravações do gestor aparecem ali com o código 303, e as entradas com o 300.
  8. Origem CORS exata. Configure só a origem do gestor, com esquema e porta. Sem gestor no navegador, deixe o CORS desligado.
  9. Firmware em dia. As correções de segurança saem só na release mais nova (capítulo 29).

Receita completa: uma pessoa no painel, do zero

release

Esta receita cadastra uma pessoa que vai bloquear alarmes e abrir janelas de manutenção no painel de um aparelho. Ela usa a conta de serviço de 7433 (Contas de serviço). A senha vem do ambiente.

H=http://192.0.2.10
HASH=$(printf '%s' "$SIMUT_SERVER_PASS" | sha256sum | cut -d' ' -f1)

entrar() {
  NONCE=$(curl -s "$H/api/login_init" | sed 's/.*"nonce":"\([^"]*\)".*/\1/')
  curl -s -c jar -X POST "$H/api/login" --data-urlencode user=servidor \
    --data-urlencode "pass=$HASH" --data-urlencode "nonce=$NONCE"
  echo
}

# 1. sessão
entrar

# 2. a política de PIN: o PIN precisa servir no painel e na API
curl -s -b jar "$H/api/config" | python3 -c \
  'import sys, json; d = json.load(sys.stdin); print({k: d[k] for k in ("pin_min", "pin_max", "pin_kb", "pin_alpha")})'

# 3. criar a conta, com PIN e as permissões Bloqueio e Manutenção (6144)
curl -s -b jar -X POST "$H/api/commit_all" --data-urlencode \
  '_payload={"users":{"actions":[{"type":"add","name":"joao","perms":6144,"pin":"482913"}]}}'
echo

# 4. esperar o reinício e entrar de novo
sleep 3
until curl -s -o /dev/null -m 3 "$H/api/login_init"; do sleep 3; done
entrar

# 5. conferir
curl -s -b jar "$H/api/users"
echo

O que esperar em cada passo:

  1. {"ok":true,"redirect":"/"}. Com "redirect":"/force_chpass", a conta de serviço ainda precisa trocar a senha (A primeira entrada).
  2. Por exemplo {'pin_min': 4, 'pin_max': 8, 'pin_kb': 3, 'pin_alpha': 0}. Escolha um PIN só de algarismos, com comprimento entre o maior de 4 e pin_min e o menor de 8 e pin_max. A API aceita só PINs de 4 a 8 algarismos, qualquer que seja a política (capítulo 26).
  3. {"status":"ok","reboot":true,"reboot_for":["users"],"creds":[{"u":"joao","p":"K7M2QX9A"}]}. Guarde a senha de creds agora: ela não aparece de novo. Se a resposta trouxer rejected, leia o motivo antes de seguir (capítulo 26).
  4. O aparelho reinicia logo depois de responder e volta em alguns segundos.
  5. A conta joao aparece com "perms":6144 e "pin":true.

Três variações comuns:

  • "rejected":["users.perms"] e nenhuma conta criada: a conta de serviço não tem as permissões de painel. Ela precisa portar 0x0800 e 0x1000 para concedê-las.
  • "rejected":["users.pin"] e a conta criada sem PIN: o PIN estava fora da regra ou já pertence a outra conta. Defina outro com {"type":"pin","id":<id>,"pin":"..."}, lendo o id em GET /api/users.
  • "rejected":["users.dup"]: já existe uma conta joao. Para trocar as permissões dela, apague por id e crie de novo no mesmo pedido, com a exclusão antes.

A pessoa entra no painel com o PIN. A senha de creds só serve para a interface web, e pede troca na primeira entrada.

Lista de aceitação do gestor

Antes de pôr o gestor em produção, prove cada item:

Voltar ao sumário

Parte VI

Referência

Capítulo 28

Especificações e limites

Este capítulo reúne em tabelas os números do SIMUT: faixas, valores de fábrica, capacidades, tempos e tamanhos. É a página de consulta de quem instala, configura e integra o aparelho, e cada linha aponta para o capítulo que explica o assunto.

Como ler as tabelas

  • Os valores são os da v2.11.1.
  • Quando um número muda de uma imagem para outra, a célula traz o selo da imagem: release, alpha ou air.
  • Uma medição traz a data e a versão em que foi feita. Os demais números vêm do código.
  • A coluna Onde leva ao capítulo que explica o item. Lá estão o efeito de cada valor e o que fazer quando um limite é atingido.

Plataforma

Item Valor Onde
Placa Raspberry Pi Pico W. O Pico sem W não serve: o firmware depende do rádio cap. 2
Processador RP2040, dois núcleos: o Core 0 mede, grava e atende a rede; o Core 1 cuida da tela cap. 1
Rádio CYW43, para o Wi-Fi e o Bluetooth cap. 2
Memória flash 2 MB cap. 1
Espaço do programa 1.020 KiB, um único espaço, sem cópia da versão anterior cap. 17
Sistema de arquivos (LittleFS) 1 MiB cap. 15
Dados da atualização 4 KiB no fim da flash cap. 17
Maior imagem aceita pela atualização web 1.040.384 B (1.016 KiB) cap. 17
Menor imagem aceita pela atualização web 100 KiB cap. 17
Wi-Fi Só 2,4 GHz. Uma rede só de 5 GHz não aparece na busca cap. 9
Segurança do Wi-Fi do AP de configuração WPA2 cap. 9
Figura 202. Legenda: a flash de 2 MB. O teto da atualização web fica 4 KiB abaixo do fim do espaço do programa.

Recursos por imagem

Recurso release alpha Air Onde
Tela Painel TFT 320 × 240 com toque LCD 16×2 Nenhuma cap. 1
Cigarra (buzzer) Sim Sim Não cap. 7
Bluetooth (console) Não Sim Sim, acordado (M0) cap. 14
HTTPS na interface web Sim, com certificado Não Não cap. 9
Nome <nome>.local (mDNS) Sim Não Não cap. 9
Console serial De emergência, 15 comandos De emergência, 15 comandos Completo cap. 14
Rotas da API 62 56 56, só acordado (M0) cap. 26
AP de configuração A pedido: menu do painel, comando ap ou gesto no boot A pedido: comando ap A pedido: comando ap cap. 9
PIN e contas no painel Sim Não Não cap. 8
Hibernação entre leituras Não Não Sim cap. 19

Pinos

Uso release alpha Air Onde
Sensores GP0 a GP15 GP0 a GP15 GP0 a GP15 cap. 6
Tela SPI0: MISO GP16, SCK GP18, MOSI GP19; CS GP28, DC GP27, RST GP26 LCD em 4 bits: RS GP16, E GP17, D4 a D7 em GP18 a GP21 — cap. 2
Toque CS GP17, IRQ GP20, no mesmo SPI0 — — cap. 2
Cigarra GP22 GP22 — cap. 2
Alimentação dos sensores e sinal de acordado — — GP16 cap. 19
Detecção do carregador — — GP17 de fábrica; aceita GP0 a GP22 e GP26 a GP28 cap. 19
Rádio do Pico W GP23, GP24, GP25, GP29 GP23, GP24, GP25, GP29 GP23, GP24, GP25, GP29 cap. 2

Sensores

Item Valor Onde
Slots 16, numerados de 0 a 15 cap. 6
GPIOs por slot De 1 a 4, conforme o tipo cap. 6
GPIOs aceitos GP0 a GP15, em todas as imagens cap. 6
Nome do slot Até 31 caracteres, sem aspas, barra invertida nem caracteres de controle cap. 6
ID de Hardware De 1 a 15 caracteres: letras sem acento, dígitos, _ e - cap. 6
Sensores I²C (BME280 e BMP280) Um por par SDA/SCL, no endereço 0x76 ou 0x77: a gravação recusa dois slots ativos no mesmo GPIO cap. 2
Sensores I²C nos pares do periférico No máximo um no I2C0 e um no I2C1; outros pares são lidos pelo PIO cap. 2
Pull-up externo 4,7 kΩ no dado do DS18B20; 4,7 kΩ em SDA e SCL do BME280 e do BMP280, se o módulo não tiver cap. 2
Procurar sondas Resultado em até 10 s; sensores I²C só em GP4 (SDA) e GP5 (SCL) cap. 6
Resolução DS18B20 9 a 12 bits; fábrica 12 cap. 6
Espera da conversão do DS18B20 Sempre 750 ms, qualquer que seja a resolução cap. 6
Amostra (ms) 1000 a 60000; fábrica 2000. Sem efeito; mudar grava sem reiniciar desde a v2.7.4 cap. 6

Tipos de sensor

Tipo Pinos Grandezas Pausa entre leituras O que o aparelho recusa Onde
DS18B20 1 Temperatura 1 s, mais 750 ms de conversão CRC errado; temperatura fora de −50 a 150 °C; outra sonda no pino cap. 6
DHT22 1 Temperatura e umidade 2 s Soma de verificação errada; sem resposta em 150 ms cap. 6
BME280 2 Temperatura, umidade e pressão 5 s Temperatura fora de −40 a 85 °C; umidade fora de 0 a 100 % e pressão fora de 300 a 1.100 hPa, só naquela grandeza cap. 6
BMP280 2 Temperatura e pressão 5 s Como o BME280 cap. 6

air No Air, a leitura acontece a cada despertar, sem pausa entre as leituras (capítulo 19).

Leitura, erro e calibração

Item Valor Onde
Média Últimas 10 leituras; descarta as 2 menores e as 2 maiores e tira a média das 6 restantes cap. 6
Entrada em erro 3 falhas seguidas cap. 6
Saída do erro 5 leituras boas seguidas cap. 6
Conferência da sonda DS18B20 A cada 5 leituras; em quarentena, releitura da ROM a cada 10 ciclos cap. 6
Pontos de calibração Até 5 por grandeza; 1 ponto soma um offset cap. 6
Interpolação Suave Exige 3 pontos ou mais; com menos, vale a Reta cap. 6
Gravação da calibração Uma a cada 5 s, com o relógio acertado por NTP cap. 6

Grandezas e limites de alarme

Grandeza Chave Unidade Faixa aceita Limites de fábrica Onde
Temperatura temp °C −327,68 a 327,66 0 a 40 cap. 6
Umidade hum % 0 a 102,3 20 a 80 cap. 6
Pressão press hPa 0 a 1.638,3 A faixa inteira cap. 6
Luminosidade lux lx 0 a 167.772,15 A faixa inteira cap. 6

A luminosidade existe na tabela de grandezas, mas nenhum dos quatro tipos de sensor a informa na v2.7.1. Os limites de alarme mudam em passos de 0,1, e um mínimo igual ou maior que o máximo faz o aparelho subir o máximo para o mínimo mais 0,1 (capítulo 7).

Histórico

Item Valor Onde
Intervalo Histórico (min) 1 a 1440; fábrica 1 cap. 6
Arquivo Um por dia, /history/AAAAMMDD.h5, no fuso do aparelho cap. 15
Registros por bloco selado Até 60. Com o intervalo de fábrica, 1 h cap. 15
Selagem antecipada Na virada do dia e numa correção do relógio por NTP cap. 15
Bloco aberto Na RAM, copiado para /history/.wip a cada registro; com o aparelho ocupado, nova tentativa em 2 s cap. 15
Perda numa falta de energia No máximo o último registro cap. 15
Espaço por registro 5,38 B com 11 canais a 1 registro por minuto, cerca de 7,6 KiB por dia (arquivos de bancada V5, 31/07/2026) cap. 15
Retenção estimada Cerca de 116 dias nesse caso; varia com os canais, o intervalo e a variação dos valores cap. 15
Limpeza automática Acima de 86 % do sistema de arquivos, apaga os dias mais antigos; confere a cada minuto cap. 15
Ritmo da limpeza 2 arquivos por vez; se ainda acima, 1 a cada 15 s. air Até 4 por despertar cap. 15
Arquivo do dia corrente Nunca é apagado pela limpeza cap. 15
Lacuna no gráfico Registros separados por mais de 3,5 vezes o Intervalo Histórico, com o mínimo de 90 s cap. 15
Baldes do gráfico Um por pixel de largura, de 300 a 1200; até 1,6 registro por balde, cada registro aparece como é cap. 15
Períodos do gráfico 1h, 6h, 24h, 7d, 1M (30 dias), 1A (365 dias), MAX cap. 15
Exportação pela API Até 31 dias por pedido, em .simx cap. 26

Log de eventos

Item Valor Onde
Tamanho de um registro 12 bytes cap. 16
Arquivos /system.blog e /system.old.blog, de 800 registros cada cap. 16
Registros guardados Entre 800 e 1.600, os mais recentes cap. 16
Códigos de evento 170 ap. B
Tempo ligado gravado no registro Até cerca de 194 dias cap. 16
Registros segurados na RAM durante toque ou operação pesada Até 32; o excedente se perde cap. 16
Filtro por transição Vai para a flash o primeiro sucesso de cada família depois do boot, a primeira falha, o primeiro sucesso depois de uma falha e um registro por família a cada hora cap. 16
Resumo do que ficou de fora Um registro Registros de rotina suprimidos (5) por hora cap. 16
air Despertar do ciclo Um registro por ciclo, Snapshot de histórico gravado (567) cap. 16
Exportação pela API Até 31 dias por pedido, em .simx cap. 26
Ritmo de GET /api/logs Um pedido a cada 200 ms por endereço cap. 26

O filtro vale só para a flash: o console com debug on e o syslog recebem todos os eventos.

Contas e segurança

Item Valor Onde
Contas Até 32; a conta 0 é a do admin cap. 8
Nome da conta De 1 a 15 caracteres, único sem diferenciar maiúsculas de minúsculas cap. 8
Permissões 13, uma por bit; perms até 8191 cap. 8
Senha inicial do admin 8 caracteres aleatórios, mostrados uma vez no console USB cap. 8
Senha nova, pela página Pelo menos 8 caracteres, com letra, dígito e símbolo cap. 13
Senha nova, conferida pelo aparelho release Só em HTTPS: pelo menos 8 caracteres, com letra e dígito cap. 8
Resumo da senha HMAC-SHA256, 5.000 rodadas, sal aleatório de 8 bytes por conta cap. 8
Sessões web 3 ao todo, 1 por conta cap. 26
Ociosidade da sessão web 15 min sem pedido autenticado; um reinício encerra todas cap. 26
Código de uso único da entrada 32 algarismos hexadecimais; vale 60 s e uma tentativa cap. 26
Token de sessão 32 algarismos hexadecimais, em cookie ou Authorization: Bearer cap. 26

Bloqueios

Canal Regra Onde
Web e /metrics Por endereço IP: 2 s no primeiro erro, dobrando até 300 s a partir do nono cap. 26
Tabela de bloqueios web 8 endereços; a contagem de erros para em 12. Com os 8 bloqueados, um endereço novo recebe 429 cap. 26
release PIN do painel, por conta 3ª tentativa errada: 5 s; 4ª: 15 s; 5ª: 60 s; 6ª: conta bloqueada no painel até reiniciar cap. 8
release Painel inteiro Travado depois de 20 tentativas erradas somadas entre todas as contas, até reiniciar cap. 8
alpha air Bluetooth 2 s no primeiro erro, dobrando até 300 s a partir do nono; vale também depois de reconectar cap. 14
alpha air Senha do Bluetooth A do admin da web, até 64 caracteres cap. 14
alpha air Sessão Bluetooth Termina com 5 min sem nada digitado cap. 14
alpha air Descoberta do Bluetooth Visível nas buscas por 5 min depois que o Bluetooth liga, no boot cap. 14

PIN do painel

release

Item Valor Onde
Caracteres por tecla 1, 2 ou 3; fábrica 3 cap. 8
Alfabeto 0-9 ou 0-9 A-Z; fábrica 0-9 cap. 8
Tamanho mínimo De 4 até o teto; fábrica 4 cap. 8
Teto do tamanho 8 com 3 caracteres por tecla, 12 com 2, 16 com 1 cap. 8
Identificação no painel Confere qualquer PIN a partir de 4 caracteres; um certo mais curto que a política leva direto à troca cap. 8
PIN pela web ou pela API Sempre de 4 a 8 dígitos cap. 8
PIN de fábrica do admin 1234, com troca obrigatória cap. 8

Rotas, ritmo e tamanhos da API

Item Valor Onde
Rotas release 62, das quais 52 exigem permissão ou sessão e 10 são públicas. alpha air 56 cap. 26
Pedidos simultâneos Um de cada vez; os outros esperam na fila cap. 26
Intervalo mínimo por endereço 200 ms em GET /api/logs e GET /api/ls; 5 s em POST /api/calib e POST /api/tls cap. 26
Campo _payload de POST /api/commit_all Até 6.144 bytes cap. 26
Corpo de POST /api/calib e POST /api/tls Até 8.192 bytes cap. 26
Janela de manutenção Até 30 dias (2.592.000 s); um pedido maior é cortado cap. 7
release Janela de manutenção pelo painel De 5 min a 720 h, com os minutos em passos de 5 cap. 7
sys.uptime Volta a zero a cada 49,7 dias cap. 27
Tempo de espera do cliente, sugerido 10 s em leituras; 30 s em exportações, listagens e histórico; 60 s em envio de arquivo e atualização cap. 26

Rede

Nomes e senhas

Campo Limite Fábrica Onde
Nome do aparelho 1 a 31 caracteres; use até 26, porque o AP acrescenta _SETUP e o nome de rede tem no máximo 32 simut cap. 9
SSID 1 a 31 caracteres Vazio cap. 9
Senha do Wi-Fi Até 31 caracteres; o WPA2 aceita até 63, mas o aparelho recusa uma senha mais longa Vazio cap. 9
Servidor NTP Até 31 caracteres; vazio usa pool.ntp.org Vazio cap. 9
Linha do console serial Até 256 caracteres; uma linha maior é descartada — cap. 14

Wi-Fi e sinal

Item Valor Onde
Espera pela rede no boot Com rede configurada, até 30 s; depois o aparelho segue sem rede. Sem rede configurada, nenhuma cap. 10
Busca de redes Até 12 redes na lista; prazo de 15 s no aparelho e cerca de 18 s na página cap. 9
Sinal fraco Em −78 dBm ou abaixo, a telemetria, a linha de alarmes e os envios pesados esperam cap. 9
Sinal impossível 0 dBm ou mais, ou abaixo de −120 dBm, em duas leituras seguidas, com 1 min entre elas: o aparelho reconecta cap. 9
Sinal sem conexão Informado como −100 dBm cap. 9

Escada de reconexão

Item Valor Onde
Uma tentativa de entrar na rede Até 20 s cap. 9
Uma busca antes da tentativa Até 15 s cap. 9
Esperas entre tentativas 5, 10, 20, 40 e 80 s cap. 9
Dormência 10 min antes de cada busca, três vezes; depois a escada recomeça cap. 9
AP de configuração A escada não abre o AP: tenta a rede até ela voltar. Da v2.7.1 à v2.8.0, abria: na primeira dormência, cerca de 6 a 7 min depois de ligar, num aparelho que nunca obteve IP (medido em bancada em 22/09/2026), e depois de uma volta inteira, cerca de 68 min pela aritmética da escada, num que já tinha obtido cap. 9

AP de configuração

Item Valor Onde
Abertura Só a pedido: o comando ap, em todas as imagens; release o item 8 do menu do painel, com a permissão Rede, e o gesto no boot. Da v2.7.1 à v2.8.0, a release e o alpha também abriam sozinhos, no boot sem rede configurada e pela escada de reconexão cap. 9
Nome da rede <nome>_SETUP cap. 9
Chave 10 caracteres, letras maiúsculas e algarismos sem O, 0, I e 1; sempre a mesma naquele aparelho, mesmo depois de um reset de fábrica cap. 9
Endereço do aparelho http://192.168.4.1 cap. 9
AP aberto num aparelho com rede configurada, pelo painel, pelo comando ap ou pelo gesto no boot Dura 15 min; depois o aparelho reinicia para tentar a rede. Até a v2.11.0, o aberto pelo gesto não seguia esse prazo cap. 9
AP aberto num aparelho sem rede configurada Fica aberto até alguém gravar uma rede ou reiniciar o aparelho cap. 9
Medição com o AP aberto Continua: lê sensores, confere alarmes e grava histórico; telemetria e syslog esperam a rede cap. 9

Data e hora

Item Valor Onde
Esperas entre pedidos ao NTP 20 s, 1 min, 3 min, 9 min e, daí em diante, 15 min cap. 10
Troca para pool.ntp.org Depois de três esperas sem resposta, cerca de 4 min 20 s depois do primeiro pedido; vale até o próximo reinício cap. 10
Correção do relógio no log de eventos No primeiro acerto depois do boot, pelo NTP ou à mão: acima de 5 s (evento 408); acima de 1 h, como aviso cap. 10
release Pergunta da data e da hora no boot Num aparelho sem rede configurada e com o relógio provisório; PULAR, ou 30 s sem toque, levam à tela inicial cap. 10
Acerto à mão pelo painel e pelo console Ano de 2026 a 2099; o dia tem de existir no mês; segundos em zero no painel. O time vale no console de todas as imagens cap. 10
Contexto do evento 13 num acerto à mão 1 interface web, 2 console, 3 painel (item 4 do menu), 4 painel (pergunta do boot) cap. 10
Fuso Horário −12 a +14, em horas inteiras, sem horário de verão; fábrica −3 cap. 10

Servidor web, HTTPS e CORS

Item Valor Onde
Porta HTTP 1 a 65535; fábrica 80 cap. 9
Conexões persistentes (keep-alive) Ligadas de fábrica cap. 9
release Porta HTTPS 443 quando a Porta HTTP é 80; senão, a porta configurada. O aparelho nunca serve HTTP e HTTPS ao mesmo tempo cap. 9
release TLS da interface web Só TLS 1.2, troca de chaves ECDHE, cifra AES-GCM de 128 ou 256 bits cap. 9
release Clientes TLS ao mesmo tempo 1 cap. 9
release Par de certificado e chave Até 8 KB; um par ausente, vazio, maior ou ilegível faz o aparelho subir em HTTP cap. 9
release mDNS <nome>.local e o serviço _simut._tcp, com uid, ver, env e tls cap. 9
Origem CORS Até 64 caracteres, http:// ou https://, sem caminho nem barra no fim cap. 9
Validade da resposta de verificação (preflight) Access-Control-Max-Age: 600 (10 min) cap. 26

Telemetria

Item Valor Onde
Transportes HTTP, HTTPS, MQTT e MQTTS cap. 21
Lote mínimo (registros) (t_int) 0 a 20.000; fábrica 0, que desliga a telemetria cap. 21
Lote máximo (registros) (t_bat) 1 a 250; fábrica 10 cap. 21
Limite do lote pela memória Reserva 12 KB sem TLS ou 32 KB com TLS e conta 350 bytes por registro no JSON e no Dinâmico, 160 no CSV cap. 21
Ajuste automático do lote Cai pela metade a cada falha, até 10; cresce 50 % a cada sucesso, até o Lote máximo cap. 21
Memória livre para enviar 24 KB com TLS, 14 KB sem TLS; a falta conta como falha cap. 21
Primeiro envio depois de ligar Pelo menos 8 s depois cap. 21
Resposta do coletor HTTP 4 s; só 200 a 299 é entrega cap. 21
Negociação TLS no HTTPS 15 s cap. 21
Espera depois de uma falha 5 s, dobrando até 300 s, com variação de 25 % para mais ou para menos cap. 21
Pausa entre lotes Nenhuma com ciclo de até 0,4 s sem TLS ou 2,5 s com TLS; senão, igual ao ciclo; teto de 10 s cap. 21
Janela de envio 30 dias antes do registro mais novo cap. 21
Contador de pendentes Para de contar em 65.535 cap. 21
Gravação do cursor na flash No máximo a cada 5 s cap. 21
IP Servidor Até 63 caracteres cap. 21
Endpoint Até 31 caracteres; fábrica /api.php cap. 21
API Key Até 63 caracteres cap. 21
Formatos JSON, CSV com 34 colunas e Dinâmico cap. 21
Modelos do Dinâmico 1. Global até 255 caracteres; 2. Linha até 511; 3. Separador até 7 cap. 21
Cabeçalho Content-Type do Dinâmico Até 31 caracteres, um tipo de mídia; vazio vale application/json. JSON manda sempre application/json, e CSV, text/csv cap. 21
Montagem do corpo Um registro inteiro por vez; o cursor avança só até o último registro enviado cap. 21

MQTT e TLS da telemetria

Item Valor Onde
Tópico Até 63 caracteres; fábrica simut/data cap. 21
Client ID Até 23 caracteres; vazio usa simut_ e o fim do MAC cap. 21
Usuário e Senha Até 31 caracteres cada cap. 21
QoS Só 0 cap. 21
Keep-Alive 10 a 300 s; fábrica 60 s cap. 21
Mensagens por lote Até 5 registros: uma por registro. Mais de 5: uma com o lote. Corpo acima de cerca de 8 KB: uma por registro cap. 21
Conexão ao broker No máximo uma tentativa a cada 5 s; 4 s por operação cap. 21
Entrega no MQTT Mensagens escritas e conexão viva 60 ms depois cap. 21
Versão e cifras TLS Só TLS 1.2; ECDHE-ECDSA ou ECDHE-RSA com AES-128-GCM ou AES-256-GCM cap. 21
Fragmento TLS Até 4.096 bytes (Maximum Fragment Length) cap. 21
/cert.pem Até 16 KB; maior é recusado e a conexão segue sem validar o servidor cap. 21

Linha de alarmes

Item Valor Onde
Tamanho da fila (RAM) (a_qmax) 1 a 64; fábrica 32 cap. 22
Fila cheia Recusa o evento novo e guarda os antigos (evento 553) cap. 22
Reinício A fila está na RAM: o que não foi confirmado se perde cap. 22
Registros por envio HTTP A fila inteira, até 64 cap. 22
Nova tentativa A cada 15 s, sem espera crescente, e a cada evento novo cap. 22
Resposta do coletor HTTP 4 s cap. 22
Confirmação pelo MQTT Até 64 números seq por mensagem cap. 22
Espaço de uma mensagem MQTT 2.048 bytes, cerca de 120 bytes por registro no modelo de fábrica. Com MQTT, use uma fila de até 16 cap. 22
Confirmações MQTT Só são lidas com a telemetria ligada (Lote mínimo acima de 0) cap. 22
seq De 1 a 65.535; volta a 1 e recomeça a cada reinício cap. 22
Caminho HTTP Até 31 caracteres; vazio usa o Endpoint com /alarm cap. 22
Modelos 1. Global até 255 caracteres; 2. Linha até 511; 3. Separador até 7 cap. 22
Cabeçalho Content-Type Até 31 caracteres, um tipo de mídia; vazio vale application/json; só no Dinâmico cap. 22
air Air Alarmes só acordado (M0); a fila não atravessa o sono cap. 22

Syslog, Prometheus e Home Assistant

Item Valor Onde
Syslog: formato RFC 5424 sobre UDP, facility local0 cap. 25
Syslog: Porta UDP 1 a 65535; fábrica 514 cap. 5
Syslog: Nível Mínimo 0 (Debug) a 4 (Fatal); fábrica 1 (Info) cap. 5
Syslog: linha Até 256 bytes por datagrama cap. 25
Syslog: fila 8 linhas; cheia, descarta a mais antiga. Sem Wi-Fi, as linhas esperam nela cap. 25
Prometheus: rota GET /metrics, formato de texto 0.0.4, 45 famílias de métricas cap. 24
Prometheus: acesso HTTP Basic, com senha de até 128 caracteres, ou a sessão da web; a conta precisa da permissão Painel. 401 sem conta e senha válidas, 403 sem a permissão cap. 24
Prometheus: senha errada Conta no mesmo bloqueio por IP da entrada web; bloqueado, recebe 429 cap. 24
Prometheus: intervalo de coleta scrape_interval de 60 s, nunca menos de 15 s. Cada leitura ocupa o aparelho por cerca de 0,69 s (v2.2.13-beta, 19/08/2026) cap. 24
Home Assistant: descoberta Pelo MQTT, uma mensagem retida por medição em homeassistant/sensor/<nó>/<objeto>/config cap. 23
Home Assistant: requisitos Formato JSON; lotes de até 5 registros, para que o Home Assistant leia os valores cap. 23

Arquivos, backup e atualização

Item Valor Onde
Envio de arquivo Recusado se for maior que o espaço livre cap. 17
Nome de arquivo Até 64 caracteres, sem .., %, caracteres de controle, barra vertical nem \ " : < > ? * cap. 29
Pasta /config Nenhum envio, exclusão nem criação cap. 29
Backup Um arquivo .bkp, só para o administrador completo cap. 17
Proteções do backup Cabeçalho de 40 bytes com CRC32 próprio, CRC32 do conteúdo e a identidade do chip cap. 17
Restauração Só no mesmo aparelho, e só o arquivo validado antes; sem limite de arquivos (até a v2.9.0, 200 arquivos e 4 KiB de nomes) cap. 17
Atualização: tamanho da imagem De 100 KiB a 1.016 KiB (1.040.384 B) cap. 17
Atualização: assinatura 241 B no fim do .bin, P-256; conferida no fim do envio (1,87 s) e de novo na instalação (1,94 s), desde a v2.9.0 cap. 17
Atualização: outras conferências Início de imagem válido para o RP2040 nos primeiros 256 bytes; etiqueta da variante igual à do aparelho cap. 17
Atualização: cópia da configuração Gravada no início do envio e usada uma vez, no boot seguinte, desde a v2.8.0; um envio cortado ou recusado mantém a configuração e apaga os demais arquivos cap. 17
release Captura do painel BMP de 320 × 240 pixels, 230.454 bytes cap. 13

SIMUT Air

air

Item Valor Onde
Ociosidade até hibernar (air idle) 10 a 65535 s; fábrica 300 s cap. 19
Renovações antes de entrar na web 3 por boot cap. 19
Período do ciclo O Intervalo Histórico cap. 19
Sono O intervalo menos o tempo acordado; no mínimo 5 s, no máximo 1 s a menos que 24 h cap. 19
Fases do despertar Aquecimento de 0,4 s; amostragem de até 30 s; conexão de até 30 s cap. 19
Rádio Liga quando os registros pendentes chegam ao Lote mínimo; com o Lote mínimo em 0, nunca liga no ciclo cap. 19
Depois de um envio que falha 5 despertares sem rádio cap. 19
Rede que não aparece Duas tentativas por despertar cap. 19
Despertar de leitura 9,31 s, dos quais 6,83 s são a conversão do DS18B20 (v2.4.1-beta, 08/09/2026) cap. 19
Despertar de telemetria Cerca de 12,7 s (v2.4.1-beta, 08/09/2026) cap. 19
Período real 60,5 a 60,6 s para 60 s configurados (v2.4.1-beta, 08/09/2026) cap. 19
Consumo Cerca de 8,2 mA de média e 17 dias numa 18650 de 3.400 mAh. É uma conta sobre os tempos, não uma medição de corrente cap. 19
Lote com t_bat=250 Cerca de 190 registros, limitado pela memória (Air em M0, v2.7.1, 23/09/2026) cap. 19
Relógio através do sono Na v2.7.1, perde até cerca de 1 s por despertar até o próximo acerto por NTP cap. 19
Relógio através do sono Cerca de ±0,09 s por despertar, sem acúmulo (−0,085 a +0,030 s em 10 despertares, bancada, 23/09/2026) cap. 10

Tempos que o operador percebe

Situação Tempo Onde
Boot sem rede Com rede configurada e fora do ar, o aparelho espera a rede por até 30 s e segue sem ela, e o painel mostra Timeout de rede. Iniciando Offline…; sem rede configurada, segue na hora, com Conexão Ignorada pelo Usuário. cap. 11
release Um toque no painel ocupa o aparelho 5 s; nesse intervalo, gravações, capturas e exportações respondem 503 com Retry-After de 5 s nas gravações e 3 s nas leituras cap. 26
release Console durante um toque Guarda até 2 comandos e os executa depois dos 5 s cap. 14
release Volta do painel à tela inicial 30 s sem toque cap. 11
release Aviso Web: <conta> no painel 5 s depois de uma entrada na web cap. 11
release Silenciar 120s 120 s cap. 7
alpha Troca de grandeza no LCD A cada 3 s; a tela atualiza a cada 0,5 s cap. 12
Painel de Controle da web Consulta o aparelho a cada 3 s cap. 13
Página depois de Salvar e reiniciar Recarrega sozinha cerca de 12 s depois cap. 13
Página depois de mudar a Porta HTTP Abre o endereço novo cerca de 15 s depois cap. 9
Busca de redes Cerca de 1 s cap. 9
Restauração de backup A página avisa que o aparelho está fora do ar depois de 90 s cap. 17
Atualização: envio e conferência 34,9 a 35,9 s (v2.7.0, 22/09/2026, 6 atualizações) cap. 17
Atualização: da aplicação até o aparelho voltar 52 a 56 s (v2.7.0, 22/09/2026, 6 de 6 bem-sucedidas) cap. 17
Atualização: cópia da imagem Cerca de 25 s em que uma falta de energia exige BOOTSEL e cabo USB cap. 17
release Quadro do espelho do painel 213 ms dentro do aparelho (v2.5.0-beta, 19/09/2026) cap. 13
release Captura do painel 1,69 s (v2.4.10-beta, 18/09/2026) cap. 13

Voltar ao sumário

Capítulo 29

Segurança

O que o aparelho protege, como ele faz isso e o que fica por conta de quem instala. Este capítulo é para quem responde pela TI e pela conformidade da instalação; os detalhes de cada mecanismo estão nos capítulos indicados em cada seção.

Quem pode falar com o aparelho

Todo acesso ao aparelho passa por um destes caminhos, e cada um tem a sua própria autenticação.

Caminho Imagens Como a pessoa se identifica O que esse caminho alcança
Interface web e API, pela rede todas (o Air só acordado) conta e senha; depois, cookie de sessão ou token Bearer o que as permissões da conta liberam
Painel release conta e PIN o que as permissões da conta liberam no painel
Console USB todas acesso físico ao cabo os comandos de recuperação, que só existem aqui
Console Bluetooth alpha air senha do admin da web o console, menos os comandos de recuperação
Ponto de acesso de configuração todas chave WPA2 própria do aparelho a interface web, enquanto o AP estiver no ar

O console USB é o caminho de maior confiança: quem tem o cabo tem a placa na mão. Por isso os quatro comandos de recuperação (system factory, system format, system admin reset e system https off) são recusados pelo Bluetooth, mesmo com a senha certa. Uma recuperação que funciona pelo rádio só ajudaria quem já entrou.

Contas e permissões

  • O aparelho tem 32 contas. A conta 0 é a do administrador.
  • Cada conta tem até 13 permissões, uma por bit. Uma conta só vê e altera o que os seus bits liberam, na web, no painel e na API. O capítulo 8 descreve cada permissão.
  • Ninguém concede o que não tem. Uma conta com a permissão de gerenciar usuários só pode dar a outra conta os bits que ela mesma tem. Um pedido que inclui um bit a mais é recusado inteiro, e a resposta diz qual campo foi recusado. A regra fecha a falha V-09 e vale desde a v2.7.0.
  • Quatro operações exigem o administrador completo (todos os bits): fazer backup, restaurar, aplicar uma atualização e instalar o certificado HTTPS.

Senhas, PIN e bloqueios

Senhas da web

  • A senha nunca é gravada. O aparelho guarda um HMAC-SHA256 de 5000 rodadas, com um salt aleatório de 8 bytes por conta e um segundo segredo preso à placa. Hashes antigos, de 2500 rodadas, são convertidos no primeiro login bem-sucedido.
  • A senha inicial do administrador tem 8 caracteres aleatórios. Ela aparece uma única vez, no console USB, e a interface web obriga a trocá-la no primeiro login.
  • Uma conta nova recebe uma senha de 8 caracteres, mostrada uma vez para quem a criou.
  • Tentativas erradas bloqueiam o cliente, com espera de 2 s a 300 s, crescendo a cada erro. A tabela de bloqueio tem 8 posições. Com todas ocupadas, o aparelho responde 429 até uma posição vencer.

PIN do painel release

  • O PIN também não é gravado: o aparelho guarda uma cadeia de hash com salt.
  • A política de PIN (comprimento mínimo, glifos por tecla, alfabeto) é configurável. O teclado é sorteado de novo a cada toque, para que a posição dos dedos não entregue o PIN.
  • Erros bloqueiam primeiro a conta e depois o painel. A sexta falha seguida bloqueia a conta. Vinte falhas no total bloqueiam o painel inteiro até o aparelho reiniciar.

Bluetooth alpha air

  • O login usa a senha do administrador da web.
  • O bloqueio cresce de 2 s a 300 s e continua valendo depois de desconectar e conectar de novo.
  • O aparelho deixa de ser encontrável 5 minutos depois de o Bluetooth ligar. Um aparelho já pareado continua conectando.

Sessões e transporte

  • Sessões da web:
    • o cookie de sessão é HttpOnly e SameSite=Strict, e ganha Secure quando a conexão é HTTPS;
    • uma sessão vence depois de 15 minutos sem uso, e o aparelho guarda até 3 sessões;
    • um integrador pode usar um token Bearer no lugar do cookie (capítulo 26).
  • HTTPS, só na imagem release:
    • o aparelho oferece apenas TLS 1.2, com troca de chaves ECDHE e cifra AES-GCM;
    • o certificado é seu: você o instala com POST /api/tls (capítulo 9);
    • sem certificado instalado, a interface web funciona só em HTTP, e o conteúdo trafega sem cifra na rede local.
  • Telemetria por TLS: o aparelho confere o certificado do seu servidor contra um arquivo /cert.pem que você envia a ele. Sem esse arquivo, a conexão é cifrada, mas ninguém confirma que do outro lado está o seu servidor, e o aparelho registra um aviso no log (capítulo 21).
  • Ponto de acesso de configuração:
    • a rede é WPA2;
    • a chave tem 10 caracteres, é derivada do identificador da placa e sobrevive a um reset de fábrica;
    • ela aparece no console USB, na tela de boot do painel e no LCD do alpha.

Limites contra abuso

  • Toda rota da API tem dono. São 62 rotas: 52 exigem uma permissão e 10 são públicas por projeto, como a página de login. Nenhuma fica sem proteção, e o CI confere isso a cada mudança.
  • As rotas pesadas têm intervalo mínimo por endereço de origem: 200 ms em /api/logs e /api/ls, e 5 s em /api/calib e /api/tls.
  • O gerenciador de arquivos recusa:
    • caminhos com .., codificação por %, bytes de controle e nomes reservados;
    • nomes com mais de 64 caracteres;
    • qualquer operação na pasta /config, onde ficam a configuração e as contas.

Auditoria

  • Registros protegidos: os de segurança, de configuração e de falha fatal sempre vão para o log de eventos. O filtro que reduz o volume do log só atua sobre eventos de rotina (capítulo 16).
  • Ações assinadas: as ações feitas no painel e as mudanças de alarme levam o nome da conta que agiu. Na linha de alarmes, o nome é gravado no registro no momento do evento, então apagar a conta depois não muda quem aparece como autor (capítulo 22).
  • Cópia fora do aparelho: para guardar o log fora do aparelho, envie-o a um servidor syslog (capítulo 25).

O que o aparelho não faz

  • Não tem rollback. Existe um único slot de firmware. Uma gravação interrompida na janela de aplicação, de cerca de 25 s, exige BOOTSEL e cabo USB (capítulo 18).
  • Não cifra o sistema de arquivos. A senha do Wi-Fi, a senha do MQTT e a chave de API da telemetria são gravadas embaralhadas com uma chave derivada do próprio chip. Isso impede a leitura casual de um arquivo copiado, mas não é cifra: quem tem a placa na mão consegue recuperá-las. Proteja o acesso físico.
  • Não é um instrumento metrológico certificado. Valide as leituras contra a sua própria referência antes de usá-lo como controle de um armazenamento regulado.

Recomendações de instalação

  1. Troque a senha do administrador no primeiro login (a interface obriga) e troque o PIN 1234 do administrador no painel.
  2. Crie uma conta por pessoa, cada uma só com as permissões de que ela precisa. Reserve o administrador completo para quem faz backup e atualização.
  3. Ajuste a política de PIN ao risco do local: um PIN mais longo e o alfabeto com letras (0-9A-Z) tornam um palpite mais difícil (capítulo 8).
  4. Ponha o aparelho numa rede separada da rede de visitantes, ou use HTTPS com um certificado seu.
  5. Se a telemetria usa TLS, envie ao aparelho o certificado do seu servidor (/cert.pem).
  6. Envie o log de eventos a um servidor syslog, para que um registro sobreviva ao aparelho.
  7. Baixe um backup depois de configurar e antes de cada atualização.
  8. Proteja o acesso físico à porta USB: os comandos de recuperação estão nela.
  9. Mantenha o firmware na versão mais recente. As correções de segurança só saem na release mais nova, sem retroativos para versões antigas.
  10. No alpha e no Air, lembre que o console Bluetooth está ativo e aceita a senha do administrador.

Auditorias e correções

Data Escopo Resultado
16/08/2026 Revisão do código contra as diretrizes de segurança do projeto Achados fechados na v2.2.5-beta
29/08/2026 Auditoria externa da v2.3.6-beta (ACH-01 a ACH-08) Correções a partir da v2.3.9-beta; ACH-05 e ACH-08 foram feitos depois, na linha de setembro
07/09/2026 Auditoria V-01 a V-08 e O-1 a O-3 Fechada na v2.4.1-beta e verificada no hardware em 08 e 09/09/2026
21/09/2026 Achado V-09: uma conta restrita criava contas com permissões que não tinha Corrigido na v2.7.0 e verificado no hardware, 10 de 10 vereditos com controles positivos

Relatar uma vulnerabilidade

Não abra uma issue pública. Use o relato privado do GitHub no repositório do projeto: aba Security → Report a vulnerability. A política completa está no SECURITY.md do repositório.

Voltar ao sumário

Capítulo 30

Solução de problemas

Os problemas mais comuns, organizados pelo que você vê no aparelho, no navegador ou no servidor. Cada linha diz a causa provável e o que fazer. Comece pelo roteiro de diagnóstico: ele resolve a maior parte dos casos antes de você chegar às tabelas.

Roteiro de diagnóstico

  1. Confira a imagem e a versão. A gaveta da interface web e o comando show system info mostram a versão. A imagem se reconhece pelo aparelho: painel de toque é a release, LCD é o alpha, sem display é o Air; ela aparece também no campo sys.env de GET /api/status. Parte dos comportamentos deste capítulo vale só para uma imagem ou uma versão.
  2. Leia o log de eventos. Na página Histórico e Logs, marque INF, WRN e ERR. No console USB, show system log mostra tudo o que está gravado. O log diz o que o aparelho tentou, o que falhou e quando (capítulo 16).
  3. Confira a rede. A página Rede e o comando show net status mostram o endereço e o sinal. Com o sinal em −78 dBm ou abaixo, a telemetria e a linha de alarmes esperam (capítulo 9).
  4. Confira a hora. Sem hora confiável, o histórico e a telemetria esperam. Veja se o NTP sincronizou (capítulo 10).
  5. Guarde as provas antes de mexer. Exporte o log em CSV e baixe um backup. Um reinício ou uma restauração apagam pistas.
  6. Se a interface web não abre, use o console USB (capítulo 14). Se nem o console responde, siga o capítulo 18.

O aparelho parou de medir ou de alarmar

Esta é a falha que mais importa num equipamento de monitoramento. Confira estes casos primeiro.

Sintoma Causa provável O que fazer
O painel ou o LCD mostram valores parados, e o histórico não cresce Da v2.7.1 à v2.8.0: o AP de configuração está no ar, e nessas versões, com ele aberto, o aparelho não lê os sensores, não confere os alarmes e não grava o histórico Atualize o firmware. Até lá, configure a rede pelo AP ou reinicie (Enquanto o AP está aberto)
Um aparelho que funciona sem Wi-Fi nunca gravou nada Da v2.7.1 à v2.8.0, sem rede configurada, o aparelho abre o AP no boot, fica nele e não mede Atualize o firmware, ou configure uma rede Wi-Fi no aparelho (capítulo 9)
Buracos de cerca de 15 min no histórico durante uma queda longa da rede Da v2.7.1 à v2.8.0: a escada de reconexão abriu o AP, e com o AP no ar essas versões não medem Atualize o firmware. Confira no log os eventos 403 e 525; o trecho sem medição não é recuperado
O histórico parou e o log mostra 512 O aparelho perdeu a referência de hora, e sem ela o histórico não grava Corrija o acesso ao NTP ou acerte a hora (capítulo 10). O evento 513 marca a volta
O histórico parou e o log mostra 515 Nenhum sensor está dando valor Veja a tabela de sensores do Painel de Controle e o capítulo 6
O log mostra Pulando arquivo de log ativo (563) O sistema de arquivos passou de 86 % de ocupação Remova arquivos que você enviou, como temas, pacotes de idioma e /web (capítulo 15)
Um sensor em alarme não fez a cigarra tocar Som de alarme desligado, Mudo Global, volume em 0 ou um silêncio de 120 s em andamento Confira os sons (capítulo 7)
Um sensor desconectado não alarma O slot está numa janela de manutenção, ou a falha foi calada com Desativar Veja a linha Manutenção no menu do sensor (capítulo 7)
air Um valor fora da faixa não gerou alarme Nos despertares (M1), o Air não confere limites Confira os limites no coletor da telemetria (capítulo 19)
Um sensor mostra Erro no painel ou ERRO no LCD Três leituras seguidas falharam: fio solto, pino errado ou sensor queimado Confira a ligação e o GPIO do slot (capítulo 6)

Instalação e primeiro boot

Detalhes nos capítulos 2, 3 e 4.

Sintoma Causa provável O que fazer
O aparelho reinicia sozinho, sem causa no log de eventos Queda de tensão no cabo USB ou na fonte Troque por um cabo de pelo menos 22 AWG e uma fonte firme (capítulo 2)
O painel fica branco ou sem imagem Fiação do SPI, do CS, do DC ou do RESET trocada ou solta Confira a tabela do TFT pino a pino (capítulo 2)
Pontos soltos em áreas lisas do painel ou do espelho da web Fios longos ou ruins para os 66,5 MHz do TFT Encurte a fiação; se não resolver, compile com frequência menor (capítulo 3)
O toque não responde T_CS fora do GP17 ou T_IRQ fora do GP20 Confira as ligações do toque (capítulo 2)
O LCD mostra blocos cheios ou fica em branco Contraste desajustado, ou LCD no 3V3 Ajuste o potenciômetro do VO; alimente o LCD pelo 5 V (capítulo 2)
DS18B20 com Erro de CRC (103) ou falha ao ler a ROM (999) Falta o resistor de 4,7 kΩ, ou há duas sondas no mesmo GPIO Ponha o resistor entre o dado e o 3V3 e deixe uma sonda por GPIO (capítulo 2)
Procurar sondas não acha o BME280 O sensor não está em GP4 (SDA) e GP5 (SCL) Configure o slot à mão com os pinos certos (capítulo 6)
Depois de gravar um BME280, o aparelho não termina o boot SDA e SCL trocados, ou fora das colunas SDA e SCL, num periférico I²C Recupere o aparelho (capítulo 18) e grave os pinos pela tabela do I²C (capítulo 2)
Dois BME280 mostram sempre os mesmos valores Os dois estão em pares do mesmo periférico I²C Mova um deles para um par do outro periférico, ou para um par cruzado (capítulo 2)
O log de eventos mostra BME in bit-bang (pins have no hardware I2C) SDA e SCL em periféricos diferentes Normal: o sensor é lido pelo PIO. Para usar o periférico, mova-o para um par da tabela
A página recusa o slot com GP… already used by slot … Dois sensores no mesmo GPIO Dê a cada sensor o seu GPIO; cada BME280 precisa do próprio par
air Os sensores do Air não respondem depois do sono A chave de energia no GP16 atrasa ou não liga os sensores Confira o circuito do GP16 (capítulo 2)
air O Air nunca hiberna O GP17 está em nível alto: o aparelho acha que o carregador está ligado Confira o divisor do carregador, ou desligue a função com air charger off (capítulo 19)
A unidade RPI-RP2 não aparece O botão BOOTSEL foi solto antes de ligar o cabo, ou o cabo só carrega e não transmite dados Repita segurando o botão até o cabo estar ligado; troque o cabo (capítulo 3)
O .bin copiado para RPI-RP2 não faz nada A unidade do BOOTSEL só aceita .uf2 Copie o .uf2 da mesma imagem
Depois de gravar, o painel ou o LCD fica apagado Imagem de outro tipo Grave pelo USB a imagem do seu hardware (capítulo 3)
O painel e a interface web estão em inglês Não há pacote de idioma na pasta /lang, ou ele foi enviado e o aparelho não reiniciou Envie language_pt-BR.lng pela página Arquivos e reinicie (capítulo 3)
O aparelho ficou em espanhol Os dois pacotes estão na pasta /lang; o es-ES vem primeiro em ordem alfabética Apague language_es-ES.lng e reinicie
Alguns textos ficaram em inglês depois de atualizar O pacote de idioma é de uma versão anterior Envie o pacote da versão nova e reinicie
O histórico e a configuração sumiram depois de gravar os arquivos da pasta data/ O uploadfs reformata o sistema de arquivos Restaure o último backup (capítulo 17); não use o uploadfs num aparelho em uso
A compilação falha no framework (enableKeepAlive) O patch.sh não foi aplicado depois de instalar o framework Rode bash tools/arduino_pico_overrides/patch.sh e compile de novo (capítulo 3)
Um aparelho 1.x voltou com a configuração de fábrica depois da atualização O firmware 2.x não lê configurações das versões 1.x Pegue a senha nova no console USB e configure de novo (capítulo 4)
O histórico de um aparelho 1.x sumiu depois da atualização Os arquivos .sim4 são apagados no primeiro boot Converta cópias baixadas antes com tools/history_v5.py --convert-v4 e envie os .h5 para /history
air A porta serial do Air some e o toque de 1200 baud não funciona O Air dorme e solta o USB Grave com o Air acordado, em M0, ou pelo botão BOOTSEL
A senha do admin não apareceu no console O programa serial abriu depois da moldura, ou o aparelho já reiniciou uma vez Rode system admin reset confirm pelo cabo USB (capítulo 4)
O console da release não mostra nada O console de emergência só mostra o prompt depois de uma tecla Enter Tecle Enter (capítulo 14)
O aparelho novo não abre o ponto de acesso de configuração O ponto de acesso só abre a pedido Abra-o com o comando ap no console ou, na release, pelo item 8 do menu do painel (capítulo 4)
release O painel abre a tela Data e hora no fim do boot Aparelho sem rede configurada, com o relógio provisório Acerte a data e a hora e toque em SALVAR, ou toque em PULAR (capítulo 10)
O console escreve Sem rede, relogio provisorio: conf time AAAA-MM-DD HH:MM:SS no fim do boot Aparelho sem rede configurada, com o relógio provisório Responda com conf time e a data e a hora locais, pelo console USB ou pelo Bluetooth; na release, o painel também serve (capítulo 10)
O aparelho novo não mostra leituras nem grava histórico Da v2.7.1 à v2.8.0: o ponto de acesso de configuração abria sozinho no boot, e com ele aberto essas versões não medem Atualize o firmware, ou ponha o aparelho na rede (capítulo 4)
O painel fica na tela de boot com AP Ativo! Reinicie a placa para sair. O ponto de acesso está aberto, pelo gesto no boot, pelo menu ou pelo comando ap Configure a rede pelo ponto de acesso; o painel sai dessa tela no reinício
alpha O LCD fica parado em SIMUT e na versão, com a barra cheia Da v2.7.1 à v2.8.0: pelo código dessas versões, o LCD não mostra as páginas do ponto de acesso que elas abriam sozinhas no boot Atualize o firmware. Até lá, pegue a rede e a chave no console USB ou com o comando ap (capítulo 4)
A rede SIMUT_SETUP não aparece no celular A rede real tem o nome do aparelho em minúsculas, simut_SETUP de fábrica Procure pelo nome que o console ou a última linha do painel mostra
O celular não entra na rede do ponto de acesso Chave errada Confira a chave na linha [AP] PSK do console; ela usa só letras maiúsculas e algarismos
system ssid Minha Rede gravou só Minha O console grava só até o primeiro espaço Grave a rede pela página Rede, pelo ponto de acesso (capítulo 4)
O aparelho não entrou na rede gravada pelo ponto de acesso A senha da rede está errada ou a rede está fora de alcance. O ponto de acesso não volta sozinho; da v2.7.1 à v2.8.0, voltava cerca de 6 a 7 min depois do boot Abra o ponto de acesso de novo e refaça a configuração (capítulo 9)
A página Rede mostra Desconectado, embora a interface abra pelo IP O NTP está ligado e nenhum servidor de hora responde Aponte um servidor de hora da rede ou acerte o relógio à mão (capítulo 10)
http://simut.local não abre Imagem alpha ou Air, ou aparelho esperando o primeiro acerto do relógio Use o endereço IP (capítulo 4)
O painel e a web continuam em inglês depois de enviar o pacote O aparelho não reiniciou: o pacote só é lido no boot Reinicie o aparelho
A página só pede uma senha nova e não deixa ir a outra página Troca obrigatória da senha de fábrica Defina a senha nova (capítulo 13)
O PIN 1234 abre a tela Novo PIN em vez do menu Troca obrigatória do PIN de fábrica Defina o PIN novo (capítulo 8)
air O Air some do USB depois de alguns minutos Sem atividade por 5 min, ele começa a hibernar Religue o aparelho ou ligue o carregador para ele ficar acordado (capítulo 19)

Rede, Wi-Fi e ponto de acesso

Detalhes no capítulo 9.

Sintoma Causa provável O que fazer
A rede não aparece em Buscar Rede de 5 GHz, rede oculta ou sinal fora de alcance O aparelho só opera em 2,4 GHz. Para rede oculta, digite o nome no campo SSID
Rádio ocupado — tente de novo em instantes O aparelho está buscando a própria rede para se reconectar Espere alguns segundos e toque de novo em Buscar
A gravação recusa net.pass A senha da rede tem mais de 31 caracteres, ou tem caractere de controle Use uma senha de até 31 caracteres na rede dos aparelhos
O aparelho não entra na rede depois de trocar o roteador ou a senha Rede configurada errada. O AP não abre sozinho Abra o AP pelo comando ap no console ou pelo item 8 do menu do painel, e configure a rede pelo AP; ou grave a rede pelo console (capítulo 18)
Da v2.7.1 à v2.8.0: o aparelho sumiu da rede e só voltou mais de uma hora depois, pelo AP Ele tinha IP e perdeu a rede; nessas versões, o AP abria sozinho ao fim de uma volta da escada (~68 min) Atualize o firmware: o AP não abre mais sozinho
O AP some sozinho depois de 15 min AP aberto com o aparelho em operação e rede configurada: o aparelho reinicia depois de 15 min para tentar a rede de novo Grave a rede nova antes dos 15 min. Se a rede continuar fora, abra o AP de novo
Não sei a chave do AP A chave é derivada do chip e não muda Veja no console serial ao abrir o AP, na tela de boot do painel ou na resposta do comando ap
http://<nome>.local não abre Imagem alpha ou Air (sem mDNS), aparelho ainda sem terminar de entrar na rede, ou rede que bloqueia mDNS Use o IP. Com o NTP ligado e sem servidor NTP alcançável, o aparelho não termina de entrar na rede (capítulo 10)
Status mostra Desconectado com um IP na linha de baixo O aparelho ainda espera o primeiro acerto do relógio pelo NTP Libere o acesso a um servidor NTP, aponte um servidor local, ou desligue o NTP e acerte o relógio à mão (capítulo 10)
Depois de mudar a Porta HTTP, a interface não abre O endereço sem porta aponta para a porta antiga Acrescente :<porta> ao endereço
Com IP fixo, o aparelho não acha servidores por nome DNS automático ligado com IP fixo: o secundário não vale, e o primário pode ser o de fábrica Desligue Obter DNS automaticamente (DHCP) e preencha DNS Primário
Depois de instalar o certificado, o endereço http:// parou Com certificado, o aparelho só atende HTTPS Use https://, na 443 se a porta for 80
/api/tls responde empty body O curl enviou o corpo como formulário Acrescente -H 'Content-Type: application/x-pem-file'
/api/tls responde the key does not belong to this certificate Chave e certificado de pares diferentes Envie a chave gerada junto com aquele certificado
/api/tls responde Forbidden — admin only A conta não é administrador completo Use a conta admin ou outra com todas as permissões
Instalei o par e o aparelho continua em HTTP O par só vale no próximo boot, ou o aparelho ligou já no AP Reinicie fora do AP. Veja no log o evento 576
A interface HTTPS ficou inalcançável Par que carrega mas cuja negociação falha No console, system https off confirm
Depois de desligar o HTTPS, a entrada volta sempre para a página de entrada Cookie Secure antigo no navegador Siga o aviso da página de entrada (capítulo 13)
O gestor de frota não consegue falar com o aparelho CORS desligado, origem diferente da página, ou falta reiniciar system cors <origem exata, sem barra no fim> e reload confirm. Confira o evento 577 no boot
O aparelho reconecta sozinho de tempos em tempos com sinal bom O rádio devolveu leituras de sinal impossíveis Normal: é a proteção contra rádio travado. Se for frequente, verifique a alimentação e a distância do roteador
O aparelho reiniciou sozinho, e o log mostra Conectando WiFi (10) com contexto 3 logo antes O rádio recusou três pedidos de conexão seguidos Normal: o reinício recupera o rádio (capítulo 9). Se repetir a cada meia hora, desligue e religue a alimentação, e confira o sinal
A telemetria para com o sinal fraco Abaixo de −78 dBm a telemetria espera Melhore o sinal: aproxime o roteador ou use um repetidor

Data e hora

Detalhes no capítulo 10.

Sintoma Causa provável O que fazer
A página Rede mostra Desconectado com IP, e a telemetria não sai NTP ligado sem servidor alcançável: o aparelho espera o primeiro acerto Libere a porta UDP 123, aponte um servidor NTP da rede local, ou desligue o NTP e acerte o relógio à mão
O log mostra NTP fallback: <servidor> -> pool.ntp.org O servidor configurado não respondeu três vezes seguidas Confira o nome, o DNS e o firewall. A troca vale até o próximo reinício
A hora do painel está atrasada depois de uma falta de energia, com o NTP desligado O relógio provisório parte do último registro e não conta o tempo desligado Acerte o relógio depois de cada reinício, pela seção Data e Hora da web, pelo item 4 do menu do painel ou com time no console, ou ligue o NTP
A data e a hora da barra de cima do painel estão em âmbar, com ? no lugar do - O relógio em uso é o provisório: nem o NTP nem uma pessoa o acertaram desde o boot Acerte o relógio ou ponha o aparelho numa rede com NTP. O primeiro acerto corrige a hora dos blocos que o boot começou (capítulo 10)
O log mostra NTP corrigindo timestamps com uma correção grande O aparelho ficou desligado por esse tempo, ou o relógio provisório estava errado Normal depois de uma falta de energia. Com o aparelho sempre ligado, investigue os eventos 524 anteriores
A hora do painel é diferente da hora do Painel de Controle na web A web mostra no fuso do computador; o painel, no fuso do aparelho Confira o Fuso Horário do aparelho e o do computador
A hora mudou em horas inteiras sozinha e voltou depois de um reinício Até a v2.9.0, digitar no campo Fuso Horário e desistir deixava o fuso digitado em uso: o ensaio o aplicava Reinicie o aparelho para voltar ao fuso gravado. Desde a v2.10.0, isso não acontece
A hora está errada em exatamente 1 h numa região com horário de verão O aparelho não tem horário de verão Ajuste o Fuso Horário nas datas de troca
O fuso da minha região tem meia hora (+5:30, −3:30) O aparelho só aceita horas inteiras Use a hora inteira mais próxima e leve a diferença em conta ao ler os dados
Medições gravadas antes de um acerto manual ficaram com a hora errada Até a v2.8.0, o acerto manual não corrigia o histórico. Hoje só o primeiro acerto depois do boot corrige, e só os blocos que o boot começou Acerte logo depois de ligar, com a hora certa já no primeiro acerto. Confira no log os eventos 408 e 409 (capítulo 10)
time ou conf time responde ERROR: Data ou hora invalida (ano >= 2026) Uma data que o calendário não tem, como 31/02, ou um ano fora de 2026 a 2099 Confira o dia e o mês (capítulo 10)
Aplicar Agora mostra Falhou ao aplicar. Data anterior a 2020 ou conta sem a permissão Sistema Confira a data e a conta
O LCD do alpha não mostra a hora O LCD não tem relógio Veja a hora na interface web

Contas, senhas e PIN

Detalhes no capítulo 8.

Sintoma Causa provável O que fazer
A conta criada pela web não aparece depois do reinício Recusada: nome repetido ou inválido, permissão que a sua conta não tem, tabela cheia Confira o nome e as permissões; crie de novo com uma conta que tenha todas as permissões pedidas
Não consigo mudar as permissões de uma conta na página Usuários A página não edita permissões Exclua e recrie a conta na mesma gravação (exclusão primeiro); as de painel mudam no item Usuários do painel
Perdi a senha de uso único antes de copiar Ela aparece uma vez só Toque em Reset na conta e grave de novo
A conta viewer não entra A senha inicial dela não é informada Toque em Reset na conta viewer e use a senha de uso único
Entro na web e vejo só Access Denied A conta não tem a permissão Painel Digite o endereço de uma página permitida, ou recrie a conta com Painel
Backup e atualização de firmware recusados para uma conta com todas as permissões Essas ações exigem o nível de administrador completo Use a conta admin
Minha conta não aparece em Quem está usando o painel? A conta não tem PIN Defina um PIN pelo botão PIN da página Usuários ou no item Usuários do painel
O painel pede Novo PIN logo depois de um PIN definido pela web O PIN é mais curto que o mínimo da política; a web aceita 4 a 8 dígitos sem olhar a política Escolha um PIN que siga a política. Até a v2.11.0, o painel recusava esse PIN com PIN muito curto (mín. 4)
Um PIN antigo não pode mais ser digitado depois de mudar a política A política tirou as letras dos cartões, ou o teto ficou menor que o PIN Defina um PIN novo para a conta no item Usuários do painel, na página Usuários ou no console
PIN já em uso! Outra conta tem esse PIN Escolha outro PIN
Conta aparece com bloqueado no painel Seis PINs errados seguidos dessa conta Reinicie o aparelho ou use outra conta
Tela vermelha ACESSO BLOQUEADO 20 PINs errados desde a última entrada certa Reinicie o aparelho
Contagem Aguarde N segundos… no teclado Terceira, quarta ou quinta tentativa errada de uma conta Espere; a espera vale para qualquer conta nesse período
O painel pede Novo PIN logo depois de entrar PIN de fábrica 1234 do admin, ou política de PIN mais exigente Escolha um PIN novo que atenda à política
Depois de mudar a política pela web, a mudança não valeu A política pela web só vale depois de Salvar e reiniciar Grave com Salvar e reiniciar, ou mude no painel, que aplica na hora
Operador conseguiu se dar permissões de painel No painel, quem tem Usuários concede as três permissões de painel sem ter todas Dê Usuários só a quem pode ter também as permissões de painel
Bloqueio de 300 s ao entrar pela web Nove ou mais senhas erradas seguidas a partir do mesmo computador Espere a contagem; ela zera numa entrada certa
Limite de sessões atingido. Tente mais tarde. Três outras contas com sessão aberta Feche uma sessão com Sair ou espere 15 min de ociosidade dela

Configuração pela web

Detalhes no capítulo 5.

Sintoma Causa provável O que fazer
Só aparece Salvar e reiniciar, com o selo Alterações não salvas O ensaio ainda não respondeu, ou o conjunto inclui slots de sensor ou calibração, que não podem ser ensaiados. No Air, é sempre assim Espere um segundo. Se continuar, a alteração só se grava reiniciando
O selo mostra Não exige reinício, mas Aplicar agora reiniciou o aparelho Até a v2.9.0, o ensaio não enxergava os campos da área de extensão (intervalo do histórico, NTP, syslog, Home Assistant, DNS automático ou secundário, conexões persistentes) Nada a corrigir: a alteração foi gravada. Desde a v2.10.0, o selo mostra Reinicia por: web
Testar diz que aplicou, mas nada mudou Até a v2.9.0, Testar não aplicava os campos da área de extensão Use Salvar e reiniciar. Desde a v2.10.0, esses campos nem oferecem Testar
Um valor alterado voltou ao anterior depois de Salvar e reiniciar O valor estava fora da faixa e o aparelho o recusou; esse botão não mostra Campos não aplicados Confira a faixa do campo neste capítulo e grave de novo com um valor válido
Falha ao salvar. — Forbidden (net) (ou outra seção) A conta não tem a permissão daquela seção, e a gravação inteira foi recusada Peça a permissão, ou descarte as alterações daquela página (Sair e entrar de novo)
Falha ao salvar. — Display in use. Retry shortly. Alguém tocou no painel há menos de 5 s Espere alguns segundos e toque de novo no botão
Falha ao salvar. — Password change required A conta está com troca de senha pendente Troque a senha (capítulo 13) e grave de novo
Falha ao salvar. — Bad payload O conjunto preparado passou de 6.144 bytes Grave em partes, uma página por vez
A barra de gravação apareceu sem você alterar nada que importe Os campos Data ou Hora da seção Data e Hora foram mexidos Use o Aplicar Agora da seção para acertar o relógio. Para limpar a barra, Sair e entrar de novo
A página Configurações abre com os campos cinza e a faixa vermelha A página não conseguiu ler a configuração do aparelho Toque em Tentar novamente. Se persistir, verifique a rede e o log de eventos
Registro Local desligado, mas o log de eventos continua sendo gravado A preferência não é consultada nesta versão Nada a fazer; o log de eventos não tem interruptor pela web
Baixar a Resolução DS18B20 não deixou a leitura mais rápida O aparelho espera 750 ms por leitura em qualquer resolução Deixe em 12 bits, a mais precisa
Os campos da política de PIN não aparecem A imagem não tem painel de toque (alpha ou Air) Normal: a política só existe na imagem release
A seção Calibração do Touch não aparece em Configurações Imagem alpha ou Air, sem painel de toque Normal desde a v2.7.4: a seção só existe na imagem release

Sensores e calibração

Detalhes no capítulo 6.

Sintoma Causa provável O que fazer
Falha ao salvar. — slot N: hardware ID cannot be empty on an active slot Slot ativado sem ID de Hardware Preencha o ID (letras, dígitos, _, -, até 15) e grave de novo
Falha ao salvar. — slot N: GPx already used by slot M Dois slots ativos no mesmo GPIO Mude o GPIO de um deles, ou libere o outro slot na mesma gravação
Sensor novo não aparece no painel nem na página A gravação não foi com Salvar e reiniciar, ou o slot não está Ativo Abra o editor, confira Ativo e grave com Salvar e reiniciar
Log 105 Divergência de hardware num DS18B20 Outra sonda foi ligada ao pino de um slot com ROM gravada Volte a sonda certa (a quarentena acaba sozinha) ou use Adotar a sonda ligada aqui e reinicie
Adotar a sonda leu o pino errado ou respondeu Nenhuma sonda respondeu neste GPIO. A adoção lê o GPIO de mesmo número que o slot Libere o slot e crie-o de novo no GPIO certo; a ROM é lida na partida
Log 999 Erro desconhecido com um BME280/BMP280 Falha de leitura I²C, ou temperatura fora de −40 a 85 °C Confira SDA/SCL, a alimentação e se há mais de 2 sensores no mesmo par
BME280 não aparece em Procurar sondas A busca só procura BMx280 em GP4/GP5 Configure o slot à mão com os pinos usados
Umidade ou pressão somem de um BME280 Valor fora de 0–100 % ou 300–1.100 hPa, descartado Confira o sensor; um BMP280 não tem umidade
Amostra (ms) não muda o ritmo de leitura O campo não tem efeito na v2.7.1 O ritmo é fixo por tipo (1 s, 2 s, 5 s)
Resolução DS18B20 não muda uma das sondas A resolução só vai ao primeiro slot DS18B20 ativo Nenhuma ação na v2.7.1; o ajuste não afeta o tempo de leitura
Mudar Intervalo Histórico com Aplicar agora reiniciou o aparelho O campo exige reinício, e até a v2.9.0 a classificação prévia não o via Use Salvar e reiniciar para este campo. Desde a v2.10.0, só esse botão aparece
Editor sem o bloco Calibração Conta sem a permissão Calibração, ou slot novo ainda não gravado Peça a permissão; grave o slot antes de calibrar
Erro na calibração: NTP not synced O relógio não foi acertado, nem por NTP nem à mão Acerte o relógio (capítulo 10) e grave de novo
Erro na calibração: rate limited Duas gravações de calibração em menos de 5 s Espere 5 s e grave de novo
Correções sumiram depois de atualizar o firmware A atualização apaga o calib.csv Restaure o backup .bkp baixado antes da atualização
Envio de calib.csv pela página Arquivos não muda nada O VERSION do arquivo enviado não é maior que o atual Aumente o número da linha VERSION, e envie de novo

Alarmes e sons

Detalhes no capítulo 7.

Sintoma Causa provável O que fazer
Desliguei os alarmes do sensor e a cigarra continua O alarme ativo é de falha, que não se desliga pela chave Resolva a falha, use Desativar na tela de alarme ou abra uma janela de manutenção
Desativar mostra Sem permissão A conta do PIN não tem Bloqueio (painel) Use outra conta ou peça a permissão a quem gerencia usuários
Linha do menu do sensor apagada, com cadeado A conta não tem a permissão daquela linha Peça a permissão: Limites (painel), Bloqueio (painel) ou Manut. (painel)
Item Limites de Alarme não aparece no menu do painel A conta não tem nenhuma das três permissões de painel Conceda pelo menos uma na página Usuários ou no item Usuários do painel
Falha ao salvar. — Alarm limit outside channel range Um limite fora da faixa plausível da grandeza Corrija o valor; a gravação inteira foi recusada
Falha ao salvar. — Alarm limit is not a number Um cliente da API mandou um limite que não é número Mande números, ou null para manter um limite; a gravação inteira foi recusada
Mudei um som na página e o aparelho mudou antes de gravar Até a v2.9.0, a consulta prévia da página aplicava os sons na memória Grave ou descarte a mudança; um reinício volta ao que está gravado. Desde a v2.10.0, isso não acontece
Mudança de som pela web pede Salvar e reiniciar Os sons ficam numa área da configuração que exige reinício Use Salvar e reiniciar; pelo painel, a mudança vale sem reiniciar
Alarme novo não tocou Estava dentro de um silêncio de 120 s, que vale para todos os sensores Espere o fim do silêncio; a cigarra volta se o alarme persistir
Imagem alpha: cigarra toca sem parar O alpha não tem como silenciar no aparelho Desligue os alarmes do sensor em Alarmes e Sons ou ligue Mudo Global, e corrija a causa
Janela de manutenção não inicia pelo painel 0 h e 0 min, ou conta sem Manut. (painel) Ajuste pelo menos 5 min; use uma conta com a permissão
A janela terminou antes do esperado O pedido passava de 30 dias e foi cortado, ou alguém tocou em FECHAR Confira o log (códigos 454 e 455) e a lista rejected da resposta do servidor
Limite mudado pela web não aparece no servidor de alarmes Só mudanças feitas no painel geram alarm_lim Consulte /api/alarms ou mude pelo painel quando precisar do registro

Painel

Detalhes no capítulo 11.

Sintoma Causa provável O que fazer
A tela inicial não responde ao toque e a barra de cima mostra WEB '...' - toque bloqueado Alguém lê o histórico ou o log pela interface web Espere a operação terminar; o aviso some sozinho
O painel desenha normalmente, mas não responde a nenhum toque, até reiniciar Até a v2.8.0: o toque só era lido quando a interrupção dele avisava, e uma interrupção perdida deixava o toque morto Reinicie. Nas versões seguintes o aparelho lê o toque também sem a interrupção e grava Evento de toque (200) uma vez por boot: anote o contexto e relate (capítulo 16)
O toque cai no lugar errado ou só funciona com força Calibração do toque ruim ou descartada pelo alinhamento da tela Configurações > Calibrar Touch; se não alcançar o menu, comece a calibração pela página Configurações da web ou pelo console
A calibração volta sempre para a primeira mira Toques imprecisos! Tente novamente.: as duas voltas discordam Segure cada mira até ela ficar verde e toque no centro dela, com a mesma pressão
A borda da imagem aparece cortada de um lado Painel com a imagem deslocada Alinhamento da Tela, ajuste, APLICAR e refaça a calibração que abre em seguida
O menu mostra poucos itens A conta identificada não tem as permissões dos outros itens Entre com outra conta, ou dê as permissões pela página Usuários
O toque no cartão abre a tela de alarme em vez do mínimo e máximo O sensor está em alarme sem silêncio Use Min/Max na tela de alarme, ou silencie
O gesto de 3 s no cartão de cima não faz nada O sensor do cartão de cima está em alarme sem silêncio, ou o dedo escorregou e o toque recomeçou Silencie o alarme; mantenha o dedo parado por 3 s
O botão de gráfico não abre o gráfico O sensor está num slot de 11 a 15 Use a página Histórico e Logs da web para esses slots
O gráfico abre sempre no mesmo período antigo, até o Hoje do calendário A janela ficou presa depois de navegar no tempo (código da v2.7.1) Toque na seta para a esquerda e depois na seta para a direita até ela apagar; ou reinicie
Mínimo e máximo do cartão incluem valores de ontem Eles não zeram à meia-noite; contam desde o dia em que o aparelho ligou Reinicie para recomeçar a contagem
Mínimo e máximo do cartão não acompanham as leituras O GPIO do sensor difere do número do slot (código da v2.7.1) Um reinício relê os valores do histórico. Onde der, ponha o sensor no slot de mesmo número do GPIO
Fails sempre 0 no Status do Sistema O campo não é preenchido na v2.7.1 Veja as falhas na página Telemetria ou no log de eventos
No boot, o celular não acha a rede SIMUT_SETUP O nome real da rede é o nome do aparelho seguido de _SETUP Procure <nome>_SETUP, como simut_SETUP; o nome aparece numa das últimas linhas da caixa de boot
O gesto do AP no boot não pega O dedo encostou antes da linha Mantenha a tela pressionada ou saiu antes de 3 s Encoste depois da linha aparecer, em até 3,5 s, e mantenha até a barra encher
Com o AP aberto, as leituras param e o CFG não abre nada Com o AP aberto, o aparelho não mede nem atende o painel (v2.7.1) Configure a rede pelo AP e deixe o aparelho reiniciar
O painel voltou sozinho à tela inicial e o tema escolhido não ficou 30 s sem toque antes de APLICAR Escolha de novo e toque em APLICAR

LCD do alpha

Detalhes no capítulo 12.

Sintoma Causa provável O que fazer
O LCD mostra ERRO fixo Nenhum slot ativo Configure um sensor pela interface web (capítulo 6)
ERRO aparece na vez de um sensor O sensor não está lendo Confira a ligação; o slot aparece no canto de baixo quando há mais de um sensor
O ícone de Wi-Fi é um X Sem conexão ou sinal abaixo de −90 dBm Aproxime o aparelho do roteador ou confira a rede (capítulo 9)
O ícone mostra sinal cheio com sinal fraco Na v2.7.1, o nível mais baixo é uma linha na largura toda Leia a altura do ícone, não a largura; a main já desenha a escada
O fim do boot mostra Sem WiFi / Offline Rede ausente ou senha errada Veja a escada de reconexão (capítulo 9)
O celular não conecta ao AP Chave digitada errada, ou rede errada Confira a chave caractere a caractere, como o console a mostra, e a rede <nome>_SETUP
Com o AP aberto, o LCD fica na barra de boot cheia, ou nas leituras paradas Na v2.7.1 o LCD não passa às páginas do AP (leitura do código) Leia o nome da rede e a chave no console USB, ou na resposta do comando ap, também pelo Bluetooth (capítulo 14)
A cigarra toca e o LCD não mostra alarme O LCD não mostra alarmes de limite Veja os valores no ciclo; use a linha de alarmes ou a web para identificar o sensor
Os pendentes não aparecem Mais de um sensor ativo, nenhum pendente, ou imagem v2.7.1 Veja o Painel de Controle da web

Console e Bluetooth

Detalhes no capítulo 14.

Sintoma Causa provável O que fazer
O terminal abre e não aparece nada Na release, o console não mostra cabeçalho Tecle Enter: aparece SIMUT>
Cada letra aparece duas vezes Eco local do terminal ligado; o aparelho já ecoa Desligue o eco local
A porta /dev/ttyACM0 não abre no Linux O usuário não pertence ao grupo da porta Inclua o usuário no grupo dialout (ou uucp) e entre de novo
Comando desconhecido. As configuracoes ficam na interface web... O comando só existe no console completo, ou foi digitado errado Veja help; configure pela web
language en responde “Comando desconhecido” O console de emergência não tem language, embora o cabeçalho o sugira Troque o idioma do aparelho pela web e reinicie
system ssid Minha Rede grava só Minha O console corta o argumento no primeiro espaço Use a interface web ou o AP de configuração
O aparelho não conecta depois de system ssid e system pass A rede nova só vale depois de reiniciar reload confirm
ERROR: CLI ocupada (display em uso). Comando descartado. Alguém tocou no painel há menos de 5 s Digite o comando de novo
O aparelho não aparece na busca Bluetooth A janela de descoberta fecha 5 min depois do boot Reinicie e pareie logo em seguida
O Bluetooth conecta mas não pede senha O pedido só sai depois do primeiro caractere Tecle Enter
Bloqueado. Tente mais tarde. Senhas erradas seguidas; o bloqueio chega a 300 s e sobrevive à reconexão Espere o prazo e use a senha do admin da web
ERROR: Comando so pela USB (cabo serial). system factory, format, admin reset e https off são recusados pelo Bluetooth Use o cabo USB
A sessão Bluetooth termina sozinha 5 min sem digitar, ou a conexão caiu Tecle Enter e digite a senha de novo
debug continua ligado depois de reiniciar Outro comando ou a web gravou a configuração com o debug ligado debug off e grave de novo
No console completo, a alteração sumiu depois de reiniciar Faltou write memory Grave com write memory (ou do write memory dentro da configuração)
Comando requer modo privilegiado. Use 'enable'. dentro da configuração O comando é do privilegiado, como sensor 3 name x ou write memory Use do <comando>, end, ou o modo sensor
conf sensor ds18b20 resolution 12 falha A forma do texto de help está errada Use ds18b20 resolution 12 na configuração
air stop pelo Bluetooth não tem efeito Durante um despertar, o Air só lê o USB Use o USB, ou ligue o carregador para o Air ficar acordado
system format deixou a interface em inglês O formato apagou o pacote de idioma Reinstale o pacote (capítulo 17)

Histórico

Detalhes no capítulo 15.

Sintoma Causa provável O que fazer
O gráfico mostra Sem dados. para um dia destacado no calendário A conta não tem a permissão Leitura, e a página não consegue baixar os arquivos do dia Dê à conta Histórico e Leitura juntas
O gráfico mostra Sem dados. para o período escolhido Nenhum registro dos sensores marcados na janela Escolha outro período, outro dia no calendário ou outros sensores em Origem:
Aparece o aviso Parcial: N perdidas N arquivos de dia não chegaram depois de 3 tentativas, ou você tocou em Cancelar Toque de novo no período. Se persistir, confira a rede e o log de eventos
Os dias mais antigos sumiram do calendário A ocupação passou de 86 % e o aparelho apagou os dias mais antigos Exporte ou mantenha um coletor de telemetria. Libere espaço removendo arquivos enviados pela página Arquivos
Há um buraco no gráfico depois de uma falta de energia O aparelho ficou desligado; a falta em si perde no máximo o último registro Nada a fazer. Confira no log de eventos o boot e a correção de horas
Um sensor renomeado aparece com o nome novo nos dias anteriores A página rotula os dados do slot com o nome e o ID atuais Comportamento esperado. O arquivo guarda o slot, não o nome
Os dados de um slot removido não aparecem na página A página só mostra os slots configurados agora Leia os arquivos .h5 com tools/history_v5.py --dump-csv
Arquivos que coloquei em /history sumiram depois de reiniciar O boot apaga de /history tudo o que não é .h5 Guarde-os em outra pasta
O histórico sumiu depois de atualizar o firmware A atualização reformata o sistema de arquivos Restaure o .bkp baixado antes da atualização (capítulo 17)
As horas do CSV diferem das do painel A página usa o fuso do computador; o painel, o do aparelho Use um computador no mesmo fuso do aparelho
Depois de mudar o Intervalo Histórico, os dias antigos aparecem com os pontos espalhados A página decodifica todos os arquivos com o intervalo atual Leia os arquivos antigos com history_v5.py --interval igual ao intervalo da época
As horas saem erradas no history_v5.py O --interval não é o Intervalo Histórico do aparelho Passe o intervalo em segundos, como --interval 300 para 5 min
A planilha junta tudo numa coluna só O CSV usa vírgula como separador e ponto como decimal Importe indicando a vírgula como separador e o ponto como decimal

Log de eventos

Detalhes no capítulo 16.

Sintoma Causa provável O que fazer
A tabela de eventos mostra poucas linhas, só erros De entrada, só a caixa ERR vem marcada Marque INF e WRN
A tabela mostra Error fetching logs Alguém estava usando o painel, ou a conta não tem a permissão Logs Espere alguns segundos e toque em Atualizar. Confira as permissões da conta
Eventos de telemetria que aparecem no console não estão no log O filtro por transição grava só as mudanças de estado e um registro por hora Comportamento esperado. Veja Registros de rotina suprimidos (5) e use debug on ou o syslog para ver tudo
O log só vai até alguns dias atrás O log guarda de 800 a 1.600 registros; os mais antigos saem Envie o log a um coletor syslog para guardá-lo por mais tempo
Um registro FTL aparece com a data Boot + A autópsia roda antes de o relógio ter hora Situe o travamento pela data dos registros vizinhos
Vários Boot do sistema com FTL e contextos 200 a 229 Travamentos do núcleo 0 detectados pelo watchdog Anote o módulo (contexto − 200) e os registros irmãos, exporte o log e veja Quando relatar um defeito
A coluna uptime_sec do CSV diz undefined Defeito da página na exportação do log Use a coluna Tempo da tabela ou o show system log
Limpar responde Falha ao limpar logs. A conta não tem Logs e Sistema juntas, ou tem uma troca de senha pendente Use uma conta com as duas permissões e troque a senha pendente
Os nomes dos eventos aparecem sem acento A página usa uma tabela própria, sem acentos Comportamento esperado
Os nomes dos eventos aparecem em inglês O idioma da página está em EN Troque o idioma para PT no seletor da gaveta
O console mostra log entries dropped (buffer full) Mais de 32 eventos chegaram enquanto o painel estava em uso ou uma operação pesada rodava Os excedentes não foram para a flash. Nada a fazer, a não ser que se repita
air O log do Air quase não cresce Num despertar, a sequência de boot não é gravada; sobra um registro por ciclo Comportamento esperado. Procure o Boot frio, não veio da hibernação (412)

Atualização, backup e restauração

Detalhes no capítulo 17.

Sintoma Causa provável O que fazer
Os botões Backup, Restaurar e Firmware não aparecem A conta não é o administrador completo Entre com uma conta que tenha todas as permissões
Falha ao baixar backup. Tente novamente. na etapa 1 O painel estava em uso, outra operação pesada rodava, ou a rede caiu Espere alguns segundos e recomece. Nada mudou no aparelho
Falha no envio (validação v=7). Cancelled. A imagem é de outra variante (release, alpha ou air) Use o .bin da variante do aparelho. Restaure o backup, que devolve os arquivos apagados pela recusa
Este .bin não é assinado, e o aparelho só instala imagem assinada. O arquivo não tem assinatura: um build local, ou um .bin anterior à OTA assinada Use um .bin de release do GitHub ou uma build do configurador. A página recusou antes de enviar: nada mudou no aparelho
Falha no envio (validação v=8) a (validação v=12) A assinatura: imagem sem assinatura (8), alterada ou de chave desconhecida (9), chave aposentada (10), abaixo do nível de segurança instalado (11), chave de bancada (12) Veja o que fazer em cada caso no capítulo 17. Restaure o backup
Falha no envio (validação v=4) O arquivo é pequeno demais para ser uma imagem. Até a v2.7.4, v=5 era a recusa de um arquivo grande demais Confira que escolheu o .bin certo. Restaure o backup
Falha no envio (validação v=6) O arquivo não é uma imagem do RP2040 Use o .bin publicado, não o .uf2 nem outro arquivo. Restaure o backup
Falha no envio (validação v=undefined) O arquivo passa de 1016 KiB, ou o envio caiu Confira o arquivo e a rede. Restaure o backup
Depois de uma recusa ou de um envio cortado, o aparelho reiniciou e voltou sem rede e sem contas Aparelho com a v2.7.4 ou anterior: a recusa reformatou o sistema de arquivos, e a configuração estava só na RAM Pegue a senha pelo console USB, configure a rede e restaure o backup (capítulo 18)
Depois de uma recusa ou de um envio cortado, o aparelho voltou com a rede e as contas, mas sem histórico, idioma e temas Desde a v2.8.0, a configuração volta da cópia guardada no início do envio; os demais arquivos foram apagados pelo envio Restaure o backup que a página baixou antes do envio (capítulo 17)
Aplicação recusada (HTTP 503) O painel estava em uso no instante da aplicação Não reinicie. Repita POST /api/ota/apply com a sessão do administrador
A página de entrada não abre logo depois da atualização O aparelho está gravando a imagem e reiniciando Espere cerca de 1 min e recarregue
O aparelho continua na versão antiga A aplicação não aconteceu Confira a versão na gaveta e o log; refaça a atualização
Depois da atualização, a interface e o painel estão em inglês O pacote de idioma foi apagado com o sistema de arquivos Restaure o backup, ou envie o .lng da versão e reinicie
Depois da atualização, o aparelho responde em HTTP e não em HTTPS O par do HTTPS foi apagado com o sistema de arquivos Restaure o backup ou instale o par de novo (capítulo 9)
Depois da atualização, os sensores leem sem correção O /calib.csv foi apagado Restaure o backup
O log mostra Config alterada (303), módulo OTA, nível ERR, logo depois de atualizar O CRC da imagem gravada não confere Grave a imagem pelo USB (capítulo 18)
O aparelho não liga depois de uma falta de energia durante a atualização O corte caiu na aplicação e o firmware ficou pela metade BOOTSEL e .uf2 pelo USB (capítulo 18)
Validação falhou: chip ID mismatch (backup is from another device) O backup é de outro aparelho Use um backup deste aparelho
A restauração trouxe de volta uma senha antiga do administrador A restauração devolve a configuração da data do backup Troque a senha depois de restaurar
Faltam as medições entre a atualização e a restauração A restauração substituiu o arquivo do dia pela cópia do backup Restaure logo depois de atualizar (capítulo 15)
Falha ao aplicar: I/O error Falha de gravação (até a v2.9.0, também um backup com mais de 200 arquivos) Não reinicie; repita a restauração: os arquivos já gravados ficam, e ela completa o resto
A página diz Upload concluído., mas o arquivo não aparece O aparelho recusou o envio (nome inválido, sem espaço ou destino proibido) Confira o nome, o espaço livre e a pasta
Um pacote de idioma enviado não fez efeito O pacote só é lido no boot Reinicie o aparelho
air A página do Air parou de responder durante a atualização O Air hibernou Ligue o carregador durante a atualização, ou ponha o Air em M0 com air stop
O reset de fábrica deixou o aparelho sem uma senha conhecida A senha aleatória desse reset não é mostrada Rode system admin reset confirm pelo console USB

Recuperação

Detalhes no capítulo 18.

Sintoma Causa provável O que fazer
system admin reset confirm responde ERROR: Comando so pela USB (cabo serial). O comando veio pelo Bluetooth Use o cabo USB
air O console do Air recusa system admin reset O console completo exige o modo privilegiado Rode enable antes
O console mostrou ERROR: NAO SALVOU: vale so ate reiniciar. A gravação da senha nova falhou Rode o comando de novo antes de reiniciar
Não vi a senha inicial no boot O console não estava conectado quando a moldura SEC-003 apareceu Rode system admin reset confirm
O painel mostra ACESSO BLOQUEADO Vinte tentativas de PIN erradas somadas Reinicie o aparelho
O console mostra [AP] FAILED to start O nome do aparelho passa de 26 caracteres, ou o rádio falhou Encurte o nome; reinicie e tente o ap de novo
O celular vê <nome>_SETUP e não conecta Chave errada, ou versão anterior à v2.7.1 Confira a chave no console; atualize para a v2.7.1
O aparelho volta para o AP a cada poucos minutos A rede configurada está errada ou fora de alcance; com o AP no ar, o aparelho não mede Grave a rede certa pelo AP ou pelo console
O aparelho não aparece no USB nem na rede depois de uma atualização O firmware ficou pela metade Grave o .uf2 pelo BOOTSEL
A unidade RPI-RP2 não aparece O botão não estava segurado ao ligar o cabo, ou o cabo só carrega Repita segurando o BOOTSEL; use um cabo de dados
O truque dos 1200 bps não funciona O console USB não existe: firmware pela metade, ou Air dormindo Use o botão BOOTSEL
Depois de gravar pelo BOOTSEL, o aparelho se comporta de forma estranha Restos de uma atualização interrompida na flash picotool erase e grave de novo; depois restaure o backup
O log mostra Falha no storage (20) repetida Sistema de arquivos com problema Baixe o que puder, system format confirm e restaure o backup
air O Air não aparece no USB Está dormindo; o USB some durante o sono Ligue o carregador, ou desligue e ligue a alimentação

SIMUT Air

Detalhes no capítulo 19.

Sintoma Causa provável O que fazer
air O Air não hiberna, com chg=1 no air status O carregador está ligado, ou o pino do carregador lê nível alto Desligue o carregador; sem carregador, confira o divisor ou use air charger off
air O Air não hiberna, com chg=0 Uma aba do Painel de Controle aberta, um gestor de frota consultando sem quiet=1, ou comandos no console Feche a aba; use /api/status?quiet=1 no gestor
air O Air nunca liga o rádio Lote mínimo em 0, pendentes abaixo do Lote mínimo, ou skip maior que 0 Confira tel= e skip= no air status
air O coletor ficou sem dados depois de uma queda dele Um envio que falha reserva 5 despertares sem rádio Normal. Os registros esperam na flash e saem nos envios seguintes
air A interface web do Air não abre O Air está em M1, sem servidor web Ligue o carregador ou desligue e ligue a alimentação
air air stop não tem efeito Foi digitado pelo Bluetooth, ou fora da janela do despertar Use o USB durante um despertar, ou o carregador
air A linha [AIR] alarm: termina com OVERRUN O despertar não cabe no Intervalo Histórico Aumente o intervalo
air O log mostra Ciclo Air retido em M0 (411) Três reinícios pelo vigia seguidos Entre, exporte o log e relate; o Air espera em M0
air O log mostra Wake anterior do Air não completou (414) Um despertar travou e foi reiniciado pelo vigia Guarde o log e relate
air O log mostra Boot frio, não veio da hibernação (412) sem ninguém ter mexido Falta de energia ou reinício Confira a bateria e a alimentação
air As horas dos registros derivam cerca de 1 s por despertar v2.7.1, sem o relógio carregado através do sono Garanta despertares de telemetria para o NTP corrigir
air Baixar a resolução do DS18B20 não encurtou o despertar O firmware espera 750 ms por conversão em qualquer resolução Aumente o Intervalo Histórico para economizar bateria
air Depois de atualizar, o Air voltou a hibernar em 300 s e o carregador voltou ao GP17 A atualização apagou o /config/air.bin Restaure o backup, ou ajuste air idle e air charger de novo
air O nome .local do Air não responde A imagem do Air não tem mDNS Use o IP, visto com show net status
air air charger 16 é recusado O GP16 é o pino de alimentação dos sensores Escolha outro pino

Telemetria e linha de alarmes

Detalhes nos capítulos 20, 21 e 22.

Sintoma Causa provável O que fazer
O coletor recebe dados de “dois aparelhos” que são o mesmo O servidor usa o IP ou o nome como chave Use o cabeçalho X-SIMUT-Uid como chave primária (capítulo 20)
Dois aparelhos configurados igual mostram X-SIMUT-Cfg diferentes A configuração inclui sementes aleatórias das contas Compare o valor de cada aparelho só com o histórico dele mesmo
No MQTT, não dá para saber de que aparelho veio uma mensagem O MQTT não leva cabeçalhos e vários aparelhos usam o mesmo Tópico Dê um Tópico próprio a cada aparelho
Nada chega ao coletor e o sinal está fraco Com o sinal em −78 dBm ou abaixo, o aparelho adia telemetria e linha de alarmes Melhore o sinal (posição, antena, repetidor); os registros ficam na flash e saem depois
O aparelho não aparece na busca mDNS Imagem alpha ou Air, que não anunciam mDNS Use o IP, a lista de clientes DHCP do roteador ou GET /api/status
Medições com hora errada ou fora de ordem no banco Relógio do aparelho sem NTP, ainda na hora provisória Ligue Sincronizar automaticamente via NTP; numa rede fechada, indique um servidor NTP local
Evento 512 no log e a telemetria parada Sem referência de hora, o histórico não grava Corrija a hora ou o acesso ao NTP; o evento 513 marca a volta
O firewall bloqueia o envio A regra abre só a entrada, mas é o aparelho quem conecta Libere a saída do aparelho para o coletor, na porta configurada
Registros Pendentes cresce e nada sai Lote mínimo em 0, ou sinal Wi-Fi em −78 dBm ou abaixo Defina o Lote mínimo; melhore o sinal
Evento 31 com o contexto −1 Servidor, porta ou nome errado; firewall; TLS incompatível Confira IP Servidor e Porta; teste o coletor com curl da mesma rede
Evento 31 com o contexto −11 O coletor leva mais de 4 s para responder Grave mais rápido ou responda assim que gravar
Evento 31 com o contexto 301 ou 302 O coletor redireciona, e o aparelho não segue redirecionamentos Aponte para o endereço final; para HTTPS, ligue o TLS
Evento 31 com o contexto 401 ou 403 Chave de acesso errada ou ausente Confira a API Key e a forma do cabeçalho
Evento 31 com o contexto 404 Endpoint errado Confira o caminho, começando com /
HTTP funciona, HTTPS falha com o contexto −1 O servidor não aceita TLS 1.2 com ECDHE-GCM ou ignora o fragmento de 4.096 bytes Ajuste o servidor: TLS 1.2, ECDHE-GCM e a extensão Maximum Fragment Length
A faixa TLS sem validação de certificado aparece Sem /cert.pem válido Envie o certificado da CA como /cert.pem pela página Arquivos e reinicie
Troquei o /cert.pem e nada mudou O arquivo só é lido ao iniciar Reinicie o aparelho
Mudei servidor ou porta no MQTT com Aplicar agora e continua no antigo O cliente MQTT só lê a porta ao iniciar Use Salvar e reiniciar
MQTT: evento 36 com Bad credentials ou Not authorized Usuário ou Senha errados, ou falta de permissão no broker Confira o usuário, a senha e a lista de acesso do broker
MQTT: nada chega e a porta é 80 A Porta não muda ao trocar o transporte Use 1883 (MQTT) ou 8883 (MQTTS)
O assinante MQTT quebra ao receber um array Depois de uma parada, lotes com mais de 5 registros saem numa mensagem só Aceite objeto e array
O coletor recebe "camara":null Forma simples do marcador, com o sensor sem leitura Use "t0_ID":{t0} ou "t0":{t0} para a chave sumir
JSON inválido no formato Dinâmico Modelo mal escrito; o aparelho não valida Confira a Prévia ao Vivo e o primeiro corpo recebido
O coletor recusa o corpo do formato Dinâmico (evento 31 com o contexto 400 ou 415), embora ele seja válido O Content-Type não é o que o coletor exige. Até a v2.7.4, o Dinâmico mandava sempre text/plain Preencha o Cabeçalho Content-Type da linha com o tipo que o coletor espera (capítulo 21)
Campos não aplicados: t_ct ou a_ct O valor não é um tipo de mídia: falta a barra, tem acento ou passa de 31 caracteres Escreva tipo/subtipo, como application/json
JSON inválido no formato JSON, com filas longas (v2.7.1) Lote grande montado com pouca memória Responda 400 a corpo inválido: o cursor não avança e o lote sai de novo, menor; corrigido na v2.7.2
Medições repetidas no banco Duplicatas por desenho (confirmação perdida, queda de energia, reset do cursor) Grave com chave única (uid, ts, canal)
Buraco nas medições depois de uma parada longa Registros mais de 30 dias antes do mais novo, ou hora fora de ordem Recupere pelo histórico do aparelho
A primeira ativação manda milhares de registros O aparelho começa 30 dias antes do registro mais novo Esperado; prepare o coletor para a carga inicial
Aviso Telemetry cursor ahead of data — reset to 0 O relógio andou para trás e o cursor ficou no futuro Nada a fazer; confira o NTP
Enviar agora diz “Envio disparado”, mas nada chega Sinal fraco, envio já em andamento, ou lote mínimo 0 depois do primeiro lote Confira o evento 546 e os seguintes no log; confira o sinal
Os envios param enquanto alguém usa o painel O painel tem prioridade sobre a telemetria Esperado; os envios voltam 5 s depois do último toque
Só um evento de falha no log, embora o coletor esteja fora há horas O log grava transições e um registro por hora Esperado; o console serial mostra todas as tentativas
Nenhum evento chega Linha desligada, ou IP Servidor vazio na telemetria Ligue Habilitar linha de telemetria de alarmes e confira o servidor
Evento 551 com 404 Caminho errado Confira o Caminho HTTP; vazio, ele vale Endpoint + /alarm
Os mesmos eventos chegam a cada 15 s O coletor não confirma: HTTP fora de 2xx, ou falta a mensagem de confirmação no MQTT Responda 2xx depois de gravar, ou publique {"seq":[...]} em <tópico>/alarm/ack
MQTT: a fila nunca esvazia, embora o coletor confirme Telemetria de medições desligada (Lote mínimo 0): o aparelho não lê as confirmações Ponha o Lote mínimo acima de 0
MQTT: evento 551 com o contexto 0 a cada tentativa A fila não cabe numa mensagem de cerca de 2 KB Use um Tamanho da fila (RAM) de até 16 e confirme rápido; em último caso, reinicie, o que esvazia a fila
MQTT: registros somem da fila sem terem chegado Confirmação retida no broker, ou dois aparelhos com o mesmo Tópico Publique a confirmação sem retenção e apague a retida; dê um Tópico a cada aparelho
MQTT: só parte dos registros sai da fila Confirmação com números entre aspas ou com quebras de linha Publique a lista compacta: {"seq":[1,2,3]}
Evento 553 Fila cheia: o coletor não confirma há tempo Resolva a confirmação; aumente o Tamanho da fila (RAM) se o volume for real
Eventos se perdem depois de uma queda de energia A fila vive na RAM Esperado; confirme rápido para a fila ficar curta
alarm_lim, alarm_on ou alarm_off não chegam quando o limite muda pela web Só as ações feitas no painel geram esses códigos Consulte o estado pela API
Nenhum registro quando o valor volta ao normal A linha não tem código de retorno ao normal Use a telemetria de medições para saber que normalizou
Um novo alarm, err ou maint_on chega depois de um reinício O aparelho refaz o estado das bordas ao iniciar Trate como confirmação de estado, não como evento novo
maint_on e alarm_lim chegam sem until, lo, hi ou user Modelo próprio antigo Acrescente "maint":{maint}, "lo":{lo}, "hi":{hi}, "until":{until} e "user":{user} ao 2. Linha
JSON inválido com "valor":, Marcador fora da forma composta, sem valor naquele registro Use a forma composta, como "val":{val}
O JSON da linha não é o do manual O 2. Linha foi editado e vale também no formato JSON Confira o 2. Linha no formato Dinâmico
A Prévia ao Vivo mostra {maint} ou {user} como texto Até a v2.9.0, a prévia não conhecia os marcadores novos Confira o corpo recebido; desde a v2.10.0 a prévia os monta como o aparelho
Pendentes: não muda O número é lido ao abrir a página Recarregue a página

Home Assistant, Prometheus e syslog

Detalhes nos capítulos 23, 24 e 25.

Sintoma Causa provável O que fazer
O aparelho não aparece no Home Assistant depois de ligar a descoberta O aparelho ainda não conectou ao broker: ele só conecta quando tem algo a enviar Espere o primeiro envio depois do reinício; com Lote mínimo (registros) em 0, ligue a telemetria (capítulo 23)
Nenhum evento 548 no log Formato diferente de JSON, ou o transporte não é MQTT(S) Deixe o Formato em JSON e o Transporte em MQTT(S), e grave com Salvar e reiniciar
Evento 548 aparece, mas nada chega ao Home Assistant A integração MQTT do Home Assistant usa outro broker, outro prefixo ou está com a descoberta desligada Confira o broker e o prefixo homeassistant; assine homeassistant/sensor/# com o mosquitto_sub para ver as mensagens
O dispositivo aparece, mas as entidades ficam sem valor As medições chegam em array (lote de mais de 5 registros) Ponha Lote mínimo (registros) em 1; para a fila atrasada, Lote máximo (registros) em 5 ou menos
As entidades voltam a ter valor só muito depois de uma parada A fila atrasada saiu em lotes maiores que 5, que o Home Assistant não lê Espere a fila acabar, ou use Lote máximo (registros) em 5 ou menos
Uma entidade fica sem valor e as outras não O sensor desse slot está em falha e a chave dele sai do JSON Veja o estado do sensor no Painel de Controle e no capítulo 6
Entidades indisponíveis logo depois de um reinício do aparelho O broker publicou a última vontade offline; o aparelho ainda não reconectou Espere o primeiro envio depois do reinício
No Air, as entidades ficam indisponíveis a maior parte do tempo O despertar termina sem despedida e o broker publica offline quando o Keep-Alive vence Comportamento esperado; aumente o Keep-Alive até 300 s para adiar o offline (capítulo 23)
Entidade antiga, sem valores, depois de remover um slot ou mudar o ID de hardware O aparelho não apaga mensagens de descoberta que não correspondem mais à configuração Apague o tópico com mosquitto_pub -r -n -t 'homeassistant/sensor/<nó>/<objeto>/config' (capítulo 23)
Dois dispositivos para o mesmo aparelho O Client ID mudou, e o nó novo virou outro dispositivo Apague as mensagens retidas do nó antigo com mosquitto_pub -r -n
O dispositivo apagado no Home Assistant volta sozinho A descoberta continua ligada no aparelho, que publica tudo de novo a cada conexão Desligue Home Assistant Discovery no aparelho antes de apagar
Trocou o transporte para HTTP e o dispositivo ficou no Home Assistant, indisponível Sem MQTT, o aparelho não tem como apagar a descoberta Volte ao MQTT, desligue a descoberta, espere o evento 548 e só então troque o transporte; ou apague os tópicos com mosquitto_pub -r -n
O texto do evento 548 diz (skipped N) Chave com aspas ou barra invertida (ID de hardware gravado por versão antiga) ou mensagem de descoberta grande demais Troque o ID de hardware por um só com letras, dígitos, _ e -; encurte nomes muito longos
O link de configuração do Home Assistant não abre a página O link é sempre http://, e o aparelho está em HTTPS Abra https:// com o mesmo endereço
Os gráficos do Home Assistant mostram medições atrasadas todas no mesmo instante O Home Assistant registra a hora da chegada, não o ts do registro Para histórico fiel, receba a telemetria num coletor que use o ts (capítulo 21)
Nada chega ao Home Assistant enquanto o aparelho está com o AP de configuração aberto Com o AP aberto, o aparelho não envia telemetria Resolva a conexão Wi-Fi (capítulo 9)
O alvo aparece como fora do ar e o curl recebe 401 unauthorized Conta ou senha erradas no basic_auth Confira a conta e a senha; teste com curl -u a partir do servidor do Prometheus
O curl recebe 403 forbidden A conta não tem a permissão Painel Dê à conta a permissão Painel na página Usuários (capítulo 8)
O curl recebe 429 com lockSec, mesmo com a senha certa O endereço do servidor está bloqueado por senhas erradas anteriores Espere o lockSec; depois, entre uma vez pela interface web a partir desse servidor para zerar a contagem (capítulo 24)
Depois de corrigir a senha, um único erro bloqueia por 300 s A contagem de erros continua alta: leitura bem-sucedida não a zera Entre uma vez pela interface web a partir do servidor do Prometheus
Operadores bloqueados na página de entrada sem ter errado a senha O Prometheus, com senha errada, divide o bloqueio com eles pelo mesmo endereço ou NAT Corrija a senha no Prometheus; separe o servidor do Prometheus da rede dos operadores
O log de eventos se enche de 301 Falha de login, com contexto 0 Senha errada no Prometheus; o syslog mostra a conta no texto Corrija a senha; cada erro depois do nono grava um evento a cada 300 s, mais ou menos
A interface web fica lenta em intervalos regulares Cada leitura do Prometheus ocupa o aparelho por cerca de 0,7 s para conferir a senha Aumente o scrape_interval para 60 s; não use menos de 15 s
A leitura estoura o tempo em HTTPS Outra conexão segura estava aberta, e o aparelho atende uma por vez Mantenha o scrape_timeout em 10 s e as conexões persistentes ligadas (capítulo 9)
Erro de certificado no Prometheus em HTTPS O certificado não é de uma autoridade conhecida ou não vale para o endereço do alvo Indique o certificado em tls_config.ca_file; use no alvo o nome do certificado ou tls_config.server_name
A série de um sensor some e outra aparece O nome do slot mudou, e o rótulo name junto Use hwid nas consultas e regras
Um sensor some de simut_temperature_celsius O sensor está em falha (simut_sensor_ok 0) ou ainda não tem leitura válida Veja o sensor no Painel de Controle e no capítulo 6
simut_ntp_synced vale 1 mas a hora está errada Na v2.7.1, a métrica conta a hora provisória como hora certa Não use a métrica para alertar sobre NTP; acompanhe os eventos 512 e 513
Contadores voltam a zero O aparelho reiniciou Use rate() e increase(), que tratam a volta a zero; veja simut_uptime_seconds
O Air aparece fora do ar quase sempre O Air só atende a rede acordado em M0 Comportamento esperado; acompanhe o Air pela telemetria (capítulo 24)
O Air não volta a dormir e a bateria cai rápido O Prometheus o consulta em M0 mais rápido que o prazo de inatividade, e cada leitura conta como uso Tire o Air do Prometheus ou só o consulte no carregador
O aparelho some do Prometheus enquanto o AP de configuração está aberto Com o AP aberto, a interface web só atende pela rede do AP Resolva a conexão Wi-Fi (capítulo 9)
Nada chega ao coletor IP do Coletor vazio, interruptor desligado, ou a gravação não reiniciou o aparelho Preencha o IPv4, ligue Habilitar encaminhamento syslog e grave com Salvar e reiniciar (capítulo 25)
O campo IP do Coletor recusa o valor Foi digitado um nome, como coletor.exemplo.com.br Use o endereço IPv4 do coletor
Nada chega, e o tcpdump no coletor vê os datagramas O firewall do coletor bloqueia a porta, ou o rsyslog/syslog-ng não escuta UDP nessa porta Libere a Porta UDP no firewall; confira o imudp do rsyslog ou o transport("udp") do syslog-ng
Nada chega com o Nível Mínimo em Fatal Os únicos eventos fatais são os registros de partida, que o syslog não recebe Use Error ou mais baixo
Linhas chegam sem hora (- no lugar da data) O aparelho ainda não acertou o relógio pelo NTP nem à mão Use a hora de chegada do coletor; corrija o NTP (capítulo 10)
O motivo de um reinício não aparece no coletor Os registros de partida e a autópsia são gravados antes de o encaminhamento começar Leia o log de eventos do aparelho (capítulo 16)
Faltam linhas de um período em que o Wi-Fi caiu A fila guarda só as 8 linhas mais novas enquanto não há rede Confira o log de eventos do aparelho, que guarda o período
Nada chega enquanto o AP de configuração está aberto Com o AP aberto, o aparelho não manda syslog Resolva a conexão Wi-Fi (capítulo 9)
Nada chega dos despertares do Air O Air só manda syslog acordado em M0 Comportamento esperado; os eventos ficam no log de eventos do Air
Muito mais linhas no coletor que no log de eventos O syslog não aplica o filtro de rotina; com Info, cada envio de telemetria vira uma linha Use Warning, ou filtre no coletor pelo MSGID
Não chegam as entradas bem-sucedidas Nível Mínimo em Warning ou acima; a entrada (300) é de nível Informação Use Info
Dois aparelhos aparecem com o mesmo HOSTNAME O HOSTNAME é o Nome, que pode se repetir Dê um Nome único a cada aparelho, ou separe pelo IP de origem
O HOSTNAME aparece com hífens no lugar de letras Espaços e letras acentuadas do Nome viram - Use no Nome só letras sem acento, dígitos e hífen, se o coletor depende do nome
Texto de evento cortado A linha passou de 255 bytes Leia o detalhe completo no console serial, no momento do evento
Linhas estranhas atribuídas ao aparelho O UDP não autentica: qualquer máquina pode mandar linhas com o nome do aparelho Aceite no coletor só os IPs dos aparelhos
Linhas em inglês num aparelho em português O aparelho não tem o pacote de idioma, ou o texto do detalhe não tem tradução Instale o pacote (capítulo 13); filtre sempre pelo MSGID

API REST e gestão de frota

Detalhes nos capítulos 26 e 27.

Sintoma Causa provável O que fazer
POST /api/login responde 401 {"ok":false,"err":1} com a senha certa Faltou o GET /api/login_init antes, o código já foi usado numa tentativa anterior, ou passou de 60 s Peça um código novo antes de cada tentativa
A entrada falha só para uma conta com acento na senha O resumo foi calculado sobre o UTF-8; o aparelho usa Latin-1 Codifique a senha em Latin-1 antes do SHA-256, ou use uma senha ASCII na conta do programa
A entrada funciona, mas todo pedido seguinte dá 401 O cliente não guardou o cookie, ou manda um Cookie de outro site junto do Authorization: Bearer Use um pote de cookies, ou mande só Authorization: Bearer sem nenhum cookie
A sessão do script cai sozinha a cada poucos minutos Outro processo, ou um navegador, entra com a mesma conta e substitui a sessão Dê uma conta a cada processo; não abra sessão por pedido
403 {"ok":false,"err":3} na entrada As três vagas de sessão estão ocupadas por outras contas Saia das sessões paradas (GET /logout) ou espere 15 min de ociosidade delas
403 numa rota que a conta deveria poder usar Em várias rotas, 403 também significa sessão vencida Pergunte GET /api/perms: 401 = entre de novo; 200 = falta a permissão
429 {"ok":false,"err":3,"retryAfter":N} no login_init Os 8 lugares da tabela de bloqueio estão com bloqueio ativo Espere os segundos de retryAfter
Um gestor e os navegadores dos operadores se bloqueiam mutuamente Estão atrás do mesmo NAT e dividem o bloqueio por IP Evite erros de senha no gestor; se possível, dê a ele um endereço próprio
commit_all responde 200, mas nada mudou Campo recusado (veja rejected), campo desconhecido ignorado, ou texto com \uXXXX Leia rejected; confira o nome da chave; mande acentos em UTF-8 direto (ensure_ascii=False)
commit_all responde 400 {"error":"Missing _payload"} O corpo foi enviado como JSON e não como formulário Mande _payload como campo de formulário, com --data-urlencode
set_time ou calib respondem missing epoch ou empty body O JSON foi enviado como formulário, o padrão do curl -d Acrescente -H 'Content-Type: application/json'
Um nome gravado aparece como Cozinha \u00e7 O cliente escapou o acento em \uXXXX Mande UTF-8 direto no JSON
O ensaio (_dry=1) disse que não reinicia, mas a gravação reiniciou O conjunto tinha campos que o ensaio não enxerga (h_int, ntp_enabled, slog_*, m_had, dns_auto, dns2, web_ka) Grave esses campos com _reboot=1 e conte com o reinício
A hora local ou o volume mudaram depois de um ensaio O ensaio aplica o fuso e os sons de verdade Não mande tz nem sounds num ensaio que não deve ter efeito; reinicie para voltar
A origem CORS foi gravada, mas o navegador continua bloqueando A origem só vale depois de um reinício Reinicie com POST /api/action?op=reboot ou grave com _reboot=1
O gestor no navegador vê “falha de rede” em vez de 401 O aparelho está sem origem CORS, ou com outra origem Configure a origem exata da página (capítulo 9); um OPTIONS responde 405 CORS disabled quando ela falta
A conta criada pela API não aparece rejected trouxe users.perms, users.name, users.dup ou users.full Corrija o motivo; users.perms = a conta que pede não tem todas as permissões pedidas
A exclusão de uma conta não apagou nada A ação usou name em vez de id Leia o id em GET /api/users e apague por id
O PIN definido pela API não abre o painel O PIN é mais curto que o mínimo da política, ou a política exige letras ou mais de 8 caracteres Use só algarismos com comprimento dentro da política e de 4 a 8, ou defina o PIN no painel
Todo pedido depois de gravar contas dá erro de conexão Gravar contas reinicia o aparelho logo depois de responder Espere o aparelho voltar (GET /api/login_init até responder) e entre de novo
503 Display in use. Retry shortly. em gravações Alguém tocou no painel, ou um cliente mandou POST /api/touch, há menos de 5 s Espere o Retry-After e repita
O arquivo enviado foi parar na raiz uploadDir veio depois do arquivo no formulário Ponha -F uploadDir=... antes de -F file=@..., ou use ?uploadDir= no endereço
429 Too Fast em /api/ls ou /api/logs Menos de 200 ms desde o pedido anterior do mesmo IP a uma das rotas limitadas Espace os pedidos; lembre que ls, logs, calib e tls dividem o mesmo relógio
503 Already processing no histórico Outro pedido de histórico está em andamento Um pedido de histórico por vez
history_multi responde só números de estimativa, com sliceRequired O período pedido gera uma resposta grande demais Peça em fatias com from e to
O .h5 baixado não tem as últimas medições Os arquivos por dia só têm blocos selados Leia também GET /api/history/open
A restauração responde st 6 O backup é de outro aparelho Um backup só restaura no aparelho que o gerou
O envio da imagem responde 422 com "v":7 A imagem é de outra variante (release, alpha ou Air) Envie a imagem com o mesmo env que /api/status informa
O envio da imagem responde 422 com "v" de 8 a 12 A assinatura da imagem foi recusada (capítulo 26) Envie o .bin assinado da release, sem alterá-lo
POST /api/ota/apply responde 409 Nenhuma imagem preparada com commit=1, o aparelho reiniciou depois do envio, ou, com "v", outro envio começou depois e a imagem gravada não confere mais com a assinatura Envie a imagem de novo com op=stage&commit=1
Um envio longo cai no meio, até a v2.10.0 Outra página do aparelho estava aberta no navegador: o aparelho cortava a conexão mais antiga para admitir as consultas dela. A porta não fazia diferença Feche as outras abas do aparelho e envie de novo, ou atualize para a v2.11.0 (capítulo 18)
avahi-browse não acha alguns aparelhos São alpha ou Air, que não têm mDNS; ou estão em outra rede ou VLAN Descubra-os pelos cabeçalhos X-SIMUT-* da telemetria no coletor
Dois aparelhos respondem pelo mesmo <nome>.local Os dois têm o mesmo Nome Dê um nome único a cada aparelho
O gestor gravou a configuração no aparelho errado O DHCP deu ao aparelho o IP que era de outro Compare sys.uid com o cadastro antes de cada gravação
As sessões do gestor caem sozinhas Dois trabalhadores, ou um operador, usam a mesma conta no mesmo aparelho Uma conta por processo; operadores com contas próprias
Operadores recebem Limite de sessões atingido O gestor ocupa vagas e não sai Uma sessão por aparelho, reaproveitada; GET /logout ao terminar
A conta de serviço cria contas, mas as de painel voltam com users.perms A conta de serviço não tem as permissões de painel que tenta conceder Dê a ela 0x0400, 0x0800 e 0x1000 (a conta de 7433)
O gestor não consegue atualizar o firmware A conta de serviço não é administrador completo A atualização exige o administrador completo (capítulo 17)
A página do gestor não recebe token na entrada A origem da página não é exatamente a origem configurada no aparelho, ou o aparelho não reiniciou depois da configuração Confira esquema, nome e porta da origem; reinicie o aparelho
A página do gestor em HTTPS não fala com os aparelhos Aparelhos em HTTP (conteúdo misto) ou certificado em que o navegador não confia Use HTTPS nos aparelhos, com certificados assinados por uma autoridade que os navegadores aceitem
O gestor no navegador perdeu um aparelho depois da atualização A atualização apagou a origem CORS e o certificado HTTPS Restaure o backup por um serviço no servidor ou pela página Arquivos do aparelho
Um lote de configuração reiniciou toda a frota O modelo tinha campos que reiniciam (tz, t_sec, rede, contas) Separe as mudanças que reiniciam e aplique-as em ondas, fora do horário de uso
O ensaio passou, mas a gravação reiniciou O modelo tinha campos que o ensaio não enxerga Veja a lista no capítulo 26 e conte com o reinício
O cfg de um aparelho mudou sem gravação do gestor Alguém mudou a configuração pela página, pelo painel ou pelo console Leia GET /api/config e compare com o modelo
Os Air nunca hibernam O Prometheus ou o gestor consultam o Air com uma conta válida Tire o Air da coleta; use ?quiet=1 no /api/status
O Prometheus bloqueia a entrada web de quem está no mesmo endereço Senha errada no Basic conta no mesmo bloqueio por IP Corrija a senha do Prometheus
Um aparelho atualizado continua na versão antiga A aplicação foi recusada (409 ou 403) ou a imagem não foi preparada com commit=1 Leia a resposta de cada passo; só a versão informada pelo aparelho prova a atualização
O envio da imagem volta com "v":7 A imagem é de outra variante Escolha images[env] pelo sys.env do aparelho
Depois da atualização e da restauração, textos novos aparecem em inglês O backup restaurado trouxe os pacotes de idioma antigos Envie os .lng da release nova para /lang e reinicie
Um aparelho com firmware antigo não atualiza pela rede Versão anterior a min_from Grave pelo cabo USB uma vez (capítulo 3)
Um aparelho sumiu do coletor Sem rede, sem energia, sinal abaixo de −78 dBm ou aparelho parado Compare a hora do último POST com o ritmo esperado e verifique o local

Quando relatar um defeito

Se nada aqui explica o que você vê, relate o defeito. Um relato que traz estas informações quase sempre leva à causa:

  1. A imagem (release, alpha ou Air) e a versão que a gaveta da interface web mostra.
  2. O que você fez, em que ordem e a que horas, pela hora do aparelho.
  3. O log de eventos exportado em CSV pela página Histórico e Logs, ou a saída de show system log pelo console USB.
  4. Num travamento, os registros Boot do sistema com nível FTL e os registros irmãos logo em seguida (capítulo 16).
  5. Uma captura da tela do painel, pelo espelho ou pela rota /api/screenshot, ou uma foto do LCD.

Relate um defeito comum nas issues do repositório: https://github.com/angeloINTJ/simut/issues. Uma falha de segurança vai pelo relato privado, e não por uma issue pública (capítulo 29).

Voltar ao sumário

Capítulo 31

Glossário

Os termos que este manual usa, com o sentido que têm no SIMUT. Cada termo aponta para o capítulo que o explica em detalhe.

A a C

Administrador completo
Conta com todas as permissões. Só ela faz backup, restaura, aplica uma atualização e instala o certificado HTTPS. A conta admin é uma delas (capítulo 8).
Adotar a sonda
Operação do editor de slot que lê a ROM de um DS18B20 e liga o slot a ela (capítulo 6).
Air (SIMUT Air)
Imagem sem display que hiberna entre um despertar e outro, para funcionar a bateria. É experimental (capítulo 19).
Alpha
Imagem com LCD de 16×2 caracteres e console Bluetooth, sem toque (capítulo 12).
AP de configuração
Ver ponto de acesso de configuração.
Aparelho
O SIMUT: a placa Pico W com o firmware, os sensores e, conforme a imagem, o painel ou o LCD.
Aplicar agora
Botão da interface web que grava a configuração e aplica sem reiniciar o que pode ser aplicado assim (capítulo 5).
Autópsia
O diagnóstico que o aparelho faz no boot depois de um travamento, a partir dos vestígios que sobrevivem ao reinício. O veredito vai ao log de eventos (capítulo 16).
Backup
Arquivo .bkp com a configuração e os arquivos do aparelho, baixado pela página Arquivos (capítulo 17).
Bloco
Grupo de até 60 registros do histórico, com o próprio código de verificação. Com o intervalo de fábrica, um bloco cobre 1 h (capítulo 15).
Bloco aberto
O bloco que ainda está recebendo registros. Ele fica na RAM, com uma cópia em /history/.wip (capítulo 15).
BOOTSEL
Botão da placa Pico W. Segurado ao ligar o cabo USB, faz a placa aparecer no computador como um disco, para gravar um arquivo .uf2 (capítulo 18).
Canal
Uma grandeza de um sensor: temperatura, umidade ou pressão. Um slot tem até quatro canais (capítulo 6).
Coletor
O servidor que recebe a telemetria e a linha de alarmes (capítulo 20).
Console completo
O console serial com todos os comandos, nas imagens de teste e no Air (capítulo 14).
Console de emergência
O console serial reduzido das imagens release e alpha, com 15 comandos: os de recuperação, os de rede, os de leitura do estado e o acerto do relógio (capítulo 14).
Console serial
A linha de comandos do aparelho, pelo cabo USB ou, no alpha e no Air, pelo Bluetooth (capítulo 14).
Conta
Nome, senha, PIN e permissões de uma pessoa ou de um sistema. O aparelho guarda até 32 (capítulo 8).
CORS
Autorização para que uma página hospedada em outro servidor, como um gestor de frota, fale com o aparelho (capítulo 26).

D a L

Despertar
No Air, o intervalo curto em que o aparelho sai da hibernação, lê os sensores, grava e, quando é hora, envia a telemetria (capítulo 19).
Dia selado
O arquivo de histórico de um dia, /history/<dia>.h5. Ele só contém blocos já selados (capítulo 15).
Dormência
Fase da escada de reconexão em que o aparelho espera 10 min antes de cada busca pela rede (capítulo 9).
Época do slot
A data em que o sensor atual começou num slot. O aparelho a grava quando o tipo do slot muda, quando uma sonda adotada troca o ID do slot, ou com Resetar época do histórico. Na v2.7.1, nenhum gráfico usa essa data (capítulo 6).
Escada de reconexão
A sequência de tentativas, com esperas crescentes, que o aparelho segue quando perde a rede Wi-Fi (capítulo 9).
Espelho do painel
Na imagem release, o painel mostrado ao vivo no Painel de Controle da interface web. Um clique no espelho vale como um toque no painel (capítulo 13).
Gestor de frota
Um programa ou uma página que administra vários aparelhos pela API (capítulo 27).
Histórico
As medições gravadas no próprio aparelho, um registro a cada Intervalo Histórico (capítulo 15).
ID de hardware
O identificador de um sensor na telemetria. No histórico, a série é a do slot (capítulo 6).
Imagem
Uma das variantes do firmware: release, alpha ou Air. Cada aparelho recebe atualizações só da própria imagem (capítulo 1).
Janela de manutenção
Período em que os alarmes de um sensor ficam suspensos de propósito, com prazo, para uma limpeza ou um degelo. A linha de alarmes registra a abertura e o fim (capítulo 7).
LCD
O display de 16×2 caracteres da imagem alpha (capítulo 12).
Linha de alarmes
O segundo canal de envio do aparelho. Ele envia um registro a cada mudança de estado de alarme, separado da telemetria de medições (capítulo 22).
LittleFS
O sistema de arquivos da memória flash, com 1 MB. Guarda a configuração, o histórico, o log e os pacotes de idioma (capítulo 17).
Log de eventos
O registro do que o aparelho fez e do que deu errado, com código, nível e contexto (capítulo 16).
Lote mínimo e lote máximo
Os campos t_int e t_bat da telemetria: quantos registros pendentes disparam um envio e quantos vão, no máximo, em cada envio (capítulo 21).

M a R

M0 e M1
Os dois modos do Air. Em M0 ele fica acordado, com a interface web. Em M1 ele hiberna e só desperta para medir (capítulo 19).
mDNS
O endereço pelo nome, como http://simut.local. Só existe na imagem release (capítulo 9).
Modo de Configuração
O item 8 das Configurações do painel, que abre o ponto de acesso de configuração (capítulo 11).
Pacote de idioma
Arquivo .lng que traduz o painel, a interface web e o log. Só é carregado no boot (capítulo 13).
Painel
A tela de toque da imagem release (capítulo 11).
Pendentes
Registros do histórico que ainda não foram entregues ao coletor (capítulo 21).
Permissão
Um dos bits que dizem o que uma conta pode ver e fazer, na web, no painel e na API (capítulo 8).
PIN
O código que confirma, no painel, a conta escolhida. A web usa a senha (capítulo 8).
Política de PIN
As regras do PIN: comprimento mínimo, alfabeto e o teclado (capítulo 8).
Ponto de acesso de configuração
A rede Wi-Fi <nome>_SETUP que o aparelho cria, quando alguém pede, para ser configurado sem outra rede. Com ela no ar, o aparelho continua medindo; da v2.7.1 à v2.8.0, não media (capítulo 9).
Recompor o histórico
Operação que reescreve o arquivo do dia depois de uma mudança nos slots, mantendo os registros já feitos (capítulo 6).
Release
A imagem com painel de toque, buzzer, HTTPS e mDNS (capítulo 1).
Relógio provisório
A hora que o aparelho usa até o primeiro acerto, pelo NTP ou à mão: parte do registro mais recente do histórico ou, sem histórico, de uma data gravada no firmware. No painel, a data e a hora aparecem em âmbar, com ? no lugar do - (capítulo 10).
Reset de fábrica
O comando system factory confirm, que volta a configuração ao estado de fábrica e mantém os arquivos (capítulo 17).
Reset do administrador
O comando system admin reset confirm, que gera uma senha nova para a conta admin e a mostra uma vez, no console USB (capítulo 17).

S a Z

Salvar e reiniciar
Botão da interface web que grava a configuração e reinicia o aparelho (capítulo 5).
Selar
Fechar um bloco do histórico e acrescentá-lo ao arquivo do dia (capítulo 15).
Sessão
A entrada de uma conta na interface web ou na API. Vence depois de 15 min sem uso (capítulo 13).
Slot
Uma das 16 posições de sensor do aparelho, numeradas de 0 a 15 (capítulo 6).
Syslog
Protocolo padrão para enviar o log de eventos a um servidor na rede (capítulo 25).
Teclado embaralhado
O teclado de PIN do painel com 2 ou 3 caracteres por cartão. Depois de cada toque, os caracteres são redistribuídos, para que quem olha a tela não descubra o PIN (capítulo 8).
Telemetria
O envio das medições do histórico ao coletor, por HTTP, HTTPS, MQTT ou MQTTS (capítulo 21).
Testar
Botão da interface web que confere a configuração sem gravar nada (capítulo 5).
Token Bearer
O código de sessão que um programa manda no cabeçalho Authorization, no lugar do cookie (capítulo 26).
Transição
Mudança de estado. O log de eventos grava uma falha repetida na primeira vez e depois só a cada hora; a linha de alarmes envia um registro por mudança (capítulo 16).
UF2
O formato de arquivo que a placa aceita no modo BOOTSEL (capítulo 3).

Voltar ao sumário

Apêndices

Referência rápida

Apêndice A

Imagens a capturar

151 de 202 figuras deste manual ainda não foram capturadas (Diagrama: 29 · Foto: 9 · LCD 16×2: 17 · Tela do painel: 41 · Página web: 55). Cada uma aparece no texto como um quadro marcado. Salve a captura em docs/images/manual/ com o nome da coluna Arquivo e rode python3 tools/build_manual.py: a figura entra no lugar do quadro.

Como capturar

  • Telas do painel: grave a imagem pico_w_test num aparelho com o painel ligado, navegue com screen <tag> ou com toques pelo POST /api/touch, espere 6 s após o último toque e baixe GET /api/screenshot. tools/screen_mapper.py faz isso para as telas que ele conhece; amplie 2× sem suavização.
  • Páginas web: tools/capture_web_shots.py (Playwright), em 1280 px de largura e, onde indicado, em 390 px.
  • LCD e fotos: fotografia, de frente, sem reflexo.
#ArquivoCap.Como capturar
101-arquitetura.png
Diagrama
1diagrama de blocos do aparelho: à esquerda, os sensores (DS18B20, DHT22, BME280/BMP280) ligados a GP0–GP15; no centro, o RP2040 com dois blocos, Core 0 (sensores, alarmes, histórico, rede, web, console, telemetria) e Core 1 (painel TFT e toque na release; LCD na alpha; sem uso no Air); abaixo, a flash de 2 MB em duas faixas, 'programa 1 MB' e 'LittleFS 1 MB' com as pastas /config, /history, /lang, /themes e o log de eventos; à direita, as saídas: navegador (interface web), servidor de telemetria (HTTP/MQTT), linha de alarmes, Home Assistant, Prometheus e syslog; embaixo à direita, o cabo USB e o Bluetooth levando ao console
202-pinos-release.png
Diagrama
2vista de cima do Pico W com os 40 pinos numerados; GP0–GP15 marcados como SLOT 0–15; GP16 MISO, GP17 T_CS, GP18 SCK, GP19 MOSI, GP20 T_IRQ, GP22 cigarra, GP26 RST, GP27 DC, GP28 CS; 3V3 (36) para TFT e sensores, VBUS (40), GNDs destacados; GP23/24/25/29 em cinza como internos do rádio
302-pinos-alpha.png
Diagrama
2vista de cima do Pico W; GP0–GP15 como SLOT 0–15; GP16 RS, GP17 EN, GP18 D4, GP19 D5, GP20 D6, GP21 D7 do LCD; GP22 cigarra; VBUS (40) para o LCD, 3V3 (36) para os sensores; GP26–GP28 sem uso
402-pinos-air.png
Diagrama
2vista de cima do Pico W; GP0–GP15 como SLOT 0–15; GP16 saída de energia dos sensores e sinal de acordado; GP17 entrada do carregador; demais pinos de GP18 em diante sem uso
502-air-energia.png
Diagrama
2GP16 acionando uma chave do lado positivo (MOSFET canal P com acionamento, ou pino EN de um regulador 3,3 V) que alimenta o barramento de 3,3 V dos sensores; à parte, o carregador de 5 V com um divisor resistivo levando ao GP17; legenda 'GP16 alto = acordado'
602-ds18b20.png
Diagrama
2sonda DS18B20 de três fios ligada ao Pico W: VDD no 3V3 (pino 36), GND no GND, DQ num GPIO de slot (exemplo GP2, pino 4); resistor de 4,7 kΩ entre DQ e 3V3
702-dht22.png
Diagrama
2módulo DHT22 de três terminais ligado ao Pico W: + no 3V3 (pino 36), dados num GPIO de slot (exemplo GP3, pino 5), − no GND; nota 'pull-up conforme o módulo'
802-bmx280.png
Diagrama
2módulo BME280 de seis pinos ligado ao Pico W: VCC no 3V3 (pino 36), GND, SDA no GP4 (pino 6), SCL no GP5 (pino 7), CSB no 3V3, SDO no GND (endereço 0x76); nota 'pull-ups de 4,7 kΩ em SDA e SCL se o módulo não tiver'
902-placa.png
Foto
2placa SIMUT v1.1 montada, vista de cima: Pico W no soquete, conector TFT-Touch com o painel ligado, bloco Alphanumeric vazio, coluna S0–S10 com uma sonda DS18B20 em S2, cigarra, conversor HLK-PM01 e a marcação 90-240Vac visível
1003-arquivos.png
Diagrama
3os doze arquivos de uma versão e para onde vai cada um: .uf2 → cabo USB com BOOTSEL (aparelho novo ou recuperação); .bin → página Arquivos, atualização pela rede; language_pt-BR.lng → página Arquivos, pasta /lang; manifest.json → gestor de frota; SHA256SUMS → conferência do download; quatro colunas coloridas por imagem (release, alpha, air, releasetwo)
1103-bootsel.png
Foto
3mão segurando o botão BOOTSEL de um Pico W enquanto o cabo USB é ligado; o botão bem visível, ao lado do chip RP2040
1204-fluxo.png
Diagrama
4fluxograma do primeiro boot: 'liga com o console USB aberto' → 'anota a senha do admin' → na release, 'o painel pergunta a data e a hora: SALVAR ou PULAR'; depois dois ramos: release e alpha 'ap no console (na release, também o item 12 do menu) → AP simut_SETUP → 192.168.4.1 → troca de senha → Rede → Salvar e reiniciar'; Air 'console: enable, configure terminal, system ssid, system pass, reload confirm'; os ramos se juntam em 'aparelho na rede' → 'pacote de idioma e reinício' → 'fuso e hora' → 'primeiro sensor' → 'PIN do painel (release)' → 'pronto para usar'
1304-painel-data-hora.png
Tela do painel
4release recém-gravada, sem rede configurada, logo depois do boot; tela Data e hora com as cinco colunas e as setas, a linha Sem Wi-Fi, os dados levam esta hora. em âmbar e os botões PULAR e SALVAR; sem rede, GET /api/screenshot não alcança o aparelho: use foto da tela, antes dos 30 s sem toque que levam o painel à tela inicial
1404-painel-ap.png
Tela do painel
4release recém-gravada, sem rede configurada; ponto de acesso aberto pelo menu (CFG, admin, PIN, item 8 Modo de Configuração, Confirmar) ou pelo comando ap no console USB; a caixa termina com simut_SETUP, PSK e a chave, Acesse no celular: 192.168.4.1 e AP Ativo! Reinicie a placa para sair.; capturar com GET /api/screenshot pelo próprio AP, com sessão admin depois da troca de senha; se a captura não funcionar no AP, use foto da tela; borre a chave antes de publicar
1504-lcd-ap.png
LCD 16×2
4alpha recém-gravada, sem rede configurada; ponto de acesso aberto pelo comando ap no console USB, com o aparelho já nas leituras; página Rede: 2 de 3 com simut_SETUP na linha de baixo
1604-novo-pin.png
Tela do painel
4release com configuração de fábrica; tela inicial → botão de configurações → admin → PIN 1234 → ENTRAR; tela Novo PIN aberta, antes de digitar
1705-selo-reinicio.png
Página web
5rota /config; largura 1280; sessão admin; imagem release; campo Fuso Horário alterado de -3 para -4 e ainda não gravado; ensaio já respondido; recorte da barra de topo
1805-tres-botoes.png
Página web
5rota /alarms; largura 1280; sessão admin; imagem release; limite máximo de temperatura de um slot alterado; ensaio respondido Não exige reinício; recorte da barra de topo com o selo e os três botões
1905-confirmacao.png
Página web
5rota /config; largura 1280; sessão admin; Nome do aparelho alterado; janela de confirmação aberta depois de tocar em Salvar e reiniciar
2105-erro-carga.png
Página web
5rota /config; largura 1280; sessão admin; aparelho sem responder a /api/config (por exemplo, rede interrompida depois de a página abrir); faixa de erro visível e campos desabilitados
2205-data-hora.png
Página web
5rota /config; largura 1280; sessão admin; NTP desligado e gravado; seção Data e Hora com os campos de data e hora preenchidos; mensagem Hora aplicada. abaixo do botão Aplicar Agora
2806-editor-ds18b20.png
Página web
6rota /config; largura 1280; sessão admin com a permissão Calibração; imagem release; editor do slot 2 aberto, DS18B20 ativo em GP2, relógio sincronizado por NTP, sem correção
2906-editor-bme280.png
Página web
6rota /config; largura 390; sessão admin; imagem release; editor de um slot novo com o tipo BME280 escolhido, Pino 0 — SDA em GP4, Pino 1 — SCL em GP5, ID de hardware e nome preenchidos, Ativo ligado, ainda não gravado
3006-editor-aviso.png
Página web
6rota /config; largura 1280; sessão admin; editor de um slot DHT22 ativo com o pino Data em GP4, que já pertence ao slot 2; a linha vermelha mostra GP4 já está em uso pelo slot 2.
3106-procurar.png
Página web
6rota /config; largura 1280; sessão admin; imagem release; um DS18B20 em GP2 e um DHT22 em GP3 ligados; logo depois de tocar em Procurar sondas e a busca terminar; recorte dos botões e da linha de resultado
3206-painel-sensor.png
Tela do painel
6screen dash; 2 sensores ativos (um DS18B20 e um BME280), ambos lendo, nenhum em alarme
3306-painel-erro.png
Tela do painel
6screen dash; 2 sensores ativos; a sonda DS18B20 desligada do pino há mais de 3 leituras, alarmes do slot ligados
3406-lcd-erro.png
LCD 16×2
6imagem alpha; 1 sensor DHT22 ativo e desligado do pino; o LCD mostra ERRO em letras grandes
3506-calibracao.png
Página web
6rota /config; largura 1280; sessão admin com a permissão Calibração; editor de um slot DHT22 ativo; relógio sincronizado por NTP; Temp com 2 pontos preenchidos e Reta escolhida; Umid sem correção; recorte do bloco Calibração
3606-calibracao-suave.png
Página web
6rota /config; largura 1280; sessão admin com a permissão Calibração; editor de um slot DS18B20; Temp com 3 pontos (0, 25 e 50 °C de referência) e Suave escolhida; recorte do bloco Calibração
3706-calibracao-ntp.png
Página web
6rota /config; largura 1280; sessão admin com a permissão Calibração; relógio do aparelho sem sincronização NTP; editor de um slot ativo; recorte do fim do bloco Calibração com o aviso NTP não sincronizado.
3907-painel-falha.png
Tela do painel
7screen dash; 2 sensores ativos; o DS18B20 do cartão de baixo desligado do pino há mais de 3 leituras; captura na fase âmbar da piscada
4607-menu-sensor-manut.png
Tela do painel
7menu do sensor aberto por uma conta que tem só a permissão Manut. (painel); caminho: tela inicial, botão de configurações, conta, PIN, Limites de Alarme, sensor
4807-manutencao-entrada.png
Tela do painel
7menu do sensor -> Manutenção -> ENTRAR; sessão admin; janela fechada; Horas 2 e Minutos 30 ajustados, antes de INICIAR
4907-manutencao-aberta.png
Tela do painel
7mesmo caminho, com a janela aberta há alguns minutos
5107-melodia.png
Tela do painel
7tela Config. de Sons; som Alarme desligado; toque na linha Alarme duas vezes para abrir a escolha de melodia
5207-mudo-confirmar.png
Tela do painel
7tela MODE_CONFIRM_MUTE_ALL; na tela Config. de Sons, selecione Mudo Global desligado e toque nele; a ferramenta de mapa de telas não alcança esta tela sozinha
5308-usuarios.png
Página web
8rota /users; largura 1280; sessão admin; imagem release; contas admin (com PIN), viewer e duas contas de operador, uma delas com PIN; nenhuma alteração pendente
5408-usuarios-permissoes.png
Página web
8rota /users; largura 390; sessão admin; selo de permissões de uma conta de operador aberto, mostrando os nomes
5508-usuarios-nova.png
Página web
8rota /users; largura 1280; sessão admin; uma conta nova preparada com as permissões Painel e Histórico, ainda não gravada; linha com Pendente: Novo e o botão desfazer
5608-senha-temporaria.png
Página web
8rota /users; largura 1280; sessão admin; logo depois de Salvar e reiniciar com uma conta nova chamada operador1; janela Senha temporária aberta; senha fictícia
5708-quem.png
Tela do painel
8screen pin; contas admin, operador1 e manutencao com PIN; nenhuma bloqueada
5908-teclado-3.png
Tela do painel
8screen pin e escolha de uma conta; política de fábrica: 0-9, 3 por tecla; dois caracteres já digitados
6008-teclado-alfa.png
Tela do painel
8screen pin e escolha de uma conta; política 0-9 A-Z, 1 por tecla; grupo PQRS aberto
6108-teclado-numerico.png
Tela do painel
8menu > Alterar Senha, sessão admin; política de fábrica; tela Novo PIN com três dígitos digitados
6208-pin-invalido.png
Tela do painel
8screen pin, escolha de uma conta, um PIN errado e ENTRAR; logo depois da recusa
6308-espera.png
Tela do painel
8screen pin; a mesma conta errou o PIN três vezes seguidas; durante a espera de 5 s
6408-painel-bloqueado.png
Tela do painel
8tela do teclado depois de 20 tentativas erradas somadas, sem nenhuma entrada certa no meio
6508-pin-em-uso.png
Tela do painel
8menu > Alterar Senha; digitar duas vezes um PIN que outra conta já usa
6608-politica.png
Tela do painel
8menu > Segurança do PIN, sessão admin; política de fábrica; linha Teclado selecionada
6708-politica-web.png
Página web
8rota /config; largura 1280; sessão admin; imagem release; recorte dos três campos de PIN da seção Hardware, com 2 glifos por tecla e 0-9 A-Z escolhidos
6808-usuarios-lista.png
Tela do painel
8screen usr; contas viewer, operador1 (com PIN, L e B) e manutencao (com PIN, M)
6908-novo-nome.png
Tela do painel
8screen usr -> NOVO; nome manutencao digitado
7008-novo-permissoes.png
Tela do painel
8screen usr -> NOVO -> nome -> OK; Editar limites e Manutenção em SIM
7108-novo-pin.png
Tela do painel
8mesmo caminho -> SEGUIR; tela Novo PIN com o teclado ordenado
7208-excluir.png
Tela do painel
8screen usr -> conta manutencao -> Excluir usuário
7409-ip-estatico.png
Página web
9rota /network; largura 1280; sessão admin; DHCP desligado; IP Estático 192.0.2.10, Máscara 255.255.255.0, Gateway 192.0.2.1; DNS automático desligado com DNS Primário 192.0.2.1; alterações preparadas e ainda não gravadas
7509-servidor-web.png
Página web
9rota /network; largura 1280; sessão admin; imagem release; certificado HTTPS instalado; página aberta por https; recorte das seções Servidor de Hora (NTP) e Servidor Web, com o interruptor Conexões persistentes visível e ligado
7609-busca.png
Página web
9rota /network; largura 1280; sessão admin; busca concluída com 5 redes de exemplo (MinhaRede protegida -48 dBm com 4 barras, uma rede aberta com 2 barras, as outras protegidas); lista aberta abaixo do campo SSID
7709-escada.png
Diagrama
9linha do tempo da escada de reconexão: queda; cinco ciclos de busca, busca e tentativa de 20 s com esperas de 5, 10, 20, 40 e 80 s; três dormências de 10 min antes de cada busca; ao fim, o recomeço da escada, que se repete até a rede voltar; nenhum AP de configuração na linha
7809-aviso-certificado.png
Página web
9rota https://192.0.2.10/login; largura 1280; navegador Chrome sem a exceção aceita; certificado autoassinado recém-instalado; página de aviso do navegador
7910-log-ntp.png
Página web
10rota /history; largura 1280; sessão admin; aba de eventos carregada logo depois de um boot com NTP; linhas 524 Hora provisória do flash, 14 IP obtido, 13 NTP sincronizado, 408 NTP corrigindo timestamps com contexto de alguns segundos, 409 e 410 visíveis
8010-acerto-manual.png
Página web
10rota /config; largura 1280; sessão admin; NTP desligado e gravado; seção Data e Hora com os campos Data e Hora preenchidos e a mensagem Hora aplicada.
8110-correcao.png
Diagrama
10linha do tempo: aparelho desligado por 2 h; boot com relógio provisório a partir do último registro, 2 h atrasado; medições carimbadas com a hora provisória; acerto por NTP com correção de +7200 s; os blocos gravados desde o boot deslocados 2 h para a frente; eventos 524, 13, 408, 409 e 410 marcados na linha
8310-painel-hora-provisoria.png
Tela do painel
10screen dash; rede configurada e NTP desligado e gravado, reiniciado e sem acerto à mão desde o boot; recorte da faixa de topo com a data e a hora em âmbar e o ? no lugar do -
8411-principal.png
Tela do painel
11screen dash; 3 sensores ativos: DS18B20 no slot 0 (fixado no cartão de cima), DHT22 no slot 1 (selecionado) e BME280 no slot 2; Wi-Fi conectado com sinal forte; 12 registros pendentes; relógio acertado; nenhum alarme
8511-pendentes-falha.png
Tela do painel
11screen dash; telemetria ligada com o coletor fora do ar há alguns minutos; recorte da barra de cima com a contagem de pendentes em vermelho
8611-aviso-web.png
Tela do painel
11screen dash; até 5 s depois de entrar na interface web com a conta admin; recorte da barra de cima com Web: admin no lugar do relógio
8811-selecao.png
Tela do painel
11screen dash; 3 sensores ativos; segure o dedo no cartão de cima por 3 s e solte; a ferramenta de mapa de telas não faz o gesto de segurar
8911-paginas.png
Tela do painel
11screen dash; 7 sensores ativos, nenhum fixado fora da primeira página; barra de botões na primeira página, com S e o botão 1/2
9011-web-ocupado.png
Tela do painel
11screen dash; durante a exportação em CSV de um dia de histórico pela conta admin, na página Histórico e Logs
9111-carregando.png
Tela do painel
11tela MODE_GRAPH_LOADING; aparece por instantes ao abrir um gráfico a partir da tela inicial; transitória, pode exigir várias tentativas de captura
9311-detalhe-temp.png
Tela do painel
11screen gra -> tap(160,120); gráfico de um BME280 aberto antes, em 24H
9411-detalhe-umid.png
Tela do painel
11screen gra -> tap(160,120) -> tap(160,120); mesmo BME280
9511-detalhe-pressao.png
Tela do painel
11screen gra -> tap(160,120) -> tap(160,120) -> tap(160,120); mesmo BME280
11011-mira.png
Tela do painel
11screen touchcal e complete a etapa de sensibilidade com o dedo; capture a primeira mira, no canto de cima à esquerda; o toque simulado não completa a sensibilidade, porque não tem pressão
11111-calib-ok.png
Tela do painel
11depois do oitavo toque de uma calibração com as duas voltas coerentes
11211-calib-recusada.png
Tela do painel
11depois do oitavo toque, tendo tocado longe da mira num dos cantos da segunda volta
11311-alinhamento.png
Tela do painel
11screen offset; deslocamento X +2 e Y -1 ajustado, antes de APLICAR
11511-mensagem-ok.png
Tela do painel
11menu > Alterar Senha; digite duas vezes um PIN novo e válido, com ENTRAR
12011-boot.png
Foto
11boot com rede configurada e alcançável; capture durante Aguardando roteador; a captura por GET /api/screenshot não alcança o boot, então use foto da tela
12111-boot-gesto.png
Foto
11boot; linha Mantenha a tela pressionada: Modo AP... no fim da caixa; foto da tela
12211-boot-progresso.png
Foto
11boot; dedo mantido na tela há cerca de 1,5 s dentro da janela; foto da tela
12311-boot-cancelado.png
Foto
11boot; dedo levantado antes de a barra encher; foto da tela
12411-boot-ap.png
Foto
11boot pelo gesto completo; caixa com o nome da rede, PSK e AP Ativo!; foto da tela; a chave da foto deve ser borrada antes de publicar
12512-splash.png
LCD 16×2
12logo depois de ligar; linha de cima SIMUT 2.7.1, linha de baixo Inicializando
12612-boot.png
LCD 16×2
12durante o boot, com a barra pela metade: SIMUT 2.7.1 e [####### ]
12712-conectado.png
LCD 16×2
12fim do boot, na rede, com IP; Conectado! e o endereço IP na linha de baixo (use um endereço de documentação na legenda publicada)
12812-obtendo-ip.png
LCD 16×2
12fim do boot, associado ao roteador sem endereço ainda; Conectado! e Obtendo IP...
12912-offline.png
LCD 16×2
12fim do boot sem rede alcançável; Sem WiFi e Offline
13012-temperatura.png
LCD 16×2
122 sensores ativos; na vez da temperatura do slot 0, com 23,4 °C; W e o ícone de sinal no canto de cima, S0 no canto de baixo
13112-umidade.png
LCD 16×2
12DHT22 no slot 1, na vez da umidade, com 58 %; S1 no canto de baixo
13212-pressao.png
LCD 16×2
12BME280 no slot 2, na vez da pressão, com 1013,2 hPa; S2 no canto de baixo
13312-negativa.png
LCD 16×2
12DS18B20 num congelador, com -18,5 °C; um só sensor ativo e nenhum pendente
13412-sem-sensor.png
LCD 16×2
12imagem alpha sem nenhum slot ativo, conectada ao Wi-Fi; ERRO em letras grandes e W com o ícone de sinal
13512-wifi-niveis.png
Diagrama
12os seis desenhos do ícone, em grade de 5 x 8 pixels, lado a lado: X, 1, 2, 3, 4 e 5 barras; em cima, a escada da v2.7.2 (colunas acesas da esquerda para a direita); embaixo, os desenhos da v2.7.1 (linhas acesas de baixo para cima); bitmaps em src/display/BigFont_HD44780.h
13612-pendentes.png
LCD 16×2
12imagem v2.7.2; 1 sensor ativo; telemetria ligada com o coletor fora do ar, 37 registros pendentes; 37 no canto de baixo à esquerda
13712-pendentes-k.png
LCD 16×2
12imagem v2.7.2; 1 sensor ativo; 2.500 registros pendentes; 2k no canto de baixo
13812-ap-1.png
LCD 16×2
12AP aberto em operação pelo comando ap; página Modo AP 1 de 3 com 192.168.4.1
13912-ap-2.png
LCD 16×2
12mesmo estado; página Rede: 2 de 3 com simut_SETUP
14012-ap-3.png
LCD 16×2
12mesmo estado; página Senha: 3 de 3 com a chave; borre a chave na foto publicada ou use um aparelho de demonstração
14213-entrada-bloqueio.png
Página web
13rota /login; largura 390; sem sessão; uma senha errada acabou de ser enviada; a mensagem Bloqueado por 2s. Tentativas excessivas. está na tela e o botão Entrar está desativado
14313-trocar-senha.png
Página web
13rota /login, depois de tocar em Trocar senha; largura 390; sem sessão; Nova Senha preenchida com 8 caracteres entre letras e dígitos, sem símbolo; Repetir Nova Senha vazia
14413-aviso-sessao-segura.png
Página web
13rota /login; largura 1280; navegador com cookie seguro de uma visita HTTPS anterior ao mesmo endereço, aparelho agora em HTTP; logo depois de uma entrada com senha certa
14513-troca-obrigatoria.png
Página web
13rota /force_chpass; largura 390; sessão de uma conta recém-criada com senha temporária; Nova Senha preenchida com uma senha que atende às quatro exigências e Repetir Nova Senha igual
14613-barra-topo.png
Página web
13rota /alarms; largura 1280; sessão admin; um limite de alarme alterado e ainda não gravado; recorte da barra de topo e da trilha
14813-gaveta-restrita.png
Página web
13rota /; largura 390; sessão de um operador com as permissões Painel e Histórico; gaveta aberta
14913-acesso-negado.png
Página web
13rota /; largura 1280; sessão de um operador sem a permissão Painel, logo depois de entrar
15113-painel-de-controle-alpha.png
Página web
13rota /; largura 1280; sessão admin; imagem alpha; 1 sensor DHT22 ativo; telemetria desligada
15213-painel-de-controle-celular.png
Página web
13rota /; largura 390; sessão admin; imagem release; 2 sensores ativos; página rolada até a tabela de sensores
15313-espelho-ao-vivo.png
Página web
13rota /; largura 1280; sessão admin; imagem release; Ao vivo ligado; o painel está na tela inicial com 2 sensores; recorte do bloco Tela com a linha de estado mostrando fps, kB e s
15413-captura.png
Página web
13rota /; largura 1280; sessão admin; imagem release; depois de tocar em Capturar, com o painel na tela inicial; recorte do bloco Tela
15513-espelho-ocupado.png
Página web
13rota /; largura 1280; sessão admin; imagem release; Ao vivo ligado; uma pessoa acabou de tocar no painel com o dedo; recorte do bloco Tela com a mensagem Display em uso na linha de estado
15613-tema-claro.png
Página web
13rota /; largura 1280; sessão admin; imagem release; tema claro escolhido no botão da barra; 2 sensores ativos
15713-celular-pendente.png
Página web
13rota /alarms; largura 390; sessão admin; um limite de alarme alterado e ainda não gravado; a barra fixa do rodapé visível
15915-caminho.png
Diagrama
15fluxo da esquerda para a direita: sensores → 'registro a cada Intervalo Histórico' → caixa 'bloco aberto (RAM), até 60 registros'; seta tracejada 'cópia a cada registro' para '/history/.wip'; seta cheia 'selar (60 registros, virada do dia, correção do NTP)' para '/history/AAAAMMDD.h5', desenhado como uma pilha de blocos, cada um com 'CRC' e 'mín/máx'; ao lado, uma fila de arquivos diários com o mais antigo marcado 'apagado acima de 86 %'
16115-sensores.png
Página web
15rota /history; largura 1280; sessão admin; lista Origem aberta com 3 sensores, dois marcados; recorte do cartão da esquerda
16215-calendario.png
Página web
15rota /history; largura 1280; sessão admin; mês de setembro de 2026 com os dias 1 a 23 destacados; dia 22 selecionado; recorte do calendário
16315-grafico-dois.png
Página web
15rota /history; largura 1280; sessão admin; dois sensores marcados, um DS18B20 e um DHT22; período 24h; legenda visível; tooltip aberto sobre um ponto; eixos °C e %RH
16415-baldes.png
Página web
15rota /history; largura 1280; sessão admin; um sensor DS18B20 de geladeira; período 7d; faixa mínimo-máximo visível em torno da linha média, com os ciclos de degelo; tooltip mostrando o valor e a faixa entre colchetes
16515-carregando.png
Página web
15rota /history; largura 1280; sessão admin; período MAX com 60 dias no aparelho; carga em andamento na metade, barra mostrando Arquivos: 31/60 e os KB recebidos, botão Cancelar visível
16615-celular.png
Página web
15rota /history; largura 390; sessão admin; um sensor; período 24h; tooltip aberto por toque
16715-exportando.png
Página web
15rota /history; largura 1280; sessão admin; exportação em andamento de um período 1M, caixa Exporting... com 45 %, tempo estimado, contagem OK e err, e o botão Cancelar
16816-transicao.png
Diagrama
16linha do tempo de 3 horas da família Telemetria: pontos cinza pequenos a cada envio (console), pontos grandes onde o registro vai para a flash; flash no 1º envio depois do boot, na 1ª falha (coletor cai), nenhuma nas falhas seguintes, na 1ª volta, e um por hora nos trechos estáveis; marcas 'Registros de rotina suprimidos (5), ctx = N' a cada hora
17016-eventos-celular.png
Página web
16rota /history; largura 390; sessão admin; seção Eventos do Sistema carregada, rolada até a tabela; só ERR marcado
17217-arquivos-leitura.png
Página web
17rota /files; largura 390; sessão de um operador com as permissões Painel, Histórico e Leitura; pasta raiz
17317-restaurar-confirmar.png
Página web
17rota /files; largura 1280; sessão admin; backup do próprio aparelho escolhido, validação concluída, janela de confirmação aberta com o número de arquivos e o tamanho
17417-restaurar-etapa3.png
Página web
17rota /files; largura 1280; sessão admin; aviso Etapa 3/3: Reiniciando dispositivo (~25 s)... visível
17517-aviso-firmware.png
Página web
17rota /files; largura 1280; sessão admin; botão Firmware tocado; janela de confirmação do navegador com o aviso de reformatação
17617-iniciar.png
Página web
17rota /files; largura 1280; sessão admin; backup simut_pre-ota já baixado pelo navegador (barra de downloads visível); segunda janela de confirmação aberta
17717-enviando.png
Página web
17rota /files; largura 1280; sessão admin; aviso Etapa 2/4: Enviando firmware (~30 s)... visível durante o envio
17817-ota-linha-tempo.png
Diagrama
17linha do tempo horizontal de uma atualização: 'backup .bkp baixado' (segundos, verde); 'envio e conferência da imagem, 35 a 36 s' (amarelo, rótulo 'sistema de arquivos já sobrescrito'); 'aplicação, cerca de 25 s' (vermelho, rótulo 'única janela em que um corte de energia exige BOOTSEL'); 'boot da imagem nova' (verde); marca 'interface web de volta, 52 a 56 s depois da aplicação'; embaixo, o que cada corte causa: arquivos perdidos com a configuração preservada, aparelho sem firmware, nada
17917-log-pos-ota.png
Página web
17rota /history; largura 1280; sessão admin; logo depois de uma atualização; seção Eventos do Sistema carregada com INF, WRN e ERR marcados; os dois registros Config alterada do módulo OTA, WRN e INF, no fim da lista
18018-bootsel.png
Foto
18um Pico W sendo ligado ao cabo USB com o polegar segurando o botão BOOTSEL; o botão em destaque, com uma seta; ao lado, a janela do gerenciador de arquivos do computador mostrando a unidade RPI-RP2
18119-modos.png
Diagrama
19máquina de estados com dois estados, M0 (acordado: web, console, Bluetooth, rádio) e M1 (ciclo: dormir, despertar, ler, gravar, dormir). Setas de M0 para M1: 'air hibernate' e 'ociosidade (air idle)'. Setas de M1 para M0: 'air stop pelo USB (desarma)', 'carregador no despertar (continua armado)', 'boot limpo (M0 pelo idle inteiro, depois volta)', 'watchdog (10 s de graça, depois volta)', '3 watchdogs seguidos (retido em M0, evento 411)'. Dentro de M1, o laço 'dormir → despertar → ler → gravar → [rádio se pendentes ≥ lote mínimo] → dormir'
18219-despertar.png
Diagrama
19linha do tempo de dois despertares num intervalo de 60 s: faixa GP16 alta durante cada despertar; despertar de leitura com boot, aquecimento 0,4 s, amostragem (a maior parte, com a conversão do DS18B20), decisão com 'grava o histórico', e sono até completar 60 s; despertar de telemetria com a amostragem e o Wi-Fi em paralelo, decisão, conexão e envio, faixa 'rádio ligado' só nele; marcas 9,3 s (leitura) e 12,7 s (telemetria)
18319-montagem.png
Foto
19um Air montado: Pico W com um DS18B20 e o resistor de 4,7 kΩ, a bateria e o carregador; os fios do GP16 e do GP17 identificados com etiquetas
18419-painel-controle.png
Página web
19rota /; largura 1280; sessão admin; imagem air em M0; 1 sensor DS18B20; cartão Registros Pendentes com alguns registros; sem o bloco de espelho do painel
18520-integracao.png
Diagrama
20Diagrama com o aparelho SIMUT à esquerda e quatro destinos à direita. Setas saindo do aparelho: 'Telemetria (HTTP/HTTPS POST ou MQTT/MQTTS)' e 'Linha de alarmes (mesmo transporte, com confirmação)' para o coletor; 'Descoberta Home Assistant (MQTT, mensagens retidas)' para o broker; 'Syslog RFC 5424 (UDP 514)' para o coletor de syslog. Setas chegando ao aparelho, na porta web: 'API REST com sessão' vinda do servidor de gestão; 'GET /metrics' vinda do Prometheus; 'mDNS _simut._tcp' como anúncio na rede local. Uma legenda separa 'o aparelho abre a conexão' de 'o servidor abre a conexão'.
18621-cursor.png
Diagrama
21Fila horizontal com os registros do histórico como pequenos quadrados, na ordem em que foram gravados. Uma marca vertical 'cursor' separa os registros já confirmados (cinza, à esquerda) dos pendentes (coloridos, à direita). Um colchete agrupa os primeiros pendentes como 'lote (até o Lote máximo)'. Uma seta leva o lote ao 'coletor'; a volta '2xx' move o cursor para o fim do lote; uma volta alternativa 'falha' deixa o cursor parado e aponta para 'espera e reenvia'. À direita, o bloco da hora aberta, ainda na RAM, também entra no lote.
19022-fluxo.png
Diagrama
22Diagrama em duas raias, HTTP e MQTT. À esquerda, a fila na RAM do aparelho com registros seq 1, 2 e 3. Raia HTTP: seta 'POST com a fila inteira' até o coletor; volta '2xx' e os três registros saem da fila; volta alternativa 'outro código ou nada em 4 s' e a fila fica, com 'novo envio em 15 s'. Raia MQTT: seta 'publish em <tópico>/alarm' até o broker e daí ao coletor; o coletor grava e publica a confirmação com os seq 1, 2 e 3 em '<tópico>/alarm/ack'; o broker entrega ao aparelho, que tira os três da fila. Uma nota mostra que, sem a confirmação, a fila inteira é publicada de novo a cada 15 s.
19223-fluxo.png
Diagrama
23Três caixas da esquerda para a direita: 'SIMUT (simut_0a1b2c)', 'Broker MQTT (broker.exemplo.com.br:1883)' e 'Home Assistant'. Setas do SIMUT para o broker, numeradas: 1 'ao conectar: homeassistant/sensor/simut_0a1b2c/<objeto>/config (retida, uma por medição)'; 2 'simut/status {status: online} (retida)'; 3 'simut/data {ts, tSTM0001, ...} a cada envio'. Seta tracejada do broker para o próprio broker: 'se o aparelho some: simut/status {status: offline} (última vontade)'. Setas do broker para o Home Assistant: 'assina homeassistant/# e cria dispositivo e entidades'; 'lê os valores em simut/data'; 'lê a disponibilidade em simut/status'. Nota no rodapé: 'o Home Assistant não manda nada ao aparelho'.
19423-evento-548.png
Página web
23rota /history; largura 1280; sessão admin; seção Eventos do Sistema carregada, com INF marcado e o filtro 548; uma linha do evento 548 Discovery HA atualizado com contexto 4, logo abaixo de 35 MQTT conectado
19524-coleta.png
Diagrama
24À esquerda, 'Prometheus (a cada 60 s)'; à direita, 'SIMUT 192.0.2.10'. Seta do Prometheus para o aparelho: 'GET /metrics, Authorization: Basic metricas:…'. Dentro do aparelho, uma caixa 'confere a senha (5.000 rodadas, cerca de 0,7 s)' e uma caixa 'endereço bloqueado?'. Quatro setas de volta: '200 texto do Prometheus', '401 senha errada', '403 conta sem Painel', '429 endereço bloqueado'. Embaixo, uma escada de bloqueio: '1º erro 2 s, 2º 4 s, 3º 8 s … 9º em diante 300 s', com a nota 'mesmo bloqueio da página de entrada'.
19624-conta-metricas.png
Página web
24rota /users; largura 1280; sessão admin; formulário Adicionar com Nome metricas, só a caixa Painel marcada, PIN vazio; a conta aparece na tabela com Pendente: Novo, ainda não gravada
19725-caminho.png
Diagrama
25Da esquerda para a direita: 'evento (qualquer núcleo)' → 'nível ≥ Nível Mínimo?' → 'fila de 8 linhas na RAM (a mais antiga sai quando enche)' → 'laço principal, núcleo 0: até 8 linhas por passada, só com Wi-Fi conectado e fora do AP' → 'UDP para 192.0.2.10:514' → 'coletor (rsyslog, syslog-ng)'. Marcas vermelhas de perda: 'antes do encaminhamento subir, no boot', 'fila cheia', 'envio falhou', 'datagrama perdido na rede', 'travamento ou falta de energia'. Uma seta lateral: 'reinício pedido (quase todos): esvazia a fila antes de reiniciar'. Embaixo, em paralelo, 'log de eventos na flash (filtro de rotina, só código e contexto)'.
19826-entrada.png
Diagrama
26diagrama de sequência entre um cliente e o aparelho: GET /api/login_init devolve nonce; o cliente calcula SHA-256 da senha; POST /api/login com user, pass e nonce; o aparelho confere e devolve Set-Cookie SIMUTSESS e o corpo {ok, redirect}; pedidos seguintes levam o cookie ou Authorization: Bearer; GET /logout encerra
19926-ota.png
Diagrama
26diagrama de sequência entre um cliente e o aparelho: GET /api/backup e conferência do CRC; POST /api/restore?op=stage&commit=1 com o .bin, resposta com v=0 e committed=1; POST /api/ota/apply, resposta 202; o aparelho reinicia; o cliente repete GET /api/login_init até responder; entra e lê a versão em /api/status; confere o .bkp com op=validate e o restaura com op=apply
20027-arquitetura.png
Diagrama
27diagrama: vários aparelhos SIMUT numa rede local; setas saindo deles para o coletor (telemetria e linha de alarmes, com X-SIMUT-Uid/Ver/Env/Cfg); setas do Prometheus para cada aparelho (GET /metrics, HTTP Basic); setas do gestor de frota para cada aparelho (API REST com cookie ou Bearer); um anúncio mDNS _simut._tcp saindo dos aparelhos release para a rede local; o gestor lendo o manifest.json da release no GitHub
20127-ondas.png
Diagrama
27diagrama: a frota dividida em três ondas; onda 0 com um aparelho de bancada, onda 1 com poucos aparelhos de cada imagem, onda 2 com o resto; entre as ondas, uma barreira 'conferir versão, telemetria e alarmes por um período'; dentro de cada aparelho, a sequência backup, envio, aplicação, confirmação, restauração, idioma
20228-flash.png
Diagrama
28barra horizontal dos 2 MB da flash do Pico W, em escala: 1.020 KiB do programa (com a marca do teto de 1.016 KiB da atualização web), 1.024 KiB do sistema de arquivos LittleFS e 4 KiB dos dados da atualização no fim; anotar que a imagem nova é recebida na área do sistema de arquivos

Apêndice B

Códigos de evento

Os 170 códigos que o log de eventos pode registrar, com o texto que o aparelho mostra em português. O número ao lado de cada registro no log é o contexto (ctx) do evento, explicado no capítulo 16. A lista é gerada de tools/logcodes.tsv, a mesma tabela de onde o firmware gera os seus.

CódigoNomeDescrição
0SYS_OKOK
1SYS_BOOTBoot do sistema
2SYS_REBOOT_USERReboot solicitado pelo usuário
3SYS_HEAP_LOWHeap baixa
4SYS_UPTIME_MARKMarco de uptime
5SYS_LOG_SUPPRESSEDRegistros de rotina suprimidos
10SYS_WIFI_CONNECTConectando WiFi
11SYS_WIFI_DISCONNECTWiFi desconectado
12SYS_WIFI_SCANVarredura WiFi
13SYS_NTP_SYNCNTP sincronizado
14SYS_IP_ACQUIREDIP obtido
15SYS_AP_STARTAP iniciado
20SYS_STORAGE_FAILFalha no storage
21SYS_STORAGE_SAVEConfig salva
22SYS_STORAGE_ROTATEStorage rotacionado
23SYS_STORAGE_FORMATFormatando flash
24SYS_STORAGE_RECOVERStorage recuperado
25SYS_STORAGE_MIGRATEDConfig migrada
30SYS_TEL_SENTTelemetria enviada
31SYS_TEL_FAILFalha de telemetria
32SYS_TEL_RETRYRetry de telemetria
33SYS_TEL_QUEUETelemetria enfileirada
34SYS_TEL_SSLCert SSL carregado
35SYS_TEL_MQTT_CONNMQTT conectado
36SYS_TEL_MQTT_DISCMQTT desconectado
37SYS_TEL_MQTT_PUBMQTT publicado
100LOG_SENSOR_RECSensor recuperado
101ERR_SENSOR_TIMEOUTTimeout de sensor
102ERR_SENSOR_CHECKSUMErro de checksum
103ERR_SENSOR_CRCErro de CRC
104ERR_SENSOR_RANGESensor fora de range
105ERR_SENSOR_MISMATCHDivergência de hardware
106ERR_SENSOR_MISSINGSensor ausente
200EVT_UI_TOUCHEvento de toque
201EVT_DISPLAY_RESTARTDisplay reiniciado
202EVT_GRAPH_RENDERGráfico renderizado
300SEC_LOGIN_SUCCESSLogin bem-sucedido
301SEC_LOGIN_FAILFalha de login
302SEC_UNAUTHORIZEDAcesso não autorizado
303SEC_CONFIG_CHANGEDConfig alterada
304SEC_SESSION_EXPIRESessão expirada
305SEC_FILE_UPLOADArquivo enviado
306SEC_FILE_DELETEArquivo apagado
307SEC_BT_LOCKOUTBloqueio Bluetooth
308SEC_PIN_OKPIN do painel aceito
309SEC_PIN_FAILPIN do painel recusado
310SEC_PIN_LOCKOUTBloqueio do PIN do painel
311SEC_PIN_AMBIGUOUSEntrada do teclado casa com duas contas
312SEC_SESSION_REVOKEDSessão encerrada: conta alterada
400APP_DISPLAY_LAUNCHEDDisplay iniciado no Core 1
401APP_TOUCH_CAL_INITIALCalibração inicial do touch salva
402APP_TOUCH_CAL_REQUIREDCalibração do touch necessária
403APP_AP_MODE_TRIGGEREDAP iniciado
404APP_READYSistema pronto
405APP_READY_APSistema pronto (modo AP)
406APP_STORAGE_CRITICALFalha crítica de storage
407APP_SENSORS_CALIBRATEDSensores calibrados
408APP_NTP_CORRECTINGNTP corrigindo timestamps
409APP_NTP_CORRECTEDTimestamps corrigidos
410APP_CACHE_INVALIDATEDCaches de gráfico invalidados
411APP_AIR_CYCLE_HELDCiclo Air retido em M0
412APP_AIR_COLD_BOOTBoot frio, não veio da hibernação
413APP_AIR_SLEEP_CLAMPEDSono limitado a menos de 24 h (alarme é por hora do dia)
414APP_AIR_WAKE_INCOMPLETEWake anterior do Air não completou
440APP_UI_THEME_CHANGEDTema alterado via UI
441APP_UI_LANG_CHANGEDIdioma alterado via UI
442APP_UI_ALARM_SAVEDLimites de alarme salvos via UI
443APP_UI_TOUCH_CAL_SAVEDCalibração do touch salva
444APP_UI_TOUCH_SENS_SAVEDSensibilidade do touch salva
445APP_UI_PIN_CHANGEDPIN do display alterado
446APP_UI_SOUND_SAVEDConfig de som salva
447APP_UI_ALARM_SILENCEDAlarme silenciado via UI
448APP_UI_ALARM_SILENCE_EXPSilenciamento de alarme expirou
449APP_UI_ALARM_DEACTIVATEDTodos alarmes desativados (RAM)
450APP_UI_USER_ADDEDUsuário criado pelo painel
451APP_UI_USER_DELETEDUsuário removido pelo painel
452APP_UI_USER_PIN_SETPIN do painel definido
453APP_UI_USER_PERMSPermissões alteradas pelo painel
454APP_UI_MAINT_ONManutenção aberta pelo painel
455APP_UI_MAINT_OFFManutenção encerrada pelo painel
456APP_UI_ALARM_BLOCKEDAlarmes do sensor bloqueados pelo painel
457APP_UI_ALARM_UNBLOCKEDAlarmes do sensor desbloqueados pelo painel
458APP_UI_PERM_DENIEDAção do painel recusada: sem permissão
459APP_UI_PIN_POLICYPolítica de PIN alterada pelo painel
470APP_ALARM_TRIGGEREDAlarme disparado
471APP_ALARM_CLEAREDAlarme zerado
472APP_ALARM_SILENCE_CANCELSilenciamento cancelado
480APP_CACHE_MINMAX_FULLCache Min/Max carregado
481APP_CACHE_MINMAX_PARTIALCache Min/Max parcial
482APP_CACHE_GRAPH_STARTEDRefresh de cache iniciado
483APP_CACHE_GRAPH_DONERefresh de cache concluído
484APP_CACHE_GRAPH_AMBIENTCache de gráfico: ambiente
485APP_CACHE_GRAPH_BOARDCache de gráfico: placa
486APP_CACHE_PRELOAD_DONEPré-carga de cache concluída
487APP_GRAPH_LOADINGCarregando gráfico
488APP_GRAPH_BUDGETBudget de render excedido
489APP_PRELOAD_BUDGETBudget de pré-carga excedido
500APP_DISPLAY_PAUSE_STUCKPause do display preso >5s
501APP_YIELD_STUCKYield preso >10s
502APP_CORE1_DEADCore 1 travado >10s, reiniciando
503APP_FLASH_BUSYColisão por flash ocupado
510APP_HISTORY_SAVEDRegistro de histórico salvo
511APP_HEAP_REPORTRelatório de heap
512APP_HIST_NO_TIME_REFHistórico pulado: sem referência de hora
513APP_HIST_TIME_REF_RECOVEREDHistórico retomado: referência de hora obtida
514APP_HIST_NO_SCHEMAHistórico pulado: schema V4 vazio
515APP_HIST_SCHEMA_MISMATCHHistórico pulado: schema não cobre sensor ativo
520NET_DHCP_MODEModo DHCP ativado
521NET_STATIC_MODEModo IP estático ativado
522NET_STARTINGGerenciador WiFi iniciando
523NET_SSID_MISSINGSSID WiFi não configurado
524NET_PROVISIONAL_TIMEHora provisória do flash
525NET_CONNECT_TIMEOUTTimeout na conexão WiFi
526NET_DORMANT_MODEWiFi em modo dormente
527NET_SHOW_IPMostrar IP
528NET_MDNS_FAILFalha ao iniciar mDNS
529NET_WIRED_STARTINGRede cabeada iniciando
530NET_WIRED_MODULE_FAILMódulo de rede não iniciou
531NET_WIRED_NO_ADDRESSSem endereço no cabo
532NET_WIRED_LOSTRede cabeada perdida
540TEL_HTTP_INITTransporte HTTP inicializado
541TEL_MQTT_INITTransporte MQTT inicializado
542TEL_MQTT_CONNECTINGMQTT conectando
543TEL_CERT_EMPTYcert.pem vazio, modo inseguro
544TEL_CERT_READ_ERRErro de leitura de cert.pem
545TEL_CERT_MISSINGSem cert.pem, modo inseguro
546TEL_FORCE_SYNCForçando sync de telemetria
547TEL_BACKOFF_SUPPRESSEDLogs de retry suprimidos
548TEL_HA_DISCOVERYDiscovery HA atualizado
549TEL_ALARM_LINE_ONLinha de telemetria de alarmes ligada
550TEL_ALARM_SENTPayload de alarmes enviado
551TEL_ALARM_FAILFalha no envio de alarmes
552TEL_ALARM_ACKRecebimento de alarmes confirmado
553TEL_ALARM_DROPEstouro da fila de alarmes
554TEL_CURSOR_RESENTArquivo do dia reenviado pela telemetria
560STO_WRITE_FAILEDFalha em escrever histórico
561STO_CORRECT_BUDGETBudget de correção de ts excedido
562STO_ENFORCE_BUDGETBudget de limite de storage excedido
563STO_ENFORCE_SKIP_ACTIVEPulando arquivo de log ativo
564STO_STATS_REPORTRelatório de estatísticas
565STO_CONFIG_REPORTRelatório de config
566STO_H5_SEALEDBloco de histórico selado
567STO_H5_WIPSnapshot de histórico gravado
568STO_SCHEMA_MISMATCHSchema de histórico divergente
569STO_LEGACY_PURGEDHistórico legado apagado
570WEB_SERVER_STARTEDServidor web iniciado
571WEB_DISCONNECT_FILECliente desconectado (arquivo)
572WEB_DISCONNECT_HISTORYCliente desconectado (histórico)
573WEB_SCREENSHOT_ABORTEDScreenshot abortado pelo cliente
574WEB_UPLOADArquivo enviado
575WEB_CLIENT_DISCONNECTCliente desconectado (conexão encerrada)
576WEB_CERT_INVALIDCertificado web inválido (HTTP)
577WEB_CORS_ORIGINCORS ligado para a origem
578WEB_CORS_INVALIDOrigem CORS inválida (CORS desligado)
579WEB_CERT_INSTALLEDPar de certificados web instalado
580CFG_THEME_APPLIEDTema aplicado
581CFG_THEME_NOT_FOUNDTema não encontrado
585CLI_UNKNOWN_CMDComando desconhecido
590SENSOR_RUNTIME_LOADEDSensores em runtime carregados
600DSP_FORCE_UNPAUSEForçar despausar
610OTA_TRIAL_STARTEDAtualização em teste
611OTA_TRIAL_CONFIRMEDAtualização confirmada
612OTA_TRIAL_EXPIREDAtualização não confirmada a tempo
613OTA_TRIAL_REVERTEDAtualização revertida
614OTA_TRIAL_BUY_FAILEDFalha ao confirmar a atualização
620I18N_PACK_LOADEDPacote de idioma carregado
621I18N_PACK_OUTDATEDPacote de idioma mais antigo que o firmware
622I18N_PACK_MULTIPLEMais de um pacote de idioma em /lang
623I18N_PACK_FAILEDFalha ao carregar o pacote de idioma
999ERR_UNKNOWNErro desconhecido

Apêndice C

Histórico de versões

O que cada versão da linha 2.x trouxe para quem usa o aparelho, da mais nova para a mais antiga. O registro completo, com as medições de cada mudança, está no CHANGELOG.pt-BR.md do repositório.

Linha 2.11 — estável

Versão Data O que trouxe
v2.11.1 12/10/2026 Correções de quatro achados altos da revisão e da política de PIN. A troca obrigatória de PIN não é mais pulada com SAIR (capítulo 8), e o painel só concede as permissões que a conta identificada tem (capítulo 8). Uma política de PIN mais exigente não tranca mais um PIN mais curto: ele identifica e leva à troca, e a mensagem de PIN curto diz o mínimo (capítulo 8). Adotar a sonda ligada aqui lê o GPIO do slot e recarrega os sensores (capítulo 6). O AP aberto pelo gesto no boot segue o prazo de 15 min (capítulo 9), e a página Arquivos explica a recusa v=6 (capítulo 17).
v2.11.0 04/10/2026 O Pico 2 W (RP2350) passa a ter imagens publicadas: o .uf2 de fábrica, com a tabela de partições, e o .bin de atualização (capítulo 3). Pela rede, ele grava a imagem nova no slot de onde não subiu, sem tocar no sistema de arquivos, e a imagem sobe em teste: fica depois de um minuto saudável, e volta sozinha para a anterior se não se confirmar em cinco minutos ou se o aparelho reiniciar antes. O painel e a página Arquivos dizem quando a versão está em teste e quando voltou (capítulo 26). Uma transferência longa não cai mais com outra página do aparelho aberta no navegador (capítulo 18), e gravar a configuração da alpha não a reinicia mais pelo watchdog

Linha 2.10 — estável

Versão Data O que trouxe
v2.10.0 03/10/2026 A telemetria envia cada registro pelo lugar onde ele foi gravado, não pela hora: um relógio que volta não deixa mais registros sem envio, e um arquivo do dia cuja posição deixou de ser confiável vai inteiro de novo (capítulo 21). Gravar contas não reinicia mais o aparelho, e uma sessão web termina quando a conta dela é excluída ou tem a senha trocada por outra pessoa (capítulo 8). Um nome sem conta custa na entrada o mesmo tempo que uma senha errada. O ensaio da página de configuração não mexe mais no aparelho em funcionamento: o silêncio geral, o fuso e os campos da área de extensão só valem depois de gravados (capítulo 5). Uma restauração que falha no meio fica com os arquivos que terminou, sem o limite de 200 arquivos, e a aplicação exige antes a conferência do mesmo backup (capítulo 17). Um limite de alarme que não é número é recusado em vez de virar 0 (capítulo 26). O menu Configurações do painel segue a ordem de uso, um grupo por página (capítulo 11). A página Arquivos abre arquivos de texto organizados (capítulo 17), e a Prévia ao Vivo da telemetria é montada com os dados do aparelho, com um registro de cada tipo (capítulo 21 e capítulo 22)

Linha 2.9 — estável

Versão Data O que trouxe
v2.9.0 02/10/2026 Pelo ar, o aparelho só instala imagem assinada pelo projeto: o .bin de uma release ou uma build do configurador; uma build própria vai pelo USB (capítulo 17). O painel mostra cada etapa de uma atualização, e o motivo de uma recusa (capítulo 11). O ponto de acesso de configuração só abre quando pedido, e o aparelho continua medindo, gravando e alarmando com ele no ar (capítulo 9). Uma unidade sem rede configurada pede a data e a hora no fim do boot, e Configurações → Data e hora abre a mesma tela (capítulo 10). SDA e SCL trocados não travam mais o boot (capítulo 2). “NTP sincronizado” passa a querer dizer que a hora foi acertada de verdade (capítulo 10). Uma borda de alarme recusada pela fila cheia sai quando há espaço (capítulo 22). A tela Licença mostra a abertura no idioma do pacote, o texto MIT em inglês e todos os componentes de terceiros (capítulo 11)

Linha 2.8 — estável

Versão Data O que trouxe
v2.8.0 30/09/2026 Um envio de firmware cortado ou recusado não leva mais a configuração: a cópia que atravessa a atualização é gravada no início do envio, o aparelho grava a configuração de volta assim que um envio termina sem aplicação, e o boot seguinte usa a cópia uma vez e a apaga. Os demais arquivos continuam voltando só pelo backup, e a proteção vale a partir de um aparelho que já tem a v2.8.0 (capítulo 17). No formato Dinâmico, cada linha de telemetria ganha o campo Cabeçalho Content-Type, que antes era sempre text/plain; vazio, vale application/json (capítulo 21 e capítulo 22). A configuração passa à versão 26 do formato: uma versão anterior gravada depois dela não a lê e volta com a configuração de fábrica (capítulo 3)

Linha 2.7 — estável

Versão Data O que trouxe
v2.7.4 26/09/2026 Procurar sondas não deixa mais em erro um BMP280 ou BME280 nos pinos de I²C de hardware (capítulo 6). Mudar só Amostra (ms) ou Registro Local, que não têm efeito, grava sem reiniciar (capítulo 5). Na alpha e no Air, a página Configurações perde a seção Calibração do Touch, e as rotas dos temas e da calibração do painel deixam de responder (capítulo 26). O site ganha o configurador de build, que monta uma imagem com outro conjunto de recursos (capítulo 3)
v2.7.3 25/09/2026 A página de entrada mostra a versão do firmware (capítulo 13). A página Configurações ganha o botão Reiniciar sem salvar, que reinicia o aparelho e descarta o que a página não salvou (capítulo 5). O ícone da aba e o logotipo da página de entrada passam a seguir a marca nova
v2.7.2 24/09/2026 O Air carrega o relógio através do sono: os carimbos ficam dentro de ±0,09 s em vez de atrasar 0,8 s a cada despertar (capítulo 19). A telemetria monta cada envio um registro inteiro por vez: uma fila longa não sai mais como JSON inválido nem pula registros (capítulo 21). Com um sensor, o LCD do alpha mostra quantos registros esperam envio, e o ícone de Wi-Fi cresce da esquerda para a direita (capítulo 12). No painel, as setas da tela Segurança do PIN movem a seleção em vez de fechá-la, apertar a política marca as contas para trocar o PIN, e o Modo de Configuração mostra a rede, a chave e o endereço do AP (capítulo 11). Os nomes dos eventos vêm do pacote de idioma. Toda imagem fica 16 kB menor
v2.7.1 22/09/2026 O ponto de acesso de configuração volta a aceitar conexões: um celular entra em 4,1 s. O AP abre sozinho num aparelho sem rede configurada ou que perdeu a sua. O painel ganha a linha 12 em Configurações, e o LCD do alpha mostra o nome e a chave da rede
v2.7.0 22/09/2026 A linha sai do beta com base em medições: 8,18 h sem reinício e 6 de 6 atualizações pelo ar sem perda. Corrige o V-09 (uma conta restrita podia criar outra com mais permissões do que tinha). A autópsia de travamento passa a guardar mais três registros

Linha 2.6

Versão Data O que trouxe
v2.6.1-beta 21/09/2026 Busca de redes Wi-Fi na página Rede, inclusive de dentro do ponto de acesso. A interface web passa a ter só o que cada imagem usa
v2.6.0-beta 20/09/2026 No painel, a conta é escolhida antes do PIN, e a política de PIN passa a ser configurável. O PIN só é compilado onde há painel de toque

Linha 2.5

Versão Data O que trouxe
v2.5.0-beta 20/09/2026 O painel passa a saber quem está diante dele: 32 contas, cada uma com o seu PIN, três permissões de alarme e o teclado embaralhado. Um servidor passa a editar alarmes ao vivo e a abrir janelas de manutenção. O espelho do painel cai de 613 para 213 ms por quadro

Linha 2.4

Versão Data O que trouxe
v2.4.10-beta 18/09/2026 Espelho do painel mais rápido (leitura a 6 MHz). O console completo volta ao Air. POST /api/tls instala o par de certificados num aparelho em serviço
v2.4.9-beta 18/09/2026 A imagem release devolve 57 kB de flash sem abrir mão de recursos. O painel superior passa a ter um gesto por função: toque curto mostra mín/máx, segurar fixa a seleção
v2.4.7 e v2.4.8-beta 18/09/2026 O painel ao vivo no navegador, e clicável
v2.4.1-beta 08/09/2026 O despertar do Air fica 2,7× mais curto. O reset de senha do console sobrevive ao boot seguinte. A auditoria de segurança de 07/09/2026 é fechada
v2.4.0-beta 07/09/2026 Chega o SIMUT Air, imagem sem display com ciclo de hibernação (experimental). O bloco do histórico sobrevive a um despertar

Linha 2.3

Versão Data O que trouxe
v2.3.5 a v2.3.9-beta 24 a 29/08/2026 O alpha ganha Bluetooth e mostra vários sensores. A interface web abre no idioma instalado. A página de licença é reescrita
v2.3.4 24/08/2026 A linha 2.3 fica estável, depois de uma dieta de RAM que manteve todos os recursos
v2.3.3-beta 23/08/2026 Os alarmes ganham a própria linha de telemetria, e o erro de sensor passa a ser um alarme
v2.3.0 a v2.3.2-beta 20 e 21/08/2026 Páginas HTTPS carregam em um terço do tempo (keep-alive). A piscada branca entre páginas some

Linha 2.2

Versão Data O que trouxe
v2.2.16 a v2.2.18-beta 19 e 20/08/2026 O servidor web por HTTPS fica utilizável no navegador, e uploads por HTTPS param de falhar
v2.2.13 e v2.2.14-beta 19/08/2026 Home Assistant (MQTT Discovery), /metrics para Prometheus e syslog remoto (RFC 5424)
v2.2.8 a v2.2.12-beta 17 a 19/08/2026 A interface web inteira volta para dentro do firmware. Os gráficos passam a ter renderizador próprio, sem CDN
v2.2.5-beta 16/08/2026 Cada permissão passa a ser conferida onde o dado é lido. O log passa a registrar transições, não batimentos
v2.2.0 a v2.2.4-beta 15 e 16/08/2026 Reforma visual da interface web, com tema escuro. Correções no relógio provisório e no histórico da meia-noite

Linha 2.1

Versão Data O que trouxe
v2.1.10 14/08/2026 A linha 2.1 fica estável. É a versão que o manual ilustrado anterior retratava
v2.1.5 a v2.1.9-beta 12 a 14/08/2026 Sistema visual único no painel, com acentos e desenho por DMA. Gráficos em baldes de tempo com a banda de mín/máx. Teclado de senha para a ponta do dedo
v2.1.0 a v2.1.4-beta 10 e 11/08/2026 A restauração passa a conferir quem pede antes de gravar. A hora ainda aberta na RAM chega aos gráficos e ao CSV

Linha 2.0

Versão Data O que trouxe
v2.0.1 a v2.0.3-alpha 01 a 10/08/2026 O histórico passa a ser gravado em blocos de uma hora: uma corrupção custa uma hora, não um dia. Curvas de calibração de até 5 pontos. O envio da telemetria resiste a uma rede hostil