Smart Elevator, IoT layer
Elevator embedded firmware that speaks controller.
The board gets you wires into the panel. The firmware decides whether those wires produce a usable record of the lift or a stream of numbers nobody trusts. It decodes the protocol, rebuilds the state of the car, maps fault codes to something a technician can act on, and keeps working when the network does not.
The problem
A signal is not a fact yet.
Ask a lift controller a simple question, such as which floor the car is on, and you will get a different answer format from every manufacturer. One returns a register value. One holds it in a floor selector position. One never states it at all and expects you to count pulses from the shaft encoder while tracking direction from a contactor.
The same is true of faults. A code is a number in a table that changes between controller revisions. Sent onward unmapped it becomes a dashboard full of integers that a maintenance manager learns to ignore within a week.
Firmware is where those differences are absorbed. Written well, everything above it gets a clean, consistent record of the lift regardless of what is inside the panel. Written badly, every problem downstream is a data problem.
Signals the firmware decodes
- Floor position and direction of travel
- Door state and full cycle timing
- Motor feed and door operator current
- Run started and run completed
- Fault raised and fault cleared
- In-service and parked-out-of-service state
- Mapped fault reason in plain language
- Severity assigned per fault code
Edge pipeline
Six stages between the panel and the platform.
Everything below runs on the device itself. The cloud receives interpreted events, not raw voltage traces, which is what keeps a few thousand elevators affordable to operate on cellular data.
Sample inputs on a fixed schedule
Parse frames per controller family
Build car floor, door, and motion state
Turn transitions into timestamped events
Write to storage before transmit
Send over an authenticated, encrypted link
Acquire
Inputs are sampled on a fixed schedule fast enough to catch a door cycle and a motor start, with debouncing on mechanical contacts so a bouncing relay does not become four events.
Decode
Serial frames are parsed against the controller frame format, registers are read at their documented offsets, and discrete inputs are combined into meaningful state. This is the layer that differs per controller family.
Reconstruct state
Raw values become a model of the lift: current floor, direction, door position, motion, and whether the car is in service. On relay panels this reconstruction is the whole job, because no single signal states the answer.
Detect events
Transitions become events. Door opened, door failed to close within the expected window, run started, run completed, fault raised, fault cleared, car parked out of service. Each carries a device timestamp taken at the moment it happened.
Buffer
Events are written to non-volatile storage before any attempt to transmit. If the modem is down or the site has lost coverage, history keeps accumulating instead of disappearing.
Publish
Structured messages are sent over an authenticated, encrypted link, acknowledged by the platform, and only then released from the buffer. Unacknowledged messages are retried with backoff.
Protocol decoding
Three kinds of hard.
Decoding work falls into three buckets, and the effort between them differs by an order of magnitude. Scoping your elevators means knowing which bucket each controller belongs in before any promises are made.
Serial drives
A documented register map is the easy case, and even there the frame format, byte order, polling limits, and revision differences have to be handled. Some drives will not tolerate aggressive polling, so read rates are tuned per model.
Relay panels
No protocol exists. Floor position is derived from selector contacts or counting shaft pulses, direction from which contactor is energised, door state from the operator contacts, and service state from the safety chain. The firmware carries a small state machine that mirrors the panel logic.
Undocumented vendor protocols
Where documentation is unavailable, behaviour is observed on a live panel: trigger a known condition, record the traffic, and confirm the correlation across repeated runs. Every inference is validated against the controller service tool before it is trusted.
{
"device": "elv-0a41c9",
"unit": "TOWER-B/LIFT-2",
"controller": "vvvf-serial-rev4",
"ts": "2026-03-12T09:41:07.220Z",
"event": "door.close_timeout",
"state": {
"floor": 7,
"direction": "idle",
"door": "opening",
"in_service": true
},
"fault": {
"raw": "0x1C6",
"mapped": "Door operator failed to
complete close cycle",
"severity": "high"
},
"metrics": {
"door_cycle_ms": 5820,
"door_cycle_baseline_ms": 4100,
"motor_current_a": 11.4
},
"buffered": false,
"fw": "2.7.3"
}Have a controller nobody has been able to read? That is the conversation we like having.
Book an engineering call →Fault code mapping
A number nobody reads becomes a reason somebody acts on.
Mapping is built per controller during discovery from manufacturer documentation, service manuals, and observed behaviour on live panels, then maintained as a versioned table shipped with the firmware.
Raw controller code retained alongside the mapped description, so nothing is lost in translation
Plain-language reason a technician can act on without opening a service manual
Severity assigned per code, because a levelling retry and a safety chain break are not the same event
Grouping of codes that always occur together, so one root cause does not become six alerts
Controller and firmware revision recorded with the mapping, since code tables change between revisions
Unmapped codes flagged rather than silently dropped, then added to the table in a firmware release
Buffering and resilience
A basement is a bad place for coverage.
Machine rooms sit in basements, on roofs behind plant, and inside lift wells lined with steel. Connectivity drops. Buildings lose power. A device that only reports live will lose exactly the history you need after an incident, because an outage and a fault often arrive together.
Events are therefore committed to non-volatile storage before transmission is even attempted, timestamped with the device clock, and replayed in order when the link returns. The platform deduplicates on identifiers so a retry never doubles a fault count.
The device also reports its own health: link quality, reconnect counts, buffer depth, restarts, and current firmware version. A unit that has quietly stopped reporting should look different from a lift that has simply had a quiet week.
Failure cases handled at the edge
Cellular outage of hours or days at a single site
Building power loss taking the lift and the device together
Platform maintenance windows where ingestion is unavailable
Clock drift, corrected against the server on every reconnect
Partial or corrupt controller frames, rejected rather than guessed
A failed firmware release, reverted by the bootloader without a visit
Over-the-air updates
Ship a fix to all your elevators without a van.
Devices live in places that are inconvenient to reach and belong to customers who do not enjoy scheduled access. An update path that is safe under power loss is a design requirement, not a feature.
Signed image
Every build is signed. A device will not accept an image it cannot verify.
Dual slot write
The new image is written to the inactive application slot while the current one keeps running.
Verify then switch
The image is checked in full before the bootloader is told to switch on the next restart.
Confirm or roll back
The new build must check in after boot. If it does not, the bootloader returns to the previous image.
Staged rollout
Releases go to a pilot group first, then widen once the pilot has reported clean for a defined period.
Version visibility
The platform knows which build every device runs, so your elevators are never in an unknown state.
Why this matters commercially
Adding a new controller family to your existing elevators becomes a release rather than a rollout. The same mechanism carries improved fault tables and tuning to units installed years earlier, which is what keeps an installed base useful instead of frozen at the day it shipped.
FAQ
Firmware questions we get asked.
Because every controller family encodes state differently. One drive publishes a register map over serial, another expresses the same information through relay coils, and a third uses a vendor protocol with no public documentation. Turning any of those into floor position, door state, and a fault reason requires decoding logic written for that controller.
Related
Where this fits.
Bring us the difficult panel.
Firmware written in house is what makes controllers other platforms decline readable here. Tell us what is in your elevators and we will tell you what can be decoded.