Why smart building systems fail without centralized management

We often come to buildings that already have a lot of technology installed.

There may be a BMS, water leak sensors, thermostats, energy meters, water meters, access control, HVAC monitoring and several other systems. Each one was installed at a different time, usually by a different company.

On paper, the building looks very well equipped.

Then we talk to the maintenance team and find out that they use only a small part of it.

One system has its own web portal. Another sends emails. A third sends SMS messages. One needs an old application that nobody likes using. Sometimes nobody knows the password. Sometimes the person who originally managed the system left the company years ago.

The equipment is still there, but the building does not really have control over it.

We have seen this problem many times. In our experience, adding more smart devices does not fix it. At some point, the building needs one place where the staff can see what is actually happening.

The problem usually starts slowly

Most buildings do not get all their systems at the same time.

A leak detection project may happen first. Two years later somebody adds energy monitoring. Then the HVAC contractor installs another system. Later a new property manager wants smart thermostats or water meters.

There is nothing wrong with doing projects this way. In many cases it is the only realistic way to upgrade an existing building.

The problem is that every contractor usually solves only their part of the job.

The leak detection company wants its leak sensors to work. The HVAC contractor wants the HVAC controls to work. The meter installer wants the meters to report data.

Nobody is responsible for what the complete building looks like after five or ten different projects.

This is how you end up with several gateways, several dashboards, different user accounts and completely different ways of handling alarms.

Every individual system may technically work. The complete setup can still be very difficult to operate.

Five dashboards are not one building management system

This becomes a real problem for the people who work in the building every day.

Imagine that a maintenance engineer receives an alarm.

First, he needs to understand which system sent it. Then he needs to log in to the correct portal. Maybe the device has a number such as A23F0819. Now he needs to find out which apartment that device belongs to and where it is installed.

That may be acceptable with 20 devices.

It does not work well when a property has hundreds or thousands of sensors.

The maintenance team does not think in device IDs. They think in buildings, floors, apartments and rooms.

The software should work the same way.

In ROOMSYS projects, we build the system around the real structure of the property. The operator can open the building, select the floor, open an apartment and see the devices installed there.

If a leak sensor under the dishwasher reports water, the operator should see that it is under the dishwasher.

If a temperature sensor in an HVAC room stops reporting, the operator should see the room and the exact device.

This sounds basic. In practice, it saves a lot of time.

SMS and email are alerts, not a management system

We have seen building systems where SMS or email is almost the entire user interface.

An alert may say:

"Leak detected. Apartment 1407."

That is useful information, but it is not enough.

Apartment 1407 may have ten leak sensors. One can be under the kitchen sink, another behind the refrigerator, another under the dishwasher and several more around HVAC equipment.

The maintenance person still has to find the problem.

A notification should tell somebody that attention is required. The central system should provide the rest of the information.

We still use SMS, email, push notifications and audible alarms. They are useful because nobody wants a building engineer sitting in front of a screen all day.

But once an alarm arrives, there should be one place where the operator can see what happened, where it happened and what the current status is.

A good central screen should be simple

Putting all building data on one screen does not automatically make the system better.

We have also seen dashboards with hundreds of graphs, tables and technical values. An engineer may like them, but the normal building team does not need most of that information.

The first screen should answer a few simple questions:

• What is wrong?
• Where is it?
• How long has it been happening?
• Does somebody need to do something now?

The detailed data can still exist behind that screen. If an engineer needs battery history, signal strength, raw measurements or communication logs, that information should be available.

But the normal operator should not need to understand MQTT, BACnet, LoRaWAN or Zigbee to respond to a water leak.

The technology should stay behind the interface.

The building also needs to know when a sensor stops working

Flow sensors are often presented as a simple way to detect water leaks. Install a meter, watch the water flow and generate an alert when something looks wrong. In real projects, it is not that simple.

The main problem is selectivity. A flow sensor knows that water is moving through a pipe, but it does not know why. The same flow can come from a shower, a washing machine, a toilet filling, somebody running a bath or a real leak. The more water consumers you put behind one meter, the harder it becomes to reliably say that a leak has happened.

This is the first thing we look at when we design a flow-based leak detection system.

But selectivity is not the only issue. Another problem we often see is that buildings monitor leaks, temperature, energy use and HVAC equipment, while nobody monitors the monitoring system itself.

This is especially dangerous with devices that normally do nothing. A leak sensor can sit under a sink for three years without detecting a leak, and that may be completely normal.

But how do you know that it is still working?

A reliable water leak detection system should also monitor the health of its devices. The building team needs to know when each sensor last communicated, whether its battery is low and whether its gateway is online.

If a sensor is expected to report once a day and has not reported for three days, that needs attention.

Otherwise, a building can have 2,000 sensors installed while nobody knows that 200 of them stopped working months ago.

The same applies to gateways and integrations.

If a gateway goes offline, the problem should be visible immediately. The building should not discover it six months later when somebody finally needs one of the sensors connected to it.

One of the biggest problems is what happens after installation

This is something we see very often.

Many installers understand wiring, sensors and physical installation very well. Software is a different business.

During commissioning everything may look fine. Devices are online. The dashboard opens. The customer signs the project off and the installer moves to the next job.

Then real life starts.

• A gateway goes offline.
• The building changes its network.
• A certificate expires.
• An integration stops working.
• Someone replaces a router.
• A battery starts dying.
• The person who knew the system leaves.
• The software needs an update.

Now the building needs somebody who understands not only where the sensor is installed but also how the complete system works.

This is where many projects start falling apart.

The installer may disappear

There is another uncomfortable reality.

An installer is often paid for completing the installation.

Once the project is complete, supporting that system for the next five years may not be a big part of their business.

Some companies provide excellent long-term support. Others do not.

We have seen buildings where the original contractor was difficult to reach a year later. In other cases the company was still around, but it simply did not have software engineers who could fix the problem.

The result is expensive hardware that is physically installed but no longer provides much value.

This is why we think long-term ownership should be discussed before the installation starts.

Not after something breaks.

• Who monitors the system?
• Who notices that a gateway is offline?
• Who replaces or reconfigures a device?
• Who fixes the integration if an API changes?
• Who updates the server?
• Who helps the building when the network configuration changes?

If nobody can answer these questions, the project has a problem even if every sensor works perfectly on installation day.

Why we usually recommend an ongoing service

Most property owners would prefer to buy a system once and never pay for it again. That is understandable. If it were realistic, we would probably prefer it too. The problem is that connected building systems are not passive equipment.

A normal pipe or cable can work for decades without anybody thinking about it. A connected monitoring system includes gateways, networks, software, servers, integrations, user accounts, notifications and security updates.

Things change. Someone needs to be responsible for keeping the complete system working. This is why we normally recommend an ongoing service instead of treating building monitoring as a one-time software purchase.

It is not because a monthly fee somehow makes the sensors better. It is because most individual buildings do not have the technical team needed to operate this infrastructure themselves.

Running it internally is often more expensive

A large real estate company with hundreds of properties may decide to build its own technical team.

That can make sense.

For one residential building, it usually does not.

To properly support a modern building monitoring system, somebody needs to understand networking, gateways, IoT devices, software, integrations and servers.

Hiring and keeping those people only to support one building can cost far more than using a service company that already has the team.

There is also a continuity problem.

If one internal employee understands everything and that person leaves, the building is back in the same situation.

With an ongoing service, responsibility should sit with the company providing the service rather than with one specific person.

That is the part we think matters.

A subscription should mean responsibility, not just access to software

There are many software subscriptions where the customer pays every month simply to keep access to a product. For building monitoring, that is not how we think the model should work.

The recurring service should include responsibility for the system.

• If a gateway goes offline, somebody should notice.
• If devices stop sending data, somebody should be able to investigate.
• If the integration with another building system breaks, there should be a team that can fix it.
• If new devices are installed two years later, there should be a way to add them without rebuilding everything.

The important thing is not the subscription itself. The important thing is that five years after installation there is still somebody responsible for making the system work.

Centralized does not mean replacing everything

When we talk about centralized building management, we do not mean that every building should remove its existing equipment and buy everything again from one manufacturer.

In many cases that would be a bad project.

• If the existing BMS works, keep it.
• If the existing energy meters work, keep them.
• If another vendor already installed good leak sensors, there may be no reason to replace them.

The better approach is often to connect the systems that already work and bring the information the building team needs into one place.

A central system can sit above the existing equipment.

The operator sees one building, while underneath that interface there may be BACnet devices, Modbus meters, LoRaWAN sensors, Zigbee devices and other systems.

The maintenance team should not care.

Avoid building everything around one hardware vendor

Hardware changes much faster than buildings.

A sensor that is a good choice today may not be the best choice five years from now. A manufacturer can increase prices, stop producing a device or leave the market.

This is another reason we prefer the software layer to be independent from the hardware.

If a better sensor becomes available, the building should be able to use it.

If one part of the building already has another manufacturer's equipment, it should not automatically need to be replaced.

We have spent a lot of time integrating devices from different manufacturers for exactly this reason.

The building should own the system architecture.

It should not become a collection of locked vendor ecosystems.

The central screen becomes more important over time

On the first day of a project, almost any system looks manageable.

The installers know where everything is. All batteries are new. All passwords are available. Everyone remembers why the system was installed. The real test comes several years later.

There are new employees. Some equipment has been replaced. More sensors were added. A few gateways were moved. The original installer may no longer be involved.

At that point, the building needs one source of truth.

• What equipment is installed?
• Where is it?
• Is it online?
• Does it have an active alarm?
• Does it need maintenance?
• Who should see that information?

A good centralized system keeps those answers available even when the people around the building change.

What we have learned

After working with different building monitoring projects, we have learned that the biggest problem is often not the sensor or the wireless technology.

It is ownership. A building can have good leak sensors, good meters, a good BMS and good HVAC equipment and still have a system that nobody wants to use.

The equipment needs to come together somewhere. The maintenance team needs one place to see what is happening. The devices themselves need to be monitored. The software needs somebody who remains responsible after the installation is finished. That is why we believe a central screen and ongoing support are not optional extras for a large smart building. They are what keeps all the other technology useful.