Technical Comparison
An Elevator-Specific Platform
vs Generic IoT
Generic IoT gateways read voltage, current, temperature and vibration. A lift controller communicates floor position, door cycles, trip counts and fault codes in an encoding that changes by manufacturer and drive. This page explains, at signal level, what elevator-specific means and where generic platforms stop being useful.
The Core Difference
A Lift Is a Controller
With a Box Attached
Most industrial monitoring is a physics problem. You attach a sensor to a pump, measure vibration and temperature, and infer condition from the signal. The machine does not tell you anything. You measure it from the outside. Horizontal IoT platforms are built for exactly that, and they are good at it.
An elevator is different. The controller already knows the state of the system. It knows which floor the car is at, which calls are registered, why the door reversed, whether the safety chain opened, and which fault it logged three minutes before the unit stopped. That information is a language, and every manufacturer speaks a different dialect. Reading it is a decoding problem, not a sensing problem.
This is why a generic gateway strapped to a lift produces disappointing results. It will faithfully report that a digital input changed state at 14:22:07. It cannot tell you that the change meant a door reversal caused by a safety edge on the third floor, which is the fact your technician needs. Elevator-specific means the decoding happens where the data is created, and everything above it is built on the decoded meaning.
Signal by Signal
What Gets Lost With a
Generic Gateway
Six data points that decide whether a monitoring deployment changes your operation or just adds a dashboard nobody opens.
| Signal | Elevator-specific | Generic IoT gateway |
|---|---|---|
| Floor position | Decoded floor and direction | Digital input change only |
| Door cycles | Counted with open and close timing | Contact open or closed |
| Trip counts | Trips per unit, by floor pair | Sensor readings, no journeys |
| Fault codes | Decoded per family with severity | Opaque number or nothing |
| Motor current | Correlated with load and direction | Raw current value |
| Safety chain | Distinct high-priority event | Just another input transition |
Floor position and direction
Generic platform
Not represented. A gateway sees a set of digital inputs changing state and has no model of a shaft.
Elevator-specific
Position is decoded from the controller into a floor index with direction and idle state, so the dashboard shows where every car is and the history shows where it stopped.
Door open and close cycles
Generic platform
At best a contact opening and closing. No cycle count, no timing, no distinction between a normal close and a reversal.
Elevator-specific
Each cycle is a structured event with open duration, close duration and reversal cause. Cycle counts drive wear estimates, and drift in close timing is one of the earliest signs of door operator degradation.
Trip counts and duty
Generic platform
Absent. Generic platforms count sensor readings, not journeys.
Elevator-specific
Trips per unit per period, by direction and by floor pair. Duty is the denominator for every wear calculation and the basis for usage-driven maintenance intervals instead of pure calendar intervals.
Controller fault codes
Generic platform
Either invisible or captured as an opaque number with no meaning attached.
Elevator-specific
Fault registers are read and decoded per controller family into plain language with severity, then timestamped and attached to the unit, the ticket and the service record.
Motor current and load
Generic platform
This one a generic platform can measure, which is why demos focus on it.
Elevator-specific
Current is measured and correlated with direction, load and trip context, so a rising trend on upward travel is distinguishable from a heavier building at peak time.
Safety chain and brake state
Generic platform
Not modelled. A safety event looks like any other input transition.
Elevator-specific
Emergency brake state, safety circuit interruptions and entrapment-relevant conditions are treated as distinct high-priority events with their own routing and escalation.
Tell us your controller families. We will tell you exactly which signals we can read from each one, and which we cannot.
Request a Signal Map →Layer by Layer
The Difference Runs
Through the Whole Stack
Elevator-specific is a property of five layers, and a gap in any one of them propagates upward. Decoded data with a generic data model is still hard to query. A correct data model fed by undifferentiated signals is still guesswork.
- Decoded floor position, not raw input states
- Door cycle counts with open and close timing
- Fault registers translated into plain language
- Usage-driven maintenance from real trip counts
- AMC contracts and warranty windows in the schema
- Service data and billing on one data model
| Layer | Generic IoT or CMMS | Elevator-specific, built to spec |
|---|---|---|
| Interface layer | A gateway with standard sensor inputs and a handful of protocol adapters that were designed for industrial machinery. | A board designed for the electrical reality of a lift panel: the signal levels your controller exposes, isolation, interference, vibration, temperature and the physical space inside the cabinet. |
| Firmware layer | Generic acquisition and forwarding. Whatever comes in goes out as a numbered channel. | Protocol decoding per controller family, fault register mapping, event construction, local buffering for connectivity gaps, and OTA update so new controller support reaches the installed base without site visits. |
| Data model | Asset, sensor, reading, threshold. Everything elevator-shaped becomes a custom field. | Lift, controller, shaft, floor, trip, door cycle, fault, visit, contract, warranty. Queries like faults per thousand trips are one line rather than an export and a spreadsheet. |
| Operations layer | Generic work orders and schedules, or a separate CMMS entirely, integrated by file exchange. | Ticketing driven by decoded faults, dispatch by skill and location, AMC visit scheduling, proposals from service findings, and a timestamped audit trail per unit. |
| Business layer | Out of scope. Billing, contracts and margin live in a separate accounting package. | CRM, ERP and accounting built on the same schema, so AMC billing, contract profitability and SLA credits are computed from service data rather than re-keyed from it. |
Interface layer
Generic: A gateway with standard sensor inputs and a handful of protocol adapters that were designed for industrial machinery.
Elevator-specific: A board designed for the electrical reality of a lift panel: the signal levels your controller exposes, isolation, interference, vibration, temperature and the physical space inside the cabinet.
Firmware layer
Generic: Generic acquisition and forwarding. Whatever comes in goes out as a numbered channel.
Elevator-specific: Protocol decoding per controller family, fault register mapping, event construction, local buffering for connectivity gaps, and OTA update so new controller support reaches the installed base without site visits.
Data model
Generic: Asset, sensor, reading, threshold. Everything elevator-shaped becomes a custom field.
Elevator-specific: Lift, controller, shaft, floor, trip, door cycle, fault, visit, contract, warranty. Queries like faults per thousand trips are one line rather than an export and a spreadsheet.
Operations layer
Generic: Generic work orders and schedules, or a separate CMMS entirely, integrated by file exchange.
Elevator-specific: Ticketing driven by decoded faults, dispatch by skill and location, AMC visit scheduling, proposals from service findings, and a timestamped audit trail per unit.
Business layer
Generic: Out of scope. Billing, contracts and margin live in a separate accounting package.
Elevator-specific: CRM, ERP and accounting built on the same schema, so AMC billing, contract profitability and SLA credits are computed from service data rather than re-keyed from it.
The Software Side
Why a Horizontal CMMS
Leaks Work
The hardware argument has a software twin. A horizontal maintenance system models an asset, a work order and a schedule. That is a genuinely useful abstraction, and it covers a wide range of industries because most maintenance really does reduce to those three objects.
Elevator service does not fully reduce. An AMC contract has a visit frequency, an inclusion scope, a term, an escalation clause and a renewal date, and it governs many units across buildings that may have different owners. Components carry their own warranty windows that expire independently of the unit. Statutory inspection records have formats set by an authority, not by you. A fault that arrives from a controller needs to become a prioritised ticket with the fault context already attached, and the visit that closes it needs to update both the maintenance record and the billable position on the contract.
When the underlying model lacks those objects, they are recreated as custom fields, naming conventions and a person who knows which spreadsheet holds the renewal dates. The software looks configured. The manual work simply moved. Every one of those workarounds is a place where an AMC lapses, a warranty claim expires, or an invoice never goes out.
Built to spec means those objects exist in the schema because you specified them, including the ones that are peculiar to your company. The reporting that follows is a query rather than a monthly reconstruction.
How to Spot It
Eight Tells in a
Demo
None of these are disqualifying on their own. Several together usually mean you are looking at a horizontal product with elevator wording applied to the interface.
The demo shows temperature and vibration charts and never shows a floor position.
Fault information appears as a code number with no decoded meaning and no severity.
There is no answer to what happens on a controller family the vendor has not seen before.
Maintenance scheduling is calendar-only, with no usage or condition trigger.
AMC contracts, warranty windows and statutory inspections are handled with custom fields.
Service data and billing data live in different systems, connected by a monthly export.
Nobody can describe the buffering behaviour when a machine room loses connectivity.
The integration story is a spreadsheet import.
Frequently Asked Questions
Technical Questions
We Get Often
No. They are good technology aimed at a different problem. A horizontal platform is designed to be indifferent to the machine it is attached to, which is exactly what makes it useful across pumps, chillers, compressors and tanks. That same indifference is what makes it weak on lifts, because the value in elevator data lives in the meaning the controller assigns to it. Use a generic platform where the physics is the whole story. Use an elevator-specific stack where the controller is.
Keep Reading
Related Pages
Start With the
Controllers.
Every engagement begins with a controller survey, because that is what determines which signals are actually available across your elevators. Send us the families you run and the approximate counts, and we will come back with a technical assessment of what can be read and what it would take.