31 Anatomy of a Connected Device
31.1 Start Simple
Imagine a door sensor that shows “closed” on a phone. That simple claim depends on the switch, board, power source, wireless link, service, app, and the person who repairs it. A fault in any one part can make the same screen wrong.
Start with one product promise. Draw the device boundary and the outside services it needs. Name who senses, stores, sends, decides, acts, and supports. Then test a low battery, a lost link, stale data, a restart, and an update that does not finish.
Keep local and remote state visible. Record the age and source of the value. A connected device is not just hardware with a radio. A working app does not prove that the physical state is current, and a cloud reply does not prove that the device can recover safely.
Go deeper in two steps. The Practitioner section applies a Device Hard-Constraint Review. Under the Hood examines trust across device state and outside services.
Start with the physical job. State what the product senses or changes. Name the person, room, machine, or animal affected. Add the safe result when power or data is gone. This keeps the screen tied to the real world.
Draw the product edge. Put the case, sensor, control part, board, memory, radio, power source, button, light, and port inside or outside it. Mark every wire and wireless path that crosses the edge. Each crossing adds a need for trust and support.
Give the device one or more roles. It may sense, act, show, store, relay, or guard. State which role is first. State which roles must still work offline. A gateway and a small end device may share a radio but need very different proof.
Trace one state. Begin at the physical event. Follow the sensor, local code, message, service, app, and human action. Keep source and time with the state. Mark any step that can change, drop, or hold it.
Test local feedback. A person near the product should know if it has power, is ready, is offline, needs setup, has rejected a command, or is in a safe fault state. Do not make a phone screen the only clue for a product that must be fixed on site.
Check power as part of the role. Measure start, sense, act, send, receive, wait, sleep, and update. Add peak current and reserve. Test a weak source. A device that resets during its main action cannot meet the promise shown by its average use.
Check identity and setup. Give each unit a stable record. State who may add it, own it, share it, reset it, and remove it. Test a second owner and an old owner. A factory label alone does not prove who controls the live product.
Check the link and service. Lose the network. Delay a reply. Send the same command twice. Restart both ends. Fill local storage. Mark state as stale when proof is old. Keep local safe work alive when the outside service is gone.
Check updates. State who signs and sends them. Keep power and space limits. Test a cut during the update. Prove the old or safe build can return. Record the build on the asset. An update path is part of the product, not an extra tool.
Check support. Ask how a person finds the last good state, fault, link, build, and battery clue. Name the team for each kind of fault. Keep logs useful but small and safe. A product is not ready when only its maker can guess what failed.
Check the full life. Plan install, normal use, share, repair, sale, reset, and final removal. Clear old trust and personal data. Keep required service records. A connected product can outlive the phone, network, account, or firm that first served it.
End with a bounded claim. Name the device, role, site, user, service, fault tests, build, and support owner. Add the changes that force a retest. New hardware, power, code, network, service, user, or place can all change the result.
Every connected device is both a physical object and a service endpoint. Start by naming what it senses or controls, how it gets power and connectivity, what local feedback it gives, what data leaves it, and which maintenance or security decision would change the experience.
31.2 In 60 Seconds
A connected device is the physical part of an IoT system that senses, acts, displays, stores, relays, or controls information at the edge of the physical world. It is not only a circuit board. It has a physical boundary, power source, connectivity path, firmware behavior, maintenance model, and user or installer context.
Fundamental review asks whether those pieces fit the device role. A small battery endpoint, an actuator, a gateway, and a public infrastructure node need different evidence, even when they use similar sensors or radios.
The mathematical gist. An 80%-derated 220 mAh coin cell provides 176 mAh or 0.528 Wh. A 3 ms, 8 mA BLE burst every 15 minutes averages only 1.03 µA, but the same burst through a late-life 200 Ω cell drops 1.60 V and leaves about 1.40 V at the radio. Charge predicts long life; voltage sag predicts the brownout.
31.3 Learning Objectives
By the end of this chapter, you will be able to:
- define a connected device by role, boundary, inputs, outputs, power, connectivity, and maintenance context
- distinguish endpoint, actuator, gateway, interface, and infrastructure roles in an IoT system
- explain how power, connectivity, sensing, actuation, compute, enclosure, and service constraints interact
- identify evidence needed before accepting a connected-device design claim
- write a bounded connected-device record with assumptions, owners, limits, and change conditions
31.4 Minimum Viable Understanding
Connected-device fundamentals are about fit. A device is reviewable when another person can see what it does, where it lives, how it is powered, how it communicates, how it is updated, how it is maintained, and what changes would require a new review.
Avoid starting from a category label such as “wearable,” “industrial,” or “smart home.” Start from the device’s role and evidence. Category labels can help organize examples, but they do not prove that a design works.
Use Figure 31.1 to keep this chapter in scope. Fundamentals name the role, boundary, evidence, and tradeoff; later chapters inspect form factor, power, and lifecycle evidence in more detail.
31.5 Prerequisites
This chapter builds on:
- Device Form Factors, which reviews physical design evidence.
- Connected Devices Lifecycle, which connects device design to operation and maintenance.
- Power Management, which reviews battery and power-state tradeoffs.
- IoT Reference Models, which places devices inside the system architecture.
31.6 Connected Device Boundaries
A connected device is the place where software promises meet the physical world. The device may be a battery sensor, a lock actuator, a gateway, a wall display, or a public infrastructure node, but the review always starts by naming what the device owns locally and what it depends on elsewhere.
Before deciding how Smart Watches shapes connected device boundaries, inspect Figure 31.2 beside Wearables. Together, Smart Watches and Wearables frame the connected device boundaries claim: device categories help orient examples, but the review still has to name the role, boundary, dependency, and maintenance evidence for the actual device.
In the diagram, check Smart Watches and Wearables separately in Figure 31.2; together they make device categories help orient examples, but the review still has to name the role, boundary, dependency, and maintenance evidence for the actual device auditable. For connected device boundaries, Smart Watches supplies visible evidence; Wearables constrains the decision. In Figure 31.2, retain Smart Watches beside Wearables so connected device boundaries remains explicit.
For a smart lock, the device boundary includes the motor, door position sensor, keypad or reader, BLE or Thread radio, battery pack, enclosure, firmware, credential storage, reset path, and update behavior. The phone app, Matter controller, Wi-Fi bridge, cloud service, and support tool may all be part of the product experience, but they are not the same device boundary.
The same category can hide very different review needs. A wearable fitness tracker, a hospital patient tag, and a worker safety badge are all wearable devices, but they differ in accuracy expectation, cleaning exposure, attachment method, privacy boundary, alert escalation, battery charging habit, and support workflow. A consumer smart plug, an industrial relay node, and a streetlight controller may all switch power, but their installation authority, local safe state, audit trail, firmware-update risk, and outage consequence are not comparable.
That is why the first review question is not “what type of product is this?” but “what responsibility does this physical device carry?” A sensor endpoint owns sampling, timestamping, freshness, and power state. An actuator endpoint owns command authorization, confirmation, interlock, manual override, and safe failure. A gateway owns local-device admission, buffering, protocol translation, time source, identity, and partial-failure reporting. A display or interface owns status clarity, accessibility, local controls, and recovery guidance.
Role: Decide whether the device senses, actuates, relays, displays, controls, or combines several roles. Context: Name the installation environment, user access, service interval, and failure consequence. Dependency: Name the gateway, phone, cloud, local controller, or operator action required for the device to keep its promise.
31.7 Device Hard-Constraint Review
Useful connected-device review starts with constraints that cannot be solved in the app later. A coin-cell nRF52 beacon, an ESP32 Wi-Fi prototype, an STM32 LoRaWAN sensor, and a mains-powered gateway may all send telemetry, but their radio airtime, sleep current, antenna placement, flash layout, thermal envelope, and maintenance path are different.
Connectivity also has to be checked in the installed context. BLE, Thread, Zigbee, Matter, Wi-Fi, LoRaWAN, LTE-M, NB-IoT, Ethernet, RS-485, Modbus, and IO-Link each move the boundary between the device, gateway, installer, and service owner. A bench test with the cover open does not prove performance inside a metal cabinet, freezer, basement, moving vehicle, or outdoor enclosure.
Build the review record from measurable constraints. For power, record sleep current, wake source, transmit duration, actuator current, brownout threshold, low-battery behavior, replacement path, and service interval. For connectivity, record join method, pairing ownership, retry limit, queue behavior, stale-data rule, local fallback, gateway dependency, and what the receiving system can distinguish. For compute and storage, record which rules run locally, what survives restart, which data is buffered, and how firmware updates are staged and rolled back.
Then test the constraint in a realistic sequence. A doorway sensor should be mounted in the doorway, with the enclosure closed, the gateway in its expected location, the battery state measured, the receiver showing fresh versus stale readings, and the reset or replacement path attempted by the person who will maintain it. A gateway should be tested with endpoint churn, local-protocol errors, clock drift, offline buffering, backhaul recovery, and partial failure displayed to support staff rather than hidden behind a single online status.
- Map the physical path. Include enclosure, mounting, sensor opening, antenna clearance, cable strain, IP rating, and service access.
- Map the power path. Include sleep states, transmit bursts, actuator current, brownout behavior, battery replacement, and charging or harvesting limits.
- Map the recovery path. Include pairing reset, local fallback, watchdog restart, OTA rollback, credential rotation, and decommissioning.
The accepted device decision should state the tradeoff. A coin-cell sensor may accept fifteen-minute freshness to meet a two-year battery target. A mains-powered gateway may accept higher local compute because it can buffer and diagnose endpoint failures. A lock actuator may reject cloud-only command handling because local override and safe failure matter more than implementation simplicity. The record should make those choices visible enough that a later radio, enclosure, battery, firmware, or deployment change triggers the right follow-up review.
31.8 Trust in State and Services
A connected device becomes trustworthy when its local state is explicit. Firmware should separate sensed value, command intent, actuator result, radio status, time source, configuration version, update slot, and fault reason instead of collapsing everything into “online” or “working.”
Storage choices matter because device history may survive loss of power, ownership transfer, or a failed update. Internal flash, FRAM, EEPROM, a secure element such as ATECC608A, or a TPM-class module may hold keys, counters, calibration, boot flags, rollback images, or pairing secrets. Each item needs a lifetime, reset rule, and protection level that matches the device role.
State transitions deserve the same attention as hardware. A device may move through manufactured, provisioned, commissioned, normal, degraded, offline, updating, rollback, factory-reset, ownership-transfer, and retired states. Each state should define what commands are accepted, which credentials are active, which data is retained, whether actuation is allowed, how the user sees the condition, and what support can inspect. If those states are implicit, field failures become ambiguous and recovery procedures become unsafe.
Gateway and mixed-role devices add another layer of state. They may track endpoint membership, local network health, backhaul reachability, clock confidence, translation errors, buffer pressure, duplicate suppression, schema versions, tenant or site binding, and update compatibility. A gateway that keeps accepting endpoint commands while its cloud path is down may create stale automation. A gateway that drops buffered data silently may turn a local radio fault into a misleading cloud dashboard. Review evidence should expose those boundaries.
- Identity: Define provisioning, certificate or key storage, ownership transfer, and revocation before field installation.
- Observability: Preserve enough counters, timestamps, firmware versions, and fault codes for support to distinguish device, gateway, and service failures.
- Safety: Keep actuator interlocks, manual override, local safe state, and offline behavior independent from cloud availability when physical harm or lockout is possible.
The low-level implementation evidence should connect back to the user-facing promise. If a device promises reliable occupancy status, its firmware must show sample timestamps, debounce rules, confidence or stale flags, retry behavior, and receiver semantics. If a device promises remote control, it must show authorization, command expiry, idempotency, result confirmation, and local safe state. If a device promises easy service, it must show reset paths, diagnostic codes, update rollback, replacement identity, and decommissioning behavior.
31.9 Connected Device Review Map
Before deciding how actuator/UI shapes connected device review map, inspect Figure 31.3 beside Compute. Together, actuator/UI and Compute frame the connected device review map claim: connected device fundamentals review map.
Check actuator/UI and Compute separately in Figure 31.3; together they make connected device fundamentals review map auditable. For connected device review map, actuator/UI supplies visible evidence; Compute constrains the decision. In Figure 31.3, retain actuator/UI beside Compute so connected device review map remains explicit.
Role: endpoint, actuator, gateway, controller, display, interface, or infrastructure node. Boundary: enclosure, mounting, user access, environment, and system segment. Inputs and outputs: sensors, events, commands, actuation, display, status, and logs. Power: battery, mains, harvesting, sleep states, service interval, and replacement path. Connectivity: local radio, wired link, wide-area link, gateway path, pairing, and fallback. Compute and storage: local decision, buffering, timestamps, logs, credentials, and update space. Security and updates: identity, provisioning, update path, rollback, reset, and decommissioning. Maintenance: install, inspect, clean, replace, calibrate, recover, and retire. Decision and change control: accepted tradeoff, owner, limit, and condition to reopen the record.
31.10 Device Boundary
The device boundary is where physical and digital responsibilities meet.
Review:
what hardware is inside the enclosure. what external sensors, cables, antennas, batteries, or mounting parts are part of the device. which gateway, phone, cloud service, or local controller the device depends on. what the user, installer, technician, or operator must touch. what data and control authority the device owns locally. what state survives restart, replacement, reset, or network loss.
If the boundary is unclear, later claims about power, connectivity, updates, or maintenance will also be unclear.
31.11 Device Roles
A connected device may have one primary role or several roles combined.
Sensor endpoint
Measures the environment or a system state. Review sensor placement, sampling, calibration, timestamps, local filtering, power state, and stale-data behavior.
Actuator endpoint
Changes the physical world. Review command identity, safe state, confirmation, manual override, local interlock, and recovery after restart or network loss.
Gateway
Connects local devices to another network or service. Review protocol translation, buffering, identity, time source, offline behavior, update path, and failure isolation.
Interface device
Provides status, controls, display, notification, or setup interaction. Review labels, feedback, accessibility, pairing, reset, and what can be done without a phone or cloud service.
Infrastructure node
Operates at scale or in places that are hard to service. Review installation repeatability, maintenance interval, weather or site exposure, asset identity, update policy, and replacement process.
Passively trackable object
Carries no power source or connectivity stack of its own; another device does the sensing and reporting. A passive RFID tag on a pet or pallet, a transit card such as an Oyster card, a QR code on a piece of equipment, a Disney MagicBand-style wristband, or a fixed Bluetooth beacon used as a positioning anchor all fall into this role. The “device” a user or operator reasons about is really the pairing of the passive tag and the reader, scanner, or beacon-listening app that gives it meaning. Review what triggers a read (proximity, line of sight, a deliberate scan), what happens when a read is missed or duplicated, who owns the reader infrastructure the tag depends on, and whether the object can be reasonably re-paired, replaced, or revoked if lost or transferred to a new owner. Google’s early Physical Web concept — a beacon broadcasting a URL that any nearby phone could resolve without an app — is a useful edge case for this role: it shows how far “trackable object” can stretch before it needs its own identity, permission, and revocation model.
The role should match the evidence. A gateway cannot be reviewed like a simple sensor endpoint, an actuator cannot be reviewed like passive telemetry, and a passively trackable object cannot be reviewed as if it had its own power and connectivity decisions — those decisions belong to its reader or gateway.
Use Figure 31.4 as a starting prompt, not as a substitute for review. It helps teams ask which category and constraint family they are dealing with, then the record still has to prove role, boundary, power, connectivity, update, maintenance, and failure behavior.
31.12 Core Building Blocks
Connected devices combine several building blocks:
Sensing or input: physical signal, user action, local event, or external device state. Actuation or output: motor, relay, display, sound, light, notification, or control message. Compute: firmware logic, state machine, filtering, inference, safety check, or local policy. Storage: configuration, identity, logs, buffered data, update package, or calibration data. Connectivity: wired, local wireless, wide-area, gateway-assisted, or intermittent link. Power: mains, battery, charging, harvesting, or mixed source. Physical shell: enclosure, mounting, sensor opening, antenna path, seal, label, and service access. Lifecycle controls: provisioning, update, reset, monitoring, repair, replacement, and decommissioning.
The review should not treat these blocks as independent. Changing one often changes another.
31.13 Tradeoffs That Matter
Connected-device design is usually a set of bounded tradeoffs rather than one perfect answer.
Before deciding how Power shapes tradeoffs that matter, inspect Figure 31.5 beside Battery Life. Together, Power and Battery Life frame the tradeoffs that matter claim: iot device design triangle showing tradeoffs among features, cost, and power.
Read Power alongside Battery Life in Figure 31.5; their named relationship makes iot device design triangle showing tradeoffs among features, cost, and power concrete. For tradeoffs that matter, Power supplies visible evidence; Battery Life constrains the decision. In Figure 31.5, retain Power beside Battery Life so tradeoffs that matter remains explicit.
Power versus capability
More frequent sensing, stronger radio use, brighter displays, local compute, and always-on status can increase usefulness, but they also change heat, battery size, charge interval, and service burden.
Connectivity versus installation
A radio that works well on a bench can fail after the device is mounted near metal, the body, water, machinery, walls, or underground material. Connectivity evidence belongs in the installed context.
Local behavior versus system dependence
Local decision-making can improve responsiveness and resilience, but it needs storage, update, reset, and policy evidence. Cloud-dependent behavior can simplify the device, but it needs offline and recovery evidence.
Simplicity versus maintainability
A sealed device can be durable, but service, reset, battery replacement, calibration, and disposal may become harder. A serviceable device can be easier to maintain, but openings and connectors add protection and assembly risks.
31.14 Evidence For Device Claims
A connected-device record should support claims with evidence such as:
device role and system boundary notes. installation or placement assumptions. power-state and service-interval evidence. sensor or actuator behavior observations. connectivity checks in the intended mounting context. local state, buffering, and restart behavior. provisioning, update, rollback, reset, and decommissioning path. maintenance, replacement, cleaning, or calibration steps. known limits and change conditions.
The goal is not to document every implementation detail. The goal is to make the design decision reviewable.
31.15 Worked Review: Battery Sensor Endpoint
A small endpoint samples a physical condition and reports values through a gateway.
Review evidence
- Sensor placement and sampling purpose are clear.
- The receiver can distinguish fresh, stale, duplicate, and missing values.
- The sleep, wake, transmit, and retry behavior fits the service interval.
- The gateway dependency is recorded.
- The battery replacement or recharge path is practical for the deployment.
- Firmware update and reset behavior are documented.
Likely review action
Hold the decision if the record only says “low-power sensor” without showing the sampling purpose, power states, receiver freshness rule, gateway dependency, and maintenance path.
Change condition
Rerun the review when the sampling interval, radio, gateway, battery, enclosure, receiver rule, update policy, or installation location changes.
31.16 Worked Review: Gateway Device
A gateway aggregates nearby device traffic and forwards selected data to another system.
Review evidence
- The gateway role is separated from the endpoint roles.
- Protocol translation and buffering rules are visible.
- Local time, identity, and configuration ownership are clear.
- Offline behavior is documented.
- The gateway update path does not strand endpoints.
- Logs or status can show partial failure instead of hiding it.
Likely review action
Ask for a gateway record if the design treats the gateway as a transparent cable. Gateways often change reliability, timing, identity, and security boundaries.
Change condition
Rerun when endpoint count, local protocol, wide-area path, buffering policy, identity model, time source, update path, or installation context changes.
31.17 Connected Device Record
Before deciding how offline shapes connected device record, inspect Figure 31.6 beside identity. Together, offline and identity frame the connected device record claim: connected device fundamentals record.
In the diagram, check offline and identity separately in Figure 31.6; together they make connected device fundamentals record auditable. For connected device record, offline supplies visible evidence; identity constrains the decision. In Figure 31.6, retain offline beside identity so connected device record remains explicit.
Role and boundary: what the device is responsible for and where that responsibility ends. Inputs and outputs: sensed data, user input, commands, status, actuation, and logs. Power and service: power source, sleep behavior, charge or replacement path, and service interval. Connectivity: local link, gateway path, pairing, fallback, offline behavior, and installed-context evidence. Compute and storage: local rules, state, buffering, timestamps, credentials, and update space. Security and updates: identity, provisioning, update, rollback, reset, and decommissioning. Maintenance: install, inspect, clean, calibrate, replace, recover, and retire. Decision and change control: accepted tradeoff, owner, known limit, open issue, and trigger.
31.18 Common Findings
The design uses a category label instead of a role and boundary record. The device role mixes endpoint, actuator, gateway, and interface responsibilities without evidence. Power claims do not include service or replacement assumptions. Connectivity was tested only before installation. Sensor or actuator behavior is described without receiver or safe-state evidence. Update, reset, rollback, or decommissioning paths are missing. Maintenance depends on tools, access, or permissions that are not recorded. The record lacks a change condition after radio, battery, enclosure, firmware, gateway, or deployment changes.
31.19 Review Checklist
Before accepting a connected-device fundamentals decision, confirm that the record includes:
device role and physical/system boundary. inputs, outputs, sensing, actuation, status, and logs. power source, power states, service interval, and maintenance path. connectivity path, gateway dependence, pairing, fallback, and installed-context evidence. compute, storage, buffering, restart, and local-state behavior. identity, provisioning, update, rollback, reset, and decommissioning path. installation, maintenance, calibration, replacement, and recovery steps. accepted tradeoff, owner, known limit, open issue, and change condition.
31.20 Knowledge Check
31.21 Matching Quiz
31.22 Ordering Quiz
31.23 Summary
Connected devices are physical system participants with roles, boundaries, inputs, outputs, power needs, connectivity paths, compute and storage behavior, security and update controls, maintenance expectations, and lifecycle limits.
The strongest review habit is to make each device claim bounded and inspectable. A device is ready for acceptance when its role, boundary, power, connectivity, local behavior, maintenance, and change conditions are visible enough for another reviewer to repeat the decision.
31.24 Key Takeaway
Connected devices succeed when physical constraints, power, sensing, communication, feedback, and maintenance are designed as one user-facing system.
31.25 Concept Relationships
Device Form Factors reviews the physical shell, mounting, and interaction surfaces that support the device role. Power Management expands the power-state and battery evidence introduced here. Connected Devices Lifecycle follows the device through provisioning, operation, maintenance, and retirement. IoT Reference Models places connected devices inside the larger system architecture.
31.26 What’s Next
Continue to Connected Devices Lifecycle to review how connected-device decisions change across provisioning, operation, maintenance, and retirement.