Real estate: data that pays
Property owners make money by lowering costs and raising the value of their buildings. Yggio connects the systems a portfolio already has and puts the data to work where it pays.
Every system answers its own question
Properties have been partly automated for decades. The result is that a portfolio accumulates systems: 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, but each has long been an island 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 functions is the hard part
- Thin documentation
- New kinds of real-time data that are hard to capture and combine
- No shared standards or data models
- Data-model projects that run for years before anyone in operations sees the benefit
Quick payback, and a data model that keeps paying
It is not one or the other. Start with the use cases that pay back quickly: energy, leaks, fault reports and how space is really used. At the same time, let their data land in one shared model from the first day, so that what you build this year can be reused, combined and extended next year. The use cases give the quick return; the data model makes it last.
The owners who get furthest set the goal first: a figure such as a saving per square metre and year by a given date. Each step then solves something the property managers need, and each step adds to the same data structure in Yggio and in the digital twin, so the next one starts from what is already there. One portfolio working this way.
Speak the standards, depend on none
Standards such as RealEstateCore and Brick Schema make systems easier to connect and to buy, and Yggio supports them. But forcing all of a portfolio’s data into one standard before anything else happens costs years and consultant hours before the first benefit, and ties the owner to whichever platform interprets that standard. Yggio keeps the standards where they help most: as outputs.
- In: about 500 translators for sensors, BMS, meters and supplier clouds over LoRaWAN, NB-IoT, MQTT, Modbus, BACnet, OPC UA and M-Bus. The systems you have stay as they are.
- In the middle: one data model based on FIWARE NGSI-LD, with the same names, units and types whatever the supplier, and a 2D room model that ties each sensor to its room.
- Out: RealEstateCore, Brick Schema and FIWARE Smart Data Models, which are aligned with each other, plus open APIs, MQTT, Power BI and Grafana. Each receiver gets the format it asks for.
- On top: the 3D digital twin of your choice, from our partners. The data and the room links live in Yggio, so the twin can be chosen, or changed, without rebuilding anything.
- Later: if a standard stops evolving, or a better one appears, you change a mapping, not your database.
Horizontal, not another vertical stack
Closed vertical systems do not scale. Each owns its own hardware, connectivity, data and interface, so every new function means another stack beside the last. A horizontal architecture separates the layers: 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.
- Fewer interfaces and components to maintain
- Open standards and a shared data model, so a dashboard built for one building works on the next
- Less dependence on any single vendor, including us
- Several properties managed through one interface
- Sensors reused across applications: a presence sensor bought for occupancy also drives ventilation and desk booking
- Easy to connect new IoT devices and AI models, and for a third party to build a service on top
Buy in modules and keep the keys
Once the interfaces are standard, a procurement can be split into functional modules and tendered separately: hardware from one supplier, software from another and AI services from a third, all speaking the same standards. A vertical system cannot be split that way, because its parts are only guaranteed to work with each other. That is what lock-in means in practice, and it shows up at renewal rather than at purchase.
Underneath it all, the owner keeps control of its infrastructure and data and decides what is shared, and with whom. Data ownership and retention are yours to set, the platform runs where you want it, and everything you need to leave (exports, device credentials, the hardware itself) is part of the delivery, not a negotiation.
In the building
- Energy optimisation: ventilation, heating and lighting on air quality, bookings, occupancy, weather and power price
- Occupancy: how space is actually used, per room and per floor
- Leak detection: the alarm chain from the first drops
- Workplace environment: temperature, air quality, noise and mould risk where people are
- EV chargers and battery storage, alongside the rest of the building’s load
Across the portfolio
- Anomaly detection: models trained on each sensor’s own history
- Needs-based waste management: collection on fill level, not a fixed round
- Activity-based offices: bookings reconciled against measured presence
- Digital twin: the 3D twin of your choice, fed with live room-level data from Yggio
- Dashboards shared by secure link to intranets, tenant portals and reception screens
Multi-tenant, at the edge and in the cloud
A single building can be run from almost anything. A portfolio cannot, because one instance has to serve people who must not see each other’s data: the owner, several property managers, contractors per site and tenants. Yggio’s organisation hierarchy grants access at a unit and inherits it down the tree, so a contractor for two sites sees those two and a tenant sees their own floor. Getting that tree right early decides whether adding a building is a configuration change or a project.
Buildings keep running when the internet does not. Yggio at the edge keeps local rules and models running through a cloud outage and keeps sensor traffic on site, while the central instance still gives the portfolio view. Everything sits on one data model based on FIWARE NGSI-LD, delivered as RealEstateCore or Brick Schema where a receiver needs it, with open APIs, the Rule Engine with AI, and the AI Assistant for questions in plain language about the platform. Questions on your own data come next.
The platform is maintained for you and updated continuously, above all for security. An owner who builds a hub of their own, or ties the portfolio to one niche supplier’s database, takes that work on as well.
Set a number, then start with one use case
The full use case in Sensative Docs.
- Set the business goal first. A number in kronor per square metre, a cost to cut or an income to raise, agreed by the management, not only by IT.
- Start with one use case. A leak or occupancy pilot puts the same Yggio instance in place that every later use case needs, and it delivers a result rather than a specification.
- Get the organisation hierarchy right early. It decides whether the next building is a configuration change or a project.
- Pick one building, and take the question from something documented: a claims history, an energy bill, a booking system’s no-show rate.
- Insist on the exit terms in the first procurement, while you still have leverage: data ownership, retention, export, device credentials.
- Measure before and after. Take a baseline before the rollout, then follow the time per fault report and action, call-outs and unnecessary visits, avoided water damage, and energy per square metre normalised for degree days. Yggio gives the event history and the outcome of the rules; the time saved shows in your work-order system.
- Extend into the shared platform on what the first building showed, adding asset classes and domains to the same tenant rather than beside it.