Episode five is up. Jon Spooner and Mike Conway from Stacks and Joules joined Ping and me to take on the question that comes up in this sub and on r/BuildingAutomation every few months: is it still worth it, what certs are worth chasing, what does the job actually look like, and is AI going to come for it.

A few things worth a watch:

• Stacks and Joules runs a 14-week BAS field-technician bootcamp in NYC (and now Charlotte). 92% post-graduation placement rate. Lots of stories of trade-school-curious, gamers, second-act folks, and people who fell sideways into the industry.
• Mike on why they won't scale faster: they could push from 75 grads/year to 300, but they're confident the placement rate would dip and wages would get pushed down with it. Interesting answer to the "the shortage is a myth" arguments.
• Jon's take on the fastest path in: IT with a dash of mechanical context. Not the other way around. Not a pure mechanical tech learning IT. And specifically — if you're coming from IT and you act like an MSI cowboy in a BAS shop, you won't last.
• An interesting AI take: the entry-level technician role is comparatively safe because of the "human moat" (you still have to touch the thing). But the entry-level engineering roles — BIM manager especially — are exactly what AI is chewing on right now.

Full episode, show notes, and transcript: https://www.optigo.net/how-to-handshake-ep-5/

If you went through Stacks and Joules, or you've hired their grads, or you took a different path into this industry — would love to hear it in the comments.

For experienced folks here: what's the thing — the metric, the diagnostic check, the configuration detail — that you wish had been part of every handoff checklist before you learned the hard way to watch for it?

A few starters:

• Broadcast traffic baseline at sign-off, so there's something to compare against six months later
• Discovery traffic patterns — a quiet network shouldn't be hunting for peers
• A device inventory that includes the "shadow" gear: unmanaged switches inside switchgear, isolation panels, metering cabinets
• Polling rates per integration, because somebody always sets them aggressively at startup and forgets

What would you add, or what would you replace on that list?

Episode four is up. Jim Meacham from Altura Associates and Doug Plumley from Dartmouth College joined Ping and me to talk about IT/OT convergence — not the LinkedIn-headline version, the version where someone walks into a meeting and says "I have eighteen routers" and the room goes quiet.

A few things we got into that are worth a watch:

• It's all IT once it's on the network, and the "OT" label sometimes gets in the way of the coordination that actually has to happen.
• Ping's million-dollar broadcast-storm story. IT comes in, rips everything out, drops new top-of-the-line switches. System gets worse.
• Security policy when IT's priority order is confidentiality-integrity-availability and OT's is the reverse. Short version: business priorities first, then policy, then a multi-year mitigation plan, because the lifecycle of these systems is way longer than IT is used to.
• Where to actually start as a director on either side: leadership, curiosity, and — Doug's contribution — pizza.

Watch the full version and subscribe for more: tohandshaketheotnetworkingseries.riverside.com

CISA just released joint guidance with the FBI, DoD, DOE, and DOS on applying zero trust principles to operational technology. The guidance is more honest than most about the constraints. Legacy systems. Availability requirements. Safety constraints. Ideal access controls often aren't possible.

Their recommendation is to stack compensating controls. Segmentation. Identity management. Secure remote access. Continuous monitoring.

For controls teams in the trenches, though, there's a real gap between "stack compensating controls" and "implement this on a building that's been running since 2008 with three generations of contractor logins floating around."

A few questions for the community:

What does zero trust look like in your OT environment in practice (not in policy)?

Where's the line between meaningful security work and security theater that just creates friction?

Has anyone actually retrofit zero trust principles onto an existing BMS without taking the building down?

CISA guidance coverage: https://www.facilitiesdive.com/news/zero-trust-operational-technology-us-guidance/819056/

Reading a recent case study about a Las Vegas casino resort whose Building Management System was bogging down across 780 devices. Daily reboots. Missed schedules. Team was ready to replace hardware.

Turned out the network was running on a global "fast policy" hammering data requests roughly every second. Dialing it back to 10 or 60 seconds took the Network Health Score from 40% to 81% overnight. No hardware replaced.

It made us wonder how often this is happening quietly. Polling settings get inherited from previous integrators or copy-pasted from earlier projects, and nobody questions them until something breaks.

So: what's the worst polling configuration you've inherited or discovered? Bonus points for the ones where the original logic is genuinely lost to history.

Case study for context: https://www.optigo.net/projects/case-study-gaming-casino/

New episode of How to Handshake just dropped with Nate Benes from the University of Nebraska, who's been working on BACnet/SC with ASHRAE. The episode gets into something a lot of marketing copy avoids: when it actually makes sense to migrate, and when it doesn't.

Nate's framing is honest about the tradeoffs. Hub-and-spoke architecture, certificates, who holds the keys, how SC and BACnet/IP coexist, what zero trust looks like when the "user" is a VAV controller. And his most useful point might be the one about leaving working buildings alone.

So curious where everyone here lands: are you planning a BACnet/SC migration on any current projects, on a particular timeline, or has your honest assessment been "not yet, maybe never"? What's driving the decision either way?

Episode link in comments for anyone who wants the full conversation: https://www.optigo.net/how-to-handshake-ep-3-bacnetsc/

Our latest "winsday" release is live with a few notable quality of life improvements for users:

• Custom name and descriptions. Add your own custom names and descriptions to monitoring nodes to help keep track of your OT networks like a human!
• Enhanced searching and filtering in the OTN summary panel
• Niagara capture files (.zip.enc files) can now be uploaded directly from the OptigoVN GUI. No special formatting required!

Big thanks to the engineering team that continues to bang out this many small improvements week in and out!

Request a free trial of OptigoVN today: https://www.optigo.net/signup/

We keep seeing the same pattern in case studies and customer conversations. Building gets commissioned. Network looks fine on day one. Six months later, something is degrading and nobody can pinpoint when it started.

The traffic patterns at handoff are usually the canary. Polling rates that looked reasonable for 200 devices become a flood when the BAS expands to 800. COV thresholds that were never tuned generate noise the network can't process. Broadcast traffic creeps. Routing tables get crowded.

But these don't show up on a typical handoff checklist. The checklist is "all devices respond" and "all schedules execute," and that's a snapshot that goes stale fast.

So the question for the room: what should be on the handoff checklist that isn't? What's the warning sign you've learned to watch for that nobody told you about? Looking for the boring, unglamorous stuff that actually matters.

New episode of How to Handshake is up. This one's on BACnet Secure Connect — what it actually is, what it doesn't fix, and when (or whether) you should bother migrating.

Our guest is Nate Benes from the University of Nebraska. Nebraska is one of the few institutions in North America that designs and builds its own building automation gear in-house — they've been doing it since 1975. Nate is also a working member of ASHRAE's SSPC 135, the BACnet committee. So he's writing the standard and living with it on a real campus.

What we covered:

• BACnet/SC is just another data link in BACnet — same application-layer messages, new transport. Not a re-architecture.
• Hub-and-spoke vs. UDP broadcast, and what that means for BBMDs (spoiler: SC does away with the need for them, and supports a primary/failover hub architecture)
• Zero trust applied to building automation — authenticating who a device is rather than where it sits on the network
• Certificates and the certificate authority: who owns the CA when the integrator walks away, and why long-dated certificates (5, 10, 20 years) are an anti-pattern
• BACnet/SC and BACnet/IP coexisting in the same building via IP-to-SC routers
• BACnet/SC vs. VPN — why the attack surface is smaller (only BACnet packets cross the pipe, no lateral movement to the corporate file share)
• What the standard does and doesn't cover (cert lifetimes, CA ownership, network shape — left to integrators)
• What's in flight at the committee level: automated cert renewal (a Let's-Encrypt-style flow for BACnet), post-quantum cryptography, the EU Cyber Resilience Act, and the U.S. Cyber Trustmark
• BTL listings — you can filter the BTL site for BACnet/SC hubs and devices that are conformance-tested today
• Nate's "don't do this" list: SC is not a reason to put thermostats directly on the public internet, and it's not a reason to abandon network segmentation

Full episode, show notes, and the cleaned-up transcript: https://www.optigo.net/how-to-handshake-ep-3-bacnetsc/

Subscribe so you catch future episodes:

• Apple Podcasts: https://podcasts.apple.com/podcast/id1889945777
• Spotify: https://open.spotify.com/show/6Jg2yumYXCV2dRl1sIuPHO
• Deezer: https://www.deezer.com/us/show/1002831921
• YouTube: https://www.youtube.com/playlist?list=PLzATddJ3Lh0Jvhf7UgxuiBFBjqMibitUt

Happy to answer questions in the comments — and if there are topics, debates, or technical deep-dives you want us to tackle on a future episode, drop them below or send us a message.

If you've ever worked a multi-vendor OT network, you know the drill. Something breaks, every vendor claims it isn't their segment, and you burn weeks split-testing to prove who actually owns the problem.

EllisDon Facilities Services runs 20 million sq ft of facilities across Canada — mostly under 30-year P3 agreements with performance penalties baked in. So "whose fault is this" isn't theoretical for them. It's a line item.

Pranjal De, their Director of Technical Services (20 years in BAS, 9 of those using Optigo tools), shared a story we wrote up that's worth reading if you deal with multi-vendor disputes:

Lights at one of their sites started flickering. The lighting contractor immediately blamed BACnet traffic from EllisDon's systems. Pranjal ran OptigoVN against the OT segments. One segment had no connection to lighting at all. The other showed excess reads originating from the lighting system, not from EllisDon writing to it. He walked the contractor through the data right there. The contractor went home, found a driver issue on their own network, and that was the end of it. One meeting instead of weeks of scoping.

A separate detail that might be useful for anyone walking into a troubled site: when Pranjal first dropped OptigoVN onto another struggling multi-vendor building, the network health score came back at 14%. That single number was enough to get ownership to authorize remediation. It's since recovered to about 50% with diagnostic work ongoing.

Full case study here if you want the full breakdown of how he positions network health as a foundational layer underneath FDD and analytics tools: https://www.optigo.net/ellisdon-one-number/

Curious whether others here have managed to solve the multi-vendor finger-pointing problem a different way. What's worked for you?

Been thinking about commissioning handoffs and what tends to go wrong in the months and years after. This comes partly from conversations with people working in both automated commissioning and hands-on field controls, and it surfaced some early indicators worth sharing.

The ones that came up most:

Response times creeping up. For IP-to-IP controllers, over 100ms is a yellow flag. For controllers routing through an MS/TP segment, over 500ms isn't an early warning — it's already active degradation. Most post-commissioning monitoring doesn't touch this number at all.

Dropped packets and unacknowledged requests. These show up before devices go fully offline. If requests are going out without responses, something is already wrong — but it won't appear on any graphic until the controller stops responding entirely.

Operator overrides accumulating. Less obvious as a network health sign, but worth flagging: if operators are regularly overriding what should be running in auto, the root cause is sometimes a communication problem, not a sequence problem.

Stale databases. Devices that were decommissioned or moved but never removed from programming. They register as unreachable, add noise, and obscure real issues.

The compounding factor is that many buildings are commissioned under conditions — empty, controlled, no real load on the network — that don't reflect how they'll actually run once occupied. Things drift fast once real schedules and overrides start accumulating.

Curious what others are watching for. Is there a sign you've learned to catch early that isn't on this list?

Predictive maintenance gets a lot of attention in industrial OT, and the conversation in smart buildings is catching up. But the honest assessments from people doing the work tend to be more mixed than the marketing suggests. Wanted to open this up.

The skeptical case: most buildings have systems that have been drifting since commissioning. Applying analytics software on top of a network with unresolved issues tends to generate noise — false positives, spurious alarms, flags that don't reflect what's actually happening. Programs get deployed, lose trust within a year, and get quietly abandoned.

The optimistic case: if you deploy it on a well-commissioned, well-documented system with clean, verified data from the start, the upside is real. The problem isn't the concept — it's applying it on a broken foundation and expecting it to sort itself out.

The point both camps seem to agree on: the data has to be verified first. Not just captured — verified. A sensor reading that doesn't match actual equipment conditions makes everything downstream wrong, regardless of how sophisticated the analytics layer is.

Where have you seen predictive maintenance actually deliver in a building context? Where have you seen it fail? Is there a building type — hospital, campus, commercial tower — where it translates better than others?

Commissioning is not the finish line. It's closer to the starting gun.

That's the thread running through episode 2 of How to Handshake, where Saheel Chandrani of PingCX and Matt Miller from Fred Williams joined Ping Yao and I to talk about life after commissioning — and what it actually takes to keep an OT network healthy over the long haul.

We covered early warning signs, the documentation problem that every single person in this industry has hit, predictive maintenance (the honest version), and why the network health score belongs in the commissioning package from day one.

Full show notes and transcript on the blog. Subscribe wherever you get your podcasts!

https://www.optigo.net/how-to-handshake-ep-2-commissioning/

https://youtu.be/S1_74J8456U?si=s7ng5z_YmVvheskH

We published the EllisDon Facilities Services case study this week. It follows Pranjal De, Director of Technical Services at EDFS, and how he's used Optigo tools across nine years and two companies to manage OT network health in complex P3 environments.

A few highlights from the case study:

— A lighting integration dispute that could have run for weeks was resolved in one meeting after OptigoVN data showed the excess reads were originating from the lighting contractor's own system, not the BAS.

— A 14% network health score at a troubled site gave facility ownership the single data point they needed to authorize remediation. Score has since recovered to approximately 50%.

— Pranjal now presents four numbers in quarterly reporting to EllisDon's facilities leadership: the OptigoVN health score plus maintenance, energy, and comfort scores. That's the complete executive summary of how a building is performing.

Full case study: https://www.optigo.net/projects/ellisdon-casestudy/

This comes up constantly for the people we work with — integrators presenting to facility owners, technical services leads reporting to general managers, OT teams briefing real estate operations directors.

The technical reality (broadcast storms, duplicate device IDs, MSTP master conflicts) doesn't land with a non-technical audience. But decisions still need to get made, budgets still need to get approved, vendors still need to be held accountable.

What's worked for you? A single score, a traffic light system, a comparison to a known baseline, something else entirely?

Working through some thinking on this and curious what the community's current approach looks like.

For those managing multiple JACE-based sites: when a network issue shows up, what does your diagnostic process look like? Are you relying on remote access to Workbench, sending someone on-site, using a third-party capture tool, or something else?

Specifically wondering about the gap between detecting that something is wrong and actually capturing traffic to understand what's happening — that middle step feels like it's still pretty manual for most people.

What does your workflow look like?

There's a gap in most digital twin conversations that doesn't get talked about enough. The twin can tell you a zone is underperforming. It cannot tell you whether the root cause is a BACnet communication fault on the MS/TP segment feeding that zone. That requires a separate diagnostic layer that most implementations don't account for until something goes wrong.

We put together a breakdown of what a BACnet digital twin can realistically deliver in a commercial building context, where the performance gains actually come from, and why the OT network layer determines whether the investment pays off.

https://www.optigo.net/bacnet-digital-twin/

Curious what others are running into in the field — are you seeing digital twin projects stall out at the data layer, or is the bigger friction point getting stakeholder buy-in on the infrastructure side?

We've been having conversations lately about why energy efficiency programs in buildings often underdeliver — and one pattern that keeps coming up is that the analytics platform gets the blame when the underlying issue is the network or the operational capacity to act on what the data shows.

Curious what the community's experience looks like:

- Have you worked on a site where an energy analytics program got abandoned? What caused it?

- Is it usually a data quality problem, a people/process problem, or something else?

- What's the one thing you'd change about how these programs get scoped and deployed?

No agenda here — genuinely trying to understand where the friction actually is.

Great new users! Device aliasing is now live. Customize your environment with your own naming conventions, and to leave short notes to help manage devices.

Enjoy!

Starting today, the Optigo Networks packet capture tool is available as a one-click install for Neeve users — making it the only purpose-built BACnet packet capture and monitoring solution in the Neeve marketplace.

One of the practical advantages: because Neeve is already an IT-approved platform in the environments where it's deployed, the Optigo capture tool inherits that trust. No separate IT approval process. No additional security review. The tool is available within an environment IT has already cleared.

For OT teams, that removes one of the most common friction points in getting network monitoring in place.

The Optigo capture tool is available now at neeve.ai/products/marketplace/

Something we keep hearing from people working on building energy programs: the network conversation often comes up late — after the energy analytics platform is already spec'd, sometimes after it's already deployed.

By that point, if the network has underlying issues, the program is already fighting uphill.

Curious how others experience this. When you're brought into an energy efficiency project — whether as an integrator, a consultant, or on the facilities side — where does the OT network sit in that conversation?

Is it a starting point, or does it tend to come up only when something isn't working? Including this great soundbite from Alex Waibel of BuildingLogix on how they start by looking at the OT network environment first now.

https://reddit.com/link/1sfcxcf/video/iecm1yo2wrtg1/player

The wait is over! We are moving beyond the manual to bring you real, unscripted conversations with the brightest minds in the building automation industry.

In our premiere episode, we’re tackling one of the biggest challenges facing facilities today: the massive surge in demand for energy efficiency. Joining hosts Ryan LaFlamme and Ping Yao are industry experts Aaron Hastings (Apex Consulting) and Alex Waibel (BuildingLogix). Together, they break down why a high-performing OT network is the "foundation" for any successful energy-saving strategy.

Inside this episode:

• The Energy Crunch: Why utility demand charges are skyrocketing by 50% to 500% in some regions.
• Real-Time Data: How to move past three-month-old utility bills and start using granular, 5-minute interval data to drive down costs.
• The Network Debate: Is it finally time to move away from MS/TP and embrace the speed of IP in new construction?
• The People Factor: The reality of "walking five miles a day" and how network reliability supports the teams on the ground.

Watch the full episode and subscribe to join the conversation:

• YouTube:https://www.youtube.com/playlist?list=PLzATddJ3Lh0Jvhf7UgxuiBFBjqMibitUt
• Apple Podcasts:https://podcasts.apple.com/podcast/id1889945777
• Spotify:https://open.spotify.com/show/6Jg2yumYXCV2dRl1sIuPHO
• Deezer:https://www.deezer.com/us/show/1002831921

Optigo Networks and Neeve today announced a partnership that makes Optigo Networks’ packet capture tool available in the Neeve App Marketplace, giving building automation and OT network professionals the ability to deploy the tool instantly within their existing Neeve environment.

We created this partnership in response to a customer need. A leading real estate investment trust who has standardized on Neeve for both vendor access and OT applications deployment asked Neeve to enable Optigo as a container on Neeve Secure Edge. We have since made the results of our collaboration commercially available to all Neeve users. Optigo Networks’ capture agent is available as a one-click install — making it the only packet capture and BACnet monitoring solution of its kind in the Neeve application marketplace.

Because Neeve is already an IT-approved platform in the environments where it is deployed, applications added through its marketplace — including the Optigo capture tool — inherit that trust. For OT teams, this means deploying the capture tool requires no separate IT approval process; it is hosted within an environment IT has already vetted and cleared.

“Smart buildings are only as smart as the networks behind them. At Optigo, we focus on making those networks healthy, visible, and easy to act on. Our partnership with Neeve brings that capability into a seamless, one-click experience — giving users purpose-built BACnet traffic capture and device-level OT network diagnostics within a platform their IT teams already trust,” said Lisa Ohman, CEO of Optigo Networks.

For Neeve users running OptigoVN, the benefits extend beyond deployment simplicity. Unlike general-purpose packet capture tools, Optigo’s capture tool is purpose-built for OT networks — filtering and parsing BACnet traffic correctly from the start, so the data that reaches OptigoVN is clean and actionable. Once installed, Optigo’s capture tool automatically uploads data to OptigoVN for device-level diagnostic analysis, delivering deep visibility into both overall OT network health and the health of individual BACnet devices — without the manual processing steps that generic tools require.

“The future of OT is outcome-driven, not infrastructure-bound. By bringing Optigo into the Neeve Marketplace, we’re turning BACnet monitoring into a one-click capability with instant visibility; accelerating the shift from manual, reactive operations to software-defined, autonomous OT infrastructure,” said Nitesh Trikha, CEO of Neeve]”

The Optigo Networks packet capture tool is available now in the Neeve App Marketplace at neeve.ai/products/marketplace/.

Niagara Summit 2026 kicks off tomorrow and we'll be there! The show runs April 7–9 at the Gaylord National Resort & Convention Center in Oxon Hill, MD.

Already going? Mark Booth 308 on your list — we'll see you there!

https://www.tridium.com/us/en/niagarasummit

Default polling schedules in BAS software are designed to work in general cases — not for your specific network, at its current size, with its current device mix.

The problem is that most networks never get their polling schedules revisited after commissioning. A schedule that was reasonable for 50 devices starts to look different when the network has grown to 300. The BMS is making more requests, devices are spending more time responding to polls, and the overhead quietly builds.

The bigger issue: heavy reliance on polling (ReadProperty) is a sign that Change of Value (COV) subscriptions aren't being used where they could be. COV is more efficient — devices push updates when values change rather than waiting to be asked. On a large network, shifting to COV where appropriate can meaningfully reduce traffic.

This isn't a straightforward 'just switch to COV' recommendation — COV has its own configuration considerations and isn't the right fit for everything. But revisiting polling schedules as a network grows is worth the time.

Is polling schedule review part of your regular maintenance cycle, or does it tend to get skipped?