40 Device Communication: Pattern Selection

40.1 Start With the Decision

Retell the user path in small steps. A person asks for an act.

40.2 Route Overview

This is part 1 of 2. Continue with Device Communication: Direct Links.

40.3 Part Objectives

• Test check your communication pattern with a concrete scenario and pass criteria.
• Validate pattern review map with a concrete scenario and pass criteria.

40.4 Chapter Roadmap

• Start Simple
• In 60 Seconds
• Check Your Communication Pattern
• Minimum Viable Understanding
• Prerequisites
• Communication Path Ownership
• Map Protocols to Behavior
• Path vs Decision
• Pattern Review Map

40.5 Start Simple

Picture a person tapping a smart lock. They need to know whether the door opened, whether the request is still in flight, or whether they should use a key. The network path shapes that human moment.

Telemetry means time-stamped reports about device state and events. The word protocol means an agreed set of rules for how devices exchange data. Start with one action. Trace it from the person to the device and back to visible proof. Name each stop. A direct path may be fast but work only nearby. A hub can keep local rules running. A mesh can route around one gap. A cloud path can support remote use but can also be slow or offline. A mixed design can use more than one path, but it needs one clear owner for state.

Ask the path in order:

• Who starts the action?
• Which device receives it?
• Does a hub carry it?
• Does a mesh relay it?
• Does the cloud take part?
• Where does the rule run?
• Which state is the source of truth?
• What can still work offline?
• What does the person see while waiting?
• What does the person do after failure?

One protocol name does not answer these questions. Practitioner compares setup, delay, power, privacy, support, and recovery. Under the Hood explains path and decision ownership, stale state, and split paths. Those details can change the user feedback. They never make a hidden failure safe to ignore.

Retell the user path in small steps. A person asks for an act. The app accepts the request. A local link may carry it. A hub may carry it. A mesh may relay it. The cloud may take part. The device receives the request. The device checks the request. The device attempts the act. Fresh state reports the result.

Now check a direct path. It can work nearby. It may avoid the cloud. It may need the phone. It may fail when the phone leaves. Setup must show the link. Support must know its limit. The user needs a clear fallback. The owner must know what stays local.

Now check a hub path. The hub can hold rules. The hub can join many devices. The hub may keep work local. It can also fail. Its power must be stable. Its state must be backed up. Its storage can fill. Its update can interrupt service. The user needs a hub fault message.

Now check a mesh path. Awake nodes may relay. Sleeping nodes may not. One failed route may heal. Another route may not exist. More hops can add delay. One relay can carry too much. A changed room can change the path. Support needs route evidence. The user still needs plain feedback.

Now check a cloud path. It can support remote use. It can join many sites. It needs an internet link. It needs account rights. It can become slow. It can go offline. Queued work can grow old. Local safety must not wait on it. Recovery must show what arrived.

Now check a mixed path. Local work has an owner. Cloud work has an owner. State has one trusted source. A fallback has one trigger. Two paths do not run the same act twice. Old commands are not treated as new. A user can tell which path failed. Support can trace each boundary.

Finish at the human result. Waiting has a clear sign. Success has fresh proof. Failure names the next step. Offline work is bounded. Private data has a clear route. Setup matches the real model. Replacement has a safe path. Ownership can transfer. The record names the next retest.

A communication topology becomes UX when people depend on its effects. Start with one action, trace the route from trigger to device response, and decide what feedback should explain direct control, hub mediation, mesh forwarding, cloud delay, local fallback, or stale state.

40.6 In 60 Seconds

Device communication patterns describe how connected products exchange commands, state, and telemetry. The pattern can be direct device-to-device communication, a hub-and-spoke system, a mesh network, a cloud-mediated path, or a hybrid that combines several of these at different layers.

The UX review question is not “which protocol is best?” The useful question is whether the communication pattern supports the user goal, installation context, response expectation, privacy boundary, power budget, recovery path, and maintenance model.

40.7 Learning Objectives

By the end of this chapter, you will be able to:

• distinguish direct, hub-and-spoke, mesh, cloud-mediated, and hybrid communication patterns
• review how a communication pattern changes setup, responsiveness, reliability, privacy, and support behavior
• identify where commands, automation rules, state, and logs actually travel
• separate user-visible failure modes from hidden network implementation details
• write a communication-pattern record with accepted limits, owners, and change conditions

40.8 Minimum Viable Understanding

A communication pattern is reviewable only when it names the participants, the path between them, the owner of automation logic, the local/cloud boundary, the failure behavior, and the user or operator action required when the path breaks.

Avoid accepting protocol labels as evidence. “Uses Wi-Fi,” “uses BLE,” “uses Thread,” or “uses MQTT” does not prove that the product is responsive, recoverable, private, easy to install, or suitable for battery operation. The pattern must be reviewed in the installed context.

40.9 Prerequisites

This chapter builds on:

• The Connected System Review Gate, which introduces the user-facing meaning of connected devices.
• Connected Device Fundamentals, which defines the device role and boundary.
• Connected Devices - Power Management, which reviews power evidence that communication patterns often change.
• Layered Network Models, which explains protocol layers behind these UX decisions.

40.10 Communication Path Ownership

A communication pattern is the product’s answer to a practical question: where do commands, telemetry, automation rules, permissions, and logs travel before the user sees an outcome? The protocol label is only one detail. The user experience depends on which path is local, which path needs the cloud, which component owns state, and what happens when one segment is degraded.

Before deciding how Owner shapes communication path ownership, inspect Figure 40.1 beside offline. Together, Owner and offline frame the communication path ownership claim: the pattern decision has to connect the user goal to the command path, state path, decision owner, local/cloud boundary, failure mode, and support record.

Check Owner and offline separately in Figure 40.1; together they make the pattern decision has to connect the user goal to the command path, state path, decision owner, local/cloud boundary, failure mode, and support record auditable. For communication path ownership, Owner supplies visible evidence; offline constrains the decision. In Figure 40.1, retain Owner beside offline so communication path ownership remains explicit.

For a lighting system, a wall switch may talk directly to a bulb, through a hub, across a Thread or Zigbee mesh, through a building gateway, and then to a cloud dashboard for remote monitoring. Those paths do not have the same latency, privacy boundary, power cost, failure mode, or support owner.

Review the pattern from the user’s promise. “The switch turns on the corridor light” is a different promise from “the facility dashboard receives occupancy telemetry” or “the cloud schedule updates every zone overnight.” The first may need local acknowledgement and bounded latency even when the internet is down. The second may tolerate buffering, sequence numbers, and delayed upload. The third may require account authority, audit logs, rollback, and a clear message when a cloud rule has not reached the local controller.

The pattern also changes who must understand the system. Installers need to know which nodes must be powered routers, where the hub or gateway belongs, and how to verify routes after doors, walls, or furniture change. Support staff need evidence that separates a sleeping endpoint from a weak link, a hub bridge fault, an internet outage, a cloud API error, or an account permission problem. Users need status that names the action they can take rather than a generic offline label.

Command path: know where user intent is accepted, queued, authorized, delivered, acknowledged, and confirmed. State path: know which device, hub, app, broker, cloud service, or dashboard is authoritative when state disagrees. Recovery path: know what remains local, what waits, what retries, what alerts, and what support can inspect.

40.11 Map Protocols to Behavior

Choose the pattern from the required behavior, then select protocols. MQTT publish/subscribe, CoAP request/response, HTTP APIs, WebSockets, BLE GATT, Matter over Thread or Wi-Fi, Zigbee clusters, LoRaWAN uplinks/downlinks, Modbus, OPC UA, and cellular MQTT all make different tradeoffs for latency, power, addressing, acknowledgement, provisioning, and diagnostics.

Start with one real workflow and trace every hop. For a wall switch, record whether the switch sends a bound Zigbee command to a bulb, sends an event to a hub rule engine, publishes an MQTT message to a broker, calls an HTTP API, or asks a cloud automation service to decide. Then record the acknowledgement that proves the physical effect: command accepted, message delivered, actuator applied, state confirmed, or stale status shown. Those are different evidence points, and they should not be collapsed into “online.”

1. Map the live command. Trace one user action from button, app, automation rule, or operator dashboard through authentication, routing, acknowledgement, physical effect, and UI confirmation.
2. Map the stale state. Define last-seen time, retained message behavior, cached state, sequence number, timestamp, confidence, and the message shown when state age exceeds the product promise.
3. Map degraded operation. Test internet loss, hub reboot, weak mesh route, sleeping endpoint, broker outage, expired credential, gateway queue backlog, and cloud API failure.

Use the installed environment, not a bench shortcut. A Thread sleepy end device may behave well near a border router but fail after a powered router is removed. A BLE direct-control path may feel immediate until the phone leaves the room or the device sleeps. A cloud-mediated alert may work in the lab but become confusing when local control still works and remote notifications stop. The review should include the exact fallback message, retry window, queue depth limit, and support evidence for each degraded state.

The implementation should expose enough diagnostics for support. Useful signals include RSSI/SNR, route parent, missed acknowledgements, queue depth, broker disconnect reason, CoAP response code, HTTP status, WebSocket close reason, gateway firmware version, and device firmware version.

40.12 Path vs Decision

A device may use a local radio path but still depend on a cloud decision. A hub may receive a command locally but fetch permissions from an account service. A mesh may relay packets locally but store schedules in the cloud. Good UX depends on separating transport path, authority path, automation path, and support path.

Message semantics matter. MQTT QoS 0/1/2, retained messages, Last Will and Testament, topic ACLs, CoAP confirmable messages, HTTP idempotency keys, WebSocket session state, Matter fabrics, Thread border routers, Zigbee binding tables, LoRaWAN confirmed downlinks, and gateway store-and-forward behavior all affect what “sent,” “received,” “applied,” and “failed” mean.

Authority should be explicit in the protocol and data model. A local button press, scheduled cloud rule, technician override, mobile app command, and safety interlock can all target the same actuator. The system needs idempotency, command expiry, conflict resolution, replay protection, permission checks, and audit records so delayed or duplicated messages do not create surprising physical behavior. If account revocation happens in the cloud, the record should state what local credentials remain valid and for how long.

Observability should preserve path evidence without exposing unnecessary personal data. Gateways can store sequence numbers, route parents, retry counts, broker disconnect reasons, cloud correlation IDs, clock confidence, firmware versions, and local decision logs. Those fields let support distinguish radio coverage, sleeping endpoints, hub storage pressure, internet loss, account failure, and cloud-service outage. They also let product teams repeat the review at the right layer when a protocol bridge, routing policy, firmware version, topology, or account model changes.

• Ordering: use sequence numbers, timestamps, idempotent commands, and conflict rules so delayed messages do not create surprising physical actions.
• Authority: separate device identity, user account authority, local override, tenant ownership, and support access.
• Observability: log enough path state to distinguish device power, local link, hub, gateway, internet, cloud, account, and firmware failures.

40.13 Pattern Review Map

Before deciding how Owner shapes pattern review map, inspect Figure 40.1 beside Mesh. Together, Owner and Mesh frame the pattern review map claim: device communication pattern review map.

Check Owner and Mesh separately in Figure 40.1; together they make device communication pattern review map auditable. For pattern review map, Owner supplies visible evidence; Mesh constrains the decision. In Figure 40.1, retain Owner beside Mesh so pattern review map remains explicit.

User goal: command, status, automation, monitoring, alerting, onboarding, or maintenance. Participants: device, phone, gateway, hub, router node, cloud service, dashboard, technician, or third-party platform. Path: direct local link, hub route, mesh route, cloud route, or a mixed path. Control owner: device, hub, edge gateway, cloud rule engine, mobile app, or operator workflow. Boundary: what works locally, what needs the internet, what needs an account, and what needs a nearby phone or gateway. Failure behavior: delayed command, missing state, queued event, degraded mode, local fallback, alarm, or manual recovery. Record: accepted tradeoff, user-facing message, support evidence, owner, and change condition.

40.14 Continue to the Next Part

Carry this evidence into Device Communication: Direct Links, which begins with Direct Communication.