ads' corner

Was asked quite a few times how I do my backups with Restic.

For more than 10 years I was using “Duplicity” for backups, but in 2019 I changed to Restic. The main reason for the change was that Duplicity still can’t handle “Big Data”, as in: larger directories. In 2009 someone opened an issue on the Duplicity bugtracker, and this problem still exists as of today. For about two years I was shifting around the problem, excluding files, trying to make the sigfile smaller. But at some point I decided that it is enough and I need to change the tool.

openHAB rules files are lazy loaded. When a rule is used the first time, the entire rule file is loaded and compiled, which apparently is single-threaded and takes a couple seconds. Even on a reasonable powerful Rasperry Pi 4. This happens both after restarting openHAB and after changing the rules file. It also means that whatever the rule in question is supposed to do has to wait a couple seconds when requested for the first time. Imagine you have a light switch, enter a room, press the switch, and it takes 5-10 seconds until the light comes on.

To work around this problem, I add a piece of code in all rules files which triggers an immediate action right after loading the file. This way the rules file is already pre-loaded (which again takes a couple seconds, but likely at a time when the rule is not needed right now).

My plan is to reinstall openHABian on a bigger SDcard, and on a Raspberry Pi 4. The latest release (v1.5) supports the new Pi 4, and I decided it’s time to do a fresh install, and see if all my Playbooks are still working.

As always, I’m searching my shell history for the right command how to install the image … but came up empty.

InfluxDB is running on a Raspberry Pi in my home network (with separate attached disk), and I installed a Grafana on top of it, to visualize crucial data.

For my openHAB system I installed InfluxDB (on a separate) Raspberry Pi. The Pi has a 32 GB SDcard, but that is not enough for storing all the data, and that Pi has additional work to do as well. For that reason I also attached a 1 TB disk to the Pi, and mounted it on /data. Now all I have to do is move the InfluxDB data directory to /data.

Recent openHAB versions come with a new HP Printer Binding, which is a big improvement over the more general IPP Binding for printers.

While I installed the Raspberry Pi with the Raspbee board on it, I had to modify the settings for the serial device. That’s done using the raspi-config tool on Raspbian.

However since I’m into automation, I don’t want to start raspi-config manually, but had to figure out how to do that in an automated way.

A while ago I got a recommendation to look into a Raspbee (from dresden elektronik) as Zigbee gateway. That looked like fun, therefore I ordered one of the devices. The first step is the installation of the Pi itself and then the software for the Raspbee.

The openHAB display in the kitchen is still the problem child. Occasionally it just stops, other times it does not refresh the HABpanel, even though it has a connection to the openHAB server. Then there is the problem with the network card in the Pi. And - ok, that’s a server-side problem - occasionally the weather stops updating. All in all that’s a lot of trouble for a display which is just supposed to run standalone.

In the latest iteration I looked into activating the integrated hardware watchdog in the Raspberry Pi. Checking the temperature it never goes above ~55°C celcius, even though the display is in an almost closed frame and can’t exchange much heat with the environment. But nevertheless occasionally the Pi just halts, and stops operating.

A while ago I switched backups from Duplicity to Restic. About time: I was using Duplicity for many years (I think I started using it around 2010, long before Restic became available) and it served me well. But recently I ran into more and more issues, especially with archives getting larger and larger. There is an 11 years old open bug in the Duplicity bugtracker, which describes a showstopper for backing up larger archives. And it doesn’t look like this will be solved anytime soon. Therefore it was time for something new.

Since I’m rolling out my backups with Ansible, it was relatively easy to create a set of scripts for Restic which use almost the same infrastructure as the old Duplicity backups. That works as expected on all our laptops. But the Raspberry Pi, which does the fileserver backups, seem to had a problem. Backups took way longer than before, jumped from 30-60 minutes (depending on the amount of changes) to constantly around 10 hours.