What else could a BAS interface look like?

I've been experimenting with a few different ways to interact with building automation data. A compact desktop app that works more like Raycast. A map of equipment and its relationships. And, because I wanted to see what would happen, a whiteboard with live Niagara points connected to the drawing.

They look quite different, but there's a common question behind them: what would I build if I started with the task someone was trying to do, rather than starting with another equipment page?

I work on BAS interfaces at QA Graphics, and these are personal projects where I can explore that question. They range from a prototype with designed demo data to tools connected to Niagara. I'm still figuring out where each approach is useful.

There is already a lot here

Custom interfaces over BAS data have been possible for a long time. Reflow and View Builder are established examples of different interfaces around Niagara, including equipment views, dashboards, histories, and alarms. Reusable graphics, templates, and relative bindings are familiar territory too.

What interests me is having more room to try different ways of interacting with building data. Conventional web development gives me access to the kinds of search, drawing, graph, and workspace tools I use outside BAS. AI coding tools are part of how I'm exploring those ideas. I can work through an implementation, try it, and keep changing the parts that don't feel right.

That still involves software development. Connecting a value is one part of it. Handling a lost connection, preserving a saved view, or making a behavior easy to edit later can take the idea in a very different direction from the first screenshot.

My projects are mostly Niagara-based. baskStream provides the connection for Dial and basdraw, while Niagara continues to handle station access and permissions. That gives me a practical place to experiment with the interface without rebuilding the system underneath it.

Dial: start with what I need

Dial started with a fairly simple preference: I like the way a tool such as Raycast can appear when I need it and stay out of the way afterward.

For a quick equipment check, I wanted that kind of interaction with Niagara. Open Command, search or filter the modeled equipment and points, and get to a useful view. That might be an equipment summary or a trend. A useful view can be saved and returned to later.

Some tasks need more room. Dial also has a Workspace with tabs, equipment and location navigation, and split panes. The same views can be used there, so moving into a larger workspace doesn't mean setting up the investigation again.

The useful distinction is how much interface the task needs. A quick lookup can stay small. Comparing values and histories can take up a full window.

This is search and filtering over a configured model. It isn't a demonstration of an AI assistant understanding arbitrary requests about a building. The equipment, points, locations, and relationships still have to be represented underneath it.

The map: keep the connections visible

The BAS Network Map explores a different starting point: equipment in relation to the rest of the system.

It puts plant equipment, water loops, air handlers, and served zones on one map. Opening an equipment panel keeps those connections in view. Points and alarms can be inspected there, and a replay timeline lets me move through a designed sequence of building events.

The question here is whether keeping the surrounding system visible helps someone investigate an issue. If several zones have alarms, being able to follow their shared air handler gives the investigation a place to start. Seeing the order of related events might help too.

The prototype doesn't establish the cause of a fault. Its equipment, relationships, telemetry, and event scenarios are defined demo data. It lets me explore how that information could be presented before claiming anything about real diagnosis.

A map has its own problems. More connections can quickly become more clutter. An overview that looks good on a large monitor may be difficult to read in a smaller window. The design still has to help someone choose what to focus on and what to leave in the background.

basdraw: let the working view stay loose

basdraw came from wanting to connect a drawing tool I enjoy using to live building data.

It's built on tldraw. Ordinary shapes, text, arrows, and groups can have Niagara points attached to them through baskStream. Values can drive labels, fills, visibility, and movement. Tables and history charts can sit alongside the drawing, and the bindings are saved with it.

I like that the drawing can remain unfinished. A possible use is a temporary troubleshooting view: sketch the equipment path, bring in the few values relevant to the issue, and write notes beside them. Another is putting live points over an imported controls drawing while reviewing a sequence.

Those are uses worth trying. I haven't established that a whiteboard is a better commissioning or troubleshooting tool. Part of the appeal is being able to experiment without needing every sketch to become a permanent operator graphic.

It also brings some very ordinary interaction problems into focus. Adding a live behavior needs to make sense. Changing its point later needs to make sense too. Saving, copying, resizing, and undoing should continue to behave like drawing operations. The live-data layer has to fit the canvas well enough that it remains pleasant to use.

The data model still matters

All three approaches run into the meaning of the data, even though they handle it differently.

A point address tells an application where to read. An interface that follows equipment relationships also needs to know what that point represents, which equipment owns it, and what that equipment serves.

Project Haystack and Brick provide ways to describe building assets and their meaning; Brick explicitly models relationships between them. That is relevant to these kinds of interfaces, alongside the reuse already common in BAS graphics.

In Dial, there is an explicit project model for equipment, locations, point mappings, and relationships. The map currently uses its own demo model. basdraw can bind directly to selected station points. These are different levels of structure, and they shouldn't be mistaken for three applications that automatically understand any building.

A model could let an interface move from a room to its serving equipment, or gather the same point across a group of units. Someone still needs to establish and maintain those mappings. A convincing interface doesn't make missing or incorrect relationships disappear.

What I want to keep exploring

A good equipment graphic can communicate a lot at once. Dial even retains access to the station's assigned equipment graphic. There are plenty of situations where that familiar view is exactly what I would want to open.

I'm interested in the tasks around it as well: finding something quickly, comparing several views, following a relationship, or gathering a temporary set of points and notes.

AI-assisted development makes those ideas worth exploring for me, but I don't have a measured cost comparison or evidence that these projects improve operator performance. Taking a personal tool into a supported deployment brings ongoing work: testing, station compatibility, access control, licensing, updates, and support.

What I can show today is a few different ways into the same kind of information, along with the questions they raise. I'd like to keep trying them against specific tasks and see which parts deserve to go further.

The next useful step is to watch someone use one for an actual piece of work and find out where it helps, where it gets in the way, and when they return to the graphic they already know.