On‑Device Anomaly Detection for Telemetry

On‑Device Anomaly Detection for Telemetry

By Surya

Intro

Devices in the field constantly send motion, temperature, and power data. In connected pet-tech products like ours, catching unusual patterns right on the device can prevent bigger problems, like a collar overheating or a tracker's battery draining too fast. Detecting anomalies locally means we can react in seconds instead of waiting on the cloud or burning through data bandwidth.

The ESP32 runs small models like Isolation Forests, which lean on simple comparisons instead of heavy math. More capable hubs like the Raspberry Pi CM4 can run compact autoencoders, which learn what normal looks like and flag anything that deviates. Together they form a fast, reliable, privacy-friendly detection system.

Why Isolation Forest

Isolation Forest works by randomly splitting data and checking how easily each reading can be isolated. Values that separate quickly are probably unusual, which makes this a good fit for small processors, since the model amounts to a handful of decision rules that run in a few milliseconds.

For devices, that means predictable speed, since every tree runs the same handful of checks; a small footprint, just a few kilobytes of memory; easy explainability, since each rule is just a feature compared to a number; and reliable, consistent results without heavy math.

Diagram of an Isolation Forest isolating anomalous sensor readings
Diagram of an Isolation Forest isolating anomalous sensor readings

Data and feature preparation

Each second of sensor data gets summarized into a handful of key numbers: motion (overall strength of movement and vibration), temperature (how quickly the reading rises or falls), and power (how much voltage drops when the device is active). These short summaries, about thirty numbers in total, are small enough to process on a microcontroller.

Training happens in a few steps: collect a few minutes of normal behavior, create the same summary features in Python, train an Isolation Forest on that data, and save the model's rules as small arrays that fit on the ESP32.

Edge inference on ESP32-S3

Each Isolation Forest gets stored as a simple table of numbers:

typedef struct {
  int8_t feature_idx;
  float threshold;
  int16_t left;
  int16_t right;
} Node;

The device checks each feature against the stored thresholds; the fewer steps it takes to isolate a reading, the more likely it's an anomaly.

Flow diagram of edge inference steps on the ESP32-S3
Flow diagram of edge inference steps on the ESP32-S3

Typical performance on the ESP32-S3: about 10KB model size, 15 to 20KB of RAM used, and under 0.5ms per inference check.

Autoencoder on CM4: smarter hub detection

While the ESP32-S3 handles quick rule checks, the CM4 hub can run a somewhat larger autoencoder model. An autoencoder learns to rebuild normal signals, and when something looks off, its reconstruction error rises, which becomes the anomaly signal.

Autoencoder reconstruction error rising when an anomalous signal appears
Autoencoder reconstruction error rising when an anomalous signal appears

This handles long-term drift well, like temperature slowly creeping up over hours, which is too subtle for rule-based models to catch. On smaller chips like the ESP32, autoencoders are usually too heavy since they need more memory and math, which is why they're best kept on hubs like the CM4 rather than every device.

Handling drift and thresholds

To keep results stable over time, the threshold adjusts automatically based on recent data averages, alerts only fire after several unusual readings in a row, and models and calibration data can be updated safely over the air.

Example of an adaptive threshold shifting with recent sensor data
Example of an adaptive threshold shifting with recent sensor data

Field results

During internal bench testing and early field trials, the setup behaved as expected. The ESP32-S3 flagged sudden movement spikes or voltage drops almost instantly, showing that simple threshold-based Isolation Forest models react within milliseconds even with noisy data. On the CM4, the autoencoder consistently caught slower, progressive changes, like gradual heating or long-term drift, that weren't obvious in raw readings. When we configured the system to send only short event packets instead of full data streams, network traffic and cloud processing dropped to a fraction of normal levels, showing that most of the useful signal can be extracted locally before anything even gets uploaded.

Together, this confirms that fast Isolation Forest checks on the device paired with adaptive autoencoder validation on the hub gives a practical, scalable balance of responsiveness, cost, and reliability.

Takeaways

  • Use Isolation Forest for small devices: fast and easy to run.
  • Use autoencoders on hubs: better suited to slow or complex patterns.
  • Together, they give quick local reactions plus smarter central verification.
  • The result is reliable, low-latency monitoring that saves battery and bandwidth.

Combining Isolation Forests on the edge with autoencoders on the hub helps catch real-world issues early, keeping devices efficient and pets safer.

Read more