Ninguém discute se uma plataforma de IoT precisa de boa visualização. Dado de sensor que ninguém olha é conta de armazenamento. Todo comprador com quem conversamos coloca “dashboards personalizados” bem no alto da lista de requisitos, e todo fornecedor, nós inclusive, responde com uma demo: um gauge, um gráfico de linha, um mapa com pinos, alguns widgets em um grid. ThingsBoard e Grafana aparecem na mesma conversa, e cada um entrega uma demo igualmente convincente.
A demo é o problema. Um dashboard de um dispositivo em uma tela grande não diz nada sobre o que acontece quando a frota tem 400 dispositivos, o cliente quer um tipo de gráfico que o produto não oferece e as pessoas que precisam do dado são técnicos que nunca vão abrir um notebook. Esses três pontos decidem se a visualização escala, e nenhum deles aparece em uma demo.
Este post mostra como estruturamos visualização na TagoIO para uma frota, e onde você ainda precisa escrever código.
Um dashboard para centenas de dispositivos
A primeira coisa que quebra depois da demo é a quantidade de dashboards. Se cada dispositivo ganha o seu próprio dashboard, o dispositivo 400 vira o dashboard 400, e mudar o layout vira 400 edições. Clonar parece tranquilo com dez dispositivos e fica impossível de gerenciar com cinquenta.
Um Blueprint Dashboard liga os widgets aos dispositivos em tempo de execução. Você monta um layout só. Cada widget aponta para um slot do blueprint em vez de um dispositivo fixo, e cada slot tem um filtro por tag (type=pump, por exemplo) que define quais dispositivos aparecem no dropdown daquele slot. O usuário escolhe um dispositivo no topo do dashboard, todo widget ligado àquele slot recarrega, e o mesmo dashboard atende todas as bombas que você marcou com tag. Um dashboard aceita até 20 slots, então uma única visão mostra uma bomba e um tanque lado a lado, e condições de filtro podem encadear slots: escolher um cliente reduz o dropdown de dispositivos aos sensores daquele cliente.
O ponto crítico é disciplina, não funcionalidade. Blueprint só funciona se os dispositivos que compartilham um slot usarem os mesmos nomes de variáveis. Um widget que lê pressure fica vazio no dispositivo que envia pump_pressure. Acerte os nomes de variáveis e o padrão de tags no Payload Parser ou no Connector antes de existir o primeiro dashboard, porque renomear variáveis em 400 dispositivos depois é uma semana que ninguém coloca no orçamento. Blueprint também não controla quem vê o quê; isso é papel das políticas de Access Management, que ligam usuários do TagoRUN aos dispositivos por tag.
Quando o widget de que você precisa não existe
Os widgets nativos cobrem os casos comuns: gráficos, gauges, mapas, tabelas, listas de dispositivos e de usuários, formulários para enviar dado de volta. Uma hora ou outra um cliente quer algo que o produto não oferece: um heatmap hexbin do piso de um galpão, um gauge circular no padrão visual da marca, um formato de gráfico que existe em uma biblioteca só.
O Custom Widget é a válvula de escape. É um único bloco em um dashboard Normal ou Blueprint que carrega o seu próprio HTML, CSS e JavaScript de uma URL que você hospeda (TagoIO Files resolve). Qualquer biblioteca web de gráficos encaixa, e o tutorial de ECharts é o caminho mais rápido para entender o handshake: inclua a biblioteca de custom widget da TagoIO, receba as variáveis do dispositivo configurado, desenhe. Custom Widgets recebem o modelo de dados completo, incluindo atualização em tempo real, envio de dado de volta e disparo de uma Analysis, e funcionam dentro do TagoRUN como qualquer outro widget.
Aviso honesto: isso é código. Alguém do seu time escreve e hospeda JavaScript. É um preço justo por um gráfico que a plataforma não tem e uma troca ruim quando um widget nativo já faz quase todo o trabalho.
Existe também o Custom Dashboard experimental, em que a página inteira é o seu arquivo HTML, hospedado e versionado pela TagoIO, com os dados chegando por consultas TagoSQL salvas. Ele roda no Admin e não está disponível no TagoRUN, no compartilhamento público nem no distribute, então trate-o como ferramenta interna de relatório. O AI Dashboard experimental monta um layout de página inteira no Admin a partir de um prompt em linguagem natural e refina por chat; útil para prototipar uma visão antes de fechar um grid de widgets, e também não está disponível no TagoRUN.
As mesmas visões no celular, com a sua marca
A terceira coisa que a demo esconde é o público. Quem mais precisa de visualização não está no escritório: gestores prediais, técnicos de campo, o líder de operações do cliente. Essas pessoas não vão entrar em um console de Admin nem aceitar um dashboard ilegível no celular.
O TagoRUN é onde o usuário final vê os dashboards que você montou: um portal web no seu domínio e com a sua marca, com gestão de usuários própria e políticas de acesso por usuário. O mesmo Blueprint Dashboard renderiza lá dentro, resolvido para os dispositivos que cada usuário pode ver. O aplicativo móvel do TagoRUN entrega os mesmos dashboards no iOS e no Android sem trabalho extra de build.
Notificação push é a parte que todo mundo esquece de checar em uma demo, e é metade do valor do mobile. Uma Action observando um limite, ou uma Analysis rodando uma verificação mais elaborada, envia a notificação direto para os usuários registrados do TagoRUN, no celular deles. Notificação disparada de uma Analysis pode levar botões, então o técnico reconhece um alerta sem abrir dashboard.
Se a listagem na loja precisa ter o seu nome em vez do nosso, o add-on Custom Mobile App publica uma versão white-label do aplicativo na App Store e no Google Play com a sua marca. Há uma taxa única de empacotamento e publicação; o preço está na página de Profile no Admin.
O limite que um dashboard movimentado vai bater
Cada carregamento de dashboard consome data output. Toda vez que alguém abre um dashboard no Admin ou no TagoRUN, a TagoIO conta um output por registro exibido, então um dashboard que renderiza 3.000 pontos de dados conta 3.000. Esse contador é separado do Data Output Service e não é cobrado, mas tem um teto mensal rígido por plano que você não consegue aumentar por conta própria:
| Plano | Registros de dashboard por mês |
|---|---|
| Free | 3.000.000 |
| Starter | 15.000.000 |
| Scale | 50.000.000 |
Se você bate no teto, os dashboards passam a dar erro até o mês virar.
Projete contando com isso. Um gráfico que plota um mês de leituras de um minuto carrega cerca de 43.000 registros cada vez que um técnico bate o olho nele. Agregue em uma Analysis, guarde o resumo em uma variável e plote isso. Deixe intervalos de tempo curtos como padrão. Acompanhe a linha “Dashboard Output” em Hard Limits no Admin antes que o cliente perceba, e confira os tetos atuais em data output para dashboards.
Um checklist antes de fechar
- Um único dashboard consegue atender todos os dispositivos de um tipo, escolhidos em tempo de execução, sem clonar nada?
- Os nomes de variáveis e o padrão de tags estão definidos antes de existir o primeiro dashboard?
- Quando um cliente pede um gráfico que o produto não tem, você consegue adicionar com uma biblioteca web, e ele continua funcionando no portal do usuário final?
- O usuário final recebe os mesmos dashboards na web e no celular com a sua marca, com notificação push vinda das mesmas regras?
- Você sabe quanto um dashboard movimentado custa em data output, e onde está o teto?
Uma demo não responde nenhuma dessas. Uma semana com uma frota já marcada por tags, um Blueprint Dashboard, um Custom Widget e o aplicativo móvel no celular de um técnico responde todas.
