Why Brick runs on free software: what you can change, and what you can’t

When we present Brick, one of the first questions from engineers and installers is: “If it’s open source, what are you selling?” It is a fair question, and the answer explains a lot about how an open-source building automation controller works.

In short: the software Brick runs on is free and stays free. ETECH LAB sells hardware built for building services, ready-made and proven configurations, and the support of people who have been commissioning heating systems for twenty years. Let’s look at what that means in practice for buyers.

What free software means

Free, or open-source, software is distributed under a licence that grants four freedoms: to use it for any purpose, to study how it works, to modify it and to distribute copies, modified or not. The source code is public.

For anyone buying a building system, those freedoms translate into three very concrete guarantees.

• Nobody can switch the software off. There is no annual licence that expires, and no server that has to authorise operation.
• Any integrator can work on it. Skills in Home Assistant and Node-RED are widespread, the documentation is public and the community is huge.
• The software outlives the supplier. If ETECH LAB closed tomorrow, Linux, Home Assistant, Node-RED and Grafana would carry on being developed and updated by others.

The licences of Brick’s components

Each component has its own licence, and they are worth knowing.

• Linux, the operating system, based on Debian. The kernel is distributed under the GPL version 2.
• Home Assistant, supervision and the app, under the Apache 2.0 licence.
• Node-RED, the control logic, under the Apache 2.0 licence.
• Grafana, charts and data analysis, under the AGPL version 3.

All are licences recognised by the Open Source Initiative. The differences matter mainly to anyone distributing modified software. For people using and modifying the software on their own system, the freedoms are the same.

What ETECH LAB provides

If the software is free, Brick’s value lies in three things.

The hardware. A controller with 22 inputs and outputs designed for sensors, actuators, pumps and valves, an expansion module and the Brick-HMI panel. It is the missing piece when you try to bring Home Assistant into an electrical panel, as we described in Home Assistant in a professional installation.

The configurations. Control flows, dashboards, architecture diagrams and wiring diagrams for underfloor and fan coil systems, already proven. They come from years of commissioning, and they make the difference between a system that works from day one and one that takes months to tune.

Support. Expertise in heating control that no free software contains: how to set a heating curve, how to coordinate a heat pump with underfloor heating, what to do when a zone never reaches temperature.

What you can change

On a Brick system you can change all of the software. In practice, the most common changes are:

• adding devices through Home Assistant integrations: a meter, an inverter, an air quality sensor;
• changing or extending the logic in Node-RED, for example a schedule linked to hotel bookings;
• building new dashboards in Grafana for an energy manager;
• connecting other systems via MQTT, Modbus or Home Assistant’s interfaces.

The Node-RED zone flow we published on this blog is an example of how it works: read it, test it, adapt it.

What is best left alone

Freedom does not mean everything should be touched. Some parts are better left as they are, or changed with great care.

• Safety functions. Flow temperature limits, frost protection, interlocks between heating and cooling. The real safety devices, such as the floor high-limit thermostat, are hard-wired and independent of the software anyway.
• The operating system, unless you know exactly what you are doing. A bad system update can stop everything else.
• The ready-made configurations, if you want to keep support. You can always start from a copy and change that.

An example: when the integrator changes

An office has a Brick system installed by a local integrator. A few years later the integrator stops trading. With a closed system the client would have to find another authorised partner for the same brand, perhaps hundreds of kilometres away, or redo the controls.

With an open system the handover is simpler. The new integrator receives the diagrams, the exported Node-RED flows and the Home Assistant configuration, logs into the controller with credentials the client holds, and within a few hours understands how the system is built. No permissions to ask for, no licences to buy, no manufacturer’s course to attend.

Only one condition has to be met: the documentation must exist and belong to the client. That is why in our handovers the updated diagrams, the credentials and the configuration export are part of the sign-off record.

Warranty and modifications

The practical question is: if I change the software, do I lose the warranty? The hardware warranty covers the controller and does not depend on the software running on it. Support for the ready-made configurations, on the other hand, only makes sense if the configuration is the one we know. So we recommend working on a copy and documenting changes: who made them, when and why.

It is the same principle that applies in any building system: whoever changes the logic is responsible for it, and whoever comes next must be able to find out.

Questions engineers ask

How do I write it into a specification? Specify characteristics rather than brands: software under a recognised open-source licence, open protocols such as Modbus, KNX and Zigbee, local operation with no mandatory cloud services, no subscriptions, and handover of the configuration and diagrams to the client.

What happens in ten years? The hardware can be replaced with another controller running the same software. The configurations can be exported. It is the opposite of vendor lock-in, which we will cover in a dedicated article.

Who updates the software? The integrator or maintenance contractor, as set out in the contract. Security updates for open-source components are public and frequent.

Does it work with other brands’ devices? Yes, and that is one of the reasons for the choice: as we saw in the article on protocols, Brick works with components from Siemens, Sonoff and other manufacturers.