Adding $30 Vibration Monitoring to a Legacy Pump Motor Using an ESP32 and MQTT
A 15-year-old cooling pump fails without warning. Bearing debris seizes the rotor. The production line stops. Estimated repair cost: $12,000 in lost output and emergency service fees. The motor has no native condition monitoring, no PLC card with spare analogue inputs, and no budget for a retrofit from the OEM. The hard operational reality is that most legacy rotating assets in Canadian manufacturing are data-blind. This guide details how to add vibration monitoring for under $30 in parts, using an ESP32 microcontroller and a MEMS accelerometer, transmitting actionable data over MQTT.
This is not a hobbyist project. It is a production-grade engineering intervention that bridges the gap between total ignorance and a full CMMS. We will cover hardware selection, physical mounting, data acquisition parameters (ISO 10816-3), FFT analysis for bearing defect frequencies, wireless transmission, power management for long battery life, and the software layer required to turn raw accelerometer data into a closed-loop work order system.
The Core Components
The bill of materials is brutally simple. You need an ESP32 development board (ESP32-WROOM-32, ~$8–12 CAD), an ADXL345 accelerometer module (~$6–10 CAD), a 3.7V 18650 Li-ion cell and holder (~$5 CAD), a passive buzzer or LED for local alerts ($1 CAD), and a plastic IP65 enclosure ($8 CAD). Total: approximately $30–35 CAD. The ADXL345 communicates over I2C (address 0x53), and the ESP32 handles WiFi connectivity to an MQTT broker.
Critical Engineering Decision: Mounting. The ADXL345 must be rigidly coupled to the motor housing. Epoxy mounting (Loctite 1C or equivalent) provides a stiff, high-bandwidth connection up to 10 kHz. For temporary monitoring, high-temperature N52 neodymium magnets work, but they introduce a low-pass filter effect above 2 kHz due to micro-movements. For permanent bearing defect monitoring, epoxy is the standard. Ensure the mounting surface is clean and flat. Do not mount on painted surfaces – grind down to bare metal.
Data Acquisition: From G's to Actionable Metrics
The ADXL345 has a full-scale range of ±16 g and a resolution of 13 bits. For pump monitoring, we are predominantly interested in the 10–1000 Hz frequency range. The sensor is configured for a sampling rate of 3200 Hz, with an anti-aliasing filter enabled. Raw x, y, z acceleration data is read at intervals determined by a free-running timer.
RMS Velocity (mm/s) – ISO 10816-3 Thresholds. Acceleration data alone is noisy and scenario-dependent. The standard for pump vibration severity is ISO 10816-3, which defines RMS velocity in mm/s. The calculation involves integrating the acceleration signal in the time domain using a high-pass filter at 10 Hz to remove DC offset, then computing the root-mean-square of the velocity waveform over a 1-second window.
// Pseudo-code for RMS Velocity calculation
accel_raw = read_ADXL345() // m/s²
velocity = integrate(highpass(accel_raw, 10 Hz)) // mm/s
rms_velocity = sqrt(mean(velocity^2)) // mm/s (RMS)
The ESP32 microcontroller performs this calculation onboard. The resulting RMS velocity value is compared directly to the ISO 10816-3 severity limits for Group 2 machines (pumps with power > 15 kW).
Table 1: ISO 10816-3 Vibration Severity for Pumps (Group 2)
| Assessment | RMS Velocity (mm/s) | Operational Action | CMMS Workflow Trigger |
|---|---|---|---|
| Good | < 3.5 | No action required. Baseline condition. | Log to database. No alert. |
| Satisfactory | 3.5 – 7.1 | Monitor monthly. Allow continued operation. | Add to weekly inspection list. |
| Unsatisfactory | 7.1 – 11.2 | Plan repair. Schedule downtime. | Generate CMMS work order (Priority: Medium). |
| Unacceptable | > 11.2 | Immediate shutdown. Risk of catastrophic failure. | Automatic CMMS alert + SMS to maintenance lead. |
This table is your operational decision matrix. Without it, the raw data is meaningless noise. The ESP32 firmware encodes these thresholds. When the RMS velocity exceeds 7.1 mm/s, the device transmits an alarm state.
FFT Spectral Analysis and Bearing Defect Frequencies
RMS velocity tells you if something is wrong. FFT analysis tells you what is wrong. The ESP32 has sufficient RAM to run a 256 or 512-point FFT on the time-domain acceleration data. This produces a frequency spectrum with a bin resolution defined by the sampling rate divided by the number of points.
FFT Bin Resolution Formula: Resolution = Sampling Rate / FFT Size. For a 3200 Hz sampling rate and a 512-point FFT, the bin resolution is 6.25 Hz. This is adequate for detecting fundamental bearing defect frequencies in pumps operating at 1800 RPM (30 Hz shaft speed).
The four primary bearing defect frequencies are calculated using the bearing pitch diameter (PD), ball diameter (BD), contact angle (θ), and number of rolling elements (N):
- BPFO (Ball Pass Frequency Outer):
(N/2) * (1 - (BD/PD) * cosθ) - BPFI (Ball Pass Frequency Inner):
(N/2) * (1 + (BD/PD) * cosθ) - BSF (Ball Spin Frequency):
(PD/BD) * (1 - ((BD/PD) * cosθ)^2) - FTF (Fundamental Train Frequency):
(1/2) * (1 - (BD/PD) * cosθ)
For a standard 6205-2RS bearing (commonly used in IEC 90-132 motor frames) at 1800 RPM shaft speed: BPFO is approximately 3.05x shaft speed (~91.5 Hz), BPFI is approximately 4.95x shaft speed (~148.5 Hz), and BSF is approximately 1.99x shaft speed (~59.7 Hz). The ESP32 firmware extracts these specific FFT bins and compares them against baseline spectra. A 10 dB rise in a BPFO bin is an early indicator of an outer race fault, often weeks before the RMS velocity triggers an alarm.
Wireless Transmission: MQTT and Network Topology
The ESP32 connects to the plant WiFi (2.4 GHz only). Do not attempt 5 GHz. The MQTT protocol requires a broker (Mosquitto or EMQX). The sensor node publishes to a structured topic tree: plant/assembly/pump_motor/vibration.
JSON Payload Structure:
{
"device_id": "PUMP-COOLANT-01",
"rms_velocity_mm_s": 8.5,
"alarm_state": "unsatisfactory",
"bpfo_db": -12.2,
"bpfi_db": -18.7,
"bsf_db": -24.1,
"battery_mv": 3800,
"timestamp": "2026-09-12T14:32:00-07:00"
}
This payload is consumed by a Node-RED instance or an MQTT bridge into the CMMS database. The alarm_state field is the direct output of the ISO 10816-3 comparison logic. If alarm_state is "unsatisfactory" or "unacceptable", the Node-RED flow should generate a CMMS work order and dispatch an alert to Slack/Teams/email.
Network Security: Place the MQTT broker behind a VLAN. Do not expose ESP32 devices directly to the internet. Use a local MQTT broker and bridge data to the cloud using a secure gateway if remote access is required.
Power Management: ESP32 Deep-Sleep and Battery Life
A wireless sensor that runs for 2 weeks is a maintenance liability. A sensor that runs for 2 years is an asset. The ESP32 features a deep-sleep mode which drops the current draw to approximately 10 µA while retaining RTC memory. The firmware is structured as follows:
- Wake from Deep Sleep (every 2 hours)
- Initialize ADXL345 (20 ms) – 1 mA
- Accumulate 1-second vibration window (1 sec) – 15 mA
- Compute RMS & FFT (500 ms) – 80 mA
- Connect WiFi + MQTT Publish (2–5 seconds) – 180 mA
- Enter Deep Sleep (10 µA)
The total active time per cycle is approximately 6 seconds. The rest of the 2-hour interval is spent in deep sleep.
Table 2: ESP32 Power Consumption and Battery Life (3,000 mAh Li-ion)
| Mode | Current Draw (Typical) | Duration per Cycle (2h) | Charge Consumed per Cycle |
|---|---|---|---|
| Deep Sleep | 10 µA | 7194 sec (99.9%) | 0.020 mAh |
| Active Measurement (Sensor + CPU) | 15–80 mA | 1.5 sec | 0.012 mAh |
| WiFi + MQTT Transmission | 180 mA | 4.5 sec | 0.225 mAh |
| Total per Cycle | Average: 0.26 mAh | 7200 sec | 0.257 mAh |
| Estimated Battery Life (3000 mAh @ 85% efficiency): ~2.8 years | |||
This battery life calculation assumes a brand-name 3000 mAh Li-ion cell with a PCB protection circuit. Cold temperatures (below -10°C) will reduce this by 20-30%. In sub-zero environments, use a lithium-iron-phosphate (LiFePO4) cell or a power-over-Ethernet (PoE) variant of the sensor. The battery voltage is monitored via the ESP32 ADC and included in the MQTT payload. Alerts for low battery (< 3.3V) are generated to trigger proactive replacement.
Software Stack and Alerting Logic
The MQTT broker feeds data into a Node-RED instance. Node-RED handles data normalization, threshold crossing alerts, and CMMS integration. Three alerting tiers are implemented:
- Tier 1 (Informational): RMS velocity 3.5–7.1 mm/s. Tag is logged as "increased vibration" in the CMMS asset history. No work order generated.
- Tier 2 (Warning): RMS velocity 7.1–11.2 mm/s. A work order is created in the CMMS with priority "Medium". The task description includes the measured spectra and a link to the relevant Visual SOP (e.g., "Bearing Replacement – Pump Type 4B").
- Tier 3 (Critical): RMS velocity > 11.2 mm/s OR a 15 dB rise in a known bearing defect frequency bin. An automated SMS/email alert is sent to the maintenance supervisor. Work order priority is set to "Critical". The system locks out the pump start command via a normally-closed relay connected to the motor control circuit (optional, field-configurable).
This software logic is the core reason the $30 sensor becomes a production-grade tool. It is not data collection; it is automated decision support.
Closing the Loop: Locking in the ROI with Software
The ADXL345 and ESP32 hardware stack is the edge node. It provides the raw data at a cost point that makes it disposable. However, the return on investment – the $12,000 downtime avoidance – is not realized until the data triggers a closed-loop maintenance action. This requires a software ecosystem that connects the sensor alert to a work order, a standard operating procedure, and a parts reservation.
Automating this specific problem with software locks in the ROI by eliminating the gap between data and action. A blinking LED on an ESP32 is not a maintenance plan. An MQTT message sitting in a broker queue is not a maintenance plan. But an alert from the sensor that automatically creates a work order in ServiceGrid, attaches the relevant ShopDocs visual SOP for bearing replacement, and reserves the correct bearing from SupplyGrid – that is a closed loop.
This is the Ryxen ecosystem approach. We build focused software tools that solve specific operational friction points. ServiceGrid for work order management. ShopDocs for visual standard operating procedures. SupplyGrid for material ordering. SafeDesk for safety compliance. When a $30 vibration sensor triggers a CMMS workflow across these tools, the ROI is locked in because the system does not require a human to connect the dots. The machine fails less, the maintenance team operates proactively, and the production schedule is protected.
The alternative is a $12,000 surprise three times a year. The $30 sensor is not just a data logger; it is the edge node of a proactive maintenance strategy. Install it, connect it to MQTT, integrate it with your CMMS, and stop accepting bearing failures as a cost of doing business.