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.

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

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.
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.
The IoTFlows cloud receives the stream, stores it, and turns it into metrics.
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.

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, Calibrate BeamTracker, and Calibration settings reference.

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.

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.

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.

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.

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.