These are Niagara products SoftwarePile is building — not services we sell today. Each came out of doing the work by hand often enough to know it should be a product.
They build on the tooling described in our engineering toolkit. Every page below states plainly that the product is in development.
Energy and Equipment Performance
- SmartEdge Energy Oversight — base-load, after-hours, peak demand, scheduling overlap and EUI benchmarking.
- HVAC Fault Detection and Diagnostics Suite — A Niagara-integrated FDD suite producing evidence-backed, prioritized equipment fault findings across AHUs, VAVs, RTUs, chillers, boilers, pumps and cooling towers.
Station Lifecycle and Change
- AX-to-N4 Migration Accelerator — station and module inventory, unsupported-component identification, ORD conversion, packaging and post-migration validation.
- Niagara Station GitOps and Change-Control Platform — understand what changed inside a station, approve it, and roll it back.
If one of these solves a problem you have now, tell us about it — early conversations shape what gets built first, and we will be straight about timelines.
What In Development Means on These Pages
None of the products described here can be bought, licensed, or subscribed to today. Each one is in development. The pages set out design intent and engineering reasoning, and there is no installer, no license, and no release date behind any of them.
There is a difference between a product and service work in the same subject area. Software Pile takes on Niagara engineering under contract now, and some of what these product pages describe overlaps with that work. What does not exist is the packaged version with an installer, documentation and a support commitment, and there is no finished internal engine sitting behind these pages waiting to be wrapped. If you need an outcome this quarter, the route is a project. If you want to influence a design while it is still moving, the route is a conversation.
What Put These on the List
Each one started from a deliverable that gets rebuilt by hand every time it is needed. Energy studies assembled from scratch for each report. Fault rules rewritten per air handler. Migration inventories put together by hand from station exports. Station change control tracked with screenshots and memory.
That is a deliberately narrow filter. A task has to be repetitive, valuable, and stable enough in shape that productizing it does not just produce a rigid tool nobody can adapt. Plenty of ideas fail that test and stay as consulting work, which is the right outcome for them. Two have design pages of their own so far: SmartEdge Energy Oversight, and the Niagara Station GitOps and Change-Control Platform.
The Layer They All Depend On
They rest on the same foundation: a station model that software can read without a human interpreting it. Consistent equipment and point naming, Project Haystack tagging, queryable data through BQL, and programmatic access through the Baja API.
Where that foundation is missing, each of these designs would degrade into custom work per site, which defeats the point of building them. The tagging and integration work described under Building Automation Integration Services is not a preliminary step to the products. It is the thing that would make them possible.
Which Parts Exist and Which Are Drawings
Treat any capability list as design intent, including this one. The question to put to a vendor, Software Pile included, is which parts exist as running code, which exist as a written specification, and which are still a sketch. For everything on this page the answer is specification and design work. There is nothing here you could install.
So this is the wrong page to build a budget or a bid date around. What Software Pile can deliver now is service work: Building Automation Integration Services, Niagara Graphics and Operator Dashboards, the Niagara engineering tools work, AX-to-N4 migration, and portfolio energy analysis delivered as a consulting engagement.