AI and the Internet of Things

Start with a measurable physical problem

Imagine monitoring a small workshop fan. A vibration sensor reports acceleration, and a technician labels recordings from normal operation and known faults. The useful question is whether a new recording warrants inspection. A dashboard full of model scores is less useful if nobody knows which action to take or how often the system raises false alarms.

The Internet of Things connects physical devices, sensors and services. AI can classify sounds, forecast energy demand or identify unusual readings in those systems. Connectivity alone is not AI, and a temperature threshold may solve a problem more simply than a learned model. Compare a model with a sensible rule before committing to data collection and maintenance.

Follow one window of sensor readings

The sensor first samples a physical quantity at a configured rate. A processing step checks timestamps and units, groups readings into windows and computes inputs such as average vibration or frequency features. The model predicts from that window. An application then combines the prediction with operating context and a response policy.

Training and deployment must use the same preprocessing: axis order, units, normalization and window length. Training on acceleration in one unit and deploying another can produce plausible scores for meaningless inputs. Record a preprocessing version with the model and keep raw test recordings so the complete pipeline can be replayed.

A fan starting up may vibrate differently from a running fan. Label those conditions explicitly instead of letting the model learn that every startup is a fault. Do not randomly split overlapping windows from the same recording into training and test sets: near-duplicate windows can make the evaluation look stronger than it is.

Choose where inference runs

Inference can run on the sensor device, a local gateway or a remote server. A device can react without an internet round trip, but has limited memory and energy. A gateway can aggregate several sensors. A remote service can run a larger model, but adds network dependence and sends data off site.

These choices can be combined. For example, a device might calculate a small anomaly score and upload selected recordings for human review. That reduces routine traffic but still requires a documented upload policy. Local inference does not make uploaded diagnostics private, and a disconnected device still needs a safe behavior.

Reject bad readings before scoring them

Missing data is not an ordinary zero. Replacing an offline sensor with zeros can make a stalled or broken sensor look like a quiet, healthy fan. Validate the window and report unavailable data separately from normal operation. The illustrative limits below belong to this exercise, not to real industrial equipment.

Run this complete JavaScript in Node.js or a browser console. It makes no hardware or network calls. The function validates a fictional four-sample window and returns its root mean square value; it is a signal-processing baseline, not a trained fault detector.

function windowRms(samples, latestMs, nowMs) {
  if (!Number.isFinite(latestMs) || !Number.isFinite(nowMs) ||
      latestMs > nowMs || nowMs - latestMs > 2000) return null;
  if (!Array.isArray(samples) || samples.length !== 4 ||
      !Array.from(samples).every(x => Number.isFinite(x) && Math.abs(x) <= 20)) return null;
  return Math.sqrt(samples.reduce((sum, x) => sum + x * x, 0) / samples.length);
}
if (windowRms([3, -3, 3, -3], 1000, 1500) !== 3) throw new Error('RMS');
if (windowRms([0, 0, 0, 0], 1000, 5000) !== null) throw new Error('Stale');
if (windowRms([1, NaN, 1, 1], 1000, 1500) !== null) throw new Error('Invalid');
if (windowRms(new Array(4), 1000, 1500) !== null) throw new Error('Missing samples');
console.log('Sensor checks passed');

Keep physical authority outside the model

A score is evidence for a decision, not permission to actuate equipment. For the workshop example, initially create an inspection recommendation. A separate controller should enforce permitted operating ranges, emergency stops and any required human confirmation. Do not connect a language model directly to a motor-control command.

Repeated noisy readings can cause an alert to flicker. Depending on the application, a response policy might require several valid windows, use different thresholds for entering and leaving an alert state, or suppress duplicate notifications. Those choices also introduce delay; measure missed faults and time to detection rather than assuming smoothing is always better.

Test the system in conditions it will meet

Hold out entire recording sessions or devices when that matches the deployment goal. Test different mounting positions, background noise, speeds, temperatures and sensor replacements. Include faults, normal startup and unavailable data. Report which conditions were represented and which were not.

Version the model and firmware together, stage updates on a small set of devices and retain a working rollback. Monitor missing-data rates, alerts confirmed by technicians and changes in input distributions. A new fan or sensor can change the problem even when no software has changed.

Sources & further reading

Primary references for the concepts in this guide. Examples and exercises are illustrative; verify provider-specific behaviour against the version you use.

• Google AI Edge: LiteRT for Microcontrollers
• Google AI Edge: Building and converting models
• Hugging Face: Considerations for model evaluation