Remote monitoring with IoT means sending readings from sensors on machines, warehouses or sites over a network to a central platform, showing them on a dashboard and alerting the right person when a value crosses a limit. The system is made of sensors, a gateway, connectivity, a messaging protocol, a data platform and a dashboard. You don’t need a large transformation programme to start: a small pilot built around one measurable question is usually the most sensible route.
What are the building blocks of a remote monitoring system?
The table below traces the path from a temperature sensor to the notification on your phone.
| Layer | What it does | Example |
|---|---|---|
| Sensor and device | Measures a physical quantity | Temperature, current, level or vibration sensor; PLC |
| Gateway | Collects data from field devices, forwards it and buffers it when needed | Industrial mini PC, LoRaWAN gateway |
| Connectivity | Carries data from the field to the internet or your network | Wi-Fi, Ethernet, LTE-M, NB-IoT, LoRaWAN |
| Messaging | The common language between devices and the platform | MQTT |
| Data platform | Stores time-stamped data and runs rules | Time-series database, rules engine |
| Dashboard and alerts | Shows status and notifies when a limit is crossed | Web dashboard, mobile push, email |
| Remote commands | Sends instructions from the platform to a device | Stopping a pump, changing a setpoint |
Most sensors connect to a gateway rather than to the internet, and the gateway forwards their data. Existing equipment often has the data already: PLCs and energy meters can be read over industrial protocols, so not every measurement needs a new sensor.
A good dashboard first answers “is anything wrong right now?”, with details and history one click away. Remote commands need more care than monitoring: decide up front who can send which command, how you confirm it reached the device, and whether it can be undone.
Connectivity options: Wi-Fi, LTE-M, NB-IoT and LoRaWAN
The right connection depends on where the device sits, how often it sends data and how much, and whether it runs on mains power or a battery.
Wi-Fi is the quickest start if the building already has good coverage, and it supports high data rates. But it is relatively power-hungry for battery devices, coverage stops at the walls, and devices join your corporate network, so plan it with your IT team.
LTE-M and NB-IoT are cellular technologies that 3GPP standardised for the Internet of Things and that run on mobile operators’ licensed spectrum. According to 3GPP, LTE-M offers lower latency and higher throughput than NB-IoT and can support services such as voice over IP. NB-IoT runs in a narrow band as small as 200 kHz with very low device complexity. Roughly, LTE-M suits devices that report often or need low latency, and NB-IoT suits stationary, meter-like devices sending small, infrequent packets. Check that your operator offers the service at your site.
LoRaWAN is a low-power wide-area network (LPWAN) specification that runs in unlicensed frequency bands. The LoRa Alliance cites a range of up to 15 km in rural areas and more than 10 years of battery life in suitable scenarios, and notes that the technology is best suited to low-bandwidth, infrequent transmissions. With your own gateway you can cover a large site or farmland without an operator, but running that network becomes your job.
| Aspect | Wi-Fi | LTE-M | NB-IoT | LoRaWAN |
|---|---|---|---|---|
| Spectrum | Unlicensed | Licensed (operator) | Licensed (operator) | Unlicensed |
| Data rate | High | Medium | Low | Very low |
| Infrastructure | Your network | Operator network | Operator network | Your own gateway or a network provider |
| Good fit for | Indoor, mains-powered devices | Frequent data, low latency | Infrequent data, fixed devices | Large sites, battery sensors |
The table is a relative comparison; real range and battery life depend heavily on reporting frequency, building construction and antenna placement. When in doubt, run a coverage test with a few devices on site.
MQTT and designing for connection loss
MQTT is an OASIS-standard, lightweight publish/subscribe messaging protocol designed for IoT. Devices publish readings to topics such as “site1/coldroom/temperature”, and a broker distributes those messages to whatever subscribes: a dashboard, a database or a rules engine. The device doesn’t need to know who uses its data, and the same structure carries commands from the platform back to the device.
Field connections will drop sooner or later: an operator outage, a power cut, weak signal in a basement. Design for it:
- Store data at the source with a timestamp. The device or gateway keeps readings while offline and sends them in order when the connection returns. Timestamped at measurement, late data still lands in the right place.
- Choose the delivery level deliberately. The MQTT 5.0 specification defines three Quality of Service levels: at most once (messages can be lost), at least once (messages can be duplicated) and exactly once. For sensor readings, “at least once” is usually enough, as long as the platform discards duplicates.
- Treat silence as an event. MQTT’s Will Message lets the broker announce “this device is offline” on your behalf when a connection closes unexpectedly. No data for a set period should raise its own alert; otherwise “all fine” and “no data” look the same on the dashboard.
- Keep local functions running. A critical control, such as stopping a pump based on a level sensor, should not depend on the cloud connection. The European standard ETSI EN 303 645 likewise recommends that devices keep operating locally when network access is lost and recover cleanly when power returns.
Security basics
Connecting field devices opens a new attack surface. ETSI EN 303 645 was written for consumer devices, but its provisions make a good checklist for business projects too: no universal default passwords, keep software updated, communicate securely and minimise exposed attack surfaces. NIST’s core baseline for IoT devices similarly includes unique device identification, protection of stored and transmitted data, and software updates that only authorised entities can perform through a secure mechanism. In practice:
- Give every device its own identity. Use per-device credentials or certificates rather than one shared password, so a compromised device can be revoked on its own.
- Encrypt the traffic. Protect MQTT traffic with TLS; the MQTT specification recommends port 8883 for servers that offer TLS.
- Limit permissions. A device should only publish to its own topics, and only authorised users should reach the command channel.
- Plan updates from day one. You can’t visit scattered devices one by one, so remote, verified updates belong in the first release.
- Don’t expose devices to inbound connections. Devices should connect out to the broker rather than accept connections from outside.
Projects that touch industrial control systems also need network separation and controlled remote access; see our post on cybersecurity for industrial networks.
Start small: one measurable use case
Projects struggle most when they start with “let’s connect everything”. Start with one question instead and measure the result:
- Write down the question. Pick a one-sentence question with a measurable answer, such as “does the cold room exceed our temperature limit at night?”
- Define success. Decide what you will measure at the end: deviations caught, inspection trips avoided or a change in consumption.
- Start with a few devices. One line, one warehouse or a handful of tanks is enough, and installation issues surface cheaply.
- Decide who gets the alert. Who receives the alarm at night, and what do they do? If nobody can answer that, the system looks good on screen but changes nothing.
- Review, then expand. If the pilot answers its question, adding new sensors and use cases to the same platform becomes straightforward.
Some good candidates for a first use case:
| Use case | What is measured | What it gives you |
|---|---|---|
| Energy consumption | Electricity use per line, machine or building | Visibility of idle machines and out-of-hours consumption |
| Cold chain | Temperature in cold rooms, cabinets or vehicles | Instant alerts on limit breaches and an automatic temperature log |
| Water tank levels | Tank level, pump status | Prevents tanks running dry or overflowing, fewer site visits |
| Machine status | Running/stopped, current, temperature | A record of stoppages and their duration |
Over time, machine status data also becomes the foundation for predictive maintenance. We discuss how this kind of data is used with AI in our post on Industry 4.0 and AI.
Frequently asked questions
Can we connect our existing machines?
In most cases, yes. The first step is to check how the machine exposes its data: an industrial protocol, a serial connection or the manufacturer’s API. If the machine provides no data at all, you can add external current, temperature or vibration sensors without modifying it.
Which connectivity technology should we choose?
Location, power source and reporting frequency decide it. Wi-Fi or Ethernet may be enough for indoor, mains-powered devices. For battery sensors spread over a large area, look at LoRaWAN or NB-IoT; for devices that send data more often, consider LTE-M.
Should the data live in the cloud or on our own servers?
Both work. The cloud gives a fast start and easy scaling; your own servers make sense when data must not leave the site. Data sensitivity, your IT team’s capacity and applicable regulations decide.
Conclusion
IoT remote monitoring brings together sensors, connectivity, a messaging layer such as MQTT, a data platform and a dashboard. Planning for connection loss and security from the start is far easier than adding them later. A small pilot built around one measurable question is usually all you need to begin.
We build software that collects data from sensors and field devices and makes remote monitoring and control possible. If you have a use case in mind, take a look at our smart city and IoT or asset management pages, or get in touch and we can look at it together.
