6 IoT Glossary: B-F

6.9.5 Beginner Example: Actuator, ADC, and DAC in a Greenhouse Prototype

Scenario: A student describes a greenhouse prototype as “the sensor opens the vent when temperature is high.”

Glossary lookup:

Sensor is not in this A-F section, but the related A-F terms clarify the boundary. ADC converts an analog thermistor voltage into a digital value that firmware can read. Actuator is the vent motor or servo that changes the physical world. DAC is only needed if the controller must output an analog voltage, not when it drives a digital relay or PWM-controlled servo.

Design choice: Rewrite the explanation as: “The temperature sensor is read through an ADC; firmware compares the digital value with the threshold; the controller drives an actuator to open the vent.” That wording separates measurement, computation, and physical action.

6.9.6 Intermediate Example: Glossary-Driven Troubleshooting of “At-least-once” Duplicate Messages

Scenario: Your MQTT sensor publishes temperature readings, but cloud dashboard shows occasional duplicates (same reading, same timestamp, received twice).

Glossary lookup (At-least-once):

“A message delivery guarantee where messages are delivered one or more times… potentially causing duplicates that receivers must handle.”

Aha moment: MQTT QoS 1 (at-least-once) is working correctly - duplicates are expected, not a bug!

Follow cross-reference: Idempotency:

“A property of operations where performing them multiple times produces the same result… enabling safe retries without unintended side effects.”

Solution: Add idempotency key to messages:

{
  "device_id": "sensor-001",
  "timestamp": "2026-02-15T10:30:00Z",
  "temperature": 23.5,
  "message_id": "a3b2c1"  // <-- Deduplication key
}

Dashboard code checks message_id - if already received, skip duplicate.

Key insight: The glossary’s cross-references led from “at-least-once” to “idempotency” to a practical deduplication fix. Understanding related concepts revealed the solution.

6.9.7 Advanced Example: BLE Cold-Room Gateway with Security and Delivery Boundaries

Scenario: A cold-room gateway reads BLE temperature sensors, filters noisy readings locally, and sends exceptions to a cloud service. The team says the system is “secure and reliable” because the gateway encrypts traffic.

Glossary lookup:

• BLE describes the short-range radio link from sensor to gateway, often through GATT services and characteristics.
• Edge Computing explains why filtering happens on the gateway before cloud upload.
• CoAP and DTLS may describe a constrained UDP path from gateway to cloud, while AMQP may describe a brokered enterprise path for exception handling.
• Authentication proves device or user identity; authorization, ACL, and firewall rules control allowed actions and network paths.
• At-least-once, dead letter queue, and circuit breaker describe what happens when delivery, processing, or downstream services fail.

Design choice: Replace the broad claim with specific boundaries: BLE readings are accepted only from enrolled device ids, noisy samples are filtered at the edge, gateway-to-cloud traffic uses DTLS with certificate validation, cloud APIs enforce authorization separately from authentication, firewall rules limit inbound paths, AMQP exceptions use idempotency keys, and a dead letter queue holds events that still fail processing.