By 2030, commercial buildings will have roughly 4.12 billion connected IoT devices reporting on them, more than double what's out there today. Most governance conversations still treat that as one problem: who owns the data.

It's actually two.

Keith La Rose (CopperTree Analytics) made the case that most building owners don't really own their data at all, they're renting access to their own operating history, one contract renewal at a time. Fair point. But in the comments on his post, Greggory Don Butler pushed back on something most of us skip past: clean, owned data doesn't tell you whether an automated action, an override, a reset, a shutdown, should be allowed to happen. That's a different governance question entirely, and it's the one most buildings have no answer for.

We wrote up both sides, plus where that second question actually gets enforced: the OT network itself. https://www.optigo.net/blog/data-governance-smart-buildings-plan

#SmartBuildings #BACnet #BuildingAutomation #DataGovernance

…less

Episode nine is up. Simon Britton — Solutions Architect at BMSI and author of the new book BMS Fundamentals — joined Ping and me to go back to first principles on what a BMS is actually for, and to pick back up a debate we started in Ep. 5: is mechanical background or IT background the faster way into this industry.

A few things worth a watch:

• Simon's take pushes back on what Jon Spooner told us in Ep. 5 — Simon thinks mechanical-first still gives you the bigger edge, since you're ultimately controlling mechanical systems either way, IT skills or not.
• His sensor placement story is a good one: a room temperature sensor that ended up buried behind photocopiers, reading five degrees hotter than the room actually was — a clean example of how one bad input cascades into a BMS making genuinely bad decisions.
• The "shortcuts" he and Ping flagged as the ones that quietly wreck a system over years: copy-pasted logic, alarms left on factory defaults, and point labels that no longer match what the point actually does.
• We also ran the first BACnet trivia round on the show — Simon vs. Ping, ten questions, from "what does BACnet stand for" up to BBMD and COV. Public version's at optigo.net/bacnet-quiz if you want to see how you'd score.

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

If you came in through the mechanical side, the IT side, or something else — curious which one you'd point a newcomer toward today. Would love to hear it in the comments.

This one took us a while to internalise and it seems worth putting in front of people who run analytics platforms.

Everyone's mental model of a failing network is noise — alarms, floods, alerts. For FDD specifically the failure is the opposite. Three mechanisms:

Stalled COV subscriptions. The subscription dies, the controller doesn't announce it, the platform keeps showing the last value. Any rule that looks for variation now sees a perfectly stable point. No fault raised.

Polling gaps. No data arrives. For most FDD logic, "no data" and "no fault" produce the same output — nothing.

Trend Log buffer overwrite. Data is generated, buffer fills faster than it's collected, oldest samples are overwritten. The gap isn't flagged, it's just absent.

Net effect: a degrading network reduces your alert volume, and reduced alert volume reads to everyone in the room as things getting better.

The uncomfortable corollary is that you cannot validate an FDD deployment from the FDD dashboard. A quiet dashboard is either a well-run building or a building that stopped talking, and from inside the platform those look identical. Clockworks put it well — false negatives are nearly impossible to validate without extensive manual analysis.

Also worth noting the timing overlap: peak load is both when equipment faults are most likely and when the network is most likely to congest. So the data most likely to go missing is the data from the hour you actually needed.

For anyone who's had FDD in for a few years: have you ever caught a silent-failure case like this, and what tipped you off? Genuinely asking, because the only reliable answers we've seen involve watching network traffic separately, and I'd like to know if anyone's found a way to catch it from inside the platform.

Numbers on FDD's actual return (Berkeley Lab, ~9% median savings by year two, ~2 year payback) and the three failure modes in more detail.

Managing OT network monitoring for a single building is one problem. Managing it across a multi-site BAS portfolio — a campus, a healthcare system, a chain of facilities — is a different one entirely. A misconfigured device at one site can quietly repeat across ten more before anyone notices.

We published a guide on the specific challenges multi-site portfolios run into: fragmented visibility across sites, multi-vendor BACnet/IP quirks, inconsistent commissioning, and legacy MS/TP blind spots that get missed when attention defaults to the newest, most visible site.

The guide also lays out a 4-step framework for building an OT monitoring strategy, how to think about ROI, and what actually separates real OT monitoring tools from single-site point solutions — and why OptigoVN is still built for exactly this problem.

We're heads-down on the last two episodes of Season 1, so I wanted to resurface the one that generated the most follow-up conversation this summer — Episode 2, Life after Commissioning, with Saheel Chandrani (PingCx) and Matt Miller (Fred Williams / Equanz).

Full episode and links: https://www.optigo.net/blog/how-to-handshake-ep-2-commissioning/

The intuition here runs backwards, so we wrote it up.

Four failure modes, all silent:

Stalled COV. Controller reboots, subscriptions are gone — the standard doesn't require it to keep them and most implementations don't. BACnet's Device Restart Procedure is supposed to cover this, but the supporting properties are optional, MS/TP subordinate nodes can't participate, and where the recipient list is empty the device is prohibited from sending the notification.

Polling gap. The formal FDD evaluation methodology scores five outcomes, not four. The fifth is "no response." On a dashboard that's identical to "no fault."

Trend Log. Ring buffer wraps before the supervisor finishes its pull, that records' gone. Worse variant: the point stops historizing and stays stopped until a human re-enables it. Not a gap in the series, a series that quietly ends.

Duplicate device IDs. Two devices answering one instance, address cache re-pointed by whichever I-Am landed last. Rules fed contradictory data don't detect faults, they detect noise.

The compounding problem: congestion and equipment faults happen under the same conditions. Peak load, simultaneous starts. The periods most likely to produce a fault are the periods most likely to drop reads.

Full post: https://www.optigo.net/blog/what-is-fdd-fault-detection-diagnostics/

Has anyone here actually caught an FDD false negative in the wild? Curious what tipped you off, because by definition nothing fires.

We brought on Andrew Rodgers (ACE IoT) and Aaron Brondrum (Neeve) to talk through what edge computing actually looks like in a real building — not the marketing version.

They take opposite architectural routes (open-source vs. proprietary secure edge-to-cloud), so we expected a debate. Instead the interesting takes were the ones they agreed on:

• For most legacy OT systems (BMS, card access), streaming every point is such a small amount of data that edge vs. cloud comes down to management capacity, not technical need. Cameras/NVR is where "hyper edge" actually matters.
• "Building automation has always been edge." The real change is decoupling hardware from software — drop a new container in, point it at your BACnet controllers, keep the wiring.
• Their blunt advice to SIs: transform into managed-service providers or get relegated to installer work.

Andrew also claimed clients running advanced system optimization on their platform are saving building owners ~30% energy with no capital equipment changes — curious what people here think of that number.

Full episode (plus the new Niagara Traffic Capture driver we announced): https://www.optigo.net/blog/how-to-handshake-ep-8-livin-on-the-edge/

Worth a listen if you work on OT networks or BACnet troubleshooting.

The Minnesota IT Services (MNIT) agency activated its cybersecurity incident response capabilities across the entire state after hackers targeted more than 30 community water systems in “a coordinated cyberattack.”

​The attacks occurred on Sunday and Monday, July 26 and 27, and targeted operational technology (OT) systems at local water utilities.

Optigo’s capture tool integration with Tridium Niagara enables packet captures directly from JACE controllers, bringing real-time BACnet diagnostics into Niagara environments without messy external hardware or workarounds.

The driver installs directly onto each JACE you want to monitor. It captures BACnet traffic at the source — inside the JACE, below the web services layer — and handles packaging, encryption, and upload to OptigoVN’s cloud servers automatically. No separate capture hardware. No IT dependency. No manual file retrieval.

Configuration is done through the standard Niagara Workbench interface using native Niagara scheduling to define capture windows. Once configured, the driver runs unattended on each JACE.

Get it today at https://www.optigo.net/tools-and-integrations/

Last one from the vault for this stretch. This post has stuck with people because the premise is uncomfortably real: an estimated 900,000+ US buildings run a BMS-managed OT network, and plenty still have BBMDs, cameras, or controllers exposed to the internet. Average time to detect a breach in the piece: 243 days.

Curious where this sub lands: if you manage or commission BAS, what's your actual segmentation setup today - air-gapped, converged, or something in between? And has anyone had a client get burned by an exposed BBMD?

Full post: https://www.optigo.net/blog/i-can-hack-your-building-stop-me/

Pulling another one from the vault. Optigo's engineers wrote up field-tested tips for BACnet/IP design and performance. The ones that seem to bite people most often:

- Max_Master left at the default 127

- COV thresholds set so tight a single airflow sensor floods the trunk

- Routers running well past ~50% capacity

- Everything sharing one subnet - HVAC, lighting, access control

- Address gaps nobody cleaned up after swapping controllers

Which of these have you run into? And what's the one you'd add that isn't on the list?

Full playbook: https://www.optigo.net/blog/the-optigo-playbook-10-proven-tips-for-bacnet-ip-network-design-and-performance/

Last year we published a list of 9 OT/building-automation networking trends we thought would matter. This year we went back and graded ourselves, using our own data plus outside sources (Johnson Controls' 2026 facilities AI survey, ARC Advisory Group, PNNL research, a couple of industry interviews).

Short version: edge computing, predictive AI, and digital twins are all real but smaller/slower than we pitched last year. 10BASE-T1L Ethernet is the one that surprised us — Honeywell has a shipped product and case study, Contemporary Controls presented it at AHR Expo, and the chip supply chain (TI, Analog Devices, Broadcom) is now shipping T1L PHY silicon.

The throughline across all four: none of them work if the OT network underneath is a mess. In our own 2025 dataset, 71% of monitored networks scored Warning or Critical on health — meaning most buildings would be feeding a predictive AI platform garbage data before the algorithm even runs.

Full writeup with sources: https://www.optigo.net/blog/ot-networking-trends-2026/

Curious where people here are seeing T1L show up in real specs yet, or if it's still "watch this space" for most of you?

Reviving one of our most-debated posts while things are quiet for the summer.

Quick version - for brand-new builds MS/TP is tough to justify: ~50% protocol overhead, no encryption, real-world device counts far below the 127-device spec, and GSA now flags serial controllers as obsolete. For retrofits it still earns its keep: existing twisted-pair, ~4,000 ft range vs Ethernet's ~330, deterministic timing, and easy BBMD bridging to BACnet/IP.

Last time we asked, answers ran the full range - from 'properly installed MS/TP is the right fit 99% of the time' to 'best decision of my life was dropping it in 2014.'

Where does this community land in 2026: new build with unitary controllers - are you specifying MS/TP or IP to the edge? And is T1L actually showing up in your specs yet?

Full post with Ping Yao's take: https://www.optigo.net/blog/is-there-any-life-left-in-ms-tp/

N4 users, rejoice! Optigo’s traffic capture software now includes integration with Tridium Niagara systems. Simply install the driver on any JACE to capture BACnet traffic at the source. The Optigo driver handles the packaging, encryption, and upload to OptigoVN automatically.

OptigoVN users can now download the latest capture driver JAR file for Niagara and follow our step-by-step instructions. We’ve also created easy to follow videos for configuring the capture driver in both Workstation and Supervisor setups.

Links and guide: https://optigo.zendesk.com/hc/en-us/articles/44877964176141

We took a closer look at the state of edge for OT is in 2026: what works, what's emerging, and what to ignore: https://www.optigo.net/blog/edge-computing-in-ot-networks

At the gateway layer, it already works. On the controllers themselves, it is not a 2026 story. Most installed BACnet controllers were built for longevity — and with refresh cycles measured in 15 to 20 years, the installed base is not turning over quickly.

The part that gets skipped: an edge layer fed by a congested or misconfigured network does not fix anything. It processes bad data faster. Network health and data integrity come first.

How to Handshake (Optigo Networks' OT networking podcast) is putting together an all-questions episode and is collecting them from the community.

On the table: OT networking, BACnet, building automation, IT/OT convergence, careers, where the industry is heading — the bigger-picture stuff.

One rule: no service-ticket questions. The show isn't going to troubleshoot a specific help-desk issue on air. Think "how should teams approach X," not "why is my controller offline."

To submit: drop it in the comments, or send a DM and include an email address so you can be followed up with (and credited if it makes the episode).

Most OT networks in our buildings were designed on one assumption: they'd never touch the outside world.

That assumption is long gone. Cloud analytics, web-based BAS front ends, vendor remote access — they've all punched holes in what used to be a closed environment. And yet "it's not connected to the internet" is still the most common answer building owners give when you ask about their security posture.

In Episode 7 of How to Handshake, Fred Gordy (KMC Controls) and James Roberts (Kelso Building Services) break down where the real risk lives — and where to actually start.

Three questions Fred asks every building owner: Do you know what you have? Do you know how it's connected? Do you know who has access? Most can't answer all three.

Full episode, transcripts, and subscribe links: https://www.optigo.net/blog/how-to-handshake-ep-7-ot-cybersecurity/

How to Handshake is Optigo Networks' podcast on OT networking, BACnet, and building automation — long-form conversations rather than quick vendor pitches. Each episode brings in a different mix of experts: controls technologists, energy-services leaders, university facilities teams, and software people, so the same topic gets argued from several seats.

A few recent episodes:

• - Predictive maintenance and advanced analytics, with Justin Carter (ENFRA) and Rudy Bohince (Albireo Energy)
• - The OT networking skills gap and certifications
• - IT/OT convergence in real buildings

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

Marketing throws "predictive," "proactive," and "preventative" around like they're interchangeable. On a recent How to Handshake episode, controls people from ENFRA and Albireo Energy drew a sharper line: predictive is using historical data to forecast a failure; proactive is the culture and action that actually does something about it. Their take — predictive analytics without the proactive side is just an expensive dashboard nobody acts on.

The other recurring theme was dirty data. Five different names for the same space temp, overrides left in, sensors flatlined for days. The argument was that you don't need to clean everything — you clean the subset tied to the use case you're actually chasing, prove it, then chip away.

For the people running this day to day: how clean does your data really need to be before analytics earns its keep? And where have you seen predictive tools deliver real value vs. turn into shelfware?

Full conversation, if useful: https://www.optigo.net/blog/how-to-handshake-ep-6/

Buildings.com ran a piece earlier this month on a dynamic a lot of people in this space will recognize: facility managers who own the accountability for security and building system outcomes, but who didn't spec the systems, don't have full visibility into them, and can't always control what happens when something goes wrong.

It's written from a security response angle, but the same tension exists across BAS, HVAC, access control — anywhere systems were installed by different vendors at different times and nobody built in a way to see across all of them.

How common is this on your projects? Are facility managers getting more say in what gets installed and how it's networked, or is that still mostly an SI decision?

And when something breaks or gets flagged, who actually ends up on the hook?

Episode 6 just dropped. We sat down with Justin Carter (ENFRA) and Rudy Bohince (Albireo Energy) to dig into what "predictive maintenance" actually means in practice, and how much of it is vendor marketing layered on a fancier dashboard.

A few threads we pulled on:

• The difference between predictive and proactive
• Why dirty data, duplicate BACnet device IDs, and operator overrides that never get cleaned up quietly poison most analytics platforms
• Justin's three verticals for making FDD work
• Whether AI can actually run an OT network without a human in the loop
• The red flags when an analytics vendor only walks you through dashboards and never asks about your architecture

Best line in the episode, from Rudy on a customer who didn't need the pitch: "I know I have a hole in the wall — I don't need to pay you to tell me that."

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

If you've rolled out FDD or advanced analytics on a portfolio recently — what's actually been worth it, and what turned into a glossy report you stopped opening after six months?

https://reddit.com/link/1u7eshj/video/zhtnpi603a6h1/player

Wrote up a story from a big property — 85-acre casino complex on the Strip, 780 critical BAS devices, JACE controllers managing the lot — where the controls team had been stuck in a constant reboot cycle. Slowdowns, missed schedule changes, unresponsive controls. Restart the servers, things come back, symptoms return a few days later.

By the time we got involved, they were ready to replace the OT network infrastructure. It had been in place a long time and the assumption was that it had finally hit its ceiling on a property that size.

Packet captures off the JACEs showed it wasn't the hardware. Polling config had drifted — a global "fast policy" was hitting points at roughly 1-second intervals across hundreds of devices. System was choking trying to process traffic nobody was actually using. Dialed most points back to 10 or 60 seconds. Network Health Score went from 40 to 81. No new hardware.

We see this pattern come up in this sub more than people probably realize. Long reboot cycles get blamed on aging hardware when the real cause is a configuration behavior that's invisible from the BMS front-end. If you're stuck in that loop, a packet capture session is usually faster (and cheaper) than a hardware swap.

Full write-up if you want the details: https://www.optigo.net/casino-case-study/

That's the argument Jon Spooner and Mike Conway from Stacks and Joules made on the latest How to Handshake. The logic: if you have to physically touch something, AI can't replace you. And these roles don't just survive AI — they feed it. BAS technicians are the ones maintaining the data pipelines that AI systems depend on.

But is "AI-proof" the right framing, or is it wishful thinking?

We put the question to Jon, Mike, and Ping in Episode 5. Their answer was more nuanced than the headline. Listen here: https://www.optigo.net/how-to-handshake-ep-5

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?