11 Anatomy of a Connected Device

11.1 Start Simple

This section: Start Simple — Imagine a door sensor that shows “closed” on a phone.

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.

11.2 In 60 Seconds

This section: 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.

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.

Math Bridge · guided foundationsHow can a 19-year charge budget still brown out?Let UX Uma separate average current from the radio's burst-voltage limit. Learn the maths

11.3 Learning Objectives

This section: 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

11.4 Minimum Viable Understanding

This section: Minimum Viable Understanding — Connected-device fundamentals are about fit.

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 11.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.

11.5 Prerequisites

This section: 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.

11.6 Connected Device Boundaries

This section: Connected Device Boundaries — A connected device is the place where software promises meet the physical world.

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.

Use Figure 11.2 to compare device categories against the evidence a real installation needs.

+

The wearable, consumer, and industrial columns leave power, link, and cost open as questions. Smart watches and fitness trackers share a group, yet each needs its own role and upkeep plan. The coin cell case makes the risk clear: a radio burst can drop voltage even when its average use looks small. A category helps start the review. It cannot tell us what the unit must do at its site. Record its boundary, key dependencies, and measured limits before making a choice.

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.

11.7 Device Hard-Constraint Review

This section: Device Hard-Constraint Review — Useful connected-device review starts with constraints that cannot be solved in the app later.

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.

1. Map the physical path. Include enclosure, mounting, sensor opening, antenna clearance, cable strain, IP rating, and service access.
2. Map the power path. Include sleep states, transmit bursts, actuator current, brownout behavior, battery replacement, and charging or harvesting limits.
3. 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.

11.8 Trust in State and Services

This section: Trust in State and Services — A connected device becomes trustworthy when its local state is explicit.

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.

11.9 Connected Device Review Map

This section: Connected Device Review Map — The nine checks in Figure 11.3 turn a device label into a review path.

The nine checks in Figure 11.3 turn a device label into a review path.

+

Start with role, boundary, and inputs and outputs to say what the local unit does and where services begin. The middle checks cover power, connectivity, and compute or storage; each needs evidence from the installed context, including what happens when a link fails. The final column takes the decision through update, maintenance, and retirement. Moving across the columns keeps an attractive feature from hiding a service burden. Finish with a record that names the limit and the condition that would reopen the choice.

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.

11.10 Device Boundary

This section: Device Boundary — The device boundary is where physical and digital responsibilities meet.

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.

11.11 Device Roles

This section: Device Roles — A connected device may have one primary role or several roles combined.

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, or a passive NFC wristband all fall into this role. The “device” a user or operator reasons about is really the pairing of the passive tag or code and the reader or scanner 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. A Bluetooth beacon, including one broadcasting a URL for Google’s early Physical Web, is an active radio device with its own power and connectivity behavior and needs a separate device-role review.

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 11.4 to review one warehouse doorway battery sensor as a sensor endpoint.

+

The first stage names sampling, timestamps, freshness, and power as this endpoint’s duties, with a gateway dependency to record. The second asks the receiver to tell fresh, stale, duplicate, and missing readings apart. Its coin-cell example derates 220 mAh to 176 mAh usable, but charge alone is not enough. In the failure stage, an 8 mA radio burst through a 200 Ω late-life cell predicts 0.008 A × 200 Ω = 1.60 V of drop and a possible brownout. This is why the record must include measured power states, a practical battery replacement path, and update and reset behavior before the role is accepted.

11.12 Core Building Blocks

This section: Core Building Blocks — Sensing or input: physical signal, user action, local event, or external device state.

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.

11.13 Tradeoffs That Matter

This section: Tradeoffs That Matter — Connected-device design is usually a set of bounded tradeoffs rather than one perfect answer.

Connected-device design is usually a set of bounded tradeoffs rather than one perfect answer.

Use Figure 11.5 to make the power tradeoff a measurable design choice.

+

The coin cell sensor gives up fast updates to meet its battery goal. The mains powered gateway can spend more energy on local storage and fault checks. The lock has a different limit: it needs local override and a safe failure path. These are different choices within the same tradeoff frame. None follows from a device label alone. For the design you choose, record sleep current, radio time, low voltage behavior, and the time until battery service. Those measurements let the team check the choice after use begins.

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.

11.14 Evidence For Device Claims

This section: Evidence For Device Claims — device role and system boundary notes.

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.

11.15 Worked Review: Battery Sensor Endpoint

This section: Worked Review: Battery Sensor Endpoint — A small endpoint samples a physical condition and reports values through a gateway.

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.

11.16 Worked Review: Gateway Device

This section: Worked Review: Gateway Device — A gateway aggregates nearby device traffic and forwards selected data to another system.

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.

11.17 Connected Device Record

This section: Connected Device Record — The worked beacon record in Figure 11.6 shows what a review needs beyond the phrase low power.

The worked beacon record in Figure 11.6 shows what a review needs beyond the phrase low power.

+

The coin cell and BLE burst fields separate stored energy from the short current demand of a transmission. The record also asks where identity is held, how an offline link is handled, and how firmware or a failed device can be recovered. Those fields belong together because a battery estimate alone cannot establish whether the beacon works in its installed setting. Keep the stated numbers tied to the chapter example, then test the radio and voltage behavior on the actual unit before accepting its service interval.

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.

11.18 Common Findings

This section: Common Findings — The design uses a category label instead of a role and boundary record.

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.

11.19 Review Checklist

This section: Review Checklist — device role and physical/system boundary.

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.

11.20 Knowledge Check

This section: Knowledge Check

11.21 Matching Quiz

This section: Matching Quiz

11.22 Ordering Quiz

This section: Ordering Quiz

11.23 Summary

This section: Summary — The strongest review habit is to make each device claim bounded and inspectable.

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.

11.24 Key Takeaway

This section: Key Takeaway — Connected devices succeed when physical constraints, power, sensing, communication, feedback, and maintenance are designed as one user-facing system.

Connected devices succeed when physical constraints, power, sensing, communication, feedback, and maintenance are designed as one user-facing system.

11.25 Concept Relationships

This section: Concept Relationships — Device Form Factors reviews the physical shell, mounting, and interaction surfaces that support the device role.

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.

11.26 What’s Next

This section: What’s Next — Continue to Connected Devices Lifecycle to review how connected-device decisions change across provisioning, operation, maintenance, and retirement.

Continue to Connected Devices Lifecycle to review how connected-device decisions change across provisioning, operation, maintenance, and retirement.

11.27 Additional Knowledge Checks

This section: Additional Knowledge Checks