# Visualização de dados de IoT: do dashboard ao aplicativo móvel

> Como estruturar a visualização de dados de IoT para uma frota: dashboards personalizados montados uma única vez com Blueprint, Custom Widgets para os gráficos que faltam e um aplicativo móvel com a sua marca.

![Visualização de dados de IoT: do dashboard ao aplicativo móvel](https://tago.io/og/pt-br/blog/iot-data-visualization-dashboards-mobile-app.png)

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, todos os dispositivos, todos os celulares: dispositivos com tags e nomes de variáveis iguais alimentam um único Blueprint Dashboard cujos slots de widget resolvem por dispositivo, renderizado no portal web e no aplicativo móvel do TagoRUN com notificações push, enquanto Custom Widgets adicionam tipos de gráfico de qualquer biblioteca web e políticas de Access Management decidem quem vê qual dispositivo](https://tago.io/images/blog/iot-data-visualization-dashboards-mobile-app/one-dashboard-every-device-every-phone.svg)

## 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](https://docs.tago.io/docs/tagoio/dashboards/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](https://docs.tago.io/docs/tagoio/widgets/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](https://docs.tago.io/docs/tagoio/widgets/custom-widget/echarts-custom-widget-tutorial-) é 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](https://docs.tago.io/docs/tagoio/dashboards/custom-dashboard/custom-dashboard-vs-custom-widget) 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](https://tago.io/run) é 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](https://docs.tago.io/docs/tagoio/tagorun/getting-started/tagorun-mobile-app) 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](https://docs.tago.io/docs/tagoio/dashboards/data-output-for-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.

## Recursos

- [Notificações para usuários do TagoRUN](https://docs.tago.io/docs/tagoio/tagorun/getting-started/notifications-for-users)
- [Data output para dashboards](https://docs.tago.io/docs/tagoio/dashboards/data-output-for-dashboards)
- [TagoRUN: coloque no ar sua própria plataforma IoT white-label](https://tago.io/blog/tagorun-deploy-your-own-white-label-iot-platform)

[llms.txt](https://tago.io/llms.txt)