Updates and maintenance of an open system: who does what

People coming from closed systems are used to two maintenance models. In the first, the software is never updated: the system works as it did on handover day until something breaks. In the second, it updates itself whenever the manufacturer decides. The first leaves the system vulnerable; the second exposes it to surprises.

An open system like Brick takes a third route: Home Assistant and the other components are updated, but the decision rests with whoever runs the system, after testing. Maintaining Home Assistant in production is a discipline, and in this article we cover what gets updated, how often, how, and by whom.

What gets updated

A Brick system has five layers of software, each with its own pace.

• The operating system, Linux based on Debian, which receives regular security updates.
• Home Assistant, which ships a major release every month, with patch releases in between.
• Node-RED and its add-on nodes, updated less often.
• Grafana and the measurement database.
• Device firmware: Zigbee sensors and controllers, the router, the panel.

Not everything needs updating every single time something is released. But nothing should be left untouched for years.

How often

For a heating system we suggest this rhythm, adapted to the building:

• automatic weekly backups, with a copy off the controller;
• quarterly updates, gathering the releases published in the meantime;
• urgent security updates when flagged, assessed case by case;
• a full check once a year, before the heating season.

The calendar in the illustration puts updates in January, April, July and October and the check in September. It can move, with one rule: no major updates in the coldest or hottest weeks of the year, when a problem costs most.

Test on a copy first

The golden rule is never to update a live system for the first time. Test on a copy first.

1. Restore the latest backup onto a test controller, or a virtual machine, in the workshop.
2. Read the change log for the new releases. Every Home Assistant release lists the changes that may require configuration work.
3. Update the copy and check that everything works: entities, Node-RED flows, dashboards, users.
4. Note the fixes needed.
5. Only then update the live system, with the fixes ready, at a quiet time.

For an installer looking after many systems with the same configuration, one test covers them all: one of the advantages of ready-made configurations.

Backup and restore

The backup is the safety net for every update. Before updating, make a manual backup on top of the automatic ones. If the update causes problems that can’t be fixed straight away, restore the backup and go back to where you were.

A backup has to be tested to be trusted. At least once a year, restore it onto a test controller to make sure it really contains everything and the procedure works. It is also the best preparation for a hardware failure, as we wrote in the minimum security rules.

When an update goes wrong

Even with all the testing, something may stop working after an update: an integration that renamed an entity, a Node-RED node that behaves differently, a Zigbee device that no longer responds. Three rules limit the damage.

• Safety does not depend on software. The floor high-limit thermostat and hard-wired interlocks keep protecting the system whatever happens to the controller.
• Restore first, investigate later. If the problem affects control and can’t be fixed in a few minutes, go back to the backup and analyse it calmly on the copy.
• Write everything down. What happened, which version, which fix. Next time, on another system, it will come in handy.

The maintenance log

Every intervention adds a line to a log: date, who, what, versions before and after, outcome. It can be a simple document shared with the client. When the installer changes, or when you need to understand why a system behaves differently from a year ago, it is the first place to look.

The annual check

Before the heating season, a full visit:

• check sensors, actuators, valves and heat source, like a small commissioning, following the dedicated checklist;
• verify backups, users and access keys, revoking any no longer needed;
• check free space on the controller and the data retention policy;
• review last season’s charts, to decide on any changes to curves and schedules;
• update the system documentation.

Who does what

In an open system, roles must be written down, because anyone could step in.

• The owner or manager keeps the credentials, decides who has access and reports problems.
• The installer or maintenance contractor runs backups, updates and checks, as set out in the contract, and keeps a record.
• ETECH LAB maintains the ready-made configurations, tests new component releases and tells installers what to check.

The maintenance contract is agreed with the installer, as for the building’s other systems. There is no mandatory fee to ETECH LAB to keep the system running: a choice we explained in the article on Brick’s free software.

Remote access for maintenance

Many maintenance tasks can be done remotely: backups, chart reviews, some updates. They need secure access, with a VPN and a personal installer key, as described in the article on remote access to Home Assistant. Checks on physical components and the most delicate updates still happen on site.

Thinking long term

A system lasts twenty years; a controller’s hardware perhaps less. With an open system, moving to new hardware is not a rebuild: restore the configuration onto a new controller and the system starts again. It is the difference between a system that ages with its manufacturer and one that is renewed by those who run it, the theme of the article on Home Assistant in a professional installation.