Grafana is already on the screen in plenty of engineering rooms. It charts CPU, memory, request latency, and queue depth, and teams trust it. So when sensor data starts showing up, from temperature probes, water meters, or machine vibration, the natural instinct is to put it in the same Grafana that everyone already watches. But Grafana does not collect from a device, does not store a time series of readings, and does not speak the protocols your hardware uses. It draws what a data source hands it, and nothing more. Therefore the real question is not “can Grafana chart IoT data,” it is “what stands between the device and Grafana, doing ingestion, storage, and the API,” and that gap is where TagoIO fits.
What Grafana actually needs from you
Grafana reads. It connects to a data source, runs a query, and renders panels. For infrastructure that data source is usually Prometheus or a SQL database that something else is already filling. For IoT data you have to provide the same thing: an endpoint Grafana can query that returns time-stamped values.
Grafana supports this through data source plugins. The Infinity data source is the common pick for arbitrary REST APIs. It can pull JSON over HTTP, handle Bearer tokens and API keys, and parse a response into rows and time series using JQ or UQL. There is also a JSON API plugin that does similar work. Either way, the contract is the same: give Grafana a URL that returns JSON, tell it which fields are the timestamp and the value, and it charts the rest.
What none of these plugins do is talk to your sensors. They assume the data already exists somewhere with an HTTP front door. That assumption is the whole job, and it is the part Grafana hands off.
The part before Grafana: ingestion and storage
A sensor in the field does not emit clean JSON over HTTPS on its own. It speaks LoRaWAN through a network server, or NB-IoT, or raw MQTT, or it posts a vendor-specific payload that needs decoding. Before any of that becomes a chart, three things have to happen:
- The reading has to be received, which means handling the device protocol and the network it rides on.
- The raw payload has to be parsed into named variables with units and timestamps.
- The parsed values have to be stored as a time series you can query later, not just the latest reading.
This is the work TagoIO does. Devices connect over HTTP or MQTT, with MQTT available on port 1883 or 8883 over SSL. TagoIO has device integrations for 500-plus models and networks, so the protocol handling is handled before you write anything. A payload parser turns the raw bytes into variables like temperature or fuel_level. Those land in time-series storage, each record carrying a time, a value, a variable name, and often a unit. The exact connector and parser setup lives in docs.tago.io, and the steps differ by device, so follow the docs for your specific hardware rather than a generic recipe.
The point is that by the time Grafana asks for data, the data exists, is clean, and has an API in front of it.
Exposing TagoIO data so Grafana can read it
TagoIO has a full REST API, and reading device data from it is a GET request. The endpoint is the regional data URL:
GET https://api.<region>.tago.io/dataAuthentication is a Device Token passed in the Authorization header. From docs.tago.io, the request to pull a single variable looks like this:
https://api.<region>.tago.io/data?variable=temperature&qty=99You can filter by time window with start_date and end_date, which accept ISO strings or relative expressions like 1 day. You can ask for just the latest reading with query=last_item. You can request several variables at once using array syntax, variable[]=temperature&variable[]=pressure.
The response is JSON with a result array, where each entry carries the fields Grafana cares about:
{
"status": true,
"result": [
{
"id": "547e353d7dbf3af122c0257d",
"time": "2014-12-02T21:55:09.301Z",
"unit": "%",
"value": 32,
"variable": "fuel_level"
}
]
}That shape maps onto an Infinity or JSON API query cleanly. The root is result, time is your timestamp column, value is the numeric column, and variable lets you split or filter series. Point the Grafana data source at the TagoIO data URL, set the Authorization header with your Device Token, set the root to result, and map the columns. From there it is a normal Grafana panel.
A few honest caveats worth checking against the docs. TagoIO applies rate limits, so a dashboard that refreshes every few seconds across many panels can hit them. The default qty is small, so set it explicitly when you want a real time range. And tokens are scoped, so think about which token a shared Grafana instance should hold before you paste it into a data source.
When you do not need Grafana on top of TagoIO
This path is worth taking only when it earns the second tool. TagoIO has its own dashboards and widgets. If your need is line charts, gauges, maps, and tables over device data, the built-in dashboards already cover it, and adding Grafana means running and maintaining another system, managing another set of credentials, and syncing two definitions of the same chart. That is more moving parts for a result you already have.
Grafana on top makes sense in specific cases. You are standardizing on Grafana across teams and want IoT data to live next to infrastructure metrics so people look in one place. You need a Grafana-specific panel, alerting rule, or plugin that TagoIO does not offer. You are merging IoT readings with non-IoT sources in a single Grafana view. In those cases the extra tool pays for itself. If none of them apply, stay in TagoIO and skip the integration.
Where TagoIO fits
Grafana is the display layer, and it is good at being the display layer. The work it cannot do is everything that happens before a query returns clean JSON: receiving from the device, decoding the payload, and keeping a queryable time series. TagoIO does that work and then exposes the result through a documented REST API, which is exactly the kind of source Grafana plugins are built to read. You keep Grafana as the front of glass and let TagoIO be the part of the stack that turns hardware into data.
Next steps
- Read how to pull device data over the API: Getting Data on docs.tago.io
- Review token types and scoping: Device Token on docs.tago.io
- Check MQTT connection details if you prefer streaming ingestion: MQTT Overview on docs.tago.io
- Start an account and connect a device: tago.io
