What are 5 IoT devices examples?
Five clear cases: an industrial vibration sensor bolted to a motor, a cellular asset tracker on a shipping container, a smart thermostat that switches off a furnace remotely, a hospital infusion pump reporting dosing data, and a soil-moisture probe on a farm feeding an irrigation controller. Each one senses a physical condition, has some onboard compute, and sends that reading over a network to a system that can act on it. That third property — something downstream can act, automatically or by a human looking at a dashboard — is what separates an IoT device from a plain data logger, and it's the test worth applying before calling anything "IoT."
What actually counts as an IoT device
A device qualifies if it does three things: senses or captures a state, connects that reading to a network without a person manually offloading the data, and exposes the reading (or itself) to remote management or action. IBM's overview of the field frames the Internet of Things as physical objects fitted with sensors and software that exchange data with other systems over the internet, which lines up with that three-part test — IBM's IoT overview.
The boundary cases are where the definition earns its keep:
- A Wi-Fi laptop is not usually called an IoT device — it's a general-purpose computer that happens to have network hardware, not a purpose-built endpoint tied to one sensing or control task.
- A smartphone sits in a gray zone: it has sensors (GPS, accelerometer) and connectivity, but it's general-purpose and user-driven rather than a fixed-function endpoint, so most practitioners exclude it from device counts even though it can act as a client for IoT systems.
- A voice assistant speaker is closer to a genuine IoT device: it has a defined function (listen, respond, relay commands), persistent connectivity, and it's remotely updatable and manageable by the vendor.
- An industrial PLC on Modbus is unambiguously IoT-adjacent once it's bridged onto an IP network for monitoring — before that bridge exists, it's just a local control loop with no network exchange, which fails the connectivity leg of the test.
Coursera's introductory explainer describes IoT devices as everyday and industrial objects fitted with sensors, software and network connectivity that let them collect and exchange data, which is consistent with using purpose-built function as the dividing line rather than raw computing power — Coursera's IoT explainer.
Ten examples, one line each
| # | Device | Function |
|---|---|---|
| 1 | Vibration/temperature sensor on rotating machinery | Detects early bearing or motor wear before failure |
| 2 | Cellular asset tracker | Reports location and condition of cargo or equipment in transit |
| 3 | Smart thermostat | Adjusts heating/cooling remotely based on sensed temperature |
| 4 | Connected infusion pump | Streams dosing and status data to hospital monitoring systems |
| 5 | Soil-moisture probe | Triggers irrigation valves when moisture drops below a threshold |
| 6 | Smart electricity meter | Sends consumption readings to the utility for billing and load analysis |
| 7 | Fleet telematics unit | Tracks vehicle location, speed and engine diagnostics |
| 8 | Connected smoke/CO detector | Alerts a phone app and building system when triggered |
| 9 | Warehouse RFID/barcode gateway node | Aggregates inventory scans and forwards them to a stock platform |
| 10 | Wearable heart-rate monitor | Streams biometric data to a health app for trend alerts |
Several roundups of applications and devices group these into consumer, industrial and healthcare categories, which is useful because the cost and security requirements differ sharply between a $20 consumer sensor and a ruggedized industrial one — Built In's IoT examples list.
Machine wear or fault begins
A predictive-maintenance case starts with a physical fault, not a dashboard. A vibration sensor mounted on an industrial motor housing continuously samples frequency and amplitude, and a temperature sensor on the same asset tracks heat buildup as bearings begin to wear.
- The sensor records a change in vibration signature or a temperature rise outside the normal operating band.
- That reading is packaged as telemetry data and sent over the plant network — often via an industrial gateway — to a monitoring platform.
- The platform's real-time monitoring compares the new reading against the asset's baseline and flags the deviation.
- A maintenance ticket is generated automatically, and a technician schedules the repair during planned downtime instead of after a breakdown.
This sequence is the actual reason industrial IoT sensors exist: not "connectivity" as an end in itself, but catching a wear pattern early enough to convert an unplanned stoppage into a scheduled one. Built In's list of examples covers this predictive-maintenance pattern as one of the more common industrial deployments — Built In's IoT examples list.
Asset moves outside any fixed network
A tracking case starts with an object that leaves the building. A shipping container, a delivery van, or a piece of rental equipment can't rely on Wi-Fi because it has no fixed access point to associate with once it's on a highway or a shipping route.
Cellular connectivity is what makes tracking possible at that scale, because it doesn't depend on the asset staying near a router. Verizon's overview of IoT system examples describes fleet and asset-tracking deployments built specifically around cellular coverage for exactly this reason — Verizon's IoT system examples.
- The tracker's GPS module and onboard sensors capture position, temperature (for cold chain) or shock (for fragile freight).
- That data streams over the cellular network to a fleet or asset management platform, not over a local network the operator controls.
- The operator sees the asset's position and condition updated in near real time on a dashboard.
- If the asset deviates from its route, stops moving unexpectedly, or a temperature threshold is breached, the operator reroutes a driver or dispatches recovery.
The deciding factor here isn't the sensor — a GPS chip is a GPS chip — it's the connectivity choice. Wi-Fi and short-range radio (Zigbee, Bluetooth) fail as soon as the asset leaves a fixed footprint; cellular and satellite links are what make wide-area and mobile deployments work at all.
Device is deployed without managed identity or updates
An unmanaged endpoint is where IoT security incidents start. A sensor or camera shipped with a default password, connected directly to a network with no separate segment, and never enrolled in a device-management system is effectively an open door.
- The device sits on the same flat network as file servers, payroll systems or building controls, with no VLAN boundary between them.
- Because nobody is tracking its firmware version or issuing credentials to it, it becomes an entry point a scanner or botnet operator can find and use to pivot toward more valuable systems.
- Applying device management fixes this: unique per-device authentication instead of shared defaults, TLS-based connectivity instead of unencrypted plaintext, and network segmentation so a compromised sensor can't reach payroll or SCADA systems even if it's taken over.
- Ongoing enrollment in an IoT platform is what makes patching and credential rotation possible at fleet scale instead of one device at a time.
This is the practical meaning of "IoT security": not a slogan, but a checklist applied at deployment time — identity, encrypted transport, segmentation, and a management system that can push an update six months later when a flaw is found.
Environmental sensor measures temperature or air quality
A building-automation case starts with a sensed condition, not a command. A CO2 sensor or a temperature probe placed in an office space or a server room reads a value continuously.
- The reading crosses a set threshold — CO2 above a stale-air limit, or temperature above the equipment's safe operating range.
- The building platform doesn't just log this; it issues a remote command to the HVAC system or a cooling unit.
- The equipment responds — a damper opens, a compressor kicks in — without a facilities technician walking the floor.
- Conditions return to the acceptable range, and the correction is recorded as part of the building's operating history.
This sense-decide-actuate loop is what separates an IoT device from a plain data logger: a logger only records, but the loop above closes on itself, with the platform making (or triggering) a decision based on the sensor's own reading. CBT Nuggets' rundown of everyday IoT examples covers smart thermostats and air-quality sensors performing this same loop in residential settings — CBT Nuggets' everyday IoT examples.
The layers behind any of these examples
Every example above depends on the same stack, even though the device itself is the only part most people ever see.
IoT device. The physical endpoint — sensor, actuator or both — with enough onboard compute to format a reading and enough network hardware to send it. This is the layer covered above; everything else exists to move its data somewhere useful and, sometimes, to send a command back.
Connectivity technology. The link carrying that data off the device. The choice isn't cosmetic — it decides range, power draw and cost. A short-range radio (Bluetooth, Zigbee) suits a device that's always near a hub; a low-power wide-area network suits a battery-powered sensor that needs to run for months; cellular suits anything mobile or far from fixed infrastructure. Onomondo's explainer on IoT devices walks through this connectivity layer as the differentiator between deployment types rather than the device hardware itself — Onomondo's IoT devices explainer.
Cellular connectivity, specifically, matters for anything stationary-but-remote (a soil probe in a field with no Wi-Fi) or genuinely mobile (a delivery van, a shipping container). It costs more per device than short-range radio but removes the dependency on a local network existing at all.
Communication protocol. The rules the device and the receiving system agree on to exchange the data meaningfully — how a reading is framed, acknowledged and retried if it doesn't arrive. This sits on top of connectivity: two devices can both use cellular and still speak completely different protocols to their respective platforms.
IoT gateway. The point where several low-power devices — sensors that can't afford the power cost of a direct cellular or Wi-Fi radio — aggregate their readings before that combined stream is forwarded onward. A field of soil-moisture probes, for instance, typically don't each carry their own cellular chip; they report over a short-range radio to a single gateway box that holds the cellular or Wi-Fi connection for the whole cluster. This is the layer that makes battery-only sensors financially and physically viable, and it's the reason a "device" in a spec sheet is often really a device-plus-gateway pair.
IoT platform / device management. The software on the receiving end that provisions each device with credentials, tracks its firmware version, accepts its data stream, and pushes updates or configuration changes back down. This is also where the security checklist from earlier gets enforced at scale — one dashboard rotating credentials across thousands of devices rather than a technician visiting each one.
Telemetry data. The readings themselves, once they've traveled through connectivity, protocol and gateway to reach the platform. This is the raw material every dashboard, alert and predictive-maintenance ticket is built from — a vibration reading, a GPS coordinate, a CO2 parts-per-million value, timestamped and attributed to a specific device ID.
What each layer costs
Readers trying to estimate a deployment run into three separate cost lines that are often quoted as one number.
| Cost component | What it covers | What drives it up |
|---|---|---|
| Hardware | Sensor, compute board, enclosure, radio module | Ruggedization (industrial), battery capacity, number of sensor types per unit |
| Data plan | Cellular or LPWAN subscription per device | Message frequency, payload size, coverage region |
| Platform | Device management, ingest, storage, dashboards | Number of connected devices, retention period, alerting rules |
A single consumer thermostat bundles all three into one retail price; an industrial deployment of a thousand vibration sensors prices them separately, and the data-plan and platform lines usually recur monthly long after the hardware is paid off. Onomondo's explainer notes that the connectivity contract, not the sensor hardware, is often the recurring line item that dominates a deployment's running cost — Onomondo's IoT devices explainer.
What happens when connectivity drops
Every example above assumes the network link is up. It won't always be, and what a device does in that gap matters more than the marketing phrase "real-time" usually admits.
- A well-built device buffers readings locally — on flash storage or in memory — and replays them once the link returns, rather than silently discarding data collected during an outage.
- A device doing meaningful onboard processing (comparing a reading against a threshold before sending) can still trigger a local action — closing a valve, sounding an alarm — even with no network path to the platform at all.
- A poorly built device simply drops readings taken while offline, which turns "real-time monitoring" into monitoring with silent gaps that only show up when someone reconciles the data later.
- Failover to a secondary connectivity path (a cellular backup on a device that's normally Wi-Fi-connected, for instance) is a design decision made at deployment time, not something added afterward.
None of this shows up in a spec sheet's headline claims, but it's the difference between a monitoring system a plant actually trusts and one that gets quietly ignored after the first unexplained gap in the data.
The four types of IoT, if the term is useful at all
"Types of IoT" usually means the deployment context, not a technical classification set by any standards body — there's no official taxonomy with exactly four entries. The categories that recur across industry roundups are consumer (thermostats, wearables, smart speakers), commercial (retail tracking, building automation), industrial (predictive maintenance, process monitoring) and infrastructure (utility metering, traffic sensors). Built In's roundup of examples groups its list along these same lines, which is a useful organizing principle even though it isn't a formal standard — Built In's IoT examples.
Treat this as a rough sorting tool for figuring out which cost and security requirements apply, not as a definition to memorize. A consumer thermostat and an industrial PLC gateway are both "IoT," but nothing about their price, failure mode or attack surface is comparable, and that gap is the more useful thing to understand than the category label itself.
Start by naming the loop your own use case needs — sense, decide, act — and work backward to the sensor, connectivity and platform that close it, rather than starting from a device name.