Wago PLC BMS: HVAC, lighting and inverters on a single platform

The real problem: one building, many isolated systems

Most technical buildings do not suffer from a lack of equipment, but from equipment that does not talk to each other. Chillers and air handling units arrive with their own controller speaking Modbus or BACnet. Lighting is managed from a separate DALI or KNX system. Energy meters export over M-Bus. Photovoltaic inverters have their own cloud portal from the manufacturer. The result is always the same: four or five islands of information, no overall picture, and maintenance that depends on physically walking to each panel.

A BMS (Building Management System) solves exactly that: it unifies the supervision and control of every building service into a single platform. The question is which platform to build it on. In projects where the key factor is protocol heterogeneity, integration freedom and licensing cost, Wago controllers programmed with Codesys are one of the strongest options on the market.

Why a Wago PLC as the core of the BMS

A classic branded BMS ties you to an ecosystem: its controllers, its gateways, its supervision software and its per-point licence fee. A Wago controller (typically a PFC200 or an Edge Controller) reverses that logic. It is a general-purpose industrial PLC that also ships, out of the box, with the protocol stacks of the building world. That brings four concrete advantages:

• A single device acts as both PLC and gateway. There is no need for a BACnet gateway, a Modbus one and a KNX one: the same controller speaks every protocol simultaneously.
• Standard IEC 61131-3 programming with Codesys, which means the code is portable, auditable and not locked into a closed proprietary tool.
• No per-point or per-variable licences. Adding 200 new signals does not blow up the cost of the system, which is exactly what happens with most commercial BMS platforms.
• Modular industrial hardware. The same terminal system used on the plant floor, with expandable I/O modules and industrial-grade temperature range and service life.

Multi-protocol architecture: the heart of the system

The feature that defines this kind of project is its multi-protocol capability. The controller acts at the same time as master of the fieldbus networks and as server towards higher-level systems. In a typical BMS, the following coexist inside the same PLC:

What matters is not the list of acronyms, but what it enables: data comes in once and is used everywhere. The temperature read from the air handling unit over BACnet, the power delivered by the inverter over Modbus and the lighting status over DALI all end up as variables of the same program, with the same timestamp and the same alarm logic. That is what allows the BMS to make real decisions instead of merely showing pretty screens.

HVAC control: where the savings are

HVAC is by far the largest consumer in the building, and therefore where the BMS proves its return. On top of the Wago PLC we implement the strategies that each machine's factory controller cannot execute, simply because it cannot see the whole picture:

• Zone-based time scheduling with working calendar, holidays and occupancy modes, so empty spaces are not conditioned.
• Sliding setpoints driven by outdoor temperature and supply temperature, instead of fixed setpoints all year round.
• Free cooling and enthalpy control, using outdoor air whenever its conditions are better than the return air.
• Pump and fan control through drives with differential pressure or variable flow, instead of running at full speed permanently.
• Equipment sequencing and rotation to spread running hours across chillers and pumps and avoid uneven wear.
• Interlocks and technical alarms: dirty filters, frost protection, flow failure, sustained temperature deviation.

These strategies are why a well-programmed BMS consistently cuts HVAC consumption, in line with what we describe in our article on energy savings through automation. And every one of them requires precisely what the multi-protocol architecture provides: cross-referencing data that lives in equipment from different manufacturers.

Lighting: DALI and KNX under the same logic

Lighting is usually integrated over DALI (individual luminaire dimming, with status and fault reading from every ballast) or over KNX (when a building automation installation already exists). By bringing both into the same PLC, lighting stops being a parallel system and becomes part of the building logic:

• Scheduled on/off, scenes and zones, with local override from a push-button.
• Daylight harvesting: the luminaire dims according to the zone light sensor, keeping the service level with less power.
• Presence detection coordinated with HVAC, so an unoccupied zone drops both light and setpoint at the same time.
• Luminaire diagnostics: DALI reports which ballast has failed and where, which turns lighting maintenance into a planned task instead of a visual walk-around.
• Running-hour counting to plan replacement.

Reading data from photovoltaic inverters

When the building has self-consumption, the BMS gains an extra dimension. PV inverters almost always expose a Modbus TCP server (many of them with a SunSpec profile), which makes it possible to read straight from the device, without depending on the manufacturer's cloud portal or its connectivity:

• Power and energy generated per inverter and per string, with detection of degraded strings.
• Voltages, currents and device temperature.
• Status and fault codes, integrated into the same alarm system as the rest of the building.
• Instantaneous balance between generation, consumption and surplus, by cross-referencing inverter data with the power analyser at the connection point.

And once the BMS knows generation in real time, it can act accordingly: shifting deferrable loads (DHW, pumps, EV charging, pre-cooling) to hours of solar surplus, or limiting export when the contract requires it. That is the difference between monitoring your PV plant and actually exploiting it. Without integration, the inverter is a chart on a manufacturer's website; with integration, it is one more input to the building control logic.

WebVisu: supervision without a SCADA and without licences

The interface of these systems is WebVisu, the web visualisation that Codesys serves directly from the PLC itself. It is a key piece of the project and deserves a proper explanation, because it completely changes the cost and maintenance equation compared with a traditional SCADA:

• The PLC is the web server. There is no supervision PC with its operating system, its updates, its antivirus and its single point of failure. If the PLC controls, the PLC visualises.
• Access from any browser, on PC, tablet or phone, with no client or runtime to install. The maintenance technician opens a URL and sees the plant room.
• No per-seat or per-variable licences. Ten users cost the same as one.
• A single source of truth. The visualisation variables are the program variables: there is no intermediate tag layer to keep in sync and no mapping that drifts over time.
• User and permission management, with separate operator, maintenance and administrator profiles.
• Mimics, trends, historians and alarms with acknowledgement, built on the real floor plans and schematics of the installation.

In practice, WebVisu covers 100% of the supervision needs of a technical building at a fraction of the cost and maintenance of a SCADA. We already described a real deployment of this approach in our success story on WebVisu running on Wago PFC200 at a Madrid logistics centre. When the client needs advanced analytics, long-term historians or the consolidation of several buildings, the same PLC publishes over MQTT or OPC UA to a higher-level platform: local visualisation still lives in the PLC, and the analytics layer is added on top without duplicating systems.

Continuous remote support: the project does not end at commissioning

A BMS is not an installation you hand over and forget. Building use changes, the seasons change outdoor conditions, equipment is added and setpoints need fine-tuning over months. That is why the system is deployed with a secure, permanent remote connection, through an industrial VPN router with an encrypted tunnel and access restricted to the project equipment, exposing nothing to the internet. That allows us to:

• Diagnose incidents in minutes, not within the window of a site visit. Most BMS faults are configuration or communication issues and are resolved remotely.
• Adjust setpoints and schedules according to the season and the real use of the building, which is where first-year savings are consolidated.
• Update the logic and the WebVisu without interrupting service and without travel costs.
• Review alarms and trends proactively, spotting drifts (a valve that no longer closes, a filter fouling earlier than expected, a PV string producing less than its twins) before they become a breakdown.
• Keep verified backups of the program, the visualisation and the equipment parameter sets.

We cover the impact of working this way in detail in our article on the importance of remote support for incidents: when remote access exists from the design stage, mean time to resolution drops from days to hours.

What the client gets

• A single platform for HVAC, lighting, meters, inverters and auxiliary equipment, instead of five isolated systems.
• Measurable energy savings, with the instrumentation needed to prove them and to support an ISO 50001 certification if that is the goal.
• Vendor independence: standard code, open protocols and no recurring per-point licences.
• Informed maintenance: alarms with context, trends and historians instead of complaints from users.
• Real scalability: adding a building, a floor or a new data source means extending the system, not replacing it.

How we approach these projects at Bluemation

At Bluemation we design and integrate BMS systems on open platforms — Wago and Codesys among them — with one clear principle: the client must own their installation. In a project like this we take care of the full cycle:

• Audit of the existing installation and of the protocol map available on each device, which is what determines what can be integrated and how.
• Design of the control and communications architecture, including OT network segmentation and its security.
• Documented, version-controlled IEC 61131-3 programming, with reusable libraries per equipment type.
• WebVisu development based on the real mimics of the building, designed for the people who will use it every day.
• Commissioning, fine-tuning and training of the maintenance team.
• Continuous remote support and evolution of the system throughout its service life.

If you are considering a BMS for your building or plant, or you have installations running as islands and want to unify them, take a look at our BMS programming service or get in touch with us. We analyse your installation with no commitment and propose an architecture tailored to the equipment you already have.