After completing this chapter, you will be able to:
IoT devices come in many shapes and sizes – from tiny fitness trackers on your wrist to massive industrial sensors on factory floors. Connected device fundamentals means understanding the basic categories (wearable, consumer, industrial, infrastructure) and the trade-offs every designer faces: you can have great features, low cost, or long battery life, but optimizing all three at once is nearly impossible. Think of it as a triangle – improving one corner usually means sacrificing another. Understanding these trade-offs helps you choose the right type of device for any IoT project.
“Did you know there are four big families of IoT devices?” asked Sammy the Sensor. “There are wearables like fitness trackers that ride on your wrist, consumer devices like smart speakers in your kitchen, industrial machines in factories, and infrastructure things like traffic sensors on roads!”
Max the Microcontroller explained, “Every device has to balance three things – it is like a triangle. One corner is features (what it can do), another is cost (how much it costs to build), and the third is power (how long the battery lasts). You cannot max out all three! A cheap device with amazing features will drain Bella’s battery in hours.”
Bella the Battery sighed, “Tell me about it! A fitness tracker needs to last a whole week on one charge, so Max keeps things simple and Lila only lights up briefly. But a smart home hub is plugged into the wall, so it can have a big screen, fast processor, and all the features it wants.” Lila the LED grinned, “The trick is figuring out which corner of the triangle matters most for YOUR project!”
Before diving into this chapter, you should be familiar with:
In the Internet of Things, “things” are the physical devices that bridge the digital and physical worlds. These connected devices range from tiny sensors embedded in infrastructure to complex smart appliances in our homes. Understanding how to design, select, and deploy these devices is fundamental to building successful IoT systems.
This chapter explores the fundamentals of connected devices: what they are, their categories, and the critical design trade-offs that determine their success.
Analogy: IoT devices are like senses and limbs for the digital world. Just as your eyes see, ears hear, and hands interact with the physical world, IoT devices let computers see (cameras), hear (microphones), feel (sensors), and act (motors, switches) in the real world.
Simple definition: An IoT “thing” is any physical device that can: 1. Sense something (temperature, motion, light) 2. Connect to a network (Wi-Fi, Bluetooth, cellular) 3. Process data (even simple decisions) 4. Act on information (turn on/off, alert, adjust)
IoT “things” are physical objects embedded with electronics, software, sensors, and network connectivity that enable them to collect and exchange data.
Examples: Fitbit, Apple Watch, medical monitors
Key characteristics:
This device taxonomy illustrates the diversity of wearable IoT form factors: - Multiple placement options: Same sensing goal (activity tracking) achieved via different body locations - App ecosystem: Every wearable requires companion smartphone app for data visualization - User preference varies: Athletes prefer chest straps (accuracy), consumers prefer wrist (convenience) - Design trade-offs: Chest sensors are more accurate for heart rate, but wrist devices have higher adoption due to comfort
Source: University of Edinburgh - Principles and Design of IoT Systems
Consumer devices are designed for household and personal use, requiring user-friendly interfaces and often being AC-powered.
Examples: Smart thermostats, connected lights, smart speakers
Key characteristics:
Industrial devices operate in harsh environments with high reliability requirements, focusing on machine-to-machine (M2M) communication.
Examples: Process sensors, PLCs, industrial gateways
Key characteristics:
Infrastructure devices are deployed at scale in public spaces with long operational lifetimes (10+ years) and are difficult to service.
Examples: Smart parking sensors, air quality monitors, smart streetlights
Key characteristics:
Critical device characteristics to consider:
| Quality | What It Means | Example |
|---|---|---|
| Reliable | Works every time | Smart lock never fails to open |
| Efficient | Long battery life or low power | Sensor lasts 5 years on battery |
| Secure | Protected from hackers | Encrypted connection, strong passwords |
| Durable | Survives its environment | Outdoor sensor handles rain/heat |
| User-Friendly | Easy to set up and use | One-button pairing, clear status |
Every IoT device must balance three competing factors:
You can’t have all three! Pick two:
Real products make these trade-offs differently! Compare an Apple Watch (features-focused) vs a Fitbit (battery-focused) vs a basic pedometer (cost-focused).
A startup is designing a consumer indoor air quality monitor. The product requirements include PM2.5 particulate sensing, CO2 measurement, temperature/humidity, and a user-facing display. Three design approaches illustrate the device design triangle with real BOM (Bill of Materials) costs, power budgets, and feature sets.
Design A: Feature-Focused (Premium)
| Component | Part | Unit Cost | Power Draw |
|---|---|---|---|
| MCU | ESP32-S3 (dual-core, BLE+Wi-Fi) | $3.20 | 80 mA avg |
| PM2.5 sensor | Plantower PMS5003 (laser scattering) | $15.00 | 100 mA active |
| CO2 sensor | Sensirion SCD41 (photoacoustic NDIR) | $28.00 | 18 mA avg (5-min interval) |
| Temp/humidity | SHT41 (calibrated, +/-0.1C) | $4.50 | 0.01 mA |
| Display | 2.4” TFT color LCD | $6.00 | 40 mA |
| Enclosure | Injection-molded ABS + diffuser | $3.50 | – |
| PCB + passives | Custom 4-layer | $2.80 | – |
| Total BOM | $63.00 | 238 mA avg |
Retail price: $149. Battery life on 3,000 mAh: ~12.6 hours. Requires USB-C power (wall outlet).
Design B: Battery-Focused (Portable)
| Component | Part | Unit Cost | Power Draw |
|---|---|---|---|
| MCU | nRF52840 (BLE only, low power) | $3.80 | 5 mA avg |
| PM2.5 sensor | Sharp GP2Y1014 (optical, duty-cycled) | $7.00 | 11 mA (10s every 5 min = 0.37 mA avg) |
| CO2 sensor | Omitted (adds $28 + 18 mA) | – | – |
| Temp/humidity | SHTC3 (+/-0.2C) | $1.80 | 0.001 mA |
| Display | 1.5” e-ink (no backlight) | $8.00 | 0 mA (only during refresh) |
| Enclosure | Ultrasonic-welded recycled plastic | $1.50 | – |
| PCB + passives | 2-layer | $1.20 | – |
| Total BOM | $23.30 | 5.4 mA avg |
Retail price: $59. Battery life on 3,000 mAh: ~23 days. Portable, BLE-only (phone app required for history).
Design C: Cost-Focused (Mass Market)
| Component | Part | Unit Cost | Power Draw |
|---|---|---|---|
| MCU | ESP8266 (Wi-Fi, single core) | $1.50 | 70 mA avg |
| PM2.5 sensor | Omitted (too expensive) | – | – |
| CO2 sensor | Omitted | – | – |
| VOC proxy | SGP40 (MOX, indicates “air quality index”) | $4.50 | 3 mA |
| Temp/humidity | AHT20 (+/-0.3C) | $0.60 | 0.001 mA |
| Display | 3-color LED (green/yellow/red) | $0.15 | 5 mA |
| Enclosure | Simple snap-fit plastic | $0.80 | – |
| PCB + passives | Single-layer | $0.60 | – |
| Total BOM | $8.15 | 78 mA avg |
Retail price: $24.99. No battery – USB powered only. No PM2.5 or CO2 – uses VOC proxy index instead. Much less accurate, but 8x cheaper BOM than Design A.
Design Triangle Summary:
| Factor | Design A (Features) | Design B (Battery) | Design C (Cost) |
|---|---|---|---|
| BOM cost | $63.00 | $23.30 | $8.15 |
| Retail price | $149 | $59 | $24.99 |
| Battery life | Wall-powered only | 23 days | Wall-powered only |
| PM2.5 accuracy | +/-10 ug/m3 | +/-15 ug/m3 | No PM2.5 |
| CO2 measurement | Yes (SCD41 NDIR) | No | No (VOC proxy) |
| Connectivity | Wi-Fi + BLE | BLE only | Wi-Fi |
| Display | Color TFT | E-ink | 3 LEDs |
Battery Life Calculation for Design B: The portable air quality monitor has average power draw \(I_{\text{avg}} = 5.4 \text{ mA}\) with a 3,000 mAh lithium-ion battery. Battery life is \(t = \frac{C_{\text{battery}} \times \eta}{I_{\text{avg}}}\), where \(\eta\) is discharge efficiency (typically 0.85 for Li-ion at room temperature due to self-discharge and voltage cutoff before 0% SOC). Thus \(t = \frac{3000 \times 0.85}{5.4} \approx 472 \text{ hours} \approx 19.7 \text{ days}\). This matches the “23 days” claim when accounting for sleep mode optimizations (device enters deep sleep between measurements, reducing idle current from 5 mA to 0.05 mA for 90% of the time). Actual calculation with duty cycling: PM2.5 sensor runs 10 seconds every 5 minutes (\(\frac{10}{300} = 3.3\%\) duty cycle), drawing 11 mA when active but 0 mA when off. Average: \(11 \times 0.033 = 0.37 \text{ mA}\). MCU in deep sleep draws 0.05 mA (99% of time) but 5 mA when active (1% of time for sensor reads, BLE transmission). MCU average: \(0.05 \times 0.99 + 5 \times 0.01 = 0.0995 \text{ mA}\). E-ink display refreshes once per minute at 5 mA for 1 second (\(\frac{1}{60}\) duty cycle): \(5 \times \frac{1}{60} = 0.083 \text{ mA}\). Total refined: \(0.37 + 0.0995 + 0.083 + 0.001 = 0.55 \text{ mA}\). Battery life: \(\frac{3000 \times 0.85}{0.55} = 4,636 \text{ hours} \approx 193 \text{ days}\). This shows the power of duty cycling and sleep modes: reducing “always-on” draw from 5.4 mA to 0.55 mA extends life from 20 days to 193 days, demonstrating why battery-focused designs obsessively optimize idle current.
Experiment with different device parameters to see how they affect battery life:
<div style="font-size: 0.9rem; opacity: 0.9; margin-bottom: 0.5rem;">Battery Life</div>
<div style="font-size: 2.5rem; font-weight: bold;">${batteryLifeHours.toFixed(1)} hours</div>
<div style="font-size: 1.2rem; opacity: 0.95; margin-top: 0.3rem;">(${batteryLifeDays.toFixed(1)} days)</div><div style="font-size: 0.9rem; opacity: 0.9; margin-bottom: 0.5rem;">Energy Capacity</div>
<div style="font-size: 2.5rem; font-weight: bold;">${(batteryCapacity * efficiency).toFixed(0)} mAh</div>
<div style="font-size: 1.2rem; opacity: 0.95; margin-top: 0.3rem;">(effective)</div><div style="font-size: 0.9rem; opacity: 0.9; margin-bottom: 0.5rem;">Daily Consumption</div>
<div style="font-size: 2.5rem; font-weight: bold;">${(avgCurrent * 24).toFixed(0)} mAh</div>
<div style="font-size: 1.2rem; opacity: 0.95; margin-top: 0.3rem;">per day</div>Try adjusting the sliders above to see how battery life changes! Notice how reducing average current draw from 5.4 mA to 0.55 mA (through duty cycling) extends battery life from ~23 days to ~193 days.
Key lesson: Design B achieves 23-day battery life by cutting CO2 sensing ($28 saved, 18 mA saved), using duty-cycled PM2.5 (100 mA reduced to 0.37 mA average), and choosing BLE over Wi-Fi (70 mA saved). Design C hits $8.15 BOM by replacing real particulate/CO2 sensors with a $4.50 VOC proxy – cheaper, but unable to distinguish smoke from cooking odors. The “right” design depends entirely on the target market: health-conscious homeowners (A), parents with portable needs (B), or budget-conscious renters (C).
The Myth: Adding additional sensors always improves device quality without meaningful cost or power impact.
The Reality: Each sensor addition has compounding costs that go far beyond the component price:
| Adding… | Component Cost | Power Impact | Hidden Costs |
|---|---|---|---|
| BME280 (temp/hum/pressure) | +$2.50 | +0.6 mA | I2C bus load, firmware driver, calibration |
| PMS5003 (PM2.5) | +$15.00 | +100 mA active | Fan noise, air intake design, 30-second warm-up |
| SCD41 (CO2) | +$28.00 | +18 mA avg | 5-minute measurement interval minimum, self-calibration algorithm |
| SGP41 (VOC) | +$4.50 | +3 mA | 10-hour conditioning period on first power-up |
A four-sensor device does not cost 4x one sensor – it costs 4x sensors + larger battery + more complex PCB + longer firmware development + harder certification testing. The PMS5003 alone requires a fan that introduces acoustic noise, a physical air intake channel, and a 30-second warm-up per measurement. Each added sensor also increases failure modes: a 99.5% reliable sensor in a 5-sensor system yields 97.5% system reliability (0.995^5).
Rule of thumb: Start with the minimum viable sensor set. Add sensors only when user research confirms the additional data changes user behavior.
Successful IoT device design is fundamentally about managing tradeoffs: power consumption versus connectivity range, form factor versus battery life, cost versus durability, and functionality versus simplicity. The best IoT devices are those that make the right tradeoffs for their specific use case and environment, not those that try to maximize every dimension simultaneously. Always start by deeply understanding the deployment context, then work backward to device specifications.
When building IoT apps that support multiple device types, you need to discover what each device can do. This JavaScript example shows a device registry pattern used in smart home platforms:
// Device capability registry for multi-device IoT apps
class DeviceRegistry {
constructor() {
this.devices = new Map();
}
register(device) {
this.devices.set(device.id, {
id: device.id,
name: device.name,
category: device.category, // 'wearable', 'consumer', 'industrial'
capabilities: device.capabilities,
constraints: device.constraints,
registered: new Date().toISOString()
});
}
// Find devices matching requirements
query(requirements) {
return Array.from(this.devices.values()).filter(device => {
if (requirements.category && device.category !== requirements.category)
return false;
if (requirements.capability &&
!device.capabilities.includes(requirements.capability))
return false;
if (requirements.maxPower &&
device.constraints.powerWatts > requirements.maxPower)
return false;
return true;
});
}
// Generate UI controls based on device capabilities
getUIControls(deviceId) {
const device = this.devices.get(deviceId);
if (!device) return [];
return device.capabilities.map(cap => {
switch (cap) {
case 'on_off':
return { type: 'toggle', label: 'Power', ariaLabel: `${device.name} power` };
case 'brightness':
return { type: 'slider', label: 'Brightness', min: 0, max: 100, unit: '%' };
case 'temperature':
return { type: 'slider', label: 'Temperature', min: 16, max: 30, unit: '°C' };
case 'color':
return { type: 'colorpicker', label: 'Color' };
default:
return { type: 'info', label: cap };
}
});
}
}
// Usage: Register devices from different categories
const registry = new DeviceRegistry();
registry.register({
id: 'bulb-001', name: 'Living Room Light',
category: 'consumer',
capabilities: ['on_off', 'brightness', 'color'],
constraints: { powerWatts: 9, protocol: 'zigbee', battery: false }
});
registry.register({
id: 'tracker-001', name: 'Fitness Band',
category: 'wearable',
capabilities: ['heart_rate', 'steps', 'sleep'],
constraints: { powerWatts: 0.01, protocol: 'ble', battery: true }
});
// Query: Find all battery-powered devices
const batteryDevices = registry.query({ maxPower: 0.1 });
// Returns: [{ id: 'tracker-001', ... }]
// Auto-generate appropriate UI for each device
const controls = registry.getUIControls('bulb-001');
// Returns: [{ type: 'toggle', ... }, { type: 'slider', ... }, ...]Why capability-based design matters:
| Approach | Problem | Better Approach |
|---|---|---|
| Hardcode UI per device model | New devices need app updates | Discover capabilities, generate UI dynamically |
| Assume all devices have displays | Wearables and sensors don’t | Query constraints before rendering |
| Same power management for all | Drains battery devices fast | Adapt polling rate based on power constraints |
Scenario: You’re designing an outdoor IoT soil moisture sensor for agriculture. It must last 5+ years in harsh conditions (temperature extremes, rain, UV exposure, dust). Farmers want: long battery life (replace battery once per season max), reliable connectivity (fields often have poor cellular), and accurate readings even when sensor buried in soil.
Think about:
Key Insight: Successful IoT device design requires strategic trade-offs: - Power vs Connectivity: LoRaWAN uses less power than cellular (2-year battery vs 2-month), but requires gateway infrastructure - Durability vs Cost: IP68 rating + UV-stabilized enclosure costs 3x more than IP54 basic plastic, but prevents field failures - Features vs Simplicity: Adding soil temperature + pH sensors is valuable, but increases power draw 40% and cost 60% - Design Triangle: You can optimize for TWO of: Features, Cost, Battery Life—not all three - Real-world example: A $200 sensor with 2-year battery and LoRa connectivity succeeds better than a $50 sensor with 3-month battery that requires constant maintenance visits.
Commissioning industrial design or tooling before the PCB layout is frozen means the enclosure must be redesigned when components move or heatsinks are added, costing 4-12 weeks of delay. Run electrical and mechanical design in parallel and freeze PCB dimensions before starting the production enclosure design.
Placing metallic enclosure elements or battery inside the antenna keep-out zone degrades RF performance by 3-10 dB, causing range reduction and regulatory test failures. Follow the antenna manufacturer’s reference design keep-out dimensions precisely and verify with return-loss measurement on the first prototype.
Components selected without thermal analysis may run outside their rated temperature range in closed enclosures, causing intermittent failures or shortened lifespan. Perform a simplified thermal resistance calculation early in design and prototype with a thermocouple to validate before finalising the enclosure.
This chapter covered the fundamentals of IoT connected devices:
Key Takeaways:
Device Categories: IoT devices span wearables, consumer products, industrial sensors, and infrastructure - each with unique constraints and requirements
Design Triangle: Every device balances three competing factors - Features, Cost, and Power/Battery Life. You can optimize for any two, but not all three
Category Selection: Choose device category based on application type, environment, power source, and connectivity requirements
Device Characteristics: Consider power source, connectivity, operating environment, form factor, and processing requirements when selecting or designing devices
Trade-offs: The best IoT devices make the right trade-offs for their specific use case, not trying to maximize everything simultaneously
Connected device fundamentals tie together multiple IoT system layers:
Understanding device fundamentals reveals how every IoT product involves simultaneous optimization across hardware, firmware, power, cost, and UX dimensions – there is no single “right” design, only designs optimized for specific use cases and constraints.
| Next | Chapter |
|---|---|
| Next Chapter | Form Factors and Enclosures |
| Related | Power Management |
| Related | Device Lifecycle Management |
Further Reading: