Matt Parnell

Years ago, I set up a monitoring dashboard on a Raspberry Pi 3. It has generally worked very well, though performance was always a bit limited due to the CPU capabilities of the Pi 3.

Recently, this dashboard began to exhibit some strange behaviors. Various graphical elements would disappear for long periods of time. I haven’t quite figured out why – though I suspect perhaps the SD card has reached its useful life (excess writes). I’ll have to confirm that later.

In any case, I’m using this as an excuse to upgrade to a Raspberry Pi 5 and give the dashboard a refresh. I’m going to document the setup procedure here.

Write the Image

Like last time, I’m using an SD card rated for a large(r) number of writes. I’m using a Delkin Utility Endurance 32GB microSD card that utilizes pSLC flash. It’s rated for -40°C to +85°C operation with 30,000 P/E cycles and a sequential R/W rate of 95 MB/s and 85 MB/s, respectively.

I downloaded the latest “Lite” version of Raspberry Pi OS (bookworm 64-bit). With my SD card identified as /dev/sdc, I wrote the image to the SD card on my desktop PC as follows:

xzcat ./2025-05-13-raspios-bookworm-arm64-lite.img.xz | sudo dd bs=4M of=/dev/sdc

Then, I installed the SD card into the Raspberry Pi. Upon first boot, a few prompts ask to set the regional settings, and create an initial user. I created a user for myself to facilitate remote login.

Initial Configuration

The SSH server isn’t installed by default on the Lite version, so let’s get that installed and started:

sudo apt-get update
sudo apt-get install ssh
sudo systemctl enable ssh.service
sudo systemctl start ssh.service

Now, all management can be done remotely, if desired. Identify the IP address by typing:

ip addr

I’d like to keep my personal login separate from the auto-login user that we’ll use to bring up the dashboard upon boot. So, I’m adding a generic user named “pi” that will support this:

sudo adduser pi

This brings up interactive prompts to set the full name, password, and a few other identifiers (these can be blank). Make sure to copy down the password in a secure location.

We’ll want the pi user to be able to sudo, so add it to the list of sudoers:

sudo usermod -a -G sudo pi

Next, install the required packages to support Chromium. Credit to this blog for the list of packages.

sudo apt-get install --no-install-recommends xserver-xorg-video-all xserver-xorg-input-all xserver-xorg-core xinit x11-xserver-utils chromium-browser unclutter

Unfortunately, for the Pi, we’re missing one vital package that will prevent startup of X11. To eliminate the error “cannot run in framebuffer mode”, install this package:

sudo apt-get install gldriver-test

Going back to Rob Anderson’s blog again, we need to create a couple of files to support kiosk mode. First, create a file /home/pi/.bash_profile with the following text:

if [ -z $DISPLAY ] && [ $(tty) = /dev/tty1 ]
then
  startx
fi

Then, create a file /home/pi/.xinitrc:

#!/usr/bin/env sh
xset -dpms
xset s off
xset s noblank

unclutter &
chromium-browser https://yourfancywebsite.com \
  --window-size=1920,1080 \
  --window-position=0,0 \
  --start-fullscreen \
  --kiosk \
  --incognito \
  --noerrdialogs \
  --disable-translate \
  --no-first-run \
  --fast \
  --fast-start \
  --disable-infobars \
  --disable-features=TranslateUI \
  --disk-cache-dir=/dev/null \
  --overscroll-history-navigation=0 \
  --disable-pinch

Edit the URL and window-size parameters as desired. Rob has a few more details on his blog that you may wish to consider.

One other step that’s needed is to support auto-login. Type the following:

su pi
sudo raspi-config

From here, select System Options – Auto Login. I believe (though I have not confirmed) that the first step (su pi) is needed to identify which account is automatically logged in. It worked as desired, so I did not investigate further.

Install InfluxDB2

The steps below are from this page. It refers to the influxdb package – though it also seems to work just fine for influxdb2. I’m going with the latter, as I’d rather use the newer version. I’m aware that InfluxDB3 is out, but for whatever reason the installation procedure seemed far less straightforward, so maybe I’ll come back to that later.

First, set up the repository (we assume that wget is already installed):

wget -q https://repos.influxdata.com/influxdata-archive_compat.key
echo '393e8779c89ac8d958f81f942f9ad7fb82a25e133faddaf92e15b16e6ac9ce4c influxdata-archive_compat.key' | sha256sum -c && cat influxdata-archive_compat.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg > /dev/null
echo 'deb [signed-by=/etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg] https://repos.influxdata.com/debian stable main' | sudo tee /etc/apt/sources.list.d/influxdata.list

Next, install InfluxDB2:

sudo apt-get update && sudo apt-get install influxdb2

Set up InfluxDB(2):

sudo influx setup

Install Grafana

To install Grafana, I followed the steps on this page to install from the apt repository.

First, import the GPG key:

sudo mkdir -p /etc/apt/keyrings/
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null

Add the repository for stable releases:

echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list

Update and install:

sudo apt-get update && sudo apt-get install grafana 

Start Grafana:

sudo systemctl daemon-reload
sudo systemctl start grafana-server

This is a continuation of Part 1, in which:

• A new “lite” Raspberry Pi OS image was installed and configured.
• The InfluxDB TICK stack was installed.
• The kiosk/dashboard environment was set up.
• Socat and Node-RED were installed (each are optional).

Set up InfluxDB

The instructions below assume use of InfluxDB 1.8.x.

Database and User Creation

For security, InfluxDB should be configured to require authentication. The user creation details that follow are based upon those provided by InfluxData.

First, create an administrative user via the CLI. Type influx in the system shell, then the following at the InfluxDB shell (where <user> and <password> are replaced with the desired values):

CREATE USER <user> WITH PASSWORD '<password>' WITH ALL PRIVILEGES

Once this session is ended, future InfluxDB shell sessions will require a username and password. Instead of just influx, type the following at the system shell:

influx -username <user> -password <password>

A database is needed to write data to. Name this database something relevant to the organization and dashboard content. In the InfluxDB shell:

CREATE DATABASE <database>

This database needs a default retention policy. I’ve decided to keep high-resolution resolution data for 12 (twelve) hours. A longer-term retention policy will be created later that will down-sample this data. In the query below, REPLICATION 1 is required, set to “1 for single node instances” per this guide. Don’t forget the DEFAULT keyword.

CREATE RETENTION POLICY twelve_hours ON <database> DURATION 12h REPLICATION 1 DEFAULT

The default retention policy can always be changed later.

Next, create a non-administrative user with write privileges to the database. This user will be used by data providers (i.e. Telegraf, Node-RED) to post values to the database. In the InfluxDB shell:

CREATE USER <write_user> with PASSWORD '<password>'
GRANT WRITE ON <database> TO <write_user> 

Then, create a third user with both read and write privileges to the database. This user will be used for dashboard access to the data.

CREATE USER <write_user> with PASSWORD '<password>'
GRANT ALL ON <database> to <read_write_user>

Configuration File

As of right now, my configuration file is quite simple. I like clean configuration files, so the first thing I did was copy the repo-provided sample config to influxdb.conf.sample.

For the most part, I’m sticking with default settings, as they work just fine for this application. If you have time (and I recommend it), review each setting in this guide and set up your configuration accordingly.

My configuration is as follows (I’ve removed the inline comments), with a description afterwards:

reporting-disabled = false

[meta]

  dir = "/var/lib/influxdb/meta"

[data]

  dir = "/var/lib/influxdb/data"
  wal-dir = "/var/lib/influxdb/wal"

  # wal-fsync-delay = "5s"
  query-log-enabled = false

[coordinator]

  log-queries-after = "0s"

[monitor]

  store-enabled = false

[http]

  auth-enabled = true 
  log-enabled = false
  pprof-enabled = false
  max-connection-limit = 50
  flux-enabled = true

[logging]

  level = "warn"

In the configuration above:

• Reporting of anonymous data to InfluxData is disabled (reporting_disabled).
• The [meta] dir, [data] dir and wal-dir definitions are required, even though I’m using the default locations. If they’re not included, Influx DB will not start. There are some considerations for the location of these paths, particularly for the Write Ahead Log (WAL), which is a temporary cache for written points:
  • Recall that in this application, an SD card is in use. Should the WAL be located on another storage device to reduce flash memory wear?
  • Per the docs, the WAL and data directories should be on separate devices if write load is heavy. I don’t think we’re anywhere near approaching that scale for this project.
• The wal-fsync-delay directive doesn’t seem to work, so it’s temporarily commented out. The intent was to reduce the frequency at which data is written from the WAL.
• In an attempt to minimize SD card wear (at the penalty of reduced debugging info):
  • query logging (query-log-enabled) is disabled.
  • the logging level is set to warn (could be downgraded to error).
  • slow query logging is disabled (log_queries_after) – this is actually disabled by default.
  • the recording of internal statistics is disabled (store-enabled).
  • HTTP request logging is disabled (log-enabled).
• HTTP and HTTPS authorization is required (auth-enabled).
• Debugging via HTTP is disabled (pprof-enabled).
• Maximum connections are set to a somewhat arbitrary 50 (max-connection-limit).
• The Flux query endpoint is enabled (flux-enabled) to support Flux queries in Chronograf.

Compaction Issues (SBC Limitations)

While researching recommendations from other projects, I came upon this post, which doesn’t exactly bode well for running InfluxDB on a Raspberry Pi SBC (especially a 3B, with only 1 GB of RAM).

My takeaways (for now, pending future review):

• InfluxDB may be designed primarily for large-scale operations, running in the cloud, and isn’t intended to be rebooted regularly. That perception certainly doesn’t align with the IoT/SBC model.
• Many of the individuals with issues seem to be running fairly large-scale data collection operations. For this project, data collection is quite limited (which should help). Less than a dozen points collected every 5 seconds.
• Keeping the database small is critical. Deleting old data is a must-do. I’m going to target keeping the data directory to well-under my RAM size (1 GB).
• The present version of Raspberry Pi OS is 32-bit (though there is a 64-bit beta). Switching to an alternate OS that supports a 64-bit environment may help, though with potential hardware support downsides. This likely wouldn’t do much on a Pi with only 1 GB of RAM, however.
• I’ll keep an eye out for future developments…

For now, I’m going to keep the design as-is. System performance during the 2021 pool season will reveal a lot, I think.

A quick way to reveal the directory sizes for InfluxDB:

sudo du -h --max-depth=1 /var/lib/influxdb/

Final Customization

To disable the logo at startup, add the following on the existing line in /boot/cmdline.txt:

logo.nologo