About
An independent Niagara development practice
One engineer, one framework, and no account manager between you and the person writing the code. The work is Niagara: modules, widgets, building automation graphics, stations and migrations — quoted as a fixed price against a written specification, and scheduled rather than queued. If the next slot is months away you will be told in the first reply.
Who you would be working with
Usama Iqbal
One engineer. The person who answers the email is the person who writes the specification, writes the Java, signs the jar and takes the call when a station will not load it. Nothing is subcontracted onward without saying so first.
Remote. Written work — specifications, installation notes, audit reports — is in English and is yours to keep.
The background is software rather than field engineering: Java, web front ends and build tooling, applied to one framework. A commissioning engineer will know some things about a site that I do not, which is why the specification comes before the price and why the first question is usually about your point naming.
Why this exists
The Niagara ecosystem has a strange shape. It is the building management system in a very large number of buildings, it has a capable and open module architecture, and yet the market for third-party modules is served by a handful of vendors. Most BMS integrators who need something outside the stock catalogue either do without, or pay for a bespoke build from whoever is nearest, and then discover three years later that nobody holds the source.
This practice exists in that gap: build the thing properly, sign it, stamp it so it installs across a mixed estate, document it for the engineer who has to commission it, and hand over the source so the module outlives the supplier.
How the work is approached
Each constraint below exists because ignoring it is how Niagara work fails. No native code, because a native library will not load on an ARM controller. Stamped to the floor version, because a module stamped too high is refused outright. Signed, because verification modes tighten in every release and become absolute in Niagara 5. Small, because a JACE has far less headroom than the laptop it was developed on.
The same discipline applies to the front end. The widgets shown in the demos are built on a documented token layer — the same one this website is built on — so a client theme is a re-point rather than a rewrite, and a view that must also render inside Workbench is written to the browser engine Workbench actually embeds rather than to whatever shipped in Chrome last month.
What is deliberately not claimed
No client logos, no case studies and no deployment counts appear on this site, because there are none to show honestly yet. The demonstration station behind the widget demos was built for this portfolio. The screenshots are of that station. When there is client work that can be named, it will be named, with permission.
There is no Tridium affiliation, no Niagara certification claimed, and no listing on the Niagara Marketplace. What there is: working, signed, data-bound modules you can interact with on this site before speaking to anybody.
Working together
Engagements are remote and quoted as a fixed price per deliverable against a written specification. The first conversation is half an hour and is free, and it is allowed to end with a recommendation that costs nothing — a stock feature you had not found, or a configuration change that removes the need for a module at all.
Estates are rarely uniform. A single client often has stations on Niagara AX, on several Niagara 4 point releases and on nothing at all yet, with HVAC plant from four vendors underneath. Work is scoped against the version floor that estate actually has, not against the newest one in it.
Capability
Technical ground covered
| Framework | Niagara 4 and Niagara 5; Baja API;
rt, wb and ux module profiles; module
signing and version stamping. |
|---|---|
| Front end | bajaux, BajaScript, PX graphics and standard sheet sets, ORD binding, BQL history queries, responsive token-driven component systems, light and dark theming. |
| Hardware | JACE controllers on ARM, Supervisor and PC stations on x86. |
| Protocols | BACnet/IP and MS/TP, Modbus TCP and RTU, MQTT, REST and vendor APIs by specification. |
| Station work | Platform commissioning, TLS and certificates, user and role models, tagging, histories, alarm classes, schedules, Niagara Network and provisioning, backup and verified restore. |
| Migration | Java 8 to 21 porting, dependency auditing, re-signing, module inventory and readiness assessment, JACE-8000 to JACE-9000 sequencing. |
Next step
Tell us the version, the hardware, and what it has to do.
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.