Skip to main content

Real estate

A curved walkway running between modern buildings at sunset, glass on one side and a sculptural roof on the other

Properties have been partially automated for decades. Sophisticated systems evolved into specialised solutions, and those were often aggregated into a central building management system. The result is that a portfolio accumulates systems rather than choosing them: a BMS per building, a booking system, an energy system, meters from whoever supplied them, and sensors added one project at a time.

Each answers its own question well. The recurring difficulty is that each has long been an isolated entity that does not easily connect to the others, not even inside the same building:

  • Many systems and components, from different generations and different vendors.
  • Closed solutions, where getting at the data and the functionality is the hard part.
  • Limitations in documentation.
  • Difficulty capturing and combining new kinds of real-time data.
  • No shared standards or data models.

Yggio is the layer that makes the portfolio one thing. Sensors and systems feed in, data is validated and enriched, rules and models act on it, and the result comes out as dashboards, alarms and control.

sensors & systems  ->  collection,          ->  rules + AI          ->  dashboards, alarms
                       validation and           rule engine,            & control
                       enrichment               models, automation      in real time

The practical advice that follows from it: start with one use case and scale into a shared platform, rather than specifying the platform first. A leak pilot or an occupancy pilot puts the same Yggio instance in place that the next use case needs.

Why a horizontal architecture​

Continuing to build on closed vertical systems does not scale, and the reason is not that the systems are bad. It is that each one owns its own hardware, its own connectivity, its own data and its own interface, so every new function means another stack beside the last one.

A horizontal architecture separates those layers instead: hardware, connectivity, integration, and the services on top. Yggio is the integration layer, which is why the same platform carries a leak sensor, a BMS point and a booking system without any of them knowing about each other.

The same architecture drawn out. Below the edge and on-premise line, data sources feed a local Yggio instance: in-door climate, air quality, building utilization, central metering, local metering and external data such as weather, Nord Pool electricity price and energy bills. Beside it, building systems reach the same instance over M-Bus, Modbus and BACnet, and the owner's IT environment contributes operational and contextual data. Above the line, on the internet side, a Yggio instance connects out to AI and BI tools such as ChatGPT and Power BI, and to specialised services such as SCADA and route optimisation

What that gives a property owner:

  • Fewer interfaces and components to maintain.
  • Open standards and a shared data model, so the same dashboard works on the next building.
  • Reduced dependency on any single vendor.
  • Several properties managed through one interface.
  • Sensors and their data reused across applications. A presence sensor bought for occupancy reporting also drives ventilation and desk booking, which is what actually lowers the cost per use case.
  • Easy to connect modern IoT devices and AI models, and easy for an external party to build a new service on top.

What it changes about procurement​

Separating the layers has a procurement consequence. Once the interfaces are standard, a system procurement can be split into functional modules and tendered separately - hardware from one supplier, software from another, AI services from a third, all of them speaking the same standards.

A vertical system cannot be split that way, because the parts are only guaranteed to work with each other. That is the practical meaning of lock-in, and it shows up at renewal rather than at purchase.

Sovereignty​

The principle underneath all of it is that the owner keeps control of its own infrastructure and data, and decides what is shared and with whom. In practice that means data ownership and retention are yours to set, the platform runs where you choose, and everything needed to leave - exports, device credentials, the hardware itself - is part of the delivery rather than a negotiation.

What the portfolio runs on​

These are the things property owners commonly build on Yggio once the data is in one place. Each is an ordinary combination of the platform's parts rather than a separate product.

What it does
Energy optimizationVentilation, heating and lighting controlled on air quality, booking status, occupancy, weather forecast and power price rather than on a timetable
Occupancy and visitor measurementHow space is actually used, per room and per floor. See Office utilization
Anomaly detectionModels trained on a sensor's own history flag readings that do not fit, which is what predictive maintenance is built from
EV chargers and battery storageCharging and storage controlled alongside the rest of the building's load
Workplace environmentTemperature, air quality, noise and mould risk, monitored where people are
Needs-based waste managementCollection driven by fill level instead of a fixed round
Digital twin3D visualisation of the property, fed with live room-level data
Activity-based officesBookable desks and rooms, with the booking system reconciled against measured presence

The platform capabilities behind them​

CapabilityWhat it means here
Rule engine with AIAutomates actions on data, rules and model results, including PyTorch-based anomaly detection
AI assistant and MCPNatural-language questions against live IoT data across several LLMs. A Yggio MCP server opens the platform to any AI integration
Multi-tenantSeparates customers, buildings, users and roles through a Keycloak-based access model
Edge-cloud continuumLocal operation close to the building with central follow-up in the cloud. Local rules and AI keep running through a cloud outage
IntegrationsBMS, IoT, booking systems, energy systems and external data sources, including Grafana, Power BI and 3D digital-twin tools
Open platformAPIs, dashboards, apps and data flows on one standardised data model (FIWARE NGSI and RealEstateCore)

The two that most often decide the architecture are the last two. A shared data model is what lets a dashboard built for one building work for the next one, and open interfaces are what keep the portfolio from depending on any single supplier - including this one.

Multi-tenancy is the portfolio feature​

A single building can be run from almost anything. A portfolio cannot, because the same instance has to serve people who must not see each other's data: an owner, several property managers, contractors per site, and tenants.

That is what the Organization Manager hierarchy is for. Access is granted at a unit and inherited down the tree, so a contractor responsible for two sites sees those two and a tenant sees their own floor. Getting the tree right early is what later decides whether adding a building is a configuration change or a project.

Edge, and why it appears in property work​

Buildings keep operating when the internet does not. Running a Yggio instance in the building means the local rules and models keep running through a cloud outage, and the sensor traffic stays on site, which also answers the question a security review will ask about what leaves the building.

The central instance still gets the portfolio view. See Building automation for how the on-site options compare, including what each one asks of the firewall.

Sharing the result​

Dashboards can be embedded anywhere through a secure link - websites, intranets, customer portals and reception displays. In practice that is how occupancy or energy data reaches tenants without giving anyone an account, and it is worth deciding early who each dashboard is for, because a dashboard built for the operations team rarely works as a tenant-facing one.

How to get started​

  1. Start with one use case, not with the platform. A leak pilot or an occupancy pilot puts the same Yggio instance in place that every later use case needs, and it arrives with a result attached rather than a specification.
  2. Get the organization hierarchy right early. It is what later decides whether adding a building is a configuration change or a project. See Organization Manager.
  3. Pick one building, and take the question from something documented - a claims history, an energy bill, a booking system's no-show rate.
  4. Insist on the exit terms in the first procurement, while you still have leverage: data ownership, retention, export, device credentials. Lock-in shows up at renewal, not at purchase.
  5. Extend into the shared platform on what the first building showed, adding asset classes and domains to the same tenant rather than beside it.