Alarmes que se escutam: faixas, limiares e avisos que não cansam

Um alarme que toca o dia inteiro deixa de ser um alarme. O manual diz sem rodeios: alarmes demais são piores que nenhum, porque a equipe se dessensibiliza e deixa passar os importantes. Se tudo é crítico, nada é crítico.

Esta nota trata do tempo real de uma operação: o que se mede, o que dispara, o que fica registrado e, sobretudo, o que chega ao telefone de quem. São quatro decisões: em que valores colocar os alarmes, quais se veem e quais tocam, quem recebe o quê, e quanto esperar antes de avisar.

Evento, alarme e notificação não são a mesma coisa

Convém separar três coisas que costumam ser tratadas como uma só.

• Um evento é algo que aconteceu e ficou registrado: um equipamento se conectou, alguém passou uma saída para manual, uma automação foi aplicada, uma tarefa foi concluída. Tudo vai para Atividade, uma única lista cronológica com o que foi, quando e quem fez.
• Um alarme vigia uma variável contra um valor. Se a condição se cumpre, ele dispara, fica registrado e espera que alguém o reconheça. Reconhecer deixa registrado que alguém leu; não resolve a causa.
• Uma notificação é o aviso que sai da plataforma para uma pessoa, por e-mail, Telegram ou push. Cada usuário escolhe seus canais e de quais eventos quer saber.

O erro habitual é criar um alarme e supor que ele tem de tocar. Não tem. Um alarme pode existir só para ser visto, e essa distinção é o que permite montar um sistema de avisos que não canse.

Os valores corretos

Um alarme analógico pode ser de três tipos: acima de um limiar, abaixo de um limiar ou fora de uma faixa. Para as variáveis digitais ele se define pelo estado esperado: se a saída deveria estar Ligada e aparece Desligada, o alarme dispara, ou o contrário.

O valor de um alarme não é o valor de trabalho. Um alarme colocado sobre o setpoint dispara a cada oscilação normal do controle, várias vezes por hora, e em uma semana ninguém olha mais. O valor correto sai do histórico: a dinâmica da variável durante uma semana boa mostra até onde ela vai sozinha, e o alarme fica por fora disso. Os alarmes configurados são desenhados sobre os gráficos da variável, no seu valor de ativação, então basta olhar a curva para saber quantas vezes ela o teria cruzado.

O manual soma dois critérios: limiares por ambiente e não globais, e poucos alarmes bem escolhidos. E um sinal de diagnóstico: reconhecer várias vezes o mesmo alarme indica que o limiar está mal calibrado ou que o problema é estrutural.

Faixa mais limiar: a sobrefaixa

Um único valor obriga a escolher entre saber tarde e saber demais. A saída é usar dois alarmes sobre a mesma variável, um de cada tipo, com destinos diferentes.

1. 01
   Faixa

   Fora de 22 – 27 °C. É a banda onde a variável deveria viver. Sair dela é um desvio: convém ver, não precisa acordar ninguém.

2. 02
   Limiar

   Acima de 30 °C, além da faixa. Isso é uma sobrefaixa: o controle já não dá conta e alguém tem de agir.

3. 03
   Notificações

   Em Minha conta > Notificações, dentro de Alarmes, desmarca-se «fora da faixa» e os limiares ficam marcados. A faixa continua existindo; só deixa de tocar.

O resultado são dois níveis. A saída da faixa é um alerta visual: aparece no widget de alarmes do painel, sobre a curva do indicador, em Atividade e no contador do menu. A sobrefaixa é a que faz o telefone tocar. E como toca pouco, quando toca é atendido.

Se os dois extremos são críticos, o esquema é o mesmo com dois limiares: um acima e outro abaixo, os dois por fora da faixa.

O filtro é de cada usuário, não da organização. Quem está na planta pode querer também as faixas no telefone; quem supervisiona várias plantas, só as sobrefaixas. O alarme é o mesmo e cada um decide quanto quer ouvir. Se alguém desliga todos os canais não chega nada, mas os alarmes continuam sendo registrados em Atividade.

Ninguém recebe aviso do que fez

As autonotificações estão desativadas por design. Se alguém passa uma saída para manual e a liga, o resto da equipe inscrita nesse evento recebe o aviso. Essa pessoa não: acabou de fazer, já sabe, e um telefone que toca pelas próprias ações ensina a ignorá-lo.

A regra vale para os eventos que têm autor: comandar uma saída, aplicar uma automação, criar, editar ou apagar um alarme, adicionar um equipamento. Os alarmes e os eventos de conexão não têm autor, então chegam a todos que os tenham marcados.

Os agentes, com conta própria

A segunda e a terceira linha da tabela são a razão desta seção. A Growcast expõe um servidor MCP, então um assistente de IA pode ler o mesmo que se vê no app e também agir: criar tarefas, criar alarmes, comandar saídas, aplicar automações. Se esse assistente se conecta com a conta de uma pessoa, para a plataforma ele é essa pessoa. O que fizer por conta própria não avisa o seu dono, porque ninguém recebe aviso das próprias ações, e em Atividade não se distingue o que cada um fez.

O manual recomenda o contrário: criar para o assistente a sua própria conta da Growcast e convidá-la para a organização. A partir daí tudo o que ele fizer fica em nome dessa conta, em Atividade, nas tarefas e em cada registro. E como é outro usuário, toda a equipe recebe o aviso quando ele age, inclusive quem o configurou. Um agente que trabalha sozinho tem de poder ser ouvido.

A conta própria também resolve as permissões. O assistente trabalha com o papel da sua conta: se essa conta não pode criar um lote, o assistente também não, e convém convidá-la com o papel mínimo de que precise. Ele não elimina nada nem administra usuários, e as ações sobre o hardware vão marcadas para que peça confirmação antes de executá-las. Se algo der errado, basta tirar o acesso dessa conta.

Conexões que piscam

Um link de internet instável produz o pior ruído de todos: desconectado, conectado, desconectado, conectado. Cada piscada dura segundos, não afeta nada, porque as regras rodam no equipamento e continuam funcionando sem internet, e ainda assim cada uma pode ser um aviso no telefone.

Para isso existe a espera de desconexão: nas notificações de conexão, cada usuário define quantos minutos esperar antes de receber o aviso, entre zero e quinze. Quando o prazo se cumpre, a plataforma olha o estado de novo: se o equipamento já voltou, não envia nada. Só avisa uma desconexão que continua sendo uma desconexão.

O valor da espera se escolhe por quanto tempo a operação pode ficar sem ser vista, não por quanto o aviso incomoda. Enquanto isso o estado ao vivo não se perde: o widget de estado do hardware mostra sozinho quando um dispositivo ou um módulo se desconecta.

Os alarmes, sempre à vista

Tudo o que foi dito tira ruído do telefone e o passa para a tela. Para funcionar, a tela tem de mostrá-lo: qualquer painel, responda a pergunta que responder, leva os alarmes à vista.

• O widget de alarmes ativos, filtrado ao ambiente do painel, com o botão de reconhecer. Seu estado normal é um cartão vazio, e por isso um cartão com texto se lê de longe.
• O estado do hardware ao lado. Se um módulo está fora, nenhum dos números do painel vale, e isso tem de ser visto antes dos números.
• Indicadores analógicos com a linha de alarme desenhada sobre a curva. Vê-se quão perto a variável está do valor que dispara, antes que dispare.
• O contador de Atividade no menu, que soma os alarmes e os eventos sem reconhecer, as ordens em curso e as tarefas pendentes. Quando chega a zero, não há nada esperando.

Os valores ao vivo chegam ao navegador por MQTT, sem sondagem: um indicador muda quando a variável muda e um alarme aparece no painel quando dispara. O alerta visual não é um aviso de segunda: é o primeiro a chegar.

Fechamento

• Valores tirados do histórico, por fora da oscilação normal, por ambiente.
• Faixa para ver, limiar para tocar: a faixa fica fora das notificações e a sobrefaixa chega ao telefone.
• Ninguém recebe aviso do que é seu; por isso cada agente trabalha com a sua conta e com o papel mínimo.
• Uma espera de desconexão de acordo com o link, para que uma piscada não seja notícia.
• Alarmes e estado do hardware visíveis em todos os painéis.

A tela avisa primeiro. O telefone toca só quando é preciso, e por isso é atendido.

Ver a plataforma→