7 IoT Glossary: Q-Z
Essential IoT Terms from QoS to 6LoWPAN
Putting Numbers to It
Reference usability can be estimated by lookup coverage:
\[ U = \frac{N_{\text{resolved-lookups}}}{N_{\text{total-lookups}}} \]
Worked example: If learners perform 220 glossary lookups and 198 are resolved without leaving the section, usability is \(198/220=90\%\). Improving cross-references and examples should push this ratio higher.
Navigation
This is Part 3 of the IoT Glossary, covering terms Q-Z. See also:
- IoT Glossary Index - Overview and quick navigation
- Glossary A-F - ACL through Frame
- Glossary G-P - Gateway through Publisher
7.1 Learning Objectives
After reviewing this section, you will be able to:
7.3 For Beginners: Using This Glossary
This glossary section covers essential IoT terms from Q to Z. Think of it as your personal IoT dictionary - when you encounter an unfamiliar term while learning about IoT systems, you can look it up here for a clear definition, simple explanation, and links to related concepts. Each entry includes common confusions to help you avoid typical misunderstandings. Use the worked examples at the end to see how these terms connect in real IoT projects.
- Define key IoT terms from Q to Z with technical precision
- Evaluate quality of service levels and their trade-offs for different IoT scenarios
- Differentiate wireless protocols (Zigbee, Z-Wave, Thread, Matter) by topology, power, and data rate
- Select appropriate database technologies for time-series IoT data based on query patterns
7.4 Q
7.4.1 QoS (Quality of Service)
Definition: A set of mechanisms that control and guarantee network resources and delivery characteristics, particularly message delivery guarantees (at-most-once, at-least-once, exactly-once).
In simple terms: Delivery guarantees - like choosing between regular mail, tracked delivery, or registered mail depending on how important your package is and how sure you need to be it arrives.
Common confusions:
- MQTT QoS (0, 1, 2) refers to message delivery, not network performance
- Higher QoS means more overhead and latency
Related terms: At-most-once, At-least-once, Exactly-once, Acknowledgment
Synonyms: delivery quality, service level
7.5 R
7.5.1 REST (Representational State Transfer)
Definition: An architectural style for web services using HTTP methods (GET, POST, PUT, DELETE) to perform CRUD operations on resources, emphasizing stateless communication and uniform interfaces.
In simple terms: Web API design principles - a common way to build APIs where URLs represent things (resources) and HTTP methods represent actions (get, create, update, delete).
Common confusions:
- REST vs. RESTful - REST is the style, RESTful describes APIs following REST principles
- Not all HTTP APIs are RESTful (many only use POST)
Related terms: API, HTTP, Microservices
Synonyms: REST API, RESTful API
7.5.2 Retry
Definition: The practice of automatically re-attempting a failed operation, typically with backoff strategies and maximum attempt limits to handle transient failures gracefully.
In simple terms: “Try again” - when something fails, automatically attempt it again (perhaps after waiting) because many failures are temporary and succeed on retry.
Common confusions:
- Retries without backoff can overwhelm systems (thundering herd)
- Not all operations should be retried (only transient failures)
Related terms: Backoff, Idempotency, Circuit Breaker
Synonyms: retry mechanism, automatic retry
7.5.3 Routing
Definition: The process of selecting paths in a network for traffic to flow, using algorithms and routing tables to determine the best path for data to reach its destination.
In simple terms: Finding the best route - like a GPS navigating traffic, routers determine the best path for data to travel from source to destination through the network.
Common confusions:
- Routing vs. switching - routing works between networks (Layer 3), switching works within networks (Layer 2)
- Static vs. dynamic routing have different use cases
Related terms: Mesh, Gateway, Packet
Synonyms: packet routing, path selection
7.6 S
7.6.1 Sampling
Definition: The process of converting continuous signals into discrete values at regular intervals, with sampling rate determining how often measurements are taken.
In simple terms: Taking periodic snapshots - instead of continuous recording, take measurements at regular intervals, like checking temperature every minute instead of watching a thermometer constantly.
Common confusions:
- Sampling rate must be at least 2x highest frequency (Nyquist theorem)
- Higher sampling rates produce more data but may not add value
Related terms: ADC, Time Series, Aggregation
Synonyms: data sampling, signal sampling
7.6.2 Schema
Definition: A formal description of data structure defining field names, types, constraints, and relationships, used to validate data and ensure consistency across systems.
In simple terms: A data template - specifies what fields data should have and what types they should be, like a form that defines required fields and their formats.
Common confusions:
- Schema-on-write vs. schema-on-read have different flexibility/reliability tradeoffs
- Schema evolution must be managed carefully to maintain compatibility
Related terms: JSON, Protobuf, Serialization
Synonyms: data schema, data model
7.6.3 Sensor
Definition: A device that detects and measures physical properties (temperature, light, motion, pressure) and converts them into electrical signals that can be processed by electronic systems.
In simple terms: The eyes and ears of IoT - devices that measure the real world and report what they sense, like a thermometer that tells a computer what the temperature is.
Common confusions:
- Sensor vs. transducer - sensors measure, transducers convert energy forms (sensors are a type of transducer)
- Sensor accuracy vs. precision are different characteristics
Related terms: Actuator, ADC, Telemetry
Synonyms: detector, transducer
7.6.4 Serialization
Definition: The process of converting data structures or objects into a format suitable for storage or transmission, enabling reconstruction of the original structure later (deserialization).
In simple terms: Packing for shipment - converting complex data into a flat format that can be sent over a network or saved to disk, then unpacking it at the destination.
Common confusions:
- Serialization format affects size, speed, and compatibility (JSON vs. CBOR vs. Protobuf)
- Deserialization must handle malformed or malicious data safely
Related terms: JSON, CBOR, Protobuf, Payload
Synonyms: marshalling, encoding
7.6.5 Serverless
Definition: A cloud computing execution model where the cloud provider dynamically manages server allocation, charging only for actual execution time, abstracting infrastructure management.
In simple terms: Computing without managing servers - write code that runs when needed without worrying about servers, scaling, or paying for idle time, like renting a taxi versus owning a car.
Common confusions:
- Serverless still uses servers, you just don’t manage them
- Cold start latency can affect time-sensitive applications
Related terms: Cloud, Microservices, Platform
Synonyms: Function as a Service (FaaS), Lambda
7.6.6 Sigfox
Definition: A proprietary LPWAN technology using ultra-narrowband modulation for very low-power, low-throughput IoT communication, operating a global network with subscription-based service.
In simple terms: A global IoT cell network - like a phone network just for simple sensors, covering the world with one subscription for devices that only send tiny amounts of data.
Common confusions:
- Sigfox is network-as-a-service (you don’t deploy your own infrastructure)
- Very limited message size (12 bytes) and daily message count (140)
Related terms: LPWAN, LoRaWAN, NB-IoT
Synonyms: none common
7.6.7 SoC (System on Chip)
Definition: An integrated circuit that combines a processor, memory, I/O interfaces, and often wireless connectivity into a single chip, providing complete computing functionality for embedded systems.
In simple terms: An entire computer on one chip - everything from the processor to Wi-Fi radio combined into a single piece of silicon, making it easy to build small, integrated devices.
Common confusions:
- SoC vs. microcontroller - SoCs typically include more features like wireless, microcontrollers are simpler
- Examples: ESP32, Nordic nRF52, Raspberry Pi RP2040
Related terms: Microcontroller, GPIO
Synonyms: System on a Chip, integrated SoC
7.6.8 SPI (Serial Peripheral Interface)
Definition: A synchronous serial communication interface using four wires (clock, data in, data out, select) for high-speed communication between a microcontroller and peripheral devices.
In simple terms: Fast wired communication - uses more wires than I2C but is faster, good for sensors and displays that need to transfer lots of data quickly.
Common confusions:
- SPI vs. I2C - SPI is faster but needs more wires and individual select lines per device
- SPI has multiple modes (CPOL/CPHA) that must match between devices
Related terms: I2C, UART, GPIO
Synonyms: four-wire serial bus
7.6.9 Star Topology
Definition: A network topology where all devices connect to a central hub or coordinator, with all communication flowing through this central point rather than directly between devices.
In simple terms: Hub-and-spoke design - every device connects to one central point, like streets radiating from a town center. Simple but the center is a single point of failure.
Common confusions:
- Star vs. mesh - star is simpler but less resilient, mesh has redundant paths
- Wi-Fi networks typically use star topology with the access point as center
Related terms: Mesh, Routing, Gateway
Synonyms: hub topology, centralized topology
7.6.10 Subscriber
Definition: A client in publish-subscribe messaging that registers interest in specific topics and receives messages published to those topics, without direct connection to publishers.
In simple terms: A listener - signs up to receive certain types of messages from the system, like subscribing to a newsletter to receive updates on topics you care about.
Common confusions:
- Subscriber vs. consumer - essentially the same concept
- Subscribers are decoupled from publishers (don’t know who’s sending)
Related terms: Publisher, Topic, Subscription, Broker
Synonyms: consumer, receiver, listener
7.6.11 Subscription
Definition: A registration with a message broker expressing interest in receiving messages matching certain criteria (typically topic patterns), maintained until explicitly cancelled.
In simple terms: A standing order for messages - tell the broker “send me anything about topic X” and you’ll receive matching messages until you unsubscribe.
Common confusions:
- Subscription vs. topic - subscription is the registration, topic is what you subscribe to
- Durable vs. non-durable subscriptions persist (or not) across disconnections
Related terms: Topic, Subscriber, Filter, Wildcard
Synonyms: topic subscription
7.7 T
7.7.1 Telemetry
Definition: The automated collection and transmission of measurements from remote devices to receiving equipment for monitoring, including sensor readings, status information, and performance metrics.
In simple terms: Remote sensing data - the continuous stream of measurements sent from devices in the field back to a central system, like vital signs monitors sending patient data to nurses’ stations.
Common confusions:
- Telemetry vs. commands - telemetry flows from devices, commands flow to devices
- Telemetry vs. logs - telemetry is structured measurements, logs are event records
Related terms: Sensor, Time Series, MQTT
Synonyms: device telemetry, sensor data, metrics
7.7.2 Thread
Definition: An IPv6-based mesh networking protocol designed for smart home devices, providing secure, reliable, low-power communication with no single point of failure.
In simple terms: Modern smart home mesh - a secure, reliable way for home devices to communicate in a mesh network, specifically designed to work with IPv6 and the Matter standard.
Common confusions:
- Thread vs. Zigbee - Thread uses IP, Zigbee has its own network layer
- Thread is a transport for Matter (they work together)
Related terms: Matter, Mesh, 6LoWPAN, Zigbee
Synonyms: Thread Group protocol
7.7.3 Throughput
Definition: The actual rate at which data is successfully transferred over a network connection, typically lower than bandwidth due to protocol overhead, errors, and congestion.
In simple terms: Real-world speed - while bandwidth is the maximum theoretical capacity, throughput is how fast data actually moves in practice, accounting for all the overhead and delays.
Common confusions:
- Throughput vs. bandwidth - throughput is achieved rate, bandwidth is capacity
- Throughput varies based on conditions, bandwidth is a fixed characteristic
Related terms: Bandwidth, Latency
Synonyms: actual speed, effective bandwidth
7.7.4 Time Series
Definition: A sequence of data points indexed by time, commonly used in IoT for recording sensor measurements, metrics, and events with timestamps for temporal analysis.
In simple terms: Data ordered by time - measurements collected over time, like temperature readings every minute, stored in time order so you can see trends and patterns.
Common confusions:
- Time series databases are optimized differently than relational databases
- Time series data often requires special handling for gaps and irregular intervals
Related terms: TSDB, Telemetry, Timestamp, Aggregation
Synonyms: temporal data, time-stamped data
7.7.5 TimescaleDB
Definition: An open-source time series database built on PostgreSQL, combining full SQL support with time series optimizations for IoT, monitoring, and analytics workloads.
In simple terms: SQL-friendly time series database - handles sensor data efficiently while letting you use familiar SQL queries and benefiting from PostgreSQL’s ecosystem.
Common confusions:
- TimescaleDB vs. InfluxDB - TimescaleDB uses SQL, InfluxDB has its own query languages
- TimescaleDB is an extension to PostgreSQL, not a standalone database
Related terms: TSDB, InfluxDB, Time Series
Synonyms: none common
7.7.6 Timestamp
Definition: A recorded point in time associated with data, typically expressed in a standardized format like Unix epoch time or ISO 8601, essential for ordering and correlating events.
In simple terms: A date-time stamp - marks when something happened, like the postmark on a letter, essential for knowing when sensor readings were taken.
Common confusions:
- Timestamp precision matters (seconds vs. milliseconds vs. microseconds)
- Timezone handling is crucial for distributed systems
Related terms: Time Series, Metadata, Telemetry
Synonyms: datetime, epoch time
7.7.7 TLS (Transport Layer Security)
Definition: A cryptographic protocol providing secure communication over networks through encryption, authentication, and integrity verification, the successor to SSL.
In simple terms: The “S” in HTTPS - encrypts data in transit so eavesdroppers can’t read it, verifies server identity, and ensures data hasn’t been tampered with.
Common confusions:
- TLS vs. SSL - TLS is the modern successor, SSL is deprecated
- TLS works with TCP, use DTLS for UDP
Related terms: DTLS, HTTPS, Certificate, Encryption
Synonyms: SSL/TLS, secure sockets
7.7.8 Token
Definition: A digital credential used for authentication or authorization, typically a string containing encoded information about identity and permissions with expiration time.
In simple terms: A digital key card - proves who you are and what you’re allowed to do, like a badge that gets you through certain doors for a limited time.
Common confusions:
- Access tokens vs. refresh tokens serve different purposes
- JWT (JSON Web Token) is one common token format
Related terms: Authentication, OAuth, Authorization
Synonyms: access token, bearer token, JWT
7.7.9 Topic
Definition: A named channel or subject in publish-subscribe messaging systems that publishers send messages to and subscribers receive messages from, enabling message routing.
In simple terms: A message address or category - like a TV channel number, publishers broadcast to a topic and anyone tuned to that topic receives the messages.
Common confusions:
- Topic hierarchy (sensors/temperature/room1) enables organized message routing
- Topics are usually strings, not queues (messages aren’t stored by default)
Related terms: Publisher, Subscriber, Subscription, MQTT
Synonyms: channel, subject, message topic
7.7.10 TSDB (Time Series Database)
Definition: A database optimized for storing, querying, and analyzing time-stamped data, featuring efficient compression, time-based indexing, and specialized query functions.
In simple terms: A database built for sensor data - specifically designed to handle millions of time-stamped measurements efficiently, with features like automatic data aging and time-based queries.
Common confusions:
- TSDB vs. relational database - TSDBs optimize for time-based writes and queries
- Examples: InfluxDB, TimescaleDB, Prometheus, QuestDB
Related terms: Time Series, InfluxDB, TimescaleDB
Synonyms: time series database
7.8 U
7.8.1 UART (Universal Asynchronous Receiver/Transmitter)
Definition: A hardware communication protocol for asynchronous serial communication between devices, using two wires (TX and RX) without requiring a shared clock signal.
In simple terms: Basic serial communication - the simplest way for two devices to talk to each other over wires, like an old-fashioned telegraph system for digital data.
Common confusions:
- UART vs. I2C/SPI - UART is point-to-point and asynchronous, I2C/SPI support multiple devices
- Baud rate must match between sender and receiver
Synonyms: serial port, RS-232 (related standard)
7.9 W
7.9.1 WebSocket
Definition: A protocol providing full-duplex communication channels over a single TCP connection, enabling real-time bidirectional data exchange between web clients and servers.
In simple terms: A two-way communication line - unlike HTTP where clients must keep asking for updates, WebSocket keeps a connection open so servers can push data instantly.
Common confusions:
- WebSocket vs. HTTP - WebSocket is persistent and bidirectional, HTTP is request-response
- WebSocket starts with HTTP upgrade, then switches protocol
Related terms: HTTP, MQTT, Real-time
Synonyms: WS, WSS (secure WebSocket)
7.9.2 Wi-Fi
Definition: A family of wireless networking protocols based on IEEE 802.11 standards, providing local area network connectivity using radio frequencies in 2.4 GHz and 5 GHz bands.
In simple terms: Wireless internet - the most common way to connect devices to a network without cables, using radio waves to link devices to a router or access point.
Common confusions:
- Wi-Fi vs. internet - Wi-Fi is the local connection, internet is what you access through it
- Wi-Fi generations (4/5/6/6E/7) have different speeds and capabilities
Related terms: BLE, Zigbee, Bandwidth
Synonyms: Wi-Fi, 802.11, WLAN
7.9.3 Wildcard
Definition: A special character in topic patterns that matches multiple topic levels, enabling subscribers to receive messages from multiple topics with a single subscription.
In simple terms: A pattern matcher - like using “*” to find all files in a folder, wildcards let you subscribe to groups of related topics at once.
Common confusions:
- MQTT uses + (single level) and # (multi-level) wildcards
- Different protocols have different wildcard syntax
Related terms: Topic, Subscription, Filter
Synonyms: topic wildcard, pattern matching
7.10 Z
7.10.1 Zigbee
Definition: A wireless mesh networking protocol based on IEEE 802.15.4 for low-power, low-data-rate applications, widely used in home automation and industrial control.
In simple terms: A mesh network for smart homes - devices form a web of connections where messages hop from device to device, creating reliable coverage throughout your home.
Common confusions:
- Zigbee vs. Z-Wave - different protocols, incompatible, both used for home automation
- Zigbee vs. Thread - Zigbee has its own network layer, Thread uses IPv6
Related terms: Z-Wave, Mesh, Thread, Matter
Synonyms: Zigbee, IEEE 802.15.4
7.10.2 Z-Wave
Definition: A proprietary wireless mesh networking protocol operating in sub-GHz frequencies, designed for smart home automation with low interference and excellent building penetration.
In simple terms: Another smart home mesh - similar purpose to Zigbee but uses different radio frequencies that pass through walls better, with strictly controlled certification.
Common confusions:
- Z-Wave vs. Zigbee - incompatible protocols, Z-Wave uses sub-GHz, Zigbee uses 2.4 GHz
- Z-Wave is proprietary with mandatory certification, Zigbee is more open
Related terms: Zigbee, Mesh, Matter
Synonyms: none common
7.10.3 6LoWPAN
Definition: IPv6 over Low-Power Wireless Personal Area Networks, an adaptation layer enabling IPv6 packets to be transmitted over IEEE 802.15.4 networks through header compression and fragmentation.
In simple terms: Shrinking IPv6 for tiny devices - makes full internet protocol (IPv6) work on constrained networks by compressing headers and splitting large packets.
Common confusions:
- 6LoWPAN is an adaptation layer, not a complete protocol stack
- Used by Thread and often paired with CoAP
Related terms: CoAP, Thread, MTU
Synonyms: IPv6 over LoWPAN
7.11 Additional Reference Terms
7.11.1 Cellular IoT
Definition: IoT connectivity using cellular networks (LTE-M, NB-IoT, 5G), leveraging existing mobile infrastructure for wide-area coverage and managed connectivity services.
In simple terms: Using cell phone networks for IoT - connecting devices through the same towers your phone uses, providing coverage almost anywhere without deploying your own network.
Common confusions:
- Cellular IoT includes multiple technologies (NB-IoT, LTE-M, 5G mMTC)
- Requires carrier subscription and SIM/eSIM
Related terms: NB-IoT, LTE-M, LPWAN
Synonyms: mobile IoT, cellular M2M
7.11.2 IIoT (Industrial IoT)
Definition: Application of IoT technologies in industrial settings for manufacturing, energy, transportation, and other industrial processes, emphasizing reliability, safety, and interoperability.
In simple terms: IoT for factories and industry - connecting machines, sensors, and systems in industrial environments to improve efficiency, safety, and maintenance.
Common confusions:
- IIoT vs. Industry 4.0 - IIoT is the connectivity, Industry 4.0 is the broader transformation
- IIoT has stricter requirements for reliability and safety than consumer IoT
Related terms: OPC-UA, Modbus, Digital Twin
Synonyms: Industrial Internet of Things, Industry 4.0 IoT
7.11.3 Real-time
Definition: System responses occurring within guaranteed time constraints, where data is processed and delivered with minimal delay to enable immediate action or feedback.
In simple terms: Instant response - systems that react immediately, like brake lights that come on the moment you press the pedal, not seconds later.
Common confusions:
- Real-time doesn’t mean “fast” - it means “predictably within time constraints”
- Hard real-time vs. soft real-time have different tolerance for delays
Related terms: Latency, DDS, WebSocket
Synonyms: real-time systems, low-latency
7.11.4 Frequency
Definition: The rate at which a periodic signal oscillates, measured in Hertz (Hz), determining radio band allocation for wireless communication and signal characteristics.
In simple terms: How fast waves wiggle - measured in cycles per second, different frequencies are used for different purposes (2.4 GHz Wi-Fi, 915 MHz LoRa, etc.).
Common confusions:
- Higher frequency generally means more bandwidth but less range/penetration
- Different regions use different frequency bands (regulatory)
Related terms: Channel, Bandwidth, Wi-Fi
Synonyms: radio frequency, Hz
Common Pitfalls
1. Confusing QoS 1 ‘at least once’ with ‘exactly once’
MQTT QoS 1 guarantees delivery but allows duplicate messages. If a sensor reading is published with QoS 1 and the broker acknowledgment is lost, the device retransmits, causing the subscriber to receive the same reading twice. For actuator commands where duplicates could cause repeated actions, use QoS 2 (exactly once) or implement idempotency at the application layer.
2. Using Zigbee and Wi-Fi simultaneously without interference management
Zigbee uses the 2.4 GHz ISM band, overlapping with Wi-Fi channels 1-11. Running Zigbee channel 11 (2.462 GHz) alongside a Wi-Fi router on channel 6 (2.437 GHz) causes interference that drops Zigbee packet delivery rates by 50-90%. Configure Zigbee to use channels 25 or 26 (above Wi-Fi channel 11) or use Z-Wave (sub-GHz, no Wi-Fi interference) for critical home automation devices.
3. Selecting an RTOS without considering the memory footprint
FreeRTOS requires 5-10 KB RAM for the kernel alone, plus stack space for each task (typically 1-4 KB per task). An 8-task FreeRTOS system on an MCU with 16 KB RAM leaves almost no memory for application data and sensor buffers. Profile memory requirements before selecting an RTOS – simpler bare-metal interrupt-driven designs are more appropriate for microcontrollers with less than 32 KB RAM.
7.12 Summary
This section covered 35 essential IoT terms from Q through Z plus additional reference terms:
| Category | Terms | Examples |
|---|---|---|
| Wireless Protocols | 7 | Sigfox, Thread, Wi-Fi, Zigbee, Z-Wave, 6LoWPAN |
| Messaging | 6 | QoS, Subscriber, Subscription, Topic, Wildcard |
| Data/Databases | 6 | Sampling, Schema, Serialization, Time Series, TimescaleDB, TSDB |
| Security | 3 | TLS, Token |
| Hardware | 4 | SoC, SPI, UART |
| Networking | 5 | REST, Retry, Routing, Star Topology, Throughput, WebSocket |
| Architecture | 3 | Sensor, Serverless, Telemetry |
| Reference | 4 | Cellular IoT, IIoT, Real-time, Frequency |
Worked Example: Selecting QoS Levels for a Multi-Sensor IoT System
You’re designing an industrial monitoring system with 50 sensors transmitting via MQTT. Here’s how to choose appropriate QoS levels for different message types using glossary definitions.
System Overview:
- 30× temperature sensors (1-minute intervals)
- 15× vibration sensors (10-second intervals, equipment health)
- 5× emergency stop buttons (immediate alerts)
Step 1: Temperature Telemetry
- Data characteristics: 43,200 readings/day per sensor (1,296,000 total), redundant data
- Glossary lookup: QoS level 0 = At-most-once delivery (fire-and-forget)
- Analysis: Losing 1 reading from 1,440/day per sensor = 0.07% data loss, acceptable for trending
- Decision: QoS 0 (lowest overhead)
- Power impact: 1 MQTT message per transmission (vs QoS 1: 2 messages, QoS 2: 4 messages)
- Battery life extension: Using QoS 0 extends battery from 3.2 years → 5.1 years (59% improvement)
Step 2: Vibration Monitoring
- Data characteristics: Critical for predictive maintenance, detects bearing failures
- Glossary lookup: QoS level 1 = At-least-once delivery (acknowledged)
- Analysis: Missing a high-vibration event could delay maintenance → $15,000 unplanned downtime
- Concern from glossary “Common confusions”: QoS 1 can deliver duplicates
- Implementation: Tag each reading with Timestamp + sequence number
- Backend deduplication: Use Idempotency checks (discard duplicate timestamps)
- Decision: QoS 1 (guaranteed delivery with deduplication)
- Network overhead: 2× messages vs QoS 0, but critical for equipment health
Step 3: Emergency Stop Buttons
- Data characteristics: Life-safety commands, must execute exactly once
- Glossary lookup: QoS level 2 = Exactly-once delivery (four-way handshake)
- Analysis: Duplicate emergency stop = restart interrupted process (unsafe), missed stop = catastrophic
- Protocol flow from glossary:
- PUBLISH (client → broker)
- PUBREC (broker → client, “received”)
- PUBREL (client → broker, “release”)
- PUBCOMP (broker → client, “complete”)
- Decision: QoS 2 (only for critical commands)
- Latency impact: 4× round-trip time (RTT), acceptable for emergency (occurs <1% of time)
Step 4: Gateway Heartbeats
- Data characteristics: Gateway online/offline status, every 60 seconds
- Glossary lookup: Telemetry health monitoring
- Analysis: If heartbeat is lost, next heartbeat arrives in 60s (acceptable detection delay)
- Decision: QoS 0 (redundant pings, fire-and-forget)
Resulting MQTT Configuration Table
| Message Type | QoS | Rationale | Overhead | Annual Energy Cost |
|---|---|---|---|---|
| Temperature telemetry | 0 | Redundant data, 1,440 readings/day | 1× | 0.8 kWh/sensor |
| Vibration data | 1 | Critical alerts, deduplication via timestamp | 2× | 3.6 kWh/sensor |
| E-stop commands | 2 | Life-safety, exactly-once required | 4× | 0.02 kWh/year (rare) |
| Gateway heartbeats | 0 | Status pings, 60s redundancy | 1× | 0.1 kWh/gateway |
Energy Impact Analysis
If we incorrectly used QoS 2 for temperature telemetry:
- Current (QoS 0): 1,296,000 messages/day × 1 transmission = 1.30M transmissions
- Incorrect (QoS 2): 1,296,000 messages/day × 4 transmissions = 5.18M transmissions (4× power)
- Battery life: 5.1 years → 1.3 years (75% reduction)
- Annual battery replacement cost: 30 sensors × $8 × 3 extra changes = $720 wasted
Key Lesson: Match QoS level to message criticality. The glossary’s “Common confusions” section for QoS emphasizes: “Higher QoS means more overhead and latency” - reserve QoS 2 only for irreplaceable commands.
7.12.1 Interactive QoS Impact Calculator
Experiment with different QoS levels to see their impact on battery life and network overhead:
Decision Framework: Wireless Protocol Selection Using Glossary Terms
Use this framework to systematically choose between Wi-Fi, Zigbee, Thread, BLE, LoRaWAN, and Cellular IoT.
7.12.2 Decision Criteria Table
| Requirement | If This Applies | Consider | Glossary Terms to Review |
|---|---|---|---|
| Range < 10 meters | Wearables, room sensors | BLE | Bluetooth, BLE |
| Range 10-100 meters | Home/office automation | Zigbee, Thread, Wi-Fi | Mesh, Star Topology |
| Range 1-15 km | Campus, farm, industrial site | LoRaWAN, Sigfox | LPWAN |
| Range > 15 km | City-wide, nationwide | NB-IoT, LTE-M | Cellular IoT |
| Battery life > 5 years | Infrequent reporting | LoRaWAN, Sigfox, NB-IoT | LPWAN, Duty Cycle |
| Throughput > 1 Mbps | Video, audio streaming | Wi-Fi | Bandwidth, Throughput |
| Latency < 100 ms | Real-time control | Wi-Fi, Thread | Latency, Real-time |
| Mesh networking required | Redundant paths, no single point of failure | Zigbee, Thread | Mesh, Routing |
| IP connectivity required | Directly addressable devices | Wi-Fi, Thread, 6LoWPAN | IPv6, Gateway |
| No infrastructure | Deploy in remote areas | LoRaWAN (own gateway), avoid NB-IoT (needs carrier) | LPWAN |
7.12.3 Comparative Analysis Example
Scenario: Smart building with 200 occupancy sensors, 50-meter coverage, 10-year deployment
| Protocol | Range | Battery Life | Data Rate | Mesh? | Verdict |
|---|---|---|---|---|---|
| Wi-Fi | 50m | 6 months | 54 Mbps | No | ❌ Battery too short |
| BLE | 10m | 2 years | 1 Mbps | No | ❌ Range insufficient |
| Zigbee | 100m | 5 years | 250 kbps | Yes | ✅ Best fit |
| Thread | 100m | 5 years | 250 kbps | Yes | ✅ Alternative (IPv6 benefit) |
| LoRaWAN | 5 km | 10 years | 50 kbps | No | ❌ Overkill for 50m, higher cost |
Decision: Zigbee or Thread
7.12.4 Common Confusion Resolution
Question: “Should I use Zigbee or Z-Wave?”
From glossary “Common confusions” sections:
- Zigbee: 2.4 GHz (global frequency), 250 kbps, 65,000 nodes
- Z-Wave: Sub-GHz (regional frequencies), 100 kbps, 232 nodes, proprietary
Decision factors:
- Building penetration: Z-Wave (868/915 MHz) penetrates walls better than Zigbee (2.4 GHz)
- Wi-Fi interference: Z-Wave avoids 2.4 GHz congestion
- Scale: Zigbee for >100 devices, Z-Wave for <100
- Global deployment: Zigbee (single frequency), Z-Wave requires region-specific modules
Rule of thumb: Residential <100 devices + Wi-Fi interference + good wall penetration → Z-Wave. Commercial >100 devices + global deployment → Zigbee.
Common Mistake: Misunderstanding Time Series Database Requirements
The Problem: Students often say “I’ll use InfluxDB” or “I’ll use TimescaleDB” without understanding when a TSDB is actually needed.
Real Project Example:
A team stored 3 temperature sensors (1-minute sampling) in a MySQL database using:
CREATE TABLE readings (
sensor_id INT,
value FLOAT,
timestamp DATETIME,
PRIMARY KEY (sensor_id, timestamp)
);After 6 months, queries like “average temperature per hour for the last week” took 45 seconds. With 12 million rows, the database consumed 2.1 GB.
Why This Failed:
- Wrong index structure: MySQL’s B-tree index is optimized for exact lookups, not time-range queries
- No automatic downsampling: All raw data kept forever (12M rows), should aggregate old data (1-minute → 1-hour → 1-day)
- Poor compression: FLOAT values stored uncompressed (8 bytes each), TSDBs compress by 90% using delta-of-delta encoding
How to Decide: Do You Need a TSDB?
Use this decision tree:
Do you have time-stamped data?
└─> NO: Use PostgreSQL, MongoDB, etc.
└─> YES: Continue...
├─> <10,000 readings/day
│ └─> Use PostgreSQL with timestamp index (adequate performance)
├─> 10,000-1M readings/day
│ └─> Consider [TSDB](glossary-q-z.html#term-tsdb) ([TimescaleDB](glossary-q-z.html#term-timescaledb) for SQL familiarity, [InfluxDB](glossary-g-p.html#term-influxdb) for IoT-native)
└─> >1M readings/day
└─> TSDB required ([InfluxDB](glossary-g-p.html#term-influxdb), Prometheus, QuestDB)Corrected Design Using TSDB:
Option 1: TimescaleDB (if team knows SQL)
- Glossary: TimescaleDB = PostgreSQL extension for Time Series
- Advantages: Familiar SQL syntax, use existing PostgreSQL knowledge
- Automatic chunking: Partitions data by time (1-week chunks)
- Continuous aggregates: Pre-compute hourly/daily averages in background
- Compression: 10× reduction using columnar storage + delta encoding
Option 2: InfluxDB (purpose-built for IoT)
- Glossary: InfluxDB = Native TSDB with custom query language (Flux)
- Advantages: Optimized Telemetry ingestion (1M+ writes/sec), built-in downsampling
- Tagging system: Store sensor metadata (location, type) as tags, not separate tables
- Retention policies: Auto-delete old data (keep 7 days raw, 90 days hourly, 2 years daily)
Performance Comparison:
| Database | 6-month Dataset Size | “Last week hourly average” Query Time |
|---|---|---|
| MySQL (original) | 2.1 GB | 45 seconds |
| TimescaleDB (compressed) | 184 MB | 1.2 seconds |
| InfluxDB (with downsampling) | 94 MB | 0.3 seconds |
When NOT to Use a TSDB:
- Event logs: Use Elasticsearch (full-text search), not InfluxDB
- Transactional data: Use PostgreSQL (ACID guarantees), not TimescaleDB
- Small datasets: <100,000 points total → PostgreSQL with timestamp index is simpler
- Complex joins: Need to join with user tables, product catalogs → PostgreSQL
Key Lesson from Glossary: Review TSDB “Common confusions”: “TSDB vs. relational database - TSDBs optimize for time-based writes and queries.” Match database to query pattern, not just data type.
7.13 Concept Relationships
How These Terms Interconnect
Quality of Service Ecosystem:
- QoS → At-least-once, At-most-once, Exactly-once → Idempotency → Retry logic
- This chain shows how delivery guarantees require specific design patterns
Wireless Protocol Hierarchy:
- Physical layer: Wi-Fi, BLE, LoRa (radio modulation)
- Network layer: Zigbee, Thread, 6LoWPAN (routing, addressing)
- Application layer: MQTT, CoAP, HTTP (data exchange patterns)
Database Decision Tree:
- Time Series data → TSDB required
- TSDB options: InfluxDB (purpose-built) vs TimescaleDB (SQL-based)
- Schema determines query patterns and storage efficiency
Security Stack:
- TLS (transport encryption) + Token (authentication) + ACL (authorization) = Secure IoT
7.14 See Also
Related Resources
Within This Module:
- Glossary Index - Navigate to other glossary sections for related terms
- Glossary A-F - Foundation terms (Authentication, CoAP, Edge Computing)
- Glossary G-P - Networking and hardware terms (MQTT, Gateway, LoRaWAN)
Deep Dives (Cross-Module):
- MQTT QoS Levels - Practical implementation of QoS 0, 1, 2
- Zigbee vs Thread Comparison - When to use each mesh protocol
- Time Series Database Selection - InfluxDB vs TimescaleDB vs QuestDB benchmarks
Hands-On Practice:
- TSDB Query Lab - Practice InfluxDB and TimescaleDB queries
- Wi-Fi vs Zigbee Range Calculator - Compare wireless protocol coverage
7.15 What’s Next
| If you want to… | Read this |
|---|---|
| Look up IoT terms from A through F | Glossary A-F |
| Look up IoT terms from G through P | Glossary G-P |
| Review the complete unified glossary | Full IoT Glossary |
| Apply security concepts (TLS, QoS) in capstone projects | Capstone Projects |
| Deep dive into time-series database concepts | Time-Series Fundamentals |