---
title: "How sensors, the cloud, and the dashboard fit together"
description: "The four layers a reading passes through, from the sensor on the machine through Wi-Fi or the 4G/LTE router to the IoTFlows cloud and the dashboard: what each layer decides, why running and stopped is decided on the device while uptime and health are computed in the cloud, and what each layer looks like when it fails."
category: "Start here"
source_url: "https://www.iotflows.com/docs/get-started/how-iotflows-works/"
---
# How sensors, the cloud, and the dashboard fit together

Trace one vibration reading from the machine to the number on the screen.

Four layers stand between a spindle turning and an uptime figure on a dashboard: the sensor, the network it joins, the IoTFlows cloud, and the client you read it on. Each layer decides something different. Knowing which layer owns which decision tells you where to look when a number looks wrong.

## The four layers
A reading takes the same four hops on every machine.

Diagram: A diagram of four layers. A machine with a sensor feeds two parallel network paths, Wi-Fi and a 4G/LTE router, which both lead into the IoTFlows cloud, which in turn feeds a dashboard and a mobile app. Labels under each layer read: running or stopped decided here; carries readings, decides nothing; utilization, uptime, downtime, parts, health; live, over MQTT.

*How a reading travels: sensor, then Wi-Fi or the 4G/LTE router, then the IoTFlows cloud, then the dashboard and the mobile apps.*

1. **The sensor** sits on the machine and senses it continuously. What it senses depends on the device: SenseAi reads vibration and acoustics, SenseAi Embedded reads vibration only, and BeamTracker reads a laser beam broken by a passing part.
2. **The network** carries what the sensor publishes. That is either a 2.4 GHz Wi-Fi network in your facility or the IoTFlows 4G/LTE router, which makes its own cellular uplink.
3. **The IoTFlows cloud** receives the stream, stores it, and turns it into metrics.
4. **The clients**, meaning the web dashboard and the iOS and Android apps, read those metrics and subscribe to live updates.

Each sensor appears in IoTFlows as a *node*, the device record that is paired to one asset. An asset with no node is a name on a list, because every number on this page starts at a node.

Choose the 4G/LTE router when plant IT will not put devices on the facility network, or when the machine sits outside Wi-Fi coverage. Otherwise use facility Wi-Fi: it is one fewer device to power and monitor. See [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/).

## What the sensor decides on the device
The sensor decides one thing, and it decides it locally: what just happened on the machine. For SenseAi and SenseAi Embedded that is whether it is running; for BeamTracker, whether a part just passed.

It compares what it senses against settings fixed during calibration, and those settings differ by device.

SenseAi and SenseAi Embedded use an upper and a lower threshold to mark where running begins and ends, plus **Momentum**, which sets how long a reading must stay across a threshold before the state flips. Momentum keeps a machine that idles for four seconds between cycles from logging four seconds of downtime.

BeamTracker measures distance instead. A **Detection distance** and a **Min Object Thickness** bracket where a part counts as present, and the gap between them stops a part hovering on one edge from chattering the count.

Those settings are stored on the node, so the decision survives a network outage. A sensor with no route to the cloud still knows the machine is running; it just has nowhere to say so. See [Calibrate SenseAi](/docs/hardware/calibrate-senseai/), [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/), and [Calibration settings reference](/docs/hardware/calibration-settings/).

This is why calibration matters more than any dashboard setting. Every metric downstream is built from the running and stopped stream, and no cloud calculation can recover a boundary the sensor read wrong.

## What the cloud decides
The cloud never re-decides whether the machine was running. It aggregates.

Diagram: A two-column diagram divided by a dashed line. The left column, headed On the sensor, runs downward: what the sensor senses, being vibration and acoustics or a laser beam broken by a part; then the settings that shape the decision, which differ by device, with upper and lower thresholds and Momentum for SenseAi and SenseAi Embedded, and detection distance and minimum object thickness for BeamTracker; then a square-wave trace labeled Running or stopped, or a part detected, which both families produce. A single arrow carries that trace across the divider into the right column, headed In the cloud, where it branches into utilization, uptime, downtime, part counts, and a health score measured against a baseline. The left column is footed 'Decided in the moment. A boundary read wrong cannot be recovered.' The right column is footed 'Derived from that timeline. Recomputed on demand.'

*What the sensor decides on the device and what the cloud decides. The sensor decides what just happened, running or stopped on SenseAi and a part detected on BeamTracker; utilization, uptime and health scores are computed in the cloud.*

From that stream, the cloud computes utilization, uptime, downtime, and part counts, and splits all of them across shifts, departments, and date ranges. For BeamTracker it derives running time from the part detections first. Every metric has one definition, in [Metrics reference](/docs/monitoring/metrics-reference/).

Machine health is computed in the cloud too, against a *baseline*: the vibration signature the machine shows when it is healthy, which a health score is measured against. Because a baseline is a statement about one machine over weeks, it can only exist where the history is, which is the cloud. See [Choose a machine health baseline profile](/docs/monitoring/baseline-profiles/).

The cloud also owns everything a sensor never sees: jobs, work orders, stock, and people. A part count from a BeamTracker and a scrap count typed by an operator meet for the first time in the cloud.

## How the dashboard stays live
The dashboard does not poll for changes. It subscribes.

*MQTT* is a lightweight publish-subscribe protocol, the one IoTFlows uses to push changes to open pages the moment they happen. When you open the Assets page, it subscribes to the event stream for your organization and repaints an asset card as each node publishes, with no page refresh.

The same transport carries the work queue, the canvas, the production pages, and chat. A work order that a technician closes on a phone changes on your screen while you are looking at it.

Live updates and page data are separate. The metrics on a page are loaded once over the API when the page opens; MQTT only keeps them current. If the live connection drops, the page keeps its last-loaded numbers and stops advancing. See [What works without a connection](/docs/get-started/offline-behavior/).

## What happens when a layer drops
Each layer fails differently. Read the symptom and go straight to the layer that owns it.

### Layer responsibilities
| Layer | Decides | Fails how | Reader-visible symptom |
|---|---|---|---|
| Sensor | The boundary: running or stopped, or a part detected | Loses power, comes loose from the machine, or is calibrated wrong | The device reads offline in **Devices**, or the machine reads stopped while it is clearly cutting |
| Network | Whether readings reach the cloud | Wi-Fi password changes, access point is out of range, router loses its cellular uplink | The device reads offline in **Devices**, and charts show a gap for the length of the outage |
| Cloud | Utilization, uptime, downtime, part counts, health scores | Rare, and never partial for one machine | Every machine stops advancing at once, not one |
| Client | What you see, and how fast you see it | The browser or phone loses its connection to the live stream | The page keeps its last-loaded numbers and stops updating |

The first two rows share a symptom, so check the network before the sensor. See [Troubleshoot an offline device](/docs/hardware/troubleshoot-offline-device/).

## See also
- [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/)
- [What works without a connection](/docs/get-started/offline-behavior/)
- [Metrics reference](/docs/monitoring/metrics-reference/)
- [Troubleshoot an offline device](/docs/hardware/troubleshoot-offline-device/)