ads' corner

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).

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.

In Grafana it is possible to define a variable for a dashboard and this variable can query the data source and use the returned list of values. Let's say the variable is $host, then the data query can use:

WHERE host =~ /^$host$/

and limit the current dashboard to the selected host. Also the variable will provide a select field at the top of the dashboard, which allows selecting the system one wants to see:

Now usually - according to the documentation - a "SHOW TAG VALUES" in the data source should be sufficient However as it is, this did not work for me, and the query came back empty:

> show tag values from system with key = host

Looks like I'm not the only one with this problem.

Luckily there is a way around with another query:

select distinct("host") from (select "host","load1" from system)

The result:

> select distinct("host") from (select "host","load1" from system)
name: system
time distinct
---- --------
0    host1
0    host2
0    host3
0    host4
0    host5
0    host6

Grafana ignores the "time" column and uses the second column for the host list. Voila.

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.

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. 

For various reasons I decided to use a dedicated Pi for this, and don't install this on the openHAB Pi already running here:

• The Raspbee needs software from a closed repository
• During installation and configuration I don't have to reboot my openHAB system all the time
• The headless install runs a webserver, this conflicts with the redirect I have on port 80 on the openHAB system
• I still have a couple Raspberry Pi B+ here, which I don't need for other projects

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.

After some investigation (means: --verbose --verbose --verbose debugging), it turns out that Restic identifies most of the files as new, even though they did not change at all. Some background information: the Raspberry mounts the QNAP fileserver using the SMB3 protocol. The "mount -t cifs" uses the "serverino" option, but apparently that is not enough to provide a stable inode number. And if the inode for a file changes, Restic assumes it is a new file.

On the bright side, because the content of the files do not change, the deduplication still works, and no additional content is added to the backup. The size of the backup does not increase. Still, Restic fetches all the data from the server, and that takes a long time.

The 7" Raspberry display in the kitchen is nice, but unfortunately by default the installation comes with a screensaver enabled. After a while, the display goes dark. No one wants to stare at a blank display, and touch the screen in order to see crucial information.

Our home automation got a nice 7" Raspberry display in the kitchen, showing the most relevant information (like temperature, weather, washing machine, dryer ect) on a dedicated screen. Quite handy, especially the temperature, and the one-click stop to the weather forecast.

While installing the Pi and setting everything up, I stumbled over the Icons which LXDE by default shows on the desktop. Not necessary, I want them removed. All I want on the desktop is the browser icon which directly goes to the HABpanel.

The reason is simple: if the Pi starts up, but the browser for unknown reasons doesn't come up, I don't want anyone to be confused by additional icons on the desktop. After all, usually the LXDE desktop is not seen by default.
 

The Raspberry Pi in the kitchen runs relatively stable, but recently the browser (which is showing the openHAB HABpanel) popped up a warning in the upper right corner. That's annoying, because this area in HABpanel shows the outside temperature.

Before investigating what's going on, I had to figure out a way to get a screenshot of the display - without running into the kitchen with my mobile phone. And without attaching a keyboard all the time (to press the "Print" button).

The openHAB HABpanel we have in the kitchen runs on a Raspberry Pi and uses a touchscreen display. The browser starts in fullscreen mode, and shows a specific HABpanel screen for this display. That's all nice, but by default the mouse cursor is in the way. Let's get rid of it.

In one of my earlier blog posts I reported that occasionally the HABpanel will disconnect from the server. Turns out it's not HABpanel, but it's the Pi itself which is causing the trouble. Part of the problem why it took me so long to investigate is that the display is in the kitchen, and someone had to have a look and spot the small red error message. To work around that problem, I hooked the device up in the network monitoring, and had an alarm triggered when the device is not reachable. Sure enough, that happens occasionally.

Because I moved /var/log to a small RAM disk to avoid wearing out the SDcard, all logs are lost once the device is rebooted. Had to bring keyboard and mouse to the kitchen in order to save the logfiles once the device was no longer reachable over the network.

The new Raspberry display works nice, but the screen is too bright. At night in the kitchen it enlightens the entire room - unnecessarily. Since I'm using the original Raspberry Pi 7" touch display, the brightness can be controlled in /sys/class/backlight/rpi_backlight/brightness. This "file" can hold a value from 0 (display off) to 255 (full bright).

The new display showing HABpanel works quite nice. But occasionally the fullscreen browser will lose the network connection. As far as I can see, it's not a Wi-Fi problem of the Raspberry Pi, but still annoying: in the morning the browser shows a small red warning that the connection to the openHAB server is lost, time is still correct, but temperature and the status of other devices is outdated. To fix that, I have to leave fullscreen mode, hit reload - and then there is no keyboard for going into fullscreen mode again (that's using the F11 key).

The Raspberry Pi with the touch display for the home automation system is coming along nicely. One problem to solve: how to display the openHAB HABpanel, and which browser to use?

Firefox and Chrome don't run on Raspbian. However "Chromium" (the open source part of the Chrome browser) is. That's a good start. But how to start the browser automatically, and in full screen?