A threshold alert "if temperature > 80°C" fires too late: by the time the threshold is exceeded, the problem has already formed. In our IoT monitoring projects, we use anomaly detection—deviations from the normal pattern that become noticeable hours or days before reaching a critical value. For example, a motor that usually heats up to 45°C in 20 minutes now reaches 45°C in 8 minutes. That's an anomaly, even though the temperature is within normal range. We have implemented a two-level architecture that detects such deviations and immediately alerts the operator. With over 5 years of mobile development and 30+ IoT projects, we can adapt the solution to any scenario.
How does on-device anomaly detection work?
For real-time IoT anomalies on a mobile device, algorithms must have low memory footprint and fast inference. Below is a comparison of three popular approaches.
| Algorithm | Memory usage | Accuracy | Inference speed |
|---|---|---|---|
| EWMA with adaptive baseline | <1 MB | Medium (univariate) | <1 ms |
| Isolation Forest (TFLite) | ~5 MB (int8) | High (multivariate) | ~2 ms |
| LSTM Autoencoder (TFLite int8) | ~4 MB | Very high (time series) | ~10 ms |
EWMA is a lightweight algorithm without a model, running on the device with zero overhead. Its 10-line Kotlin implementation fits into the codebase in an hour. Isolation Forest is better for multivariate data: offline training, fast inference, model converted to TFLite via ONNX. LSTM Autoencoder is the best choice for time series with patterns (daily cycles, production shifts). After int8 quantization, it takes ~4 MB and produces reconstruction error as an anomaly score.
Why is EWMA the optimal choice for on-device?
EWMA is implemented as a simple recursive formula: estimate = alpha * observation + (1 - alpha) * previous_estimate. The adaptive baseline updates on the fly: if no anomalies were detected, the baseline shifts toward current values. The anomaly threshold is the standard deviation multiplied by a coefficient. This provides instant response (<1 ms) without network or battery consumption.
How we implemented LSTM Autoencoder on TFLite?
For complex time series, we use an LSTM Autoencoder trained on normal data. The model is converted to TFLite with int8 quantization—size reduces from 12 MB to ~4 MB. Inference runs via Interpreter on Android or MLModel on iOS. Reconstruction error is computed as the mean squared error over a window; if it exceeds a threshold (tuned on validation), an anomaly is flagged. We added suppressions to filter planned events and a feedback loop (a "This is normal" button) to collect negative samples. After a month of operation, the number of false positives drops by 60%.
Why is multi-level detection necessary?
The optimal architecture is two-level. On-device: lightweight EWMA for instant reaction (<100 ms). On-server: a heavy model (Isolation Forest, LSTM AE) with full historical context for precise classification. The mobile app receives events from both levels: device → direct push via local notification (if the app is running), server → FCM/APNs with confirmed anomaly and its classification.
@Serializable data class AnomalyEvent( val sensorId: String, val timestamp: Long, val value: Double, val baseline: Double, val anomalyType: AnomalyType, // SPIKE, DRIFT, PATTERN_BREAK val severity: Severity, val possibleCause: String? // filled by server via LLM ) AI-driven IoT sensor anomaly detection: analytics and false positive management
The analytics screen should show a heatmap of anomalies by sensor and time of day, clusters by type (DBSCAN on the server), and correlations between sensors. These insights appear only after accumulating data over several weeks, so it's important to set up context collection from the start.
How to manage false positives? — AI anomaly detection
- Feedback loop: a "This is normal" button on the anomaly card sends a negative sample; the server incorporates it into retraining.
- Suppressions: "do not alert for sensor T-5 from 06:00 to 08:00—this is planned warm-up."
- Confidence threshold: show only anomalies with confidence > 0.8.
Comparison of on-device vs. server detection
| Criterion | On-device | Server |
|---|---|---|
| Latency | <1 ms | ~100 ms (network) |
| Accuracy | Medium (EWMA) | High (LSTM) |
| Autonomous | Full | Network-dependent |
| Model update | Via OTA | Instant |
The choice depends on the scenario: for time-critical reactions, on-device is needed; for detailed analysis, server is better.
What's included in the work
- Development of an anomaly detection module with two-level architecture.
- Training and quantization of models (EWMA, Isolation Forest or LSTM as per choice).
- Integration into the mobile app (Android/iOS) with TFLite/Core ML support.
- Configuration of feedback loop, suppressions, and analytics dashboard.
- Documentation, operator training, and one-month post-launch support.
Savings on alerts due to early detection reach 40%. We will assess your project within 2 working days. Our expertise—over 5 years of mobile development and 30+ IoT projects—guarantees a stable system. Request a consultation to evaluate your project—we'll find the optimal solution. Contact us.
References: EWMA on Wikipedia, TFLite documentation.