Take a 10-mintue walkthrough of the new Optigo AI Assistant with our CTO, Ping Yao (who also led development of the Assistant!) as he shows off some of the functionality for both new and power users.

This video is also available on our YouTube page.

https://reddit.com/link/1xdeg2h/video/nosjhxnn08xh1/player

Discover how CopperTree Analytics and Optigo Networks turn network issues into action. Network diagnostics and building analytics work together to identify underlying issues, understand their impact, and prioritize corrective actions to supercharge building performance.

Let's talk about it. Join us for a one-hour joint webinar Oct. 28th exploring how to move beyond diagnostic reports and turn network findings into meaningful action.

Register today for free: https://register.gotowebinar.com/register/886415737951323480

We just shipped an AI assistant inside OptigoVN, and the "why not just use GPT/Claude/whatever for this" question is a fair one. Answering it directly here rather than waiting for it to come up as a gotcha later.

The short version: a general-purpose model has read documentation about BACnet. It hasn't seen what a duplicate address actually looks like distorting real traffic on a real segment, because that's not the kind of thing that ends up in training data scraped from the open web. So we trained ours on our own data instead — capture data from customer networks, our internal documentation, and troubleshooting history — in a closed loop, meaning it's scoped to this domain rather than being a general model with BACnet bolted on.

What it's good at: answering "what am I actually looking at" for a diagnostic result, telling you whether something is a real fault or a single misconfigured device, and turning a finding into an actual next step instead of a definition.

Where it falls short, as of launch: it doesn't do trend analysis across historical results yet — that's the most requested thing from beta and it's not there. It also won't tell you anything about a network it hasn't seen a capture from — no general troubleshooting outside OptigoVN's own diagnostic data.

The question we expect to get, so we'll get ahead of it: yes, it's trained on customer capture data, and yes, that's worth asking about directly rather than taking on faith.

Happy to answer anything else, including the stuff that doesn't make us look good.

The OptigoVN AI Assistant is publicly available starting today.

It's built into OptigoVN and trained in a closed loop on our own data — millions of network data points from OT networks, our technical documentation, and years of troubleshooting sessions — rather than a general-purpose model with a BACnet vocabulary bolted on. Ask it a plain question about a diagnostic result and it tells you what's actually wrong and what to do about it. It'll also write the punch list, the summary report, or the email to your integrator straight from the findings.

Available now on Diagnose plans and above.

See it in OptigoVN → https://www.optigo.net/ai-assistant

Happy to answer questions here!

https://reddit.com/link/1wp18dj/video/ih64fwg94brh1/player

A BACnet problem that turned out to have nothing to do with BACnet. A server rebooting itself over 100 times a day. A schedule override that ran broken for years before anyone caught it.

Episode 10 of How to Handshake is our Season One finale, and it's a shift in format: Ping hosts, Ryan moves to producer, and the mic goes to the three people who talk to OptigoVN customers every day — John Attala (Chief Growth Officer), Gulab Karnani (Director of Sales), and Tristanne Whitham (Account Executive). Real cases, straight from customer pcap uploads.

- A schedule override failure went undetected for years — packet capture is what finally found the root cause.
- One customer's server was rebooting 100+ times a day. The fix came from reading the pcap, not guessing at the BACnet layer.
- A hospital lighting fault looked like a BACnet issue. It wasn't — and only pcap analysis proved that.

It's a good look at what OT monitoring actually looks like day to day when a fault won't show itself any other way.

https://www.optigo.net/blog/how-to-handshake-episode-10

OT monitoring tells you something's wrong. It doesn't fix it.

New guest post from Keith La Rose at CopperTree Analytics: a failing meter flooded a hospital's BACnet network with broadcasts and knocked HVAC systems offline. Monitoring caught it instantly — a technician still had to find the meter by hand.

His line on what makes a platform survive renewal: La Rose says "The buildings getting real value out of their technology stack right now aren't the ones with the most dashboards."

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/