Engineering studio · remote · fixed price
Plantroom Labs connects systems that were never meant to work together and builds the useful thing on top: a station that behaves, a device fleet a platform can read, an agent that can see a building, a web app a business can deploy. Each project gets a team picked for the fields it touches, led by one person who writes the specification and answers every email. Every job is a fixed price against a written specification agreed before work starts.
The core
A LoRaWAN sensor, a Niagara station and an invoicing spreadsheet look nothing alike. The job on each is the same, and so is the way it is checked.
Get the data off the system as it really is: the protocol, the decoder, the export, the jar. Measured, not taken from the manual.
Map it to one data model with your names and tags, so the next system and the next engineer can find it.
Write back only where it is meant to: priorities, schedules, commands. Every write is scoped and reversible.
Put it in front of the person who needs it: a graphic, a dashboard, an alarm, an agent answer.
Source, notes and access in your name. Support afterwards if you want it, and nothing that only we can keep alive.
Sensor → Firmware → Radio → Network server → Payload decode → Platform → Interface
Bold is what you can open on this site today. The rest is ours too, and travels under NDA.
Fields
Most real jobs cross two or three of these. That is the reason they sit under one roof. Every field, with the work and notes behind it →
Building automation
Stations, modules, schedules, alarms and the Niagara 5 move. JACE-8000 is the usual target.
Connected devices
Sensor fleets, payload decoders and the firmware behind them, into whatever platform has to read them.
Systems integration
BACnet, Modbus, MQTT, oBIX and REST between systems that were never meant to talk.
AI agents
Letting a language model read a control system, and deciding what it may never write.
Interfaces
Graphics and dashboards operators look at all day, built against the live data model.
Web and DevOps
The web app nobody can deploy, the spreadsheet a business runs on, and the site that sells it.
Hardware
Boards, firmware, SOLIDWORKS enclosures and printed parts, for the projects that need something physical.
Project teams
A job is staffed for what it touches, not from a bench. The specification names which of these roles the job needs and who fills each one, so you know who built what before you pay for any of it.
Owns the specification, the fixed price and every reply from the first email to handover. On every job, named in the quote. Today that is Usama Iqbal.
Protocols, data models, back ends, agents and the web apps around them.
Operator graphics, widgets and dashboards built against the live data model.
Electronics, PCB layout and firmware for device work, named in the specification when a job needs it.
SOLIDWORKS enclosures, brackets and 3D-printed parts for projects with something physical in them.
Services
The fields are where the work sits; these are what you can buy. Each one is scoped in writing and priced per deliverable, and six of them need no BMS in the building at all.
A fixed-scope paid audit of an existing integration: what talks to what, where it breaks, and what fixing it would take.
Read moreCustom IoT and LoRaWAN builds: decoders that survive a station, a self-hosted ChirpStack server, MQTT, and the points or dashboards the readings become.
Read moreField protocol integration and the data behind it: BACnet, Modbus, M-Bus and MQTT, into a building system, a database or a dashboard.
Read moreWeb and app builds with the DevOps around them: front end, backend, the database under it, and the build, deploy and monitoring work that keeps it up.
Read moreRemote website design services for small firms: a few real pages, fixed price, and a measured handover — HTTPS, broken links, Lighthouse, page weight.
Read moreAn audit of the spreadsheet a team runs on — every rule it encodes, and which ones contradict each other — then one bounded slice of it as a web app.
Read moreBespoke Niagara rt, wb and ux modules and drivers written against the Baja API: pure Java, signed, and stamped to install across a mixed estate.
Read moreNiagara operator screens built once and reused: standard PX plant sheets bound by relative ORD, bajaux web widgets and dashboards, and a written standard.
Read moreNiagara 5 readiness audits and migration, including JACE 8000 to JACE 9000: which third-party modules survive the new runtime and mandatory signing.
Read moreJACE controller and Niagara station setup end to end: platform commissioning, TLS, users, roles, BACnet and Modbus, tagging, histories, alarms, backups.
Read moreCustom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
Read moreSelected work
Systems involved, what made them hard to connect, what was built and what can be shown in public. No client is named on any of them.
A language model can be given a control system to read without much ceremony.
A connected-device platform for retail and facilities: battery-powered devices on a long-range radio network, a provisioning path, remote configuration, telemetry, an operator dashboard and an internal operations app.
Building automation graphics are usually drawn once, per site, by hand, and then maintained by whoever is still there.
A LoRaWAN sensor arrives with a decoder written by its manufacturer, and the station believes whatever that file returns.
A member of the Niagara community publishes three free programs for copying component trees and driving link creation from a CSV.
Try before you ask
The demo below is the real widget code running in your browser against a simulated station. Fourteen programs: three for an unfamiliar network, nine for what Niagara will do with your file, one for the spreadsheet a business runs on. All read-only, MIT-licensed and one file each. And the notes. There are 54, on narrow questions about protocols, stations, devices and the web, written from the system rather than from memory.
Supply and return air temperature, fan power, zone CO₂, a fan-speed dial, a demand chart, a writable zone set point, plant commands and the alarm queue. Twelve tiles, each bound to its own station ORD — and the values are moving because a simulated station is pushing them. Move the set point and the plant responds.
Building automation · Niagara 5
Niagara 5 moves off Java 8, makes a valid module
signature mandatory and does not run on JACE-8000 hardware. Every third-party
module has to be recompiled and re-signed, and the bespoke ones are only found
by looking. The module scan is free: send a modules/
listing, the jars or a backup and a per-module table comes back by email. It is
static analysis against a Java 25 JDK, not a test on a Niagara 5 build.
How we work
Scope, target versions and hardware agreed in writing before a number exists. One fixed price, no hourly billing.
Built against your data model, point naming and tagging, so nothing needs rework on handover.
Every quote names the releases the work is tested against and how long a point-release breakage is fixed at no charge.
Bespoke work can ship with source, so you are not dependent on us to keep it alive. What you own.
Notes
No pitch in them. If a note means you do not need to hire anyone, that is a good outcome. All notes →
Niagara's module permission model is built on Java's Security Manager. On a Java 25 JVM it cannot be installed, so the checks stop happening.
A module with no Niagara 5 build can stop the migrator outright, and one that has a build can still fail to load. What breaks, and why.
What a Niagara module actually is on disk, the two ways to build one, and the three Software Manager refusals that actually mean something.
Next step
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.