# IoT Data Visualization: From Dashboards to the Mobile App

> How to structure IoT data visualization for a fleet: custom dashboards built once with Blueprint, Custom Widgets for missing charts, and a branded mobile app.

![IoT Data Visualization: From Dashboards to the Mobile App](https://tago.io/og/blog/iot-data-visualization-dashboards-mobile-app.png)

Nobody argues about whether an IoT platform needs good visualization. Sensor data nobody looks at is a storage bill. Every buyer we talk to puts "custom dashboards" near the top of the requirements list, and every vendor, us included, answers with a demo: a gauge, a line chart, a map with pins, a few widgets on a grid. ThingsBoard and Grafana come up in the same conversation, and each produces an equally convincing demo.

The demo is the problem. A dashboard for one device on a big screen says nothing about what happens when the fleet is 400 devices, the customer wants a chart type the product does not ship, and the people who need the data are technicians who will never open a laptop. Those three things decide whether visualization scales, and none of them show up in a demo.

This post is how we structure visualization on TagoIO for a fleet, and where you still need to write code.

![One dashboard, every device, every phone: tagged devices sharing variable names feed one Blueprint Dashboard whose widget slots resolve per device, rendered into the TagoRUN web portal and mobile app with push notifications, while Custom Widgets add chart types from any web library and Access Management policies decide who sees which device](https://tago.io/images/blog/iot-data-visualization-dashboards-mobile-app/one-dashboard-every-device-every-phone.svg)

## One dashboard for hundreds of devices

The first thing that breaks after the demo is the dashboard count. If each device gets its own dashboard, device 400 means dashboard 400, and a layout change means 400 edits. Cloning feels fine at ten devices and is unmanageable at fifty.

A [Blueprint Dashboard](https://docs.tago.io/docs/tagoio/dashboards/blueprint-dashboard) links widgets to devices at runtime instead. You build one layout. Each widget points at a blueprint slot rather than a fixed device, and each slot has a tag filter (type=pump, for example) that decides which devices appear in its dropdown. The user picks a device at the top of the dashboard, every widget bound to that slot reloads, and the same dashboard serves every pump you have tagged. A dashboard can hold up to 20 slots, so one view shows a pump and a tank side by side, and filter conditions can chain slots so that picking a customer narrows the device dropdown to that customer's sensors.

The catch is discipline, not features. Blueprint only works if devices sharing a slot use the same variable names. A widget reading `pressure` goes blank on the device that sends `pump_pressure`. Fix variable names and the tag scheme in the Payload Parser or Connector before the first dashboard exists, because renaming variables across 400 devices later is a week nobody budgets for. Blueprint also does not control who sees what; Access Management policies do that, matching TagoRUN users to devices by tag.

## When the widget you need does not exist

Built-in widgets cover the usual cases: charts, gauges, maps, tables, device and user lists, forms for sending data back. Sooner or later a customer wants something the product does not ship: a hexbin heatmap of a warehouse floor, a ring gauge styled to a brand guide, a chart shape that only exists in one library.

The [Custom Widget](https://docs.tago.io/docs/tagoio/widgets/custom-widget) is the escape hatch. It is one tile on a Normal or Blueprint dashboard that loads your own HTML, CSS, and JavaScript from a URL you host (TagoIO Files works). Any web charting library fits, and the [ECharts tutorial](https://docs.tago.io/docs/tagoio/widgets/custom-widget/echarts-custom-widget-tutorial-) is the fastest way to see the handshake: include the TagoIO custom-widget library, receive the configured device variables, draw. Custom Widgets get the full data model, including realtime updates, sending data back, and triggering an Analysis, and they work inside TagoRUN like any other widget.

Honest note: this is code. Someone on your team writes and hosts JavaScript. That is a fair price for a chart the platform does not have and a bad trade when a built-in widget does most of the job.

There is also the experimental [Custom Dashboard](https://docs.tago.io/docs/tagoio/dashboards/custom-dashboard/custom-dashboard-vs-custom-widget), where the whole page is your HTML file, hosted and versioned by TagoIO, with data arriving through saved TagoSQL queries. It runs in Admin and is not available in TagoRUN, public share, or distribute, so treat it as an internal reporting tool. The experimental AI Dashboard builds a full-page Admin layout from a natural-language prompt and refines it by chat; handy for prototyping a view before committing to a widget grid, and also not available in TagoRUN.

## Getting the same views onto phones under your brand

The third thing the demo hides is the audience. The people who need visualization most are not in the office: facility managers, field technicians, the customer's operations lead. They will not log into an Admin console or tolerate a dashboard that is unreadable on a phone.

[TagoRUN](https://tago.io/run) is where end users see the dashboards you built: a web portal under your domain and brand, with its own user management and per-user access policies. The same Blueprint Dashboard renders inside it, resolved to the devices each user may see. The [TagoRUN mobile app](https://docs.tago.io/docs/tagoio/tagorun/getting-started/tagorun-mobile-app) gives those users the same dashboards on iOS and Android with no extra build work.

Push notifications are the part people forget to check in a demo, and they are half the value of mobile. An Action watching a threshold, or an Analysis running a more involved check, pushes a notification straight to registered TagoRUN users on their phones. Notifications sent from an Analysis can carry buttons, so a technician acknowledges an alert without opening a dashboard.

If the store listing needs your name rather than ours, the Custom Mobile App add-on publishes a white-label version of the app to the App Store and Google Play under your brand. There is a one-time fee for packaging and deployment; pricing is on the Profile page in Admin.

## The limit a busy dashboard will hit

Every dashboard load costs data output. Each time someone opens a dashboard in Admin or TagoRUN, TagoIO counts one output per register displayed, so a dashboard rendering 3,000 data points counts 3,000. The counter is separate from the Data Output Service and is not billed, but it has a hard monthly ceiling per plan that you cannot raise yourself:

| Plan | Dashboard registers per month |
|---|---|
| Free | 3,000,000 |
| Starter | 15,000,000 |
| Scale | 50,000,000 |

Hitting the ceiling means dashboards error until the month resets.

Design against it. A chart plotting a month of one-minute readings loads about 43,000 registers every time a technician glances at it. Aggregate in an Analysis, store the summary in a variable, and plot that. Set short default time ranges. Watch the "Dashboard Output" row under Hard Limits in Admin before a customer does, and check the current ceilings in [data output for dashboards](https://docs.tago.io/docs/tagoio/dashboards/data-output-for-dashboards).

## A checklist before you commit

- Can one dashboard serve every device of a type, selected at runtime, without cloning?
- Are variable names and the tag scheme fixed before the first dashboard exists?
- When a customer asks for a chart the product lacks, can you add it with a web library, and does it still work in the end-user portal?
- Do end users get the same dashboards on the web and on a phone under your brand, with push notifications from the same rules?
- Do you know what a busy dashboard costs in data output, and where the ceiling is?

A demo answers none of these. A week with a tagged fleet, a Blueprint Dashboard, one Custom Widget, and the mobile app on a technician's phone answers all of them.

## Resources

- [Notifications for TagoRUN users](https://docs.tago.io/docs/tagoio/tagorun/getting-started/notifications-for-users)
- [Data output for dashboards](https://docs.tago.io/docs/tagoio/dashboards/data-output-for-dashboards)
- [TagoRUN: deploy your own white-label IoT platform](https://tago.io/blog/tagorun-deploy-your-own-white-label-iot-platform)

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