Sensor Applications Module Guide

Measure Before You Automate

A sensor application is not a sensor connected to a dashboard. It is a claim about the physical world carried through a transducer, placement, interface, timestamp, data path, decision rule, and action. Each boundary can change what the reading means. A precise number with the wrong unit, a temperature probe beside a heater, or a phone moving in a pocket can produce technically valid data that cannot support the intended decision.

This module teaches that whole route. The domain chapters start with the measurement question, compare sensing patterns, choose hardware, and build a bounded validation record. The architecture chapter assigns acquisition, filtering, transport, storage, decision, actuation, and evidence responsibilities. The mobile chapters then treat a phone as a permissioned, variable sensing platform rather than a universally calibrated instrument.

Carry one scenario through the route: a small produce store must detect sustained heat near its cold-room door and request ventilation without reacting to a passing person, one noisy sample, or a failed sensor. The route ends only when the team can explain why the action happened, what evidence bounded it, how a person can override it, and what the system does when the evidence is stale or implausible.

Learning Objectives

By the end of the module, you should be able to translate an application goal into a measurand, range, resolution, response-time, placement, calibration, environmental, power, interface, and maintenance contract. You should be able to distinguish a raw reading from a derived state, select hardware against the contract rather than a parts list, and preserve source, unit, timestamp, identity, context, validity, uncertainty, and retest triggers in an evidence record.

You should also be able to trace sensing into action without hiding the control boundary: acquisition, filtering, threshold or model, persistence rule, command, acknowledgement, safe state, operator override, and audit record. For phone sensing, you should be able to choose browser or native access, handle denied and unavailable permissions, interpret orientation and location uncertainty, compare heterogeneous devices, and limit participatory-sensing claims to the coverage and calibration evidence actually collected.

Before You Start

You should recognise voltage, current, a digital sample, a timestamp, and a basic network message. If sensor physics or interface limits are unfamiliar, begin with How Sensors Work and Reading Sensor Datasheets. If the action side is new, How Actuators Work separates command, driver, load, acknowledgement, and safe state.

Bring a decision question, not a favourite board or phone API. For the cold-room scenario, write the temperature range that matters, the maximum useful delay, where the air should be sampled, what comparison can establish plausibility, how long a threshold must persist, and what happens when the reading is missing. This module supports prototypes and bounded evidence; it does not turn one classroom run into a safety certification or a deployment-wide accuracy claim.

A Worked Sensor-to-Action Route

Begin with the decision and physical quantity

Start in From Sensing to Action. Rewrite “keep produce safe” as a bounded decision: if the air near the closed cold-room door remains above 8 °C for five minutes while the reference zone remains cooler, request ventilation and alert the operator. Name exclusions immediately: this is not a food-core temperature measurement, a compressor diagnosis, or proof of regulatory compliance. The action needs two temperature contexts, door state, sample age, persistence, and a manual override—not merely one threshold.

Use Sensing Across Domains to compare the pattern with environmental monitoring, occupancy, health, and industrial examples. The same sensor can support different claims only when placement and operating context travel with it. A fast response may matter at the door; long-term stability may dominate in a reference zone. This comparison prevents a domain label such as “smart building” from substituting for requirements.

Select the measurement chain, not just the transducer

Continue to Sensor Hardware Selection. Record the expected 0–15 °C range, required uncertainty, condensation risk, response time, cable length, power budget, interface, enclosure, calibration route, and replacement plan. A digital temperature sensor may simplify the interface, but its package and placement still set thermal lag and exposure. Add a door contact because the action contract depends on door state; do not infer every opening from temperature alone.

Open The Sensor Data Path and assign responsibilities. The device samples both temperature probes and the door contact, validates range and timestamp, and sends an identified record. The gateway retains a short outage buffer. The decision service rejects stale or invalid records, applies the five-minute persistence rule and hysteresis, and issues an idempotent ventilation request. The actuator controller checks its own interlock, reports accepted, applied, or failed state, and falls back safely. The audit row joins input record IDs, rule version, command ID, acknowledgement, override, owner, and retest trigger.

Prove the route before widening the claim

Use Lab: Sensor Application Workflow to co-locate each probe with a reference under stable and changing conditions. Calculate bias and error, preserve placement photographs and units, then test normal readings, a disconnected probe, stale time, a stuck value, a door-state disagreement, storage pressure, and a failed acknowledgement. The lab earns a bounded decision such as “trend and threshold suitable in this placement”; it does not erase uncertainty or prove every cold room behaves the same way.

Use a phone where its role is honest

Read Mobile Phone as a Sensor before adding a technician phone. In this route the phone is primarily a user prompt, recorder, and gateway: it scans the asset label, captures a placement note, shows the alarm evidence, and records an override reason. Mobile Sensor APIs helps decide whether a browser can supply the needed camera, orientation, or location cue and what permission, secure-context, accuracy, and failure fields must be retained. Do not turn a convenient phone reading into a calibrated plant instrument by omission.

Use Participatory Sensing only if many staff observations answer a shared question, such as where warm-air complaints cluster. Gate records by prompt version, access state, time, placement, phone context, and coverage before aggregation. More contributors improve reach, not automatic accuracy. The result may guide inspection priorities while the installed probes remain authoritative for the ventilation rule.

Why the Three Labs Matter

The general Sensor Application Workflow lab proves the physical measurement chain: reference comparison, bias, error, placement, failure handling, and the boundary of the claim. It comes before automation because a control rule cannot repair evidence whose source or context is wrong.

Lab: Mobile Web Sensor APIs isolates the browser boundary. Run support, secure-context, user-gesture, permission, device-frame, timestamp, and location-uncertainty checks on the target phone and browser. Then use Lab: Mobile PWA and Audio Sensing to test offline app-shell behavior, queued records, sync evidence, microphone consent, browser processing, FFT settings, relative levels, and retention. These are separate labs because a valid web sensor event does not prove offline delivery or calibrated audio, and a working PWA does not prove the physical measurement.

Keep one evidence packet across all three: question, source and role, setup, permission, units or feature definition, timestamps, quality fields, reference result, accepted and rejected states, offline or retry behavior, action boundary, interpretation limit, owner, and retest trigger. Change one condition at a time and preserve failures rather than overwriting them with the next successful run.

Quick Route Check

Related Practice

Continue into Sensor Calibration for deeper error models and production evidence, State Machine Patterns for persistence, retries, interlocks, and safe states, and Data Quality Monitoring for missing, late, invalid, and quarantined records. For the message boundary, MQTT Quality of Service explains delivery evidence without pretending QoS proves the physical observation or final action.

A strong final exercise is a one-page sensor-to-action decision record for the cold room: measurement question and exclusions, range and timing, sensor and placement, reference comparison, acquisition and validation, network and outage behavior, rule and hysteresis, command and acknowledgement, safe state and override, audit fields, privacy and retention, owner, and retest trigger. If the route begins with a kit and ends with a dashboard screenshot, Physics Phoebe would send it back to the measurement question. Return to Browse Modules when you want the wider course route.