IoT Elevator Health Monitor with Predictive Maintenance Alerts

Elevators fail expensively — a seized bearing or a jammed door mechanism traps passengers and takes the car out of service for days. Yet most maintenance is still calendar-based: a technician visits every month whether the machine needs it or not. Predictive maintenance flips this around by watching the machine's own signals continuously. This project implements that idea on a tabletop elevator model: an MPU6050 vibration sensor on the car frame and a current sensor on the drive motor feed an ESP32, which learns the baseline vibration and current profile of a healthy trip. When vibration rises in a specific frequency band or motor current creeps upward — the classic signatures of bearing wear and mechanical drag — the system flags it on a cloud dashboard and pushes an alert, demonstrating condition-based maintenance on a real machine problem.

1. The MPU6050 vibration sensor is mounted on the elevator car frame and the current sensor is placed in series with the drive motor supply.
2. During commissioning, the elevator runs a set of healthy trips while the firmware records baseline vibration RMS and current profiles per trip phase (accelerate, cruise, decelerate).
3. In normal operation, the ESP32 samples vibration and current on every trip and compares them against the stored baseline.
4. Each door open/close cycle increments the door-cycle counter, which is tracked against the design maintenance interval.
5. Readings publish over Wi-Fi to the cloud dashboard, where trend charts show vibration and current evolving over days of operation.
6. When vibration RMS exceeds the warning band or current trends upward over successive trips, the system raises a WATCH/ALERT state and pushes a notification.
7. The trip event log records every anomaly with timestamps, giving the report real trend data from the student's own test runs.

Tech stack:

• ESP32 (Wi-Fi microcontroller)
• MPU6050 vibration/IMU sensor
• ACS712 current sensor
• Tabletop 3-floor elevator model
• MQTT broker + cloud dashboard
• Arduino IDE (C++ firmware)
• OLED status display
• 12 V DC drive supply

• [Vibration signature monitoring] An MPU6050 on the car frame captures vibration during every trip; firmware compares RMS levels against the learned healthy baseline.
• [Motor current tracking] A current sensor on the drive motor watches for the slow current rise that signals bearing drag or misalignment — a leading indicator of mechanical trouble.
• [Door-cycle counting] Every door open/close is logged, since door mechanisms are the most frequent elevator failure point and cycle count drives their maintenance schedule.
• [Cloud trend dashboard] Vibration, current and cycle counts stream to the cloud with long-term trend charts — the heart of predictive maintenance is the trend, not the instant value.
• [Predictive alerts] Threshold-plus-trend rules raise EARLY WARNING before hard limits trip, with NORMAL / WATCH / ALERT states shown on the dashboard and a local display.
• [Trip event log] Each trip is logged with timestamp, floors served, vibration peak and current draw for the report's analysis section.
• [Baseline learning mode] A calibration routine records the healthy signature during commissioning; all later comparisons are relative to the student's own machine.

• Tabletop 3-floor elevator model with sensors fitted
• ESP32 health-monitoring node (assembled, programmed)
• Cloud trend dashboard setup with alert rules
• Complete firmware source code with baseline-learning routine
• Wiring diagram and sensor mounting guide
• Baseline commissioning procedure document
• Project report PDF (background, predictive-maintenance theory, firmware, results)
• PPT presentation for final review
• Viva Q&A preparation document (vibration analysis, current signature, MQTT)

• This monitors a tabletop model; real elevators need certified sensors, safety-rated installation and compliance with lift codes — the report states this boundary plainly.
• Vibration baselines are machine-specific: the node must be recommissioned on any new machine, which the procedure document covers.
• The MPU6050 is a consumer IMU, not an industrial accelerometer; it detects trend changes well but is not a precision vibration-analysis instrument.
• Current-signature fault detection is trend-based; it flags developing problems but cannot diagnose the exact failed component.
• Wi-Fi is required for cloud trends and phone alerts; local display and logging continue offline.
• Simulated faults (added imbalance, drag load) are used to demonstrate detection — the report labels these as induced test conditions, not real failures.