Setting Up Otis Elevator Remote Monitoring: 7 Mistakes I Made So You Don't Have To
-
The 7-Step Checklist
-
1. Understand that remote monitoring is not a replacement for the maintenance contract
-
2. Confirm the exact controller firmware versions before the site survey
-
3. Decide who owns the historical data and how long you can keep it
-
4. Plan the network as if it were a piece of life-safety equipment
-
5. Define alert ownership before the system is switched on
-
6. Test the integration with fire service and emergency operation modes
-
7. Get every promised integration and report in writing
-
1. Understand that remote monitoring is not a replacement for the maintenance contract
-
Common Errors I Still See
-
The Bottom Line
I've been handling elevator maintenance contracts for commercial properties for eight years. In that time, I've personally made—and documented—14 significant mistakes on connected elevator projects, totaling roughly $12,000 in wasted budget. This is the checklist I now run through before any Otis elevator remote monitoring install.
Use this if you're a building manager, a facilities director, or a general contractor preparing to put an Otis elevator (or a whole bank of them) on a remote monitoring service. I want to say I've worked with around 40 elevators in the last two years, but don't quote me on that exact number. It doesn't matter whether your site is in Houston, Phoenix, or anywhere else—the same hidden decisions come up.
The 7-Step Checklist
1. Understand that remote monitoring is not a replacement for the maintenance contract
People think adding remote monitoring will automatically improve uptime. Actually, it's the other way around: uptime improves when your maintenance provider has more data to plan visits, not when you replace scheduled maintenance with a dashboard. The monitoring is a notification layer, not a mechanic in a box.
Before you sign an Otis elevator remote monitoring add-on, make sure the existing maintenance plan stays active. If you're using Otis ONE, it's designed to supplement the maintenance agreement. As of January 2025, Otis' public site describes Otis ONE as a connected IoT service that provides real-time equipment insights and prioritized notifications (Source: Otis.com, accessed January 2025). Local code still requires periodic elevator maintenance and inspections; remote data doesn't replace that.
2. Confirm the exact controller firmware versions before the site survey
I once ordered a retrofit kit for a Gen2 unit, assuming all of them had the same controller. Wrong. The controller firmware version changed mid-year, and the monitoring gateway couldn't read the data bus correctly. It took about three weeks—or rather, four with troubleshooting—to sort out the correct interface module.
The fix is simple: send the elevator model, serial number, and current controller firmware version to the Otis team before the site visit. Don't rely on the building's "I think it's a 2018 model." Take a photo of the nameplate and the controller card if you can. It saves days.
3. Decide who owns the historical data and how long you can keep it
The sales sheet won't mention data retention. We had a contract where the standard terms only kept 30 days of operational history. For predictive analytics, that's useless—you need a baseline that covers an entire service cycle. (Note to self: always ask this before signing, not after.)
Now I put a data retention clause in every agreement: we get 24 months of historical data, and the building owner has the right to export raw data in CSV format. If the vendor hesitates, that's a red flag.
4. Plan the network as if it were a piece of life-safety equipment
Remote monitoring is only as good as its connection. We tried to save $45/month by skipping the cellular failover on one site. In Q3 2024, the building's IT policy updated the Wi-Fi password, and we lost remote visibility for two weeks. The elevator itself kept running, but we missed a door fault signature, and the compliance report came back incomplete. That "savings" ended up costing $3,200 in additional manual checks and rework.
Run the gateway on a dedicated network segment—not the public Wi-Fi network used by tenants. If the monitoring vendor offers a cellular backup or a wired connection, take it. The cost is small compared to the cost of blindness.
5. Define alert ownership before the system is switched on
The most frustrating part of connected elevators: the dashboard says "system healthy" because the alerts were sent, but nobody was assigned to act on them. In the first month on one property, 14 fault notifications went to a shared email inbox that nobody read over the weekend. The system did exactly what it was supposed to do. The process around it failed.
Assign a primary and a backup person who can page or escalate an alert. Write it into the building's procedures. Decide now: which alerts require a technician dispatch, and which are just informational. If you don't define that, your team will ignore the alerts, and the monitoring investment is wasted.
6. Test the integration with fire service and emergency operation modes
This is the one that scares me. The monitoring gateway connects to the elevator controller, and if it's set up wrong, it can interfere with safety logic.
We had a false car fire alarm at a Houston site because the monitoring relay wasn't isolated from the fire-service interface. From the outside, it looked like the gateway was fine. The reality: the system passed the pre-install checklist but failed when the elevator went into Phase I emergency recall. The fix took a full day and a lot of red-faced phone calls.
Always test remote monitoring in all elevator operating modes before the vendor walks off the job: normal operation, fire service, inspection, and maintenance control. If the system can't behave differently in each mode, don't flip it live.
7. Get every promised integration and report in writing
We were promised "advanced analytics" on a project, and it turned out to be a weekly PDF with door cycle counts. No API access, no raw data, no integration with the building automation system. The original sales conversation made it sound like the platform could do everything; the service agreement defined a much smaller deliverable.
Write down exactly what you're going to receive: report format, frequency, API endpoints, and whether you can connect the data to your BAS. If the vendor says "we can add that later," get a quote for adding it later—because later means change order.
Common Errors I Still See
- Buying premium monitoring before building the response process. An informed customer knows that a monitoring system is a decision-support tool, not a decision-making tool.
- Assuming the service provider sees the same alerts you do. The manufacturer's monitoring center might not dispatch a technician just because you have an account. It depends on your contract—read it carefully.
- Focusing only on the hardware price. The "free gateway" often comes with a higher monthly service fee. Over a five-year agreement, that can cost more than an upfront purchase. (Surprise, surprise.)
The Bottom Line
I'm not here to talk you out of remote monitoring. I think connected maintenance is the right direction for the industry. But the value comes from the decisions you make before the gateway goes online. Prices and terms change, so verify current service details with your Otis representative—whether that's in Houston, Phoenix, or your city.
Remote monitoring is a decision-support tool, not a decision-making tool.
Use this checklist, and you'll save yourself the $12,000 (and the red-faced phone calls) that paid for mine.