Sensors are cheap; meaning is not
A wireless leak sensor costs little and installs in minutes. That’s the trap. Buildings end up with leak sensors from one vendor, CO2 monitors from another, door contacts on the security system and occupancy in the lighting platform, each with its own app and its own idea of what “Room 214” means. The data exists. Nobody can use it together.
The real decision is how to add sensors so the data stays usable: which devices, which path into your systems, and who looks after them once they’re on the wall.
What we connect, and what we watch for
| Sensor | Typical question | What we watch for |
|---|---|---|
| Occupancy and people counting | Is the space used, and by how many? | Lighting delays inflate presence; counters need clear sightlines |
| CO2 | Is ventilation keeping up? | Placement near diffusers, doors or windows; calibration drift |
| Temperature and humidity | Are spaces comfortable and within limits? | Sun-struck walls, sensors mounted inside cabinets |
| Leak | Is water where it shouldn’t be? | Cable versus spot sensors; who gets the alarm at 2 a.m. |
| Door contact | Is it open when it shouldn’t be? | Overlap with access control; battery life on busy doors |
Gateways and the edge
Most battery sensors talk to a gateway over a low-power radio, and the gateway decides a lot about how reliable the system feels. We look for gateways that:
- buffer readings when the internet link drops and send them later with correct timestamps;
- run simple local rules at the edge, so a safety action such as closing a water valve doesn’t depend on a cloud round trip;
- accept signed firmware updates remotely;
- sit on a segmented network with only the outbound connections they need.
Where a building needs more local logic, a small edge computer can host the MQTT broker, translate protocols and keep a short history on site.
MQTT, Sparkplug and why structure matters
MQTT is a lightweight publish-and-subscribe protocol: devices publish to a broker, and any authorized system subscribes. On its own, MQTT says nothing about topic names or payload formats, so every integrator invents a scheme. Sparkplug B, standardized as Sparkplug 3.0 (ISO/IEC 20237:2023), fixes that. It defines a topic namespace, a typed payload format, and birth and death messages, so a subscriber knows the moment a gateway goes offline instead of trusting a stale last value.
When the data also has to reach a BMS, we expose the relevant points over BACnet (see BMS integration). MQTT carries the many-devices, many-subscribers traffic; BACnet carries the handful of points the HVAC sequences need.
Tags decide whether data is reusable
A point named AHU1_ZN3_CO2 means something to the person who named it. A point tagged in Brick or Project Haystack says what it measures, which equipment it relates to and which space it’s in, in a form software can query. ASHRAE 223P is developing a standard semantic model on the same ideas, and we follow it as it matures. We tag at onboarding, because tagging later from a spreadsheet of cryptic names costs more and never quite gets finished.
Onboarding and lifecycle
Every device gets an entry in the device register before it’s installed: location, unique credentials, firmware version, battery date, owner and expected replacement date. When a device is retired, its credentials are revoked and its history is kept. This is unglamorous work, and it’s what stops a sensor fleet from quietly decaying.
Proven on the bench first
New devices and gateway combinations run on the Lytbit Lab bench before they go into a building. We compare reporting intervals with the datasheet, check range through the materials typical of your building type, capture network traffic to see where each device really connects, and record the results in a Bench Note. Sometimes the note says “don’t buy this one”, and that’s the most valuable kind.
