Luke Murray
CoFounder & CTO, XY Sense
Today we announced the launch of PremLink, XY Sense’s on-premise occupancy integration appliance. You can read the full announcement here. This post is the engineering story behind it, after months of real-world testing and validation with select enterprise customers.
Our CEO Alex wrote recently about cloud versus on-premise architecture. This is my own version of that same argument: why we built XY Sense in the cloud in the first place, why that stopped being enough on its own, and what it actually took to compress a cloud-scale processing pipeline onto a server that sits in a comms room. It wasn’t a compromise between cloud and on-prem. It was an entirely new piece of engineering, and it took us the better part of a year to get right.
The conversation has changed shape
For most of the life of this category, that cloud-native architecture was the whole answer, because the occupancy signal was being asked to do progressively more, but always one layer removed from the building itself. First it was reporting: dashboards, utilization studies, portfolio reviews. Then it was feeding space-planning and workplace strategy tools. Then real-time displays and wayfinding. Then live integrations into space booking, automatic no-show release and meeting-room reclaim. Each step embedded the occupancy signal a little deeper into the systems people actually use day to day.
That progression taught us something we now treat as a first principle: the occupancy signal is a source of truth, and the more systems it’s embedded into, the more ROI it generates. A signal that only feeds a quarterly report earns its keep once a quarter. The same signal wired into booking, wayfinding and workplace apps earns its keep continuously. But every one of those use cases still shared one forgiving property. If the data was a few seconds stale, or the dashboard was unavailable for twenty minutes during an outage, nobody’s HVAC system cared.
That’s no longer the conversation I’m having with customers, and it isn’t just anecdote. The EU’s recast Energy Performance of Buildings Directive now mandates building automation and control systems in non-residential buildings above 290kW, extending to buildings above 70kW from 2029. Automated, occupancy-responsive control isn’t a competitive nice-to-have anymore. In a growing number of jurisdictions, it’s becoming the baseline a building has to clear. Customers aren’t asking; “show me how my floors are used.” It’s “why can’t my building act on this, the moment it changes.” Occupancy and indoor air quality data has stopped being something a workplace team reads about after the fact. It’s a live input to building automation itself: demand-controlled ventilation, occupancy-driven HVAC sequencing, lighting that responds to a room going empty rather than a timer.
That shift exposes an uncomfortable architectural truth. Our platform and a customer’s BMS have historically spoken two completely different languages, running on two completely different assumptions about the world.
XY Sense’s cloud platform speaks in REST APIs, dashboards, webhooks, and JSON payloads served over the public internet. It assumes elastic compute. It assumes it can always reach the internet. It’s built to be updated continuously.
A BMS speaks BACnet objects. It assumes a deterministic local network. It expects sub-second response times to a COV subscription. And, correctly, it has zero tolerance for “wait, let me check the cloud” as an acceptable answer to “is this room occupied right now.” Building automation was designed, for very good reasons, to keep running when the outside world doesn’t cooperate.
I’ll caveat that: some of the biggest names in building automation are now pushing their platforms toward the cloud too, and I don’t think that’s wrong. But there’s always a lag between what the market leaders ship and what the bulk of the market actually runs. Buildings turn over on ten-year cycles, sometimes longer. The BMS installed in most buildings today was specified years ago and will still be there years from now, long after the newest cloud-native platforms have shipped. That installed base is the reality occupancy data has to work with, and for most of it, the control loop still needs to survive an outage on its own, regardless of where the software layer above it eventually moves. That’s the segment this architecture is built for, and it’s the majority of the market.
You can’t solve that gap by making the cloud platform “a bit more real-time.” You can’t solve it by asking BMS platforms to trust an internet connection they were explicitly designed not to depend on. The two systems need a translator sitting between them, physically inside the building, fluent in both languages at once. That’s the gap PremLink exists to close.
The state of play: a debate that’s asking the wrong question
Every few months I’m in a room with a security architect or a BMS integrator who thinks the answer here is obvious: keep it all on-prem, no cloud dependency, full stop. A few weeks later I’m in a different room with a workplace technology buyer who thinks the opposite is just as obvious: why are we even talking about a physical box, shouldn’t this all just be cloud? For a decade, occupancy platforms and building automation systems evolved down two separate paths. Each path came with its own architectural religion.
Workplace software people default to cloud-first thinking. That’s where the interesting problems have historically lived: scale, machine learning smarts, portfolio analytics, advanced AI features. Building engineers default to on-prem thinking, because BMS and OT systems have always been built around determinism. A controller has to do the same thing every time, in a predictable amount of time, regardless of what the internet is doing that day.
Both instincts are correct. That’s the part the debate usually misses. Cloud and on-prem aren’t competing answers to the same question. They’re good answers to two different questions: how do I get smarter over time, and how do I keep functioning right now. Any occupancy platform serious about powering building automation, not just reporting on it, has to answer both at once. Neither one gets to make the other unnecessary.
That “best of both worlds” framing is the entire engineering thesis behind PremLink. Before I get into why the cloud stopped being sufficient on its own, I think it’s worth explaining why we built XY in the first place.
Why we built XY Sense in the cloud
None of this was a default choice. We built XY Sense as a cloud-native platform because the problem genuinely required cloud-scale computing. It still does.
- Hundreds of billions of anonymous data points. Every Area Pro sensor is continuously sighting people at 2-second intervals, generating anonymous X/Y coordinate events all day, every day, across every deployed floor. At the scale we now operate (tens of thousands of sensors across enterprise portfolios), that’s hundreds of billions of individual events flowing through the platform every year. Storing, indexing and making that data queryable at portfolio scale is not a workload you run on a box in a cupboard.
- Floor-level stitching and deduplication. A single open-plan floor is rarely covered by a single sensor. Coverage areas overlap deliberately, both for redundancy and because our sensors read up to 3,000 sq ft (279m²) each. That means the same person can be legitimately sighted by more than one sensor at once. The platform has to reconcile those overlapping views into a single, accurate occupancy count per space: what we internally call stitching and deduplication. Doing that well, especially as floor plans change shape over time, benefits enormously from the compute elasticity the cloud gives you.
- Layout resolution. Buildings are not static, and our data model has to keep up. Desks get rearranged, meeting rooms get subdivided, entire floors get refitted. Every one of those changes needs to be reflected in how raw sensor coordinates get mapped to “spaces” a workplace or facilities team actually cares about. That mapping, layout resolution, is a continuously maintained model, not a one-time calibration. The cloud is what lets us keep that model current without physically touching every sensor every time a wall moves.
- Pushing new intelligence to the edge. The behavioural analysis our sensors do, sit/stand detection, paths of travel, dwell time, runs on the device itself, at the edge. But the algorithms behind it keep improving, and every improvement has to reach hardware that’s already installed in the field. That’s the cloud’s job here: making new and better algorithms available to the entire fleet remotely, so a sensor a customer bought years ago gets smarter in place, with no one physically tampering with the device and no firmware loaded on-site by hand. Doing that safely at fleet scale, staged rollouts, rollback safety, confirmation that each device actually took the update, across thousands of sensors we can’t walk up to, is itself a cloud problem.
So when people ask why an occupancy platform “needs the cloud,” my honest answer is: because the alternative is running your own hyperscaler in every building you deploy into.
That was never realistic, and it still isn’t.
What is PremLink?
PremLink is XY Sense’s on-premise appliance: a real-time, on-premise occupancy protocol translator, and a fully managed one at that. It runs the same core data-processing logic that normally runs in our cloud (floor-level stitching, deduplication, and space/headcount resolution) locally, inside the customer’s building, and publishes the result directly onto their BMS as BACnet/IP and UDMI.
It’s important to be precise about what that is and isn’t, because it’s easy to hear “on-prem” and assume “air-gapped” or “cloud-independent.” It’s neither, deliberately. PremLink is cloud-resilient, not cloud-independent. The XY Sense cloud remains the system of record for calibration, space configuration, sensor health monitoring, analytics, and firmware. PremLink doesn’t replace any of that.
Resilient, not independent. That’s the whole architecture in three words. PremLink takes the one workload that genuinely cannot tolerate a round-trip to the internet, the live sensor-to-BMS pipeline, and runs it locally, continuously, whether or not that round-trip is available at any given moment.
Why did we build it?
Two problems pushed this from “interesting idea” to “we need to ship this.”
The first was resilience. Every cloud-only occupancy platform has the same latent single point of failure. The moment the building’s internet connection drops, the BMS loses its occupancy signal, and automation quietly reverts to fixed schedules: the exact behaviour occupancy-driven automation was meant to replace. For a dashboard, that’s a minor inconvenience. For HVAC sequencing or demand-controlled ventilation, it’s the difference between the feature working and not.
The second was security posture. Honestly, this is the one that came from listening to our largest prospective customers rather than anticipating it ourselves. Regulated enterprises (banking, government, pharma) run OT security reviews that a purely cloud-dependent architecture doesn’t clear, no matter how good the encryption is. The review isn’t really about the crypto. It’s about whether automation-critical data ever has to leave the building to be usable, and whether anything can reach in from outside. An architecture with no answer to “what happens to my BMS integration when a security team unplugs the WAN link for testing” doesn’t get past procurement in those environments. Full stop.
There was a third pattern underneath both of those, and it’s the one that made this feel critical to XY as a business. We had customers, some of the largest, most sophisticated occupancy deployments we’d shipped, who were looking to increase their annual ROI from their sensor deployments but the last mile to building automation and reducing operational costs was blocked by an on-prem requirement.
A cloud-first customer with a modern smart-building layer could go from sensor to occupancy-driven HVAC without much friction. A customer running a fifteen-year-old BMS with no cloud-facing integration layer couldn’t. Neither could a global bank whose security posture mandates on-premise processing as a condition of deployment. The sensors were live. The data was accurate. None of it could actually touch the building. It’s the gap PremLink is built to close.
To be clear, PremLink isn’t a rejection of that smart-building software layer. It’s the opposite. We integrate today with smart building OS platforms like Kode Labs and others, and we’ll keep deepening those integrations, because for customers who have that layer, it’s often the best place for occupancy data to land. But not every building has one, and not every building is going to get one soon. Plenty of our customers aren’t in the market for a smart building OS: budget, timing, a BMS vendor relationship that predates that category, or a security posture that rules it out for now. For them, “wait until you adopt a smart building OS” isn’t a real answer to “how do I maximize value from the sensors I already installed.” PremLink is what we built for that gap: a direct line from sensor to BMS, in the protocols the BMS already speaks, with no smart building OS required in between.
How it works
Architecturally, PremLink sits as a hybrid node between the sensor layer and both the BMS and the cloud.
Sensor layer. XY Sense and selected IAQ sensor partners stream anonymous events to PremLink over the customer’s local network via mTLS, mutually authenticated, on port 31883.
Local processing. PremLink performs the live pipeline entirely on-device: floor-level stitching, deduplication, and mapping of raw sensor events to actual spaces on the floor plan. It doesn’t use sensor IDs as a proxy for spaces. It resolves genuine space-level occupancy, because a single space can be covered by multiple sensors, and a single sensor’s data can feed multiple space layers simultaneously (an individual meeting room and a building-wide floor total, subscribed to at once, with no extra setup).
BMS output. The processed result is published locally over two open protocols, so we’re not asking customers to adopt anything proprietary at the integration layer:
- BACnet/IP, supporting ReadProperty/ReadPropertyMultiple and COV subscriptions, delivering occupancy status, headcount and percent-occupied to the BMS in roughly 400 to 700ms from a change of state.
- UDMI over MQTT, publishing schema-compliant virtual space and physical sensor device payloads, including sensor state and health messages sourced from PremLink itself rather than the sensor directly.
Cloud sync. In parallel, and entirely asynchronously to the BMS-facing pipeline, the original sensor data is forwarded outbound to the XY Sense cloud over MQTT and HTTPS, keeping analytics, calibration and configuration in sync. Every connection PremLink makes to the cloud is outbound-only. The device initiates; the cloud never reaches in. No inbound firewall rules are required, and the appliance presents no externally reachable attack surface.
Resilience. If the internet drops, the BACnet/UDMI pipeline to the BMS is entirely unaffected. Sensor-side data is buffered on a rolling, first-in-first-out basis: roughly 24 hours in-memory at the sensor, and a disk-backed buffer on the PremLink device itself, sized to the deployment, that survives a power loss rather than just a network blip. On reconnect, everything syncs back automatically. The one honest caveat: cloud analytics continuity, not BMS output, is what’s affected by an extended outage. Configuration changes made cloud-side won’t reach the BMS until the connection is restored. Automation keeps running. The intelligence layer catches back up when it can.
Security posture. PremLink runs on a hardened, container-based Linux OS orchestrated with Kubernetes. No SSH. No local shell. No unnecessary packages. No local user interface at all. Every service is an isolated, independently updatable container, and everything is managed remotely through the XY Sense cloud, over that same outbound-only channel. Combined with dedicated OT network isolation and mTLS end to end, the device is built to satisfy the same security reviews that rule out purely cloud-dependent architectures.
What building it actually involved
The honest engineering story here is that PremLink is not a stripped-down version of our cloud platform. It’s a genuine re-architecture of it.
Our first instinct was the obvious one: take the existing stitching and deduplication service, containerise it, and drop it onto the appliance largely as-is. It didn’t survive contact with fixed hardware. Our cloud logic was built assuming elastic compute: spin up whatever processing you need, scale horizontally, don’t think too hard about the memory footprint of any one process. Ported directly, it choked. Memory usage climbed under sustained load in a way the cloud simply absorbs by adding capacity, and a single appliance can’t. We had to go back through every stage of the stitching and deduplication logic and re-derive it for a fixed-resource, always-on environment, on a 16-core/32-thread EPYC processor with 64GB of RAM, redundant enterprise SSDs, and dual redundant power supplies, rather than an elastic one.
Our cloud logic was built assuming elastic compute: spin up whatever processing you need, scale horizontally, don’t think too hard about the memory footprint of any one process. The surprise was how little of that assumption we had actually leaned on. We had spent years optimizing the stitching and deduplication pipeline for scale and cost, because in the cloud both of those arrive as a bill every month. That work paid off somewhere we never planned for it to. The full pipeline for medium sized building runs on our test devices with 16GB of RAM.
What did have to change was the shift from elastic to fixed. Every stage needed a predictable resource ceiling under sustained load, on a box that cannot add capacity when it gets busy. The appliance ships on a 16-core/32-thread EPYC processor with 64GB of RAM, redundant enterprise SSDs, and dual redundant power supplies. That is more headroom than the pipeline needs, which is deliberate to enable scale for a 50+ floor skyscraper. An always-on device in a plant room does not get tuned after installation.
The second hard problem was doing that without weakening the fully managed model customers actually want. Customers don’t want a server to administer. They want an appliance that shows up pre-configured and stays that way. That’s why there’s no local CLI, no SSH, and no on-device UI. Every operational lever, from firmware to configuration, is pulled remotely, over the same outbound connection the BMS pipeline never depends on. Getting “fully managed” and “zero inbound attack surface” to coexist, rather than trading one off against the other, took as much design effort as the processing pipeline itself.
The third was refusing to let “on-prem” quietly become “worse.” It would have been easy to ship a cut-down version of our accuracy and call it a resilience trade-off customers should accept. We didn’t. PremLink runs the same stitching and deduplication logic that powers our ~99% accuracy in the cloud, translated line for line into a constrained-hardware, always-on context. Not a simplified approximation of it.
What we’re releasing, and how it evolves from here
What ships at launch is the core translation layer: BACnet/IP and UDMI output from a fully managed appliance, sensor and IAQ integration in one stream, and the resilience and security posture described above.
From here, the roadmap follows the same principle the whole architecture is built on: the right workload in the right place. Expect the on-prem surface to grow deliberately, with more BMS protocol coverage, more of our health and diagnostic signal exposed locally, and better handling of the cloud-catch-up problem, so an extended outage leaves less to reconcile when connectivity returns. What won’t change is the boundary. PremLink stays a cloud-resilient translation and automation layer, not a cloud replacement. The intelligence keeps compounding centrally. The moment-to-moment decisions keep running locally, regardless of what the internet is doing.
Why we’re excited
I’ve spent a long time watching occupancy platforms get very good at describing buildings after the fact. What excites me about PremLink isn’t the protocol translation itself. BACnet and UDMI aren’t new technology. It’s that we’ve closed the loop between accurate sensing and the systems that actually run a building, without asking either side to compromise on what it was built to do. The cloud keeps getting smarter. The building keeps running, on schedule, in real time, regardless of what’s happening outside its walls. That’s not a compromise between cloud and on-prem. It’s what good systems architecture looks like when you stop treating it as a debate.
The result is the best of both worlds for our customers.
To learn more or get started with PremLink
- Visit xysense.com/premlink
- Request a briefing on real-time occupancy-driven building automation
- The XY Sense team will be at PropTech Connect London, 9–11 September to discuss PremLink with BMS technology partners, MSIs and smart building specifiers. Meet with the team at our booth.
