From Sensor to Dashboard: How Industrial IoT Monitoring Works

A tank level alert on a phone looks simple. A pump vibration trend on a dashboard looks simple too. Behind both is a chain of devices, signals, networks, software, and rules that must work together, often in harsh industrial sites where heat, noise, distance, dust, and water are part of the job.

Industrial IoT monitoring is the practice of collecting real-world data from equipment and processes, moving it securely to a software platform, and turning it into status, trends, alarms, and work instructions.

The full path is usually:

Sensor → Signal → RTU → Network → Cloud → Dashboard → Alarm → Action

Each step matters. If the sensor is wrong, the dashboard is wrong. If the signal cannot travel reliably, the cloud never sees the data. If alarms are poorly set, people stop trusting them.

This guide explains how the whole system works, including common industrial signal types such as 4–20 mA, pulse, RS485, Modbus, LoRaWAN, 4G, and MQTT, with ProSight as the dashboard layer that makes the data useful.

Industrial monitoring starts with reliable field measurements.

The sensor measures what is happening in the field

The sensor is where industrial IoT begins. It converts a physical condition into an electrical value that another device can read.

Common examples include:

• Pressure in a compressed air line

• Water level in a tank

• Flow rate through a pipe

• Temperature inside a process vessel

• Motor run status

• Pump vibration

• Valve position

• Rainfall, wind, or site weather conditions

  
  

For example, a pressure transducer on a pump outlet might measure line pressure. A level sensor might track a chemical tank. A flow meter might count how much water passes through an irrigation line.

This is where product selection matters. A dashboard cannot fix the wrong sensor type, range, or installation point. For many common applications, categories such as ProSense pressure sensors, ProSense temperature sensors, ProSense flow sensors, and ProSense level sensors cover the starting point of the system.

A good sensor choice answers a few practical questions:

• What exactly needs to be measured?

• What is the expected measurement range?

• Is the site wet, dusty, corrosive, hot, or exposed to sunlight?

• Does the sensor need local display?

• How far is it from the control panel or remote terminal unit?

• What signal output does the receiving device accept?

  
  

The last question leads to the next step.

The signal carries the measurement

A sensor does not usually send “tank is 63 per cent full” in plain language. It sends an electrical signal. The receiving device interprets that signal and turns it into an engineering value.

The most common industrial signal types include 4–20 mA, pulse, RS485, and Modbus.

4–20 mA is the workhorse analogue signal

A 4–20 mA signal uses electrical current to represent a measurement range.

A common example:

• 4 mA means 0 kPa

• 20 mA means 1,000 kPa

• 12 mA means roughly 500 kPa

  
  

The signal starts at 4 mA, not zero, because this helps detect faults. If the circuit reads 0 mA, the cable may be broken, the sensor may have no power, or something else has failed.

4–20 mA is widely used because it works well over long cable runs and resists electrical noise better than many voltage signals. It is common in pressure, level, flow, and temperature applications. Many ProSense transmitters are designed around this style of field signal.

Pulse signals count events or rotations

A pulse output sends a repeating on-off signal. Each pulse represents an event, such as a litre of water passing through a flow meter or one rotation of a shaft.

Pulse is common for:

• Totalising flow

• Tracking machine cycles

• Measuring frequency or speed

• Counting pump starts

• Recording rainfall from tipping-bucket gauges

  
  

Pulse signals are simple and useful, but they need the right input type and clean wiring. They can also need debouncing or filtering if the signal comes from a mechanical contact.

RS485 lets devices communicate over distance

RS485 is an electrical communication standard. It is not a data language on its own. It defines the physical layer that lets devices talk over a twisted pair cable, often across long distances.

RS485 is useful when several devices need to share one communication line. For example, a site may have several meters or instruments wired on the same RS485 network back to a controller.

Modbus gives structure to the data

Modbus is a communication protocol. It tells devices how to request and return data.

A Modbus device stores values in registers. A controller or RTU asks for a register, and the device replies with the value. That value might be flow rate, total flow, temperature, pressure, status, or a fault code.

In plain terms:

• RS485 is the wiring method

• Modbus is the conversation

• The sensor or meter provides the data

  
  

Modbus RTU over RS485 remains common across water, energy, manufacturing, agriculture, and building services because it is simple, well known, and supported by many field devices.

Different signal types often meet inside the same field enclosure.

The RTU collects and prepares the data

An RTU, or remote terminal unit, sits between field devices and the wider network. It is often installed in a control panel, pump station, bore shed, tank farm, or remote site cabinet.

The RTU’s job is to collect signals, process them, and send the right data onwards.

Typical RTU functions include:

• Reading 4–20 mA analogue inputs

• Counting pulses

• Reading digital inputs and outputs

• Polling Modbus devices over RS485

• Scaling raw values into engineering units

• Applying basic logic

• Storing data during network outages

• Sending data to the cloud

  
  

A sensor might produce 12.6 mA. The RTU converts that into 537 kPa. A flow meter might send 350 pulses. The RTU turns that into litres or cubic metres. A Modbus energy meter might expose dozens of registers. The RTU reads only the values needed.

This step is also where data quality improves. The RTU can reject impossible values, average noisy signals, apply calibration offsets, or mark a device as failed if communication stops.

A practical setup often mixes signal types. One RTU might read:

Field device	Signal type	Example value
Tank level sensor	4–20 mA	72 per cent full
Flow meter	Pulse	18.4 kL total
Pressure transmitter	4–20 mA	420 kPa
Energy meter	Modbus over RS485	13.2 kW
Rain gauge	Pulse	2.4 mm rainfall

This is common in real sites. Industrial IoT rarely uses one clean signal type everywhere. The RTU brings them together.

The network moves data off site

Once the RTU has data, it needs a path to the cloud. The best network depends on site layout, power, coverage, bandwidth, and how often data needs to update.

Common options include Ethernet, Wi-Fi, LoRaWAN, and 4G.

LoRaWAN works well for low-power remote sensing

LoRaWAN is designed for small amounts of data sent over long distances with low power use. It suits battery-powered sensors and remote monitoring points where only occasional readings are needed.

Good LoRaWAN use cases include:

• Tank level

• Soil moisture

• Weather stations

• Gate or access status

• Low-frequency flow or pressure readings

• Environmental monitoring

  
  

LoRaWAN is not ideal for high-speed control or large data volumes. It is better for periodic monitoring, such as readings every few minutes or every hour.

For widely spread assets, LoRaWAN can reduce cabling and power requirements. That can be useful across farms, water networks, reservoirs, industrial yards, and utilities.

4G gives wide-area connection for remote sites

4G cellular is one of the most practical ways to connect remote industrial assets. If a site has coverage and suitable antenna placement, a 4G router or RTU can send data to the cloud without fixed internet.

4G is often used for:

• Pump stations

• Remote tanks

• Irrigation systems

• Temporary equipment

• Mining and quarry sites

• Utilities and council assets

• Mobile plant support equipment

  
  

The key design checks are signal strength, antenna location, data allowance, carrier coverage, and power backup. In regional Australia, antenna choice and mounting height can make a large difference.

A 4G-connected RTU can often buffer values locally if the network drops out, then forward them when the connection returns.

Remote sites often use cellular or low-power networks to reach the cloud.

MQTT publishes data to the cloud

MQTT is a lightweight messaging protocol often used in industrial IoT. It is popular because it works well over networks that may have limited bandwidth or occasional dropouts.

MQTT uses a publish and subscribe model.

A device publishes data to a topic, such as:

`site01/pump01/pressure`

A cloud platform subscribes to that topic and receives updates.

This approach is different from older polling methods, where a central system repeatedly asks each device for data. With MQTT, field devices can send values when scheduled, when a value changes, or when an alarm condition occurs.

MQTT is useful because it supports:

• Small message sizes

• Clear topic structures

• Secure connections when configured correctly

• Efficient data transfer

• Many devices feeding one platform

  
  

Security still needs proper design. Devices should use authentication, encrypted connections where supported, careful access control, and sensible topic naming. A publicly exposed device with weak credentials is a serious risk.

The cloud stores and organises the data

The cloud receives incoming messages, checks them, stores them, and makes them available to users and applications.

This is where raw field data becomes a monitoring system.

A cloud platform may handle:

• Device registration

• Data storage

• Time-series history

• User access

• Alarm rules

• Dashboard views

• Reports

• Notifications

• API access to other systems

  
  

This layer also makes remote access practical. A service team does not need to visit a pump shed just to know if pressure dropped overnight. An operations team can compare sites, review trends, and check whether alarms repeat under the same conditions.

Cloud design should match the value of the data. Some readings only need short retention. Others, such as water use, environmental data, production counts, or compliance-related records, may need longer history and tighter access control.

ProSight turns data into a usable dashboard

A dashboard is not just a collection of numbers. It should help someone understand what is happening, what changed, and what needs attention.

ProSight plays this role in the monitoring chain. It takes field data from sensors, RTUs, and connected devices, then presents it as live values, historical trends, alarms, and site views.

A useful ProSight dashboard might show:

• Tank levels across several sites

• Pump running status

• Flow rate and daily total

• Pressure trends before and after pump starts

• Battery voltage at remote stations

• Communication status

• Alarm history

• Map-based asset locations

  
  

Good dashboards avoid clutter. They show the values people need for decisions, not every value a device can produce.

For example, a water operator may need to see tank level, inlet flow, outlet pressure, pump status, and alarm state. A maintenance technician may also need motor starts, runtime hours, fault history, and cabinet temperature.

The same data can support both views, but the dashboard should present it differently.

If the field system starts with suitable products, such as ProSense flow instrumentation, ProSense level measurement, and ProSense pressure measurement, ProSight can make those readings visible without people needing to interpret raw signals.

Alarms turn data into attention

A dashboard is helpful when someone checks it. Alarms are different. They call attention to a condition that needs action.

Common alarms include:

• High tank level

• Low tank level

• Low pressure

• High pressure

• No flow when pump is running

• Flow when valve should be closed

• Sensor fault

• RTU offline

• Low battery

• High cabinet temperature

  
  

The best alarms are specific. “Pump 2 outlet pressure low for 5 minutes while running” is more useful than “fault”.

Alarm rules need care. If alarms trigger too easily, people learn to ignore them. If they trigger too late, damage or downtime may already be underway.

Useful alarm design includes:

• Sensible thresholds

• Time delays to avoid nuisance trips

• Different severity levels

• Clear message text

• Escalation if nobody responds

• Alarm acknowledgement

• Alarm history for review

  
  

A good alarm should answer three questions:

1. What happened?

2. Where did it happen?

3. What should someone do next?

   
   

Action is the point of the whole system

The final step is action. Monitoring has value because it helps people do something sooner, safer, or with better information.

That action might be manual:

• Send a technician to inspect a pump

• Refill a chemical tank

• Clean a blocked strainer

• Check a failed level probe

• Investigate unexpected flow overnight

  
  

It may also be semi-automatic:

• Create a maintenance task

• Notify an on-call operator

• Export data to another system

• Trigger a report

• Escalate after a set time

  
  

In some systems, monitoring connects to control. That needs extra care. Reporting a low tank level is one thing. Starting or stopping equipment remotely is another. Control actions need permissions, safety checks, local fallback, and clear responsibility.

The goal is not to put every reading on a screen. The goal is to turn trusted field data into timely decisions.

The dashboard is useful when it leads to clear work in the field.

A complete example from tank to technician

Imagine a remote water tank supplying a small industrial site.

A level sensor measures the water level and sends a 4–20 mA signal to an RTU. A flow meter on the outlet sends pulses, with each pulse representing a known volume. A pressure sensor on the pump discharge also sends 4–20 mA. An energy meter reports pump power over Modbus RTU on RS485.

The RTU scales all readings into useful units:

• Tank level in per cent

• Flow in L/min

• Daily flow in kL

• Pressure in kPa

• Pump power in kW

• Pump run status

  
  

The RTU sends the data over 4G using MQTT. The cloud receives it, stores it, and makes it available to ProSight.

In ProSight, the operator sees a live dashboard with tank level, pump status, pressure, and flow trend. An alarm rule watches for low tank level. If the level stays below the threshold for long enough, ProSight sends an alert.

The technician receives the alarm, checks the dashboard history, and sees that the pump ran but pressure stayed low. That points to a likely suction issue, blocked filter, or pump fault. The technician arrives with the right parts and checks the most likely causes first.

That is the value of a well-built monitoring chain. It shortens the path from problem to response.

The weak links to check before building

Most monitoring problems come from basic design gaps, not from the cloud layer.

Before building a system, check these items:

• The sensor range matches the process

• The sensor output matches the RTU input

• Cable length and shielding suit the signal

• RS485 networks have correct termination and addressing

• Modbus register maps are documented

• Pulse scaling is known and tested

• The RTU can buffer data during outages

• 4G or LoRaWAN coverage is proven at the installed location

• MQTT security is configured correctly

• Alarm thresholds match real operating conditions

• Dashboard users see the values they need

  
  

Strong industrial IoT monitoring comes from all layers working together. A ProSense sensor in the right location, connected through the right signal and network, gives ProSight the data it needs to show what is happening and raise alarms before small problems become expensive ones.

The dashboard is only the visible part. The real system starts at the sensor and ends when someone takes the right action.