Welcome back to How to Handshake, Optigo Networks’ podcast series on OT networking, building automation, and the conversations that actually move the industry forward.
Subscribe to the podcast on Apple Podcasts, Spotify, Deezer, and YouTube!
Life After Commissioning
In episode two, we’re joined by Saheel Chandrani from PingCx and Matt Miller from Fred Williams (part of Equanz) to dig into what happens after the commissioning team packs up and leaves. For a lot of people in this industry, that’s the moment the real work begins—and the moment most buildings start to drift.
We talk early warning signs, documentation gaps, the case for and against predictive maintenance, and what it would take to make network health a standard commissioning deliverable.
In this episode, we’re tackling:
- Early warning signs: What does a degrading OT network actually look like, and are these signs that people should be catching earlier?
- The commissioning gap: Why buildings are often commissioned under conditions that don’t reflect how they’ll actually be used—and what that means for long-term health.
- Forced recommissioning: Some municipalities are now mandating periodic recommissioning. What cities are doing this, and what does it mean for the industry?
- Predictive maintenance—hype or reality? Our guests give an honest take on where it delivers and where it falls flat.
- Documentation: All three guests agreed: it’s missing almost every single time. Why, and what can be done about it?
- The network health score as a standard deliverable: Ping makes the case for including network benchmarks in the Owner’s Project Requirements document from the start.
Watch the full episode here:
We want to hear from you!
What topics, debates, or technical deep-dives do you think this show needs to cover? Send us a message on LinkedIn, Reddit, or Bluesky, or email us at marketing[at]optigo.net.
Transcript:
Ryan LaFlamme: On this week’s show, Saheel from PingCx and Matt from Fred Williams join Ping and I to talk about life after commissioning—and what it takes to keep an OT network healthy over the long haul. Early warning signs, documentation, and whether predictive maintenance really measures up to the hype. I’m Ryan LaFlamme and this is How to Handshake, Episode Two.
Ryan LaFlamme: I’d like to thank Saheel and Matt for joining Ping and I today. First things first—I’ll give you each a chance to say hello and tell us who you are and who you work for. I’ll start with you, Saheel.
Saheel Chandrani: My name is Saheel Chandrani and I’m the co-founder and CEO of a company called PingCx. We are an autonomous commissioning solution for building automation systems. We’ve been on the market for about two years, though the software has been around a little while longer. I’ve been in the controls world for most of my career—coming up on 20 years in the industry. Thanks for having me.
Matt Miller: Hi, I’m Matt Miller. I am a controls specialist for a MEP group called Fred Williams—it’s a smaller part of a larger company called Equanz. I’m part of a controls startup branch in the Boston area, so I’m doing a lot of sales, or trying to learn how to do sales—which is probably a better way for me to say that. I’ve done controls for about 15 years, but it’s largely been out in the field as a technician. A lot of my experience is in mechanical rooms. Thank you for having me.
Ryan LaFlamme: 100%. And Ping, we know you. Everybody here has got a different perspective: we’ve got the hands-on field side from Matt, and the commissioning automation angle from Saheel. That’s great because our discussion today is about commissioning—and in particular, all of the work that happens after commissioning. We know from a lot of people that this is the point where they kind of drop off. But for a lot of people, including I think everyone around the room here, it’s where a lot of the work just starts.
Let’s go around and talk about early warning signs. This is something that perhaps doesn’t get addressed a lot immediately after commissioning. What are the first indicators that you look for when a network is starting to degrade? Are these obvious signs, or are these things you couldn’t blame people for missing? Matt, let’s start with you, then Ping, then Saheel.
Matt Miller: I think most of them can be somewhat easy to find, though there are degradation things that are harder. What I look for first is facility operator overrides. A lot of times I’ll see something get commissioned, it’s been checked—it should run in auto—and as soon as the contract work or the commissioning is complete, the owner-operators go and override things. If you override a damper, that program and that controller is never doing what it was built and designed to do. So I look for overrides and communication bus health, things like that.
Ping Yao: Of course, we have the benefit of being able to see what’s inside the network—whether using Optigo Visual Networks or a capture file from Wireshark. The two early signs I normally look for are: first, any slowdown. For IP-to-IP controllers, anything over 100 milliseconds is too slow. If you’re going through a router with MS/TP on the other side, anything over 500 milliseconds is not just an early sign—it’s a sign of actual degradation. Second: dropped packets. Requests that don’t have acknowledgments, requests that don’t have responses. That’s a pretty clear one. Below that layer, you start looking at devices that don’t respond at all—what we call unreachable devices in Optigo Visual Networks. That typically means something was changed, decommissioned, or removed, and the database or programming wasn’t updated. After those, you start looking at stale databases. Slow response, dropped packets, overrides, stale data.
Saheel Chandrani: From our perspective, our platform automates a lot of the workflow. Matt is physically articulating devices as he does commissioning. Ping will be the first person to notice slowdowns in communication—did I get the acknowledgment? Is the system responding as quickly as it should? The speed metric Ping shared is very trackable. From our side, we have a timeout period: after a certain amount of time without good communication between devices, we know to pause the exercise and fix the network issue first. Speed concerns, especially while waiting for system feedback, are usually the first sign of trouble for us.
Ryan LaFlamme: How would you distinguish between signs of actual device failure versus misconfiguration or configuration drift?
Ping Yao: Hardware failure is quite rare. In ten years of analyzing networks, I’ve only heard of two cases of actual hardware failure where a network card actually died. The one exception I’d note is equipment installed on something that vibrates—motors, fans. The connectors, the terminal screws, or the cable can cause issues. A resistor can come loose slightly. That can cause noise. But in a new building or after a recent retrofit with new devices, if there’s a problem, my first angle is not device failure—it’s misconfiguration.
Saheel Chandrani: Agree. Hardware failure at the controller level is rare. More likely, new work was added and some additional devices were implemented outside the main scope.
Ryan LaFlamme: Let’s talk about the handoff after commissioning. When you’re giving back a building’s OT after commissioning, what are the first things you want the people receiving it to understand?
Saheel Chandrani: Commissioning is a stage prior to the building being in use. And as soon as people start using the building, they start changing overrides, schedules—things that weren’t in place prior to commissioning. Many times these buildings are empty at commissioning, and then people move in and things don’t operate the way they were designed to. That’s why there’s continuous commissioning. Commissioning is a point in time, and the before and after the physical use of the building is very often extremely different.
Saheel Chandrani: The idea that commissioning begins after a certain point—after substantial completion—is a myth, in my opinion. Many commissioning scope items are done by individual trades. The formal documented commissioning that verifies a deliverable to an end user might be a snapshot in time, but the commissioning process starts right in the design phase. The Owner’s Project Requirements document is the guidebook. None of the activities or scope items of commissioning should be surprises to trades further down the line. Commissioning doesn’t start after the last two bricks have been laid.
Matt Miller: Completely agree with Saheel. Commissioning does start at every individual trade level.
Ryan LaFlamme: Ping, do you think that when commissioning starts as early as possible, that should also include the IT teams who often come in toward the end?
Ping Yao: Great question—it was actually my burning question for Saheel and Matt. To my knowledge, commissioning of OT network communication doesn’t really exist as a formal scope item. Am I correct?
Saheel Chandrani: Commissioning is functionality—it’s adherence to design specifications. The OPR document isn’t a spec document. The spec document lists every finite, quantifiable construction detail. The OPR says: “I intend for this site to work a certain way.” That’s what you’re verifying. I know that so much of a building’s systems are dependent on a high-quality, high-functioning network that without the right infrastructure, you just have a bunch of disparate systems throughout the building doing their own thing. And there isn’t an OPR document I’ve ever seen that says that’s acceptable. The design vision is a building that is orchestrated—that works at least in conjunction with itself. Giving both the IT and the OT networks the right diligence during the commissioning phase is a very important element of the process.
Ping Yao: I would love to see the OPR include even a basic perspective on the network side—the amount of broadcast traffic, the directionality of traffic, the expected response time, the number of IP addresses maximum per subnet. There’s enough IT expertise in the world that we could bring some of it into this document and it would just make our buildings better.
Ryan LaFlamme: How often does forced recommissioning happen? Not continuous commissioning—I’m talking about months or years after a system has drifted, where an owner or even a law mandates a new commissioning stage.
Saheel Chandrani: It does exist, and it’s growing. Certain municipalities and geographies have local laws or policies that dictate periodic recommissioning. Let’s talk specifically about New York City, which is my home city. New York has local laws—Local Law 87 is one of them—that require, among other things, recommissioning of buildings over 25,000 square feet every ten years. And when you apply that rule to the number of buildings that size in New York City, that’s a very large amount of facilities that every ten years must go through a systematic recommissioning. Then you look at cities like Boston, Denver, and Washington DC—these policy-driven requirements for periodic recommissioning are very much there. It’s very achievable. And when you layer on automation solutions, you can take what would be a months-long scope of work and execute it in a couple of days.
Ryan LaFlamme: And that’s a perfect segue to predictive maintenance. We all know predictive maintenance and proactive health are very much the buzzwords right now. It gets a lot of attention in industrial OT contexts—but how much of that translates to smart buildings? Where does it start to show some cracks?
Saheel Chandrani: Predictive maintenance is—I’ll just say it—it’s hype because it takes work to achieve a system that is able to flag true concerns and not just pollute alarms with false alarms. Part of why that chaos gets introduced is that you’re applying predictive maintenance or analytic software to systems that, after a few years, have just naturally drifted and degraded. Applying really intelligent software on top of a system that has naturally drifted, you’re actually going to find a lot of noise. To answer your question: I don’t think it’s hype in the long run. I think there’s real benefit to predictive maintenance. But a thorough recommissioning of the BMS is an important prerequisite. If you were to deploy predictive maintenance directly after construction, your odds of success with that software are so much higher.
Ryan LaFlamme: And after the handoff, who does that responsibility fall to?
Saheel Chandrani: Historically it’s been facilities and engineering. But today’s facilities management team is not just one stakeholder—it includes people from IT, OT, sustainability, finance, and the core business. To that end, system integrators have often inherited a lot of that ongoing responsibility, even informally. What makes the network health score so powerful in that context is that it objectifies the conversation. When it’s time for a service contract renewal, you can say: “When we started the year, we were at X, and we’ve either maintained it or improved it. Here’s what we’ve done.” That subjectivity around “did they show up and actually do something?”—all of that variability goes away when you have a clearly articulated number.
Ping Yao: We say all the time that network health isn’t a commissioning-specific topic or a post-commissioning-specific topic—it’s something that should be observed from the start all the way through. The network is the foundation you rebuild everything on. I would love to see the Optigo health score or its equivalent become part of the standard commissioning deliverable package—not something complex, just: this is the number of packets, this is the response time, this is the health score at handoff. Come back years later and you can see whether it’s drifted by 8% or 300%. That context helps enormously.
Ryan LaFlamme: Let’s talk about documentation. How often do you find that it’s missing, wrong, or was never updated after the initial commissioning?
Saheel Chandrani: That happens 100% of the time. I don’t think it needs more detail than that—and I don’t think it comes from a place of malice. It comes from the speed at which things happen in a building. Look at a large owner: the construction department is different from the facilities department, procurement is trying to achieve its own objectives. Three, five, ten, fifteen years into a building’s operational life, you’ve had scenarios where procurement had their way and brought in trade contractors who brought their own chaos to the building. The lack of documentation hygiene is hard to avoid.
Ping Yao: It’s one of the most common issues we find. When there might be configuration drift, the first question should be “where’s your documentation and have you been keeping up with it?”—and the answer is almost always no. Commissioning gets treated as a trusted snapshot in time, and then it drifts from there. That’s another reason to make the network health score a standard part of the commissioning package—you then have a baseline you can actually reference.
[Matt Miller dropped from the session briefly due to connection issues. He rejoined to answer the final set of questions, which we’ve called: Predictive Maintenance—Reality Check vs. The Hype.]
Ryan LaFlamme: Matt, predictive maintenance gets a lot of attention in industrial OT contexts, but how much of that actually translates into smart buildings? Where does the idea fall apart for you?
Matt Miller: I think it’s in its early stages, but I’m a believer. When I set something up to be optimal, I’m thinking: I want your piece of equipment to run optimally so that you can save money. And for us out in the field, we can also say: if we can commission it and keep it running optimally, you can get incentives from your utility provider. The part where predictive maintenance needs the most work is the data foundation. Step one is having the data and capturing it reliably. And Saheel made the same point—without a high-performing OT network as your base, you can’t even start layering on trending programs or data capture. If you don’t know whether the data is clean or working, you don’t have predictive maintenance. You need not just data, but verified data. If somebody sends me data and I show up and the reading doesn’t match the actual equipment, everything downstream breaks.
Ryan LaFlamme: After commissioning is complete and you’re giving back the building, who is typically responsible for long-term network health? And in your experience, are those people equipped to do it?
Matt Miller: It’s a mixed bag. Technically, the building owner owns it. What they do is hire a building engineer. There are some building engineers who know it very well. But a lot of others say “I know enough, and when I have a problem, I call you.” That’s not a knock on the individual—it’s a very demanding job. What would help is if building owners had training programs to ensure their building engineers understood how to maintain the network at strong quality and how to look at data trends over time. If you read a temperature at 70 degrees for six months and one day it’s 150, that tells you immediately that there’s something wrong with a sensor or a wire. The question is: how quickly can you recognize it, and are you even watching?
Ryan LaFlamme: How do you communicate network health to a facilities director or building owner who doesn’t have the technical background and doesn’t want to get into packet-level diagnostics?
Matt Miller: When I’m on site, I do show them. If something is offline, I mention it right away. But I don’t think there’s enough emphasis on this during the turnover process. When we finish a job and do owners’ training, it’s usually one day—if it’s even a full eight hours—and it’s pretty generic. Here’s your login, here’s what the graphics look like, here’s your air handlers. It’s not enough. The network health score approach—one single number that a facilities director can look at without needing to understand what a packet is—is more effective than anything I can say in an eight-hour walkthrough. They can understand “30 out of 100” even if they can’t read a Wireshark capture.
Ryan LaFlamme: Are there differences in how you approach long-term OT network health in a hospital versus a university campus or a commercial tower?
Matt Miller: Personally, I think the fundamentals are the same. You do have to stress the importance more depending on the context—a hospital has more critical stakes—but the fundamentals don’t change. Your network needs to be strong and needs to stay that way.
Ryan LaFlamme: Final question: network documentation and its role in long-term health. How often is it missing or never updated after initial commissioning?
Matt Miller: Both Ping and Saheel said “all the time” and those three words were about to come out of my mouth too. Every single time. If I go to a service call at a site I’ve never been to and there is documentation, I would be genuinely surprised. That’s part of why I built my app. When guys retire, that institutional knowledge leaves with them. The app—it’s available at checkpoint-cx.com—is a commissioning tool built from the field up, from a technician’s perspective. I upload a submittal, it extracts all the equipment and point lists, and then I can do point-to-point verification against actual readings with a meter in hand. I’ve also built in step-by-step sequence guides that a junior tech who’s never been on a job alone can follow. It’s togglable—if you know what you’re doing, you turn it off. And I’ve linked out to all relevant trade codes directly in the app. The goal is to make sure no knowledge gets lost just because someone went to a different job site the next morning.
Ryan LaFlamme: That’s all the questions I have. Matt, thank you for taking the time and for making it back. Saheel, thank you so much—and I hope to have you both back. Thanks for joining us on How to Handshake, created by Optigo Networks. You can find us on YouTube and at optigo.net. Tune in in two weeks for the next episode.
