Smart Elevator, IoT layer
Elevator remote monitoring, explained properly.
Most people meet this subject through a sales deck full of dashboards. This page is the other half: what a lift controller actually exposes, which signals are worth capturing, how they travel from a basement panel to a screen, and what decides whether the result is data you can act on.
Starting point
Most monitoring is still a phone call.
In a large share of buildings, the first indication that a lift has failed is a building manager on the phone, and by then the callout has already happened, the SLA clock has already run, and somebody is standing in a lobby explaining. Everything that follows is recovery.
Remote monitoring exists to move that first indication earlier, ideally before anyone in the building notices. The technical question is where the information comes from. A lift controller already knows the answer. It holds the fault register, the door operator state, the position of the car, and the motor feed. It simply never tells anyone, because it was never designed to.
A monitoring system is the layer that asks. The engineering quality of that layer is what separates a live picture of your elevators from an expensive source of false alarms.
Captured signals
What a monitored lift actually reports.
The exact set depends on what the controller exposes, which is why a survey comes before any promise. These six groups cover what most installations can obtain and why each one earns its place.
- Floor position and direction
- Door state and cycle timing
- Fault codes with timestamps
- Motor current and load
- Call registrations and trip counts
- Safety and service state
Floor position and direction
Where the car is and whether it is moving up, moving down, or idle. On serial controllers this is a register read. On relay panels it is reconstructed from selector position, contactor state, and shaft pulses.
Why it matters
Underpins trip counting, journey time, and the ability to tell a stranded car from a parked one.
Door state and cycle timing
Open, closing, closed, reopened, and how many milliseconds each transition took. Door timing is measured rather than estimated, so a drift of a few hundred milliseconds is visible.
Why it matters
Door systems cause a large share of elevator callouts, and timing drift usually precedes failure.
Fault codes with timestamps
The raw code the controller raised, the moment it happened by device clock, and a mapped plain-language description tied to the controller revision.
Why it matters
Gives a technician the reason before the site visit instead of after it.
Motor current and load
Current on the main drive feed, sampled fast enough to see the shape of a start rather than an average, plus derived load indication per run.
Why it matters
Rising current under a comparable load is one of the earliest mechanical warning signs available.
Call registrations and trip counts
Landing and car calls registered, runs completed, and cumulative usage per unit and per period.
Why it matters
Turns maintenance intervals from a calendar rule into a usage-based one.
Safety and service state
Emergency brake state, safety chain continuity where it can be read safely, inspection mode, and whether the car is in or out of service.
Why it matters
Separates a lift that is broken from a lift that a technician has deliberately taken offline.
The path of one event
From a contactor closing to a line on a screen.
Follow a single door fault through the system and every design decision becomes visible. Six stages, each of which can quietly ruin the data if it is treated as an afterthought.
Signal isolated and sampled at the panel
Firmware decodes and timestamps events
Written to storage before transmit
Validated and joined to the unit record
Live state, alerts, and replayable history
At the panel
Signals are isolated, conditioned, and sampled. Nothing about elevator control is modified. The interface listens.
On the device
Firmware decodes the protocol, rebuilds the state of the car, detects transitions, and stamps each event with the time it occurred rather than the time it was sent.
In storage
Events are committed to non-volatile memory before transmission is attempted, so a lost link or a power cut cannot erase the record.
Over the link
Messages travel over cellular or Ethernet on an encrypted, authenticated connection, and are released from the buffer only once the platform acknowledges them.
At the platform
Events are validated, deduplicated, written to a time-series store, and joined to the unit record so a fault sits in the context of the lift, the site, and the contract.
On the screen
Live state per unit, alerts on defined conditions, and history that can be replayed to answer what the lift was doing before an incident.
Looking for the software side rather than the engineering? The operations suite is where this data becomes daily work.
Elevator operations software →Connectivity
Designed around the worst signal in the building.
Machine rooms are in basements, on roofs behind plant, and inside shafts lined with steel. Cellular coverage in those places ranges from acceptable to absent, and building networks are rarely offered to a supplier without a conversation.
A monitoring design that assumes a healthy connection will lose the exact window that mattered, because power failures, network failures, and lift failures often arrive at the same moment. Local buffering exists for that reason. Events are stored first and sent second, then replayed in order with their original timestamps.
The device also reports on itself. Link quality, reconnect count, buffer depth, and restarts are visible, so a unit that has silently stopped talking looks different from a lift that has simply had a quiet week.
Security of the data path
Per-device identity and credentials provisioned during production
Encrypted transport between the device and the platform
Devices that fail authentication rejected at the platform edge
Signed firmware images, verified before they are accepted
Role-based access to elevator data, per region and per client
Audit trail on every action taken in the platform
Cloud-hosted or deployed on your infrastructure where policy requires it
Data quality
Four decisions that decide whether any of it is useful.
Monitoring projects rarely fail because a dashboard was ugly. They fail because the underlying record did not match reality, people stopped believing the alerts, and the system quietly became a screen nobody opens.
Read the controller, do not guess around it
A vibration sensor stuck to a machine can tell you something moved. It cannot tell you the controller raised a levelling fault, which floor the car stopped at, or whether the door reopened three times. Data quality is decided by where you tap, and the panel is the only place the truth exists.
Timestamp at the source
If events are stamped on arrival at the server, every network delay becomes a measurement error. Device-side timestamps with clock correction on reconnect keep sequence and duration intact, which matters when the question is what happened first.
Sample fast, report on change
Sampling rate determines what can be measured. Reporting rate determines what it costs to run. Separating them means door cycle timing stays accurate to milliseconds while a unit still fits comfortably inside a modest cellular data plan.
Prefer no data to wrong data
Partial frames, ambiguous relay states, and codes outside the known table are flagged as unknown rather than converted into a plausible value. A gap is recoverable. A confidently wrong record poisons everything built on top of it.
RnD Square designs the interface hardware and writes the firmware in house, which is why controllers that other platforms decline are readable here. The detail sits on elevator IoT hardware and elevator embedded firmware.
Limits
Monitoring on its own fixes nothing.
A fault event that lands on a screen at two in the morning and waits for someone to notice has saved nobody. The value appears when the event opens a ticket with the controller data already attached, routes to a technician who can reach the site, and lands in a history that can be produced later when a client questions a response time.
That is the operations layer, and it is a different discipline from reading a panel. Monitoring supplies the truth. Operations decides what happens next.
FAQ
Common questions about remote monitoring.
A device installed in the lift control panel connects to the controller signal points, samples them continuously, and runs firmware that decodes those signals into state and events. Those events are timestamped, buffered locally, and sent over an authenticated encrypted link to a platform where they become live status, alerts, and history.
Related
Keep reading.
Want this on your elevators?
Bring the controller types you run and the sites you cover. We will tell you what can be read from each panel and what a set of monitored elevators would actually look like.