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.
01-arquitetura.pngdiagrama 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 consoleVersõ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
.uf2de fábrica, que traz a tabela de partições, e o.binde 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.
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.
02-pinos-release.pngvista 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ádio02-pinos-alpha.pngvista 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 uso02-pinos-air.pngvista 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 usoA 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).
02-air-energia.pngGP16 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'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).
02-ds18b20.pngsonda 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 3V3DHT22
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.
02-dht22.pngmó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'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
0x76e, sem resposta, em0x77. - 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.
02-bmx280.pngmó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'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:
- Um sensor por par. A leitura do aparelho aceita dois sensores no mesmo par, em
0x76e0x77, mas a página Configurações e o console recusam dois slots ativos no mesmo GPIO. Dê a cada sensor o seu par. - 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
ctxigual 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
S0aS10, 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.
02-placa.pngplaca 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ívelLista de conferência da montagem
Antes de ligar o aparelho pela primeira vez:
- O GND do Pico W, da tela e de todos os sensores está ligado entre si.
- Os sensores e os pull-ups vão no 3V3 (pino 36), não no 5 V.
- alpha O LCD vai no 5 V (pino 40), com o R/W no GND e o potenciômetro de contraste no VO.
- Cada DS18B20 tem o resistor de 4,7 kΩ do dado ao 3V3, e há uma sonda por GPIO.
- Cada BME280 ou BMP280 tem o seu par, com SDA e SCL nos papéis da tabela do I²C.
- Nenhum sensor está em GP16 ou acima.
- release O TFT e o toque compartilham MISO, MOSI e SCK, com CS separados: GP28 para o TFT e GP17 para o toque.
- Anote qual sensor está em qual GPIO: a configuração dos slots pede essa informação (capítulo 6).
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).
03-arquivos.pngos 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)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.
- Desligue o cabo USB do Pico W.
- Aperte e segure o botão BOOTSEL, o único botão da placa.
- Ligue o cabo USB ao computador, ainda segurando o botão.
- Solte o botão. O computador mostra uma unidade de disco chamada
RPI-RP2. - Copie o arquivo
.uf2para a unidadeRPI-RP2. - Espere. A unidade some sozinha, e o Pico W reinicia já com o SIMUT.
03-bootsel.pngmã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 RP2040A 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):
- Entre na interface web com uma conta que tenha as permissões Leitura PERM_FILE_READ e Upload PERM_FILE_UPLOAD. O
admintem as duas. - Abra a página Arquivos e a pasta
/lang. - Toque em Enviar e escolha
language_pt-BR.lng, o da mesma versão do firmware. - Confira se o arquivo aparece na pasta com o tamanho certo.
- 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.
- Em Produto, escolha SIMUT (a imagem release), SIMUT Alpha, SIMUT Air ou SIMUT para o Pico 2 W.
- 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.
- 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.
- 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.uf2de 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
maine informa a versão damain, que pode estar à frente da última versão publicada. Sem mudanças, a página aponta a última versão publicada, porque compilar gera amainde 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
.binnum 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.shaplica 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
zopflicomprime 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_alphaoupico_w_air. Opio runsem-ecompila só apico_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
.sim4da pasta/historysão apagados no primeiro boot. Baixe-os antes de atualizar e converta-os no computador, com a ferramentatools/history_v5.pydo 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.
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
- 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).
- Ponha o aparelho na rede: abra o ponto de acesso de configuração com o comando
apou pelo menu do painel, ou grave a rede pelo console (Pôr o aparelho na rede). - Entre na interface web e troque a senha (A primeira entrada na web).
- Instale o pacote de idioma e confira o fuso e a hora (Idioma, fuso e hora).
- Configure o primeiro sensor (O primeiro sensor).
- release Troque o PIN de fábrica do painel (O PIN do painel).
- Confira a lista final (Pronto para usar).
04-fluxo.pngfluxograma 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'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
picocomou 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.
04-painel-data-hora.pngrelease 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 inicialNo 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.
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.1Na 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
apfunciona também pelo Bluetooth, e o LCD alterna o endereço, a rede e a chave (capítulo 12).No celular ou no computador, conecte-se à rede
simut_SETUPcom a chave.Abra
http://192.168.4.1. A página de entrada aparece.Entre como
admin, com a senha inicial.Defina a senha nova na página Bem-vindo! (capítulo 13).
Abra a página Rede, toque em Buscar, escolha a sua rede e digite a senha dela (capítulo 9).
Toque em Salvar e reiniciar na barra de topo.
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).
04-painel-ap.pngrelease 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 publicar04-lcd-ap.pngalpha 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 baixoap: 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
- No navegador, abra o endereço do aparelho, como
http://192.0.2.10. - Entre como
admin. - 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
- Idioma. Envie
language_pt-BR.lngpara 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). - 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).
- 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
timeno console; na release, também pela pergunta do boot ou pelo item 13 do menu, Data e hora (capítulo 10).
O primeiro sensor
- Abra Configurações e role até Sensores e GPIO.
- Toque em + Adicionar slot de sensor.
- Escolha o tipo, o GPIO de cada pino, o ID de Hardware e o Nome, e ligue Ativo.
- 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).
- Na tela inicial, toque em CFG, na barra de botões de baixo, logo depois do último sensor (capítulo 11).
- Na tela Quem está usando o painel?, toque em
admine depois em ENTRAR. - Digite
1234e toque em ENTRAR. - O painel abre a tela Novo PIN. Digite o PIN novo e toque em ENTRAR.
04-novo-pin.pngrelease com configuração de fábrica; tela inicial → botão de configurações → admin → PIN 1234 → ENTRAR; tela Novo PIN aberta, antes de digitarO 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:
- A senha do
adminfoi trocada e está guardada em lugar seguro. - A conta
viewertem senha nova ou foi excluída (capítulo 8). - O aparelho está na rede, e você sabe o endereço dele (Encontrar o endereço).
- A chave do ponto de acesso está anotada (capítulo 9).
- 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. - Há um só pacote de idioma na pasta
/lang(capítulo 3). - Cada sensor aparece no Painel de Controle com leituras plausíveis (capítulo 6).
- Os limites de alarme de cada sensor estão definidos (capítulo 7).
- release O PIN do
adminnão é mais1234, e cada operador tem a sua conta com PIN (capítulo 8). - A telemetria e a linha de alarmes estão configuradas, se houver servidor (capítulo 21, capítulo 22).
- Um backup da configuração foi baixado (capítulo 17).
- air O ciclo de hibernação foi conferido (capítulo 19).
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.
05-selo-reinicio.pngrota /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 topoOs 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:
- Faça a alteração, por exemplo um limite de alarme.
- Espere o selo mostrar Não exige reinício.
- 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:
- Faça as alterações.
- Espere o selo mostrar Não exige reinício.
- 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:
- Faça as alterações.
- Toque em Salvar e reiniciar.
- 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.
05-tres-botoes.pngrota /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ões05-confirmacao.pngrota /config; largura 1280; sessão admin; Nome do aparelho alterado; janela de confirmação aberta depois de tocar em Salvar e reiniciarOs 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_intounet.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:
- O painel mostra Aplicando configurações… e depois Reiniciando o sistema…, cerca de 1,5 s cada.
- O aparelho grava a configuração, registra o evento e responde à página.
- O aparelho reinicia. Uma gravação de histórico ou de log em andamento é interrompida.
- 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:
- Identidade (General Identity)
- Data e Hora (Date & Time)
- Hardware (Hardware & Sampling)
- Sensores e GPIO (Sensors & GPIO)
- Syslog Remoto (Auditoria) (Remote Syslog (Audit Trail))
- release Calibração do Touch (Touch Calibration)
- 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.
05-erro-carga.pngrota /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 desabilitadosIdentidade
| 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.
05-data-hora.pngrota /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 AgoraHardware
| 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.
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.
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.
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:
- Toque em Resetar Calibração.
- Confirme em Resetar calibração do touch para padrão de fábrica?
- 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:
- Toque em Reiniciar sem salvar.
- 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.
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
| 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 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
GP0aGP15. 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
0x76e0x77, 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
06-editor-ds18b20.pngrota /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çãoO 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
- Abra Configurações e role até Sensores e GPIO.
- Toque em + Adicionar slot de sensor. O editor abre no slot livre de menor número.
- Escolha o Tipo. O formulário ganha um seletor para cada pino do tipo.
- Escolha o GPIO de cada pino em Atribuição de GPIO.
- Digite o ID de Hardware, por exemplo
FREEZER-1. - Digite o Nome, por exemplo
Freezer da sala 2. - Ligue Ativo.
- Confira se a linha de aviso vermelha está vazia.
- Toque em Concluído.
- 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.
06-editor-bme280.pngrota /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 gravadoUm 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
- Na tabela, toque na linha do slot.
- Mude os campos.
- Toque em Concluído.
- 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
- Na tabela, toque na linha do slot.
- Toque em Liberar slot.
- Confirme a pergunta Liberar este slot? Tipo, GPIOs e identificação serão apagados.
- 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 |
06-editor-aviso.pngrota /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.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.
- Toque em Procurar sondas. O botão fica desativado e a página mostra Procurando… (Scanning…).
- Espere o resultado, que chega em poucos segundos. A página espera no máximo 10 s.
- 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.
06-procurar.pngrota /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 resultadoGrandezas 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
ERROem letras grandes. O mesmoERROaparece 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.
06-painel-sensor.pngscreen dash; 2 sensores ativos (um DS18B20 e um BME280), ambos lendo, nenhum em alarme06-painel-erro.pngscreen dash; 2 sensores ativos; a sonda DS18B20 desligada do pino há mais de 3 leituras, alarmes do slot ligados06-lcd-erro.pngimagem alpha; 1 sensor DHT22 ativo e desligado do pino; o LCD mostra ERRO em letras grandesOperaçõ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.
- Abra o editor do slot.
- 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.
- Abra o editor do slot.
- Toque em Resetar época do histórico (Reset history epoch).
- 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.
- 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.
- Toque em Recompor o histórico agora e confirme.
- 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
06-calibracao.pngrota /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çãoPara 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:
- Ponha o sensor e o instrumento de referência no mesmo ambiente e espere os dois estabilizarem.
- Abra o editor do slot.
- Na grandeza a corrigir, toque em + Adicionar ponto.
- 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.
- Digite em Referência o valor que o instrumento mostra.
- Para mais pontos, mude o ambiente (por exemplo, outra temperatura), espere estabilizar e repita os passos 3 a 5.
- Escolha Reta ou Suave.
- Confira se a linha de aviso vermelha do bloco está vazia.
- 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.
06-calibracao-suave.pngrota /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ção06-calibracao-ntp.pngrota /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.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.
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.
07-painel-falha.pngscreen dash; 2 sensores ativos; o DS18B20 do cartão de baixo desligado do pino há mais de 3 leituras; captura na fase âmbar da piscadaNo 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 |
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).
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:
- Toque no cartão que pisca.
- Toque em Desativar.
- Escolha a conta na lista Quem está usando o painel? (capítulo 8).
- 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.
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:
- Abra Alarmes e Sons.
- Digite o novo valor no campo.
- 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
| 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.
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.
07-menu-sensor-manut.pngmenu 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, sensorLimites 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.
- Toque na barra do limite.
- 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.
- 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.
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
- No menu do sensor, toque em Manutenção e depois em ENTRAR.
- 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.
- 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.
07-manutencao-entrada.pngmenu do sensor -> Manutenção -> ENTRAR; sessão admin; janela fechada; Horas 2 e Minutos 30 ajustados, antes de INICIAR07-manutencao-aberta.pngmesmo caminho, com a janela aberta há alguns minutosPela 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;
0fecha a janela; - um valor negativo é recusado, e um valor acima de 30 dias é cortado; nos dois casos o campo volta na lista
rejectedda resposta; - a consulta de alarmes informa, por sensor, quantos segundos faltam para a janela fechar, e
0quando 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.
07-melodia.pngtela Config. de Sons; som Alarme desligado; toque na linha Alarme duas vezes para abrir a escolha de melodia07-mudo-confirmar.pngtela 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 sozinhaA 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.
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
/historyexige 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.
08-usuarios.pngrota /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 pendenteA 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.
08-usuarios-permissoes.pngrota /users; largura 390; sessão admin; selo de permissões de uma conta de operador aberto, mostrando os nomesCriar 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:
- Digite o Nome.
- Marque as permissões.
- Se a pessoa vai usar o painel, digite um PIN em PIN do painel (opcional).
- Toque em Criar. A conta aparece na tabela com Pendente: Novo.
- Toque em Aplicar agora na barra de topo.
- Copie a senha que aparece na janela Senha temporária (Temporary password).
- Toque em Guardei — recarregar (I saved it — reload).
08-usuarios-nova.pngrota /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 desfazerA 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).
08-senha-temporaria.pngrota /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íciaMudar 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:
- Toque em Excluir na conta e confirme Excluir?.
- Crie a conta de novo, com o mesmo nome e as permissões novas.
- Toque em Aplicar agora.
- 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
- Toque em Excluir na linha da conta.
- Confirme a pergunta Excluir?.
- 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
- Toque em Reset na linha da conta.
- Confirme a pergunta Forçar reset?.
- Toque em Aplicar agora.
- 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.
- Toque em PIN na linha da conta.
- Digite o PIN, ou deixe vazio para apagar o PIN da conta.
- Toque em OK. A linha mostra Pendente: PIN.
- 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
- Na tela inicial, toque em CFG, na barra de botões de baixo, logo depois do último sensor (capítulo 11).
- Na tela Quem está usando o painel?, toque na sua conta para selecioná-la e toque de novo, ou toque em ENTRAR.
- Digite o PIN no teclado (O teclado).
- 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.
08-quem.pngscreen pin; contas admin, operador1 e manutencao com PIN; nenhuma bloqueadaO 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:1a9em três linhas e o0sozinho no meio da quarta; - com
0-9 A-Z, nove teclas de grupo,0-9,ABC,DEF,GHI,JKL,MNO,PQRS,TUVeWXYZ. 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.
08-teclado-3.pngscreen pin e escolha de uma conta; política de fábrica: 0-9, 3 por tecla; dois caracteres já digitados08-teclado-alfa.pngscreen pin e escolha de uma conta; política 0-9 A-Z, 1 por tecla; grupo PQRS aberto08-teclado-numerico.pngmenu > Alterar Senha, sessão admin; política de fábrica; tela Novo PIN com três dígitos digitadosPIN 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.
08-pin-invalido.pngscreen pin, escolha de uma conta, um PIN errado e ENTRAR; logo depois da recusa08-espera.pngscreen pin; a mesma conta errou o PIN três vezes seguidas; durante a espera de 5 s08-painel-bloqueado.pngtela do teclado depois de 20 tentativas erradas somadas, sem nenhuma entrada certa no meioO 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).
- Toque em Alterar Senha.
- Na tela Novo PIN, digite o PIN novo no teclado ordenado e toque em ENTRAR.
- 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 é.
08-pin-em-uso.pngmenu > Alterar Senha; digitar duas vezes um PIN que outra conta já usaA 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-Ztorna 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.
- 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 entre0-9e0-9 A-Z. - 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.
08-politica.pngmenu > Segurança do PIN, sessão admin; política de fábrica; linha Teclado selecionada08-politica-web.pngrota /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 escolhidosUsuá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,BeMà 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.
08-usuarios-lista.pngscreen usr; contas viewer, operador1 (com PIN, L e B) e manutencao (com PIN, M)Criar uma conta no painel:
- Toque em NOVO.
- Digite o nome no teclado de texto, com até 15 caracteres, e toque em OK. O X do título volta à lista.
- 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.
- Toque em SEGUIR.
- 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).
08-novo-nome.pngscreen usr -> NOVO; nome manutencao digitado08-novo-permissoes.pngscreen usr -> NOVO -> nome -> OK; Editar limites e Manutenção em SIM08-novo-pin.pngmesmo caminho -> SEGUIR; tela Novo PIN com o teclado ordenadoEditar 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:
- No editor da conta, toque em Excluir usuário.
- 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.
08-excluir.pngscreen usr -> conta manutencao -> Excluir usuárioAuditoria
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) |
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.
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:
- Desligue DHCP.
- Preencha IP Estático, Máscara e Gateway.
- Na seção Configuração de DNS, desligue Obter DNS automaticamente (DHCP) e preencha DNS Primário (DNS).
- Toque em Salvar e reiniciar.
- 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.
09-ip-estatico.pngrota /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 gravadasDNS
| 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.
09-servidor-web.pngrota /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 ligadoEscolher a rede pela busca
O botão Buscar lista as redes Wi-Fi ao alcance do aparelho, para você escolher sem digitar o nome.
- Toque em Buscar. O botão muda para Buscando….
- Espere a lista, normalmente em cerca de 1 s.
- Toque na rede desejada. O nome vai para o campo SSID, a lista se fecha e o cursor vai para Senha.
- 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 |
09-busca.pngrota /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 SSIDA 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.
09-escada.pnglinha 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 linhaQuando 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
apdo 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
apou 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 textoAP 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:
- Conecte o celular ou o computador à rede
<nome>_SETUP, com a chave. - Abra
http://192.168.4.1e entre com uma conta que tenha a permissão Rede. - Na página Rede, toque em Buscar, escolha a rede e digite a senha.
- 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.10funciona. 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 KEYeRSA 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:
- Confira que o endereço é o do seu aparelho.
- Abra os detalhes do aviso, geralmente em Avançado.
- 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.
09-aviso-certificado.pngrota 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 navegadorVoltar 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://ouhttps://; - 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).
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:
- NTP: a hora certa, pela rede. É o padrão de fábrica (NTP).
- Acerto manual: a hora que alguém digitou, pela interface web, pelo painel ou pelo console (Acerto manual).
- 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.
10-log-ntp.pngrota /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íveisFuso 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
- Abra Configurações e vá até Data e Hora.
- Preencha Data e Hora, na hora local do fuso configurado.
- 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.
10-acerto-manual.pngrota /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.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:
- Registra NTP corrigindo timestamps (408), com a diferença em segundos. O texto diz NTP também num acerto à mão.
- 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.
- Registra Timestamps corrigidos (409), com o número de blocos corrigidos. Um número negativo indica falha, e aparece como aviso.
- 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).
10-correcao.pnglinha 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 linhaOnde 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.
10-painel-hora-provisoria.pngscreen 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 -?.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).
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 |
11-principal.pngscreen 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 alarmeA 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, comoWeb: admin, por 5 s depois de uma entrada bem-sucedida na interface web. O silêncio tem prioridade sobre esse aviso.
11-pendentes-falha.pngscreen dash; telemetria ligada com o coletor fora do ar há alguns minutos; recorte da barra de cima com a contagem de pendentes em vermelho11-aviso-web.pngscreen 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ógioOs 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 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:
- Segure o dedo no cartão de cima por 3 s. O painel toca o som de toque e o cartão fica cinza.
- Toque no botão do sensor na barra de botões.
- 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.
11-selecao.pngscreen 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 segurarCartõ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.
11-paginas.pngscreen 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/2Quando 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.
11-web-ocupado.pngscreen dash; durante a exportação em CSV de um dia de histórico pela conta admin, na página Histórico e LogsGestos 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.
11-carregando.pngtela MODE_GRAPH_LOADING; aparece por instantes ao abrir um gráfico a partir da tela inicial; transitória, pode exigir várias tentativas de capturaO 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 emdd/mmna 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.
11-detalhe-temp.pngscreen gra -> tap(160,120); gráfico de um BME280 aberto antes, em 24H11-detalhe-umid.pngscreen gra -> tap(160,120) -> tap(160,120); mesmo BME28011-detalhe-pressao.pngscreen gra -> tap(160,120) -> tap(160,120) -> tap(160,120); mesmo BME280O 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 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 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).
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.
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).
- Toque em Modo de Configuração e em ENTRAR.
- A tela de confirmação diz: O aparelho sai da rede e abre a rede de setup. Tem certeza?
- 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.
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 |
- Toque no idioma.
- 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.
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.
- Toque no tema, ou mova a seleção com as setas.
- 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).
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.
- Encoste o dedo na mira e mantenha, com pressão leve e constante.
- 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.
- Segure o dedo na mira até ela ficar verde, cerca de 0,4 s.
- Solte. A próxima mira aparece.
- 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.
11-mira.pngscreen 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ão11-calib-ok.pngdepois do oitavo toque de uma calibração com as duas voltas coerentes11-calib-recusada.pngdepois do oitavo toque, tendo tocado longe da mira num dos cantos da segunda voltaAlinhamento 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.
11-alinhamento.pngscreen offset; deslocamento X +2 e Y -1 ajustado, antes de APLICARLicenç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 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).
11-mensagem-ok.pngmenu > Alterar Senha; digite duas vezes um PIN novo e válido, com ENTRARA 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).
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).
11-boot.pngboot 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 telaO 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.
- Ligue o aparelho.
- Espere aparecer Mantenha a tela pressionada: Modo AP…. A janela do gesto só abre depois que essa linha está na tela.
- Em até 3,5 s, encoste o dedo na tela e mantenha.
- 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.
11-boot-gesto.pngboot; linha Mantenha a tela pressionada: Modo AP... no fim da caixa; foto da tela11-boot-progresso.pngboot; dedo mantido na tela há cerca de 1,5 s dentro da janela; foto da tela11-boot-cancelado.pngboot; dedo levantado antes de a barra encher; foto da tela11-boot-ap.pngboot 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 publicarA 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.
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
[####### ]
12-splash.pnglogo depois de ligar; linha de cima SIMUT 2.7.1, linha de baixo Inicializando12-boot.pngdurante o boot, com a barra pela metade: SIMUT 2.7.1 e [####### ]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
12-conectado.pngfim 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)12-obtendo-ip.pngfim do boot, associado ao roteador sem endereço ainda; Conectado! e Obtendo IP...12-offline.pngfim do boot sem rede alcançável; Sem WiFi e OfflineAs 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.
12-temperatura.png2 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 baixo12-umidade.pngDHT22 no slot 1, na vez da umidade, com 58 %; S1 no canto de baixo12-pressao.pngBME280 no slot 2, na vez da pressão, com 1013,2 hPa; S2 no canto de baixo12-negativa.pngDS18B20 num congelador, com -18,5 °C; um só sensor ativo e nenhum pendenteErro 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,
ERROfica 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.
12-sem-sensor.pngimagem alpha sem nenhum slot ativo, conectada ao Wi-Fi; ERRO em letras grandes e W com o ícone de sinalAlarmes
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.
12-wifi-niveis.pngos 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.hOs 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 como2k.
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.
12-pendentes.pngimagem v2.7.2; 1 sensor ativo; telemetria ligada com o coletor fora do ar, 37 registros pendentes; 37 no canto de baixo à esquerda12-pendentes-k.pngimagem v2.7.2; 1 sensor ativo; 2.500 registros pendentes; 2k no canto de baixoO 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:
- 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] PSKe[AP] URLquando o AP abre; ou - nas páginas do AP, no LCD.
- na resposta do comando, que traz a chave; o nome da rede é o nome do aparelho seguido de
- No celular ou no computador, conecte-se a essa rede com essa chave.
- Abra
http://192.168.4.1.
O restante está no capítulo 9.
Senha: 3 de 3
K7PX4MRW2A
12-ap-1.pngAP aberto em operação pelo comando ap; página Modo AP 1 de 3 com 192.168.4.112-ap-2.pngmesmo estado; página Rede: 2 de 3 com simut_SETUP12-ap-3.pngmesmo estado; página Senha: 3 de 3 com a chave; borre a chave na foto publicada ou use um aparelho de demonstraçãoA 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) |
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
- Conecte o computador ou o celular à mesma rede do aparelho.
- No navegador, digite o endereço do aparelho, por exemplo
http://192.0.2.10. - 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 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:
- Digite o nome da conta em Usuário.
- Digite a senha em Senha.
- 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.
13-entrada-bloqueio.pngrota /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á desativadoTrocar 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.
- Toque em Trocar senha.
- Preencha Usuário, Senha Atual (Current Password) e Nova Senha (New Password).
- 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.
- Repita a senha nova em Repetir Nova Senha (Repeat New Password).
- 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.
13-trocar-senha.pngrota /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 vaziaO 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.
13-aviso-sessao-segura.pngrota /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 certaA 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 comandosystem admin resetno 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.
- Digite a senha nova em Nova Senha (New Password).
- 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.
- Repita a senha em Repetir Nova Senha (Repeat New Password).
- 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.
13-troca-obrigatoria.pngrota /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 igualSessõ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:
SIMUTseguido da versão do firmware, por exemploSIMUT 2.7.1. Até o aparelho responder, apareceSIMUT 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.
13-barra-topo.pngrota /alarms; largura 1280; sessão admin; um limite de alarme alterado e ainda não gravado; recorte da barra de topo e da trilhaA 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.
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).
13-gaveta-restrita.pngrota /; largura 390; sessão de um operador com as permissões Painel e Histórico; gaveta aberta13-acesso-negado.pngrota /; largura 1280; sessão de um operador sem a permissão Painel, logo depois de entrarO 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ó.
13-painel-de-controle-alpha.pngrota /; largura 1280; sessão admin; imagem alpha; 1 sensor DHT22 ativo; telemetria desligadaCartõ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.
13-painel-de-controle-celular.pngrota /; largura 390; sessão admin; imagem release; 2 sensores ativos; página rolada até a tabela de sensoresO 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
- 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).
- 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. - 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.
13-espelho-ao-vivo.pngrota /; 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 sTocar 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
- Toque em Capturar. Se o espelho estiver ao vivo, ele para, porque os dois não podem ler o painel ao mesmo tempo.
- 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.
13-captura.pngrota /; largura 1280; sessão admin; imagem release; depois de tocar em Capturar, com o painel na tela inicial; recorte do bloco TelaTrocar 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.
13-espelho-ocupado.pngrota /; 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 estadoTema 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.
13-tema-claro.pngrota /; largura 1280; sessão admin; imagem release; tema claro escolhido no botão da barra; 2 sensores ativosIdioma
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:
ENe o código curto do pacote carregado, comoPTouES. Sem pacote carregado, sóENaparece. - 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.
13-celular-pendente.pngrota /alarms; largura 390; sessão admin; um limite de alarme alterado e ainda não gravado; a barra fixa do rodapé visívelA 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.mde na pastaLICENSESdo 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.
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.
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
releasee nas imagens de teste, ele não mostra nada até você teclar Enter; então aparece o promptSIMUT>. - 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.
- Ligue o SIMUT e, nos primeiros 5 minutos, procure dispositivos Bluetooth no celular ou no computador.
- Pareie com o nome do aparelho. O SIMUT não pede confirmação no pareamento.
- 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.
- Conecte e tecle Enter. O aparelho responde com o pedido de senha.
- Digite a senha do
admine 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 resetesystem https offsão recusados pelo Bluetooth, inclusive dentro dedo, comERROR: Comando so pela USB (cabo serial).O log registra o código 302, Acesso não autorizado. O comandoapfunciona 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 memoriaconta 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:00respondeERROR: Data ou hora invalida (ano >= 2026), e o relógio não muda. Um formato errado respondeERROR: 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.
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:
- O registro entra no bloco aberto, na RAM.
- 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. - 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).
15-caminho.pngfluxo 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 %'.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 %:
- Apaga o arquivo de dia mais antigo, pela data do nome.
- 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.
- 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).
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.
15-sensores.pngrota /history; largura 1280; sessão admin; lista Origem aberta com 3 sensores, dois marcados; recorte do cartão da esquerdaO 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.
15-calendario.pngrota /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árioO 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.
15-grafico-dois.pngrota /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 %RHBaldes: 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.
15-baldes.pngrota /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 colchetesDe 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 |
15-carregando.pngrota /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ívelNomes 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
.h5e 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.
15-celular.pngrota /history; largura 390; sessão admin; um sensor; período 24h; tooltip aberto por toqueExportar 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.
- Escolha os sensores em Origem:.
- Escolha o período, ou toque num dia do calendário, e espere o gráfico carregar.
- Toque em ⤓ CSV, abaixo do gráfico.
- 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. - 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.
15-exportando.pngrota /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 CancelarO 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:
- Abra a página Arquivos (capítulo 17).
- Toque na pasta
history. - 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 [%]etemp8 [°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:
- Atualize pela página Arquivos. Ela baixa um backup
.bkppara o seu computador antes de começar, com todos os arquivos do histórico e o bloco aberto. - 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.
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:
- O primeiro sucesso de cada família depois do boot vai para a flash. É a prova de que aquela parte funciona.
- 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.
- O primeiro sucesso depois de uma falha vai para a flash. É o registro da recuperação.
- 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.
- 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).
16-transicao.pnglinha 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 horaNo 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.
- Toque em Carregar (Load). Uma barra mostra os kilobytes recebidos.
- Marque os níveis que quer ver. De entrada, só ERR vem marcado.
- Para procurar, digite em Filtrar… (Filter events…). A tabela mostra só as linhas que contêm o texto.
- 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.
16-eventos-celular.pngrota /history; largura 390; sessão admin; seção Eventos do Sistema carregada, rolada até a tabela; só ERR marcadoExportar o log em CSV
- Carregue o log com Carregar.
- Ajuste as caixas de nível e o Filtrar…: a exportação leva só as linhas que a tabela mostra.
- 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.
- Toque em Limpar.
- Confirme a pergunta Limpar logs?.
- 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:
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.ctx=1008: o núcleo 1 estava no módulo 8,DISPLAY, desenhando o painel.ctx=4184: o aparelho estava ligado havia 184 min, 3 h 04 min, quando travou. Isso confere com oup3h04mdo último registro antes do travamento.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 |
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).
17-arquivos-leitura.pngrota /files; largura 390; sessão de um operador com as permissões Painel, Histórico e Leitura; pasta raizO 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
- Marque os arquivos.
- 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
- Abra a pasta de destino.
- Toque em Enviar e escolha um ou mais arquivos.
- 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 linhaVERSIONfor 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
- Marque os arquivos.
- Toque em Excluir e confirme a pergunta Excluir N?.
- 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:
- Entre com o administrador completo.
- Abra a página Arquivos e toque em Backup.
- 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.
- Abra a página Arquivos e toque em Restaurar.
- Escolha o arquivo
.bkp. Um arquivo com outra extensão é recusado com Selecione um arquivo .bkp de backup. - A página mostra Etapa 1/3: Validando backup (CRC + chip ID)… e envia o arquivo para conferência, sem gravar nada.
- Leia a pergunta de confirmação e toque em OK para seguir.
- A página mostra Etapa 2/3: Aplicando restore (pode levar ~15 s)… e envia o arquivo de novo, agora para gravar.
- A página mostra Etapa 3/3: Reiniciando dispositivo (~25 s)…, e o aparelho reinicia sozinho.
- 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.
17-restaurar-confirmar.pngrota /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 tamanho17-restaurar-etapa3.pngrota /files; largura 1280; sessão admin; aviso Etapa 3/3: Reiniciando dispositivo (~25 s)... visívelO 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ívelWRN, 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
.binda imagem certa. Cada versão publica três imagens:simut_v<versão>_release.bin,simut_v<versão>_alpha.binesimut_v<versão>_air.bin. Use a mesma variante que está no aparelho. O.uf2com 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
- Entre com o administrador completo e abra a página Arquivos.
- Toque em Firmware. A página mostra o aviso abaixo. Leia e toque em OK.
- Escolha o arquivo
.bin. Um arquivo com outra extensão é recusado com Selecione um arquivo .bin de firmware. - 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. - 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.
- A página mostra Etapa 2/4: Enviando firmware (~30 s)… e envia a imagem. O aparelho grava e confere a imagem.
- A página mostra Etapa 3/4: Aplicando firmware…. O aparelho aceita a aplicação e desliga a rede.
- 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.
- Espere cerca de 1 min e recarregue a página de entrada.
- Entre e confira a versão (Conferir a versão).
- 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.
17-aviso-firmware.pngrota /files; largura 1280; sessão admin; botão Firmware tocado; janela de confirmação do navegador com o aviso de reformatação17-iniciar.pngrota /files; largura 1280; sessão admin; backup simut_pre-ota já baixado pelo navegador (barra de downloads visível); segunda janela de confirmação aberta17-enviando.pngrota /files; largura 1280; sessão admin; aviso Etapa 2/4: Enviando firmware (~30 s)... visível durante o envio17-ota-linha-tempo.pnglinha 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, nadaTempos 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 camposys.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) |
17-log-pos-ota.pngrota /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 listaDepois da atualização
- Entre de novo. A sessão anterior não sobrevive ao reinício.
- Se o aparelho usava HTTPS, ele volta em HTTP até o par ser restaurado (capítulo 9).
- 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. - 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):
- Ligue o carregador no pino configurado, GP17 de fábrica. Com o carregador, o Air fica em M0 enquanto a atualização durar.
- Sem carregador, ponha o Air em M0 de outro jeito: ligue-o de novo, ou rode
air stoppelo console USB durante um despertar. Cada pedido autenticado da página renova o tempo de ociosidade. - Atualize com a imagem
simut_v<versão>_air.bin, como nos passos acima. - Restaure o backup. Sem ele, o
air idlevolta a 300 s e oair chargervolta 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,Ie1. 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
apou 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 deSenha 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.
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
.bkpda página Arquivos (capítulo 17). - O
.uf2da versão instalada, publicado junto de cada versão comosimut_v<versão>_release.uf2,_alpha.uf2ou_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.
- 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 stoppelo console USB durante um despertar (capítulo 19). - 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. - HTTP ou HTTPS? Com um par de certificados instalado, o aparelho atende em
https://. Tente os dois (capítulo 9). - 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. - 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.
- Entrou, e a página mostra só
Access Denied? A conta não tem a permissão Painel (capítulo 13). - 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.
- Ligue o computador ao aparelho pelo cabo USB e abra o console (capítulo 14).
- air No Air, rode
enable. - Rode
system admin reset confirm. - Anote a senha de 8 caracteres que aparece depois de
Nova senha (unica vez):. Ela não aparece de novo. - Entre na interface web com a conta
admine essa senha. - 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
- Confira a chave. Ela tem 10 caracteres, maiúsculas e algarismos, sem
O,0,Ie1. Leia-a no console USB, na linha[AP] PSK :, na resposta do comandoap, na tela de boot do painel ou no LCD do alpha. - 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.
- 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, usehttps://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, abrahttp://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 confirmOs 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 factoryousystem format(capítulo 17); - o firmware foi gravado depois de apagar a flash inteira.
Para recuperar:
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).Configure a rede. Pelo AP, aberto com
apou pelo menu do painel, ou pelo console (A rede configurada está errada).Entre na interface web com
admine a senha, e troque a senha.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=7e uma sem assinatura comv=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:
- Desligue o cabo USB do Pico W.
- Segure o botão BOOTSEL, o único botão do Pico W.
- Ligue o cabo USB com o botão segurado.
- Solte o botão.
O computador mostra uma unidade de disco chamada RPI-RP2. No Linux, lsusb lista a placa como 2e8a:0003.
18-bootsel.pngum 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-RP2Pela 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:
- 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).
- Pelo console USB, rode
system format confirm. O aparelho reformata o sistema de arquivos e reinicia com a configuração de fábrica. - 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 stopenquanto o console aparece, nos segundos em que o Air está acordado. Pelo Bluetooth,air stopnã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.
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, ouair sleep, no console. O console respondeEntrando em hibernacao (SIMUT Air).... - Pela ociosidade: depois de
air idlesegundos 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.
19-modos.pngmá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'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:
- Aquecimento: espera 0,4 s com os sensores alimentados. O GP16, que alimenta os sensores, já sobe no começo do boot (O GP16).
- 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.
- 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).
- Conexão: só num despertar de telemetria com o Wi-Fi de pé. Espera o enlace até 30 s; não espera o NTP.
- 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.
- 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.
19-despertar.pnglinha 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)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). offdesliga 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, comt_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
Grave a imagem do Air pelo BOOTSEL:
simut_v<versão>_air.uf2(capítulo 3).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).
Abra o console USB e pegue a senha do administrador: a moldura
SEC-003do primeiro boot, ouenableseguido desystem admin reset confirm(capítulo 18).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 confirmSem 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 comandotime(capítulo 10).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.
Descubra o IP com
show net statuse entre na interface web comadmin. Troque a senha.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.
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).
Ajuste o Air, se precisar:
air idleeair charger.Faça um backup pela página Arquivos (capítulo 17).
Feche a página, desligue o carregador e rode
air hibernate, ou deixe a ociosidade acabar.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.
19-montagem.pngum 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 etiquetas19-painel-controle.pngrota /; 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 painelLimitaçõ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 |
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.
20-integracao.pngDiagrama 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'.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-Uidde todo POST de telemetria e da linha de alarmes; - na resposta de
GET /api/status, campouid; - 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.pemenviado, 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.
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.
21-cursor.pngFila 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.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.
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://ouhttps://, 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, comosimut_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.
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.
Quando o aparelho envia
- Cada registro novo do histórico soma 1 ao contador de pendentes, que o Painel de Controle mostra em Registros Pendentes (capítulo 13).
- Quando os pendentes chegam ao Lote mínimo, começa um esvaziamento. Depois de ligar, o primeiro espera pelo menos 8 s.
- 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.
- Com a confirmação, o cursor avança até o último registro que o lote levou.
- 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
t0ouu3. 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_STM0001eh0_STM0001, mesmo quando o sensor não mede umidade. Os demais ficams2,h2e 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 sempretext/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, comojson, um com acento, comoaplicaçã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/jsonno 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) ouNot 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-ECDSAouECDHE-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.
- Obtenha o certificado da CA, em formato PEM.
- Salve-o com o nome
cert.pem. - Na página Arquivos, envie o arquivo para a raiz do sistema de arquivos (capítulo 17).
- 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
- Crie o usuário do aparelho:
sudo mosquitto_passwd -c /etc/mosquitto/senhas simut. - Crie o usuário do coletor:
sudo mosquitto_passwd /etc/mosquitto/senhas coletor. - Reinicie o broker:
sudo systemctl restart mosquitto. - No aparelho, use Porta 1883, Usuário
simute 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:
- Rode o receptor numa máquina da mesma rede e anote o endereço dela.
- Na página Telemetria, preencha IP Servidor, Porta, Endpoint e API Key.
- Ponha Lote mínimo (registros) em 1.
- Use Aplicar agora.
- Toque em Enviar agora.
- Confira no receptor o POST recebido.
- No Painel de Controle, confira Registros Pendentes caindo até Sincronizado, e Telemetria Env. subindo (capítulo 13).
- 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 |
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
- Um evento entra na fila, com um número de sequência,
seq. - O aparelho envia a fila inteira ao coletor, na mesma passada.
- O coletor confirma os registros que recebeu.
- O aparelho tira da fila só os registros confirmados.
- 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.
22-fluxo.pngDiagrama 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.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. Ovalé 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_sileerr_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 trazuser.alarm_offeerr_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_offealarm_ontambé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_onemaint_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 geramaint_offsemuser.
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
alarmnovo; - um sensor que já está em falha gera um
errnovo; - uma janela de manutenção ainda aberta gera um
maint_onnovo, semuser.
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:ttemperatura,uumidade,ppressão,lluminosidade. Num evento de limite, é a grandeza que saiu da faixa, e numalarm_lim, a que mudou. Nos demais códigos, é a primeira grandeza do sensor:tpara todos os tipos atuais. Sem identificador, vem o número do slot, comot3.- Números.
val,loehiusam 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 oseqsozinho 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.
- A temperatura do slot 0 passou do máximo, com 8,52 °C.
- Alguém tocou em Silenciar 120s.
- O BME280 parou de responder.
- A conta
joaoabriu 2 h de manutenção no slot 0. - A conta
joaomudou os limites de umidade do slot 1 para 30,0 e 70,0. - 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
alarmtraz a leitura de agora do primeiro sensor ativo. - O
alarm_limtraz os limites de umidade de um sensor que mede umidade, ou os de temperatura quando nenhum mede. - O
maint_onabre 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
seqque 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
seqrecomeç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.
/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:
- 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.
- 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
alarmem segundos; - abra uma janela de manutenção de poucos minutos num sensor: sai um
maint_onagora e ummaint_offno fim do prazo (capítulo 7); - desconecte um sensor: sai um
err.
- na página Alarmes e Sons, ponha o limite máximo de um sensor abaixo da leitura atual: sai um
- Confira o registro no coletor.
- Na página Histórico e Logs, em Eventos do Sistema, confira os eventos 550 e 552.
- Recarregue a página Telemetria e confira Pendentes: 0.
- 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 |
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:
- O aparelho conecta ao broker com a telemetria no transporte MQTT (capítulo 21).
- Logo depois de conectar, ele publica uma mensagem de descoberta para cada medição, retida no broker, sob o tópico
homeassistant/. - O Home Assistant lê essas mensagens e cria o dispositivo e as entidades.
- 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.
23-fluxo.pngTrê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'.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:
- Abra a página Telemetria.
- Em Transporte, escolha MQTT(S) e preencha o broker como no capítulo 21.
- Em Construtor, deixe o Formato em JSON.
- Em Lote mínimo (registros), digite
1. - Ligue Home Assistant Discovery.
- Toque em Salvar e reiniciar na barra de topo e confirme.
- Espere o primeiro envio de telemetria depois do reinício.
- 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}}
23-evento-548.pngrota /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 conectadoNo Home Assistant, passo a passo
Os menus citados aqui são os do Home Assistant, não os do aparelho.
- No Home Assistant, abra Configurações, depois Dispositivos e serviços.
- 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.
- Confira, nas opções da integração MQTT, que a descoberta está ativa e o prefixo é
homeassistant. - Configure o aparelho como em Ligar a descoberta.
- 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. - Abra o dispositivo. As entidades aparecem com os nomes da tabela de As entidades, já com unidade e classe.
- 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.
- Na página Telemetria, desligue Home Assistant Discovery, sem mudar mais nada.
- Toque em Salvar e reiniciar e confirme.
- Espere o próximo envio de telemetria.
- Confira o evento 548, Discovery HA atualizado, nos Eventos do Sistema. No console e no syslog, o texto do evento diz
HA discovery clearedseguido do número de mensagens apagadas. - Confira no Home Assistant que o dispositivo sumiu.
- 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
offlinequando o Keep-Alive vence, e as entidades ficam indisponíveis até o despertar seguinte. Um Keep-Alive maior, até 300 s, adia ooffline. - 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
tsdo 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,HumidityePressure, 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 parahttps://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.
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.
24-coleta.pngÀ 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'.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.
- Na página Usuários, crie a conta
metricascom a permissão Painel e sem PIN (capítulo 8). - Toque em Salvar e reiniciar e anote a senha da janela Senha temporária.
- Entre uma vez na interface web com a conta
metricase defina a senha definitiva na troca obrigatória (capítulo 13). Escolha uma senha longa: o HTTP Basic aceita até 128 caracteres. - Saia da interface web.
- Grave a senha num arquivo legível só pelo Prometheus, por exemplo
/etc/prometheus/simut_senha.
24-conta-metricas.pngrota /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 gravadaA 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
/metricsnã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 comsimut_sensor_okem 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
# TYPEdas 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: 5mevita 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
uidnas métricas. Identifique o aparelho pelo alvo ou por rótulos que você mesmo põe na configuração. simut_ntp_syncedsempre 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).
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).
25-caminho.pngDa 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)'.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 comoC--mara-1. Com o Nome vazio, sai-. Ouiddo 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 campoTIMESTAMPsai 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:
- Abra a página Configurações e vá até Syslog Remoto (Auditoria).
- Ligue Habilitar encaminhamento syslog.
- Em IP do Coletor, digite o IPv4 do coletor, por exemplo
192.0.2.10. - Em Porta UDP, deixe
514ou use a porta do seu coletor. - Em Nível Mínimo, escolha o nível (Qual nível usar).
- 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")
}
- Crie o arquivo acima.
- Reinicie o rsyslog:
sudo systemctl restart rsyslog. - Libere a porta UDP 514 no firewall do coletor, só para os endereços dos aparelhos.
- Ligue o encaminhamento no aparelho e espere o reinício.
- 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; troquectxporcoreouuppara 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 stopno 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.
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.
- Peça o código com
GET /api/login_init. - Calcule o SHA-256 da senha, em hexadecimal minúsculo (A senha em SHA-256).
- Envie
POST /api/logincom os campos de formuláriouser,passenonce. - Guarde o token de sessão que volta no cabeçalho
Set-Cookie. - 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.
26-entrada.pngdiagrama 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 encerraGET /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_initdo 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/permstraz"mc":1;POST /api/commit_all,POST /api/action?op=rebootePOST /api/clear_logsrespondem409:
{"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_chpasse 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) recebe204, 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
Origindo 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:
- Recebeu
401: entre de novo uma vez e repita o pedido. - Recebeu
403: pergunteGET /api/perms. - Se
/api/permsresponde401, a sessão morreu: entre de novo e repita. - Se
/api/permsresponde200, 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
trueefalsena maioria das respostas, e como1e0em alguns campos, comontp,telecap; confira a tabela de cada rota. Nos pedidos, o aparelho aceitatrue,false,1e0, com ou sem aspas. - O tipo do corpo decide como ele é lido. Com
Content-Type: application/x-www-form-urlencoded, que é o padrão docurl -d, o aparelho lê campos de formulário. Com qualquer outro tipo, ele guarda o corpo cru e não lê campos. Por issoset_timeecalibprecisam de-H 'Content-Type: application/json', ecommit_allprecisa 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, usejson.dumps(dados, ensure_ascii=False). - Campo desconhecido num pedido é ignorado em silêncio. Confira o efeito lendo o estado de volta.
- Caminho inexistente responde
404com o texto404: Not Found. Se o cabeçalhoHostdo pedido não é o IP do aparelho nem termina em.local, a resposta é um302parahttp://<ip>/network, o comportamento de portal do ponto de acesso. Uma rota com o método errado, comoGET /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_passvazio 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,dns2eweb_ka, e respondia"reboot":falseonde a gravação real reiniciava pelo grupoweb; - 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).
26-ota.pngdiagrama 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=applyBaixe 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"Envie a imagem. O campo do formulário leva o
.binda mesma imagem do aparelho (release,alphaouair, oenvdo/api/status), assinado: os das releases e os do configurador são (capítulo 17).commit=1deixa 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":0e"committed":1. Uma imagem recusada volta com422:vMotivo 4 Imagem pequena demais 5 Imagem grande demais 6 Início da imagem inválido 7 A imagem é de outra variante. envdiz qual8 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,bytesecrc32, comstdiferente de 5:1falha ao começar,2envio incompleto,3imagem maior que a área de preparo,4falha de gravação,6envio 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.
Aplique.
curl -s -b jar -X POST "$H/api/ota/apply"{"accepted":true,"mode":"apply"}A resposta
202chega 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 é409com"v", e a imagem é descartada.Confirme. Espere o aparelho voltar, repetindo
GET /api/login_inita cada 3 s. Entre e leiaveremGET /api/status, ouversionemGET /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:
- Peça
GET /api/wifi/scan?again=1para começar uma busca nova. A resposta é{"scanning":true}. - Repita
GET /api/wifi/scan, semagain, a cada segundo, atéscanningserfalse.
{"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 respondem503por 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
409e 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 |
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.
27-arquitetura.pngdiagrama: 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| 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-VereX-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
adminsó pode ser definido pelo próprioadminou 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 /logoutdevolve 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
/metricsnã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
401entrando de novo uma vez, e403perguntandoGET /api/perms(capítulo 26); - registre cada gravação com o
uid, o que foi pedido e a resposta inteira, inclusiverejected.
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:
- Configure em cada aparelho a origem exata da página, pelo console serial ou pela chave
corsdocommit_all(capítulo 9). - Reinicie cada aparelho: a origem só vale depois do reinício.
- Na página, entre com
POST /api/login. Como o pedido sai da origem autorizada, a resposta traz o token no corpo, emtoken. - Mande o token em
Authorization: Bearerem cada pedido. A página não usa cookie. - Saia com
GET /logoute 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.brehttp://gestor.exemplo.com.brsã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-Afternem osX-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
- Entre e confirme o
uid(Confirmar quem responde). - release alpha Mande o
_payloadcom_dry=1. Leiarejected,rebootereboot_for. - Se o ensaio recusou algum campo, pare e corrija o modelo ou o cadastro.
- Mande o mesmo
_payloadsem_dry, ou com_reboot=1se você já espera reiniciar. - Se a resposta traz
"reboot":true, espere o aparelho voltar e entre de novo. - Leia o estado de volta (
GET /api/config,GET /api/alarmsouGET /api/network) e confira os campos. - Guarde o novo
cfgdeGET /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-Uiddo POST, ou pelo tópico no MQTT; - responda
2xxrá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:
- A imagem certa. Leia
sys.enve escolhaimages[env]. Nunca escolha pela versão ou pelo nome do arquivo. - O arquivo inteiro. Calcule o SHA-256 do
.binbaixado e compare comsha256. Confira tambémsize. - A etiqueta. O
.bincontém o textoSIMUT-ENV:<env>;v=<versão>;. Confira que<env>é o do aparelho e<versão>é a do manifesto. - A assinatura. O
.bintermina com os 8 bytesSIMUTSIG. Sem eles, o aparelho recusa a imagem com"v":8, depois de o envio já ter sobrescrito o sistema de arquivos. - 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. - 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:
- Baixe o backup
.bkpe confira a integridade. - Envie a imagem com
POST /api/restore?op=stage&commit=1e confira"v":0e"committed":1. - Aplique com
POST /api/ota/apply. - Espere o aparelho voltar e confirme a versão nova em
sys.ver. - Confira o backup com
POST /api/restore?op=validatee restaure-o comPOST /api/restore?op=apply; espere o reinício. O aparelho só aplica o backup que acabou de conferir (capítulo 26). - Envie os pacotes de idioma da release nova para
/lange 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.
27-ondas.pngdiagrama: 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- 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.
- Onda 1. Poucos aparelhos em uso real. Espere um período de trabalho normal e confira que todos voltaram a mandar telemetria.
- 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:
- 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.
- HTTPS onde a rede não é sua. Em HTTP, quem escuta a rede lê as leituras, os PINs enviados num
commit_alle 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). - 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. - Senhas diferentes em cada aparelho, guardadas num cofre de segredos e lidas do ambiente pelos scripts, nunca escritas neles.
- Uma chave de telemetria por aparelho (
t_key), conferida pelo coletor. Os cabeçalhosX-SIMUT-*identificam, mas não autenticam: qualquer máquina da rede pode imitá-los (capítulo 20). - Backups são segredos. Um
.bkpcontém a configuração inteira, com as contas e as chaves. Guarde-os cifrados e com acesso restrito. - 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.
- Origem CORS exata. Configure só a origem do gestor, com esquema e porta. Sem gestor no navegador, deixe o CORS desligado.
- 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:
{"ok":true,"redirect":"/"}. Com"redirect":"/force_chpass", a conta de serviço ainda precisa trocar a senha (A primeira entrada).- 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 epin_mine o menor de 8 epin_max. A API aceita só PINs de 4 a 8 algarismos, qualquer que seja a política (capítulo 26). {"status":"ok","reboot":true,"reboot_for":["users"],"creds":[{"u":"joao","p":"K7M2QX9A"}]}. Guarde a senha decredsagora: ela não aparece de novo. Se a resposta trouxerrejected, leia o motivo antes de seguir (capítulo 26).- O aparelho reinicia logo depois de responder e volta em alguns segundos.
- A conta
joaoaparece com"perms":6144e"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 portar0x0800e0x1000para 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 oidemGET /api/users."rejected":["users.dup"]: já existe uma contajoao. Para trocar as permissões dela, apague poride 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:
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 |
28-flash.pngbarra 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 arquivosRecursos 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 |
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
429até 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 é
HttpOnlyeSameSite=Strict, e ganhaSecurequando 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).
- o cookie de sessão é
- 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.pemque 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/logse/api/ls, e 5 s em/api/calibe/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.
- caminhos com
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
- Troque a senha do administrador no primeiro login (a interface obriga) e troque o PIN
1234do administrador no painel. - 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.
- 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). - Ponha o aparelho numa rede separada da rede de visitantes, ou use HTTPS com um certificado seu.
- Se a telemetria usa TLS, envie ao aparelho o certificado do seu servidor (
/cert.pem). - Envie o log de eventos a um servidor syslog, para que um registro sobreviva ao aparelho.
- Baixe um backup depois de configurar e antes de cada atualização.
- Proteja o acesso físico à porta USB: os comandos de recuperação estão nela.
- 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.
- 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.
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
- Confira a imagem e a versão. A gaveta da interface web e o comando
show system infomostram 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 camposys.envdeGET /api/status. Parte dos comportamentos deste capítulo vale só para uma imagem ou uma versão. - Leia o log de eventos. Na página Histórico e Logs, marque INF, WRN e ERR. No console USB,
show system logmostra tudo o que está gravado. O log diz o que o aparelho tentou, o que falhou e quando (capítulo 16). - Confira a rede. A página Rede e o comando
show net statusmostram 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). - Confira a hora. Sem hora confiável, o histórico e a telemetria esperam. Veja se o NTP sincronizou (capítulo 10).
- Guarde as provas antes de mexer. Exporte o log em CSV e baixe um backup. Um reinício ou uma restauração apagam pistas.
- 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:
- A imagem (release, alpha ou Air) e a versão que a gaveta da interface web mostra.
- O que você fez, em que ordem e a que horas, pela hora do aparelho.
- O log de eventos exportado em CSV pela página Histórico e Logs, ou a saída de
show system logpelo console USB. - Num travamento, os registros Boot do sistema com nível
FTLe os registros irmãos logo em seguida (capítulo 16). - 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).
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
.bkpcom 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_intet_batda 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
.lngque 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>_SETUPque 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 contaadmine 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).
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_testnum aparelho com o painel ligado, navegue comscreen <tag>ou com toques peloPOST /api/touch, espere 6 s após o último toque e baixeGET /api/screenshot.tools/screen_mapper.pyfaz 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.
| # | Arquivo | Cap. | Como capturar |
|---|---|---|---|
| 1 | 01-arquitetura.pngDiagrama | 1 | diagrama 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 |
| 2 | 02-pinos-release.pngDiagrama | 2 | vista 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 |
| 3 | 02-pinos-alpha.pngDiagrama | 2 | vista 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 |
| 4 | 02-pinos-air.pngDiagrama | 2 | vista 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 |
| 5 | 02-air-energia.pngDiagrama | 2 | GP16 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' |
| 6 | 02-ds18b20.pngDiagrama | 2 | sonda 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 |
| 7 | 02-dht22.pngDiagrama | 2 | mó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' |
| 8 | 02-bmx280.pngDiagrama | 2 | mó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' |
| 9 | 02-placa.pngFoto | 2 | placa 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 |
| 10 | 03-arquivos.pngDiagrama | 3 | os 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) |
| 11 | 03-bootsel.pngFoto | 3 | mã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 |
| 12 | 04-fluxo.pngDiagrama | 4 | fluxograma 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' |
| 13 | 04-painel-data-hora.pngTela do painel | 4 | release 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 |
| 14 | 04-painel-ap.pngTela do painel | 4 | release 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 |
| 15 | 04-lcd-ap.pngLCD 16×2 | 4 | alpha 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 |
| 16 | 04-novo-pin.pngTela do painel | 4 | release com configuração de fábrica; tela inicial → botão de configurações → admin → PIN 1234 → ENTRAR; tela Novo PIN aberta, antes de digitar |
| 17 | 05-selo-reinicio.pngPágina web | 5 | rota /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 |
| 18 | 05-tres-botoes.pngPágina web | 5 | rota /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 |
| 19 | 05-confirmacao.pngPágina web | 5 | rota /config; largura 1280; sessão admin; Nome do aparelho alterado; janela de confirmação aberta depois de tocar em Salvar e reiniciar |
| 21 | 05-erro-carga.pngPágina web | 5 | rota /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 |
| 22 | 05-data-hora.pngPágina web | 5 | rota /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 |
| 28 | 06-editor-ds18b20.pngPágina web | 6 | rota /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 |
| 29 | 06-editor-bme280.pngPágina web | 6 | rota /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 |
| 30 | 06-editor-aviso.pngPágina web | 6 | rota /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. |
| 31 | 06-procurar.pngPágina web | 6 | rota /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 |
| 32 | 06-painel-sensor.pngTela do painel | 6 | screen dash; 2 sensores ativos (um DS18B20 e um BME280), ambos lendo, nenhum em alarme |
| 33 | 06-painel-erro.pngTela do painel | 6 | screen dash; 2 sensores ativos; a sonda DS18B20 desligada do pino há mais de 3 leituras, alarmes do slot ligados |
| 34 | 06-lcd-erro.pngLCD 16×2 | 6 | imagem alpha; 1 sensor DHT22 ativo e desligado do pino; o LCD mostra ERRO em letras grandes |
| 35 | 06-calibracao.pngPágina web | 6 | rota /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 |
| 36 | 06-calibracao-suave.pngPágina web | 6 | rota /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 |
| 37 | 06-calibracao-ntp.pngPágina web | 6 | rota /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. |
| 39 | 07-painel-falha.pngTela do painel | 7 | screen 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 |
| 46 | 07-menu-sensor-manut.pngTela do painel | 7 | menu 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 |
| 48 | 07-manutencao-entrada.pngTela do painel | 7 | menu do sensor -> Manutenção -> ENTRAR; sessão admin; janela fechada; Horas 2 e Minutos 30 ajustados, antes de INICIAR |
| 49 | 07-manutencao-aberta.pngTela do painel | 7 | mesmo caminho, com a janela aberta há alguns minutos |
| 51 | 07-melodia.pngTela do painel | 7 | tela Config. de Sons; som Alarme desligado; toque na linha Alarme duas vezes para abrir a escolha de melodia |
| 52 | 07-mudo-confirmar.pngTela do painel | 7 | tela 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 |
| 53 | 08-usuarios.pngPágina web | 8 | rota /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 |
| 54 | 08-usuarios-permissoes.pngPágina web | 8 | rota /users; largura 390; sessão admin; selo de permissões de uma conta de operador aberto, mostrando os nomes |
| 55 | 08-usuarios-nova.pngPágina web | 8 | rota /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 |
| 56 | 08-senha-temporaria.pngPágina web | 8 | rota /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 |
| 57 | 08-quem.pngTela do painel | 8 | screen pin; contas admin, operador1 e manutencao com PIN; nenhuma bloqueada |
| 59 | 08-teclado-3.pngTela do painel | 8 | screen pin e escolha de uma conta; política de fábrica: 0-9, 3 por tecla; dois caracteres já digitados |
| 60 | 08-teclado-alfa.pngTela do painel | 8 | screen pin e escolha de uma conta; política 0-9 A-Z, 1 por tecla; grupo PQRS aberto |
| 61 | 08-teclado-numerico.pngTela do painel | 8 | menu > Alterar Senha, sessão admin; política de fábrica; tela Novo PIN com três dígitos digitados |
| 62 | 08-pin-invalido.pngTela do painel | 8 | screen pin, escolha de uma conta, um PIN errado e ENTRAR; logo depois da recusa |
| 63 | 08-espera.pngTela do painel | 8 | screen pin; a mesma conta errou o PIN três vezes seguidas; durante a espera de 5 s |
| 64 | 08-painel-bloqueado.pngTela do painel | 8 | tela do teclado depois de 20 tentativas erradas somadas, sem nenhuma entrada certa no meio |
| 65 | 08-pin-em-uso.pngTela do painel | 8 | menu > Alterar Senha; digitar duas vezes um PIN que outra conta já usa |
| 66 | 08-politica.pngTela do painel | 8 | menu > Segurança do PIN, sessão admin; política de fábrica; linha Teclado selecionada |
| 67 | 08-politica-web.pngPágina web | 8 | rota /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 |
| 68 | 08-usuarios-lista.pngTela do painel | 8 | screen usr; contas viewer, operador1 (com PIN, L e B) e manutencao (com PIN, M) |
| 69 | 08-novo-nome.pngTela do painel | 8 | screen usr -> NOVO; nome manutencao digitado |
| 70 | 08-novo-permissoes.pngTela do painel | 8 | screen usr -> NOVO -> nome -> OK; Editar limites e Manutenção em SIM |
| 71 | 08-novo-pin.pngTela do painel | 8 | mesmo caminho -> SEGUIR; tela Novo PIN com o teclado ordenado |
| 72 | 08-excluir.pngTela do painel | 8 | screen usr -> conta manutencao -> Excluir usuário |
| 74 | 09-ip-estatico.pngPágina web | 9 | rota /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 |
| 75 | 09-servidor-web.pngPágina web | 9 | rota /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 |
| 76 | 09-busca.pngPágina web | 9 | rota /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 |
| 77 | 09-escada.pngDiagrama | 9 | linha 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 |
| 78 | 09-aviso-certificado.pngPágina web | 9 | rota 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 |
| 79 | 10-log-ntp.pngPágina web | 10 | rota /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 |
| 80 | 10-acerto-manual.pngPágina web | 10 | rota /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. |
| 81 | 10-correcao.pngDiagrama | 10 | linha 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 |
| 83 | 10-painel-hora-provisoria.pngTela do painel | 10 | screen 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 - |
| 84 | 11-principal.pngTela do painel | 11 | screen 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 |
| 85 | 11-pendentes-falha.pngTela do painel | 11 | screen dash; telemetria ligada com o coletor fora do ar há alguns minutos; recorte da barra de cima com a contagem de pendentes em vermelho |
| 86 | 11-aviso-web.pngTela do painel | 11 | screen 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 |
| 88 | 11-selecao.pngTela do painel | 11 | screen 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 |
| 89 | 11-paginas.pngTela do painel | 11 | screen 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 |
| 90 | 11-web-ocupado.pngTela do painel | 11 | screen dash; durante a exportação em CSV de um dia de histórico pela conta admin, na página Histórico e Logs |
| 91 | 11-carregando.pngTela do painel | 11 | tela 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 |
| 93 | 11-detalhe-temp.pngTela do painel | 11 | screen gra -> tap(160,120); gráfico de um BME280 aberto antes, em 24H |
| 94 | 11-detalhe-umid.pngTela do painel | 11 | screen gra -> tap(160,120) -> tap(160,120); mesmo BME280 |
| 95 | 11-detalhe-pressao.pngTela do painel | 11 | screen gra -> tap(160,120) -> tap(160,120) -> tap(160,120); mesmo BME280 |
| 110 | 11-mira.pngTela do painel | 11 | screen 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 |
| 111 | 11-calib-ok.pngTela do painel | 11 | depois do oitavo toque de uma calibração com as duas voltas coerentes |
| 112 | 11-calib-recusada.pngTela do painel | 11 | depois do oitavo toque, tendo tocado longe da mira num dos cantos da segunda volta |
| 113 | 11-alinhamento.pngTela do painel | 11 | screen offset; deslocamento X +2 e Y -1 ajustado, antes de APLICAR |
| 115 | 11-mensagem-ok.pngTela do painel | 11 | menu > Alterar Senha; digite duas vezes um PIN novo e válido, com ENTRAR |
| 120 | 11-boot.pngFoto | 11 | boot 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 |
| 121 | 11-boot-gesto.pngFoto | 11 | boot; linha Mantenha a tela pressionada: Modo AP... no fim da caixa; foto da tela |
| 122 | 11-boot-progresso.pngFoto | 11 | boot; dedo mantido na tela há cerca de 1,5 s dentro da janela; foto da tela |
| 123 | 11-boot-cancelado.pngFoto | 11 | boot; dedo levantado antes de a barra encher; foto da tela |
| 124 | 11-boot-ap.pngFoto | 11 | boot 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 |
| 125 | 12-splash.pngLCD 16×2 | 12 | logo depois de ligar; linha de cima SIMUT 2.7.1, linha de baixo Inicializando |
| 126 | 12-boot.pngLCD 16×2 | 12 | durante o boot, com a barra pela metade: SIMUT 2.7.1 e [####### ] |
| 127 | 12-conectado.pngLCD 16×2 | 12 | fim 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) |
| 128 | 12-obtendo-ip.pngLCD 16×2 | 12 | fim do boot, associado ao roteador sem endereço ainda; Conectado! e Obtendo IP... |
| 129 | 12-offline.pngLCD 16×2 | 12 | fim do boot sem rede alcançável; Sem WiFi e Offline |
| 130 | 12-temperatura.pngLCD 16×2 | 12 | 2 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 |
| 131 | 12-umidade.pngLCD 16×2 | 12 | DHT22 no slot 1, na vez da umidade, com 58 %; S1 no canto de baixo |
| 132 | 12-pressao.pngLCD 16×2 | 12 | BME280 no slot 2, na vez da pressão, com 1013,2 hPa; S2 no canto de baixo |
| 133 | 12-negativa.pngLCD 16×2 | 12 | DS18B20 num congelador, com -18,5 °C; um só sensor ativo e nenhum pendente |
| 134 | 12-sem-sensor.pngLCD 16×2 | 12 | imagem alpha sem nenhum slot ativo, conectada ao Wi-Fi; ERRO em letras grandes e W com o ícone de sinal |
| 135 | 12-wifi-niveis.pngDiagrama | 12 | os 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 |
| 136 | 12-pendentes.pngLCD 16×2 | 12 | imagem v2.7.2; 1 sensor ativo; telemetria ligada com o coletor fora do ar, 37 registros pendentes; 37 no canto de baixo à esquerda |
| 137 | 12-pendentes-k.pngLCD 16×2 | 12 | imagem v2.7.2; 1 sensor ativo; 2.500 registros pendentes; 2k no canto de baixo |
| 138 | 12-ap-1.pngLCD 16×2 | 12 | AP aberto em operação pelo comando ap; página Modo AP 1 de 3 com 192.168.4.1 |
| 139 | 12-ap-2.pngLCD 16×2 | 12 | mesmo estado; página Rede: 2 de 3 com simut_SETUP |
| 140 | 12-ap-3.pngLCD 16×2 | 12 | mesmo estado; página Senha: 3 de 3 com a chave; borre a chave na foto publicada ou use um aparelho de demonstração |
| 142 | 13-entrada-bloqueio.pngPágina web | 13 | rota /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 |
| 143 | 13-trocar-senha.pngPágina web | 13 | rota /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 |
| 144 | 13-aviso-sessao-segura.pngPágina web | 13 | rota /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 |
| 145 | 13-troca-obrigatoria.pngPágina web | 13 | rota /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 |
| 146 | 13-barra-topo.pngPágina web | 13 | rota /alarms; largura 1280; sessão admin; um limite de alarme alterado e ainda não gravado; recorte da barra de topo e da trilha |
| 148 | 13-gaveta-restrita.pngPágina web | 13 | rota /; largura 390; sessão de um operador com as permissões Painel e Histórico; gaveta aberta |
| 149 | 13-acesso-negado.pngPágina web | 13 | rota /; largura 1280; sessão de um operador sem a permissão Painel, logo depois de entrar |
| 151 | 13-painel-de-controle-alpha.pngPágina web | 13 | rota /; largura 1280; sessão admin; imagem alpha; 1 sensor DHT22 ativo; telemetria desligada |
| 152 | 13-painel-de-controle-celular.pngPágina web | 13 | rota /; largura 390; sessão admin; imagem release; 2 sensores ativos; página rolada até a tabela de sensores |
| 153 | 13-espelho-ao-vivo.pngPágina web | 13 | rota /; 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 |
| 154 | 13-captura.pngPágina web | 13 | rota /; largura 1280; sessão admin; imagem release; depois de tocar em Capturar, com o painel na tela inicial; recorte do bloco Tela |
| 155 | 13-espelho-ocupado.pngPágina web | 13 | rota /; 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 |
| 156 | 13-tema-claro.pngPágina web | 13 | rota /; largura 1280; sessão admin; imagem release; tema claro escolhido no botão da barra; 2 sensores ativos |
| 157 | 13-celular-pendente.pngPágina web | 13 | rota /alarms; largura 390; sessão admin; um limite de alarme alterado e ainda não gravado; a barra fixa do rodapé visível |
| 159 | 15-caminho.pngDiagrama | 15 | fluxo 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 %' |
| 161 | 15-sensores.pngPágina web | 15 | rota /history; largura 1280; sessão admin; lista Origem aberta com 3 sensores, dois marcados; recorte do cartão da esquerda |
| 162 | 15-calendario.pngPágina web | 15 | rota /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 |
| 163 | 15-grafico-dois.pngPágina web | 15 | rota /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 |
| 164 | 15-baldes.pngPágina web | 15 | rota /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 |
| 165 | 15-carregando.pngPágina web | 15 | rota /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 |
| 166 | 15-celular.pngPágina web | 15 | rota /history; largura 390; sessão admin; um sensor; período 24h; tooltip aberto por toque |
| 167 | 15-exportando.pngPágina web | 15 | rota /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 |
| 168 | 16-transicao.pngDiagrama | 16 | linha 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 |
| 170 | 16-eventos-celular.pngPágina web | 16 | rota /history; largura 390; sessão admin; seção Eventos do Sistema carregada, rolada até a tabela; só ERR marcado |
| 172 | 17-arquivos-leitura.pngPágina web | 17 | rota /files; largura 390; sessão de um operador com as permissões Painel, Histórico e Leitura; pasta raiz |
| 173 | 17-restaurar-confirmar.pngPágina web | 17 | rota /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 |
| 174 | 17-restaurar-etapa3.pngPágina web | 17 | rota /files; largura 1280; sessão admin; aviso Etapa 3/3: Reiniciando dispositivo (~25 s)... visível |
| 175 | 17-aviso-firmware.pngPágina web | 17 | rota /files; largura 1280; sessão admin; botão Firmware tocado; janela de confirmação do navegador com o aviso de reformatação |
| 176 | 17-iniciar.pngPágina web | 17 | rota /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 |
| 177 | 17-enviando.pngPágina web | 17 | rota /files; largura 1280; sessão admin; aviso Etapa 2/4: Enviando firmware (~30 s)... visível durante o envio |
| 178 | 17-ota-linha-tempo.pngDiagrama | 17 | linha 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 |
| 179 | 17-log-pos-ota.pngPágina web | 17 | rota /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 |
| 180 | 18-bootsel.pngFoto | 18 | um 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 |
| 181 | 19-modos.pngDiagrama | 19 | má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' |
| 182 | 19-despertar.pngDiagrama | 19 | linha 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) |
| 183 | 19-montagem.pngFoto | 19 | um 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 |
| 184 | 19-painel-controle.pngPágina web | 19 | rota /; 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 |
| 185 | 20-integracao.pngDiagrama | 20 | Diagrama 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'. |
| 186 | 21-cursor.pngDiagrama | 21 | Fila 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. |
| 190 | 22-fluxo.pngDiagrama | 22 | Diagrama 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. |
| 192 | 23-fluxo.pngDiagrama | 23 | Trê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'. |
| 194 | 23-evento-548.pngPágina web | 23 | rota /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 |
| 195 | 24-coleta.pngDiagrama | 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'. |
| 196 | 24-conta-metricas.pngPágina web | 24 | rota /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 |
| 197 | 25-caminho.pngDiagrama | 25 | Da 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)'. |
| 198 | 26-entrada.pngDiagrama | 26 | diagrama 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 |
| 199 | 26-ota.pngDiagrama | 26 | diagrama 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 |
| 200 | 27-arquitetura.pngDiagrama | 27 | diagrama: 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 |
| 201 | 27-ondas.pngDiagrama | 27 | diagrama: 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 |
| 202 | 28-flash.pngDiagrama | 28 | barra 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ódigo | Nome | Descrição |
|---|---|---|
| 0 | SYS_OK | OK |
| 1 | SYS_BOOT | Boot do sistema |
| 2 | SYS_REBOOT_USER | Reboot solicitado pelo usuário |
| 3 | SYS_HEAP_LOW | Heap baixa |
| 4 | SYS_UPTIME_MARK | Marco de uptime |
| 5 | SYS_LOG_SUPPRESSED | Registros de rotina suprimidos |
| 10 | SYS_WIFI_CONNECT | Conectando WiFi |
| 11 | SYS_WIFI_DISCONNECT | WiFi desconectado |
| 12 | SYS_WIFI_SCAN | Varredura WiFi |
| 13 | SYS_NTP_SYNC | NTP sincronizado |
| 14 | SYS_IP_ACQUIRED | IP obtido |
| 15 | SYS_AP_START | AP iniciado |
| 20 | SYS_STORAGE_FAIL | Falha no storage |
| 21 | SYS_STORAGE_SAVE | Config salva |
| 22 | SYS_STORAGE_ROTATE | Storage rotacionado |
| 23 | SYS_STORAGE_FORMAT | Formatando flash |
| 24 | SYS_STORAGE_RECOVER | Storage recuperado |
| 25 | SYS_STORAGE_MIGRATED | Config migrada |
| 30 | SYS_TEL_SENT | Telemetria enviada |
| 31 | SYS_TEL_FAIL | Falha de telemetria |
| 32 | SYS_TEL_RETRY | Retry de telemetria |
| 33 | SYS_TEL_QUEUE | Telemetria enfileirada |
| 34 | SYS_TEL_SSL | Cert SSL carregado |
| 35 | SYS_TEL_MQTT_CONN | MQTT conectado |
| 36 | SYS_TEL_MQTT_DISC | MQTT desconectado |
| 37 | SYS_TEL_MQTT_PUB | MQTT publicado |
| 100 | LOG_SENSOR_REC | Sensor recuperado |
| 101 | ERR_SENSOR_TIMEOUT | Timeout de sensor |
| 102 | ERR_SENSOR_CHECKSUM | Erro de checksum |
| 103 | ERR_SENSOR_CRC | Erro de CRC |
| 104 | ERR_SENSOR_RANGE | Sensor fora de range |
| 105 | ERR_SENSOR_MISMATCH | Divergência de hardware |
| 106 | ERR_SENSOR_MISSING | Sensor ausente |
| 200 | EVT_UI_TOUCH | Evento de toque |
| 201 | EVT_DISPLAY_RESTART | Display reiniciado |
| 202 | EVT_GRAPH_RENDER | Gráfico renderizado |
| 300 | SEC_LOGIN_SUCCESS | Login bem-sucedido |
| 301 | SEC_LOGIN_FAIL | Falha de login |
| 302 | SEC_UNAUTHORIZED | Acesso não autorizado |
| 303 | SEC_CONFIG_CHANGED | Config alterada |
| 304 | SEC_SESSION_EXPIRE | Sessão expirada |
| 305 | SEC_FILE_UPLOAD | Arquivo enviado |
| 306 | SEC_FILE_DELETE | Arquivo apagado |
| 307 | SEC_BT_LOCKOUT | Bloqueio Bluetooth |
| 308 | SEC_PIN_OK | PIN do painel aceito |
| 309 | SEC_PIN_FAIL | PIN do painel recusado |
| 310 | SEC_PIN_LOCKOUT | Bloqueio do PIN do painel |
| 311 | SEC_PIN_AMBIGUOUS | Entrada do teclado casa com duas contas |
| 312 | SEC_SESSION_REVOKED | Sessão encerrada: conta alterada |
| 400 | APP_DISPLAY_LAUNCHED | Display iniciado no Core 1 |
| 401 | APP_TOUCH_CAL_INITIAL | Calibração inicial do touch salva |
| 402 | APP_TOUCH_CAL_REQUIRED | Calibração do touch necessária |
| 403 | APP_AP_MODE_TRIGGERED | AP iniciado |
| 404 | APP_READY | Sistema pronto |
| 405 | APP_READY_AP | Sistema pronto (modo AP) |
| 406 | APP_STORAGE_CRITICAL | Falha crítica de storage |
| 407 | APP_SENSORS_CALIBRATED | Sensores calibrados |
| 408 | APP_NTP_CORRECTING | NTP corrigindo timestamps |
| 409 | APP_NTP_CORRECTED | Timestamps corrigidos |
| 410 | APP_CACHE_INVALIDATED | Caches de gráfico invalidados |
| 411 | APP_AIR_CYCLE_HELD | Ciclo Air retido em M0 |
| 412 | APP_AIR_COLD_BOOT | Boot frio, não veio da hibernação |
| 413 | APP_AIR_SLEEP_CLAMPED | Sono limitado a menos de 24 h (alarme é por hora do dia) |
| 414 | APP_AIR_WAKE_INCOMPLETE | Wake anterior do Air não completou |
| 440 | APP_UI_THEME_CHANGED | Tema alterado via UI |
| 441 | APP_UI_LANG_CHANGED | Idioma alterado via UI |
| 442 | APP_UI_ALARM_SAVED | Limites de alarme salvos via UI |
| 443 | APP_UI_TOUCH_CAL_SAVED | Calibração do touch salva |
| 444 | APP_UI_TOUCH_SENS_SAVED | Sensibilidade do touch salva |
| 445 | APP_UI_PIN_CHANGED | PIN do display alterado |
| 446 | APP_UI_SOUND_SAVED | Config de som salva |
| 447 | APP_UI_ALARM_SILENCED | Alarme silenciado via UI |
| 448 | APP_UI_ALARM_SILENCE_EXP | Silenciamento de alarme expirou |
| 449 | APP_UI_ALARM_DEACTIVATED | Todos alarmes desativados (RAM) |
| 450 | APP_UI_USER_ADDED | Usuário criado pelo painel |
| 451 | APP_UI_USER_DELETED | Usuário removido pelo painel |
| 452 | APP_UI_USER_PIN_SET | PIN do painel definido |
| 453 | APP_UI_USER_PERMS | Permissões alteradas pelo painel |
| 454 | APP_UI_MAINT_ON | Manutenção aberta pelo painel |
| 455 | APP_UI_MAINT_OFF | Manutenção encerrada pelo painel |
| 456 | APP_UI_ALARM_BLOCKED | Alarmes do sensor bloqueados pelo painel |
| 457 | APP_UI_ALARM_UNBLOCKED | Alarmes do sensor desbloqueados pelo painel |
| 458 | APP_UI_PERM_DENIED | Ação do painel recusada: sem permissão |
| 459 | APP_UI_PIN_POLICY | Política de PIN alterada pelo painel |
| 470 | APP_ALARM_TRIGGERED | Alarme disparado |
| 471 | APP_ALARM_CLEARED | Alarme zerado |
| 472 | APP_ALARM_SILENCE_CANCEL | Silenciamento cancelado |
| 480 | APP_CACHE_MINMAX_FULL | Cache Min/Max carregado |
| 481 | APP_CACHE_MINMAX_PARTIAL | Cache Min/Max parcial |
| 482 | APP_CACHE_GRAPH_STARTED | Refresh de cache iniciado |
| 483 | APP_CACHE_GRAPH_DONE | Refresh de cache concluído |
| 484 | APP_CACHE_GRAPH_AMBIENT | Cache de gráfico: ambiente |
| 485 | APP_CACHE_GRAPH_BOARD | Cache de gráfico: placa |
| 486 | APP_CACHE_PRELOAD_DONE | Pré-carga de cache concluída |
| 487 | APP_GRAPH_LOADING | Carregando gráfico |
| 488 | APP_GRAPH_BUDGET | Budget de render excedido |
| 489 | APP_PRELOAD_BUDGET | Budget de pré-carga excedido |
| 500 | APP_DISPLAY_PAUSE_STUCK | Pause do display preso >5s |
| 501 | APP_YIELD_STUCK | Yield preso >10s |
| 502 | APP_CORE1_DEAD | Core 1 travado >10s, reiniciando |
| 503 | APP_FLASH_BUSY | Colisão por flash ocupado |
| 510 | APP_HISTORY_SAVED | Registro de histórico salvo |
| 511 | APP_HEAP_REPORT | Relatório de heap |
| 512 | APP_HIST_NO_TIME_REF | Histórico pulado: sem referência de hora |
| 513 | APP_HIST_TIME_REF_RECOVERED | Histórico retomado: referência de hora obtida |
| 514 | APP_HIST_NO_SCHEMA | Histórico pulado: schema V4 vazio |
| 515 | APP_HIST_SCHEMA_MISMATCH | Histórico pulado: schema não cobre sensor ativo |
| 520 | NET_DHCP_MODE | Modo DHCP ativado |
| 521 | NET_STATIC_MODE | Modo IP estático ativado |
| 522 | NET_STARTING | Gerenciador WiFi iniciando |
| 523 | NET_SSID_MISSING | SSID WiFi não configurado |
| 524 | NET_PROVISIONAL_TIME | Hora provisória do flash |
| 525 | NET_CONNECT_TIMEOUT | Timeout na conexão WiFi |
| 526 | NET_DORMANT_MODE | WiFi em modo dormente |
| 527 | NET_SHOW_IP | Mostrar IP |
| 528 | NET_MDNS_FAIL | Falha ao iniciar mDNS |
| 529 | NET_WIRED_STARTING | Rede cabeada iniciando |
| 530 | NET_WIRED_MODULE_FAIL | Módulo de rede não iniciou |
| 531 | NET_WIRED_NO_ADDRESS | Sem endereço no cabo |
| 532 | NET_WIRED_LOST | Rede cabeada perdida |
| 540 | TEL_HTTP_INIT | Transporte HTTP inicializado |
| 541 | TEL_MQTT_INIT | Transporte MQTT inicializado |
| 542 | TEL_MQTT_CONNECTING | MQTT conectando |
| 543 | TEL_CERT_EMPTY | cert.pem vazio, modo inseguro |
| 544 | TEL_CERT_READ_ERR | Erro de leitura de cert.pem |
| 545 | TEL_CERT_MISSING | Sem cert.pem, modo inseguro |
| 546 | TEL_FORCE_SYNC | Forçando sync de telemetria |
| 547 | TEL_BACKOFF_SUPPRESSED | Logs de retry suprimidos |
| 548 | TEL_HA_DISCOVERY | Discovery HA atualizado |
| 549 | TEL_ALARM_LINE_ON | Linha de telemetria de alarmes ligada |
| 550 | TEL_ALARM_SENT | Payload de alarmes enviado |
| 551 | TEL_ALARM_FAIL | Falha no envio de alarmes |
| 552 | TEL_ALARM_ACK | Recebimento de alarmes confirmado |
| 553 | TEL_ALARM_DROP | Estouro da fila de alarmes |
| 554 | TEL_CURSOR_RESENT | Arquivo do dia reenviado pela telemetria |
| 560 | STO_WRITE_FAILED | Falha em escrever histórico |
| 561 | STO_CORRECT_BUDGET | Budget de correção de ts excedido |
| 562 | STO_ENFORCE_BUDGET | Budget de limite de storage excedido |
| 563 | STO_ENFORCE_SKIP_ACTIVE | Pulando arquivo de log ativo |
| 564 | STO_STATS_REPORT | Relatório de estatísticas |
| 565 | STO_CONFIG_REPORT | Relatório de config |
| 566 | STO_H5_SEALED | Bloco de histórico selado |
| 567 | STO_H5_WIP | Snapshot de histórico gravado |
| 568 | STO_SCHEMA_MISMATCH | Schema de histórico divergente |
| 569 | STO_LEGACY_PURGED | Histórico legado apagado |
| 570 | WEB_SERVER_STARTED | Servidor web iniciado |
| 571 | WEB_DISCONNECT_FILE | Cliente desconectado (arquivo) |
| 572 | WEB_DISCONNECT_HISTORY | Cliente desconectado (histórico) |
| 573 | WEB_SCREENSHOT_ABORTED | Screenshot abortado pelo cliente |
| 574 | WEB_UPLOAD | Arquivo enviado |
| 575 | WEB_CLIENT_DISCONNECT | Cliente desconectado (conexão encerrada) |
| 576 | WEB_CERT_INVALID | Certificado web inválido (HTTP) |
| 577 | WEB_CORS_ORIGIN | CORS ligado para a origem |
| 578 | WEB_CORS_INVALID | Origem CORS inválida (CORS desligado) |
| 579 | WEB_CERT_INSTALLED | Par de certificados web instalado |
| 580 | CFG_THEME_APPLIED | Tema aplicado |
| 581 | CFG_THEME_NOT_FOUND | Tema não encontrado |
| 585 | CLI_UNKNOWN_CMD | Comando desconhecido |
| 590 | SENSOR_RUNTIME_LOADED | Sensores em runtime carregados |
| 600 | DSP_FORCE_UNPAUSE | Forçar despausar |
| 610 | OTA_TRIAL_STARTED | Atualização em teste |
| 611 | OTA_TRIAL_CONFIRMED | Atualização confirmada |
| 612 | OTA_TRIAL_EXPIRED | Atualização não confirmada a tempo |
| 613 | OTA_TRIAL_REVERTED | Atualização revertida |
| 614 | OTA_TRIAL_BUY_FAILED | Falha ao confirmar a atualização |
| 620 | I18N_PACK_LOADED | Pacote de idioma carregado |
| 621 | I18N_PACK_OUTDATED | Pacote de idioma mais antigo que o firmware |
| 622 | I18N_PACK_MULTIPLE | Mais de um pacote de idioma em /lang |
| 623 | I18N_PACK_FAILED | Falha ao carregar o pacote de idioma |
| 999 | ERR_UNKNOWN | Erro 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 |