One of the latest AI crazes right now is the Open Claw project—and from my own testing, it’s actually pretty impressive. I’ve been following Matthew Berman, who has been putting Open Claw through its paces across a variety of use cases. From acting as a personal assistant to monitoring multiple social media feeds, the capabilities are worth seeing for yourself. His video, “Do THIS with OpenClaw so you don’t fall behind… (14 Use Cases)” is a great place to start.
See for yourself—some of the ideas are a bit “okay, I guess,” and clearly more for testing and learning purposes. Things like daily briefings, monitoring Fitbit data, making suggestions, or even keeping a food log where AI tries to identify patterns (like foods causing gut issues based on historical data). It’s very AI-intensive, and realistically, most people wouldn’t use this level of automation day to day.
But that’s not really the point.
What’s interesting is the underlying capability. There are a lot of powerful ideas happening here—especially in how agents can coordinate tasks, choose models, and run prompts while we sleep. In Matthew Berman’s demo, there are clear examples of workflows that could absolutely translate into the smart building world.
Hear me out.
Setting up Open Claw comes with a bit of a learning curve, and it has a lot of bells and whistles that I haven’t even explored yet. Out of the box, there are about ten different ways to interact with your “bots.” So far, I’ve experimented with the Discord chatbot, which works pretty well. I may also try Google Chat, which is supported, but at the moment, I don’t think I quite need it yet.
Open-FDD
For the Open-FDD project, which is still in an early development phase, I’ve only been using Open Claw since yesterday to autonomously test the application. I’m having it generate web app testing code through the Open Claw chat, building on some bare-bones scripts I already had. In web testing, tools like Selenium (Python API) can open a Chrome browser, log in, and programmatically test buttons and widgets on the Open-FDD frontend—which is actually a very common practice in web application testing.
On my test bench with a few BACnet devices, I have Open Claw rigorously testing the full functionality of Open-FDD. It’s actually pretty good at writing test code, going through documentation, finding broken links, and even creating GitHub issues automatically on my behalf when it finds something wrong. So all in all, I basically have Open Claw acting as my personal assistant for web application testing—and honestly, it’s probably better at parts of it than I am.
The coolest part is the autonomy: while I sleep from 6PM to 6AM, it runs a full battery of tests. Last night it did pretty good—I was happy with the results. It’s fully testing the Open-FDD API, the web application, and even making BACnet requests to my test bench devices, then validating the results and submitting GitHub issues if it finds something broken.
The default chat of Open Claw is real basic and easy to use.
I’m still the human in the loop—approving actions and guiding it—but it’s starting to feel like its own self-contained feedback loop. Open Claw will even offer to fix the issues it finds, although I’m not quite ready to let it go that far yet.
Like Matthew Berman shows in his YouTube demos—doing a million different things—I also have Open Claw monitoring GitHub PRs. It’s kind of mimicking another AI tool I’ve been trying called CodeRabbit, which does a really nice job reviewing PRs and even suggesting fixes through AI-generated prompts. I’m curious to see how close Open Claw can get to that level.
And thanks to people like Matthew Berman highlighting this stuff, I found out that one of OpenAI’s models is supported directly in Open Claw through a standard subscription. I’m using the Codex-style model through my $20/month plan, and honestly, there’s a lot you can do with that. If you were doing all of this strictly through API usage, it would get expensive fast.
This is all super experimental—and honestly, that’s exactly the kind of space I like to work in. If you want to check it out, the whole setup is being run autonomously by Open Claw, with me guiding it more like an advisor.
https://github.com/bbartling/open-fdd-automated-testing
At the moment, we are mainly focused on frontend and API regression testing. The GitHub README also outlines a couple of additional areas we haven’t fully explored yet with Open Claw, including AI-assisted data modeling and verification.
This includes things like export/import flows for the Open-FDD data model, Brick tagging and rule_input mapping validation, and SPARQL checks to confirm that imported data is actually usable by Open-FDD. It also means verifying that AI-assisted tagging outputs correctly land in the application.
Another big area is live BACnet and FDD verification. This involves using fake BACnet devices with deterministic fault schedules, validating BACnet scraping against known good and bad data windows, and checking BACnet graph/addressing through SPARQL and API validation. There are also YAML rule hot-reload checks, along with making sure faults are properly computed and surfaced by Open-FDD as expected.
All of this starts to build toward a future where optimization and supervisory logic can be driven directly from equipment semantics.
Optimization Algorithms
So it’s also well known that generative AI is exceptionally good at converting codebases—Java to Python, C to Rust, whatever. And honestly, it makes you think: if Open Claw can already do everything I described above, why couldn’t it also become the optimization algorithm for the building?
There are already repositories out there with simple optimization logic. I even have some Niagara Program Objects written in Java—basic rule-based algorithms for things like Guideline 36 AHU duct static pressure reset, temperature trim and respond, and even a conceptual optimal start algorithm.
https://github.com/bbartling/niagara4-vibe-code-addict
A future TODO for this project—once we’re working with live HVAC systems—is to pull down that Niagara “vibe coder” repo and have Open Claw convert everything to Python. It’s kind of like my current test bench, but way more enhanced. And of course, we’ll be closely monitoring everything with FDD as well—which could really be any FDD application, as long as we guide Open Claw in the right direction.
And the neat thing is that Open Claw should have full access to the FDD results, allowing it to learn from them and revise algorithms as needed. Of course, that would require a truly robust and well-validated FDD implementation already in place.
I also think this is an important area for IoT—being able to push data to cloud dashboards and analytics platforms, where experts can evaluate what’s going on. For example, mechanical engineers working for consulting firms that specialize in commissioning building systems could use this data to better understand performance and identify issues.
The Building Operator
One huge hurdle with all of this is that the building operator has to stay in the loop. Optimization algorithms are great for reducing energy bills and demand charges, but we also need to focus on actually helping the building operator do their job.
I can say with pretty high confidence that most building operators—probably almost all—don’t really care about energy efficiency or utility bills. They’re judged on comfort. The accounting department pays the bills, and operators often don’t even see them. So from their perspective, why would they care?
And the moment one of these optimization algorithms causes an issue—like crashing part of a chiller plant (and let’s be honest, there are always hiccups)—trust is gone. They’re going to hate it.
That’s the real problem: most AI in buildings today is geared toward energy efficiency, and the operator is completely removed from it. It just runs in the background, and ideally they don’t even notice it’s saving energy. But does that actually help the operator? Especially the ones who aren’t even looking at energy bills?
In research around this space, beyond the hard math—like quantified energy savings, M&V, and all that—there also needs to be real, grounded research focused on the people actually operating the buildings. That means interviewing maintenance staff and operators directly, asking questions like:
- Do you even like this software?
- Does it actually help you?
- How many hours per week does it save you from dealing with temperature complaints?
To me, this is the real sell. Energy efficiency is important—but it’s almost a secondary (though still very valuable) byproduct. For AI to be adopted in buildings, it needs to be loved by the building operator first and foremost.
Just like with BAS upgrades, a good facilities manager will usually go with whatever the building operators actually want to use.
Would Industry Have To Change?
Another thought people bring up is how AI has completely flipped the software engineering world upside down. But has that really filtered into the operational technology (OT) world?
Not really—at least not in any meaningful way.
Unless you’re in IoT (which leans heavily on modern software tools), most of the HVAC and BAS world looks pretty much the same. Are HVAC controls technicians doing anything differently because of AI? Are building operators changing how they run systems? Are mechanical engineers designing HVAC systems differently?
From what I can see—nope.
To my knowledge, not a single BAS manufacturer has fundamentally changed how they build or deploy systems because of AI. But maybe they don’t have to… or maybe they won’t. And honestly, that might be fine.
Because tools like Open Claw—and others like it—might not need the industry to change at all.
If building operators are willing to adapt, chat with AI, and AI models can write solid code, we might be able to just creep and crawl right around traditional systems. Interrogate a BAS, run BACnet commands, optimize sequences—do whatever we need—without waiting for the industry to officially adopt AI.
Must Haves
My own personal take on this is that there needs to be an element of CMMS (Computerized Maintenance Management Software) built into whatever we’re doing.
For example, imagine a building operator workstation that includes an AI agent chat interface—something like Open Claw—running optimization algorithms, analyzing FDD data, tuning that data, and then making suggestions on what’s actually wrong in the HVAC system. Things like sensors drifting out of calibration, flatlined signals, flaky points, or failing valves and dampers.
But beyond just fault detection, there should also be a teaching component.
AI could help operators understand when a building is being operated incorrectly—which happens all the time. For example, a mechanical engineer may have designed the ventilation system to meet code requirements, which then gets translated into a BAS setpoint. Over time, that setpoint gets “monkeyed with,” and before long, ventilation is no longer aligned with code—or the original design intent may be outdated altogether.
A lot of this knowledge could be baked directly into a knowledge graph. That’s really where I see Open-FDD heading: toward an open-source knowledge graph for BACnet systems that includes equipment, feeds relationships, and even design-level data like system capacities—essentially everything you’d find in a mechanical schedule.
If a building had a complete knowledge graph like that, then Open Claw—or any similar AI system—could go even further. It could perform things like virtual energy metering, which is already common in many FDD platforms. The difference is that today, that context usually isn’t fully captured in a structured, connected graph.
Check out a recent Reddit post from a service manager—likely from a mechanical contractor—asking what work order software people are actually using these days.
So if AI isn’t solving this problem—being a teacher, an optimizer, and also a work order generator for technicians or supervisors—it may not be a complete solution. Because at the end of the day, what really matters is capturing issues, turning them into actionable work, and helping technicians fix real problems in the field. Not just dashboards, not just energy savings, but actual workflow. If something like Open Claw can detect a fault, explain it clearly, generate a work order, and help guide the fix, then that’s something the industry will actually use. At least, this is where I want Open-FDD to go in the long haul.
Conclusion
This is a long post! But keep one thing in mind: something I keep hearing from a variety of sources is that computers are getting closer and closer to understanding natural language—which is something all humans already know, no matter what industry you work in.
I really like an IBM Technology YouTube video where they walk through the history of programming languages. At one point, everything was written in bare-bones assembly, then came C, then higher-level languages that made things easier to understand—and now we’re entering an era where computers can understand natural language itself.
The neat part is the title of that video: “Best Language for AI: What You Need to Know.” And you guessed it—the answer is natural language. Knowing how to work with AI is becoming its own kind of programming.
Thanks for reading. The Open-FDD project is looking for active contributors and testers, and maybe over time it can grow into something beyond just a weekend hobby project running on a test bench.
https://github.com/bbartling/open-fdd
Until next time—over and out.
– Ben
