Industrial IoT Development for Smart Buildings
A smart building is rarely one system; it is a chiller plant on BACnet/IP, meters on Modbus, a lighting panel speaking proprietary RS-485, and an access controller that owns occupancy data but shares none of it. We build the IIoT gateway and integration tier that normalizes those protocols into one tag model and pushes supervisory logic across them, so the building runs as a system instead of five disconnected vendor islands.
Challenges specific to Smart Buildings
Chiller plant BACnet/IP data never reaches the analytics layer
The plant controller exposes BACnet/IP objects but no historian binding, so chilled-water supply temp, kW, and flow are trended locally for 24 hours then overwritten, and nobody can prove plant kW/ton across a season.
Utility and tenant meters live on an orphaned Modbus trunk
Power and BTU meters sit on a Modbus RTU loop with no gateway, registers are read by a spreadsheet once a month, and tenant submetering disputes have no auditable interval data to settle them.
Occupancy is trapped inside the access-control system
Badge-in counts that should drive demand-controlled ventilation and unoccupied setback stay locked in a proprietary access database with no export, so HVAC conditions empty floors at full load.
Lighting and security run on protocol islands
A DALI/0-10V lighting panel and the security DVR each speak their own bus, share no schedule with HVAC, and a holiday or after-hours event has to be programmed five times in five tools.
Cross-system supervisory logic has nowhere to execute
There is no tier that can read plant load, meter demand, and occupancy together, so peak-demand limiting and optimal start/stop are impossible and the building eats every demand-charge spike.
How GizanTech solves them
- Multi-protocol gateway and tag normalization. 1) An edge gateway runs concurrent BACnet/IP, BACnet MS/TP, and Modbus RTU/TCP clients, maps every object and register into one normalized tag model with engineering units and quality flags, and exposes it upstream as MQTT/Sparkplug B or BACnet/IP.
- Plant historian binding and M&V data path. 2) We bind chiller-plant kW, flow, and supply/return temps to a time-series historian at one-minute resolution, compute kW/ton and plant efficiency on the edge, and retain IPMVP-grade interval data for measurement and verification.
- Revenue-grade submetering pipeline. 3) Modbus power and BTU meters are polled on a fixed interval, timestamped and gap-flagged at the gateway, and delivered as auditable 15-minute interval reads so tenant cost allocation and ENERGY STAR reporting are defensible.
- Occupancy and access data liberation. 4) We pull badge and occupancy events out of the access-control system via its API or OSDP/Wiegand bridge, normalize them to per-zone occupancy tags, and publish them to HVAC and lighting for DCV and unoccupied setback.
- Cross-system supervisory control tier. 5) A supervisory engine reads plant, meter, and occupancy tags together to run peak-demand limiting, optimal start/stop, and after-hours scheduling once, then writes setpoints back over BACnet to every subsystem.
| Building system | Fieldbus protocol | Integration approach | Operational / energy outcome |
|---|---|---|---|
| HVAC / chiller plant | BACnet/IP (controller objects) + Modbus TCP on the VFDs | Gateway polls plant objects, binds kW/flow/temps to historian, computes kW/ton on the edge | Continuous plant efficiency trend; optimal start/stop trims 8-15% of plant runtime energy |
| Energy / tenant metering | Modbus RTU power & BTU meters | Fixed-interval poll, gateway timestamps and gap-flags 15-minute interval reads | Auditable revenue-grade submetering; tenant cost allocation and ENERGY STAR data hold up |
| Occupancy / IAQ | BACnet MS/TP CO2/IAQ + access-system occupancy via API/OSDP | Normalize CO2 and badge counts into per-zone occupancy tags for DCV and setback | Demand-controlled ventilation cuts fan and reheat hours on empty floors |
| Access / security | OSDP / Wiegand + proprietary access API | Bridge door and intrusion events into the tag model and the unified schedule | After-hours events drive HVAC and lighting once instead of five separate tools |
| Lighting control | DALI / 0-10V panel over RS-485 to BACnet | Map lighting groups to BACnet objects sharing the supervisory occupancy schedule | Daylight and vacancy harvesting cut lighting load and align with HVAC setback |
Go deeper
Industrial IoT Development for other industries
Frequently asked questions
Do you replace our existing BMS or integrate with it?
We integrate. The IIoT gateway sits alongside your existing BACnet and Modbus controllers, reads their objects and registers, and adds a normalized data and supervisory layer on top, so you keep your plant controllers and gain cross-system control and historian data without a rip-and-replace.
How do you get occupancy data out of a closed access-control system?
We integrate through whatever the system exposes: a documented REST or database API where one exists, or an OSDP/Wiegand bridge at the reader level where it does not. Badge and door events are normalized into per-zone occupancy tags that drive demand-controlled ventilation and unoccupied setback.
Is the submetering data good enough for tenant billing?
Yes. We poll the Modbus power and BTU meters on a fixed interval, timestamp every read at the gateway, flag any gaps, and store auditable 15-minute interval data, so tenant cost allocation, demand-charge analysis, and ENERGY STAR submissions are defensible rather than spreadsheet guesses.
Can the integration tier actually save energy or just monitor?
It controls. The supervisory engine reads plant load, metered demand, and occupancy together to run peak-demand limiting, optimal start/stop, and after-hours scheduling, then writes setpoints back over BACnet, which typically trims 8-15% of plant runtime energy and clips demand-charge spikes.
What does the data look like to our cloud or analytics platform?
Upstream we publish the normalized tag model as MQTT with Sparkplug B, or expose it as BACnet/IP for an existing head-end, so your analytics, fault-detection, or cloud platform sees consistent engineering units and quality flags instead of raw vendor registers.