An accelerometer can produce an impressive chart long before it produces a trustworthy maintenance signal. Sampling cadence, mounting, machine speed, sensor range and operating state all shape the measurement. A good ESP32 experiment preserves those facts, computes repeatable features in Python and treats an alert as a prompt for inspection, not a diagnosis.
Choose a sensor and sampling rate for the frequencies you need to observe, not merely because an inexpensive breakout board is available. Verify bandwidth, noise density, full-scale range, anti-alias filtering, bus throughput and mounting resonance from the sensor documentation. An I2C sensor read at irregular intervals is not automatically a uniformly sampled vibration signal.
Collect timestamped XYZ samples into fixed-duration windows. Record actual sample count, missed deadlines, sensor range, orientation, temperature if relevant, machine identity and operating condition such as idle, load or speed. Preserve raw windows for a representative calibration set. If the ESP32 cannot buffer a full high-rate window, stream chunks with sequence numbers and detect gaps at the receiver.
Remove gravity or static offset deliberately; subtracting a mean can be reasonable for some features but may erase slow motion that matters. Check clipping and missing samples before computing a score. Timestamp the sample cadence rather than assuming the requested timer interval was achieved under Wi-Fi, storage or interrupt load.
In Python, begin with transparent features: per-axis RMS, peak-to-peak, crest factor, kurtosis when justified, and band-limited energy. For frequency structure, estimate a power spectral density with a documented window and segment length. Welch's method averages modified periodograms from overlapping segments, which can smooth a noisy estimate; segment size trades frequency resolution against averaging. Label spectral units correctly and retain the sampling rate used.
Split calibration and evaluation by time or machine run, not by randomly mixing adjacent windows from the same run. A threshold tuned on one operating speed may flag every normal sample at another speed. Compare like operating states, assess false alarms and missed events, and require a sustained or repeated deviation before paging a person.
A score outside baseline means “different under this model,” not “bearing failure.” Loose mounting, a changed load, temperature, sensor saturation or a maintenance action may explain the shift. Attach the feature vector, raw-window reference, model version and operating context to each alert so a reviewer can reproduce it. Start as advisory monitoring; safety shutdown decisions require a separately engineered and validated protection system.
| Signal or feature | Useful for | Check before alerting |
|---|---|---|
| RMS acceleration | Overall vibration trend | Comparable speed, load and sensor range |
| Crest factor | Transient peaks relative to average energy | Outliers, clipping and window length |
| Spectral band energy | Energy shifts in selected frequency regions | Sample rate, aliasing and bin resolution |
| Sample-gap count | Acquisition and transport health | Never interpret an incomplete window as normal |
Send derived features frequently and raw windows selectively when bandwidth and privacy allow. A record should include a stable machine ID, window sequence, sensor configuration, firmware/software versions, acquisition quality, feature values and server receipt time. Bound device queues and use idempotent ingestion so retries do not create extra samples. Dashboards should overlay operating state and missing-data markers with vibration trends.
Test a repeatable healthy baseline first, then introduce safe, known variations on a lab rig: changed speed, a controlled imbalance fixture or a loose test mount under appropriate supervision. Avoid damaging equipment or using people as a test load. Measure how often the rule alerts during normal variation and how quickly it detects the injected change. Document the tested machine envelope; do not extrapolate to equipment you have not characterized.
ESP32 plus Python is a capable learning pipeline when acquisition quality and machine context are first-class data. Use fixed windows, preserve raw evidence, compare equivalent operating states, validate features and calibrate alert costs. An anomaly score can prioritize a human inspection; it cannot certify machine health by itself.