Occupancy Counting <> HVAC: An Uphill Battle for Buyers

Hey friends, 

Thank you for all the feedback on last week’s first-of-its-kind newsletter. In case you missed it, we helped two different Buyers narrow the vast occupancy counting marketplace down to a shortlist of the 2-3 best vendors for them. 

We can’t share the vendors that were selected, but we’re sharing our learnings so future buyers can shortcut their procurement processes. (Buyers, we’re also happy to provide this service for you, free of charge.)

This week, we’re sharing our analysis on the uphill battle facing one of those Buyers, who wants to integrate occupancy counting into their HVAC control sequences. 

As far as smart building tech use cases go, this one is about as complicated as it gets. But it’s a use case that we desperately need to simplify. If it were easier, the energy, cost, carbon, and grid flexibility savings would be massive. 

Imagine if zone-level HVAC control sequences could be tailored to modulate ventilation (the #1 energy consumer in a building) and schedules based on the exact number of people in the space. The potential savings were massive pre-pandemic—now they’re even larger with hybrid work/live/learn/play schedules. 

The kicker? Those same sensors can then be used for many other use cases, such as Better Space Planning & Performance Measurement and More Efficient Maintenance Operations. All of this was covered in the Buyer’s Guide to IoT Sensors. 

But it’s not easy, and it’s holding back our industry. To illustrate why, consider all the components required to put this use case together. The Buyer must assemble/buy the following parts:

1. Sensor CapEx + Sensor Config/Commissioning Services
2. Physical installation of each sensor
3. Networking + Power 
4. Sensor SaaS
5. Integration with vendor’s API 
6. Publishing data in a format that can be consumed by BAS
7. Reprogramming the BAS or supervisory control

Bringing all of this together is a big undertaking; each extra component adds risk and cost. This is often too much for busy Buyers (hint: all of them).  

So what can the players in the marketplace do to make this simpler? Let’s walk through some ideas. 

First, sensor vendors need to have local integration capabilities, specifically the ability to publish data via BACnet and/or MQTT. So far, we’ve only found a few people counting sensor vendors that have this feature. 

This would cut out 3 components (4, 5, 6) in the graphic above, and it would remove the dependence on the sensor vendor’s API as the only integration option. While Buyers love API-first products, there’s also a desire for fallback options in case one option doesn’t work in the field. Local integration options also negate the need for two-way communication with the vendor’s cloud, which is a much more difficult ask for the Buyer’s IT people.

In the absence of BACnet/MQTT options, buyers need off-the-shelf, not custom, offerings that publish IoT sensor data in a consumable format on the BAS network. Further, mapping sensor data to the correct HVAC zone is not a trivial problem to solve. Several of our Marketplace Partners do this today—reach out and we’ll introduce you.  

Finally, custom integration and programming means extra risk and cost and less scalability. Sensor vendors should partner with data layer vendors to allow plug-and-play integration—built for one Buyer and shared with all future Buyers. The same logic applies to supervisory control sequences, which can be moved to the application layer of the stack. 

Then your stack would resemble the horizontal layers shown above. (Learn more with our Buyer’s Guide to the Data Layer and the Buyer’s Guide to Advanced Supervisory Control.) 

In summary, the vendor marketplace needs to collaborate to remove risk for buyers. However, the vendors can only take it so far. Buyers also need to think holistically about their tech stack and not expect each use case to stand on its own. 

The ROI of your digital infrastructure is difficult to calculate, but you simply can’t do use cases like this without a properly specified device layer, a robust and connected network layer, and a data layer capable of scalably connecting your siloed stacks together.  

Our industry is so rich,

—James and the Nexus Labs team