An IoT glossary: common terms explained in plain words

The Internet of Things (IoT) means ordinary equipment fitted with sensors and a connection, so it can report what is happening and sometimes act on its own. The vocabulary around it can make a simple project sound complicated. Below are the terms you are most likely to hear from a developer or vendor, grouped by where they fit, each with a short, plain explanation.

The physical parts

• Sensor: a component that measures something, such as temperature, humidity, water level, electric current or motion, and turns it into a signal a circuit can read.
• Actuator: the opposite of a sensor. It does something: switches a pump on, opens a valve, sounds a buzzer.
• Relay: an electrically controlled switch that lets a small circuit turn larger equipment on and off. Anything connected to mains power should be wired by a qualified electrician.
• Microcontroller: a small, low-power computer on a single chip that reads sensors and runs simple programs. The ESP32 is one; Arduino boards are built around one.
• Single-board computer: a more capable small computer, such as a Raspberry Pi, that runs a full operating system.
• Gateway: a device that collects data from nearby sensors and passes it on to the internet. Useful when sensors use a short-range or low-power radio.
• Enclosure and IP rating: the enclosure is the box that protects the electronics. An IP rating is a standard code that describes how well a box keeps out dust and water; check what each digit means for your conditions.

Connections and messages

• Connectivity: how a device sends its data: Wi-Fi, mobile data through a SIM, LoRa, Bluetooth or a cable. Each suits different distances, power budgets and locations. The article on IoT connectivity options compares them.
• LoRa: a long-range, low-power radio technology suited to small amounts of data over wide areas such as farms.
• MQTT: a lightweight messaging method widely used by IoT devices. Devices publish messages to named topics, and other systems subscribe to the topics they care about. See MQTT explained for more.
• Broker: the server in an MQTT system that receives messages and passes them on to subscribers.
• Telemetry: the stream of readings a device sends back, such as a temperature reading every few minutes.
• Heartbeat: a small, regular "I am alive" message. When heartbeats stop, the system knows a device is offline instead of assuming all is well.

Software and data

• Firmware: the program that runs on the device itself.
• OTA (over-the-air) update: installing new firmware remotely, without visiting the device with a cable.
• Cloud: servers on the internet that store data and run dashboards and alerts.
• Edge processing: doing some of the work on or near the device, for example switching a pump off locally even when the internet is down.
• Dashboard: the screen, usually on a phone or computer, that shows current readings, history and alerts.
• Threshold: the value at which the system reacts, such as sending an alert. Set thresholds with the people responsible for the equipment and the relevant official guidance, not by guesswork.
• Alert fatigue: what happens when people receive so many alerts that they start ignoring them.
• API: a defined way for one piece of software to exchange data with another, for example sending sensor data into your inventory or accounts system.

Reliability and accuracy

• Accuracy: how close a reading is to the true value.
• Calibration: checking a sensor against a trusted reference and correcting any difference.
• Drift: the slow movement of a sensor's readings away from the truth over time.
• Uptime: how much of the time a system is working as intended.
• Watchdog: a built-in timer that restarts a device automatically if its program freezes.
• Backup power: a battery, UPS or solar arrangement that keeps devices running through power cuts, which matters a great deal in many district towns.

Using this glossary in a real conversation

You do not need to master these terms to start a project. What helps is knowing enough to ask good questions:

1. Which sensors and actuators does this need, and who will install them safely?
2. How will each device connect, and what happens when that connection drops?
3. Where will the data be stored, and who owns it?
4. How will we know if a device goes offline or a sensor drifts?
5. How will firmware be updated after installation?

If a vendor answers those clearly, without hiding behind jargon, the project is on solid ground. If the answers are vague, ask again in plain words until they are not. Remember that monitoring adds to proper safety equipment and qualified technicians; it never replaces them.

Where to go next

A good way to test the answers in real conditions is a small IoT pilot project before a full rollout: one site, a few sensors, a few weeks of real data. To talk through your own project in plain words, see the IoT development service.