What to Ask a Monitoring Vendor Before You Commit Hero — BluSENSE

BluSENSE Resources

What to Ask a Monitoring Vendor
Before You Commit

Not all monitoring systems perform equally in real buildings. The right questions — asked before you buy — separate systems built for reliability from those that look good on paper.

An hour of due diligence now is worth considerably more than fixing a poor choice later.

Talk to an Expert
What to Ask a Monitoring Vendor Before You Commit — BluSENSE

Choosing a building monitoring system is a longer-term commitment than most hardware purchases. The data you collect becomes more valuable the longer it runs, which means the vendor you choose today is the one you'll still be working with — or wishing you'd replaced — in five years' time. Asking the right questions before you commit takes an hour. Undoing a poor choice takes considerably longer.

The questions below aren't designed to catch vendors out. They're designed to surface the information that separates systems that perform reliably in real buildings from those that look good in a product overview.

About data integrity

What happens to my data if the internet connection goes down?

This is the single most important question for any application where data completeness matters. What you want to hear: data is recorded locally on the device continuously, and synced to the cloud when connectivity resumes — with no gaps in the record. If the answer involves data being held in a buffer and potentially lost after a certain period, or simply not recorded during outages, that's a significant reliability risk for M&V, compliance, or long-term performance tracking.

How are timestamps recorded — at the device or when data reaches the server?

Timestamps should be applied at the moment of capture, by the device itself, using an onboard real-time clock. What you want to hear: each reading is timestamped locally at the point of measurement. If timestamps are applied server-side on receipt, outages and sync delays produce timestamp irregularities that can undermine time-series analysis.

What is the data capture interval, and is it configurable?

A 15-minute interval is adequate for utility reporting. It's insufficient for diagnosing fast-cycling faults or capturing demand spikes. What you want to hear: the system captures at 1-second intervals, or at a minimum supports sub-minute resolution and allows you to configure the interval to match your application.

About sensor compatibility

What sensor types and communication protocols does the hardware support?

Real buildings contain a mix of sensor technologies. A system that only supports one or two signal types will leave portions of your building unmonitorable — or require multiple separate devices with separate data streams. What you want to hear: support for pulse inputs, 1-Wire, RS-485/Modbus, 4-20mA analog, and current transformers as a minimum. The broader the compatibility, the more of your building a single device can cover.

Can I connect sensors from third-party manufacturers, or am I locked into your sensor ecosystem?

Vendor lock-in on sensors is a significant long-term cost and flexibility risk. What you want to hear: the hardware supports any sensor that produces a compatible signal type, regardless of manufacturer. You should be able to use best-in-class sensors for each application rather than whatever the monitoring vendor happens to sell.

About ongoing costs

What are the ongoing subscription or licensing fees, and what happens to my data if I stop paying?

Subscription fees are often underweighted at purchase and overweighted later. A device that costs less upfront but charges $50/month per unit adds up quickly across a portfolio — and if the subscription lapses, cloud-stored data may become inaccessible. What you want to hear: either no subscription fees, or complete clarity on what the subscription covers, what it costs at scale, and that locally stored data remains accessible regardless of subscription status.

Is there a fee for data access, API access, or additional users?

Some vendors charge separately for dashboard access, API integration, or adding team members. These costs are rarely prominent in initial quotes. What you want to hear: data access is included, and the pricing model is transparent about what's covered and what isn't.

About data ownership and access

Who owns the data my system collects?

This sounds like a legal technicality until you try to switch vendors or integrate your data with another system. What you want to hear: the data belongs to you, is exportable in a standard format at any time, and is not used by the vendor for any purpose without your consent.

Can I export my data, and in what format?

If your data can only be accessed through the vendor's dashboard and can't be exported, your analytical options are permanently limited to what that dashboard provides. What you want to hear: data is exportable in CSV or a standard open format, either on demand or delivered automatically — for example, as a daily CSV email.

About support and longevity

What support is available during deployment and after?

Hardware installation is the easy part. Sensor placement, system configuration, and interpreting early data are where most monitoring projects succeed or struggle. What you want to hear: structured support options are available — not just a helpdesk ticket system, but access to people who understand building systems and can help you get the most from your monitoring investment.

Where is the hardware manufactured, and what is the warranty?

Supply chain resilience and repair turnaround time matter more in long-term monitoring deployments than they might in consumer electronics. What you want to hear: hardware is manufactured to a known standard, warranty terms are clear and reasonable, and replacement or repair logistics are practical for your deployment environment.

The vendor you choose today is the one you'll still be working with — or wishing you'd replaced — in five years' time.

One final question

After working through the questions above, there's one more worth asking — of yourself rather than the vendor:

Does this system answer the specific question I defined before I started looking?

A monitoring system that scores well on every technical question but doesn't actually address your monitoring goal isn't the right system. The best hardware for your application is the hardware that measures what you need to measure, reliably, at the resolution you need, for as long as you need it — without creating dependencies, costs, or constraints you didn't anticipate.

That's a reasonable bar. Most good vendors will meet it. And if a vendor struggles to answer these questions clearly, that itself is useful information.