ElevateSafe: Smart Monitoring for Legacy Elevators

May 25, 2026

Work done in collaboration with: Matteo Ciulia and Lorenzo Pellegrino.

In historical cities like Rome, countless buildings rely on aging elevators that lack any built-in fault detection. Upgrading these systems or installing traditional monitoring solutions is often prohibitively expensive and requires risky modifications to fragile, decades-old electrical circuits.

Enter ElevateSafe—a low-budget, IoT-based monitoring system designed specifically for low-to-medium class residential buildings. Our goal is to bring modern anomaly detection and predictive maintenance to legacy infrastructure without breaking the bank.

The Concept

ElevateSafe bypasses the need for invasive wiring and building-wide Wi-Fi. It relies on a distributed architecture:

  • Sensing Nodes: Autonomous, battery-operated devices installed in the elevator cabins, with IMU and Hall Sensors.
  • Central Node: A single gateway installed in the building with a wired power source and Wi-Fi access.

The sensing nodes monitor acceleration and door movements to infer the health of the elevator. If an anomaly is detected, data is communicated to the Central Node via LoRa, which then routes it to an AWS cloud dashboard.

Under the Hood: Hardware & Software Architecture

The system is built for simplicity, affordability, and low power consumption:

  • Heltec WiFi LoRa 32 (V3): The brain of both our Sensing and Central nodes. It features an onboard OLED controlled via the Adafruit_SSD1306 and Adafruit_GFX libraries. The crucial LoRa communication is handled smoothly by the RadioLib library, enabling long-range communication through building walls.
  • LSM6DS3 IMU: By applying an Exponential Moving Average (EMA) filter on the accelerometer data of the LSM6DS3, the system cleans the data from the rumor and detects vibrations or movements that deviate from normal operation.
  • KY-035 Hall Sensors & Neodymium Magnets: Placed on doors and floors to detect passenger hop-on/off and floor arrivals with minimal current draw. They also act as checkpoints strictly resetting any IMU drift. These sensors were not used for the demonstration but are crucial for future iterations to provide more granular insights into elevator usage patterns, as they allow us to detect the distance of the elevator from the best spot and the floor it is currently on, information that can be leveraged to improve the detection accuracy of the system.

To assure responsiveness without blocking operations, the software relies strictly on a FreeRTOS architecture. We separated operations into dedicated tasks (vSensorTask, vFilterTask, vCommTask), using FreeRTOS StreamBuffer for rapid, thread-safe binary data transfer between the 1kHz sampling routine and the LoRa transmission logic.

Data Flow & Anomaly Detection

TODO

Concept vs. Reality

Looking back at our initial concept, several ambitious environmental monitoring goals were streamlined or replaced during the hands-on implementation:

  • Light & Temperature Sensing: We originally planned to use a 5506 Photoresistor and the IMU's built-in temperature sensor to monitor cabin states for energy optimization. During development, realizing that optimizing the core analysis on our accelerometer and ensuring reliable LoRa payloads were better priorities, the photoresistor was left out since it was not essential for the primary functionality.
  • Hall Sensor Swap: We conceptualized using the AH3503 linear Hall sensor, but ultimately adapted our hardware stack to use the KY-035 digital module due to the capacity of detecting the distance of the elevator from the best spot, an information that can be leveraged in the future to improve the detection accuracy.
  • Adding Unplanned Security: Our initial spec made no mention of payload security. However, recognizing the risks of cleartext alarm telemetry broadcasting over LoRa, we implemented symmetric AES-128 CBC encryption directly on the sensing node leveraging the mbedtls library: 
    mbedtls_aes_context aes;
mbedtls_aes_init(&aes);
mbedtls_aes_setkey_enc(&aes, LORA_AES_KEY, 128);
mbedtls_aes_crypt_cbc(&aes, MBEDTLS_AES_ENCRYPT, 16, temp_iv, plaintextBlock, &txBuffer[16]);
    Future iterations could explore more robust key management strategies, such as per-device keys or integrating a secure element for hardware-based encryption.

Evaluation & Constraints

To ensure the system is genuinely viable for older buildings, we focused heavily on specific constraints:

  1. Power Consumption: The Sensing boards cannot draw power from the elevator's electrical system, since the are old and unreliable. Instead, they are powered by batteries that should be optimized to run continuously for around 3 months, that is 1 month more than the average maintenance schedule for most elevators, requiring very low maintenance.
    By law (D.P.R. 162/99) ordinary manutention of elevators is executed every 6 months but usually, and expecially in old elevators, this is performed every 2 months.
    This battery life requirement is one of the most challenging constraints, as it limits the frequency of data collection and transmission.
    This aspect is achieved through a combination of hardware choices (low-power sensors, efficient microcontroller) and software strategies (light sleep modes, event-driven wakeups). For instance, the IMU is configured to trigger an interrupt on significant movement, allowing the microcontroller to remain in light sleep until necessary.
    Nonetheless, the reliance on battery power means that the system is not suitable for monitoring elevators with extremely high traffic or those that require real-time anomaly detection, as frequent wakeups and transmissions would drain the battery faster than desired.
    Plus the use of Heltec WiFi LoRa 32 (V3) is not ideal for this application and does not allows us to meet the requirements about power consumption. Future iterations could explore custom-designed hardware to further extend battery life and reach the desired performance.

  2. Network Efficiency: Relying on a LoRaWAN topology using SF7, we achieve up to 1Km of coverage, suitable for urban environments. To respect the 1% duty cycle limit of the ETSI standard, our payloads are heavily optimized down to just a few bytes:

    typedef struct AlertData {
    uint8_t elev_id;
    uint8_t alarm;
    uint8_t reserved[2]; // Padding to make the struct 4 bytes total for efficient queue storage
} AlertData;

  3. Reliability & Response Time: ElevateSafe is focused on measuring data for asynchronous analysis rather than real-time security, achieving a stable sub-10 second delay for data visualization on AWS. This is sufficient for maintenance alerts and energy optimization insights, but not for immediate safety interventions, but it is not a problem for our intended use case.

Future Directions

While the current implementation of ElevateSafe demonstrates the feasibility of smart monitoring for legacy elevators, there are several avenues for future development:

  • Enhanced Anomaly Detection: Incorporating machine learning algorithms to analyze the collected data could improve the accuracy of anomaly detection and provide predictive insights into potential failures. But it is important to consider the computational limitations of the sensing nodes and the need for efficient data transmission when designing these algorithms.
  • User Interface Improvements: Developing a more user-friendly dashboard for building administrators to visualize elevator health and receive alerts could enhance the usability of the system. This could include features such as historical data analysis, trend visualization, and customizable alert thresholds.
  • Integration with Building Management Systems: Integrating ElevateSafe with existing building management systems could allow for more seamless maintenance scheduling and energy optimization, providing a more comprehensive solution for building administrators.

The Impact

By gathering intelligence on elevator movements and anomalies, ElevateSafe delivers two primary benefits:

  • Predictive Maintenance: Early detection of mechanical deterioration drastically reduces the need for manual testing and prevents unexpected breakdowns.
  • Energy Optimization: By learning the usage patterns of the elevator, building administrators can optimize cabin lighting, saving condominiums money and providing immediate ROI.

ElevateSafe proves that with the right combination of Edge computing and LoRa technology, protecting and upgrading historical infrastructure doesn't have to be a luxury.

Riccardo Passacantando