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!
Predictive Maintenance: Real Tool or Marketing du Jour?
The pitch on advanced analytics and predictive maintenance is that the data was there all along — we just weren’t listening to it. But how true is that, really? Can the building automation systems most buildings have today actually predict what’s about to break? And can the OT networks underneath them handle the analytics layers vendors keep selling on top?
In episode six, we’re joined by Justin Carter, Controls Technologist at ENFRA, and Rudy Bohince, Center Director of Managed Services at Albireo Energy, to cut through the buzzwords on predictive maintenance, advanced analytics, and the role AI is actually playing on the OT network today.
What’s the real difference between predictive, proactive, and preventative — and how much of it is vendor fluff? How clean does your data need to be before any of this earns its keep? What are the red flags when an analytics vendor is pitching you, and is AI ready to run the show without a human in the loop? Spoiler: not yet.
Sitting in the co-host seat this week is Optigo’s Chief Growth Officer, John Attala, filling in for Ping.
What we covered:
- Predictive vs. proactive maintenance
- What advanced analytics is actually good at catching today
- The dirty data problem
- Justin’s three verticalities before analytics can do anything useful
- Why network performance gets more critical as analytics layers pile on
- The honest AI answer: No Skynet today
- How to evaluate vendors
Transcript:
Ryan LaFlamme: The promise of advanced analytics and predictive maintenance is that the data was there all along — we just weren’t listening to it. But how true is that, really? Can the systems most buildings have today actually predict what’s about to break? In this episode, I’m joined by Justin Carter of ENFRA and Rudy Bohince from Albireo Energy to dig into what predictive maintenance actually means, what data you need to make it work, and whether the OT networks running our buildings can even handle the analytic layers being sold on top of them. I’m Ryan LaFlamme, and this is How to Handshake, Episode Six.
Ryan LaFlamme: Welcome to the episode. It’s me again, Ryan, and sitting in the co-host seat this week is our Chief Growth Officer, John Attala, filling in for Ping, who is currently in California. Joining us as well, Rudy Bohince from Albireo Energy. Rudy, tell people what you do there.
Rudy Bohince: Sure, I appreciate you having me on. At Albireo, I lead our managed services center, which handles our intelligence services and smart building services. Beyond is our alarming platform — we do simple building analytics and some cloud hosting, all on top of our building automation and data center divisions.
Ryan LaFlamme: And I think we have Justin — perfect timing. We were just jumping into introductions, Justin. I’ll send it right back to you.
Justin Carter: I’m Justin Carter. I work for ENFRA. I’m one of their controls technologists, based out of our Fayetteville, Arkansas location.
Ryan LaFlamme: Perfect. We’re here today to talk about predictive maintenance. Preventative maintenance, predictive maintenance — they have a lot of different terms, a lot of different marketing terms. Let’s jump right in. What do we mean by predictive maintenance? How is it different — if it’s different at all — from what people are calling proactive maintenance? Because sometimes these terms get used pretty interchangeably. Rudy, start us off.
Rudy Bohince: We’ve heard a lot of them used interchangeably. Some of it is marketing fluff, I’ll call it. There’s a lot of that buzzworthy type stuff out there. The big thing is where the action meets the road. I always look at predictive as using your historical data to predict the future. I’ve had this many air handlers in my building, and three of them failed after 5,000 run hours, whatever it may be. So when I get to my next air handler, chances are I’m going to get there — and I want to do maintenance before that happens. That’s where I draw the line on the nuance: predictive is using historical data to predict the future. Proactive is less about that data and more like an oil change in your car. I change my oil every 5,000 miles because somebody told me to once. That’s proactive — not really based on data that’s constantly changing, just based on runtime. Justin, is that along your lines of thought?
Justin Carter: Yeah, definitely. To take it a step further — the predictive piece is the big organization that says, “I spent $2 million to deploy this predicting algorithm, AI, whatever you want to call it.” But they’re not changing their culture. It tells them the chilled water valve actuator has an issue, and they’re not calling someone to come fix it. They’re not using internal staff to fix it. So now you’re predictive, but you’re not proactive. That’s a little bit of what I’ve actually seen in the real world. It’s a shame to watch some customers say, “Man, we did the program and we just never did anything with it.” The proactive part is changing your culture. The predictive is great, but it’s nothing without the proactive.
Ryan LaFlamme: I love that. To expand on it — and maybe be a stickler for words — to me, “proactive” implies intention. I want to be better about how I’m doing the same job I’ve been doing for years. Therefore, I’ll use the predictive analytics, the tools at my disposal, to allow me to do that. But you’re absolutely right — predictive analytics without proactivity is pretty useless. That’s a great segue. Predictive analytics, advanced analytics — again, vendor marketing du jour. What does advanced analytics actually look like, as opposed to regular data and regular traffic? How is it different from the trend graphs and dashboards operators have been using for years?
Justin Carter: If we approach a site and they say they have analytics — or they feel like they have advanced analytics — and I go on there and it’s something the incumbent controls contractor put in, it’s histories, trends, and nice dashboards. You get a little bit of that. But if you go to market and look at the actual advanced analytics community, typically what you’ll see in their products is: this is the issue, this is how much it’s costing you, here’s a priority list. This one’s compliance-based. This one’s cost-based. Say if you have a hospital — “This one might not be costing you money, but your OR is out of compliance. It’s above 60% relative humidity.” That’s where my head goes when you say advanced analytics. Every client is a little different — a Class A office building isn’t going to care about certain things — but that’s where I see people sometimes say they’re doing advanced analytics and I’m like, “Oh, that’s just a history or trend chart.”
Rudy Bohince: To your point, Justin — the biggest one is what are you doing with that data? You could have all the advanced analytics behind it, but having an operator be able to see what’s going on and easily understand it is kind of what makes it advanced. Our job on the analytics side, and the controls provider side, is to make it as simple as possible to take action on that data. You can run whatever AI models in the background to make it advanced, but if it’s not directive for that client, it doesn’t matter. Hospital versus commercial office building — they’re not all the same. If you don’t have it customized to them and their needs, you can do whatever you want, and it won’t make a bit of difference. Boil it down into something simple that you can take action on, that you can easily see, and then prove that you fixed something. That’s what makes this stuff more advanced.
Ryan LaFlamme: What problems are these tools really good at catching, and what are they still missing? This could be your wish list.
Justin Carter: You’re catching some simpler stuff for sure. Things like a damper goes open and the airflow doesn’t go up — or it goes down. “Okay, actuator flipped on polarity, or the PI loops backwards.” It did the opposite of what I expected. Some of that simpler stuff has been catchable for over a decade and it works pretty well now. We do some advanced chiller analytics where we’ve found things the chiller companies weren’t finding with their techs on site. We’re able to look at pressures in the chiller and ask, “Does this make sense for that given refrigerant?” That’s some of the more advanced stuff — and sometimes even we’re not great at it. We have partners, we all look at the data, and it takes a minute. There’s definitely a threshold. I don’t know exactly where it is, but simple airside and waterside stuff — the market’s got that pretty well.
Rudy Bohince: Where it really gets advanced is when you start comparing equipment performance versus rated and published performance. Taking all that data out of a building and comparing one piece to another by equipment type. Like Justin said, equipment running after hours, holiday scheduling, damper stuff — that’s all been baked in for a while. That’s your retro-commissioning scope. Then it’s a matter of looking at real-world performance versus typical published performance. I’ve got 15 pumps in a system — why is this one operating differently from the others, and why does that only happen at certain flow rates? That’s where you’re getting into some of the more advanced stuff. But that requires somebody to look at it and have an understanding of the building and its history.
Ryan LaFlamme: Everybody’s hinting at the idea that what makes things more advanced is bringing in larger context. John, I’m curious — we have a very different experience on the software side. What would we consider the advanced side of our analytics versus the core?
John Attala: Our analytics are very different from what you might get out of a tool like Wireshark, where it’s all just there on a page. We’re talking about going from looking at hundreds of thousands of packets in a dashboard to getting needle-in-the-haystack information at your fingertips. It’s pretty game-changing in that respect. There are things it may not do as well as you’d like, particularly for MS/TP — when you get down to the physical wiring level and electrical signals, that’s just something you can’t get out of the zeros and ones of the packets. But hopefully that’s going away with BACnet/SC and BACnet/IP migrations.
Ryan LaFlamme: Predictive models are pretty heavily involved in this, and they need data to learn from. When we look at building systems specifically, what types of historical data — from the network and from the controllers — are actually useful for a predictive model? For people at home trying to set this up at their organization, how far back should they be holding on to this data?
Rudy Bohince: We’ve had customers with old legacy systems and legacy servers that have had data for 15 years, just because they had it. They didn’t really have a use case for it — they didn’t know what they were going to do with it until later. If you already have data — primarily building automation data — keep your trends on everything, because you never know. The industry is changing so much that more and more data is becoming available, and you don’t know what you’re going to do with some of it. You may as well keep it. It’s almost an insurance policy, and that way you can learn from your past.
That said, most of the data we deal with is pretty dirty. There aren’t many naming conventions. Space temperatures have five different names depending on who programmed it and what manufacturer. You don’t need to clean up all of that data to make it useful. Take it one step at a time. Figure out what you’re going to do with it, and then invest your time to clean that data before you try to boil the ocean. There’s a ton of information out there, and you can get really hung up trying to do the right data modeling on a small set of data points that has almost no ROI. Keep all the data you can cost-effectively, then figure out what you want to do with it, focus on cleaning that subset, show the results, and chip away at it. That’s what we’ve seen be successful.
Ryan LaFlamme: Justin — as it relates to network data specifically, is there value in historical data, or is it more “what have you done for me lately”? Do we really just care that the network is in optimal shape today, and what happened yesterday is a matter of fact to look back on when needed?
Justin Carter: If you’re talking about HVAC energy data, consistency is more key than length. You need seasonal data — summer, winter, the shoulder months. Networks are a little different, because they probably don’t change much based on season unless you’ve got equipment outside. Network is typically more about what’s going on right now. Is someone touching the network? Did you add 18 BACnet devices? Why is it all duplicated? It’s definitely more “what have you done for me lately.” You wouldn’t need a whole lot of data — probably the last three weeks. “You’ve been acting like this, and I see all these devices, and then all of a sudden something’s different.” For HVAC data, that range can be very different, because there’s a lot more going on.
Ryan LaFlamme: Rudy, I want to circle back to dirty data. We hear about it a lot. One of the keys to making an analytics program work is having underlying data that’s in good shape — point names, complete trends, timestamps. How much cleaning and tagging does a typical building need before it’s ready to be layered with predictive software? And for people organizing this at an SI or a facilities team — who gets the ticket?
Rudy Bohince: I kind of sit in managed services. We do both the analytics side and a lot of BAS support, so we get both ends of the spectrum. Sometimes we’re the SI doing the tagging, sometimes we’re the data analytics provider. We’ve always approached it from the analytics side — we’ll clean the data within our analytics platform, because we know what happens in the facilities isn’t going to change. They still want their zone temp called zone temp — whether we want it called “space” doesn’t matter, because they need to use it on a daily basis. We found it more economical to do it in our analytics platform, because that’s where we have more control, and it’s the least impactful to the building operators using it.
It can be quite a lot. We tag by equipment type and data type and go through a standard. We also focus on what we’re trying to get out of the program. We have some internal commissioning checks we run for data integrity. I’ve got a VAV box — I’m expecting 15 points out of it. How many do I actually have? How many fit the spec from a tagging model? How many history points do I have? Is that what I’m expecting? Do I have big gaps in data? Do I have sensors that aren’t changing?
That’s the other problem — you’ve got operators involved. They go in to do maintenance, they have a hot or cold call, they override something. Sometimes those overrides stay. Sometimes they remember to remove them when the event is over. If you’re trying to make a regular trend curve of “this is what I expected it to look like,” and all of a sudden it flatlined for three days, that makes it real tough to do any sort of historical analytics or plug it into an AI engine. We try to look at all that as part of a data integrity effort when we onboard a project, and factor it into the analytics rules.
John Attala: Rudy, you just touched on something interesting. What we’ve found a lot at Optigo is that there’s a real focus on data integrity from the SI or the building owner who’s deploying these technologies, but we always like to relate that back to the network comms issues we see. For example, if you have a BAS technician who, on a bad day, programs the same device instance ID into two VAV controllers — now you’re pulling that data into your software, and it’s probably pulling the wrong data half the time. Those systems are making assumptions or running FDD rules on completely flawed data. That serves as a good reminder for folks deploying these products: you don’t want to have one without the other. You really want proper network performance and device addressing — and all that core stuff — before or at the same time as you’re deploying these tools. Otherwise, who knows whether you’re operating under good assumptions to begin with.
Ryan LaFlamme: When we record these podcasts, if I’m not careful to give everything a proper name, and a few weeks down the road I need to come back and make edits — if everything is called “take one,” it’s the same problem. Justin, I saw you nodding through that.
Justin Carter: We call the offering monitoring-based commissioning, and we have a team that does the data part. There are kind of three verticals here. First — I’ve got a connection, and it’s stable. No duplicate BACnet IDs, blah blah. Second — a team comes in and does the tagging. You can use Haystack, or whatever the product we use happens to use. Third — the team that actually gets to have the fun and do the analytics. The prerequisite for them to even see it in our analytics product is that it has to have a stable connection first. We’re using Optigo to make sure the BACnet scores are good, among other things, before we even give it to the site-build team. Then if the site’s not built right — if you haven’t checked that air handler 2 serves these 15 VAVs — it doesn’t make it to the team trying to do the analytics and get an issues log in front of an owner. I don’t think I’m giving away any secrets there. If you’re not at least doing those three verticals, you’re going to have a tough time.
Rudy Bohince: Exactly right. Understanding your network is the first step. We’ve used Visual BACnet in the past, and we won’t touch a job until it gets to a certain score. Otherwise, you can’t trust anything, and you’re throwing good money after bad. I’ve gone into analytics customers and they say, “I know I have a hole in the wall — I don’t need to pay you to tell me that.” It’s like, no, you don’t. Fix your foundation, and then you can really do the fun stuff.
Ryan LaFlamme: Stop me if this sounds wrong — coming from a previous role on the IT side, one of the things you hear a lot about in the last few years is edge analytics. The idea of doing the data crunching where the data is coming in, rather than shoveling it all into one central computer. You don’t hear about it a lot in OT networking and smart buildings. A lot of the OT networks we deal with run older, low-powered hardware that may not have the horsepower for meaningful compute at the edge. From your experiences in the field, how real is that constraint? And what does a path forward look like? Is it rip and replace? Piecemeal upgrades? Or just pushing the analytics somewhere else entirely?
Rudy Bohince: We haven’t seen a whole lot of analytics on the edge yet. The closest we get is the supervisory level within a building, or up in the cloud. We’re not seeing analytics on a chiller, on a VAV box, or any of those controllers. Where we are seeing the edge come into play is trends — rather than always looking at BACnet COV, we’re sometimes looking at the trend value, because then we get that trend collection on the edge. If we lose a network connection or a port shuts down, the data keeps collecting at the edge, and when the connection is reestablished, it transfers up to the supervisor and the analytics engine. We do localized trends there, and we’ll do extended trending — long-term trends — either in the supervisor or in a SQL database, and pull those into the analytics engine.
In the future, you’ll start seeing more compute power at the edge. Different OEMs — chiller manufacturers, air handlers, VRF — are going to start packaging their analytics locally. Then the role of an analytics provider changes. If they know their chillers best, let them analyze that. We can factor it in and apply what they’re finding to the rest of the building, because it all cascades down. That’s where edge analytics ties into the supervisor — and then you’ve got to have somebody make sense of it all.
John Attala: I don’t have much experience with analytics at the edge. Everything we get is captured from somewhere on the network. Rudy gave a really excellent answer. It’s interesting where this is going to go. Semi-related — I was at the Niagara conference a couple of months ago talking to a gentleman about network performance, and I asked, “Why would you not want to investigate a tool like Optigo for your company?” The answer was pretty surprising. It was, “Well, we only use IP networks now. We only build out IP networks, so we’re not using MS/TP anymore — we wouldn’t have any of the slowness or bottlenecks your product can fix.” I hope that’s not indicative of how the larger industry is thinking, because BACnet/IP does not mean lack of broadcast or lack of congestion in a network. It just means it can go faster and hit harder when it does happen.
Rudy Bohince: As you add more analytics and people use the data more — trying to get building automation data and electrical meter data into the rest of their building platforms, into Power BI, into Grafana — network performance is going to become more important, because you’ll have more systems and more people getting into this data. A lot of what we’ve seen has been either a serial connection into the BAS or BACnet polling, and whether it’s IP or MS/TP, that’ll slow everything down. As analytics change, as it goes to the edge and back up, we’ve got to catch up with the rest of the IT world. Network performance is going to become more critical, not less. You layer these things on, and it starts to bog things down. Building operators aren’t going to understand why — they’re just going to get graphics that spin and spin, and data that’s old and stale because it can’t update.
Ryan LaFlamme: As IT/OT convergence continues, OT is being dragged into the larger IT world, and with that comes all the extra overhead — more data, more bandwidth. As Jim from Altura said in a previous episode, it’s easier these days to just say: if it’s on the network, it’s all IT. And we’ve got to start raising the expectations for OT network performance to match IT, if we expect predictive maintenance and advanced analytics to actually run.
Rudy Bohince: We’ve restructured my team around exactly that. As part of our managed services center, we recognized we’ve got system integrators across the country dealing more and more with IT teams, and we don’t generally speak that language. So we’ve hired IT people and brought them up to speed on BACnet, Modbus, and OT networks. We do a lot of heavy network work through my team now because of that interconnection. Justin, have you noticed the same?
Justin Carter: Absolutely. Can you hear me okay? Apologies — IT issue, right? Today I’m sitting here doing it on the phone, because my IT is very secure.
Ryan LaFlamme: You’ve got your OT test lab behind you and we’re troubleshooting IT issues live.
Justin Carter: Yeah. So, the data delivery team I work with — when we sign the big energy-as-a-service contracts and get in front of an IT department, or even for a quick retro-commissioning or monitoring-based commissioning, we recently brought on a guy who’s been doing IT for 20 or 30 years. For the last year, some of my conversations have been, “What is BACnet? What is this, what is that?” And when I bring it into certain IT terms — instead of saying “trends,” you say “logs,” and “the discovery we’re talking about is similar to this kind of TCP thing” — all of a sudden it’s, “Oh, it’s a broadcast message instead of unicast.” It’s like, “Yeah.” Just bringing him in, our IT security reviews have gone so much faster. If you at least have one or two people on your team who can get past the acronym and terminology hell we live in, it’s necessary at this point.
I’m seeing the industry move to IP-based controls too. You want to do more at the edge — not just analytics, but more trending, more everything. The IT/OT convergence is definitely something to keep an eye on. If your teams don’t have someone who can speak a little bit of IT and convert BAS acronyms and terminology to the IT world, you will have a lot of issues. You get the IT/OT people in there, they’re lost for a second, and then once they hit the ground running, they’re like, “Oh man, it’s not that confusing. BACnet is a protocol you’ve got to deal with, Modbus is a protocol you’ve got to deal with sometimes, Lon is still out there a little bit.” It’s not scary. Once you do it a few times, it’s really not.
Ryan LaFlamme: We had Douglas Plumley from Dartmouth College on, and I asked him how he was able to bridge the gap between IT and OT. His answer was pizza parties. Get people in the room, give them some food, and let them talk. It was really getting over that initial nomenclature hump, and it turned out there was a lot more in common than there was different.
Speaking of seeing more advanced things, we have to talk about the 800-pound gorilla in every room — AI and machine learning. Software that learns patterns from data, rather than following the rules you set out, is a pretty big shift for a world that has been so schedule-based and “if then” for so long. Looking specifically at, say, anomaly detection for BACnet/IP — how feasible is the idea of AI running the show? Not just being someone you ask for advice, but actually turning over the decisions? That is the marketing dream: set it and forget it. How feasible is that, what barriers are in the way, and is it even possible — or is this a pipe dream?
John Attala: Should we pause for the groans of our audience?
Ryan LaFlamme: Yeah — give them a second. They’ve now closed the podcast. We’ll give them a second to load it back up. Ladies and gentlemen, thank you for coming back. We are with you.
John Attala: It’s a box you have to check when you do a podcast like this. Otherwise you don’t get through the AI filters to get to the top.
Ryan LaFlamme: Exactly. I acknowledge I will be listening to a conversation about AI at some point in this podcast.
Justin Carter: I remember an article about three weeks ago — one of the AI LLMs was asked to solve some problem, and the way it finally solved it was by deleting the database. That kind of answers it for me. You still need the human component. When the human component is involved — say global commanding, before you do anything like global commanding, most automation systems have it — the human still needs to click the button that sends the zone temperature setpoint to 68 on every box in the whole hospital. It’s almost like you’ve got to firewall certain areas off. If someone really expects it to be fully automated with no human component, they probably need to step away for the next three, five, ten years and come back.
Ryan LaFlamme: No Skynet. Not as of today.
Rudy Bohince: In some cases, we’re still trying to get operators to trust the regular control system and the schedules. Depending on where you’re at, I still deal with operators who want to go outside, feel the wind, and then set their chilled water temperature for the day. It’s baby steps. The other part is the decision-making tree. If you have an issue or a hot/cold call — where’s that decision-making happening? We’re not comfortable there yet from an operational standpoint. It’s a couple of years out, for sure.
John Attala: On the BACnet and network diagnostics piece, AI is going to be an important component going forward, but it can lack operational context. For example, if we’re looking at a campus environment and devices that are offline, the tool may flag that as an anomaly or a problem to be addressed — whereas maybe it’s just wintertime and the chiller has been turned off. That’s a simple context AI could certainly learn, but it’s the kind of thing missing today. It can be improved, but it’ll probably take a couple more years.
Rudy Bohince: That’s a little bit of what I was talking about with data integrity, too. You don’t have normal curves that operate the way you think they should. You might have a sensor that shorts and shows 327 degrees, then goes back down. A meter resets. It’s not clean historical data most of the time. We’re starting to use AI, but in choice areas — usually behind the scenes and in support mechanisms.
Ryan LaFlamme: It’s interesting, because to hear some people talk, it’s almost past what you just said, Rudy. It’s not just “take my historical data and tell me where I should be.” It’s “take the historical data — I’ll see you later. Send me a report at the end of the month.” That’s the gulf between the marketing speak and the reality, where a fuse could go and suddenly it’s making the worst kind of decisions.
I want to move into our second-to-last question. We are a software vendor and we pay attention to a lot of what we do, but we don’t always get to see what everybody else is offering. There are a lot of vendors out there — analytics startups, fault detection — and we’ve been lucky enough to have a few on the show. There are also incumbent BMS providers bolting advanced analytics and predictive modules onto their products. What’s actually delivering value in the market today versus what’s mostly marketing? What’s making you roll your eyes when vendors are contacting you? And what should a building owner zero in on when somebody is talking about advanced analytics?
Justin Carter: Some red flags for me: if you’re getting shown something and it’s only dashboards, and they’re not mentioning at all how they actually connect to your existing systems — not talking about architecture, not asking you what you’ve got — they’re just showing the pretty dashboards. If they’re walking you from point A to point B to point C to point D, not hiding much, and not just sitting behind a pretty GUI, you’re probably onto something.
Rudy Bohince: What Justin hit on is where I was going. Before you’re even evaluating something, you’ve got to look internally and figure out how you’re going to work it into your workflow. That’s the A to B to C that Justin mentioned. If you don’t have somebody using it and owning the results of it, you could buy any system out there. It could be really flashy and cool, you’ll get a lot of reports, you’ll get some nice dashboards, but you won’t make any progress, because nobody owns it. Before you go look at any of the systems out there — and there are a lot of really good ones, and a lot of fluff — figure out how you’re going to use it and who’s going to use it. If you don’t have a dedicated person whose job it’ll be, then when you evaluate the technology, you want to evaluate the support system and the consulting agreement that goes along with it.
I totally agree with Justin that this needs to tie to some sort of work orders. You want to be able to say, “I found this, I assigned it to you or to Building Tech, they fixed it, and this was the result” — rather than, “I got this really cool thing, it’s got AI, I can talk to it, but I don’t actually make any changes.”
Ryan LaFlamme: I really like that piece of advice. Figure out your use case, and don’t be afraid to ask the vendor to answer for it. Say, “This is what I need — can it do it?” Rather than letting them go through their whole demo and show pretty graphics. Can it do A, B, and C for me in my situation?
John Attala: Ryan, I’m going to go off the board for one question.
Ryan LaFlamme: Yes, you can. Spicy questions and spicy answers are encouraged.
John Attala: Here’s something I’ve heard before in the context of Optigo’s solution, and I wonder if it resonates for you guys and how you address it in the market. FDD or analytics — anything that’s finding problems and allowing the owner or service provider to fix them — is there value in these tools beyond, say, the initial one-year deployment? Or are we finding everything in the first year, and then we’re just selling pretty reports in years two and onward?
Justin Carter: For a certain type of project — say an energy-as-a-service contract that’s 20 or 30 years — absolutely. We keep it in there as an insurance policy. I’ll tell you, we’ve got one project that’s maybe on year seven, year eight. In about year four or five, some big BAS upgrade happened, and a broadcast storm started. “Is it your fault detection product?” Nope. It’s this right here. Optigo shows where it started and where it’s going. It’s coming from the BAS server. I’m not going to pick on the vendor, but it’s a vendor we see a lot — they like to be really chatty with BACnet. The conversation went real fast from “Is it ENFRA’s fault detection platform?” to “It happened on March 15th right at 2 PM, the guy had just come back from lunch, and he’d installed another panel.” I could tell you the minute it happened. After that, I got a lot of buy-in internally to make sure some type of BACnet analytics stays installed on new projects.
Rudy Bohince: Buildings are not static. Somebody’s always plugging something in, doing tenant fit-outs, doing upgrades. That causes changes everywhere — on the controllers, on the network. Something’s always changing. Sure, you may have found a lot of stuff in the first year, but that doesn’t mean it hasn’t changed in year two, three, four. It’s your insurance policy, your continuous commissioning agent, your network analyst, all boiled into one — making it easy to find that type of stuff. There’s ongoing value to all of it.
John Attala: I’m glad you guys mentioned those stories. I’m a greedy salesperson, so I’m clearly biased — but you’re right. There are things that happen in the building in year two and beyond. If you’re not using an FDD platform or a network analytics platform, you miss those things. Depending on severity, the building owner will pay for them one way or another. If it’s not for the FDD product lumped into the service agreement, it’s the time and material to get them fixed.
Ryan, we’ve had conversations with people who’ve used OptigoVN and said, “Oh, it was great — fixed all our problems, I’m good now, thanks, bye.” In general, that’s an antiquated way some people operate in our industry, but conversations like these are starting to turn the tide. There’s a beginning of an understanding that continuous monitoring on the network side — and the performance of the BAS beyond what’s built into the BMS itself — is valuable. Or if not directly to the customer, then the service provider is claiming value from it. We know of a service provider with a unique business model where their service delivery is a fixed annual fee — they don’t get paid additional time and material if they have to come outside their contracted bank of hours. You can imagine how darn valuable a product like this is in that scenario.
Ryan LaFlamme: Perfect segue to our final question. It’s easy to talk about this when you have a large company or large budgets, where you have money to burn. But say you’re running a mid-size portfolio — typical mix, HVAC, lighting, access control — and you’re thinking about whether it’s time to jump into analytics software. Is now a good time to start? Wait a few years? Stay with your current approach? Where is this technology earning its keep today, and where is staying with what you have probably better?
Justin Carter: It depends on the amount of risk. Electricity rates aren’t going down. Natural gas rates aren’t going down. It’s about your risk tolerance, and then how much capital you really have. If you don’t have the capital — I heard this when I started in the industry — sometimes people can’t afford to have a building automation system. What that meant was, if you’re not going to install it right, you’re not going to choose a good vendor, you’re going to go low bid, and you’re not going to take care of the sensors once they get five or ten years old and need recalibrating — maybe you can’t afford that system. Same thing for fault detection. There’s a point of entry. If you’re going low bid on everything, and the sales guy is showing you pretty GUIs and isn’t asking you good questions about how it fits your culture and whether it can integrate with your work order system — there are firms out there that can consult and tell you whether you have the capital for this or not.
Rudy Bohince: You do have to do some self-reflection. My earlier example — the customer who said, “I know my dampers are falling off the wall, I can’t do anything about it” — that’s probably not worth the investment in fault detection right now. You’ve got to get your house in order first. Sometimes that’s hard to look internally and recognize. You’ve got to change the culture and get into a maintenance mentality before it’s worth investing in something like this.
Ryan LaFlamme: It’s almost like — can you afford to fix the problems it finds?
Rudy Bohince: Correct. The other part is, this allows you to do more with less. We’re in a gap in the industry where you’ve got a lot of really experienced people and a lot of really young people, and not much in between. Depending on where your staffing is and the size of your portfolio, this can be a good way to bridge that gap — to get those early-career folks up to speed quicker by giving them better information.
John Attala: Justin talked about risk and cost, and those need to be factored in heavily. The other thing to consider: if you’re a building owner who’s happy to get a bill for however many hours of work for your systems, and it’s opaque what was done — keep doing what you’re doing, you’re probably good. If you actually want insight into what’s wrong with the building, the sensors, the controllers, how your energy bills could go down, how to improve the speed of your building automation system — if you want that visibility rather than just paying an opaque bill each month — FDD and analytics are a good time to get in. Visibility breeds accountability. If you don’t have access to these tools and you’re not getting some of this reporting, you really don’t know what’s going on. You’re trusting whoever is doing the work in your building to be honest with you. When you have access to those tools, now you’ve got a level of collaboration with your vendors and a level of visibility and transparency that breeds better work and better outcomes for the building.
Ryan LaFlamme: That is a perfect place to end. Justin and Rudy, thank you so much for joining us. We’ll talk to you again soon.
Rudy Bohince: Thank you, really appreciate it.
Justin Carter: Yeah, thanks. Take care, guys.
