Elevator Monitoring System

A end-to-end monitoring platform that reads elevator controller signals, streams them over MQTT, and presents live car position, door state, faults and usage analytics to building operators.

Role: Lead Engineer — firmware, backend, dashboard
Duration: 10 months
Status: Production

Elevator Monitoring System main screenshot

Background

Maintenance teams relied on tenant phone calls to learn that an elevator had stopped. There was no historical record of faults, so recurring issues were diagnosed from memory rather than data.

Problem

Elevator controllers exposed only dry contacts and Modbus registers, with no networking. Downtime was discovered late, root-cause analysis was guesswork, and service reports were written by hand.

Solution

An ESP32-based gateway reads controller I/O and Modbus registers, publishes normalized events over MQTT with store-and-forward buffering, and a Node.js ingest service persists time-series data. A React dashboard renders live state per unit, with rule-based alerting to WhatsApp and email.

Features

Live car position, direction and door state per unit
Fault detection with severity classification and escalation rules
Offline buffering so no event is lost during network outages
Trip counters, run hours and usage heatmaps for preventive maintenance
Role-based access for operators, technicians and management
Exportable service reports in PDF and CSV

Architecture

1Field layer — elevator controller I/O and Modbus TCP registers
2Edge gateway — ESP32 firmware, normalization, local ring buffer
3Transport — MQTT broker with TLS and per-device credentials
4Ingest — Node.js consumer writing to PostgreSQL time-series tables
5API — REST + WebSocket for live subscriptions
6Client — React dashboard with virtualized unit grid

Challenges

Building networks with intermittent connectivity required a durable edge buffer and idempotent ingest.
Every elevator brand exposed different register maps, so a per-model mapping layer was introduced.
Alert fatigue: initial rules fired too often and were replaced by debounced, severity-aware rules.

Lessons Learned

Normalize at the edge — the cloud should never know vendor quirks.
Operators trust a system only after it survives a real outage; design for the outage first.
A small set of well-chosen metrics beats a dashboard full of gauges.