Connected Product and Service Design · Study deck

Device Communication: Pattern Selection

Retell the user path in small steps.

UX Uma is your guide for this deck.

communication-patternshub-and-spokemesh-networking

After studying this chapter

Learning objectives

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

Major section

Start Simple

They need to know whether the door opened, whether the request is still in flight, or whether they should use a key.

Telemetry means time-stamped reports about device state and events.
The word protocol means an agreed set of rules for how devices exchange data.
A direct path may be fast but work only nearby.
Its storage can fill.

Choose direct, hub, mesh, cloud, or hybrid communication by tracing the user goal through command and state paths, ownership, local/cloud boundaries, failure behavior, and support evidence.

Major section

Start Simple (continued)

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.
One protocol name does not answer these questions.

Major section

Start Simple (continued)

It may fail when the phone leaves.

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.

Major section

Communication Path Ownership

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.
Those paths do not have the same latency, privacy boundary, power cost, failure mode, or support owner.
The pattern also changes who must understand the system.

Major section

Communication Path Ownership (continued)

Users need status that names the action they can take rather than a generic offline label.

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.
The second may tolerate buffering, sequence numbers, and delayed upload.
Command path: know where user intent is accepted, queued, authorized, delivered, acknowledged, and confirmed.

Major section

Map Protocols to Behavior

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 implementation should expose enough diagnostics for support.

Major section

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.

Major section

Path vs Decision (continued)

Observability should preserve path evidence without exposing unnecessary personal data.

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.
Authority: separate device identity, user account authority, local override, tenant ownership, and support access.

Major section

Path vs Decision (continued)

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

Deck summary

Key takeaways

They need to know whether the door opened, whether the request is still in flight, or whether they should use a key.

A hub can keep local rules running.
It may fail when the phone leaves.
The protocol label is only one detail.
Users need status that names the action they can take rather than a generic offline label.

Retrieval practice

Recall check 1 of 4

UX Uma says: answer from memory, then check your reasoning.

Q1A facilities team is choosing how corridor lights, wall switches, occupancy sensors, and a cloud dashboard communicate. Which review record is strong enough to approve the pattern?

AShow a dashboard and protocol name without local command path, authority, outage, or support evidence.

BList schedules, alerts, and remote control without showing which layer owns failure or recovery.

CShow one switch-to-light demo without hub, cloud, route, account, and outage tests.

DRecord outcome, actors, direct/hub/mesh/cloud paths, authority, outages, routes, support, tradeoffs, and change triggers.

Show answer

Answer: D A reviewable communication-pattern decision ties user outcome, participants, paths, decision ownership, local and cloud boundaries, failure behavior, support evidence, owner, accepted limits, and change condition together before the topology is trusted.

Retrieval practice

Recall check 2 of 4

UX Uma says: answer from memory, then check your reasoning.

Q2A corridor light must keep responding to a local wall switch during an internet outage. Which communication role best preserves that rule?

AA remote broker required before the wall switch can change lights.

BA phone relay required for every local wall-switch action.

CA local hub keeping switch-to-light rules through internet outage.

DUse the mesh because routing connectivity also determines the local control rule.

Show answer

Answer: C A local hub can own the switch rule and keep it running when the cloud is unavailable.

Retrieval practice

Recall check 3 of 4

UX Uma says: answer from memory, then check your reasoning.

Q3A wall switch stops working because its hub has lost power. What should the user-facing status say?

ARoute-parent identifier only, hiding the failed switch action.

BSwitch unavailable; light state unknown; seek support for the hub.

CA bare offline label without naming hub loss or state uncertainty.

DLight shown on solely because a command was attempted.

Show answer

Answer: B The message says what failed and what the person can safely do.

Retrieval practice

Recall check 4 of 4

UX Uma says: answer from memory, then check your reasoning.

Q4A building has awake wall-powered nodes that can relay messages around a failed link. Which communication pattern fits?

AOne direct link with no relay path after its link failure.

BMesh communication with awake nodes relaying around the failed link.

CUse cloud control because the wall-powered relay nodes can wait for the cloud decision.

DOne isolated sensor with no network path to other nodes.

Show answer

Answer: B Awake nodes can relay messages, and the route can change around a failed link.

Print reference

Answers

Answer key.

D · A reviewable communication-pattern decision ties user outcome, participants, paths, decision ownership, local and cloud boundaries, failure behavior, support evidence, owner, accepted limits, and change condition together before the topology is trusted.
C · A local hub can own the switch rule and keep it running when the cloud is unavailable.
B · The message says what failed and what the person can safely do.
B · Awake nodes can relay messages, and the route can change around a failed link.