STFN

Hello World

STFN — Thu, 01 Dec 2022 24:00:00 GMT

I've started this blog mostly because sometimes I want to say something that doesn't fit into the 280 chars of a Tweet, and is more persistent than a social media thread. This is not a Youtube channel because I don't feel like recording myself in front of a camera. Finally, I miss the times of late 00s / early 10s, when the Internet was a different, more personal place, with the blogosphere and all that.

I don't exactly know what this blog will be about, probably computers and all the silly things that come with them, but we'll see.

So, Hello World!

Raspberry Pi Pico Weather Station - part I

STFN — Fri, 02 Dec 2022 24:00:00 GMT

Collecting data is fun [citation needed], and one of the most ubiqtous and easiest to collect information around us is environment data, meaning things like temperature or atmospheric pressure. Sensors design to collect it are cheap and easy to use, and the data can be saved and manipulated using even the simplest machines.

This post will be the start of a series in which we'll make a preliminary weather station that will be able to share our local weather data with the world, be it a private service, or a feed to a public site like Weather Underground.

Here's how I am presenting weather data on my local Grafana instance:

The weather station will be using two sensors to gather the environment data: BMP280 and DHT11. BMP280 will provide us with atmospheric pressure and temperature readings. DHT11 provides temperature and humidity, but we will be only taking the latter from it, as BMP280 can measure how hot it is (or we are) with higher precision.

Parts list

List of required components:

A word on BME280 vs BMP280

Some of you might wonder why I am using BMP280, a pressure and humidity sensor, and DHT11, a temperature and humidity sensor, when I could be using BME280, which measures all three aspects at once. The simple explanation is, this is a learning project, and BME280 is around two-three times more expensive than BMP280 and DHT11 combined. It is natural that in the course of learning mistakes happen, and breaking such an expensive part would be painful. Also, using two different sensors with different communication protocols makes us learn twice as much!

Connecting Everything

Below you'll find the Raspberry Pi Pico pinout (list of pins) taken from https://datasheets.raspberrypi.com/. All of the pin names and numbers will taken from it, use it as a reference.

Let's start with connecting BMP280. That sensors uses the I2C communication protocol, so it'll need four pins: power (VCC), ground (GND), and two communication pins, SCL and SDA.

connect BMP280's VCC to Pico Pin 36 (3V3OUT)
GND to Pico Pin 38 GND
SDA to Pico Pin 1 (GP0)
SCL to Pico Pin 2 (GP1)

Now moving onto DHT11. DHT11 uses a single cable protocol, but still needs power and ground.

connect DH11s OUT Pin to Pico Pin 20 (GP15)
+ to Pico Pin 36 (3V3OUT)
- to Pico Pin 18 (GND)

Yes, both DHT and BMP280 need to be connected to the 3V3 pin as they both rely on 3 volt input.

Connecting with a breadboard

The easiest, but not solid way is to connect everything using a breadbord and male-to-male or male-to-female cables. Even if you plan to do a permanent solution later, it's good to start with a breadbord to make sure things work. It's super simple to correct any wrong connections at this point. If you're happy with how it works right now, just skip the soldering part and go straight to programming.

Soldering on a dev board

This is how I did the soldering, surely could have been better, but it does work.

Preparing the Pico

I started with soldering GPiO headers to the Pico, and then the Pico to the development board.

Adding BMP280

Now it was time to solder the BMP280 and connect it to the Pico with short leads.

Adding DHT11

Finally I soldered DHT11. I made double sure no cables were touching each other, or other pins or the Pico, that would lead to unpredicatble results. I also planned out the space on the board so that later I can add a connetion to power the board not using the USB header.

Making it run

Now as everything is connected, let's do some code writing! For development I will be using Thonny, a simple code editor that has built-in support for Raspberry Pi Picos and other microcontrollers. You can install Thonny from thonny.org. I won't dive into how to setup and use Thonny for RPi Pico, as there is already a great explanation done by the RPi team itself: https://projects.raspberrypi.org/en/projects/getting-started-with-the-pico/2

There is however one functionality that those docs do not cover, and that is installing additional packages to our Pico. Support for BMP280 is not included in Micropython, and so we'll need to install the library that will allow us to use it.

In Thonny, go to Tools -> Manage packages in the menu bar and type "bme280" in the search field. Second on the list of results there should be "micropython-bme280" and that is the package we'll need. This library supports both BMP280 and BME280, so no worries. Click on it and select Install. Once it is installed, we're fully ready to go. Make sure you install the BME280 library for Micropython, the version for the regular version of Python will not work. The library for DHT is built in in micropython so no need to do anything here.

And now the part we have all been waiting for, the code. In Thonny, create a file called weather.py (or any other, filenames don't matter for now) and paste this code snippet:

# https://github.com/SebastianRoll/mpy_bme280_esp8266
# https://docs.micropython.org/en/latest/esp8266/tutorial/dht.html

import dht
import bme280

SCL_PIN = machine.Pin(1)
SDA_PIN = machine.Pin(0)
DHT_PIN = machine.Pin(15)

i2c = machine.I2C(0, scl=SCL_PIN, sda=SDA_PIN)
bme_sensor = bme280.BME280(i2c=i2c)
d_sensor = dht.DHT11(DHT_PIN)

temperature, pressure, _ = bme_sensor.read_compensated_data()
temperature = temperature / 100
pressure = pressure / 256 / 100

d_sensor.measure()
humidity = d_sensor.humidity()

payload = {
    "temperature": temperature,
    "pressure": pressure,
    "humidity": humidity,
}
print(payload)

Don't worry, we'll now go through it line by line so that everything is clear and understandable. The first two lines are comments with links to the libraries we are using in the snippet, you can check their documentation if you're curious.

import dht
import bme280

SCL_PIN = machine.Pin(1)
SDA_PIN = machine.Pin(0)
DHT_PIN = machine.Pin(15)

Now it's time to import the two libraries we are using, one for BMP280, second one for DHT11. Afterwards we are declaring three constants that will store the information about the pins that we are using to connect the Pico to the sensors. Remember to alter those lines if you connected your Pico differently that I did!

i2c = machine.I2C(0, scl=SCL_PIN, sda=SDA_PIN)
bme_sensor = bme280.BME280(i2c=i2c)
d_sensor = dht.DHT11(DHT_PIN)

temperature, pressure, _ = bme_sensor.read_compensated_data()
temperature = temperature / 100
pressure = pressure / 256 / 100

d_sensor.measure()
humidity = d_sensor.humidity()

Preparation's done, now it's time for the main work. The first block of the code above initializes the I2C protocol, the BME280 sensor, and the DHT11 sensor. The second block is reading from BME280. One thing to remember is that BMP280 measures two entities, temperature and pressure, and the more expensive BME280 measures also humidity. However, the read_compensated_data() method always returns three values, temperature, pressure, and humidity. The third value in our case will be alwas zero, so we just discard it. Simple. The next two lines are converting the returned values to a human readable standard, degrees Celsius in case of temperature and hectoPascals for atmospheric pressure. In the third block it's time for DHT11 to do it's job, we trigger the measuring operation and save its result.

payload = {
    "temperature": temperature,
    "pressure": pressure,
    "humidity": humidity,
}
print(payload)

The grand finale, the cream de la cream! The values that we got from the sensors are saved in a Python dictionary and printed to the screen. Voila! When the magic green Run button is pressed, you should get something like this in the console:

{"pressure": 999.5192, "humidity": 48, "temperature": 22.58}

Of course, showing numbers in the console is not the most useful way of presenting data. A better way it to show them on a graph to present how they change in time, or show them on your mobile phone, or maybe make other devices automatically do stuff based on them (e.g. turn on the AC if temperature is <20C). Patience, all that will be covered in the next parts of this series.

Thanks for reading!

Astrophotography - The Iris Nebula

STFN — Mon, 05 Dec 2022 24:00:00 GMT

As the first astrophoto on this blog I present you my most recent capture, taken in the middle of November 2022. This is the Iris Nebula (also known as NGC 7023), 1,300 light-years away in the constellation of Cepheus and six light-years across. The Iris Nebula is a bright reflection nebula, the interstellar gas and larger particles are illuminated by a bright young star in the middle of the nebulosity. The bright nebula is surrounded by darks nebulae, clouds of materia where the star's shine does not reach. The annotated image shows that also three faraway galaxies also made it to the image, known only by their number in the PGC catalogue.

Acquisition details

Total exposure time: 3 hours 50 minutes. Focal length: ~440mm.

Telescope: Vixen ED114SS with 0.67x reducer-flattenner.
Camera: QHY168C
Filter: Optolong UV/IR cut.
Mount: iOptron GEM28
Focus and Dew Heater Controller: Astrolink 4 Mini S

Acquired using KStars on a Raspberry Pi running https://astroberry.io/. Processed in PixInsight.

Visit my gallery on Astrobin.com

Raspberry Pi Pico Weather Station - part II

STFN — Mon, 12 Dec 2022 24:00:00 GMT

This post is a continuation of Part I in which we build a Raspberry Pi Pico W with BME280 and DHT11 sensors and made it retrieve weather data. In this part we'll connect to Wifi to send that data to a MQTT broker on another machine.

I'll continue where I left in the previous part, so it's crucial that you first reach the state described in the end of Part I in order to continue with this part.

Starting simple - connecting to Wifi

Let's start with just connecting to Wifi. The code snippet below is taken from MicroPython docs, however I spiced it up to make debugging a little bit easier later on.

In Thonny, create a file with a nice name like connect.py on the Raspberry Pi Pico W.

import time
import network
import machine

led = machine.Pin("LED", machine.Pin.OUT)

ssid = "NETWORK-NAME"
password = "PASSWORD"

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(ssid, password)

max_wait = 10
while max_wait > 0:
    led.on()
    time.sleep(0.1)
    led.off()
    if wlan.isconnected():
        break
    max_wait -= 1
    time.sleep(1)

if not wlan.isconnected():
    for _ in range(5):
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.1)
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.7)
    time.sleep(1)
    machine.reset()
else:
    status = wlan.ifconfig()
    led.on()
    time.sleep(3)
    led.off()

Let's now dissect the code to better understand what is happening.

import time
import network
import machine

led = machine.Pin("LED", machine.Pin.OUT)

ssid = "NETWORK NAME"
password = "PASSWORD"

To start, some configuration, import the needed modules, setting up the built-in LED and defining the Wifi name and password. Set your own values of course :)

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(ssid, password)

Set the Wifi module to station mode. This is needed because Pico W by default is set in access point mode, but we will be using it to connect to another network. Then activate the interface and finally connect.

max_wait = 10
while max_wait > 0:
    led.on()
    time.sleep(0.1)
    led.off()
    if wlan.isconnected():
        break
    max_wait -= 1
    time.sleep(1)

Wait 10 seconds for the establishing the connection. Blink the LED each second. If Pico connected to Wifi, end the waiting loop.

if not wlan.isconnected():
    for _ in range(5):
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.1)
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.7)
    timer.sleep(1)
    machine.reset()
else:
    status = wlan.ifconfig()
    led.on()
    time.sleep(3)
    led.off()

This part of code is probably self explanatory. If after 10 seconds connection was not established, do two rapid blinks every 0.7 seconds, five times, wait one second and reset the machine to try again. If the connection was established, light the LED for three seconds.

Why blink the LED when we can see on the screen if the connection was established or not? This is going to be a weather station, and there is little point of having a weather measuring device always connected to a computer with a screen, isn't it? By having the LED show the connection status, we will be able to see what's going on without a screen, with the Pico running on it's own, on a balcony, in a shed or a field.

I added the reset-and-try-again code because from my experience, Wifi on a Pico W is often janky, and tends to sometimes fail connecting. Trying again often solves the issue. As an additional exercise, you might implementing resetting the Pi after an increasing interval of time, that would be a nice exercise in Python.

Sending data with MQTT

Awesome, we can now connect to Wifi, now let's send some data! This section will be connecting what we achieved in Part I with Wifi, so again, if you didn't do Part I, go there first.

As the data protocol I have chosen MQTT, because it is the industry standard for Internet of Things (IoT) communication, it's lightweight and can be easily implemented on a Pico W, so it's perfect for our usecase.

To start with MQTT, we'll need a broker. Broker is a piece of software that will collect the data send by the Pico, and allow other programs to digest that data. It has to be run on a different machine than a Pico, any Linux or Windows machine will do, but preferably it should be something that is running 24/7 to collect data without stoppages. A popular broker is Mosquitto, and you can install it from its Downloads page.

Once it is installed, you should have some additional tools available as well, the first one we'll use is mosquitto_sub, a CLI tool to subscribe to topics.

MQTT is based on subscribing and submitting to topics. A topic is like a newsletter, you can send messages to it, and everyone that has subscribed to that particular newsletter will receive everything that you are sending.

Fire up a terminal window, and run

mosquitto_sub  -t '#'

-t '#' means that we have subscribed to any possible topic. The process will now wait for any message sent on a topic to the machine that you are running the subcriber on. Leave it running in the background, it will be useful in just a moment. For now, let's go back to Thonny.

There, we will expand the script that we just created, combining the Wifi connection magic, with MQTT spells and what we did in Part I.

As for the library to use MQTT on a Pico, umqtt should be available straight from the box as a part of MicroPython core, but if for any reason it's not there on your device, try installing it the same way as we installed bme280 in Part I.

Right, so, the full code for this part:

import json
import time

import bme280
import dht
import machine
import network
from umqtt.simple import MQTTClient

led = machine.Pin("LED", machine.Pin.OUT)

ssid = "NETWORK NAME"
password = "PASSWORD"

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(ssid, password)

max_wait = 10
while max_wait > 0:
    led.on()
    time.sleep(0.1)
    led.off()
    if wlan.isconnected():
        break
    max_wait -= 1
    time.sleep(1)

if not wlan.isconnected():
    for _ in range(5):
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.1)
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.7)
    time.sleep(1)
    machine.reset()
else:
    status = wlan.ifconfig()
    led.on()
    time.sleep(3)
    led.off()

SCL_PIN = machine.Pin(1)
SDA_PIN = machine.Pin(0)
DHT_PIN = machine.Pin(15)

i2c = machine.I2C(0, scl=SCL_PIN, sda=SDA_PIN)
bme_sensor = bme280.BME280(i2c=i2c)
d_sensor = dht.DHT11(DHT_PIN)

temperature, pressure, _ = bme_sensor.read_compensated_data()
temperature = temperature / 100
pressure = pressure / 256 / 100

d_sensor.measure()
humidity = d_sensor.humidity()

payload = {
    "temperature": temperature,
    "pressure": pressure,
    "humidity": humidity,
}

qt = MQTTClient("umqtt_client", "BROKER_IP", keepalive=3600)
qt.connect()
qt.publish(b"weather", json.dumps(payload))
qt.disconnect()

The code above is basically the combination of connecting to Wifi from the beginning of this post, and gathering data from sensors in Part I, but there are some slight changes, and new parts, so let us focus on those.

import json
import time

import bme280
import dht
import machine
import network
from umqtt.simple import MQTTClient

Note that we need to import some more libraries to do the things that need to happen.

payload = {
    "temperature": temperature,
    "pressure": pressure,
    "humidity": humidity,
}
print(payload)
qt = MQTTClient("umqtt_client", "BROKER_IP", keepalive=3600)
qt.connect()
qt.publish(b"weather", json.dumps(payload))
qt.disconnect()

As previously, we are building the payload, but then something new happens. Instead of just printing it, a MQTT client is initialized, we attempt to connect to the broker, and yes, the data is send! Then it's only a matter of closing the connection, and we are done.

The BROKER_IP needs to be changed to the IP of the computer that you are running mosquitto_sub. Remember that this needs to be the internal LAN IP of the machine. On Linux you can find it using ip addr in the terminal.

Run the script in Thonny. If everything is configured correctly, the weather data should be printed out in the Thonny console. But that's not everything, go to the terminal window with mosquitto_sub running. In it you should see the payload as well! This is how it looked like for me:

stefan@home:~ $ mosquitto_sub  -t '#'
{"pressure": 1012, "humidity": 45, "temperature": 24}

Every time you run the script, a new line should appear, with new readouts.

This is a great step ahead in our journey to create a RPi Pico weather station, now the sensors data can be seen on a different machine on the network, a computer that is much more powerful than a Pico. And so that data can be manipulated, aggregated, presented on a graph or used in an automation, the possibilities are really endless here. But that all will come in Part III, where we will use the data to show it on a Grafana dashboard.

As a homework, think how would you make the Pico collect and send the data continuously, for example every 5 minutes?

Thanks for reading!

My 2022 in astrophotography

STFN — Fri, 30 Dec 2022 24:00:00 GMT

This is my 2022 astrophotograpy summary. It wasn't great, it wasn't terrible. There were some firsts for me: first time using Pixinsight, first time combining data from several nights, first time using a dedicated astro camera... I didn't spend as much time as I wanted on astro, but all in all it didn't go that bad. Let's hope the upcoming year will be better!

Images, from top left:

NGC 7635, the Bubble Nebula and Messier 52 open star cluster, 141". Astrobin
Horsehead Nebula, first time using a field flattener and combining material from 3 nights, 216". Astrobin
Rosette Nebula, edited in pseudo HOO, 216". Astrobin
Veil Nebula, first time using an astro camera, QHY168C, only 40 minutes, because I imaged on a hot summer night, and I could not stand the mosquittos any longer :) Shot using an old Russian lens, Jupiter 37A, 135mm, 40".
Soul Nebula, 60" captured through intermittent clouds.
Barnard 11 and friends, 123".
Iris Nebula, 230", almost 5 hours in a single session, finally the dust started to come out nicely. Astrobin

The Horsehead, Rosette, and Veil were imaged through an Optolong L-enhance filter, for the rest I used an Optolong UV/IR filter. Everything apart from the Veil was done using a Vixen ED114SS 600mm f/5 telescope, a GEM28 mount and a bunch of auxiliary gear I will mention in the future posts.

Plans for 2023? I want to revisit a few places, definitely try out some galaxies like M101, M33, Leo Triplet, get my first globular cluster. My dream is a good photo of the Witch's Head, maybe a glimpse of Rho Opuchi. We'll see, I am planning to revisit this post a year from now and check what I managed to achieve from my plans.

Clear skies everyone and a happy new astro year!

Powering Raspberry Pi Pico with AA batteries (Weather Station Part III)

STFN — Tue, 03 Jan 2023 24:00:00 GMT

Continuing on what we did in part II of making a RPi Pico Weather Station, now it's time to untether the Pico from the PC.

The simplest way is to connect the Pico to a USB charger or a powerbank via its USB port, it does not require any additional hardware and works out of the box, but it has some drawbacks.

The main downside of powering a Pico from a powerbank is that such devices often have a minimal required power draw for them to work, and if the connected device uses less energy, the powerbank assumes it was disconnected and turns off. While this causes no problems for phones etc, it can lead to bad consequences when using a microcontroller like a Pico. When a Pico goes to sleep (for example when waiting during time.sleep()) it draws so little energy that the powerbank may assume there is nothing connected, turns off, and the Pico never wakes up.

That's way a dumber energy source will be a better energy source for our needs. In this episode I will show how to power a Pico from 4 AA batteries.

Going back to the Pico Pinout diagram, the pin that interests us is VSYS, the second pin on the right when looking at the Pico with the USB port at the top.

To quote the Pico datasheet:

VSYS is the main system input voltage, which can vary in the allowed range 1.8V to 5.5V, and is used by the on-board SMPS to generate the 3.3V for the RP2040 and its GPIO.

What we need to carry out from that sentence is that the Pico can be powered by providing positive voltage to that pin and that voltage needs to be between 1.8V and 5.5V. This means that rechargeable AA batteries will be perfect for the job, as fully charged their voltage is around 1.3V, and four of them in series should provide us with 5.2V, well within the acceptable range.

Only use rechargeable batteries for this project, Alkaline (li-ion) AAs have a higher full charge voltage of around 1.5V, four of them will amount to 6V which can be tragic for the Pico. Be careful and if unsure, check the voltage with a multimeter before connecting them to the board.

As the microcontroller runs, the batteries will slowly lose their charge and their voltage will drop. Once the combined voltage reaches 1.8V, the board will turn off and the batteries will need to be recharged.

Connecting batteries to Raspberry Pi Pico

To connect the battery holder, I used an ARC screw connector that I soldered to the board and place short cables between its leads and between it and the Pico's VSYS and GND pins. Always double, triple check the polarity! The red cable from the battery pack is the positive that needs to go to VSYS and the black one needs to be connected to GND.

The battery holder is a simple four AA holder. The batteries are connected in series, so their voltages add up, and the whole pack has the capacity of a single battery.

Before connecting the holder cables to the Pi, make sure the battery holder is turned off.

Making the code run without a PC connection

There is a few things that we need to change with our code that we created in Part II. This is the first time in the series where filenames become important. Raspberry Pi Pico with Micropython has two special filenames: boot.py and main.py.

boot.py is always run when the Pico is powered up. There is no need to call it from an IDE like Thonny, it will run automatically. This is where we can do some initial setup, like connecting to a network. Once boot.py finishes successfully, the execution is passed to main.py, in which there will be our main program loop. With every cycle of that loop, the Pico will measure the environment data, send it to the MQTT broker, and fall asleep for a certain amount of time, and the loop will go into another cycle. Forever, or until the power dies.

Let's go with code. First the booting part, with no changes to what was in the previous episode.

boot.py

import time
import network
import machine

led = machine.Pin("LED", machine.Pin.OUT)

ssid = "NETWORK-SSID"
password = "NETWOTK-PASSWORD"

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(ssid, password)

max_wait = 10
while max_wait > 0:
    led.on()
    time.sleep(0.1)
    led.off()
    if wlan.isconnected():
        break
    max_wait -= 1
    time.sleep(1)

if not wlan.isconnected():
    for _ in range(5):
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.1)
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.7)
    time.sleep(1)
    machine.reset()
else:
    status = wlan.ifconfig()
    led.on()
    time.sleep(3)
    led.off()

And then the main part. Compared to the previous version of the code, the one major change is that the measuring and sending is now inside an endless loop. I've set the sleep time between measurements to 30 seconds, as I find a reasonable resolution for doing temperature readings. Reducing the sleep time will increase the data resolution, increasing it will extend the battery life.

main.py

import json
import time

import bme280
import dht
import machine
import network
from umqtt.simple import MQTTClient

led = machine.Pin("LED", machine.Pin.OUT)

SCL_PIN = machine.Pin(1)
SDA_PIN = machine.Pin(0)
DHT_PIN = machine.Pin(15)

i2c = machine.I2C(0, scl=SCL_PIN, sda=SDA_PIN)
bme_sensor = bme280.BME280(i2c=i2c)
d_sensor = dht.DHT11(DHT_PIN)

wlan = network.WLAN(network.STA_IF)

while True:
    if not wlan.isconnected():
        machine.restart()
    temperature, pressure, _ = bme_sensor.read_compensated_data()
    temperature = temperature / 100
    pressure = pressure / 256 / 100

    d_sensor.measure()
    humidity = d_sensor.humidity()

    payload = {
        "temperature": temperature,
        "pressure": pressure,
        "humidity": humidity,
    }

    qt = MQTTClient("umqtt_client", "192.168.0.176", keepalive=3600)
    qt.connect()
    qt.publish(b"sensors", json.dumps(payload))
    qt.disconnect()
    led.on()
    time.sleep(0.5)
    led.off()
    time.sleep(30)

Fire it up!

Now it's the moment of truth. Make sure both files are saved on the Pico. Unplug it from the PC. If you haven't done it already, connect the battery holder to the Pico. Once again, double check the polarity and whether the cables are connected to the right pins.

Turn on the battery holder. The Pico LED should start blinking slowly as it's connecting to the Wifi. If successful, there should be a long blink confirming it has connected and sending data. If there are double quick blinks, it means it has failed connecting and will restart and try again. If there were a few unsuccessful retries, turn of the batteries, connect it back to the PC and check everything again, pay special attention to the Wifi credentials.

And that's it, you are done and can boast your own, battery operated, Raspberry Pi Pico Weather Station!

How long will it last

The Pico just turned off with batteries depleted.

I did several tests of how long the Pico can run from AA batteries. With the 2450mAh IKEA LADDE batteries, I've been getting uptimes of around 50 hours maximum with the environment sensing code seen above, in temperatures betwenn 10 and 0C.

Of course the timespan will depend on a lot of factors:

the health of the batteries, fresh, healthy batteries make a big difference
work load, if the Pico mostly sleeps between short times of running, the battery runtime will be much longer
temperature outside, the colder the shorter the runtime

And that's it, you should now have a Raspberry Pi Pico that can independently of a wall socket or you computer. In the future I am planning to try running a Pico from a li-ion 3.7V battery together with a TP4056 battery charging module, and compare it with using AA batteries. We'll see how it turns out!

Big Clive's NiMH charger

STFN — Mon, 30 Jan 2023 24:00:00 GMT

So, there's this Scottish Youtuber, Big Clive, who has a channel about electronics and electrical appliances, and I've been binge watching him for the last few months. To be honest, he was one of my main inspirations in getting a soldering iron.

In one of his videos, he built a trickle charger for NiMH and NiCd batteries, and was so kind to provide the files needed to have the PCB files ordered to do the charger by yourself. The project seemed easy enough and giving a lot of satisfaction so I could not stop myself from doing it on my own.

Here is the video I'm talking about, the link to the PCB designs is in the description.

I ordered the PCBs from JLCPCB, and it was only a few dollars, and the shipping took around 2-3 weeks.

After ordering the PCBs, I started looking for the other components.

The hardest part was finding the right micro USB connectors. To match the board, the connectors had to have four pins in two pairs, and preferably all pointing downwards to the board. I could not find the right ones in any of the Polish electronics shops nor e-commerce platforms. Eventually I found the right parts somewhere around the 8th page of Aliexpress search results, so I ordered 20 of them to be safe for the future.

The rest of the elements was much simpler to find, yet I still had to source them from three different places. That was so surprising, as everything here seems to a standard electrical component. Looks like GPUs are not the only things suffering from shortage. Anyway, here are all of the required components.

Lol, only after taking the photos, soldering everything together etc I realised I did not include the LEDs in the pic.

Part list:

PCB from Big Clive's design
micro USB connectors
AA battery holders
120 Ohm resistors
470 Ohm resistors
1N4007 diodes
colour LEDs (not shown)

I first soldered the USB connector. Fit like an USB glove.

Then came the 1N4007 diodes.

120 Ohm resistors came next. I helped myself with some electrical tape to keep everything in place as I was soldering from the other side of the board.

I don't what why I kept forgetting about the LEDs, I did not take a picture as they were soldered, so here is a photo with the LEDs and half of the battery holders. I taped the holders from both ends because they refused to lie flat on the board.

And don't forget about that 470 Ohm resistor at the end of the board!

And the ready charger. For testing I put some IKEA LADDA 2450mAh rechargeable batteries which I had discharged to around 1.12 Volt.

Look how pretty it is, I really like how it turned out with those warm amber LEDs, it could as well be a nice night lamp, or I might hang it on a wall to just be there and present itself. I also added some legs so that it does not lie on the soldered ends. In the future I might make another one and combine them into a tasty charger sandwich.

And does it charge? I measured the charge current, I got 50mA throught the battery connectors. As I mentioned above, I put four discharged AA batteries to see what happens. After 48 hours I put them to my "normal charger" which reported that they were halfway charged. After four days, they were "almost charged". Clive said it should take around a week to charge high capacity batteries, and that seems to be true in my case.

Thanks for reading, that was a fun little project, took some planning and searching and waiting, but eventually turned out very well.

If you liked it, please checkout Big Clive's Patreon page.

Set up GPSD with U-blox7 GPS Dongle on Linux

STFN — Sat, 18 Feb 2023 24:00:00 GMT

If you are in hurry and want to skip my ponderings and jump straight to the solution, le click here.

The fix was tested on a Raspberry Pi running astrobbery.io, a Linux Mint PC and a Manjaro laptop. Worked fine in all cases.

Background

I bought a small and cheap GPS/GLONASS USB dongle called U-blox7. I got it mostly to tinker with GPS data, but also to use in my astrophotography rig as a way to get location, and most of all, time from GPS satellites.

Why time? Because one of my astroberry devices, Astrolink 4 Pi does not have a RTC clock, and so "forgets" the time everytime it's turned off. And when I am using it out in the open field without internet access getting the time from ntp is not possible. Knowing the current time is needed to provide correct FITS header data to astrophotography images, which in turn allows easier plate solving, not to mention simplifing going throught the history of captures.

Happy that it finally arrived in the mail, I jumped in front of my PC, went throught the GPS for Linux docs, and installed gpsd, the GPS managing Linux daemon, and gpsd-clients, a set of clients taking data from gpsd and presenting it in a useful manner:

sudo apt install gpsd
sudo apt install gpsd-clients

...and it did not work.

Problem

My GPS device was not found by gpsd. gpsd was reporting no devices when monitored by cgps:

When running cgps I got an empty table, and among the logs there was an ominous

{"class":"DEVICES","devices":[]}

Cause

A quick browse of the intertubes suggested checking if the device is actually registered by the OS. By using dmesg I found out that the usb dongle was registered by the system as /dev/ttyACM0, while all gpsd docs mention dev/ttyUSB0 as the default device. That seemed to be the cause of the issue.

dmesg output:

[ 7225.765450] usb 1-3: new full-speed USB device number 2 using xhci_hcd
[ 7226.007961] usb 1-3: New USB device found, idVendor=1546, idProduct=01a7, bcdDevice= 1.00
[ 7226.007968] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 7226.007970] usb 1-3: Product: u-blox 7 - GPS/GNSS Receiver
[ 7226.007971] usb 1-3: Manufacturer: u-blox AG - www.u-blox.com
[ 7226.031755] cdc_acm 1-3:1.0: ttyACM0: USB ACM device

Solution: configuring gpsd for the right device

One way to fix it is to stop the gpsd instance that started with the boot of system, and run a new one with the correct device.

Killing all gpsd processes:

sudo systemctl stop gpsd
sudo systemctl stop gpsd.socket
sudo rm /var/run/gpsd.sock

Starting gpsd manually, in the foreground and with debug ON:

sudo gpsd -D 5 -N /dev/ttyACM0

gpsd should now run fine and healthy. Open cgps in a different tab, and it should report a device and start collecting data from it. If not, continue to the next step:

Solving the permissions problem

It is possible that even after selecting the correct device, gpsd will still not be able to use it. This is caused by the service not having the permissions to access the /dev/ttyACM0 device. The solution is to add yourself, meaning your user, to the dialout group, which has access rights to tty devices:

sudo usermod -a -G dialout $USER

After running the command above, try again with running gpsd in the foreground. gpsd should now use the correct device and be able to access it. Once you know it works fine, ctrl+c out of the gpsd running in the foreground and run gpsd as a deamon in the background:

sudo gpsd /dev/ttyACM0

Fixing the service

Once gpsd is running fine, the next step is fix the daemon config file, so that is starts on boot already with the correct device.

To see how the service is started, I checked /lib/systemd/system/gpsd.service.

In my case, it looked like this:

[Unit]
Description=GPS (Global Positioning System) Daemon
Requires=gpsd.socket
# Needed with chrony SOCK refclock
After=chronyd.service

[Service]
Type=forking
EnvironmentFile=-/etc/default/gpsd
ExecStart=/usr/sbin/gpsd $GPSD_OPTIONS $DEVICES

[Install]
WantedBy=multi-user.target
Also=gpsd.socket

The ExecStart line shows that the service is started with the devices taken from an environmental variable. That variable is taken from the EnvironmentFile line above.

Opening that file, I saw

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES=""

# Other options you want to pass to gpsd
GPSD_OPTIONS=""

I changed it to

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES=/dev/ttyACM0

# Other options you want to pass to gpsd
GPSD_OPTIONS=""

Now it was only a matter of restarting the services

sudo systemctl restart gpsd
sudo systemctl restart gpsd.socket

And it works! cgps reports the correct device, even after restarting the whole system.

Using GPSD in KStars and EKOS

To use gpsd in EKOS, fist you need to install the indi_gpsd driver. I used the instructions from indilib.org, here's a tl;dr version:

sudo add-apt-repository ppa:mutlaqja/ppa
sudo apt-get update
sudo apt-get install indi-gpsd

Now in EKOS gear configuration view you can select GPSD under the Aux dropdown. When you start the profile for the first time, you will be asked if you want to get the system time from the GPS service. Click yes and you are done!

Powering a Raspberry Pi Pico with solar panels and an 18650

STFN — Fri, 09 Jun 2023 24:00:00 GMT

This is the description of my first attempt with powering a Pico with solar panels. There is now a second part, which is much more successful. I highly recommend to visit Part 2 as well, or instead of this post.

Reducing Raspberry Pi Pico W power consumption and a second attempt at using solar panels

Somehow this blog is turning into a "how to power things" diary, and this is not what I intended, but oh well, let's roll with it.

Introduction

In this article, I will be using the Raspberry Pi Pico Weather Station that I built in the previous parts, but the solution is versatile enough to power any microncontroller or a single board computer. The only limiting factor is that the power consumption of the device should be low enough to allow it survive the night from the battery.

If you know how much your device draws current in miliamps, you can calculate its battery life by dividing the battery's capacity in miliamphours by the current in miliamps. So for example, if you have a battery that can store 2500mAh, and a device that pulls 100mAh, it theoretically should run for 25 hours. Of course theoretically, because there always factors like losses in the cabling and connectors, or the battery losing capacity with time.

Parts List

a device you want to power, it can be a Raspberry Pi Pico, an ESP32/8666, basically anything that can take 5V input
solar panels
DFRobot Solar Manager
an 18650 battery with a battery holder
cables and preferably a stripper/crimping tool

those are not affiliate links, I just like this shop and buy most of my electronics gear from them

Word of caution:

18650 are li-ion batteries, which in contrast to your typical NiMH or NiC batteries can be very dangerous! They can explode or start a fire if handled incorrectly! I am not responsible for any damage you might do to yourself or your surroundings. Sorry.

Solar Panels

You should look for any panels that output 5V of voltage and at least 1W of power. Then again, the ones I got are rated for 1W, but max I got with them in direct sunglight was a quarter for it, so so much for accurate specifications :)

Spoiler: this will lead to problems later.

I got mine from Aliexpress. I bought two of them to provide more power to the board. Both are rated at 5V, 1W.

There are two ways of connecting solar panels with each other. There is the parallel way, and the series way.

In the serial connection, the negative of one panel is connected to positive of the second panel. The positive of the first power is connected to the device, as well as the negative of the second panel. In this connection the voltages of the panels sum up, but the total current produced is as in a single panel. If I connected my panels this way, I would get 1W of power at 10V. The solar manager accepts only 5V, so that would fry it up. Not good.

In the parallel connection, the positives of each panel are connected to each other, and the negatives are also connected to each other. The positive connector of one panel and the negative connector of another panel go to the powered device. The voltage of the system is as the voltage of the single panel, but the current is a sum of the current of particular panels. I connected my panels this way, and I got 2W at 5V, at least theoretically. Perfect!

Here's some photos from testing the solar panels. In full sunlight, two panels connected in parallel produced ~100mA at 5.6V, which gives about half a watt of power.

18650 Battery

18650 batteries are sold with or without internal safety measures. Those failsafes protect the cell from being overcharged, or discharged too much. Both those scenarios can be destructive to the battery and even dangerous all around. For this project you can use batteries without protection, as the solar power manager we will be using has it's own protective measures, but if you want to be extra safe, get the protected ones. You will also need a battery holder, if you know how to solder get one without attached cables, they are more universal.

Solar Power Manager

For this project I am using a DFRobot Solar Power Manager 2.0. It is a cheap and useful device that will serve us in several ways at once. First of all, it will work as as a relay of power from the battery to the microcontroller, and secondly, it will charge the battery from the solar panels. What is also very important, it has its own protective measured to charge and discharge the battery in a safe, controlled way. Several input/output connectors are a nice additional touch.

Connecting Stuff

Here's how everything looks connected together:

Everything should be straightfoward. I started with soldering cables to the solar panels, and connecting them to Manager's Solar + and - connectors. Then I did the same with the battery holder. Remember to pay double attention to the polarity of connections.

After checking that the connections are good and pluses go to pluses and minuses go to minuses, I connected the Pico using the USB connection. A better way would be to connect the Pico using the pins on the Manager and the ARC connector on the RPi, but for quick tests I went with just using USB.

When the battery was inserted, the Pico came to life! A magical moment <3. If yours does not want to do the same, try pushing the boot button on the Solar Manager, sometimes it needs it to start.

Making a case

As a weather station should work outside, I had to find a case that would accomodate it. The case should be rainproof, but also allow for air circulation. It also should not get too hot so that the readings would not be skewed. As this is a prototype project, I went with what I already had, and I used an IKEA bathroom cosmetics holder.

It does the job quite good, it's white so it won't get too hot, it has cutoffs for air circulation, and used upside down it provides protection from the elements.

I superglued the battery holder and the power manager to the bottom. For the Pico, I glued some velcro tapes to one side. This will allow me to replace the Pico with some other device in the future. Finally outside I glued the solar panels to some styrofoam to give them a proper angle to the sun.

Testing

I took the finished case to my balcony, put it in sunglight and plugged the Pico in. The Solar Manager reported that it is charging. The Pico started sending data to the MQTT server.

Power issues

After a few days of testing it turned out that the solar panels do not give enough power to keep the battery charged. While this setup does indeed run a bit longer than running the pico with batteries only, it's still not enough to keep it running indefinitely. I only got three days at best of run time, after that the battery is depleted. With the long summer days! I will need to look for better, larger solar panels. Another thing I will need to take a look at is reducing the power consumption of the Pi, setting up deep sleep or turning of the wifi when not transmitting. There will be updates at some time in the future, hopefully with solutions.

Thanks for reading, if you have any comments, please drop me a line on email or Mastodon. Links at the top of the page.

My thoughts as I reach 100 million points in BOINC

STFN — Fri, 04 Aug 2023 24:00:00 GMT

Today I reached one hundred million points in BOINC. It's a number as any other, but as we, humans, enjoy nice round values, so well enough it can be a time to celebrate and think about BOINC in general.

As a word of introduction, BOINC, or Berkeley Open Infrastructure for Network Computing is a system that allows for scientists to tap into compute resources of ordinary people. If a researcher requires vast computational resources to, say, simulate a galaxy, they can create work units that will be sent to volunteers' computers, calculated by them, and returned to the project's database. The whole idea is based on the fact that computers of today have become powerful as never before, yet most of the time they use mininal resources, as the user is doing some light tasks like internet browsing. Why not use those idling CPU cores, those GPUs that can compute sun rays bouncing of a windshield of a virtual car hundreds of times a second? Modern research requires a lot of processing power as volume of data grows exponentially. Sounds like a perfect match. The theory is beautiful. The outcome? Not so much.

My BOINC journey

I discovered BOINC in the midst of the pandemic, in April 2021. In those tragic times, I, as many other people, realised I had some old hobbies and interests that I forgot a long time prior. For me, it was astronomy. I decided to come back to it. I joined internet forums (still my favourite way of belonging to an internet community), bought books, started reading about the current research. I even bought my first telescope and started taking pictures of our Cosmos (both of which turned out awful at the beginning, but that is a story for another time).

During that time I did some crunching for folding@home, they were the talk of the party because of their involvement in research for the Covid vaccine. So I started looking if there was something like f@h but for astronomy. And it was, this is how I came across BOINC.

I started with my old desktop, with a Intel i5-4460 and Nvidia 750Ti. Now I am crunching on my current, much more powerful desktop, with a 16 thread AMD 3700X and a RTX2060. Occasionally I also pull out from the basement that old desktop, but now with a RX470 ex-mining GPU. I've been also crunching on a Raspberry Pi.

As a fact, BOINC has been lately the sole reason I want and buy more powerful computer hardware, if it wasn't for it I would be happy with a much less powerful GPU, as I don't game much.

And so, after 2 years and four months of regular crunching, I reached 100 million BOINC points. Those points of course are just virtual boasting numbers, shared resources to the scientists. But I do feel good that in a tiny tiny way, I contributed to scientific research, and maybe what I did will make some breakthrough I bit closer to reality. This is what BOINC is all about, giving your resources and not expecting anything in return, apart from progress.

Projects I contribute to

This is a short summary of the projects I currently crunch, to learn more about them, visit their respective science pages.

Universe@Home

Run by the Nicolaus Copernicus Astronomical Center of the Polish Academy of Sciences in Toruń, Poland, this BOINC project simulates the lifetimes of stars and black holes to better understand the mechanisms behind their evolution

Einstein@Home

Einstein@Home is currently one of the most active BOINC projects, it's goal is to research gravitional waves by analysing data from radiotelescopes and satellites.

MilkyWay@Home

This project is all about our own galaxy. It's goal is to study its history by analyzing the current structures of stars in the Milky Way.

Asteroids@Home

This project, located in the University of Prague, focuses on researching asteroids, their dimensions and spin based on the available imagery.

World Community Grid

In contrast to the other ones, this project is about life sciences, recently mostly about looking for new cures for cancer and covid. The project owners had to change infrastructure last year and had months of technical issues, but seem to be getting more and more stable lately. Perfect for people that feel that astronomy is too far away from real life problems.

Gaia@Home

This project has been carried out by my own Adam Mickiewicz University in Poznań, it focused on researching comets, however in the last few months it has been active very rarely and looks dead at the moment.

Future of BOINC

Last year the creator of BOINC wrote a long article talking about his views on BOINC, and one of the main points is that, according to him, BOINC "plateaued in 2007" and since then has been in decline. I haven't been that long with BOINC, but even in my short period, I can understand why he sees it this way. The BOINC projects list is full of dead links, and since I joined I have not seen a new, stable project. The beautiful idea is just not surviving in reality.

Reasons for this are many, among them lack pf publicity and media converage, underfunded academia, and the software itself being complicated for both scientists and volunteers (don't get me started on setting up proper GPU drivers on Linux). Another issue are the rising energy prices. Contributing your computer to BOINC is not as free as it sounds, running the CPU and GPU with a heavy load means increased heat, noise, wear of parts, and a much higher energy bill. One month when I run my crunchers at full tilt 24/7, my energy bill increased three times. That is not something many are willing are accept just for internet karma, especially when taking into consideration concerns about global warming and the source of all that electricity.

A bit of a silver lining is that with the downfall of crypto mining, the market is flooded with cheap GPUs that are perfectly valid for actually doing something good, and getting powerful resources is as easy as ever.

But to sum up, BOINC right now is the realm of diehards and geeks, and not everyone watching cat videos on a laptop, as BOINC creators envisioned at the beginning. Nobody knows about it, joining it is not that easy, and the price to pay is high. And when you actually join, there is not that much choice what to crunch.

And this makes me super sad, because BOINC is this beautiful grassroot initiative that is very much in line with my love for the non-profit, federated Internet driven by volunteers.

I will continue to crunch as long as I can, as long at energy prices allow me to do so and as long as the projects exist, and I invite you to join me. Drop me an email, talk to me on Mastodon, I will be happy to help and guide you into crunching yourself.

What do you think? Are you BOINCing? Let me know.

State of my homelab in August 2023

STFN — Tue, 15 Aug 2023 24:00:00 GMT

My center of operations

I thought I might do a series of posts in which I show the status of my homelab, with updates each time something significant happens. This way I will be able to log the changes to my setup, how it evolves over time, with updates and downgrades. When read at some point in the future, it might turn out to be interestting story? We'll see. Anyway, every series has a start, and so has this one, this is the first instance of the State Of My Homelab.

On the left, a TP-Link router provided by my ISP. The provider delivers an Ethernet cat cable straight from the wall, so no need for a modem. This is the first flat I'm seeing this, in my previous one there was a coax first, and a fiber optic later coming from the common parts of the block.

The white box is a Netgear GC110 smart switch, which currently I am using in a dumb mode, with no special configuration applied. I want to learn advanced networking, VLANs etc, but I never really sat down to it. Yet. Cool thing about it is that it has SFP ports, so one day I might use with fiber optics to connect stuff together? Maybe connect my future house with my future shed?

On top of the switch is my "dev server", a Raspberry Pi 4b which I use to test out stuff before pushing it to my "production". The Pi is running Raspbian, right now I am using it to test out Mullvad VPN, and a bit of BOINC, hence the fan. With light load, I never needed a fan if the case was open enough. Speaking of the case it's a TerraPi Alpha SSD Case, and I highly recommend it, that case has served me for years, it's great quality and the mounting is ingenious. The Pi is using an SSD for storage and SD card for booting. I wanted to use the SSD to host the system, but the Pi is very picky when it comes to USB-SATA controllers and SSD brand, and this combination did not want to cooperate.

Below the shelf, on the floor there is an IKEA Tradfri gateway, which I used to connect to my Home Assistant, but for now it's now doing anything, in this generation of homelab I'm not running Home Assistant at all, got bored with it. Maybe next time.

Finally, on the right is the main production server of my homelab, Lenovo X240 with Intel i5-4300U and 8GB of RAM. I bought it as a cheap dispensable laptop to take when I wouldn't want to carry expensive hardware on me, but I could not stand the screen quality and resolution, so it was promoted to become a server. I wish I could upgrade the RAM, but it has only one slot, and cannot take more than 8GB sticks

The Lenovo mainframe is also sporting an SSD in an external case as storage, and I removed both of the batteries, as they are not needed, and I don't want to risk them bloating.

The secondary usecase of the server is a small file sharing server via NFS. I don't have yet a proper NAS, but the few hundred gigs available on the external SSD are a convenient way to move stuff between computers in my LAN.

What I'm hosting

Dashy

A homelab dashboard, this is what the screenshot is showing.

Calibre

An ebook storage and management system

Metube

For downloading videos from Youtube. Surprisingly fast!

Podgrab

Downloads and stores podcasts. I mostly use it for data preservation (aka hoarding), I listen to podcasts only my phone with the iOS Podcasts app :)

Airsonic

Listen to MP3s, awful UI but it works. No, seriously, the UI burns out your eyes.

RSS

RSS is the best thing out there for following blogs. No algorithm, no ads, just a feed. For my RSS client I recently moved from Tiny Tiny RSS to FreshRSS.

qbittorent

Those Linux ISOs won't download themselves.

Concourse

Tool for creating CI/CD pipelines, something like GitHub actions but self-hosted. One of the tools that I am always planning to learn and never get around to it.

Grafana

Dashboards, Grafana get's data from InfluxDB and Prometheus and makes nice graphs out of it.

InfluxDB

Time series database, together with Telegraf I am using it to gather statistics about the system, like Docker container stats. Also sometimes I'm using it to fetch and aggregate data from MQTT.

Uptime Kuma

For monitoring uptime of your sites. I use it to see if this blog is up.

ADSB

I'm self-hosting an ADSB receiver to watch airplanes. This is a topic for a separate blog post in the future.

Pi-Hole

The single best thing to remove ads and trackers when browsing the Internet.

Permawiki

My self-hosted instance of Wiki.js where my girlfriend and I store resources on cultivating our garden.

FlatNotes

For making quick notes and drafts of blog posts.

Prometheus

Prometheus together with node-exported to gather metrics on my homelab state. The metrics are then ingested to Grafana and shown as dashboard graphs.

To quote a famous American poet of the 21st century (Drake):

started from a Raspberry Pi Zero W, now we're here.

Thanks for reading!

A DIY off-grid 12V powerbank

STFN — Sun, 27 Aug 2023 24:00:00 GMT

There is now a continuation of this post, in which I made an LTE modem to work with this powerbank: Off-grid LTE modem

The problem

One of my hobbies is astrophotography, and that is something that is best done off-grid, far away from light sources such as cities. Astrophotography also requires a steady source of electricity to power the equipment, cameras, computerized tripods, a laptop etc. These two aspects combined suggest using a portable power source. Typical powerbanks won't do, as they give out 5 volts to charge a phone or a tablet, and I need 12V of voltage, with currents of several amps for hours at at time. There are three basic solutions how to get a portable 12V power source:

buy a cheap 12V powerbank dedicated to astronomers
buy a very expensive, powerful portable power source like a Jackery
build your own power source

At first I went with option 1, I bought a Bresser Power Station which was ok at the beginning, but once I move to a cooled astrocamera with a large power requirement, it just would not provide the needed power level (it was far below 9000).

As time passed and I got better with electronics and soldering, I decided I now know enough to build my own power supply.

Preparation

I admit with shame that I do not have any photos from the time I was building the powerbank. I built it some time ago, and it was an iterative process, and I was not sure it will end up here on the blog. I hope the photos and diagrams I am showing here are understandable enough to show how its construction.

Battery

The first thing to decide was the battery. I needed a steady supply of 12V with enough capacity to work through a long night. I also wanted the battery to be safe and keep the factory capacity for a long period of time. On the other hand, I did not require it to be lightweight, as I would only carry it to and from my car. Budget was also an important factor.

I dismissed Li-ion batteries right away because of their flammability and cost. And they would require a BMS (Battery Management System) into which I do not want to delve yet. LiFePo4 would be awesome, but again the cost is for the time being prohibitive for me. So I settled for the good ol', tested and tried AGM lead acid batteries. They weight a lot but that's not really an issue for me, they can survive a lot of cycles without losing too much capacity, and they have a reasonably low self-discharge. The price per watt hour is not great, but also not terrible.

I would love to have an RTG like the Vikings, but hey, we don't live in the future yet.

Going back to Earth, I searched for a good model of a battery, and I've settled with a YUASA REC22-12 deep-cycle battery. It has a capacity of 22Ah, which suits me fine, and is designed to survive a lot of cycles from full to almost depletion. I could have gone for a GreenCell with half the price, but I read mixed opinions about their longevity.

Case

For the powerbank case I went with the simplest and sturdiest option, I bought a plastic tool box with internal dimensions enough to store the battery and the cables. Plastic is also easy to cut, and I had to do quite a few holes for the connectors. Speaking of connectors...

Connectors

For those, I went with XT60 sockets. XT60 is a safe overkill for the current I will be using, and it's cheap and easy to solder. They are also, at least in my opinion, sturdier than the 2.1 x 5.5mm barrel jacks.

Additional parts

The remaining parts are the cables, fuse, voltage meter, internal connectors for the cables, and finally a USB charger for phones. As for the USB charger, it took me quite some time to find, but eventually the "motorcycle or car usb chargers" is the category I found the one that I needed.

Overdischarge failsafe protector

One additional part that I added to my build is the overdischarge failsafe. It turns off everything taking power from it when it senses that the battery voltage fell below a set threshold. Batteries, especially lead acid ones should not be discharged too much, as then they can lose a lot of their capacity. 12V lead acids should not be discharged below 10.5-11V. You can go without this failsafe by just being careful and regularly monitoring the battery voltage while using it, I wanted to be double sure and have an automatic cutoff in case I forget to turn the equipment off or something breaks.

Parts list

YUASA REC22-12 battery -- 370PLN -- 83EUR
Qbrick System Pro 500 Basic tool box -- 65PLN -- 15EUR
16AWG silicone cable (3 meters should be enough with a safe margin) -- 7PLN -- 2EUR
XT60 plug and socket (x2) -- 10PLN -- 3EUR
5 pin electric connectors (x2) -- 6PLN -- 2EUR
10A fuse with mount and cable (pack of ten) -- 14PLN -- 5EUR
3A USB 12V charger -- 40PLN -- 10EUR
15V analogue voltmeter -- 10 PLN -- 3EUR
assorted car cable connectors -- depends on the pack, but around 15PLN -- 5EUR
overdischarge protection -- 20 PLN - 6 EUR
total: 557PLN -- 134EUR

I am not providing any links as such small electronic components (with the exception of the battery) usually are not of a specific brand, so the best way to buy them is just to search for their name on any electronic components store and buy the that looks right.

For this project it is required that you have a soldering iron and know how to solder, as the connectors will be soldered.

Additionally you need a 12V lead acid battery charger, any car battery charger will do just fine.

For the tools, a drill and a hole saw are required. A glue gun and, a stripping tool and a connector crimper will be useful.

Connecting stuff

The overall design of the electrical system is simple: a power source and four receivers: a voltage meter, one USB charger and two XT60 sockets. From the battery power goes to a cable box that splits the power to all receivers. The receivers are connected in parallel. This way they all receive the same voltage, 12V, and the current taken from the battery is the sum of currents used by the individual receivers.

I have chosen 16AWG silicone cables as they should handle the currents I am forecasting to be used in the setup, and are resistant to heat and cold. One thing I could have done better was to use different colours for positive and negative, but I handled it with some red markers.

Battery and power switch

I started with fitting the battery. When looking for both battery and the case, I matched the external size of the battery with the internal volume of the case, so the battery fit snugly inside. I put some cardboard to fix it in place. If you plan to carry the powerbank a lot over rough terrain, consider fixing the battery in a more robust way, maybe with some angle brackets.

With the battery done, I drilled a hole for the switch. I used a small diameter hole saw, placed the switch and fixed it in place with hot glue.

The next part was the connection between the battery and the switch. It does not really matter from which terminal of the battery you start, I went with the positive side as that was closer to the side of the case I decided to be the control panel. For the connection. I used one of the fuses. The fuse casings I bought already had cables attached to both sides, so I just crimped the right connectors to both ends. For the battery end I used an M5 open connector, but the switch end I used the connector that came with the switch itself.

The switch has three connectors, not exactly sure why, so by testing I found out which two make a connection when the switch is ON, and I connected the lead from battery to one of those. One connection done.

Optional overdischarge protector

I went with adding an overdischarge protector but you can skip it. In my setup, I first two the PCB board and screwed it to a piece of plastic. Between the board and the plastic I placed a thermal pad I had lying around from some M.2 hard drive. I added it to have a soft base for the PCB and for some thermal conductivity. Then I glued the plastic piece to the case with hot glue. I connected the negative lead from the battery and positive lead from the switch to the IN port of the protector, and placed leads from the OUT port to the cable boxes. Finally, I configured the protector to turn off the battery at 11.5V. The battery manual says it can be discharged down to 10.5V, but I went with a higher value to increase its longevity.

Cable boxes and voltage meter

Next part was to prepare the two cable boxes which will act as manifolds to distribute the energy to the devices. I went with five element connectors to have four devices available (the fifth cable goes to the battery). I glued them to the bottom of the case. To one of them went the cable from the switch, to the second one I connected the negative terminal of the battery.

From now on, make sure that the power switch is in the OFF position, or disconnect the battery from the cable boxes!

Now came the time for the first device that will receive the electricity coming from the battery, and that is the voltage meter. The one I have has a round casing and for screws to secure it in place. I drilled the whole for the casing with a large hole saw, and eyed four holes for the bolts. It got in nicely, and I put nuts on the bolt to make sure it does not fall out. I placed one cable from the positive cable box and one from the negative cable box and connected to the meter by round cable connectors. Easy stuff.

Now, when you turn on the switch, the voltage meter should show the current voltage. If the meter needle goes the other way to negative it means you connected the cables the wrong way round. Ask me how I know this.

XT60 sockets

Now the hardest part. I had to make square holes in the box to fit two XT60 connectors. I tried using a hairsaw, I think that's the correct name? but it did not work out. I eventually drilled some holes with a wood drill, and connected them with a knife. Once I had large enough holes, I soldered the cables to the XT60 sockets and fastened them to the plastic case with small screws and more hot glue. The XT60 sockets have small + and - signs on them, make sure you connect them the right way to the cable boxes.

USB charger

The last step was very simple, I had to drill a round hole like for the power switch, I placed the USB charger in the hole, secured it with the provided plastic nut, and finally I took two lengths of cable, crimped car connectors at the ends, and connected the USB charge to the cables boxes.

Testing

Before plugging anything of value, I tested the powerbank with a multimeter. I turned the switch on, and checked the sockets whether they had the proper polarity and voltage. I then tested the USB charger with a cheap USB light. Everything was working fine, so I plugged in my phone, and it started charging! Finally I plugged my whole astrophotography setup to one of the XT60 sockets and it booted and operating like normal. What a relief.

12V light source

One of the use cases I have for this powerbank is to power the lights for my garden shed. I did not want to use LED strips or anything similar, as the lighting was meant to be warm and house-like to make the whole place cosy. After a lot of searching I finally found a lightbulb with a warm tone and a standard E14 thread that runs on 12V voltage. For the mount, I bought a simple IKEA lamp, cut off the 220V plug and soldered an XT60 connector. Works like a charm and gives really nice light.

Astrophotography setup

I don't want to talk too much about my astrophotography setup here as there will be a separate post about it, but to give a tl;dr version, I am using an Astrojolo Astrolink 4 Pi that takes 12V from the powerbank and uses it to power a Raspberry Pi together with all the other astro components that need the electrons to operate.

Real life usage

Because of bad weather so far I had one chance to test my project in full, and it worked perfectly, provided stable power for three hours and still had charge for a few more. And I could charge my phone at the same time.

Charging

To charge the powerbank, I am using a standard car battery charger. For now I am putting the charger clips right on the battery terminals, but one of my improvement plans is adding a separate connector only for connecting the charger. It will be a nicer solution and won't require opening the case to charge the powerbank.

Next steps

In the future I am considering adding another battery to connect them in parallel, doubling the overall powerbank capacity. Maybe I will also add a 220V converter, but for now I don't really have a use case for it. An USB-C power delivery charger would be awesome, but I have yet to find one that does not look super cheap and suspicious. And I don't want to plug my laptop into something looking like a 5$ e-waste.

So, this is it, I hope you like it. If you have any questions, comments, suggestions, or want to show your power solutions, hit me up on Mastodon or send me an email. I would love to get any feedback from you, even a short email saying "I read it until the end", or "this post sucks!!!!11one" will be appreciated. Links at the bottom of the page.

NGC 7000 - North America Nebula

STFN — Sat, 09 Sep 2023 24:00:00 GMT

Finally a photo of the sky!

The largest red blob in the middle of this photo is the North America Nebula (NGC 7000 or Caldwell 20), an emission nebula in the constellation of Cygnus. Above it is the Pelican nebula (IC 5070), both of them swimming in a sea of minor red clouds. Both nebulae are of the emission type, meaning they are giant clouds of atomic hydrogen and oxygen, which are being excited by nearby young, hot stars (just like teenagers close to other teenagers), and emit light (not like teenagers).

I imaged those teenagers, I mean nebulae, over three nights in the beginning of September 2023.

Image Processing

Total acquisition time is 5 hours 50 minutes, in which 2 hours were for the RGB version, and 3:50 for the narrowband. All captured in 5 minute exposure at -15C sensor temperature, gain 10, offset 50.

Most processing was done in Pixinsight, with final touches in GIMP.

I photographed the nebula using two different filters, the first one was UV/IR filter, and the second one was a narrowband Ha + OII duoband 5nm filter from SVO. After stacking them separately in WBPP I got two masters, one wideband RGB and the second one in narrowband.

The initial step was to register them with one another so that the stars align.

Then I moved to processing the narrowband image:

Dynamic Background Extraction
SCNR to remove surplus green.
Soft stretch (I am using EZ Scripts suite)
Starnet2 to remove the stars
Unsharp Mask
Final stretch

With that done, I switched to the wideband RGB image:

Dynamic Background Extraction
Photometric Colour Calibration
Soft stretch
Tiny bit of Curves transformation to slightly reduce the stars bloat
Starnet2 with star mask to extract the stars

Now with narrowband image done and the star mask ready, I moved to PixelMath to combine them using a formula I came across several times on different internet forums, which for some magical reason works much better than simple addition: ~((~narrowband)*(~star_mask)). This combining is a quick step, and I run it several times with different amounts of Curves transformation to see what suited me best.

I saved the combined image as .tif and opened it in GIMP for some final touches, a bit of cropping, unsharp mask, saturation and curves tweaking.

Gear Used

iOptron GEM28 equatorial mount
QHY 168C cooled astrocamera
an old and moldy M42 lens 200mm, f/3.5
ZWO ASI 120MC and ZWO Mini guider for guiding
Astrojolo Astrolink 4Pi running Astroberry OS for session control and image acquisition.
my DIY powerbank to power everything.

Final Thoughts

This is so far my best astro picture with the longest acquisition time. Yet, after spending days looking at much better astrophotography on Astrobin and Astropolis, it does not feel that good to me. But well, I feel I made progress since the last time, and this is what counts.

I need a better lens, this one has an awful CA which makes those atrocious halos around stars, but that is something that needs to wait until I get some budget.

That's it, hope you liked it. And as a bonus, the narrowband starless version:

Astro Archive - The Horsehead Nebula

STFN — Wed, 04 Oct 2023 24:00:00 GMT

Recently I had an idea to go back to my older astrophotography and try editing those photos again with new techniques that I learned along the way to see what happens and whether I can pull out some new stuff out of old data.

I asked on my Fediverse account if people were interested in seeing such content, and the majority said yes, so here we go. That's how the idea of Astro Archive was born.

For the first image to retry I chose my old attempt to photograph one of the staples of the northern winter sky, the Horsehead Nebula in the belt of the Orion constellation.

I imaged Orion for three nights in March of 2022. Total acquisition time was 3 hours 36 minutes, shot only in narrowband using the Optolong L-enhance filter and an astromodded Canon 1200D DSLR.

Most processing was done in Pixinsight, with final touches in GIMP.

The telescope I used then was a Vixen ED114SS, which I sold this year because I was not happy with its large dimensions and low image quality.

The main point of this photo is the Horsehead Nebula, it's striking shape of a, well, horse head, visible upside down in the centre. This black cloud of cosmic dust contrast with the glowing reds of the background emission nebula. There are not many stars visible above the horse, as the light is blocked by the larger nebula from which the horse stems. Only two stars shine strong enough to make their own small nebulae, IC435 and NGC2023.

On the right there is the magnificent Flame Nebula, NGC2024, a mix of glowing hydrogen and darker dust and smoke burning in the sky. Surrounding the Flame there are a few smaller nebulae, lighted by their stars.

Both the Flame and the nebula surrounding the horse are glowing because of the immense power of Alnitak, the leftmost star in the Orion Belt. Here visible as a shining ball of light just below the Flame. Alnitak is actually a trio of stars, the brightest of them being a blue supergiant, with a mass of 33 solar masses and 21 thousand brighter than our star.

In the lower part of the image, one can see the intricate lines of the hydrogen dancing in the solar winds, looking like a draped curtain. Sometimes the solar winds collide, and cause hotspots that shock warm the hydrogen ever more, making it glow brighter.

At the bottom of the image there are two interesting structures that seem not be named. It looks like hydrogen is lit by a nearby star and formed in its solar wind, once angled away from the star, once surrounding it. I do now know if this is the correct explanation, or are those two just visual companions, being in the same line of sight, but physically totally distant.

Finally, lurking somewhere in the background are galaxies other than our own, too faint to see, only their location marked on the annotated image below.

Image Processing

The image processing I chose was straightforward:

Dynamic Background Extraction
Photometric Colour Calibration
SCNR to remove surplus green.
Soft stretch (I am using EZ Scripts suite)
Starnet2 to divide the image into a star mask and a starless image.

On the starless image:

Unsharp Mask
Final stretch

On the star mask

Tiny bit of Curves transformation to slightly reduce the stars bloat
More SCNR

Finally I moved to PixelMath to combine the star mark with the starless image using a formula I mentioned in the previous post: ~((~narrowband)*(~star_mask)).

I saved the combined image as .tif and opened it in GIMP for some final touches.

Final thoughts

This was at the time my best astrophoto. Looking at it now, I mostly see the downsides. There is not enough acquisition time to work with, less than 4 hours on an old DSLR will not give you wonders. And that Vixen telescope would only give round stars in the middle of the image, the corners being just a mesh of triangular points.

Nonetheless, it was fun to go back to my earlier works, and have a chance to share them with you.

Below you will find the annotated and the starless versions of the image.

Powering an LTE modem from a 12V battery

STFN — Sun, 08 Oct 2023 24:00:00 GMT

Background

This project came from a simple need: I have a piece of land without grid electricity, and I want to have Wi-Fi there. I could just use my phone as a hotspot for a laptop, but I wanted something better, and not using the phone's battery. And building something for living off-grid is always fun.

In one of the previous blog posts I wrote how I built a 12V powerbank, so the energy source is covered. I also have an LTE modem, a TP-Link TL-MR100 which I bought some time ago to be used on holidays in remote places. Those two sounded like a perfect match, the only issue was how to connect them.

Looking at the sticker on the modem, it needs voltage of 9 volts, and uses 0.85A (I assume that second value is at maximum gain and throughput). My powerbank provides from ~13.5V fully charged to 11.5V at shutdown threshold. That sounds like a job for a step-down converter!

If you want to build something similar for yourself, check the sticker under your LTE modem for power specs, if your modem uses 12 volts, you might not even need to a converter, just connect it straight to the battery. Or if you want to be on the safe side, get a step-down/step-up converter that will output 12V no matter the voltage of the battery. In every other case you'll need a converter, maybe even a step-up one if your modem runs on, for example, 15 volts.

I am not responsible for any damage you cause to your equipment or yourself.

Parts List

Step-down converter

A step-down converter is a device that takes an input voltage and outputs an output voltage. I know, shocking. In my case I needed something that will reduce the voltage of the battery, fluctuating between ~13 to ~11 volts, and provide a stable 9 volts to the modem. After some searching and reading, I found that a perfect solution for me would be something based on the LM2596 chip. This chip can receive voltages from 40 to 4.5 volts, and output from 37 volts to 3.3 volts and handle a maximum current of 3 amps, so my use case would be well within its capabilities.

There is a lot of different converters using this chip, just go to your favourite online marketplace and search for the chip name, you'll get pages and pages of devices. They come in fixed and variable output voltages. All of them are dirt cheap, for 2-4 euros. Just select one that you like. I chose a fancier product, with a display showing the input and output voltages.

And all the other stuff

Apart from the converter, you'll need:

cables to connect stuff
plugs to end the cables
cable shrink wrap
a nice case for the chipset

And typical electrical DIY tools: multimeter, side cutters, a cable stripper, soldering iron, hot glue gun, and screwdrivers.

Build Process

For the wires I went with speaker cables, as they are perfect for DIY direct current projects: cheap, quite weather resistant, come in pairs of wires, and are marked for positive and negative. And I already have 30m of them lying around for a project that never came to fruition. Mine are, I think, 2 x 1.5mm and they were a bit too fat, I had to trim the ends to make them fit into the converter connector holes.

When soldering the cables, pay special attention to polarity and at every step make sure you don't mix it. Speaker cables have one of the wires marked in red, the convention is that it is the positive one. XT60 and barrel plug also have + and - signs on them, if you always go plus to plus, you should be fine. Just test often.

I cut two lengths of the speaker cables, one for the powerbank-converter part and second for the powerbank-modem part. I carefully split the positive and negative wires and stripped the ends of their isolation. At this time I added short lengths of heat shrink to give the cable an additional layer of protection at the ends. For the first part I soldered an XT60 connector to one end. I chose that connector type because my powerbank already has these. The second end of that cable I soldered to the input side of the step-down converter. Part one done.

For the second length I did the same, splitting, stripping, and soldering. One end went to the output side of the step-down converter, and at the second end I screwed a 2.1x5.5mm barrel plug. Check what plug your modem has, it is very possible that it will too have that one, it's a very popular standard.

The final step was to add a case to the converter. Again I used something I already had lying around the workshop (aka my bedroom), a weatherproof electric box. The converter fit nicely inside. In accordance to ancient Chinese traditions, I hot glued the it to the inside of the box, and added additional hot glue on the soldered connectors to protect them from moisture. And some more hot glue to close the cable gaps and fix everything securely. Now just a sign explaining what's inside the box (what's in the box?!) and the project is completed.

With that the project is basically done, now it's time to configure and test it.

Testing

Setup and start

My LM2596 is a variable voltage one, and has a display to show input and output voltages. If you have a constant output voltage one, skip the setup part. If you have a variable output one, but without a display, you'll need a multimeter to check the output voltage.

I plugged the input cable to my powerbank and powered it on. The display started showing the output voltage. Using a small screwdriver, I carefully turned the adjust screw until the display showed 9 volts. This is all that is needed to setup the converted, but I wanted to do some testing, so I connected a PC case fan to the output side. As I was changing the voltage, the fan was visibly spinning slower and faster, so that confirmed that the converter works. Finally I checked the output plug with a multimeter to be triple sure that I am getting exactly 9 volts on it. I also made sure the polarity is correct, for barrel jacks the inside should be positive, and the outer shell should be negative.

Finally it was the time for the great finale, I connected the LTE modem to the converter, and the converted to the powerbank. I turned on the powerbank... and it worked! The modem started as usual and quickly caught the mobile network. In moments, I was able to connect to the Wi-Fi and browse the intertubes on battery power.

Now I can browse Mastodon while sitting in a field, the future is incredible. Thank you for reading, I hope you enjoyed it!

I would love to get some feedback from you, dear reader, you can drop me an email, or contact me on Mastodon.

On degoogling my life

STFN — Fri, 20 Oct 2023 24:00:00 GMT

In July of 2023 I left Twitter and switched to Mastodon. There were many reasons to do so, the main being Twitter decaying into this hellhole of modern internet, with falling quality of discussion and service, the crypto bros and growth ninjas. Twitter was never perfect, but after being sold to Elon, everything started falling apart. On the technical side there were the posting limits, the broken notifications, the neverending advertisement. On the ethical side, I've hears stories of people reporting obvious hate speech and getting replies that it's not breaking the rules of the site. And Elon himself posting antisemitic, conspiracy, just disgusting things, with his blue ticked followers clapping at this every word. And the algorithm, I cannot stand algorithm social media. The all encompassing algorithm is just a way to drive what one should see and what should be hidden, and it is not transparent what are the criteria, which is a wide open way for making people think and behave as the platform owners want them to.

So I went to Mastodon, I already had an account there for a few months but hadn't really tried it. Yet in that July everything fell in place and I felt right at home there. I've always been a fan of a different internet, a grassroot one, led by amateurs who give their hearts into it. I sad it many times, I miss the internet of the early 00s, with the discussion boards, the blogs, the personal sites, content made with passion. And Mastodon feels like going back to that time. Its federation is its strength, no one has enough power to control the Fediverse as a whole. And everyone can find an instance for themselves. I found people with common interests there, refugees from corporate internet, writing blogs about bike trips, tinkering, soldering and compost, and since the change I've been feeling much better mentally.

Now, switching from Twitter to Mastodon gave me an impulse to finally move forward with something I've been planning to do for quite some time now: move my internet presence in general from corporate, ads-pushing and personal information guzzling intertubes to the other side, the side that is made by people who want to make it good, away from the flood of enshittifaction that is permeating the mainstream internet.

Here in this blog post I would like to list the services that are a good alternative to the mainstream behemoths. Every service listed here I am using personally, and can recommend it without a doubt. And nobody paid me to do so, actually I am supporting them with money :)

Google - For replacing my search engine I tried several alternatives, I've been using Duck Duck Go for a few months, but I wasn't too happy with the results it was giving me, and often I had to do another search in Google to find what I wanted. Recently I came across Qwant and I believe I finally found a search engine for me. It does not collect any data about you, and the search results are (at least for me ofc) much better than Google. Qwant does not provide AI generated gibberish at the top of the search results page, it's clean and it's fast. I highly recommend it.

Gmail - Continuing on theme of the Google suite, for email I am switching from Gmail to ProtonMail. They are an email service that is privacy and safety focused, and does not gorge on your data as the mainstream email providers. They have a generous free plan, and paid options for people who need more out of their inbox. I've seen some people also recommending Tutanota, but I have never tried them. You can see I am using Protonmail, as the contact email for this blog is from them. Drop me an email to say hi :)

Google Maps - OpenStreetMap. In short one might say that OSM is a crowd-sourced version of Google Maps, but that would be only one angle. OSM is a massive community people whose intent is to provide the largest possible set of geospatial data. What does that mean? Firstly, it means that everyone can, and is encouraged to update OpenStreetMap. Secondly, it is possible to input much more different types of information to places on the map, in order to benefit different kinds of people. OSM puts great focus on people on bikes, people on foot, as well as people with different handicaps. For example every street crossing in OSM can be marked as having or not tactile information for people with sight issues. The height of the curb can be defined to allow people on wheelchairs to better plan their routes. In short, OSM is much, much wholesome than Google Maps and I encourage everyone to use it and to contribute to it. To contribute, you can register and start editing on the main OSM site, openstreetmap.org, or even better, install one of the mobile apps available, that will allow you to edit map data during your walks, when you are actually at the place you want to edit. I personally use StreetComplete, and more on it in the Android section.

Youtube - I'll admit I am a heavy Youtube user, and there are many Youtubers I watch regularly. But recently I started discovering PeerTube and I like the atmosphere there. Peertube is a Mastodon for video, it's another federalized ecosystem of independent instances that anyone can create. Sadly, people whom I watch on Youtube do not post there, but I discovered new creators there. A notable example is Andy Balaam, who made a great Rust tutorial. In general, Peertube feels like the early days of Youtube, with people posting what they find worth sharing with the world, their hobbies and interests, and as I said many times, this is the facet of the Internet that I prefer and find the most catching. If I ever create a video, I will post it on Peertube.

Instagram - Oh Instagram. Once all the rage and envy of everyone whose phone would not support the app. Who didn't publish at some time a heavily filtered, retro-vintage-out-of-focus square photo? I sure did. Yet in recent times, especially after it being acquired by Facebook, the enshittifaction of Instagram has been in full swing. I've been opening it rarely the recent months, but everytime I did I was shocked by the ads-to-posts ratio. And it belongs to Meta, so most probably it tries to gather every possible information on its user and use it to profile and push towards us more crap. It just doesn't feel like a place to publish content anymore. I'm still there to watch the stories of a few of my closest friends, but nothing more. As for the better alternative, I am moving to PixelFed, which also belongs to the Fediverse. It has zero ads and zero personal data mining. Its instances run on user donations, so there is no incentive to make it worse for the people. You can find me there at pixelfed.social/stfn.

AWS - I've been using AWS for many applications, most of all as cold backup of all my important data. Their Glacier tier of storage made it very cheap to store almost a terabyte of files. But this is coming to an end for me. I just don't want to give Bezos any of my money and data, I've read too much about what Amazon is doing their treatment of their employees and contractors, about the scams, about Bezos and his plans to litter the Low Earth Orbit with thousands of satellites, etc, etc. I won't lie, I have very strong negative feelings towards billionaires in general.

For backup I have moved to Hetzner, a German company that offers storage and VPS solutions. Their 1 TB storage box is only a little bit more expensive than storing data on AWS, but it gives me a peace of mind. I've also used their VPSs a bit for testing and was impressed by their speed. Not for this blog though, this blog is running on RackNerd, mostly because a long time ago I bought a very good deal VPS from them on a sale, so I'm keeping it.

The final nail to AWS's coffin for me is that I found out that it is not simple to just get data from Glacier, so I still haven't removed everything I store on AWS. I don't want to feel like a prisoner of technology that is not easily under my command. And full disclosure, I'm also still using them as the CDN for this blog, but I want to move away from it ASAP, I just need to find some time to finalize the move.

What service would you recommend for a blog CDN? Let me know via email or on Mastodon. Thanks! And no, no Cloudflare, absolutely no Cloudflare.

Goodreads - For my book log, I'm moving to Bookwyrm. Bookwyrm is also a decentralized federation of servers, just like Mastodon. I like the simple and clean UI. Not much else to say, if you want to send me a friend request, you can find me at bookwyrm.social/user/stfn

Github - I recently found out about Codeberg. To quote their "About" page: Codeberg is not a for-profit corporation but an open community of free software enthusiasts providing a humane non-commercial and privacy-friendly alternative to commercial services such as GitHub. The non-profit and FOSS loving side of Codeberg is what sold me to them. The downside of Codeberg is that it does not yet provide Github-like Actions for everyone, but I can live with that, and if I ever need to learn actions for professional reasons, I can just have a test repo on GH. On Codeberg you can find me at codeberg.org/stfn. For now there's only one of me repos there, but I will eventually move all my public and worth moving code from GH to Codeberg.

iPhone - Android and F-droid. In September I switched from iPhone 7 to a Fairphone 4. And that is a big change in terms of both open source software, and sustainability. On the topic of sustainability, Fairphone the company, states that it is their core value. I have no way to check the validity of their claims when they talk about "responsible material sourcing" and "advocating for workers’ welfare", but at least they are talking about such issues, in contrast to other phone companies. What I do know is that Fairphone is repairable and has a battery that can be just swapped as in the old days. Yes, you can just take off the backplate and pull out the battery, like in a Nokia 3310. Both of those aspects, repairability and replacability (is that even a word?) are important to me. Batteries do not last long, and being able to just order a new one, and replace it without dismantling the whole phone is a welcomed change.

As for open source software, this is the field in which Android's relative openness wins over iOS. While Android is not open source, it is much less restrictive in what can be run it. On Android you can install apps from alternative sources without rooting the phone, and a great source of apps is F-Droid.

F-droid is an alternative to the Google Play store, hosting apps that are open source, and take privacy and security seriously. I will probably do another blog post on F-droid in detail, but for now, let me just say that among the apps from F-droid that I use daily, there are:

AntennaPod, a player for podcasts
Tusky, a Mastodon client
Mullvad, a client for the Mullvad VPN
StreetComplete, my favourite application and a joy for long walks. This app allows you to update OpenStreetMap by answering simple questions as you walk along, for example "what surface is this sidewalk? Are there light at this zebra crossing? Does this bus stop have a bench?" I highly recommend it, and at the same time warn, that this is a highly addictive sport.

Self-hosted solutions

I am self-hosting a lot of different services for my personal use, a full list of them can be found in one of my previous blog posts (stfn.pl/blog/11-my-homelab-0823/). One that is worth mentioning here is an RSS reader. My first RSS reader was the late Google Reader, and after its demise (wink wink google cemetery) I switched to Feedly. Finally, a few months ago I switched to a self-hosted FOSS solution: Fresh RSS, and I've been using it ever since. It just works and has a pleasant web interface. And its light, so it can run on anything, a Raspberry Pi will do just fine.

Future plans

For me ebook reader I am still using my 4th gen Kindle which I bought way back in 2012. I will be using it until it dies and cannot be fixed, but for the next one, I will be looking for something that does not belong to Amazon, I am considering either an Inkbook or a Kobo.

I'm also thinking of ditching the stock Android for a more open and privacy confused mobile OS. Probably I will go with /e/ OS, as Fairphone is officially supporting them and recently has even started to sell their phones with that operating system preinstalled. But before that I need to do some more research, make sure my banking apps and all that other important stuff works seamlessly with it.

Final thoughts

The process of me moving to the better side of the internet is still in progress. It's often not easy to break established workflows and ditch tools that I have been using for a long time, but I feel this is the right thinkg to do, and it makes me happy.

Are you also moving away from Google and Amazon? How does it go for you? Are you using different solutions than I? I would love to hear your feedback, contact me on Mastodon or via email. Or maybe I could establish another way of communication? Let me know!

And finally,you can help with funding my future projects by supporting me on these crowdfunding sites:

I would like to express thanks to m0bi, discrust, Kuba Orlik and Arkadiusz Wieczorek for showing me cool, open source solutions.

RPi 4b vs RPi 5 benchmark in BOINC - Einstein@Home

STFN — Sat, 04 Nov 2023 24:00:00 GMT

TL;DR: The Pi 5 is roughly 30-50% faster than Pi 4b.

I finally received my Raspberry Pi 5. I pre-ordered one straight on release day in September, and it arrived at my door a week ago. I used it for a moment as a desktop device with a full desktop install of the Raspberry Pi OS, and the first impression have been very positive so far, it feels much, much snappier in typical desktop activities such as browsing the Internet or watching videos. But that is not why I bought it, using a Pi as a desktop is on the last position of my "what to use a Pi for" list. I have several ideas on how I want to use the new Pi, and the first one is to try it out as a BOINC cruncher. From that came the plan the benchmark it in comparison to the previous model, the Raspberry Pi 4, which I have three of.

BOINC

In short, BOINC is a platform that allows people to share their computing power with scientists that need it to do scientific analysis. Everyone can install a BOINC client, select a project they are interesting it, and let their computer do calculations that are then returned to the scientists. The calculations are divided into tasks, usually a task uses a single CPU core, and you can crunch (that is the BOINC word on performing calculations) as many tasks simultaneously as the number of cores in your CPU. Some project also allow crunching on the GPU. I wrote more about BOINC in this blog post: My thoughts as I reach 100 million points in BOINC

I did a share of BOINC calculations on my Raspberry Pi 4 and was curious how it compares with the new Pi 5. And so I set up a test.

The BOINC project I chose for crunching in this test is Einstein@Home. I chose this one because it's one of only two projects that provide ARM64 tasks (the second being Asteroids@Home), its tasks are relatively short, and the project has a high task size uniformity (more on that later).

Test baseline

To make the test as fair as possible I defined a set of baseline rules:

both Pis used the same SD cards. I am using SandDisk Ultra 64GB.
both Pis used the official power supplies dedicated to their specific models.
both Pis used the same cases and active cooling. Actually, I put both of them in a single cluster case. For cooling I am using a 120mm 12V fan powered by a 6V power brick. I decided to go this way, as that large fan running at half speed is almost inaudible, and that allows me to sleep in the same room as the test rig. The Pi 5 has the official active cooler attached, but the large fan is working so well that the active cooler did not start during the whole test. I was monitoring the CPU temps, and they never exceeded 55C on both Pis, so there is certainty that neither of them was thermal throttling.
both Pis were set up in the same way. The configuration was totally stock, no overclocking. I burned the Pi OS 64 bit Lite on both SD cards, started them, upgraded all the packages and installed BOINC. Both Pis run headless.

Why the test could not be fully fair

And now I must mention that even though I implemented all those measures mentioned above, the test conditions were not perfectly uniform. The issue is that the tasks that the BOINC servers are sending are not always the same size, and some take a longer to finish than others. Einstein@Home tasks are rather uniform in their size, but they are not exactly the same. A BOINC user has no control over which tasks they receive. So it is theoretically possible that one Pi was getting a higher percentage of larger tasks than the other. To mitigate this problem I went with making the task pool bigger. I crunched 80 tasks per Pi, in hope that more tasks would reduce the weight of a single task size. I think around 80 is the sweet spot between having a large enough pool of data, and waiting for ages for the benchmark to finish. After all, the Pis are not the fastest crunchers.

With the baseline of the way, let's see the results.

Results

Average tasks time

For the 4b, the average tasks time was 16353 seconds (4 hours, 32 minutes and 33 seconds). For the Pi 5, the average task time was 10858 seconds (3 hours and 58 seconds), a decrease of around 33%.

Minimum task time

Maximum task time

For the 4b, the longest task took 17148 seconds (4 hours, 45 minutes and 48 seconds). For the Pi 5, the longest task took 11370 seconds (3 hours, 9 minutes and 30 seconds), a decrease of around 33%.

Average tasks per day

A day has 86400 seconds. Both Pi 4 and Pi 5 have four cores, so they have 345600 core-seconds per day. Dividing that number by the average task time, the results are 21 tasks per day for the Pi4 and 31 tasks per day for the Pi 5, the Pi 5 can crunch 47% more tasks per day than the Pi 4.

Benchmark raw results

I am attaching below the benchmark data. Please feel free to use it in whatever way you want, just please link to this blog post if you want to publish your work.

Benchmark data in LibreOffice Calc format

RPi 4b results in CSV

RPi 5 results in CSV

Summary and further steps

This has been only a preliminary test of the new Raspberry Pi. To sum the results so far, the Pi 5 is, to little shock, faster than the previous model, 33% decrease in task crunch time is a reasonable generational upgrade.

I want to continue testing the Pi 5 in different scenarios. For the next steps, I will crunch Asteroids@Home, and see if the performance difference between the 4 and 5 will be the same or different in another BOINC project.

Apart from that, I wonder how much a bottleneck is using the SD card as storage. I think I will also do a test running the Pi5 from an NVME M.2 SSD in a USB case to see what kind of a difference will it make.

I should also receive soon a Pi alternative, an Odroid C2, and see how it compares with the two pis.

As for the Pi5 itself, I plan to test it out in other scenarios, I think the next one will be making a NAS out of it. Whatever I do with it, I will write about it on my blog.

Thanks for reading!

If you have any comments about the test, its metodology, my calculations, or have suggestions what to test next, drop me an email, or contact me on Mastodon. Links are in the footer.

RPi 4b vs RPi 5 benchmark in BOINC - Asteroids@Home

STFN — Thu, 16 Nov 2023 24:00:00 GMT

TL;DR: For Asteroids@Home the Pi 5 is roughly three times faster than Pi 4b.

This post is a continuation of the previous blog in which I compared Pis crunching Einstein@Home, so here I omit the parts that would be identical. For more information on the test background and methodology, please read the previous blog post.

The BOINC project I chose for crunching in this test is Asteroids@Home. This is the second of the two projects that provide tasks for ARM 64 bit boards.

Asteroids@Home task uniformity

In the blog post about Einstein@Home I mentioned that BOINC does not always send task of uniform size, some of them are smaller than the others and may skew test results. Asteroids@Home also has this issue. From what I observed most of the tasks are of a similar size, but there are also some outliers which run time is much, much shorter, around 1/2 - 1/3 of the typical tasks length. Because of that I am omitting the "minimum task time" part in this test, because it would only show whether one of the Pis was lucky to receive such a task.

What is also worth mentioning, is that Pi 4 received tasks called "Period Search Application v102.14aarch64-unknown-linux-gnu", while the Pi 5 tasks were called "Period Search Application v102.14". The application version is the same, so I assume there was no difference, but I will validate that claim in the A@H forums and update this part once I have an answer.

Temperatures

An interesting difference between Asteroids and Einstein on the Pi 5 was the thermal load of the CPU.

As in the previous test, my rig has a 120mm fan running at 6 volts, cooling both RPi 4 and RPi 5 in an open cluster case. The Pi 5 also has its dedicated, PWM-controlled active cooler attached.

When crunching Einstein on the RPi 5, the temps were around 55C. The dedicated cooler did not start, the large fan cooled it enough to keep the temps below the threshold that would trigger the active cooler.

Asteroids put a much higher thermal load on the Pi 5's CPU, the Pi was again at around 55C, but to achieve that temperature, the active cooler was running at 5k RPM the whole duration on the test. Whereas the Pi 4, with only a heatsink attached, did not pass 60C as with Einstein. Seems that Asteroids are pushing the 5's cores much harder. Maybe that is what is causing the massive change in performance?

Here I have to praise the Pi 5 active cooler. Even though running at 5k rpm, it was inaudible, drowning in the noise of the 120mm fan running at half power.

Let's see the results.

Results

Average tasks time

For the 4b, the average tasks time was 38010 seconds (10 hours, 33 minutes and 30 seconds). For the Pi 5, the average task time was 12207 seconds (3 hours, 23 minutes and 27 seconds), around three times faster.

Maximum task time

For the 4b, the longest task took 42208 seconds (11 hours, 43 minutes and 28 seconds). For the Pi 5, the longest task took 15244 seconds (4 hours, 14 minutes and 4 seconds), again more or less three times faster.

Average tasks per day

A day has 86400 seconds. Both Pi 4 and Pi 5 have four cores, so they have 345600 core-seconds per day. Dividing that number by the average task time, the results are 9 tasks per day for the Pi4 and 28 tasks per day for the Pi 5, the Pi 5 can crunch three times more tasks per day than the Pi 4.

Benchmark raw results

I am attaching below the benchmark data. Please feel free to use it in whatever way you want, just please link to this blog post if you want to publish your work.

Benchmark data in LibreOffice Calc format

RPi 4b results in CSV

RPi 5 results in CSV

Summary and further steps

This has been the second post in the series about comparing Pi 5 with its predecessor. As I said in the previous blog posts, there are also other scenarios in which I want to test the newest Pi, and now I think the immediate next one will be running Universe@Home.

Thanks for reading!

If you have any comments about the test, its methodology, my calculations, or have suggestions what to test next, drop me an email, or contact me on Mastodon. Links are in the footer.

RPi 4b vs RPi 5 benchmark in BOINC - Universe@Home

STFN — Thu, 30 Nov 2023 24:00:00 GMT

TL;DR: For Universe@Home the Pi 5 is roughly three times faster than Pi 4b.

This is the third and final blog post in the series about comparing the performance of Raspberry Pi 4b and 5 in crunching different BOINC projects.

It's the final one because there are only three projects that I crunch on a regular basis and that support ARM processors.

Here are the previous ones:

Einstein@Home

Asteroids@Home

The full description of the test background and methodology, can be found in the first episode.

Universe@Home task uniformity

In the blog post about Einstein@Home I mentioned that BOINC does not always send task of uniform size, some of them are smaller than the others and may skew test results. Universe@Home also has this issue, and to a much larger extent. The U@H tasks differ widely in size, on my Ryzen 3700X machine, the tasks can take from 25 minutes to 90 minutes to finish. That is why for this comparison I have crunched 200 tasks per Pi to reduce the impact of tasks dissimilarity on the results.

Temperatures

An interesting difference between Asteroids, Einstein and Universe on the Pi 5 was the thermal load of the CPU.

As in the previous test, my rig has a 120mm fan running at 6 volts, cooling both RPi 4 and RPi 5 in an open cluster case. The Pi 5 also has its dedicated, PWM-controlled active cooler attached.

Einstein put very little thermal load on the Pi 5 CPU, the onboard active cooler did not even start. Whereas Asteroid put a heavy strain, the cooler had to run at 5k RPM to keep the board at a reasonable temperature below 60C. Universe was somewhere in between, the onboard cooler did start, but it only had to run at 2000 - 2500 RPM to keep the Pi at around 55C.

Let's see the results.

Results

Average tasks time

For the 4b, the average tasks time was 15511 seconds (4 hours, 18 minutes and 31 seconds). For the Pi 5, the average task time was 5602 seconds (1 hour, 33 minutes and 22 seconds), around 2.7 times faster.

Minimum task time

For the 4b, the shortest task took 6277 seconds (1 hours, 44 minutes and 37 seconds). For the Pi 5, the shortest task time took 2208 seconds (just 36 minutes and 48 seconds!), again around 2.7 - 2.8 times faster.

Maximum task time

For the 4b, the longest task took 26695 seconds (7 hours, 24 minutes and 55 seconds). For the Pi 5, the longest task took 9493 seconds (2 hours, 38 minutes and 13 seconds), again around 2.8 times faster.

Average tasks per day

A day has 86400 seconds. Both Pi 4 and Pi 5 have four cores, so they have 345600 core-seconds per day. Dividing that number by the average task time, the results are 22 tasks per day for the Pi 4 and 61 tasks per day for the Pi 5, the Pi 5 can crunch 2.8 times more tasks per day than the Pi 4.

To put that in perspective, the Raspberry Pi 5 in this particular benchmark is faster in computation speed than my old i5-4460, and not that far from a modern Ryzen 3700X.

Benchmark raw results

I am attaching below the benchmark data. Please feel free to use it in whatever way you want, just please link to this blog post if you want to publish your work.

Benchmark data in LibreOffice Calc format

RPi 4b results in CSV

RPi 5 results in CSV

Summary and further steps

This is the final post about benchmarking the Pi in BOINC. Now I need to find another use for it. Whatever plan I have for the newest little SBC, I will write about it here.

Thanks for reading!

If you have any comments about the test, its methodology, my calculations, or have suggestions what to test next, drop me an email, or contact me on Mastodon. Links are in the footer.

Invidious - Open Source Youtube Frontend

STFN — Tue, 05 Dec 2023 24:00:00 GMT

20th post for the first anniversary of my blog, woop woop!

Continuing on the theme of degoogling, which I described in more detail in this blog post, this time I look at alternative ways to watch Youtube. Recently I cut down my YT intake significantly, but there are still great Youtubers that I enjoy watching, and their content is not available anywhere else, so I won't be leaving the platform entirely. Fortunately, there are ways to watch videos without being too exposed to Google and its shenanigans.

Le what is an Open Source Youtube Frontend?

A few days ago, m0bi mentioned Invidious on Mastodon. Invidious is an open source alternative front-end to YouTube that can be self hosted, and that combination of words raised my interest. There's a lot to unpack here, so let's dissect what exactly is Invidious.

First of all, what is an alternative frontend to Youtube? Youtube, as every webpage has a frontend and a backend. The backend is what is happening beneath the hood, storing video files, database calls, user authentication and authorization, tracking follows and like, all that stuff that needs to happen, but nontechnical users do not care about it all. Frontend is the layer that the user interacts with, what they see, so the actual video player, login screens, like and subscribe buttons. When you go to youtube.com you see the default, official frontend to Youtube. However, it is possible to have your own frontend that will talk to the backend as if it was the official one. This is where Invidious comes in.

Invidious is open source, meaning anyone can see and edit its code, and offer fixes that will be merged to its distribution. It allows you to create accounts that are not Youtube accounts. Thanks to that, you can follow people and build playlist, and the Google overlords will have no data on you. And it does not show ads.

I've been using it for a few days, and it has been great. The UI is much cleaner, there are no ads, and there is no algorithm pushing you random videos to watch. The last thing may be a downside to some, but if you migrate from YT and have an established set of people to watch, you won't miss it. And maybe it will save you from spending too much time watching videos. With all the praise, I however spotted two downsides to Invidious:

If you go with a self-hosted Invidious as I do (more on that later), The Firefox SponsorBlock addon does not work. I found a GitHub thread on it, with no resolution.
You cannot just paste a YT link to the Invidious search input, that would be an awesome addition.

To watch videos with Invidious (seriously, I cannot type this name correctly at the first try) you can use one of the official instances listed in the Invidious docs, or self host one. As I am a self hosting nerd, of course I went with the second option.

Self Hosting Invidious

Instructions how to self host Invidious are in its official documentation. I went with the simplified production deployment with Docker, because I do not run a reverse-proxy on my homelab (I will one day sit to it, I swear!)

I cloned the repo to my homelab and generated a secret hash:

git clone https://github.com/iv-org/invidious.git
cd invidious
pwgen 20 1

If you do not have pwgen, just apt install it. The next step is to edit the docker-compose.yml file. I copied the generated hash to the "CHANGE_ME!!" place in the YAML file. Finally I changed the ports stanza from - "127.0.0.1:3000:3000" to - "3010:3000" because as I said, I don't have a reverse proxy, and also on my homelab port 3000 is already occupied. If you have port 3000 free, don't change it. All that was left was simply docker compose up -d.

When I opened http://<my_homelab_ip>:3010 I saw a beautifully empty page. I searched for a video in the search bar, and it just played. Perfect.

The next step was to create an account. It's not required, but it allow you to follow people. Because accounts are hosted locally and not connected to YT in any way, I could name it whatever I want, so I went with the traditional 123qwe username. Imagine trying that on YT, lol.

One final thing

The docs suggest that Invidious should be restarted often, preferably once every hour, so I did it with a cron job. Just fire crontab -e and add the line below at the end of the file, remember to change the path to yours. And if you have an older version of Docker, for you it might docker-compose with a hyphen.

0 * * * * /usr/bin/docker compose -f /home/stefan/Containers/invidious/docker-compose.yml restart

And that's it, you now have a way to watch Youtube without actually going to Youtube, how cool is that?!

Thanks for reading! And thank you everyone who in the last year read my blog, left me feedback, shared it, liked it, and supported me on Ko-Fi.

Update 06-12-2023

After publishing this post I realized that I cannot set the video resolution to anything higher than 720p. It turned out that this is the default setting, I guess to reduce strain on small servers hosting Invidious.

To change it, go to the settings (little cogwheel in the top right corner), and change the Preferred video quality setting to DASH. This way you will unlock all of the available resolutions of a given video.

Before:

Changing the settings:

After:

Display your Mastodon followers count on a 4 digit TM1637 display

STFN — Sat, 16 Dec 2023 24:00:00 GMT

If you ever wanted to show how many followers on Mastodon you have without pointing people to your account, but instead present it on a physical numeric display, you have come to the right place.

This is a quick and simple project that with the right hardware you can finish in maybe 15 minutes. And can be infinitely expanded by presenting other information as well, or toggling through data, or doing simple animations. The sky (but not Bluesky) is the limit.

What you need

A single board computer with GPIOs, any Raspberry Pi or its clone will do. I wrote the script to be run a full-fledged computer running Pi OS, but with minor modifications can also be run on a microcontroller like a Pi Pico. For brevity, I will assume you are using a Raspberry Pi.
A TM1637 based four digit display. You can buy them cheap from Arduino or any other electronics store.
Female to female connecting cables.

Create access creds for Mastodon API

The Pi will need to talk to Mastodon using the Mastodon API. For that to happen, access credentials need to be generated. Open your Mastodon account page, and go to Preferences, next Developer, and click New Application. Fill in the form, the name and website can be anything, it does not matter. In the Scopes section select only "read all your account's data". That is all that is needed, and it is a good practice to give such creds only the minimal set of permissions, so don't select anything else.

Once you created an application, you will be given the Client key, the Client secret and the Access token. Save them in a secure place and do not share them with anyone. Let's now move to setting up the Pi.

Hardware Setup

I assume you have a working single board computer running Linux, which you can access using a keyboard and a screen, or via SSH. I will not dive into configuring and starting an SBC here.

Once you have an SBC ready, make sure it is powered down before connecting the display to the Pi.

Here's the pinout diagram which I have taken from the Pi's official documentation. If you are using a different board, check its docs.

The display has four pins: VCC, GND, CLK and DIO.

Connect the VCC pin to the 3.3V pin on the Pi, this is GPIO 1. Connect the GND pin to any of the ground pins on the Pi, I connected it to the ground pin next to the 5V pins, as it's the closest one to the 3.3V one.

The CLK and DIO pins can be connected to any digital input/output pin on the Pi.

I connected them to GPIO 2 and GPIO 3 respectively as again, they are the closest ones.

Start the Pi and open the terminal.

Software Setup

I am assuming you are running a Debian-like distro. If not, use the package manager that comes with it. This will be the only distro-specific part.

First, make sure you have python-venv and git installed. We will need them later.

sudo apt-get install python3-venv git

Copy my repo to fetch the required files bash

git clone https://codeberg.org/stfn/mastodon-followers-display.git

Now it's time for setting up the script. It is good practice to never mess with the system Python environment, so let's create a virtual environment to install the dependencies needed to run the script.

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

The next step is to set the access credentials so that the script will be able to talk to Mastodon. Copy the .env-example file to a new one called .env and fill in the variables with the credentials you got when setting up the Mastodon API. The API_BASE_URL is the url of your instance.

cd mastodon-followers-display
cp .env-example .env
nano .env

Running and adding to cron

Once the setup is done, it's time to actually test the script

python script.py

The display should come to life, first show 0000, and once the Pi logs into Mastodon, it should show your followers count. If nothing happens, make sure that the pins are connected correctly, maybe DIO and CLK are the other way round.

The final step is adding the script to cron so that it will be run periodically, for example every five minutes.

Open cron:

crontab -e

At the bottom of the file, add this line:

*/5  * * * * /home/stfn/mastodon-followers-display/venv/bin/python /home/stfn/mastodon-followers-display/script.py

The first part of the line is the cron time statement. This one means "every ten minutes". Use crontab guru if you want to have a different time period. Cron requires absolute paths, that's why we are providing first the path to the python binary that is in the virtual environment created during setup, and then the absolute path to the script file. Remember to change the paths to your actual ones!

Aaand done, now you can put the Pi with the display on a shelf and boast how many people follow you on Mastodon, after all, this is all that matters, right? Right?

( ͡° ͜ʖ ͡ – ✧)

Thanks for reading!

How to monitor 12V battery charge with a Raspberry Pi Pico

STFN — Fri, 05 Jan 2024 24:00:00 GMT

Last year I built a 12V powerbank to power my astrophotography rig and to light my shed. It has been working great so far, in fact I liked it so much I built a second one. While I've been very happy with my DIY powerbanks in general, they lack one functionality, and that is remote monitoring of the battery charge level. It would be awesome if I could check the battery voltage remotely, while the rig is working out there in the cold night. This need inspired me to look for battery monitoring solutions, but from the ones I found, none were interesting, and after all, it's much more fun to build something by yourself, rather than take something off the shelf.

I have a Raspberry Pi Pico W, which I already used for other projects, such as making a weather station and I decided I want to do something based on it. When browsing the internet, I came across this forum thread showing how to measure voltage with the Pico.

Theoretical background

The Raspberry Pi Pico has 3 ADC (Analogue to Digital Converter) inputs. Analogue in this case meaning it can measure voltage as a continuous spectrum, in contrast to the digital pins, which only work in binary, 0 and 1, voltage and no voltage. In this project I am using one of those inputs to measure the voltage of the battery. Now, the problem is that, it can only accept voltages up to 3.3V. If I wanted to measure, let's say, the voltage of a 1.2V AA battery that would be fine, but I want to monitor a 12V battery, which voltage can range from 13.5V at full charge, to 11V at depletion. That's why we need to use a tool from the basics of electronics: a voltage divider.

A voltage divider is a circuit which consists of two resistors connected in series. The voltage measured between the point between the resistors (Vout) and the negative battery terminal will be lower than the voltage of the battery itself (Vin). The voltage drop is constant and based on the values of the resistors, so by measuring the lowered voltage and knowing the conversion rate, we can calculate the voltage of the battery. Looking at the diagram should give you a better understanding of the whole idea.

Image taken from Wikipedia commons.wikimedia.org/w/index.php?curid=36347358

Hardware

To build this battery voltage measuring device, we will need:

A microcomputer or a microcontroller with GPIOs, with at least one analogue GPIO. I am using a Raspberry Pi Pico, because this is what I already have around.
a prototype board
two resistors
cables
the usual tools: a soldering iron, cable crimpers and strippers
optionally: a buck converter to power the Pico from the 12V battery, but that won't be needed if you want to power the Pico from an external power source. I bought a variable step-down converter based on a LM2596 chip.

Choosing the resistors

We will need the voltage divider to reduce the incoming battery voltage (13.5V - 11V) to a value acceptable by the Pi Pico, which is below 3.3V.

Below is the formula to calculate the voltage drop. There is also a handy online calculator available.

After doing some trial and error calculations I went with a 75 kOhm and a 20 kOhm resistor. This way even at the maximum cell voltage of ~13.5V, the voltage coming to the Pico will be around 3V. The resistors are in the kiloohm range to reduce the amount of current flowing through the Pi.

Connecting stuff

Diagram made with Circuit-Diagram

The circuit is very simple. The branch starts with the positive connector of the battery, goes through both resistors and returns to the negative connector. From a point between the resistors, another branch connects to one of the analogue pins on the Pi. I went with Pin 28, as it's the nearest one to the AGND (Analogue Ground Pin). A final branch goes from the AGND to the negative connector on the battery. And we're done.

I used a prototype board to connect all of the components. First I went with soldering the resistors to the prototype board. Remember or mark which resistor is the higher value one and which is the lower value. I left one hole of space between the resistors for a cable going to the Pico.

The next step is to solder the cables going from the battery to the resistors. If you are going to use a plug to connect the device to a battery as I am, it's a good time to solder it now. Pay attention to the polarity of the plug, the positive cable needs to be connected to the resistor with the higher value.

Now solder to the resistors the two cables going from the board to the Pico. Don't solder cables to the Pico itself yet! Once you have the resistors and the cables soldered, this is a good point to test that the voltage divider actually works. Connect the two battery cables to a battery and with a multimeter, measure the voltage between the the cables that will be connected to the Pico. If the battery is close to full charge, the measured voltage should be around 3V. If that is the case, cool, we're home. If not, something went very wrong with the circuit, check all the connections again.

Now connect the board-to-Pico cables to the analogue input, and the analogue ground of the Pi.

The soldering part is done. Take a double look at your work and make sure everything is connected properly. With the Pico UNPLUGGED from the computer, connect the battery cables to the battery socket. Wait a few minutes. Nothing should get hot, nothing should emit smoke. If everything looks fine, it's time to connect the Pico the a computer and start working on the software side.

Software

I am assuming you know how to access the Pi Pico in a code editor and you are using MicroPython. I am using Thonny to write and run code on the Pi.

Reading the voltage

Let's start with something very simple, just measuring the voltage and printing it out.

from machine import Pin, ADC
from time import sleep
analogue_input = ADC(28)

VOLTAGE_DROP_FACTOR = 4.572

while True:
    sensor_value = analogue_input.read_u16()
    voltage = sensor_value * (3.3 / 65535) * VOLTAGE_DROP_FACTOR
    print(voltage)
    sleep(30)

Most of the code should be obvious. Wer are importing the needed modules, measuring the voltage in a loop, and printing the measured value. But let's talk about this line.

voltage = sensor_value * (3.3 / 65535) * VOLTAGE_DROP_FACTOR

This is how the voltage on the Pico should be measured. The actual value returned by measuring the analogue input is a number between 0 and 65535, with the max value meaning 3.3V and 0 meaning 0V. By multiplying that value by 3.3 we are getting the voltage coming through the analogue pin. However, we are not exactly interested in the voltage at the Pi pin, we want to know the voltage of the battery. We are using a voltage divider that drops the battery voltage, right? Therefore, we need to multiply the Pi voltage by the voltage divider factor. Here I went with the simplest approach. I measured at the same time the voltage reported by the pi, and, using a multimeter, the battery voltage and calculated the difference factor. For me it is 4.572, but as every resistor differs a tiny bit, it will be different for everyone else. You will need to measure and calculate your own drop factor.

The part below is totally optional, feel free to skip it.

When testing if the whole device actually works, I let it run for a few hours and saved the measured values to a file, and plotted it in a Jupyter Notebook using matplotlib.

Here is the code used to generate the plot:

voltages is a file with each value on its own line. The raw values from the file are plotted in blue, and as you can see the data is noisy, so I used a smoothing filter for the red line. I found how to do it here on stackoverflow

import matplotlib.pyplot as plt
import numpy as np
from math import factorial
from scipy.signal import savgol_filter

with open("voltages") as f:
    lines = f.readlines()
lines = [float(line.strip()) for line in lines]
lines = np.array(lines)

x = np.array([x for x in range(len(lines))])

smooth_lines = savgol_filter(lines, 51, 3)
plt.plot(x, lines)
plt.plot(x, smooth_lines,color='red')
plt.ylabel('voltage')
plt.xlabel('data points')
plt.axis([0, len(lines), 11.8, 12.4])
plt.savefig('voltage.png')
plt.show()

Adding internet connectivity

Once we are able to read the voltage, it would be good to send it somewhere, wouldn't it? And for that I am using the power of the Internet.

First we need to connect the Pi to a WiFi network. Here's the code to do it. Save it on the Pico in a file called boot.py, and this way the script will be run every time the Pico is powered on. This is exactly the same code I used in the Pico Weather Station post. I believe the code is self-explanatory, but is something is unclear, refer to that previous post, I explain it there in detail.

import time
import network
import machine

led = machine.Pin("LED", machine.Pin.OUT)

ssid = "NETWORK-NAME"
password = "PASSWORD"

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(ssid, password)

max_wait = 10
while max_wait > 0:
    led.on()
    time.sleep(0.1)
    led.off()
    if wlan.isconnected():
        break
    max_wait -= 1
    time.sleep(1)

if not wlan.isconnected():
    for _ in range(5):
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.1)
        led.on()
        time.sleep(0.1)
        led.off()
        time.sleep(0.7)
    time.sleep(1)
    machine.reset()
else:
    status = wlan.ifconfig()
    led.on()
    time.sleep(3)
    led.off()

Pico web server

Next we need to make the voltage information available. The simpler way is to make a web server out of the Pico. I took the code below from a guide on the Raspberry Pi webpage and modified it a bit to accommodate to my needs.

In short, the Pi will be listening for any incoming connections, and once a client talks to the Pi, it will measure the voltage and return it in a JSON format. If you prefer HTML rather than JSON, check the guide linked above for an example.

One issue with using the Pi as a webserver is that you will need to know it's IP address to connect to it. To find the IP address you can use nmap under Linux, or an iOS/Android wifi scanner application.

Save the file below as main.py. boot and main are special names for files on the Pico. Every time the Pico is powered on, first the boot file is run, and then the main one. This happens even when the Pico is not connected to a computer.

import json
import network
import socket
import time

VOLTAGE_DROP_FACTOR = 4.572

analogue_input = machine.ADC(28)

addr = socket.getaddrinfo('0.0.0.0', 80)[0][-1]

s = socket.socket()
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(addr)
s.listen(1)

while True:
    try:
        cl, addr = s.accept()

        sensor_value = analogue_input.read_u16()
        voltage = sensor_value * (3.3 / 65535) * VOLTAGE_DROP_FACTOR

        response = {
            "voltage": voltage,
        }

        cl.send('HTTP/1.0 200 OK\r\nContent-type: application/json\r\n\r\n')
        cl.send(json.dumps(response))
        cl.close()

    except OSError as e:
        cl.close()

Sending data with MQTT

And here is the MQTT version. I prefer using MQTT over HTTP as I can pipe MQTT messages into my InfluxDB/Grafana monitoring pipeline and put the data into a nice graph.

To use MQTT you will need to install the umqtt library on the Pico, Thonny support installing additional packages using the "Tools -> Manage packages" menu.

What is also the upside of using MQTT is that we do not need to know the IP of the Pico, here the Pi needs to know the IP address of the MQTT broker, which is usually static or just more stable than the IP address of the Pico.

The main.py file for using MQTT:

import json
import time
import machine
from umqtt.simple import MQTTClient

led = machine.Pin("LED", machine.Pin.OUT)
analogue_input = machine.ADC(28)

VOLTAGE_DROP_FACTOR = 4.572

while True:
    sensor_value = analogue_input.read_u16()
    voltage = sensor_value * (3.3 / 65535) * VOLTAGE_DROP_FACTOR

    payload = {
        "voltage": voltage,
    }

    qt = MQTTClient("umqtt_client", "<MQTT BROKER IP>", keepalive=3600)
    qt.connect()
    qt.publish(b"battery", json.dumps(payload))
    qt.disconnect()
    led.on()
    time.sleep(0.5)
    led.off()
    time.sleep(30)

The code is very similar to the one shown in the Pico Weather Station post.

The main difference here is that with MQTT we are pushing the data in set intervals to an MQTT broker, a server that handles the incoming messages and allow other clients, such as InfluxDB, to read them and use them to for example create a graph. battery is the name of the topic, in MQTT topics are a way to separate different types of messages from each other. This part of the code sets up an MQTT client instance, connects and sends the payload.

qt = MQTTClient("umqtt_client", "<MQTT BROKER IP>", keepalive=3600)
qt.connect()
qt.publish(b"battery", json.dumps(payload))
qt.disconnect()

This is not the place to dive into MQTT specifics, if you want to start using this protocol, start with checking out Mosquitto, a popular MQTT broker.

Base done

The base is now done, we have a working battery monitoring device that can send the battery status over the network. When connected to a battery, and powered via USB from a powerbank or a wall charger, it will connect to the internet and provide information on the voltage level of a 12V battery.

Now let's tackle the issue that is is being powered from a power source that is external to the 12V battery. This can be seen as either a feature or a flaw of the design. A feature because this way it won't drain the main battery, and will run even if the main battery is temporarily turned off. A flaw because it adds a second battery that needs to be charged, and together with that additional cabling and complication in general.

Changing the power source

In this section let's talk about modifying the device so that it does not require an additional power source to run.

The Pi Pico can be powered from a 5V power source, either via the USB port or the VSYS and GND pins. In my previous project I went with powering it with the pins, and this is also what I am doing here.

I ordered a buck converter that can take a higher input voltage and output a stable 5V. The on I bought is a variable output converter based on the LM2596 chip. Before using with the Pi, it needs to be configured. There is a tiny potentiometer on the board, and by turning it you can set the output voltage. I connected the buck converter to a 12V battery and checked the output voltage with a multimeter. I turned the potentiometer until the output was exactly 5V. Now the thing that was left, was to connect the converter output to the VSYS and GND pins on the Pi. As always, follow the polarity.

And done, now there is only one plug coming out of the box. When the device is plugged into a 12V power source, it will automatically power up and start transmitting battery levels.

The finished project

Final words

I still need to tweak some things, when I finished the soldering I realized the cables are a bit short. I also need to weather-proof the box. I'm also thinking of adding a thermometer to monitor the battery temperature, but that is something for another project and another blog post.

This has been the longest and most complex blog post so far. I hope you enjoyed it and will build your own device! As always, I would love to hear feedback from you. If you have thoughts on what I wrote, please let me know either via email, or by talking to me on Mastodon. Links are in the footer. Thank you so much for reading!

Building the tiniest NAS with ZFS using a Raspberry Pi Zero

STFN — Sun, 21 Jan 2024 24:00:00 GMT

Some time ago I came across this article about making a NAS from a Raspberry Pi Zero 2W. After reading, it dawned at me that I can make something similar, but turn it up to 11. I decided to make a NAS with a Raspberry Pi Zero W, that will have a ZFS mirror pool made from two USB drives.

Why? Because I wanted to see what would happen, and learn exactly how bad it would be.

I have a Pi Zero W, it was the first Pi I ever bought, but now it was just sitting in my cupboard waiting for a new idea. I broke it's camera connector, so it wasn't in the best shape. I also have the OTG cable for cable, a powered USB hub, and two very cheap 128GB USB drives, that are so slow they cannot be used for any real work. Combining those parts together sounded like a perfect usecase for parts that would serve no other purpose.

Setting up

First I burned a Raspbian Lite 32 bit on one of my smaller microSD cards. I always run my Zeros headless, so I set up SSH and Wi-Fi. I powered the board on, sshed (yes, that is a word, I say so, therefore it is) into it, did the typical apt update && apt upgrade, and started to look for a way to install ZFS.

After checking some options like building the binaries from scratch, I went with the simplest and laziest option:

sudo apt install zfsutils-linux

And I waited. And waited. Turned out that this way, the ZFS utils were being installed for every kernel version I had on the Pi, and there were four of them. Not sure why, I am not well versed in this low-level Linux kernel stuff. Anyway, after five hours it still did not finish installing.

It was getting late and I really wanted to go to bed and turn off my not-so-quiet desktop, so I canceled the build process, and went with plan B: I sshed to the Pi with my phone using Termius, and run the install process again from there by running sudo dpkg --configure -a. The phone kept the ssh session running. Thinking about it now, I could have just connected the Pi to a monitor and keyboard, but that would mean fighting with the cable organization behind the monitor, and again, this was a project driven by laziness.

When I woke up the next day, the ZFS utils were already installed. So it looks like installing NFS on a Raspberry Pi Zero takes between five and eight hours. Oh, and at the beginning you get an error message saying that you should not do it on a 32 bit system. But as they young people are saying: YOLO the police.

Creating the pool

Running a few basic ZFS commands like zfs get all or zpool list confirmed the ZFS was installed on the Pi. Now it was time to create the pool. At first I decided the create the mirror pool on my desktop to save time, and import it on the Pi.

Le nope

I connected the USB drives to the hub, and the hub to the OTG cable connecting it to the Pi. And nothing. Both lsusb and lsblk did not see any drives. The drives did not light up their LEDs. I suspected it's maybe because I created the pool on a x86 64 bit machine and was trying to run it on a 32 bit ARM architecture? I reformatted the drives to ext4 and tried again. Still nothing.

Turned out the Pi did not see my hub at all. I tried all possible combinations, running the hub powered off, powered on, plugging it after the Pi was turned on, plugging it when the Pi was off, nothing helped. Googling (actually Qwanting in my case) showed that the Pi Zeros are very finicky when it comes to accepting USB hubs, so it looked like my hub just wasn't the right one.

Plan B

With the hub not working, and not having another one to try out, I went with plan B, running a single disk ZFS pool. This turned out to be super simple.

First I checked the ID of the USB drive:

>> ls -l /dev/disk/by-id
lrwxrwxrwx 1 root root  9 Jan 20 09:31 usb-Wilk_USB_DISK_3.0_070125F69F331078-0:0

And then, as root, created the pool using the ID:

All commands below were run as root

>> zpool create thepool usb-Wilk_USB_DISK_3.0_070125F69F331078-0:0

I checked where it got mounted:

>> zfs get mountpoint thepool
NAME     PROPERTY    VALUE       SOURCE
thepool  mountpoint  /thepool    default

I could have change the default mount point, but it was fine for this test project.

To see if it actually works and can store data, I downloaded an image from JWST to the pool folder.

cd /thepool
wget https://stsci-opo.org/STScI-01G8GZHGM987XCHJZ846YRHWGF.tif

And it worked! Now it was time for the final step in making my NAS, setting up sharing.

ZFS and NFS

First I installed the NFS server, and then I configured the ZFS pool to enable accessing the pool over the network.

apt install nfs-kernel-server
zfs set sharenfs=on thepool

On my desktop I created a share mountpoint and connected to the NFS share on the Pi:

sudo mkdir -p /mnt/shared-test
sudo mount -t nfs <ip-of-the-pi>:/thepool /mnt/shared-test

So, now I have a tiny NAS that runs a ZFS single disk pool, and shares it over NFS, and is extremely slow, has no data redundancy, and uses USB drives I would not trust even to carry throwaway data from one room to another.

How slow is it?

I uploaded to the pool 16GB of data in files of different size, and it took 4 hours, so write speeds are around 1MB/s. Reading was only a bit faster, but not passing 2MB/s. The bottleneck was for sure the CPU, ZFS uses a lot of processing power, and a single 1GHz core is not a typical ZFS system.

Not exactly a speed daemon, but it was a fun little weekend project. Hope you liked it!

If you know from experience any USB hubs that are known to work with a Pi Zero, please let me know.

Thanks for reading!

My Mastodon bots, and how to easily run your own

STFN — Wed, 24 Jan 2024 24:00:00 GMT

March 2026 - Since writing this post a lot has changed, most of all I moved my bots to my own GoToSocial instance, and GTS has a slightly different API. Those two bots presented below can use either Mastodon or GTS, the codebase provides clients for both. Also, botsin.space has sadly been deleted.

One of the great aspects of Mastodon is that it very simple to run your own bot on the platform. Setting up API credentials is a breeze, and you can start reading or sending toots in a matter of minutes. There are very good docs on how to use the API. There is also a Mastodon Python SDK, a wrapper for the HTTP queries, that makes writing bots even simpler if you already know the language.

I am currently (January 2024) running two bots on Mastodon, both of them I wrote myself and I am hosting them on my VPS, the one which is also hosting this blog.

Astrobin Image Of The Day

Astrobin Image Of The Day is a bot that every afternoon posts the Image Of The Day from Astrobin (duh). Astrobin is an online gallery for astrophotographers to showcase their work, and every day there is an Image Of The Day chosen by a selected jury. Using Python and BeautifulSoup I am parsing the IOTD page, extracting the url and some metadata, and composing a toot with a link to the prized image. This bot has been running for six months now and is slowly building a group of followers. The source code for it is available at my Codeberg.org profile.

Energetyka Polska

Energetyka Polska (Polish Energy Industry) is my new bot, deployed only a few days ago. It posts Polish-specific data, so it's in Polish. Every two hours it pulls data from Electricity Maps API and publishes stats about the state of electricity production in Poland, which types of power plants produce how much electricity, and what is the percentage of renewables and low emission sources in the Polish energy mix. Electricity Maps' API is very simple to use, and with posting twelve times a day, I am well within their free tier. The source code for it is, again, available at Codeberg.org.

Running your own Mastodon bot

Why would you want to run a bot? It's a nice, short project, good way to practice a programming language of your choice, and allows to show your work to the world without doing complicated deployments, the heavy lifting being handled by the Fediverse.

First a word of caution: When considering creating a bot, please make it for something good, to share interesting data, to alert about important stuff, to make people's life better. OK? Thanks! Don't be a spammer.

To make creating bots even easier, I have created a template project in Python that you can use. It's available here at my Codeberg repo. Feel free to fork it, or just download, amend to your needs and run.

I believe the README file says everything required to run and deploy the bot, but if something is missing, please let me know. Running the bot requires only basic Python and Linux skills, and should be of no problem for anyone who ever touched the terminal.

One thing to consider when deploying a bot is choosing the instance for it. There are instances dedicated for bots, like botsin.space, or you can choose a generic one. Please, however, check each time the instance's rules whether it allows hosting bots, and what are its rules regarding acceptable types of content.

Next you will need a place for it to run. It kind be any type of Linux* machine, even a Pi Zero, or an ancient Thinkpad will do. Basically anything that can run Python and cron. Deployment instructions, again, can be found in the repo's README file.

* Windows or Mac, probably could also work, but come on, who uses them? Not me.

If you would like to contribute to the repo, hit me up, we can make it a group project!

And that's it! If you are going to use the template for your own bot, it would be awesome if you could tag me somewhere, thanks!

The time came to replace my headphones

STFN — Wed, 07 Feb 2024 24:00:00 GMT

I bought new small headphones. My previous ones were Huawei AM61 which I bought in 2018. I try to use any electronic device I buy to the fullest and as long as possible, but they were getting long in the tooth, with the rubber parts falling off. The cable was getting in the way in thick clothing, and the Huaweis were the only portable device that I had with a micro-USB cable, which meant I had to remember about yet another cable when traveling. I lost the rubber earcup a few days ago and I had enough. And so I searched for a replacement.

I had very simple criteria for new headphones:

small so that they can fit under a beanie in winter, and so that I can take them anywhere without reducing my backpack capacity
sound quality good enough to listen to podcasts
charge via USB-C cable as my laptop, phone and powerbank
cheap so that I won't be too sad when I lose or drown them

As you can see those criteria were basic, as I already have good, large headphones with ANC for work and leisure indoors (Sony WH1000XM3). The new ones were meant to just be something I can throw in my backpack or my pocket anytime and allow me to listen to stuff and isolate from the environment on the train of on a walk.

I also decided I want to try out separate earbuds, AirPods style, to see if being totally cable free will be something I like (spoiler alert: I like it very much).

After doing some searching, reading and comparing I went with Edifier X3s

Why Edifier X3s

The answer is short: they fit all of the criteria listed above and they are the cheapest earbuds from a brand I somewhat recognize.

I paid for them 99PLN (~22EUR, 25USD) with free shipping on Allegro, a Polish Amazon equivalent, and with my experience so far I can say that for the price they are almost perfect, with minor issues.

I've been testing them for two days now, mostly walking and listening to podcasts, with occasional music and a call from my mum.

Pros

They just work, pairing was super fast
Sound quality for podcasts is very good, the sound is clean and crisp
I had no problem having a call using them, even though they were covered under a beanie, the caller had no problem understanding me
USB-C!
Cheap

Cons

While the earbuds themselves feel sturdy and have a nice weight to them, the case feels super cheap, but hey, you get what you pay for
It is not easy to pull them out of the case, there is no good handle on the buds and the plastic is slippery, this I think is the biggest con so far
I wish there was a way to temporarily lock the touch functionality on them so that I can handle the earbuds and not change track/volume/whatever by mistake

Summary

If you are looking for basic earbuds that just do their job, then those will be good for you. I'm happy and would recommend them.

Of course, this is not a sponsored article, I bought them with my own money after doing some searching myself.

Thanks for reading!

the social network

STFN — Sun, 18 Feb 2024 24:00:00 GMT

So I've seen The Social Network again. The last time I saw it was back in 2010 just after the premiere.

I feel this is still a great movie that did not age one bit, on the contrary, it became even better and more up-to-date with all that we know and have experienced in the year 2024.

From the cinematic point of view the movie is beautiful, with those shots, those colours, that montage. Atticus' and Trent's soundtrack is a cherry on top, highlighting what happens visually. The dialogues, the tempo, the back and forths between Mark and the rest are oh so good.

But that's not what I wanted to talk about.

Watching that movie today in 2024 gave me much food for thought than in 2010. Partly because I am older, partly because I am now a web developer, and partly because Facebook is now 20 years old, and we have all seen its rise and fall.

My story of using Facebook is probably similar to the stories of many of my peers. I've joined Facebook in the summer of 2008, between my first and second year at the university. The fact that I remember this date already says something. Around 2008 was the date that Facebook was gaining traction in general in Poland, and it was doing so on the smouldering ashes of other, older Polish platforms of similar kind, like Grono.

At that time Facebook was the cool thing at I was using it daily to connect with my friends. I remember updating statuses, posting tons of photos from parties of even simple walks. Facebook was used to coordinate plans even before there was Events or even Messenger. Poking was a thing. You people remember poking? And that simple, squarish interface? And the chronological timeline? And liking stupid pages like "putting water on your toothbrush" or "it rough". And the facebook quizzes? The way FB was used back then was immortalized in this epic Youtube video made by some random guy who later became the most popular Polish rapper. Adding someone on Facebook was an important thing.

I have been using Facebook this way until somewhere around 2013? More or less. I finished University, I moved to other networks, mostly instagram and tumblr. People stopped posting personal stuff. Organic growth of fanpages was cut, the timeline became algorithmic, it got filled with ads and sponsored content.

That was the first total enshittification of a platform that I have encountered. And then came the Cambridge Analytica scandal. And accusation of tampering with elections outcomes. And Facebook just being a global playground for spreading hideous right wing propaganda.

At some point the situation arrived to what it is today. When I open Facebook today maybe 1% of the content I see is coming from people I know, the rest is just random pointless garbage. Face, as we used to call it, became an empty husk of itself, with Zuck moving to the Metaverse and its VR shitshow.

This post does not have a thesis or a moral. It's just a reminiscence of a time in my life and the impact of one specific social network on it.

I can say with full certainty that I grew up and came of age on the Internet, and the period of Facebook was an important part of my Web upbringing. As someone said, those were the days, and now there are no days.

In the second scene of The Social Network, Zuck opens his LiveJournal to blog about his heartbreak. With the fall of Facebook and the rise of decentralized networks like Mastodon and rebirth of blogging, I feel that life is writing the new final scene of TSN, with the Internet coming full circle, from blogs to Facebook, to blogs. Just like this one. And all the ones I follow.

Thanks for reading!

I gave my first public talk on Python

STFN — Sun, 03 Mar 2024 24:00:00 GMT

On the 29th of February my employer organized a Python meetup, PyRa2024, at their office in Poznań, and I was encouraged by a few colleagues to do a talk there. I wasn't sure what to talk about, I don't feel like have anything interesting to say about Python, even though I work with it every day. But later , is struck me: I can talk about MicroPython! It will be fresh, I have not heard about anyone else talking about it, and I already have the content ready, I could present my projects that I have been writing about on this blog.

And so my presentation "MicroPython - how to start" was born. I talked about how to make a weather station from a Rapsberry Pi Pico, basically the content of these blog posts:

Raspberry Pi Pico Weather Station - part I

Raspberry Pi Pico Weather Station - part II

Powering Raspberry Pi Pico with AA batteries (Weather Station Part III)

I was stressing about the whole thing for weeks before, but when I went up to the stage, I just started talking, and the whole thing went smoothly, even when at one point Thonny decided to not work as intended, something that never had happened to me before. The beauty of Murphy's law and live coding.

I had a Pico with me, and I spent most of the talk running code from it, even showing how to do a MQTT integration with a broker on my laptop.

After the talk I got a lot of questions from the very kind audience. The questions were so good and in-depth, that for an embarrassingly high percentage of them my answer was "I don't know such details" :D And the cherry on top was this one person who came up to me at the end and said that they came to the meetup specifically for my presentation. If you are reading this, thanks again for coming and for the kinds words <3

BTW, the other speaker, Jacek Kołodziej, had a very interesting talk about Python's GIL, check it out!

This is me showing a bunch of cables with a Pico somewhere along it, the pic taken from the How to monitor 12V battery charge with a Raspberry Pi Pico blog post. Thank you Karolina for taking the photo and for the support from the first row <3

So that was my first talk, and let's hope it won't be the last. Thanks for reading!

My first steps in Meshtastic

STFN — Mon, 18 Mar 2024 24:00:00 GMT

This post is a log of my initial experiences with Meshtastic. It it also meant to be a compilation of the knowledge about Meshtastic I have gathered so far. I hope it will be beneficial for others who want to join the Meshtastic club/cult/family, but please bear in mind that it is in no way a complete compendium. If you see any errors, please let me know. I hope to write another post once I know more.

For some time now I've been drawn to radio communications. There are many reasons why it interests me, among them being its romantic, old-school charm, its basis on electronics and physics, its strong DIY culture, and independence from the Internet and corporate, commercial environment. Ham radio is a fascinating part of the alternative, off-grid, survivalist, I could even use the word "punk", culture which has been very close to me in the last years.

I don't have a radio license yet, so apart from the doing a lot of learning, I am investigating possible ways to engage myself in radio comms that are available to unlicensed individuals. And that's how I came across Meshtastic.

What is Meshtastic?

It took me a while to understand what exactly is Meshtastic, so I'll try to summarize it here in the clearest way possible.

Meshtastic is a project that allows text communication, on a certain level you could compare it Facebook Messenger or IRC, or Gadu-Gadu if you come from my country.

In contrast to FB Messenger, it does not use the Internet*, but radio waves. Therefore to be a part of the Meshtastic network, a special piece of equipment is required to send and receive messages. That piece of equipment is basically a microcontroller with a small, low power radio transmitter. There are many different devices that support Meshtastic, some can be used standalone as they have a screen and a keyboard, but most need to be paired with a phone or other device, that will provide the interface to send and receive messages. Example models of such devices are the LILYGO ESP32, Heltec V3, or the RAK Wisblock.

* it can but let's ignore it for now.

Meshtastic communication network has channels just like IRC. When you start your Meshtastic device for the first time, it will be configured to listen to the default channel, it is the same channel for everyone. You can also create your own channels and configure two or more devices to talk privately using them. The communication is encrypted.

Meshtastic is a peer to peer network. There are no central servers. Every device works as a repeater, meaning that it forwards any message it receives. Messages have a limited lifespan, they can only travel through several devices (hops) before they expire. This makes the network resilient, there are no single points of failure as long as there are enough devices to continue passing messages. Meshtastic devices can be left on their own in remote locations and they will automatically work as nodes, forwarding any message they receive.

Meshtastic is based on the LoRa radio communication system. LoRa is a LOng RAnge low power system that trades range and power for bandwidth. That's why it only supports text, no voice or media.

Meshtastic can be used without a radio license because it uses parts of the frequency spectrum that fall under the ISM (industrial, scientific, and medical) laws. Such frequencies can be used by companies and individuals that do not have a radio license, however there are limitations in the transmit power and the time the frequency is used by a single device. In Europe the available frequencies are 433MHz and 868MHz, and in the USA it's 915MHz. I don't know about the rest of the world.

My beginnings with Meshtastic

I don't remember where I first came across Meshtastic. I suspect it might be Mastodon. At first it was very confusing for me what Meshtastic is what is provides, so I did some more digging. And that's one of the reasons I am writing this blog post, so that people have it easier than me. One of the first sources of information I came across was the Polish Meshtastic site lora.waw.pl. And well, technically it's ok, but the "promotional materials" that its author published on Youtube appalled me. A bunch of suggestive images cobbled together, with audio commentary going from one conspiracy theory to the next, with strong vibes of "new world order", "covid was a scam" and antivaccines. Don't watch it, don't waste your time. It pains me that on the Venn diagram of lifestyles, certain off-grid people are sometimes close to the tinfoil hat lunatics.

Anyway, having more technical knowledge I went to buy my first LoRa Meshtastic device. Browsing through available options, I went with a cheap solution, and ordered a LILYGO LoRa32 ESP32, 433MHz from Aliexpress. I went with the 433MHz version because I read someone's comment on a Facebook Meshtastic Poland group, that it works better in the countryside where I live.

You can also order it straight from the manufacturer's site: LILYGO LoRa32 V2.1_1.6

Screenshot of an Aliexpress listing of the LILYGO ESP32 LoRa

First Tests

The device arrived in about two weeks. It came in a plastic case, with a small antenna and PH2 cable to solder a battery. The provided antenna is around 5cm in length, and from what I read later on, it has a range in meters more than anything else.

I connected the antenna to the board (you cannot power on the without the antenna attached, it will break!) and connected it to my PC with a microUSB cable. I flashed it with Meshtastic software using the flasher.meshtastic.org/ site, I chose the T-LoRa V2.1-1.6 option. While it was flashing, I installed the Meshtastic app on my Android Fairphone 4. When the flashing was done, I unplugged the radio from my PC and connected it to a power bank. The pairing of the device with the Android app was straightforward, it works as any other Bluetooth pairing.

Of course it did not find any nodes when I took it outside in the small town where I live. I did not expect anyone else here uses Meshtastic. So I went to a hill that overlooks the nearby city of Poznań (~600k inhabitants) and tried my luck there. And... nothing. No nodes.

My 433MHz LILYGO hanging from a bush on a hill, trying to find some friends.

I decided then that the next course of action would be to get a better antenna. I ordered a much larger antenna dedicated to the 433MHz frequency. It arrived much faster, as I ordered it from a Polish shop.

Screenshot of an KONEKTOR (local Polish hamradio shop) 433MHz antenna listing.

That still did not give me any contacts around Poznań. I went back to the drawing board, did much more reading, especially on the Meshtastic global FB group, and it turned out, that here in Europe, 868MHz is a much more popular band. And it is also better from a technical point of view, as the 433MHz has much stricter restrictions when it comes to transmit power. So with a heavy sigh, I ordered another LILYGO, this time in 868MHz. I also ordered an 868MHz antenna to match. I was telling myself that despite all that I still spent next to nothing in comparison to my astrophotography equipment. The new radio arrived after two weeks, just a few days ago.

Current situation

Last weekend I had some business to do in Poznań, so I took my 868MHz LILYGO together with me. I wanted to do some walking around the city centre to try to get some contacts. Sadly, my walk was cut short when the nice weather turned into freezing rain, and let's just say I did not have the clothes for the occasion. I went to the train station to go home. I had my radio on the whole time, as well as during the whole train trip, but still I did not find any nodes.

My 868MHz LILYGO looking for other nodes in the center of Poznań.

Right now my plan is to take both my 433MHz and 868MHz radios with me and try again making contact from the hill overlooking the whole city. If that does not work out, I'll again do a walk through Poznań, this time much longer, and hope I will make a contact at last.

I think I'll also buy another 868MHz node, this time from RAK WisBlock to do some more testing, and maybe try out connecting sensors to nodes.

From all my hobbies, this has been the loneliest so far, even though it's all about communication :D

My two LILYGO radios

Other stuff

Case

A case would be a good idea, carrying a bare PCB with an antenna sticking from it is not the most ergonomic solution. I found a case design on Thingiverse that fits my LILYGO, and I'm looking for someone in my town to print it out for me. Will update once it is printed.

How to make your Meshtastic node visible on the map

There is a worldwide map of nodes available, but making your device visible on it is not enabled by default, and takes some work to do. It is not simple and took me some time to understand it, so I'm sharing with you the needed steps. Remember that every time you change the config, the device restarts and you need to reconnect to it.

I assume you have a working Meshtastic device connected via Bluetooth to your mobile phone app.

In Radio Configuration in the Network tab set up the WiFi network and connect it to WiFi. In the radio list (last tab of the main screen) you should now see an IP address of the radio to connect it. You will no longer be able to connect to it vai Bluetooth.

In the Location tab set the location. I prefer to manually set a location, and set it to the town centre for privacy reasons.

In the MQTT tab, enable MQTT. Do not change the default MQTT URL, login and password.

In the Channels tab, tap on the default LongFast channel, and in the popup enable Uplink enabled.

In the LoRa tab, deselect Ignore MQTT.

Within a few minutes, your device should become visible on the map.

The downside is that your device will now use not only radio waves, but also the web to see other devices. This might sound like an advantage, but in my opinion kills the main reason for using Meshtastic: being independent from the Internet.

And that's it for now. A lot of things I still don't know about Meshtastic, but some basis I already have, and I always enjoy sharing my knowledge. I will be writing more on radio communications once I get more experienced in the topic. In the meantime, thanks for reading, and please, please give me feedback on what I wrote and most of all, point out any errors I have made.

Special thanks to Szescstopni and Piotr Sikora for them sharing their knowledge with me on LoRa.

Shorts 1

STFN — Sat, 23 Mar 2024 24:00:00 GMT

This is the first episode of Shorts, a post in which I share things that raised my interest in the last few days.

Lithium-Ion Batteries Power Your Devboards Easily

A great article showcasing how to power your boards whether they need 3.3V, 5V, or either. The article also talks about batteries, TP4056s, buck/boost converters and voltage regulators. All that tasty electronics stuff.

Using the TP4056: There's a right way, and a wrong way

Continuing on the topic of powering stuff, an eye-opening article on how to use the TP4056. I did not know you cannot use it to charge the battery and power boards at the same time! At one point I was thinking to use a TP4056 to power a Pico and charge a 18650 from solar panels, good that I went a different route then.

The simplest antenna to receive NOAA weather satellite imagery

A video tutorial how to make a NOAA antenna from some electrical connectors and a bundle of wire. The video is in Polish, but everything is shown clearly, and physics are universal, so there's no need to listen to it at all.

Vitalii Koshura's blog about BOINC

Vitalii Koshura is one of the maintainers of BOINC, and recently he started updating his blog more regularly. Highly recommended to everyone who is passionate about distributed computing.

There are more Starlinks in orbit than known exoplanets

Prof. Sam Lawler toots a lot how Starlinks are destroying Low Earth's Orbit and causing massive problems to astronomers and other scientists. And now there are more Starlinks in orbit than known exoplanets.

I finished reading 747: Creating the World's First Jumbo Jet and Other Adventures from a Life in Aviation by Joe Sutter. It's a captivating book showing the whole life of Joe Sutter, nicknamed "the father of the 747". What hit me the most is the stark contrast between his days, putting safety and engineering prowess as the main and most important aspects of every part of work at Boeing, and how things are going in Boeing today, with the Max's failure after failure.

I started listening to the Hackaday podcast and got instantly hooked.

How to make a timelapse with a Raspberry Pi

STFN — Fri, 05 Apr 2024 24:00:00 GMT

12 hours in 24 seconds.

Spring is here and it's time to put some plants into the soil. When the seeds started to sprout I got this idea that it would be cool to record a timelapse to see how plants grow.

My fiancee and I, we now have several trays of seedlings on our windowsills, and I chose the largest one as the actor in the timelapse. The largest plants are the pumpkins, in the front there are cauliflowers, and on the right we are waiting for celery to appear. In some time, all those plants will go into the soil in our garden. In other trays we have more pumpkins, watermelons, a lot of tomatoes and bell peppers.

Going back to the topic of making timelapses, I assembled some hardware, did some searching on the intertubes, and came up with the following plan of work:

Hardware and Software

First, the hardware part.

To make the timelapse, I am using a Raspberry Pi 4b with the Camera Module 3 NoIR.

The case is the Raspberry Pi Cluster Case from PiHut to which I attached the camera with a metal l-bracket and some bolts.

For the software part, I am using Pi OS Bookworm Lite 64bit and libcamera library to control the camera. For info how to do an initial configuration the camera, refer to libcamera docs. Batch editing of the timelapse images I am doing in darktable, and the final assembly of images into a video happens in good old ffmpeg.

Running the timelapse

I placed the Pi on a very janky construction made from stools and cardboard boxes. In the future I want to find a way to add a tripod mount to the base of the cluster case, that will save me a lot of hassle and allow for very precise positioning of the camera.

The Pi is running headless as all my other Raspberries, so I sshed into it from my PC.

First I made a few test images to check the framing, to do it quickly I ran

rpicam-still -n -o test.jpg && scp test.jpg <PC IP>:/home/<user dir>

This command takes the picture and copies it from the Pi to my computer in one go. I will talk about the different arguments in a moment. Once the framing is good, it's time to run the actual timelapse:

rpicam-still -n --timelapse 60000 -t 0 -o capture_%05d.jpg

rpicam-still is the name of the app for taking still images. I know, nobody would have guessed that. -n means "no preview window". We have no video output from the Pi, so there is no way to a preview window. An alternative would be to run a full desktop image of the Pi OS, and open the desktop remotely using a VNC client. But I prefer to just ssh. --timelapse 60000 defines that it should be a timelapse, 60000 is the number of microseconds between frames. 60000 microseconds is 60 seconds, so one minute between captures. -t 0 is for setting how long the timelapse should take, in microseconds. 0 means indefinitely, until you cancel the app with ctrl+c, or the Pi turns off. -o capture_%05d.jpg is about the naming of the images. %05d means 5 digits, so the first captured image will be capture_00000.jpg, the second capture_00001.jpg etc. If there was no digit placeholder defined, all timelapse images would be saved to the same file.

If the timelapse gets interrupted, and you want to continue it without breaking file numeration, the initial number of the frame can be defined with:

rpicam-still -n --timelapse 60000 --framestart 389 -t 0 -o capture_%05d.jpg

With that, the timelapse will start with the first image saved as capture_00389.jpg

There is much more configuration available for the rpicam apps, refer to the libcamera docs for a full list.

And now the timelapse is running. Leave the Pi alone for a few hours, and occasionally check if new images are being created. You can open another ssh connection to the Pi and ls the image folder.

To copy the images from the Pi to my PC I use rsync. It ignores the files that are already copied to the destination, so I can run it from time to time to just copy the new batch.

rsync --progress capture* <PC IP>:/home/<user dir>

Preparing the files

Once the timelapse is done and the files are copied to a PC, it's time to do some editing.

I have a Camera Module that does not have the IR filter. I bought it for astrophotography and have not used it for this means so far. So yeah, not great. Anyway, not having an IR filter means that when shooting in daylight, the colours are off. And so I needed to correct them. My timelapse turned out to be 730 images, so editing them one by one was not feasible. GIMP does not have a tool to do batch editing, so I turned to darktable.

Kudos for people in this thread for sharing how to do it.

In darktable, I imported all 730 images, and went to edit the first one. When the colours were much better I came back to the library view, and on the right, under styles, I selected create. This created a new style, a preset from the edit history of that first image. Then I selected all images with ctrl+a and double clicked on the saved style. This applied the edits to all files in one go. Then all that was left was exporting. Again in the library view, I went to export in the right hand bottom corner, changed the size to 1920x1080 and exported all images to a new folder. Editing was done, and the last part that was left was...

Creating a video

To create the video from images, I took my inspiration (meaning I copied and pasted) from this article.

Here's the command to create video from images, with my edits:

ffmpeg -framerate 30 -pattern_type glob -i "*.jpg" -s:v 1920x1080 -c:v libx264 -crf 17 -pix_fmt yuv420p my-timelapse.mp4

~~And that's it! The timelapse is done! Finally, to embed the video here on my blog I used video.js.~~

March 2026: As part of my move to Bunny CDN, I also switched the video player to the one provided by Bunny Stream

Thanks for reading! Spring is coming so in the upcoming weeks there probably will be more posts about gardening and other outdoor stuff, and less about tinkering with computers and solder. I've been having some doubts whether this blog should be computers-only, or should it just be about anything I do and find worthwhile sharing. For now I am leaning towards option 2, but I would love to hear your feedback on it. Thanks fo reading! Please leave a comment or reach out to me via email or Mastodon.

and random linguistic fact: in Polish those small plants that you grow on your window sill to later put into soil are called "flance", from German pflanzen.

IS TICKLESS Pet really single use?

STFN — Tue, 09 Apr 2024 24:00:00 GMT

No, it's not. Yes, you can apply Betteridge's law here.

We have a large dog, a mix of a Belgian and German shepherd, and we take him on a lot of walks in forests and fields. My fiancee bought for him an ultrasonic ticks and fleas repellent called TICKLESS Pet. It's 30EUR / 140PLN, so not the cheapest device. The promotional materials said that you turn it on by pulling the plastic tab, and then it works for six months continuously. At the time I did not pay much attention to that claim.

Last week Alicja came to me and said that our dog took a bath in a stream, and the device stopped working. The thingy has a single button, you can click and then a green LED blinks to confirm that it's still working. That's the only interaction with the device that you can have, you cannot turn it on or off. Now the LED did not blink. "Can you do something with it?". And I said I'll try.

Getting inside and bringing it back to life

First let's consult the FAQ on TICKLESS's page:

Screenshot from TICKLESS's FAQ available at tickless.com/en/faq-2/

TICKLESS is a closed system.

It's really hard to agree with that statement when the device is in a plastic case with massive holes to let the ultrasounds out. Opening it takes a few seconds, the case needs to be delicately pried open at the seam, any wedge or screwdriver will work.

The device in it's glory. You can see the logic board through the holes in the case

Opening it reveals the main part: a simple logic board with a few SMD components, some chip, an ultrasound speaker... and a CR2032 holder with a totally standard button cell.

The case opened and the logic board inside

Front side of the logic board with the ultrasonic speaker

Back side of the logic board with the battery holder

Again, to quote the FAQ:

Can I change the battery? No!

Why would you not be able to change the battery? It's not soldered in, it's just press fitted into a typical cell holder that can be found in any other device, like a TV remote control.

I removed the battery, carefully cleaned the whole board with a q-tip soaked in isopropyl alcohol. There was some surface rust from the water getting into the "closed" device, but no connection looked to be damaged. I put the battery back again, and the device came back to life, the LED blinked, and blinked again when I clicked the button. The case also had no problems being assembled again, it's also press fitted.

Now the device is back on the dog's collar, and once the battery discharges, I will just put another CR2032 in. And barring any physical damage, it should work for another six months.

Bottom Text

I feel that this is a prime example of planned obsolescence. I know this is not something large and expensive as a washing machine, but still, it's a piece of electronics that can work for a long period of time, but is designed in a way to not last long, unless one is willing to go an extra mile. It would not be a manufacturing problem to add an easy way to open the case to simplify changing the battery. Of course, TICKLESS offers a rechargeable version, but it's almost twice the price.

I hate single-use electronic devices, and the problem is growing. I've seen single use vapes (the EU will be doing something about them soon), even single use powerbanks, and that waste of resources is just unacceptable.

So yeah, just wanted to share my disdain for such practices, and maybe someone will save some money from my findings, and a small electronic device will not go to landfill that soon.

Thanks for reading!

BTW, I'm thinking of finding a way to listen to the sounds it's making, I just need to find a microphone that will hear ultrasounds. Any recommendations?

Making a portable Meshtastic node

STFN — Tue, 16 Apr 2024 24:00:00 GMT

I am continuing my journey with Meshtastic, and since my last post I made some progress, yet mostly in hardware. ~~~I still did not connect to anyone over LoRa~~~*, but I had some interesting communications over MQTT bridges. And I made a portable node, and I am in the process of making and testing a solar-powered remote node.

* scratch that, just before posting this blog post I finally made contact over LoRa at 433MHz!

This is going to be a short post showcasing how I built my portable node and what are my future plans. Maybe it will be source of inspiration for someone.

The Parts

For the Meshtastic node, I am using a LILYGO ESP32 LoRa32 V2.1_1.6. It comes with a JST-PH socket to connect to a 3.7V Li-ion battery pack, and this is the powering solution I am using for this build.

Note that your device might have different power requirements, check that before following what I did.

The parts list is very short and simple:

A plastic case
An 18650 battery holder, connected in parallel or not connected from the factory, more on that later.
A short SMA extender
USB-micro charging cable
cables and short pieces of wire, I used leftover resistor legs

You will also need the usual assortment of tools, a drill, a soldering iron, a heat gun, a glue gun and wire ~~gun~~ strippers.

The battery pack

When it comes to the battery holder, you can use any size that fits your needs, a single 18650, two, three, or more. What is very important is to find one that connects all batteries in parallel, or allows to freely wire it. More often than not, 18650 battery holders are wired in series, and this is not what we want. What we want is to provide the voltage of a single 18650 cell (~3.7V), and the capacity of multiple cells. To achieve that we need to connect every cell in parallel. Meaning that the positive side of every cell is connected to one wire that goes to the positive connector of the LILYGO. The same happens on the negative side, all negative cell connectors are connected with a single wire and go to the negative connector of the radio. In result, we will have a battery that works as if it was a single cell with a large capacity.

I bought a battery holder that had no connections between individual cells, so I soldered them:

Battery holder underside with no connections

Connectors on one side connected

Cable going from one side, it will connect to the LILYGO, the same will be done on the other side

The cables coming from the battery pack, I soldered them to the JST-PH connector that came with the LILYGO. Cells can be placed either way in my battery pack, so for the time being, the polarization doesn't matter, it will matter when inserting the cells into the holder.

The antenna and charging

As for the antenna, I got this SMA extender to allow the antenna to be outside the case. I drilled a hole in the case with an 8mm drill (a 7mm would probably fit better but I did not have one), and the male end of the extender through it, secured it with the provided nut.

Finally I drilled another hole with a 10mm drill, and put an IKEA micro USB cable through it to allow charging the LoRa radio without opening the case.

Now came the big part.

The assembled Meshtastic node

Assembly

The assembly was simple, I connected the antenna, then the battery pack, paying special attention to the polarization of the cells. All have to go in in the same direction. And the cells need to be placed in the correct orientation, with the positive terminal connected to the positive terminal in the device's socket.

Once I was sure everything was working fine, I hot glued the battery pack to the case. I put the charging cable through the larger hole, tidied it with some cable straps, and hot glued the whole to keep it in place, leaving a short length dangling for easier charging.

Finally I put a piece of foam inside the case to make sure things do not rattle around when carrying, and screw in the lid.

And that's basically it! Short, fun project that resulted in a Meshtastic node that you can safely carry around, and when using three or so 18650s, will work for a few days without charging. My case is relatively weatherproof, and safe to carry in a backpack.

My node living free in the wilderness

Future improvements

One downside of this build is that there is no way to see the screen, but then again, I use the Android app to interact with the radio and do all the configuration. What I would actually add to the node in the future would be an on/off switch to conserve battery, and maybe a cable holder to stop it from dangling freely.

Continuing my Meshtastic journey

I am planning to take this node on a trip with me to some cities and try to make contacts with the locals.

Apart from that, I am right now building and testing a solar-powered node that will eventually be placed on my piece of land. A blog post on it should appear in the next few weeks.

Many thanks to people of Mastodon, and Meshtastic, and Meshtastic Polska Facebook groups for feedback and inspiration.

The Space Shuttle - how I remember it

STFN — Tue, 23 Apr 2024 24:00:00 GMT

A few weeks ago, Scott Manley made a video about a nonstandard Space Shuttle landing at the Edwards Air Force Base. The video was based on a blog entry written by Wayne Hale, a Space Shuttle Flight Director.

When I come across a new blog, I rarely read the old entries, maybe one or two of the latest ones. As for Wayne's diary, I am in progress of reading the entire thing. I cannot recommend his writing enough. It's captivating, technical, yet accessible at the same time. He talks about the day-to-day work of being a Flight Director, about the hair raising emergencies, and everything in between. I hope he'll make a book of his memories one day.

Reading his blog about the Space Shuttle made me think about my memories and experiences with it.

I remember when my dad was getting us The Internet for the first time, it was somewhere in 1996, if I recall correctly. I was eight by then, and I don't know why, but my first thought when I was told that we are going to have Internet at home was that I will be able to visit sites about the Space Shuttle. Why those in particular? I don't know, I was not a space nerd during that time, but somehow I made a connection between the tubes and the Shuttle. Maybe because both of them were for me insanely advanced technology? Children's minds work in mysterious ways. Funnily enough, I don't remember actually visiting "those sites", but the anticipation stayed in me.

Fast forward a few years, and I vividly remember watching the Columbia disaster in real time. That also stuck in me. Watching CNN and other English-speaking stations despite my not-so-great proficiency in that language. My dad facepalming at Polish media reporting that the Shuttle was traveling "several times the speed of light" during reentry. He said that he still remembered witnessing the Challenger disaster, he was in the Army back then (in his time, every Pole had to serve in the Army for a few months), and he and his team were sitting around the radio listening to the news.

I also remember watching Space Shuttle launches broadcasted live when they came back to flight. I was then in high school and watched them on my first own PC, and tried to interest my high school crush in the topic (that did not work out, as the whole relationship thing with her).

I remember reading how the Space Shuttle built the ISS, following the construction of solar panels and trusses and living quarters.

Fast forward again, it's 2011 and I am watching the finalest ever landing of the Space Shuttle, STS-135, and I feel that an era ends.

To think about it, the Shuttle was always somewhere in the background for most of my life. My fascination with space and spaceflight would come and go through all those years, with ebbs and flows, but it was there.

Now as I am older, I understand better the full story of the Shuttle, how it was the most advanced flying machine that the mankind has ever created, and in a way a financial disaster for NASA, about all the compromises that had to go into building it.

And thanks to Wayne's blog I am able to relive all that, and learn even more about the machines and people who built it and flew it and controlled the missions.

Just like Wayne is, I am now excited for Artemis. Much more for Artemis than for Starship, as I prefer governmental institutions going to space for science, rather than capitalists doing it for profit.

Thanks for reading!

P.S. It's funny, I have only two types of blog posts, the first category are the ones I write for weeks, project updates and such, and the second one are personal musing like this one, which I am able to finish in 30 minutes, 1 hour tops. There is nothing in between. Any you never know when inspiration hits you.

Reducing Raspberry Pi Pico W power consumption and a second attempt at using solar panels

STFN — Tue, 07 May 2024 24:00:00 GMT

If you don't want to read the intro, just jump straight to conclusions.

Almost a year ago I made my first attempt at making a solar panel powered weather station using a Raspberry Pi Pico. That attempt turned out to be a failure, the solar panels I used were not able to prolong the the life of a Pico in any significant way. I abandoned the project and moved into different fields, mostly ham radio. And then came winter and any solar projects went into total hiatus.

Fast forward 10 months, and the summer is almost here, again there are long sunny days, and I have renewed interest in solar power. What is more, I am also looking into powering not only Pis, but also Meshtastic nodes with solar panels, something that I will write about very soon in an upcoming blog post.

And this time I am working in two directions, first I am investigating ways to reduce Pico's power consumption, and secondly, looking into better panels to power the Pico from the Sun.

Let's first start with the usage of electricity, and the move to its production.

Measuring Raspberry Pi Pico W power consumption...

What I will be describing here applies specifically for the Raspberry Pi Pico W, but I believe it can be also applied to other microcontrollers with Wi-Fi connectivity. Now as I am writing it, I think I might do at some point a comparison between a Pico W and an ESP8266 that I also have lying somewhere in a cupboard.

I am running Micropython on my Picos, however the findings here are independent of the language used.

Current monitoring

To monitor the power consumption in real time I bought a UNI-T UT658 USB monitor. With what I know now, I would buy something else, this monitor only shows three decimal places when it comes to amps, meaning I can only know the current (the current current?) in tens of miliamps. Then again, it's better than nothing, and the meter allows for prolonged measuring of total usage, so I can calculate the average current within a period of time.

Hardware setup

In my first attempt, I used a Pico W with a BMP280 and DHT11 sensors. All three were soldered to a development board, with an ARC connector to power the microcontroller. You can see the pictures in the previous blog post linked at the top. This time I went with a much simplified setup, I am using a BME280 sensors that can check pressure, humidity and temperature from a single chip. For powering the Pico, I used the micro-USB connector for testing, and female-to-female jumper cables for the "production" run.

For testing purposes I have been powering the Pico from a standard powerbank, with the UNI-T in between the bank and the micro-USB cable going to the Pico.

Software setup

This is the initial script that I run on the Pico. It is a simplification of what I've been running at the previous attempt.

import json
import time

import bme280
import machine
import network
from umqtt.simple import MQTTClient

sdaPIN=machine.Pin(0)
sclPIN=machine.Pin(1)

i2c = machine.I2C(0,sda=sdaPIN, scl=sclPIN)
bme = bme280.BME280(i2c=i2c)

led = machine.Pin("LED", machine.Pin.OUT)

ssid = "SSID"
password = "PASSWORD"

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(ssid, password)
max_wait = 10
while max_wait > 0:
    if wlan.isconnected():
        break
    max_wait -= 1
    time.sleep(1)

if not wlan.isconnected():
	machine.reset()
    
while True:
    led.on()
    time.sleep(0.2)
    led.off()
    data = bme.read_compensated_data()
    payload = {
        "temperature": data[0] / 100,
        "pressure": data[1] / 256 / 100,
        "humidity": data[2] / 1024
        }

    qt = MQTTClient("umqtt_client", "MQTT_BROKER_IP", keepalive=3600)
    qt.connect()
    qt.publish(b"weather", json.dumps(payload))
    qt.disconnect()
    time.sleep(60)

A full description of what this script does can be found in the previous post (link at the top), but let's recap it here, it's very simple.

First import all of the required modules. Next, initiate the I2C interface and the BME280 environment sensor, define the pin of the internal LED.

Second, connect to WiFi. If connecting to wifi timeouts, restart the Pico.

Now we enter the eternal loop in which we blink the LED, ask BME280 nicely to measure the environment, connect to the MQTT broker, send data and go to sleep for a minute.

I saved the script as main.py so that it would run when the Pico was powered, disconnected it from the PC and plugged it into a powerbank, with the UNI-T in between. And the results were surprising to say the least:

The Pico W is using ~45mA all the time when WiFi is on

45mA may not sound like a lot, but if you have a Pico running from a 3000mA battery, you'll get 75 hours at best of runtime. And small, cheap solar panels will not provide enough current to power the Pico and charge the batteries at the same time. This is why my previous attempt failed.

Testing the Pico's power usage

...And how to lower it

Time to finish that very long intro and move to the actual solution. I went to the Interwebs to see how others solved this issue. At first I thought that deepsleep or other low power modes would be the answer, but it turned out that the Pico's flavour of Micropython does not support deepsleep at all, only lightsleep. And using lightsleep did not make any significant change during my testing. The actual solution was much simpler:

Turn off Wi-Fi

Turns out the Wi-Fi chip is the single largest power guzzler on the whole board, and turning it off causes the power consumption to fall dramatically.

The script I am showing above handles internet connectivity in a very simple way, the Pico connects to a wireless network once at startup and keeps the connection up for the whole time it is powered, even when it is sleeping. This is pointless and wasteful.

And so I modified my script to turn off Wi-Fi when sleeping, and power it on again only when sending data via MQTT.

import json
import time

import bme280
import machine
import network
from umqtt.simple import MQTTClient

sdaPIN = machine.Pin(0)
sclPIN = machine.Pin(1)

i2c = machine.I2C(0, sda=sdaPIN, scl=sclPIN)
bme = bme280.BME280(i2c=i2c)

led = machine.Pin("LED", machine.Pin.OUT)

ssid = "SSID"
password = "PASSWORD"

while True:
    wlan = network.WLAN(network.STA_IF)
    wlan.active(True)
    wlan.connect(ssid, password)
    max_wait = 10
    while max_wait > 0:
        if wlan.isconnected():
            break
        max_wait -= 1
        time.sleep(1)

    if not wlan.isconnected():
        machine.reset()

    led.on()
    time.sleep(0.2)
    led.off()
    data = bme.read_compensated_data()
    payload = {
        "temperature": data[0] / 100,
        "pressure": data[1] / 256 / 100,
        "humidity": data[2] / 1024,
    }

    qt = MQTTClient("umqtt_client", "MQTT_BROKER_IP", keepalive=1)
    qt.connect(clean_session=True)
    qt.publish(b"weather", json.dumps(payload))
    qt.disconnect()
    wlan.active(False)
    wlan.deinit()
    time.sleep(60)

The difference between this version and the previous one is that I moved connecting to WiFi to inside of the eternal loop. Every iteration begins with the Pico connecting to WiFi. Then we do the measuring, sending data via MQTT, and once the data is sent, the Pico disconnects from the MQTT broker, disables the WiFi module, and the goes to sleep. After 60 seconds, the Pico wakes up, powers on the WiFi module, connects to the wireless network, etc, etc.

Running this script with the power monitor attached showed that the power consumption is at 40-50mA only for the second or two that it takes the Pico to connect to Wi-Fi and transmit data. During sleep the power consumption falls to levels below what the UNI-T monitor can show, so less than 10mA.

My power monitor is also capable to measure power consumption over time and provide the result in milliampere-hours. I performed tests over two and 12 hours, and they confirmed the massive difference betwen Wi-Fi adapter being on all the time, and being on only for transmitting.

With Wi-Fi on all the time, the average power consumption was ~45mAh per hour. With turning Wi-Fi off when sleeping, the Pico W used ~6mAh per hour. 7 times smaller!

6mAh is a much better result, it is now much simpler to power the Pico W with solar panels, even the small ones.

Issues with MQTT

However, a new problem arose. With the Pico's continous establishing and ending connection with Wi-Fi and the MQTT broker, there is a now much higher risk of something going wrong at every loop. And the MQTT library that I am using is not handling connection errors well. During testing I've seen many times that after an hour or two the Pico would just freeze with Wi-Fi on, not sending anything to the broker.

After careful debugging (adding a ton of logging to a file) the culprit was found. Sometimes the MQTT connect() method would stop, and there was no timeout implemented by the library. Any issue with connecting to the MQTT broker would just freeze the Pico, and that would be the end, until it was rebooted manually. Not the best behavior for something that is meant to run independently for a prolonged period of time.

As the MQTT library I am using micropython-umqtt.simple. I installed it using Thonny's package manager. Thonny also allows to easily edit the files of the installed libraries, they can be found on the Pico in the lib/ subfolder.

After going through the documentation of Micropython's socket module, the module that the MQTT library is using underneath, I found that it does support handling timeouts. And so I added a timeout of 10 seconds, and modified the library's file to reboot the Pi when the connection cannot be established within a given time. A crude solution but it works. Below I am providing the code for the updated connect() method.

def connect(self, clean_session=True):
	self.sock = socket.socket()
	self.sock.settimeout(10.0)
	addr = socket.getaddrinfo(self.server, self.port)[0][-1]
	try:
		self.sock.connect(addr)
	except OSError as e:
		log(f"connecting timeouted with error {e}")
		machine.reset()
	except Exception as e:
		log(f"something totally broke! {e}")
		machine.reset()

The rest of the connect() stayed the same. Also at the top of the file I added a simple error logger to have a persistent log of errors that I can check later.

def log(txt):
    with open("error_log", "a") as logfile:
        logfile.write(str(txt))
        logfile.write("\n")

This change has solved my issues with the Pi freezing. If you have a better solution, I will be very happy to hear your feedback!

Solar panels - attempt #2

Now that the power consumption issue is resolved, it's time to go back to solving the power generation and management. The main difference between this and the previous build, is that I used much larger and better solar panels.

I bought two "3.5W 6V" solar panels from a Polish electronics shop. As the previous ones, they do not have a manufacturer label, but the overall build quality feels much better. I connected them in parallel using the additional connectors at the back and some 22AWG cables I bought previously. I also added a backplane from some sort of a plumbing bracket I found at a local hardware store. The bracket has a lot of holes for different connectors, I used the middle one to add an M5 screw. The bracket was then hot-glued to the back of the panels. The whole assembly is sturdy and universal enough to be mounted anywhere.

Solar panels assembly

Theoretically those two panels running in parallel should provide more than an 1 Amp of current (7W at 6V), but the best I got was around 300mA in full sunlight. Not great, but enough to both power the Pico and recharge the batteries after a night.

I reused the solar power manager from the previous iteration, it's still the Solar Power Manager 5V v1.1 from DFRobot. It's small and just works.

The battery storage is the same as in the Portable Meshtastic Node project I did a few weeks ago. Please consult that blog post for detailed instructions. It consists of three 18650 batteries connected in parallel. Together they provide around 7500mAh. I used a JST-PH 2.54mm connector to connect it to the solar power manager.

And that's the full parts' list. I connected the solar panels to the Solar In connector (I wish there was another JST socket for them), the batteries to the Battery In socket, and the Pico W using the 5V and ground pins. Nothing groundbreaking here.

Everything connected, placed in my not-that-clean balcony

Close-up on the Pico with the BME280 environment sensor

Current situation

I am still testing the performance of the new build, and so far I am impressed. I started the test with the batteries fully charged using a standalone charger and during the first day, the solar panels have been able to keep the full charge continuously. In the morning the batteries were depleted a bit, but the panels were able to recharge them in a few hours. Despite the fact that the whole day was cloudy and the panels are sitting on a windowsill pointing towards the West. I am sure that installed outside and pointed South, the batteries would get recharged way before noon.

Update: After 10 days of running, the battery voltage was around 4.10V at their lowest level, and they are recharging to full charge every day.

I am convinced that with the current setup, the Pi Pico W can run indefinitely, or well, at least until late Autumn, when the days will be much shorter. But we'll measure that bridge when we get there.

The only missing step is a case, I need to work out something that will protect the Pico and the batteries, but at the same time provide free airflow for the sensor suite.

And that's it! I am very happy with the outcome of this project. I have been talking only about the Pi Pico W here, but the lessons learned are universal, and can be applied to any device running from 5V or similar voltage. The next step for me will be to apply them to an off-grid node of Meshtastic. This project is already underway, and soon will be described here in detail.

Previous parts of my journey making a weather station with a Raspberry Pi Pico:

Raspberry Pi Pico Weather Station - part I

Raspberry Pi Pico Weather Station - part II

Powering Raspberry Pi Pico with AA batteries (Weather Station Part III)

Powering a Raspberry Pi Pico with solar panels and an 18650

Some interesting discussions that I found on the topic of Pico power consumption, that have been a great source of knowledge and inspiration when working on this project:

Reddit: Power reduction on pico w? - how to do?

PICO W - lightsleep not working after cyw43_deinit #10889

PICO W lightsleep doesn't work when using rshell #12573

Join my Matrix Space! And some other random news

STFN — Fri, 17 May 2024 24:00:00 GMT

Just a few short updates today:

Matrix Space

I created a Matrix space for everyone who would like to discuss interesting topics like programming, SBCs, hamradio, BOINC, permaculture and all that in between, and I would like to invite who is reading my blog to join!

If you don't know Matrix, it's like Discord, but open and decentralized, like the Fediverse.

(Invitation Link)

Once you register with Matrix and join my Space (hehe, mySpace), you'll need to join a room, there should be a list of rooms available somewhere in the UI.

Blog updates

My latest post (Reducing Raspberry Pi Pico W power consumption and a second attempt at using solar panels) was mentioned in an article at hackster.io: Some Smart Thinking About Always-On Wi-Fi Gets a Raspberry Pi Pico W Weather Station Sipping Solar, and in a CircuitPython Newsletter, even though I am not using CircuitPython at all.

Those mentions caused the largest spike in visitor numbers since the beginning of this blog, but my super basic techstack - NGINX serving static files - had no problems. Yay for simplicity!

Ashley Cawley left a very interesting comment under my How to monitor 12V battery charge with a Raspberry Pi Pico post, which turned into a thread on the Raspberry Pi Forums It turns out that different version of the MicroPython firmware work differently with analogue inputs on the Pico, and the code I presented in that blog post has issues with running with the newest version of MP.

Ashley, I am so sorry, I promised to take a look at it this week, but I totally did not have the time to do so, I will get back to you!

I now have three (3!) Meshtastic nodes, one of them running on solar panels, and soon I will present them here.

I am also in the process of moving my homelab from a Thinkpad X220 to a proper "server" desktop PC made from different old parts.

There are so many things I want to write about, if only I had more time.

Thanks for reading, you are the best people <3

Making my own private Strava

STFN — Tue, 21 May 2024 24:00:00 GMT

Go straight to the main part and skip my personal musings and all that boring stuff.

I bought a new bike

I used to bike a lot. Starting with the smallest bike with additional wheels for stability, I remember the big moment that was removing those supports, and riding for the first time without them, as the grownups did.

Then it was the staple of every child growing up in Poland in the 90s: the First Communion bicycle. It was an MTB, with horn-style handlebars, 3x6 gearing, 26" inch and crude steel (I guess?) frame. In line with another ancient Polish tradition, it was in adult size to "serve you longer as you grow". For the first few years I had trouble getting on and from it, because it was much too large for me, and that would often end in scraped knees.

With even bad traditions having a grain of truth in them, it served me well into high school. And then I went to a big city to go to the University. The bike was left in my hometown, and some years later my dad threw it away. I still kinda miss it. And I don't have any photos of it.

For the first few years in the big city I did not cycle at all, but that changed when my grandpa decided he is too old to cycle, and gave me his MTB. I was lucky enough to live at that time in a place that had a dedicated communal bike and trolley room, so I could store it. It was also at that time that I started working, so I used my bike to commute to work, which turned out to be much faster than by public transport.

The only photo of my second MTB that I have, I got a flat tire that day and came back home by tram

And I got hooked into biking on a totally new level. I gave that MTB to my sister and bought myself a very old road bike which I renovated and converted into a city single speed. I later turned it into a fixie bike, and replaced so many parts it became a Theseus' bike.

My fixie, probably fourth or fifth iteration. That was a fun thing to ride and to build. At some point I was even making my own wheels.

Finally I bought a proper road bike, it was an awesome retro bicycle, with a mix of Shimano and Campagnolo road components, which I later switch to all Shimano. The brakes and axles were Dura-Ace. If you know, you know. I rode it a lot around Poznań, took it to the mountains. My record was 95km in a day.

Somewhere in the Sudety mountains.

Then the pandemic came, and I moved from Poznań to a small nearby town. And the biking died out. I wasn't commuting to work anymore, the roads around weren't that good, and I lost heart in riding in traffic.

Since 2021 until March of this year I did maybe 50km altogether. Yet, to paraphrase Bloc Party, "At 36 I have decided something must change". I sold my single speed - fixie - again single speed of Theseus, I sold my road bike, and bought an MTB.

It's a Goetze* Define PRO with 29" tires, 2x10 Shimano drivetrain and hydraulic disk brakes. And it's a life changer.

My new MTB in it's natural habitat.

I now live next to a large forest, and not being confined to asphalt roads changes everything. There are hundreds of kilometers of sand and gravel roads around me, and I can travel them all. I can go to a lake, I can go to my homestead*, I can ride and ride and not see any cars for hours.

Popey recently wrote about regaining the Joy of Code. I have regained the Joy of Biking :3

So far I did around 300km with my new bike, and switching from a road bike required some adjusting. Mostly mental, I had to stop being afraid of going into loose gravel or sand, and gain the courage that I am able to ride over most terrains, even small brooks. And the disk brakes are awesome, totally different and much better than the road bike traditional brakes. One other I had to get used is that I have a working suspension, and the bike bending under you is actually a good thing.

So that is my biking story in a nutshell, now let's talk about the software.

Setting up my private activity logger

My first activity logger was a basic "bike computer" attached to the handlebars, showing data like current speed and total distance. Then came the era of smartphones, and already on my first one, a HTC Wildfire S, I installed an activity tracking app. Somehow I never used Endomondo. At first I was using Runkeeper, and later on switched to Strava.

Open Tracks

Today, with the growing enshittifaction of Internet services, and my current preference for private, FOSS solutios, I started looking for something of the latter kind. I asked a question on Mastodon what do people prefer, and from their suggestions (thank you so much!) I chose OpenTracks.

It can be installed on an Android phone using F-droid. One more reason I am happy with my recent switch from iOS to Android.

Open Tracks allows tracking your activities with GPS, and saving them locally on your phone. No cloud services, no ads, no subscriptions. It just works. And can also show summarized stats, total distance, average speed etc.

Exporting data

The activities are only saved locally on my phone. OpenTracks allows for automatic exporting them to a particular location in the phone's storage. I have enabled that to store the tracks on my phone's microSD card (yes, my Fairphone 4 has a microSD slot, and it's still a great idea). I also configured Open Tracks to export files as *.gpx, more on that later.

The next step is to move the data from the phone.

Also with the use of F-droid, I installed Termux, which is a terminal emulator for Android phones.

In Termux I wrote a oneliner bash script that uses rsync to copy the files from the phone to my NAS.

My script to backup activities from my home to my NAS. I also use it to backup photos.

And this part is done, I now have a quick and simple way to export tracks to my NAS, which gives the additional advantage of having them backed up in more than one place. From time to time I open Termux on my phone and run the bash script to export new files.

Presenting data

I now have the GPX files on my NAS. The next step is to visualize them on a map.

For that I use GPSPrune, a free piece of software that can be simply installed with apt on my Debian 12 machines.

At first I exported the files in the default KMZ format, but GPSPrune had problems opening them, so I switched to GPX, and it worked.

What is especially cool about it is that I can open multiple activity files at once, which will generate a sort of a heat map of my rides. Something, if I remember correctly, is only available in Strava premium subscription :)

Screenshot from GPSPrune tutorial video

Bottom Text

And that's it. With the use of free and open software I am able to have my own activity tracker allowing me to review and visualize my rides. And all that without sharing my private data with some corporate cloud vaporware.

I admit that using Open Tracks, Termux, Bash, Rsync and then GPSPrune is a bit unwieldy and requires some technical skills, but in my personal case, the pros outweigh the cons by a lot. What do you think?

Thanks for reading!

* I'm sure you Internet people of 2000's will smile now :)

* I still haven't decided how to call that piece of land that I have. A garden? A homestead? A future house location? Not sure.

I got married!

STFN — Thu, 20 Jun 2024 24:00:00 GMT

I haven't written anything here for almost a month, but that happened for a very important reason: I got married!

Alicja is the greatest girl, and now I can call her my wife, how cool is that?!

The place was very rustic

First day of wearing the wedding ring

State of my homelab/NAS in June 2024

STFN — Sun, 23 Jun 2024 24:00:00 GMT

Almost a year has passed since I last wrote about the the state of my homelab. Basically every component of it has been replaced since that time, and so I decided to write a new episode.

As in the previous iteration, I have a combined server and NAS for my homelab. The more proper way would be to divide it into separate units, but due to space, power and budget constrains, I'm running a single box to both host my services and store data.

And this iteration is quite a revolution, I finally went with a "desktop" PC, with proper storage and low-power, but reasonable specs.

Hardware

Tha hardware used for this build is mostly stuff I already had lying around, coming from my old "gaming" desktop, or from Alicja's (my wife <3) Netflix box. She used to have a small mATX PC connected to a TV, but a month ago I found a good deal for a Fujitsu USFF desktop computer, gave it to her, and reacquired her PC for parts for my NAS.

Actually, the only parts I bought specifically for the homelab were the hard drives.

The inside of my new homelab server

The case is a Cooler Master Elite back from 2014 which was the basis for my first very own desktop PC. It's age is visible in the fact that it has three 5.25" trays (who uses 5.25" trays anymore?!), and there are no means for cable management. But for my needs it's great, it can store a lot of hard drives, and the airflow is good. It even still has the DVD drive/burner that was useful a decade ago. I would remove it, but I don't have the replacement mesh cover for the front, so the DVD drive works as a high-tech plug for the front of the case. How the times have changed.

The motherboard is a Gigabyte GA-Z97P-D3. Not much to say about it. It has a 1150 socket, six SATA ports and four RAM slots. Typical of the time. The webpage for it says that it supports NVME drives via PCIe, something I might investigate in the future. If the system could boot from an NVME drive in a PCIe slot, then I could use the whole six SATA ports for storage.

The CPU is more interesting than the motherboard. It is an i3-4170T with two cores, four threads. The T in the name denotes that it is a low power variant, with only 35W of TDP. From what I've seen so far, it is absolutely fast enough for the tasks I throw at it.

The CPU cooler is a SilentiumPC Spartan 5 120mm, an overkill for the 35W TDP CPU, but that allows it to run at the lowest possible speed, making the build almost silent.

The RAM is just some 32GB in four sticks of 8GB, 1600MT/s. It works. It's not ECC. Maybe one day I will move to a system with ECC RAM?

The PSU is a Seasonic 500W low tier model. It has only Bronze rating, I'm using it as it is also a hand-me-down from a previous build. If I were to buy a power supply specifically for a homelab, I would go with a Gold or Platinum rating.

For cooling the drives, there is a BeQuiet! 120mm fan in the front. Also set to run in silent mode. All in all, I have no problems living and sleeping in the same room as the box, the fan hum drowns out in the background noise.

Finally there is the PCIE Wi-Fi card, because again, due to space constrains in the vicinity of the router, the NAS needs to use wireless to connect to the rest of the network. Not perfect but here we are.

Drives

The drives are a mix of ones bought specifically for it to be a NAS, and ones taken from the previous iteration of my homelab.

The drives. There's still room for more.

The boot drive is a 500GB SSD from my previous homelab.

The main storage is a pair of 4TB HDDs, one WD Pro, and one Seagate Ironwolf. Both are CMR, 5600rpm

The secondary, "fast" storage is a pair of 2.5", 1TB SSDs.

And there is also a single 500GB SSD just because I had nothing to do with it. Currently it serves as a place to store random, temporary files.

Six drives in total, populating all of the available SATA ports. If one day I need more ports, I will probably buy a PCIe expansion card for either NVME or SATA drives.

The case had no place for 2.5" drives, another sign of it's age, so the four SSDs live in this shiny 3.5" -> 2.5" adapter cage.

The yellow and red spaghetti in the middle is there because the PSU did not have enough SATA power ports, and I had to buy MOLEX to SATA power converters. They are not pretty but they work.

Storage configuration

All drives, apart from the boot one, use ZFS. For the boot drive I stayed with ext4, to save myself the hassle of setting up ZFS-on-boot in Debian.

The two HDDs run in a ZFS mirror, the same as the two 1TB SSDs. The remaining 500GB SSD is a ZFS single.

The pools are shared over the network using NFS configured straight in ZFS.

One thing that surprised me is that I cannot see detailed statistics of how full the drivers are, neither via Prometheus nor Telegraf. This is possible, but only under FreeBSD. For reasons I don't exactly understand, Linux does not have such powers.

And from the few weeks that I have been using my NAS, I can see that what they say that "ZFS likes RAM" is true. Any larger copying operation results in most of those 32GB of RAM being occupied.

Software

As the box is not only a NAS, but also a homelab, it runs several self-hosted services.

The operating system is Debian 12 Bookworm. I think you can already see that the name of this build is simplicity and "just-workism" and Debian fits into this philosophy perfectly.

The systems run a mix of ways, most of them are Docker containers, but some are systemd daemons. I don't know and don't care much about the systemd drama in the Linux world, for me it's an awesome tool, and I've been liking it even more once I learnt how to daemonize stuff myself.

The dashboard

Homepage

For the dashboard of my homelab, I am running homepage. I switched to it from Dashy because the editing workflow for Dashy was for me janky at best. Homepage is edited by writing YAML files, which I found much cleaner and simpler.

Metube

Metube is a Youtube downloading service. I'm surprised it's still running with all those YT wars with ad blockers and the like. I try to download as much stuff from YT as possible before they lock it down even further. Great for getting music and tutorials.

FreshRSS

FreshRSS is a self-hosted RSS reader with a clean UI.

Navidrome

Navidrome is a music player. I still have some mp3s that I bought on Basecamp.

PhotoPrism

One of my newest discoveries, PhotoPrism is a self-hosted photo management app, similar in UI to iPhotos on the IOS cloud. A cool feature is that it can do object detection on the photos, and tag and sort them based on what it finds. One day I will write a longer blog post on it.

Podgrab

Podgrab is an app to automatically download new podcast episodes as they appear. Actually, I use this app only for preservation (a.k.a hoarding) of podcasts, I listen to them only on my phone using AntennaPod.

Grafana, InfluxDB, Prometheus

My monitoring solution is based on Prometheus and Node Exporter collecting metrics, InfluxDB digesting them, and Grafana as the presentation layer. Also a topic for a future blog post.

Cockpit

Cockpit is a web interface for server management, allows reviewing and modyfying settings, updating software, reading logs, all that sysadmin stuff.

PiHole

Who said PiHole can only be installed on a Pi? I'm sure most homelabbers use it, it's a DNS based adblocker.

FlatNotes

FlatNotes - a super simple app for making notes. I use it to make drafts of new blog posts. The notes are saved as markup file straight on the disk, allowing for easy backup

IT Tools

A set of tools in a single Docker container useful for any software developer. I use them all the time, mostly for formatting JSON files, generating UUIDs, all those small things that have to be done.

Forgejo

Forgejo is a self-hosted git repository manager, a great alternative to GitHub. It also supports actions similar to GitHub Actions. I use it to store my blog repo, and publish it live on every merge to main. Forgejo I am running as a systemd service.

Hoarder

Hoarder is a new app, still under development. It's a bookmark manager with a nice trick up its sleeve: It can use AI to tag newly added bookmarks. There will soon be a whole separate blog post on this.

Bottom Text

Having a homelab is an iterative journey. My first homelab was a single Raspberry Pi Zero running PiHole. I then moved to a pair of Pi 4s, then an old Thinkpad, and now I arrived at having a "desktop" box with redundant storage and a lot of RAM. I'm happy where I am now, and I learnt a ton along the way.

Cosplaying as a sysadmin ((c) Jeff Geerling) gives you a wide set of skills, and, at least for me, I am using some of them in my day work. For example, without a homelab I would not have learnt so much about Docker, something that I use everyday for my job, and I can put on my resume.

One thing I need to take a closer look at is power consumption. I don't have a wall meter yet, so I don't know how much power the box is drawing. Something that I will tackle in the near future and report my findings.

I already have a plan how to enhance my homelab, so stay tuned! And you can stay tuned by subscribing to my RSS feed. Please do not "smash the like button" as I don't have one.

Thanks for reading!

I reached 150 million points in BOINC

STFN — Thu, 27 Jun 2024 24:00:00 GMT

I started BOINCing somewhere in April of 2021. It took me two years and four months to reach 100 million points. In August of 2023 I wrote a blog post about this milestone. Today, less than a year later, I reached 150 million points, and it's time to write an update.

Of course those are only imaginary Internet swag points, but on the other hand they do show the real life resources, electricity and hardware, that I put into BOINC.

Since the last update I have been mostly crunching Einstein@Home and Asteroids@Home, with some Universe@Home and Milkyway@Home. I reached 87 million points in Einstein, mostly thanks to the new GPU based O3AS application that is very "generous" when it comes to points. In Milkyway@Home I reached 10 million points, mostly to get to a nice round number. In Asteroids I passed 4 million points, and in Universe I'm at 50 million, and it looks like that I will stay at this level for a long time.

I've been mostly crunching on my desktop, with a Ryzen 3700X and an RTX2060 GPU. I also used my new Raspberry Pi 5 to do some crunching, and I wrote a series of blog posts, comparing it with the Pi 4b:

Einstein@Home

Asteroids@Home

Universe@Home

In the recent months I mostly moved my crunching to a Hetzner Server Auction box. I find them to have the best price to performance ratio when it comes to rentable servers, and crunching tasks on a 32 thread Ryzen 5950X was a joy to observe. I did it so as not share the electricity costs with my wife, and also reduce the noise and heat in our home.

So, that's about me, but how does the general BOINC situation look today? Bleak.

The BOINC ecosystem does look like it is sunsetting, with no new projects on the horizon, and existing ones having issues and scaling down, with one notable exception.

Gaia@Home seems to be permanently down and I don't have any hope for it anymore.

Universe@Home has sadly lost their main scientist, and they have been inactive since January. There were talks about reactivating it in April or May, but now it's late June, and nothing happened.

Milkyway@Home has finished their GPU application, and now provides only one CPU app.

World Community Grid just cannot get their stuff together after all those years after being acquired. Most of their apps have tasks very rarely or not at all. At least their website doesn't break twice a day as it used to.

Asteroids@Home seems ok, they have had a steady run for the last months, with a good stream of jobs to crunch, and even development work to make them more efficient and use modern CPU features.

And Einstein@Home, the jewel in the BOINC crown, a project that has a steady flow of new jobs to crunch, new projects being developed, and the best, most responsive staff I've ever seen in a BOINC project.

As I said again and again, I think BOINC is a great project that could bring a lot of added value to the world, but it's underfunded and understaffed. The current situation is just so sad, watching the BOINC ecosystem curl and shrink. Seeing a new BOINC project appearing would be the coolest thing.

That’s all for today, see you at 200 million points for a new update.

How to set up Umami.is, a self-hosted analytics service

STFN — Thu, 04 Jul 2024 24:00:00 GMT

March 2026: In December of 2025 my VPS got hacked, and the reason was a vulnerability in the Umami container: I got hacked, and that has uncovered all the things I've been doing wrong

Disclamer

I know that this article will be about touchy subjects, so let's start with the important stuff:

Yes, my blog is collecting data about its visitors, meaning You.
It is only the most basic stuff, like country, browser, OS, and the referrer.
I am not collecting any personally identifiable information, there are no cookies and no local storage used.
I'm doing it only because I like looking at numbers and I'm curious where do people find my blog
I am not selling or passing that data to anyone. And now, with a self-hosted solution, it will never leave my server.

With that out of the way, let's continue.

Umami dashboard

Why move to self-hosted analytics

Since this blog started at the end of 2022, I have been using GoatCounter as my source of analytics.

It's free, clean, and simple to use. GC offers a free hosted service, so getting started is only a matter of setting up an account and adding a small piece of HTML to your website. I still highly recommend it for anyone wanting to have a turn-key solution for their website. And they are donations based, you can help them here.

The main issue I was having with GoatCounter was that every adblocker was cutting them out, as the JS script used for counting visits was calling a well-known, external service. I could clearly see in the nginx logs that I was getting much more traffic than GC recorded.

On the other hand, a self-hosted analytics service is hosted, and communicates only with your own server, and adblockers have no reason to block it unless specifically provided with the server's domain.

And also, you know how it is with homelabbing and self-hosting, from time to time you want to check out different tools :) I could have switched to a self-hosted GC instance, but I wanted some change, and so I tried out Umami, and so far I have been very happy with it.

So let me share with you how I installed and configured Umami.

Installation

As for the installation, I went the way I usually go with such services, using Docker Compose to run them in containers.

(all terminal snippets taken from Umami docs)

git clone https://github.com/umami-software/umami.git
docker-compose up -d

This will get you a database and a Umami worker available at port 3000. If you installed it in your VPS, you should be able to access it at http://<domain>:3000. It's possible you will need to add a custom rule to your firewall to allow access at that port. Don't worry, it's only temporary.

You can now visit Umami's dashboard and set up a secure admin password.

Do not add a website yet! First we need to set up a proper way of accessing Umami on the server, and for that we need to have a subdomain and configure it in nginx.

Using a subdomain

Accessing Umami over a non-standard port and without HTTPS is by far not a good solution. What I did is I set up a subdomain with my domain provider and configured it in nginx.

To set up a subdomain I opened the admin dashboard at the company's website where I have all my domains, went to my main domain stfn.pl, an added a subdomain umami.stfn.pl. I pointed that subdomain to the same IP address as the main domain. It will be nginx's responsibility to sort out the traffic.

Nginx reverse proxy config

I am using nginx as my HTTP server. Adhering to best practices, I have created a separate configuration file at /etc/nginx/conf.d/umami.conf. I am using nginx's functionality of "reverse proxy", in which it is passing request coming to a specific domain, towards a service running in the backend, and passing them from the standard HTTP port 80 to a different one, used by the backend service.

The configuration is rather straightforward. server_name is the domain which this config file is monitoring. proxy_pass defines where the requests should be passed.

The different proxy_set_header stanzas define which headers should be carried on to the backend. I added them, as without them the country information would not reach Umami. The issue is described in this GitHub issue.

server {
    server_name umami.stfn.pl;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host  $host;
    }

}

Once you have the config file saved, it's good practice to first test the new config using

sudo nginx -t

Nginx will tell you if there are any problems with the configuration file. If all is fine, what is left is to restart nginx

sudo systemctl restart nginx.service

Now Umami should be available at the subdomain you defined. Remove the firewall rule for port 3000, it won't be needed anymore.

Next part is setting up HTTPS. For that I am using Certbot. Setting up Cerbot is very easy, everything is described on this single page.

Certbot will automatically updated your nginx config, adding all of the required stanzas. Once Certbot does its thing, you will be only able to access your new subdomain with HTTPS.

Configure Umami for data collection

Configuring Umami for data collection is described here and here in the docs.

Once you go through those steps, you should start seeing traffic on your Umami dashboard. But there is one issue, anytime you access your website, it will be also counted, and will skew the results. But there are ways to mitigate this issue.

Disabling Umami for dev work and local machines

For my blog I am using Astro.js, which is based on React. React allows to differentiate between the development and production states using environmental variables. To disable Umami collecting data when I am developing my blog, I modified the tracking code:

<head>
	{
		import.meta.env.MODE == "production" && (
			<script
				defer
				src="link"
				data-website-id="xxx"
			/>
		)
	}
</head>

This way the script will only render when the site is exported using yarn build.

To disable counting my visits to my blog, I used the solution described in this Github Issue. Adding an env variable in your browser's local storage will stop Umami from collecting data on a given webpage. To do so, run the code below in your browser's console in the dev tools, when your site is opened:

localStorage.setItem('umami.disabled', 1)

Bottom text

And that's it! I am happy to switch to a self-hosted analytics. I feel that I am more in control of what and how is being gathered, I can access the raw data in the database container, and I am not on the mercy of any external service.

There are of course downsides of self hosting stuff. One is that there is a visible increase in the server's load, as it needs to run the required docker containers. If you are using a very, very low-end machine for your website, that might become an issue, especially during traffic spikes. Another issue is that you are storing the data, and you are responsible for backups. Which of course can be seen either as a problem, or as an opportunity to practice backups and backup restoration. Depends on your viewpoint :)

Thanks for reading!

I passed the AWS Certified Cloud Practitioner certification

STFN — Wed, 17 Jul 2024 24:00:00 GMT

Yesterday I passed the AWS Certified Cloud Practitioner exam, and therefore I am a certified Practitioner of the Cloud of AWS.

This is my first AWS certificate, and I have been planning to obtain it for the last few years. The final push that convinced me to do it was that my employer offered to reimburse it. It's always nice to save a hundred dollars :)

Why did I do it? I'm a software developer with leanings towards the DevOps side, and I think that preparing for this certificate provides a good basis for going deeper in the future and learning the tools that will open for me the doors towards becoming a full-time DevOps. And I have this growing feeling that in the current market situation, being "just" a Python developer is just enough, and it is more and more expected of people to be more full-stacky. And I prefer to expand towards the DevOps side, not towards Frontend.

The syllabus for this certificate is a very wide bird-eye view of the whole ecosystem of AWS, from the basics like S3 and EC2, through databases, serverless, Infrastructure as Code, to more theoretical stuff like the Cloud Adoption Framework and adherence to local laws. There is also a lot about billing and managing users and companies in the cloud.

How I prepared for the exam

I started with going to the AWS training site. And I have to say, their training materials are a mess. There are so many sites and courses available there, and every site looks a bit different, every log in is several redirects, it's hard to find stuff you've already visited, it's just confusing.

Having conquered their site, I enrolled to the AWS Cloud Practitioner Essentials (Second Edition) course. The course itself was okayish, it has that corporate feel with a visibly calculated amount of cringe jokes. The content revolved about explaining how the AWS cloud works on the example of a coffee shop. It is visible that it's aimed at non-technical or semi-technical people. The whole course took me a around a week of afternoons to finish.

Having finished that course I did not feel like I was prepared to take the exam, so I looked for other options. What I chose was the ExamPro AWS Certified Cloud Practitioner course. I found it on Youtube first, and then came across many positive comments on Reddit, so I gave it a go and bought it for 29 dollars. Not cheap, but I decided I prefer to go this way. I don't mind learning from videos, and the example exams were a big help. I felt that it gave me much more information than the AWS course.

Finally, I went through the question set provided in this very useful GitHub repo: AWS Cloud Practitioner Study Notes (CLF-C02)

All in all it took me around two weeks of an hour or two a day to prepare for the exam. For me, the technical parts like EC2, lambdas, databases and S3 were relatively easy, harder to remember were the management and law parts. It's easy to learn what interests you, and hard to learn the boring stuff.

The exam itself was relatively straightforward. I went to a local training center governed by Pearson Vue, was greeted, registered, and was sat in front of a computer in an empty room. Answered the 65 single or multiple choice questions. After that there was a short survey how was the exam, and finally I got the score screen saying that I passed. I got an official confirmation via email a few hours later, and was informed that I received the score of 86%. 70% is the passing threshold.

What next?

I don't think I will stop here. Currently I am considering either going slow and steady and enrolling for the AWS Certified Developer exam, or going straight all in, and attempting to get the AWS Certified DevOps Engineer - Professional. I am sure both of them will look good on my CV and will help me in my daily job, but probably the second one will be a big boost in my possible transition to a more DevOps career. I still have some time to decide.

~~BTW: This blog uses AWS. While the webpage is hosted at another provider, I am using S3 with CloudFront to serve the images and that one video.~~

March 2026: that is no longer the case, I moved to Bunny CDN and wrote it about it here.

Thanks for reading!

How to set up subdomains in the homelab with PiHole and Caddy

STFN — Sat, 20 Jul 2024 24:00:00 GMT

I have a homelab in which I run several self-hosted services (more on it here). The services are deployed as Docker containers, and each of them exposes a different port. Up until now I have been using the port number to access them, for example homelab.local:3002 would lead me to Grafana. The landing page for the homelab is served by Homepage which is bound to port 80, the default port for HTTP. Thanks to that, I can just access homelab.local and use the links presented there to access the services without needing to remember their ports.

The dashboard

But this gets tiring quickly when you want to access the services directly. And well, for a moment my Homelab felt too complete and I wanted to check out some new configuration and tooling. I wanted to have subdomains, so that instead of going to homelab.local:3002 I could just visit grafana.homelab.local.

Here comes DNS

DNS is a tool that translates IP addresses into human-readable URLs. Thanks to DNS, you can ask your browser to access fosstodon.org and not a bunch of numbers making an IP address.

To make the subdomains work, we'll need two things: an HTTP server than can do reverse proxying, and a local DNS server. The DNS server will tell your computer how to reach the homelab, and the reverse proxy will distribute the incoming traffic between the different services. For the first part, we'll use Caddy, and for the second one there is something that a lot of homelabbers is using, but not directly for this feature: Pi-hole.

Caddy setup

Why Caddy you ask? I chose it because I've seen good reviews of it in several places, and most of all because I wanted to try a tool I have not used before. For this blog I am using nginx, so I looked for alternatives, and Caddy was high on the list of recommended software.

The installation instructions for Caddy can be found in the Caddy docs. In my homelab I am using Debian Bookworm, so I installed it by adding the Caddy repository to my software sources, and then installing it with apt.

This way after installation I have a systemd service which can run a daemon in the background.

Investigating the service file (/lib/systemd/system/caddy.service) shows that Caddy is storing its configuration in the Caddyfile at /etc/caddy/Caddyfile, and this is the file that we'll need to edit.

sudo nano /etc/caddy/Caddyfile

The Caddyfile will have a default configuration of serving static webpages. We won't need it, you can just remove it or comment it out. What we will need is a reverse proxy, so, all we need in the Caddyfile is the setup for the reverse proxy, anything else can be let at their defaults values.

A reverse proxy is a service that accepts requests from the client, and forwards them to another service living on the server. There can be several of those services running together on the server, and Caddy will distribute traffic between them based on the URL of the request.

Here is how my Caddyfile looks like:

http://homelab.local {
reverse_proxy :3001
}

http://photo.homelab.local {
reverse_proxy :2342
}

http://music.homelab.local {
reverse_proxy :4533
}

http://rss.homelab.local {
reverse_proxy :8090
}

http://jellyfin.homelab.local {
reverse_proxy :8096
}

This tells Caddy that if it receives a request from the client's browser to access the URL homelab.local, it needs to forward it to service running at port 3001, which is my Homepage instance. But if the client's browser requests the URL rss.homelab.local, it needs to forward it to the service running at port 8090, which in my case is FreshRSS.

After applying the changes, we need to restart the Caddy service

sudo systemctl restart caddy.service

This part is done, and now it is the time to move to the second part of the setup.

Pi-hole setup

I assume your client device, the one from which you will be connecting to the homelab, is already configured to use Pi-hole. If not, go through the post-installation steps.

Now our homelab knows how to distribute the requests coming to it based on the URL, but there is one big problem. Our client device, the one from which you are connecting to the homelab to get the RSS feeds or music, does not know that requesting rss.homelab.local or music.homelab.local must lead to the same computer, to the homelab. Remember, as we discussed in the beginning, the client uses a DNS server to be told which address means which computer.

The base url, homelab.local, should work out of the box due to local DNS resolution, (which is an ever more black box for me), but the subdomains will not work unless we specifically setup the DNS server to tell the clients that the subdomains are the same computer as the base one.

And here comes Pi-hole. Pi-hole adblocking functionality is based on DNS.

For example, when you visit a page, like onlinenewsthatmakeyouangry.com, the page tells your browser to also pull images from ads.onlinenewsthatmakeyouangry.com, and Pi-hole will see that those are ads, and will not return an IP address for them. The ads will not be fetched and you will not see them. That's Pi-hole in two sentences.

Pi-hole allows setting up custom DNS entries, and this what we will use to point the client to our homelab subdomains. Local DNS is the menu entry that we need. The screenshot shows how it should be configured. Remember to put the IP address of your homelab.

Most probably you will need to disconnect your client device and connect to your network again to make the changes work.

If everything was configured, the subdomains should now work. Try it out!

HTTP or HTTPS?

In the Caddyfile I provided the URLs starting with http://. One of the big features of Caddy is automatic configuration of HTTPS, so why am I using HTTP?

I do not expose my homelab to the Internet, and I do not have a public domain for it. For such domains Caddy creates a self-signed SSL certificate, which the browsers find suspicious and warn you before accessing pages with such "shady" certificates. Again, my homelab is not available from outside my network, so I don't care about HTTPS, and I don't want to see a warning every time I visit my local server, therefore I am telling Caddy specifically to only use HTTP.

If you have a homelab living in the wide open Internet and it has a public domain, then you can remove the http:// prefixes from the Caddyfile, and Caddy will generate a proper SSL certificate for your server.

And that's it, your homelab is now on a totally new level! Thanks for reading!

How I Learned to Stop Worrying and Love the Classic Watch

STFN — Sat, 10 Aug 2024 24:00:00 GMT

In January of 2019 I bought a smartwatch, a Garmin vívoactive 3. I bought it during a typical period of "getting fit after a breakup". And at the time it did wonders for me. I am a person who enjoys seeing numbers and graphs about my life, and having a daily statistic of steps and calories was a big motivation. It made me walk to work instead of taking the public transport. I recorded every run and every bike ride.

Garmin allows automatic syncing of recorded activities to Strava and of course I did that too. The best part of finishing every bike ride was checking out the list of new personal records I beat, and the leaderboard of the local segments. The smartwatch was an important part of my life, and I wore it every waking moment, sometimes even not taking it off for sleep.

That period ended rather abruptly with the pandemic and the first lockdown, and I remember at one point being angry that all my stats would go down because of staying at home. I know how bad that sounds.

The lockdown finished and I was back at pushing the number of steps. I rode my bike much less frequently because of reasons described in the Making my own private Strava blog post, but still, using the smartwatch was an important aspect.

And then... I lost it. I could not find it anywhere, I searched the whole flat, the garden, the car, even the basement but it was nowhere to be found. After some mental investigations I came to a conclusion that I must have put in some bag that I later emptied to a trash bin. I was bummed out, but also at that time I did not want to spend a lot of money on a new watch, as I had higher priority spendings on the horizon.

In the meantime I got interested in old 80s watches, and on a whim I bought a CASIO F-91W, a classic watch that tells the time and is so famous it has its own Wikipedia page.

A year has passed, I mostly forgot about my smartwatch, and then all of a sudden, in a classic trope of 50s family sitcoms and boomer memes (well, those are the same picture), my wife found my watch where I searched several times and missed it. It was somehow weirdly wedged under the seat of our car.

Rejoice! Again I started counting the steps and making sure I passed some arbitrary threshold each day. I recorded a bike ride with it, and checked out the detailed stats.

It lasted two weeks.

And I lost interest. I could not be bothered witch charging it every two days. And the watch face that I like does not have a battery indicator, so sometimes when I forgot to check it, it would die on my wrist. My mentality regarding privacy also changed and I was not happy with sharing my most personal data with some external servers, that have already at least once been attacked by ransomware.

Another aspect is my current preference to use private, open source software, and with that I would not be able to use Strava anymore. Going back again to my blog post about biking, where I describe my current bike ride logging solution.

And so I am back to my CASIO, which Just Works, tells the time, the date and even the day of the week, and the battery will last for the next decade. It does not have distracting notifications. It is waterproof and even if I manage to break it, buying a new one will not break me financially. I do not need anything else right now.

I think it's just another example of me being tired of too much technology.

And if I ever need to make an IED, I have the first part.

Thanks for reading!

Trying to use a terminal only laptop

STFN — Fri, 16 Aug 2024 24:00:00 GMT

I am writing these words in NeoVim, started from tmux, running in Debian Bookworm. The laptop is a Lenovo Thinkpad X240 with a Haswell-era CPU and 8GB of RAM. And I do not have any graphic environment, just a terminal. And at the same it's hard and great.

Why am I doing it? Mostly because I can, and I thought it would be a fun challenge to try and use the command line only. And it's also a very good learning experience, I already learned stuff that would not interest me if I had Gnome or KDE or Xfce to fallback on. I already had to learn how to copy and paste in vim.

My, so to say, techstack right now is tmux for terminal composition, and neovim as a text editor. The terminal client is bash, usually I use zsh, but for this laptop I want to see if I can achieve the same level of configuration with good ol' bash. Wi-Fi is configured using nmcli, and I can even send the occasional toot using toot the Mastodon client.

The best thing about using a terminal-only system is it's speed. Everything is instant. Opening a file in nvim? Instant. Waking up from sleep? Faster than opening the lid. The computer is as fast as fast you can type.

A quirk of this laptop is that there is no separate Insert key, to do Insert you need to do Fn + End, which is a bit irritating when using nvim.

One thing I am not yet able to investigate is the battery life difference. I have bought this laptop with very bad batteries (yes, plural, it has an internal and external one!) and I disposed of them when it was running as a homelab. I'm planning to buy a battery and see how it goes.

Overcoming Obstacles

The biggest problem with not having a graphical interface is browsing the Internet. Yes, there is Lynx, but modern webpages are mostly not designed to work in text-only mode. BTW: One interesting thing came out with using Lynx: It asks you everytime a webpage wants to save a cookie, and it is eye opening. Probably more people would stop using Google if they had to type "yes" 15 times before being able to do a query. Anyway, I will admit, I resorted to cheating and and mostly searched for stuff on my phone when using this laptop.

And now came another problem. If for example I wanted to download something I found on my phone, like a link to a deb package, how to do it? I could retype the link, but that would be cumbersome. So I went with a dirty-yet-working solution. I copy the link on my phone, save it to FlatNotes hosted on my homelab, scp the note to the laptop, copy the url and download it with curl. This is the stuff I do for fun.

What can you do without a DE?

Surprisingly, a lot. First and foremost, you can write. Even write more than usual, because there are less distractions. Developing software is also possible. With tmux the left side of the screen can be the code editor, again vim is perfect here, and the right side can be anything.

Right now my blog writing screen is tmux dividing the screen in three parts, top left is node dev server, bottom left is vim, and the right half is lynx showing the blog page at localhost. I wish lynx could automatically refresh the page on changes as Firefox, but you can't have everything.

Hmm, I would add a photo of it here, but my image preparation and upload pipeline is still rather complicated, so I'll just add the photo to the Mastodon toot announcing this post. I wonder if you can take screenshots from the terminal? Something to investigate.

Internet browsing is also possible, but as I mentioned above, not that easy. But you do save a lot of bandwidth by not downloading the assets. Posting to Mastodon? Sure. Browsing RSS? Also possible. Listening to music? Le oui, I've seen terminal music players. The CLI is the limit. That sentence would work much better if you prononuced CLI in a way that rhymed with "sky".

I'm thinking of taking this laptop with me on my next holiday. It will allow me to do some maintenance work, like backuping photos from the camera to my homelab, and at the same time will not tempt me to doomscroll and browse too much intertubes.

I think that's it for now. Once I spend more time in the land of no graphics, I may have more things to share.

Thanks for reading! Now to see how if I can control my Forgejo deployment pipeline from the terminal. This post feels to much more chaotic and less organized that usually, but that's ok for me, I want to experiment with writing more spontaneously.

How to archive YouTube

STFN — Mon, 26 Aug 2024 24:00:00 GMT

Nothing on the Internet can be considered permanent. Webpages disappear, songs get removed from Spotify¹, Amazon famously removed George Orwell's books from Kindles^[2]. Youtube videos also disappear either by copyright complains, of because their creators decide to remove them.

So what to do? Download anything you find important. In my homelab series³ I already mentioned Metube⁴, which allows downloading single videos or playlists. But now there's something else to download videos from Youtube.

A few days ago Patryk⁵ showed me Pinchflat⁶. Pinchflat is a "YouTube media manager". It allows for downloading whole channels or playlists, and what is more, it also keeps tracks of them, and automatically downloads new videos.

There's quite a few configuration options. You can set things like the desired video quality of downloads, add thresholds to the age of videos to be downloaded from a given channel, or how often should Pinchflat looks for new content. Everything is described in the GitHub repo.

Pinchflat can be installed using Docker, so very basic familiarity with that tool is required. After installation, it can be accessed through the browser. I also put it behind a reverse proxy with a custom subdomain for easier access. I wrote how to do it in my blog post about Caddy⁷

If you are going to install Pinchflat, make sure you have a lot of disk space in advance. I downloaded only a few channels in 1080p, and already 450GB of disk space is being used. But that's one of the reasons we have NASes, isn't it?

Pinchflat also allows browsing and watching videos, and provides useful metadata for the file. The metadata is stored on the disk together with the video files.

Pinchflat vs Metube

Am I going to ditch Metube after installing Pinchflat? No. I would say those two tools complement each other, and I will continue using both of them.

Pinchflat allows downloading whole channels and playlists, and keeping track of new videos, while Metube allows downloading single videos and playlists.
Pinchflat only supports downloading in a video format, Metube also supports downloading videos as mp3, something very useful when fetching music from YT.

And thanks it, short and sweet. Thanks for reading!

P.S. As you can see, in this post I am experimenting with footnotes. Do you prefer inline links or footnotes? Let me know on Mastodon or via email.

[1] Disappearing albums

[2] Amazon settles 1984 suit, sets limits on Kindle deletions

[3] My Homelab

[4] Metube on Github

[5] pgronkievitz @ wspanialy.eu

[6] Pinchflat on Github

[7] How to set up subdomains in the homelab with PiHole and Caddy

WireGuard and PiHole for secure ad blocking on your smartphone

STFN — Sat, 07 Sep 2024 24:00:00 GMT

Caveats

Let's start with some caveats. I am not an expert in VPNs, network configuration, nor network security. The solution that I am presenting is working for me, I am using it everyday, and so far it has caused me no problems. Then again, there is a real possibility I have made a glaring mistake or omission. I am hoping that someone much smarter than I am will read this post and point out any issues. If you are such a person, please contact me, you can catch me on Mastodon or via email, links in the footer.

Introduction

I write blog posts like this to report on something I implemented for myself to fill my specific needs, or to share something I learnt recently. This project covers both. I wanted to learn how to create and configure VPNs and other advanced network configuration, and also I wanted a way to block ads and trackers on my phone. It is possible that what I achieved here can be reached with simpler means, but I like overcomplicating things when learning, as it gives more knowledge on a wider set of tools.

The outcome of this project can be summarized as such:

I am now able to use PiHole to block ads and trackers on all of my devices, no matter to which network I am connected, be it my private LAN, a public WiFi, or even cellular network. This is achieved by running a VPS (Virtual Private Server) with PiHole, which is an advertisement blocking software.

PiHole blocks ads by working as a DNS server. In a very tl;dr description, a DNS server is a server that tells your computer how to find a way to certain places on the Internet. You want to go to Wikipedia, your computer asks a DNS server how to get there, and the DNS server replies "first left, then right, and twice straight ahead". Actually, the server replies with an IP address, but that's the general idea. When PiHole is being used a DNS server, it gives directions to proper content, but when your computer asks for directions to get something like advert.malware.com, it will say nothing, and the ad will not be fetched.

For security reasons, we are connecting to our new DNS server over a VPN (VIrtual Private Network), so that only our machines can connect to it and no one else.

Theoretically the VPN part can be omitted, but that is highly undesirable. A publicly available DNS servers can be used by malicious third parties in DDOS attacks. Please do not leave your DNS server unsecured.

This post is laid out in several steps

getting a VPS
setting up a WireGuard server on the VPS
setting up PiHole on the VPS
configuring a Linux computer to use WireGuard and PiHole. This step can be omitted if you only care about ad blocking on your phone, but I recommend at least reading through it to get a better understanding of the process.
configuring a smartphone to use WireGuard and PiHole.

Why just not use uBlock Origin?

But I am! My main browser on both my laptop and my phone is Firefox with uBlock Origin installed, but especially on the phone, the browser is not everything. Apps also connect to the Internet. Google Discover opens its links in Google Chrome which soon will not allow using uBlock Origin. Basically everything on your phone can send and receive traffic, traffic that is often advertisements or tracking. And PiHole will be able to block it all.

Getting a VPS

The first thing that you will need is a computer that can be reached from the Internet. One solution is to expose a device in your home network, but that is less safe, and not available for everyone, people who are, for example, behind a CGNAT do not have an easy means to expose their home devices to the public. So in this project, I am using a VPS (Virtual Private Server) from a cloud provider.

The provider of my choice is RackNerd. While less known than the large players like AWS or GCP, in my opinion they deliver a solid service and often have much cheaper prices for the low end boxes, which we will need for this project. BTW, I am using their server to host my blog. I learnt about them from Low End Box, which I also recommend to get good deals on cheap servers.

March 2026: I moved away from Racknerd and switched to Hetzner, because I no longer want to use US-based companies.

You can order any server, for our needs even the cheapest and smallest ones will work. As for the OS, I am using Debian on all of my servers, but most probably any other terminal Linux OS will be just fine. This tutorial assumes using an OS that has apt as the package manager and systemd for managing background processes.

Once you have a server running, it is basically required to do an initial configuration and hardening to secure it from external threats. Initial Server Setup with Ubuntu is a great article on how to do this initial config, I really suggest you go through it and implement each step. I know the title says "Ubuntu", but the things suggested there are universal.

Setting up WireGuard

Alright then. You have a server to which you can SSH safely, and which has a UFW firewall running. Now it's time to set up a VPN (Virtual Private Network). Having a VPN will give you a secure way of connecting to your server that no one else is able to replicate.

This part is largely based on the two following articles, with some parts advanced, unneeded parts omitted.

How to set up WireGuard on Ubuntu 20.04

Access Your Home Network From Anywhere with WireGuard VPN

In short, WireGuard is based on exchanging keys, the server and every client has a public and a private key which are used to authenticate the connection. Without knowing those keys, other computers will not be able to join the VPN. From a OS perspective, WireGuards creates a new network interface, usually named wg0, using which you connect to the server and other peers in the VPN network. Yes, VPN network, I also use LED diodes :)

Server configuration

The part below needs to be done on the VPS, which will become the WireGuard server.

Start with installing WireGuard

sudo apt install wireguard

Next, generate a private key:

wg genkey | sudo tee /etc/wireguard/private.key

Generate a public key from the private key:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Create the server config file:

sudo nano /etc/wireguard/wg0.conf

And paste the text below into the file:

[Interface]
PrivateKey = <server_private_key_goes_here>
Address = 10.8.0.1/24
ListenPort = 51820
SaveConfig = true

The server will have an IP address of 10.8.0.1, and the whole VPN network will be in the 10.8.XXX.XXX range.

Add rule to firewall to enable communication on WireGuard's port 51820.

sudo ufw allow 51820/udp

Enable and start the wireguard service

sudo systemctl enable wg-quick@wg0.service
sudo systemctl start wg-quick@wg0.service

The server configuration is almost done, time to move to the client. We'll start with configuring a Linux machine, if you want to have WG only on your phone, skip this part.

Linux Client configuration

As in the server part, install WireGuard and setup public and private keys:

sudo apt install wireguard
wg genkey | sudo tee /etc/wireguard/private.key
sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

The client config file looks a bit different, as it also needs information about the server.

sudo nano /etc/wireguard/wg0.conf

[Interface]
PrivateKey = <client_private_key>
Address = 10.8.0.2/24
 
[Peer]
PublicKey = <server_public_key>
AllowedIPs = 10.8.0.0/24
Endpoint = server_public_ip:51820

Fill in the private key of the client, the public key of the server, and its public IP address. Within the VPN network, the IP address of the server will be 10.8.0.1, and the client will be 10.8.0.2.

Connecting client to server

To connect the VPN client to a server, we need to inform the server of the client's key. Run this command on the server:

sudo wg set wg0 peer <client_public_key> allowed-ips 10.8.0.2

Finally, start the WG service on the client's machine:

sudo wg-quick up wg0

Now you should be able to SSH into the server from the client, using the server's VPN IP address:

ssh 10.8.0.1

For advanced usage, like tunnelling all traffic from the client through the server, consult the two articles I have linked above.

Setting up Pihole

The next step is setting up PiHole on the same server that has the WireGuard VPN server.

PiHole installation instructions can be found here. I would recommend installing Pihole as a service, and not using Docker. We will be hiding PiHole behind the UFW Firewall, and there is a known problem of UFW not blocking traffic to and from containers). It can be fixed, but the easiest solution here is just install PiHole not with Docker.

In the installation wizard one step is very important. There is a screen where PiHole asks you which interfaces should it use. By default it's all interfaces. Change it to wg0 only. It will be another means of defense against abuse of the DNS services on your server.

Finally, update the UFW rules to allow incoming traffic on port 53, but only through the wg0 interface:

ufw allow in on wg0 to any port 53

Making sure it all works

At this point we have WireGuard and PiHole running on our server, now it's time to make sure that we can use them. We will test by using our VPN client machine to ask the server to resolve a DNS query, tell us the IP address of the Wikipedia. The simplest way is to use the nslookup command. If you do not have it on your machine, install the dns-utils package using your package manager.

On the client machine run:

nslookup en.wikipedia.org 10.8.0.1

The response should be similar to

Server:         10.8.0.1
Address:        10.8.0.1#53

Non-authoritative answer:
en.wkipedia.org canonical name = ncredir-lb.wikimedia.org.
Name:   ncredir-lb.wikimedia.org
Address: 208.80.154.232
Name:   ncredir-lb.wikimedia.org
Address: 2620:0:861:ed1a::9

If you are getting an error, make sure WireGuard is running on both server and client, that PiHole is running, and if the firewall rules are correct.

And now run:

nslookup en.wikipedia.org <public ip of the server>

The connection should time out. This means that the server's DNS service cannot be used from the public Internet. This is exactly what we want. Good work!

Now we need to make the Linux machine use our new DNS server whenever it's doing DNS queries, so basically when you are browsing the Internet. The base two ways to do it is to set in the terminal, or in the network settings widget.

Here'show to do change it using the command line.

To change it using the Network Settings widget, open your network settings, edit the current connection, and set in the IPv4 tab, set the DNS servers field to 10.8.0.1. Disconnect and reconnect to the network. Done!

Smartphone configuration

And now, after that rather long introduction, it's time for the main topic of this post, setting up WireGuard and PiHole on the smartphone!

To use WireGuard on your smartphone, there is a WireGuard application available on the Play Store or the App Store. Install it and add a new interface using the plus sign and select "create from scratch".

Name is whatever you want, wg0 is fine. Generate the private and public keys. The addresses field will be the VPN IP address of your smartphone. It can be the next free IP address in the 10.8.0.XXX range (the same as the server). For me its 10.8.0.3. For the DNS servers field, set it to 10.8.0.1.

Now select "Add peer" at the bottom. The peer public key is the server public key. Endpoint is the server public IP address. Allowed IPs is the range of the IP addresses in our VPN, in our case 10.8.0.0/24.

Save the new interface and enable it. If you have Termux or Termius, you can test the new connection by SSHing into the server at 10.8.0.1, it should work now.

And again, using Termux, you can test if your phone can resolve DNS queries with our DNS server using the same nslookup command as in the previous section.

Because you have set 10.8.0.1 as the DNS server IP in the WireGuard app settings, your phone should now use PiHole everytime the WireGuard VPN is running on it!

The final step is letting the server know that the phone can be trusted.

sudo wg set wg0 peer <public_key_from_smartphone> allowed-ips 10.8.0.3

That's it! Your phone's web traffic is now filtered with PiHole, and it does not only apple to the web browser's traffic, but also to all of the applications that are on it. Using your phone will now be a much lighter and more private experience :)

It took us a while to get here, but I do believe the gains are worth the hassle. When logged in to the Pihole admin interface on the server you will see how much malicious traffic is blocked from your phone (mind, this link will only work if you went and applied all of the steps of this post). Here's an example of what PiHole blocks from my phone:

Thanks for reading! This was one of the longest and most complicated posts I've written so far. I hope it will be as useful to you as it is for me. Please, I'd love to hear any kind of feedback from you. You can write me an email, leave a comment below, or catch me on Mastodon. Links in the footer.

Thinking on storage

STFN — Sat, 21 Sep 2024 24:00:00 GMT

I just bought a 128GB Samsung SD Card for 39.99PLN (~9EUR), and that made me think about the progress that storage made since I started using computers.

I have this opinion that in the realm of IT, storage is where the progress is most palpable, most visible.

Of course with CPUs there has been also a massive progress, the first CPU I used, a 386, had clock speeds from 12.5Mhz to 40Mhz, depending on the version (thanks Wikipedia). The CPU in the laptop on which I am writing those words can boost up to 4Ghz, increase with a factor of 100. But visualizing that development is much harder, especially as its clouded in other factors, like improvements in IPC and going from single to multiple cores. Number go up good, but can you feel it?

For storage it's something different, especially if you are over 30 as I am, and remember how it used to be. And storage is about things you can see, or listen to, move from place to place.

This post has no particular reason or moral, I just want to talk how I remember and feel about storing stuff on my PC.

The first PC ever that I was using, that my dad brought home somewhere in the mid 90s, probably 1996? had no hard drive, as it was too expensive. I remember that to start the computer, you had to insert a yellow floppy from which it would boot to DOS, and then to play my fav game of that time, Mahjongg, you had to insert another diskette. For them youngsters, a single 3.5" floppy disk held 1.44MB of data. Megabytes.

Fast forward a few years, and a few iterations of the Family Computer in the Computer Room, my dad gave me a separate partition to store my games. It was 700MB. When I bought Diablo II I had to choose the "minimum install", as the full one would not fit.

In the middle of high school, ~2006, my dad bought himself a laptop and gave me our family computer, at that time it had a total 60GB of storage in two hard drives.

From a 1.44MB floppy to 60GB HDDs in ten years.

I took that PC with me to study at the University, and I filled it to the brim with MP3s (arrrr!) and RAW files from my DSLR. A MP3 was 5MB, and a single RAW file was 10MB.

Speaking of RAW files, it was at that time when I bought my first DSLR from money I earned from working in a hardware shop. I think I paid somewhere around 200PLN(~50EUR) for a 2GB SD Card.

And since then it went quickly, in 2009 I got a laptop with a 250GB 2.5" hard drive. In 2015 I bought and build from scratch my first very own desktop PC, with a 1TB HDD and a 250GB SSD. My next PC had a 4TB HDD and 1TB NVME SSD.

Finally, today my knees are being warmed by my NAS sitting under my desk. The NAS has in total six drives, 5 HDDs and a single boot SSD. In total, there's 13.5TB of raw space inside that box, with 8.5TB of it being usable, as some drives are mirrored.

In 28 years, from a floppy disk to a ZFS mirror. From 1.4MB to 13.5TB, 13500000MB, a factor of almost one million.

And again, this is something you can actually see. It's hard to spot or visualize in your head the difference between 3GHz and 4GHz CPUs, or 2600MT/s vs 3600MT/s RAM speeds, but for drives, it's there. If you still have MP3s, you can actually store thousands of times more of them on your drives, and that happened in less than a decade.

When I was having that laptop, I was taking a lot of photos, and eventually I run out of space on the 250GB HDD. So I started backuping them on DVD drives. At that time, 4.7GB felt like quite a lot for storing data. A few months ago, when I finally went through of all my DVDs and put them on my NAS, 4.7GB was just a blip, barely recognizable on a graph in Grafana.

I think this has been so far the most random, old-man-waves-at-clouds post in my blog. But hey, sometimes I feel like writing a detailed tutorial, and sometimes I just write all that random stuff that comes to my mind. Hope you like both of those.

I also caught the comet

STFN — Thu, 17 Oct 2024 24:00:00 GMT

Would you look at that, finally another post about taking photos of the night sky.

After seeing all those cool photos of the C/2023 A3 Tsuchinshan-ATLAS comet on Mastodon, I decided I need to join the craze and try to hunt it myself. At the first attempt I went to a nearby hill and tried to see it with binoculars, but to no success. So the next night I went all in, packed my DSLR, a 17-40 and a 50mm lens, a tripod, and drove to found a good spot.

I'm a big fan of wind turbines (pun kinda intended), so I came up with the idea that combining a comet with one of those would be cool. There's a wind farm (is that a name for a group of wind turbines?) not far from my place, so I went there, and even managed to find a place to park.

I got the best results with the 50mm f/1.8 lens. The camera is my old Canon 1200D, astromodified. The exposure time was 4 seconds at f/3.2, ISO 1600.

And here it is, with all its comet glory:

(click on the photo for a larger version)

I'm rather content how nice the tail turned out. With some slight curves manipulation I was able to pull it out of the surrounding sky.

And of course, if you zoom in, you will count at least three satellite streaks. The night sky is becoming a mess.

If you want to hunt for the comet yourself, I highly recommend Stellarium, both the desktop version and the mobile app. As for the desktop version, you will need to add the comet manually, there's a really good blog post on how to do it: [How to add a comet to Stellarium]9https://blog.martinbelan.com/2020/07/09/how-to-add-a-comet-to-stellarium/).

And there's also Heavens Above. HA is not only a great resource on everything happening in the sky, it's also a manifest on "if it works, don't change it". I don't think the webpage look changed in any way since I first saw it somewhere around 2005.

As for my astrophotography journey in general, I got fed up with trying to make my mount work, so I am sending it to a person that services mounts. I hope he will be able to fix it, or at least find the cause of all my issues. And once the mount is back and fixed, I should be able to go back to the game. I also have a plan to switch my astro controller to a Pi 5 with an NVME drive, which should give much, much better performance. I will of course report how it goes.

Thanks for reading!

I got my Raspberry Pi 5 a HAT

STFN — Sat, 19 Oct 2024 24:00:00 GMT

This is not a sponsored article, everything mentioned here I bought for myself with my own money.

As I mentioned in the previous blog post, my astrophotography journey is suspended until I get back my mount from servicing. But in the meantime I can work on upgrading other parts of my setup. So far I have been running a Raspberry Pi 4 with astroberry.io to control the acquisition process, and its performance was always a bit of a pain for me. I have a Pi 5, it was an impulse buy on the day of its release, and lately I had no use for it, so I decided it will be my new astrophotography controller.

And as I am going to use I might as well crank it up to 11 and try out those new NVMe HATs for bigger and faster storage.

Choosing the HAT

For the HAT I chose the HatDrive! Nano by Pineboards.

I chose a product by Pineboards for a few reasons, first of all I've been following their progress, and I am impressed how quickly they went from basically two guys with a soldering iron, to a proper company making Raspberry Pi accessories, and second, the creators are my fellow compatriots, and I felt like supporting the Polish hardware scene :) And thirdly, my main inspiration for all RPi stuff, Jeff Geerling, made a few videos showcasing their products and his reviews were positive.

I chose the HatDrive! Nano because well, it was the cheapest option, and with the smallest footprint, which I think helps with the cooling, while still supporting 2230 and 2242 NVMe drives as the larger HAT models.

Hardware setup

The HAT came with a set of screws, spacers, and the ribbon cable. The screw package looked like a set from a different model, because it had four spacers, while the Nano version only uses two. But hey, free M2.5 spacers, always useful when tinkering with SBCs. Also in the documentation section on the Pineboards webpage there is no entry for the Nano, only for the Lite, but that's ok, they are almost indentical when it comes to mounting.

For the case I am using a ThePiHut cluster case. It's universal enough to be able to accommodate the Pi 5 as well as the 4, can be used for single SBC builds, and is open on the sides, which is good for the cooling. I had to modify the mounting of the Pi a bit to make it work with the spacers, thankfully I had a bunch of long M2.5 bolts that went through the bottom of the case, through the Pi and into the spacers from below.

Mounting the HAT itself was easy, the hardest part was handling the ribbon cable, but with being very very cautious, I managed to make it work. I'm always afraid I will break those tiny connectors that hold the ribbons in place. And not without reason, I broke the camera connector on my first Pi Zero.

The NVMe SSD I am using is a 512GB Kioxia drive which I bought rather cheaply from a local marketplace. The seller said it was taken from a new laptop which in place got a larger drive.

That dangling thingy visible in the photos is the battery for the RTC clock.

Booting The Pi 5 from an NVMe drive

My plan was to ditch the SD card altogether and use the NVME as the boot drive.

After installing the NVMe HAT, I booted the Pi from the SD card. I'm running the latest version of the Raspberry Pi OS, 64 bit, with the desktop environment.

The system booted normally, and I opened GParted to see if the new drive was seen by the system. And it was! On the first time!

The drive was reporting correctly, so I used the SD Card Copier utility, installed by default on the RPi OS, and copied the system from the microSD card to the NVME drive. It took around 10 minutes.

Then I went through the instructions provided by Jeff on how to set the NVMe as the boot drive. Few commands in the terminal later, I turned off the Pi, removed the microSD card and turned it back on again.

Running the NVMe Pi

And I have to say, WOW! The difference is staggering. The boot sequence, which takes 30 seconds, maybe more on a microSD card, was almost instantaneous when booting from the NVMe. That white window with the Raspberry Logo barely blinks. The desktop is ready to use in seconds.

The whole feel of using the Pi is different. Thunar is smooth as butter. All the apps load much faster. It's as if it was a totally different computer. Firefox is a much better experience. And for those astrophotography people out there, I have to tell you, using KStars from an NVMe drive will not be a pain anymore.

I won't provide any benchmarks, there's already a ton of them on the Internet. If you want to see graphs and numbers, I highly recommend Bret's webpage, where he does all sort of high quality testing of different SBCs.

I had two main concerns when installing the NVMe HAT. The first one was WiFi connectivity and the second one was cooling.

The WiFi on the Pi is not the best, especially when using the 5GHz band. I was concerned that the HAT would interfere with the signals and degrade the performance, but from my short testing I did not see any problems. We'll see how it goes in the long run.

As for cooling, after adding the HAT, I installed PHD2 by compiling it from source. And even under prolonged load, with the active cooler on, the Pi stayed around 58C. I have a feeling that the HAT even helps with the cooling a tiny bit, as it guides air through the radiator and not away from it. But that may be just my suspicion.

Bottom Line

I now strongly believe that if you have a Pi5, you should consider getting an NVMe HAT for it. You will get a much better experience of using that SBC. I would say that now the microSD, while being cheap and plentiful, and easy to replace, is now the biggest bottleneck for the Pi. It's great for tinkering and quick testing, breaking and reflashing, but for running sustained loads, and in general using the Pi as "prod", go with a drive.

All in all I paid 16EUR for the HAT (with taxes and shipping) and a similar amount of money for the drive. Smaller drives can be bought for half that or even less.

On one hand, is not an insignificant amount of money to be spend already on top of the cash that the Pi itself costs, but on the other hand, you get much, much better performance from the hardware you already have.

I have to say, I am excited for that future holds. If everything goes well, I should be back in the astro game on a whole new level. And even if that does not work out, I now have a very performant SBC that I can use for other tasks.

What do you think about all this? I'd love to hear your thoughts, in the comments below, via email, or on Mastodon. Links in the footer.

Thanks for reading!

Testing the performance of an NVMe HAT in BOINC

STFN — Thu, 31 Oct 2024 24:00:00 GMT

In the previous post I talked about getting an NVME HAT for my Pi 5. After seeing how much faster the Pi 5 became when ditching the SD card, I thought I might see if the new storage makes any difference in BOINC.

In short, BOINC is a framework that allows scientists in need of processing power to send work to volunteers. The computers of the volunteers then crunch the work units and send back the results back to the scientists for further analysis. This way ordinary people can help push science forward, by sharing their mostly idling computers. I've been participating in BOINC for almost four years now.

I talked more about BOINC in My thoughts as I reach 100 million points in BOINC and I reached 150 million points in BOINC blog posts.

A year ago I got my Pi 5 and tested its performance in BOINC against the Pi 4B. The results have shown that the Pi5 is indeed much faster than the previous generation of the popular SBC:

RPi 4b vs RPi 5 benchmark in BOINC - Einstein@Home

RPi 4b vs RPi 5 benchmark in BOINC - Asteroids@Home

RPi 4b vs RPi 5 benchmark in BOINC - Universe@Home

Now it's time to see if the NVMe HAT will make the Pi 5 even faster.

And the tl;dr answer is: it depends on the project.

Maybe not the cleanest setup, but hey, it worked

Test Setup

The test was done using a Raspberry Pi 5, with the active cooler, official Rpi 5 power supply, and with an NVMe hat from Pineboards. The NVMe drive is a KIOXIA 512GB 2242 SSD. I also added a 80mm fan powered from the Pi's USB port for enhanced cooling. Throughout the test, the Pi's CPU temperature stayed at around 60C.

I crunched on all four cores. I did not overclock the Pi's CPU.

Einstein@Home

In Einstein@Home, the HAT does make a difference of around 30 minutes per task. There were no problems with the cooling, the slowly turning 80mm fan combined with the active cooler resulted in a quiet and cool operation of the testing rig. Not much else to report, so here are the diagrams:

Average tasks time

For the 4b, the average tasks time was 16353 seconds (4 hours, 32 minutes and 33 seconds). For the Pi 5, the average task time was 10858 seconds (3 hours and 58 seconds), a decrease of around 33%. The average task time for the Pi 5 + NVMe was 8055 seconds (2 hours, 14 minutes and 15 seconds), around 30% faster in comparison with the Pi 5, and 67% faster than the Pi 4.

Minimum task time

For the 4b, the shortest task took 13866 seconds (3 hours, 51 minutes and 6 seconds). For the Pi 5, the shortest task time took 10207 seconds (2 hours, 50 minutes and 7 seconds), a decrease of around 26%. The minimum task time for the Pi 5 + NVMe was 7673 seconds (2 hours, 7 minutes and 53 seconds), around 28% faster in comparison with the Pi 5, and 57% faster than the Pi 4.

Maximum task time

For the 4b, the longest task took 17148 seconds (4 hours, 45 minutes and 48 seconds). For the Pi 5, the longest task took 11370 seconds (3 hours, 9 minutes and 30 seconds), a decrease of around 33%. The maximum task time for the Pi 5 + NVMe was 8624 seconds (2 hours, 23 minutes and 44 seconds), around 27% faster in comparison with the Pi 5, and 66% faster than the Pi 4.

Average tasks per day

Asteroids@Home

After finishing with Einstein@Home, I switched to another projects which also supports ARM tasks: Asteroids@Home.

As previously, I started with the default settings, added the project in BOINC Manager, and the Pi 5 began churning through the tasks.

The first thing I spotted is that I had to pump up the cooling, as the temperatures on the CPU rose quickly, and the Pi's active cooler sped up to become very audible. To mitigate this, I switched the 80mm fan from using the 5V USB, to a 12V barrel jack power brick. That kept both the temperatures and the noise under control, an 80mm fan running at high speed is much more acceptable in terms of noise than a 40mm one.

After crunching around 40 workunits I realized that there is basically no difference in the runtime. The runtimes were around 3% shorter than when using the SD card.

Another thing that raised my curiosity was that the application version differed from the one I crunched a year ago. I asked in the project's forums if those two are actually comparable, and the answer was that yes, they are similar. However, there is a new, optimized version of the crunching application, which should give much better performance. It should be already provided to all users, but somehow that was not the case. But I could switch to it manually. This would not only allow to squeeze even more performance from the Pi, but also ensure that I am really comparing apples to apples. Or raspberries to raspberries.

Switching to the optimized version of the application was very simple, all it took was adding an app_info.xml file in the project's folder (/var/lib/boinc/projects/asteroidsathome.net_boinc for Linux) and downloading the app file. Note that the BOINC folder belongs to the root user, so you will need root permissions to do so. Here's my app_info.xml file in full:

<app_info>

<app>
<name>period_search</name>
<user_friendly_name>Period Search Application</user_friendly_name>
<non_cpu_intensive>0</non_cpu_intensive>
</app>


<file>
<name>period_search_10220_aarch64-unknown-linux-gnu</name>
<executable/>
</file>


<app_version>
<app_name>period_search</app_name>
<version_num>10220</version_num>
<platform>aarch64-unknown-linux-gnu</platform>
<avg_ncpus>1.000000</avg_ncpus>
<api_version>7.17.0</api_version>
<file_ref>
<file_name>period_search_10220_aarch64-unknown-linux-gnu</file_name>
<main_program/>
</file_ref>
</app_version>

Here's the link to the forum thread.

Thank you ahorek's team and Keith Myers for all your help! :)

And so I crunched the optimized version as well, both with and without the NVMe HAT, and the results were identical: there is no significant difference when switching the storage type.

So, here are the results for the average task time:

Raspberry Pi 4: 38010 seconds (10 hours, 33 minutes and 30 seconds) seconds
Raspberry Pi 5, default app, SD card: 11953 seconds (3 hours, 19 minutes and 13 seconds)
Raspberry Pi 5, default app, NVMe HAT: 11661 seconds (3 hours, 14 minutes and 21 seconds)
Raspberry Pi 5, optimized app, SD card: 6717 seconds (1 hour, 51 minutes and 57 seconds)
Raspberry Pi 5, optimized app, NVMe HAT: 6593 seconds (1 hour, 49 minutes and 53 seconds)

I strongly suspect, that in contrast to Einstein's application, the Asteroids' one does much less disk I/O during operation, and so does not depend on the speed of the storage. The increased thermal load on the CPU would also suggest that it is much more utilized, and therefore is the biggest bottleneck here.

Universe@Home

Sadly, U@H is still suspended and it's future is unknown.

Final Words

Here are the detailed benchmark results in ODS file format:

Asteroids@Home

Einstein@Home

So, should you buy the NVMe HAT?

If you use your Pi 5 not only as a BOINC cruncher: a strong yes. As I wrote in the previous blog post, it makes a large difference in the Pis overall responsiveness and performance.

If you use your PI 5 only as a BOINC cruncher: It depends. If you are a fan of E@H and only crunch that project, then I would say go for it, a 30% improvement in crunching speed is a lot. If you prefer Asteroids, it won't make any difference. And I hope that one day I will be able to again crunch Universe@Home and see how it fares with better storage.

I think that for now it's the end of benchmarking the Pi 5. The SBC will now wait for me recreating my astrophotography setup, and once it is done, it will go atop my mount to control the acquisition process. And that will be a topic of another blog post.

P.S. Just before publishing this post, Pineboards.io announced that they will be releasing an NVMe + PoE HAT, and that makes me double excited, as I am planning to dive into the world of Power of Ethernet when I build a new iteration of my homelab.

March 2026: Sadly, Pineboards is no more, they closed their online store at the beginning of 2025.

Thanks for reading!

I started using ESPhome and now I have a local smarthome

STFN — Wed, 13 Nov 2024 24:00:00 GMT

I have been slowly getting into the field of smart home solutions. I am taking my time, because I do not want to fall into the typical pitfalls of the "easy" smarthome. First of them being vendor lock-in, which becomes especially bad when that vector bankrupts and all of their devices become pretty bricks. And second being privacy and data security. I don't want my devices to talk to some random servers, sharing data they should not have access to in the first place.

Also I am big fan of FOSS solutions, and I don't mind making stuff myself, both with a soldering iron, and in the command line.

And it looks like I found something that ticks all the boxes: ESPHome

In the tl;dr version, ESPhome is a tool that provides a simple way to configure microcontrollers, allowing to use them with Home Assistant or other smart home software.

ESPhome enviroment sensor visible in Home Assistant

Now, ESPhome supports a metric ton of devices and accessories like sensors or controllers, so I won't be diving into those details, instead I want to show how it works by showing two ESPhome projects that I did: a relay, and an environment sensor, both connected to Home Assistant.

Initial State

Everything written below assumes that you already have a working Home Assistant running in your home server, and you know a little bit about the command line.

The Hardware

ESPHome supports ESP32 and ESP8266 microcontrollers. It also officially supports the RP2040 devices, such as the Raspberry Pi Pico, but I had multiple problems making them work, that will be a topic for another post.

For the first project I am using an ESP-wroom-32 microcontroller based on the ESP32 chip. You can get them literally dirt cheap, for a few euros each, and they will work just fine with ESPhome. I've seen them as cheap as 3 EUR / 15 PLN on aliexpress, and just a bit more expensive at local retailers.

For the second project I went with the Seeed Studio XIAO ESP32C3. It is more modern and advanced than the wroom-32, with a USB-C connector and an external Wi-Fi & Bluetooth antenna. I came across it when browsing one of the electronic shops where I usually buy parts for my projects, and I was impressed by its capabilities.

It's tiny, the size of a typical coin, yet it supports all of the typical microcontroller interfaces, like SPi, ADC or I2C. It has a built-in USB-C connector for programming, and as for wireless connectivity, Wi-Fi and Bluetooth are also on board. But the thing I liked most is that it has a charge controller for li-ion batteries, which means you can connect a battery straight to the board, and charge it via the USB-C. It supports any 3.7V li-ion battery, and I went with a typical 18650. It's more expensive than the wroom one, but still in the acceptable range, at 5 EUR / 30 PLN.

The biggest downside for me is that the battery connector pads are tiny and are very difficult to solder to, a JST connector would be a much better solution.

The Relay

The relay that I am using is an IDUINO single channel relay that can handle mains voltage and can be bought for as little as 3 EUR.

The Sensor

As for the sensor I went with a BME280, which is a combined temperature, pressure and humidity sensor. It's the same sensor I used in my Solar Weather Station project.

Setting up ESPhome

There are multiple ways to install ESPhome, I went with the most "oldschool" way, installing it manually from the command line. It's also the simplest one to set up, as it only requires having Python on your local machine.

Everything is described in the installation instructions, but here's the recap:

Create a Python virtual environment (it's considered a good practice to always create one when working with Python)

python3 -m venv venv

Now, activate it, and install the required dependency and the package itself

For Linux:

source venv/bin/activate
pip install wheel
pip install esphome

for Windows:

venv/Scripts/activate
pip install wheel
pip install esphome

And here you go, ESPhome is installed and ready to be run. Before we run it, though, let's prepare the hardware.

Of course, those are just examples, you can mix and match hardware as you wish.

Project 1: ESP32 relay

ESP32 connected with the relay

The esp-wroom-32 and the IDUINO relay both come with GPIO headers already soldered, so there is no need to do any additional soldering. All that you need is three female-to-female jumper cables.

The relay has three connectors, negative, positive, and control.

In this PDF documentation you can find the pinout diagram for the ESP-wroom-32

The positive needs to go to the VIN pin on the ESP32, this is the pin that provides 5V output for powering the relay. The negative needs to be connected to one of the ground pins, there's one next to the VIN pin, so we can use this one. Finally, the control pin needs to be connected to any of the pins on the ESP32 that can be controlled. GPIO13 is right next to the VIN and GND pins, so let's use this one and have all three cables connected next to each other.

For now you can leave the other side of the relay not connected to anything as we are testing our project.

You can connect mains voltage (120V-220V) to that relay, but remember that working with such high voltage is dangerous and can kill you. Proceed only if you know what you are doing, and at your own risk. Be reasonable.

ESPhome setup

After connecting the relay, connect the ESP32 microncontroller to your computer using a micro-USB cable. With the Python virtual env activated, run:

esphome wizard livingroom-relay.yaml

For the board type select esp32dev. Fill in the Wi-Fi information. Once the wizard is done, a file livingroom-relay.yaml will be created. Open it with your text editor of choice.

At the bottom of the file add:

switch:
  - platform: gpio
    name: "Switch 1"
    pin: GPIO13

Change the name to something more descriptive :)

Once this is done, run

esphome run livingroom-relay.yaml

If this is the first time you are installing ESPhome on that device, the script will install the required software and copy the yml file to the device. This requires the USB cable. Subsequent updates can be done via Wi-Fi, another cool feature of ESPhome.

Once the installation is done, the board will connect to WiFi, the logs will tell what is happening. If all finished successfully, the next step is to go Home Assistant.

Now the magic should happen, and HA should automatically find ESPhome and notify you that a new integration is available. If that didn't happen, refresh the page after a few minutes, or try to add the integration manually from the integration settings.

Once the integration is added, a new relay toggle button should appear on the HA dashboard, with the name that you provided in the yml file.

Clicking on the toggle button activates the relay, an audible click should be heard as it turns on and off. And in effect, you are able to control dumb devices, even those running on mains voltage, like lamps or fans, from your Home Assistant. And everything happens locally without shady cloud software.

The relay in action

Project 2: Seeed Studio Environment Sensor

Seeed Studio connected with the BME280 sensor

For this project the build process was a bit more involved, as it required soldering the pin headers to both the ESP board and the BME280 sensor.

Then, with two small wires, I connected the 18650 battery case to the pins on the downside of the board. This was not a pro gamer move, soldering the battery pins would be much easier if I did before adding the pin headers. Anyway, with some complicated soldering iron gymnastics, I managed to make it work.

Next was the Wi-Fi & Bluetooth antenna with its tiny connector. The external antenna is another cool feature of that board.

I connected the board with the sensor using female-to-female jumper cables.

The BME280 sensor I am using support I2C connectivity, to this is the protocol I went with. Connecting it with the board requires four cables: VCC, GND, SCL and SDA.

Here's the pinout diagram for the Seeed board:

I connected the VCC of the sensor with the 3.3V output pin on the board. GND with the GND pin. SDA to the GPIO6 pin, and SCL to the GPIO7 pin. And the hardware part is done.

ESPhome setup

Most parts of the setup are identical as in the first project, so I'll just glide over them.

Create a new file using the wizard. As the board type, select seeed_xiao_esp32c3. When the yml file is created, at the bottom of it add

i2c:
  sda: GPIO6
  scl: GPIO7
  scan: true
  id: bus_a

sensor:
  - platform: bme280_i2c      
    address: 0x76
    temperature:
      name: "Temperature"
    pressure:
      name: "Pressure"
    humidity:
      name: "Humidity"

This snippet first configures the I2C connection and sets up the BME280. The output will have clear, human-readable names.

Update the file with the provided snippet, run the upload, and again, once the microcontroller is running with the new code, HA should discover it automagically.

Now the cool thing with that board is that you can leave it plugged in and it will charge the 18650 battery in the soldered in battery case. After a few hours of charging, you can plug it off and the board will run under its own power.

From my experience, under default settings and with a good 18650, it reach 5 days of uptime. With more cells, and with longer times between readings (it can be configured in the yml file), it should reach multiples of that runtime.

The full package with the battery and the wireless antenna

ESPhome Dashboard

ESPhome has another cool trick up its sleeve.

esphome dashboard .

Running the command above in the folder where the config files are stored will start a webserver. Opening the provided link in the browser will take you to a dashboard that shows the currently online ESPhome nodes, and the ability to edit their config upload it over Wi-Fi. Super useful stuff when the nodes are in hard to reach places, or are firmly secured.

Bottom Text

This has been just scratching the surface of what ESPhome is capable of. Browsing the docs shows that it can support a lot of different boards and sensors and controllers.

One interesting project that I found is controlling cooling fans: esphome-fan-controller

I feel that ESPhome will be very useful to me once I have my own house. The possibility of having home automation without relying on shady third party software, but instead on one's own coding and soldering skills is extremely tempting for me.

And on the other hand, ESPhome in my opinion significantly reduces the entry barrier for less technical people by allowing relatively easy means of programming and configuration of microcontrollers. And with the right hardware, like the Grove sensors, soldering is not even required.

And that's it, if I have any new projects with ESPhome, I will for sure share them with you.

Thanks for reading!

I published my first package to PyPi

STFN — Tue, 19 Nov 2024 24:00:00 GMT

Zambretti-py on PyPi.

As long-time readers of my blog may know, I like gathering environmental data like temperature and pressure. And some time ago I started thinking, if I am able to gather such data over a timespan, maybe I could use it for local forecasting of weather? I know that real forecasting requires a lot of data and massive computation, but maybe there is something simple for short-term forecasts?

A physical Zambretti Forecaster, image taken from Wikipedia, copyright CC BY-SA 4.0

A quick startpaging* presented me with the Zambretti algorithm, a relatively simple way to forecast the weather for the next hours, using the current temperature and a history of changes in atmospheric pressure. Looked like something perfect for my basic use case.

*Startpage is currently my favourite web search engine.

Now, it looks simple and useful, surely somebody already implemented it in Python!

And turns out that no, there had been no Python implementation of the Zambretti algorithm on PyPi. And don't call me Shirley.

I dropped the topic for a few weeks, but one day I had an idea... if nobody made a Python package for it, maybe I could do it? And publish it? That would be cool, a learning experience, and having my own package on PyPi would be another step in my Python development ladder.

The code

The code can be found on GitHub - zambretti-py. I usually prefer Codeberg, but this time I went with GH, mostly for the easily available Actions.

And so I sat down and started writing my own package. I decided to start small and simple, without any dependencies, using only what is available in the Python Standard Library.

My main source of inspiration was this repo, I took some of the code snippets from it and converted them into Python.

Making it into a package for anyone to use raised for me some interesting questions regarding the project structure and imports. I went with imports in the __init__.py file to simplify importing when using the package.

The biggest issue with this code is that it can be better. Showing your work publicly is never easy, and impostor syndrome is strong with this one. And on top of that are the thoughts of "you are called a senior developer at work, how can you now know how to make it better?!". So thank you to all my Fediverse friends who encouraged me to actually carry on and publish it.

And I can always make it better with time, right? The package is currently at version 0.0.4, there is still a long way to reach 1.0.0.

I have plans on how to improve it, probably at some point I will drop the "uses only the standard library" idea. I'm thinking of using Pydantic for data storage and validation, Pydantic has been one of my favourite Python modules lately.

I would love to see somebody made a PR with a suggested improvement, it's always good to see other people's ideas.

Publishing on PyPi

I started my plan for publishing on PyPi with asking the Fediverse people for tips on how to do it, and kindly enough, I received a lot of replies with great feedback. This is what I really enjoy about Fedi, people there are not only knowledgeable, but also helpful <3

You can read the conversation in full here.

As with the code I decided to start slow, small, and simple.

I have to praise the documentation available at packaging.python.org, it is clear, well written, and provides good examples. Exactly what good documentation should have.

My main source of knowledge was this tutorial on packaging which is a concise version of a more in-depth documentation.

Going along the tutorial I modified the structure of the project, added the required pyproject.toml file, and filled it with the metadata.

For testing, I registered at Test PyPi, created a token, and with a imaginary drumroll, I published zambretti-py to the test repository with a single command in the terminal. And it worked! I was amazed how simple and straightforward the whole process is. Publishing to a test repo allowed to straighten some things with naming and metadata.

Going to Prod

After resolving the minor issues that I found after publishing to the test env, and after another round of code refactoring (you can never have enough refactoring), I decided to jump on the deep end and go with Prod, the real PyPi.

The publishing process was virtually the same, I registered at pypi.org, set up a token and used the same commands, just without the bits defining the testing repository.

Alas! zambretti-py is now live! Other Python developers can now find it and use it in their projects, I made a tiny contribution to the Python ecosystem and that felt and still feels great.

Switching to GitHub Actions

After publishing I manually I looked for ways to streamline the publishing process and I found that GitHub provides a ready to use Action that publishes packages to PyPi. The only required configuration is setting the secret for the PyPi token. The action is run on every creation of a release on GH.

I'm used to using GH Actions and releases at work, but having to use the releases mechanism for my own project is something new, and another learning opportunity.

Next steps

The closest next step is to improve the code, obviously :)

In the conversation in the Fediverse about publishing, many people mentioned something called Trusted Publishers and this is something I want to take a closer look.

Bottom Text

Even though it is just a small and simple package, the whole process has been a great learning opportunity for me. Packaging in Python is something totally new to me, and also I had to refresh my knowledge on GitHub Actions and releases.

I'm hoping I will continue this journey, and learn even more new things as I maintain zambretti-py.

And I am happy to be a tiny part of the FOSS contributors community.

If you are also thinking of publishing your package to PyPi, do it! It can be scary at the beginning, but all in all, it is something that anyone can do easily, and there is nothing stopping you.

I would like to again thank everyone on the Fediverse who gave me ideas, feedback and nice words, and answered my questions, you people rock.

P.S. I wrote most of this blog post in Neovim running in tmux. I'm really getting into those two tools, and using them instead of VSCode sparks joy in me. Probably soon I will make a post specifically on how I am using them and how do my configuration files look like.

Thanks for reading!

How I started my GoToSocial instance in the Fediverse

STFN — Tue, 26 Nov 2024 24:00:00 GMT

Ever since I joined the Fediverse a year and a half ago, I had this vague idea that one day I would have my own instance. And here we are, I am now the owner and the admin of fedi.stfn.pl

The welcome screen of my instance

The final push that made me create my own instance was the sad story of botsin.space, a Fediverse server dedicated to running bots. For the last year I had been running there my Astrobin Image of the Day bot. But that now ended as its owner decided that they do not have the time and means to continue running this popular instance, and that they would be shutting it down. Gracefully, they provided ample time for migrating before the final turning off the lights.

I considered several options, most of them being migrating to other existing instances, but eventually I decided that this is a perfect motivation for me to start my own gig. After doing some research and asking a few fellow Fedi people, I decided to go with GoToSocial, an ActivityPub server application.

From reading the docs, GoToSocial seemed like an easy solution to implement, and it did not require SMTP, something which stopped me from my old plan to self-host Lemmy. One day I will write about my bad experiences with an SMTP service. I was also glad to read that GTS requires minimal resources, and so can be run on a low-tier VPS. Finally, I've seen a few people in the Fediverse running their own instances, and they all seemed happy with the quality of service.

OK then, the software is chosen, now for the place to run it. I again turned to RackNerd, as I am happy with their VPS that I already have, and they have a BlackFriday (ugh, I know) sale. This post, as any other, is not sponsored by them, nor by anyone else, but I have an ~~~affiliate link~~~ that you can use, and if you buy something from them using the link, I will get a tiny commission. This blog is also running on a RackNerd VPS. I went with a slightly more powerful machine, with two CPU cores and 3GB of RAM.

2026 Update: I left RackNerd for Hetzner as part of my move from US to European services.

The rest of the post will be about the initial setup, configuration and running of my GoToSocial instance, if you, dear reader, want to do the same I would suggest reading it in full before following my steps.

No usable frontend?

Before we start, let's get one thing out of the way. One thing that was not clear for me was that, quoting the docs, "Unlike other federated server projects, GoToSocial doesn't include an integrated client front-end (i.e., a web app)." What does that mean?

It means that you when you go to webpage of your account, for example stfn @ fedi.stfn.pl, you will not be able to post new statuses. Also there is no timeline view of the people you follow, there is only the instance welcome screen. To actually use your account, you need to use a separate app, the two recommended by GoToSocial are Semaphore in the browser and Tusky on mobile. Semaphore is okayish, looks and works very beta-like, but Tusky I can fully recommend, its the app that I use all the time on my phone. All in all I would say it's just a minor inconvenience, and I understand the GTS devs focusing fully on the backend part.

The preparation

Once you have your own VPS, you need to get a domain for it. One options is to buy a domain from your preferred domain provider, I personally use home.pl, but from what I know there's a ton of them, like NameCheap, or Porkbun. After buying, point the domain to the IP address of your fresh VPS. The second option, is that if you already have a domain you can set up a subdomain, which is usually free. This is what I went with, I have the domain stfn.pl, and for the instance url I chose fedi.stfn.pl

Now, the server. I went with the typical setup and hardening of a Linux VPS, DigitalOcean has a great article on it, which I use everytime I have a new machine in the cloud: DigitalOcean initial server setup.

The outcome is a VPS to which I can ssh into using only ssh keys, with a regular user with sudo permissions, and the VPS is running a firewall. The firewall is configured so that the VPS can only be accessed using ports 22 (ssh), 80 (http) and 443 (https)

A good checkpoint at this moment is to install nginx, and try opening your domain in the browser. If everything went fine, you should see a default nginx welcome screen. If not, one possibility is that you need to wait a bit, it takes time for DNS to propagate.

Installing GoToSocial

Here is the documentation for installing GTS: Installation

I would suggesting reading it all before starting with the installation, that will give a clear view of all the things that need to be done.

I went with a bare metal installation, did not feel like using Docker here. I also decided to use a separate reverse proxy for handling the incoming traffic.

I also decided that SQLite will be fine, the docs said that using SQLite is ok for instances up to 30 users, and I don't think I will ever pass 10, with most of them being bots posting once a day or so.

Here is my config.yml file in full:

host: "fedi.stfn.pl"

bind-address: "127.0.0.1"

port: 8000

trusted-proxies:
  - "127.0.0.1/32"

db-type: "sqlite"
db-address: "sqlite.db"
storage-local-base-path: "/gotosocial/storage"

lets-encrypt-enabled: false

instance-language:
  - "en-gb"
  - "pl"

The default port is 8080, but I went with 8000, as 8080 is the port used by the nginx-prometheus-exporter, about which I will talk more in the next post.

The bind-address and trusted-proxies are required to be this way for GTS to work with the reverse proxy. Also lets-encrypt-enabled is set to false as nginx will be handling the TLS certificates, not GoToSocial.

The final step here was to set up the systemd service. I have a confession to make, I am a big fan of systemd, I use it whenever possible to daemonize services. This is also described in the documentation.

At this moment, after enabling and starting the systemd service, you should be able to curl into your instance from your server, but not from anywhere else, as GTS is running, but will only accept connections from 127.0.0.1, meaning the same machine. You can test it out by running:

curl localhost:8000

And the response should be the HTML of the instance welcome screen.

With GoToSocial running, it's time to configure the reverse proxy. If you did the previous steps, nginx should be already installed on your server. GoToSocial provides docs on setting it up: reverse proxy setup

For obtaining TLS certificates I am using Certbot, with Certbot the whole job is a single command, and the certificates autorenew automatically.

The upside of having a separate reverse proxy is that in the future you will be able to run other services along GTS on your VPS, and separate the traffic flowing towards them at the reverse proxy level.

At this moment you should be able to type your domain in the browser, and see the welcome screen of your GoToSocial instance.

If that is not the case, then it's time for investigation, I would start it in this order:

# check if GoToSocial is running
sudo systemctl status gotosocial.service
# check if nginx is running
sudo systemctl status nginx.service
# check GoToSocial logs
sudo journalctl -f -u gotosocial.service
# check nginx logs
sudo tail -f /var/log/nginx/access.log

Each one of those places should tell you something about the state of things.

But if everything is fine, the instance is running, nothing is burning, you can proceed with creating the first user. GTS provides a CLI tool for the creation of users, everything is described in the docs, but for the tl;dr crowd, here's the command:

./gotosocial --config-path /path/to/config.yaml \
    admin account create \
    --username some_username \
    --email some_email@whatever.org \
    --password 'SOME_PASSWORD'

Read the docs for other info, like promoting the user to be an admin. And remember to restart the GTS service each time you create a new user:

sudo systemctl restart gotosocial.service

After each restart, GTS needs a minute or two to be up and running again, so be patient and don't panic :)

Using GoToSocial

And it's done. You can now log in, using Tusky, Semaphore or any other application, provide the username, password, and instance url, and done, you are a part of the Fediverse from your own domain! It's that simple.

Settings

To configure your account and your whole instance, you can login to the settings page, at {domain}/settings. There you will be able to well, set the settings for your account, and if you have the admin right, set the settings for the whole instance. Set the settings, wow, that came out bad. But you know what I mean. Settings. Config.

Federating

It takes a while for the other instances to find out about yours. What I did was that I used my existing accounts at pol.social and fosstodon.org to boost my "hello world" post from my first account in my instance, and it helped advertise my new instance over the Fediverse. At the moment of writing this post, my server is federating with almost 1600 other instances.

Who is using fedi.stfn.pl?

Right now it's me, and my two bots:

For now I do not plan to invite anyone else, I am new at this Fedi administration thing, and if I break something and lose all data, I want to be the only one affected by it.

Bottom line

So here I am, with my own Fediverse instance. So far it has been running fine, there are still some things I need to work out, like regular backups. I have nginx logs opened in the background to take a look at them now and then and see if there are any problems happening. In the other pane of tmux I have htop opened to see the resources usage. So far, barring short spikes when someone popular boosts my toots, the load is close to 0.0, and RAM usage is around 400-500MB.

I am sure this is only the first blog post in a series in which I will be talking about my experiences as an admin. And already I have to say, it does feel good :)

And what is more, having my own instance means I can upload my own custom emojis. Being a person who grew up in Poland in the 90s and 00s, the choice was obvious. I apologize for nothing.

The Pope and Gadu-Gadu

I would like to thank

Special thanks to Amin and Inga for helping me work out some doubts and issues that I had with initial configuration! :)

Coming up next

Soon there should be another blog post, in which I will talk about how I migrated my bot, and about setting up monitoring for my instance.

Thanks for reading!

Administrating my GoToSocial instance - monitoring and backup

STFN — Mon, 23 Dec 2024 24:00:00 GMT

As with the previous post about GoToSocial, you should not take what I write here as gospel. It is possible that I am doing something not in the best way. One of the reasons I write those posts, apart from the need to share what I learnt, is the hope that someone more knowledgeable than I am will pinpoint my mistakes and provide useful feedback.

My GoToSocial instance has been running for more than a month now, and now as I have gathered some experience in administrating it, I can share it with you, dear readers.

fedi.stfn.pl has been running without issues so far. I did not lose any data, and the number of instances federated with it is constantly growing. The bots are doing what they are told, and I am occasionally using it to toot updates, mostly meta toots on how it's doing. Ah, the Fediverse trend of tooting mostly about the Fediverse :)

The number of instances with whom I am federating is growing.

In the previous blog post I talked about the setup and deployment part of a GoToSocial instance, here I want to talk about the day-to-day monitoring and backup chores.

Resources Usage

My instance does not see much traffic, there are four active accounts there, three being bots posting once a day, and my personal account, to which I post once every few days. There are occasional spikes of traffic when larger accounts retoot my bots.

I'm running it on a VPS with 2 vCPU and 3GB of RAM. The RAM usage is stable around 600MB, with spikes up to 800MB. The typical load is around 0.1, with spikes rarely passing 1.0. During that month I used 10GB of transfer, including typical Ubuntu package updates. GTS media folder uses around 500MB of disk space. I can confirm what the GTS docs state, that with light traffic, GTS will run on the smallest of VPSs, or a Raspberry Pi, if you can expose your local SBC to the Internet.

Monitoring

For the basic, "is my site up" monitoring I am using healthchecks.io. They provide free email and WhatsApp alerts when the site is not responding. And a nice badge to put somewhere.

For detailed information on how the instance is doing I am using a combination of Prometheus, Node Exporter and Nginx Exporter.

I have all three running as systemd services. Prometheus scrapes itself, Node Exporter and Nginx Exporter and exposes the metrics. To reach the metrics from outside, UFW is configured to expose port 9090, but only over the Tailscale VPN interface. The metrics are presented in the form of graphs in Grafana running in my new, shiny k3s cluster. More on that cluster in a future blog post.

Part of the /opt/prometheus/prometheus.yml config file defining the metrics collection.

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: node
    static_configs:
      - targets: ['localhost:9100']

  - job_name: nginx
    static_configs:
      - targets: ['localhost:9113']

And the settings for the UFW firewall, showing how Prometheus is only available through the VPN.

>>> sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 443                        ALLOW IN    Anywhere
[ 3] 80/tcp                     ALLOW IN    Anywhere
[ 4] 9090 on tailscale0         ALLOW IN    Anywhere
[ 5] OpenSSH (v6)               ALLOW IN    Anywhere (v6)
[ 6] 443 (v6)                   ALLOW IN    Anywhere (v6)
[ 7] 80/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 8] 9090 (v6) on tailscale0    ALLOW IN    Anywhere (v6)

Backup

Backup is done using Borgmatic. Borgmatic is a tool to run Borg on schedule. Borg is a tool to make incremental backups. Incremental meaning that the first backup backs up (wow, great language) the full data, and the subsequent ones only record the information about the changes, saving disk space.

I configured Borgmatic according to the docs. For now, I am only backing up locally on the same VPS, but I have plans to set up automatic remote backups to my Hetzner Storage Box. I just hope I'll make myself do it before I really need it :)

Martin created an interesting alternative approach to GTS backup. He made a bash script that handles the backup process in a smart way. I recommend taking a look at the repo, and listening to the podcast in which he discusses his approach.

Who is on my instan

stfn - my account for tooting about the instance

astrobin_iotd - a bot that every day toots the Astrobin Image of the Day

stacjadnia - a bot that every day toots a link to a random railway station in Poland

naszpapa - a bot that every day at 21:37 toots an emoji with the face of the late pope John Paul II (that is a Polish inside joke, don't ask).

Bottom Line

I am very much enjoying having my own instance in the Fediverse, I feel that I have reached another level in my online presence. It's a learning opportunity, and also a way to have your own part of the Fediverse. Even if my the instances of my main accounts go down (I do hope it won't happen, those are great instances with very nice admins), I will have a place to go back to. And I have a place for testing, for investigating, for my silly bots.

I even might consider inviting other people to use my instance, but only if they acknowledge that I am actually a noob in "cosplaying as a sysadmin" ((c) Jeff Geerling) and they won't mind that there is a non-zero possibility that I do something stupid and lose all their data.

BTW, a few days ago the admin of the late botsin.space instance released a "postmortem", writing in detail about his experience in running a large Mastodon instance. I found it very interesting to read, and telling a lot about the state of Mastodon and the Fediverse in general. Reading it made me even more thankful for the creation of GoToSocial, a simpler and lighter than Mastodon way to have your own instance.

Thanks for reading! If I find something worth mentioning about my GTS instance, there will be another blog post in this series.

I have a new skill - I can now make Ethernet cables

STFN — Sat, 04 Jan 2025 24:00:00 GMT

Happy New Year!

Last month I started building my Kubernetes cluster made from Raspberry Pis (I promise there will be a blog post on it soon). At first it was connected with Wi-Fi, but I wanted to switch it to Ethernet, and eventually power it over PoE (Power over Ethernet). I did not not have cables of the right length, so I went browsing through the usual online shops. And then, I had a revelation: I might make the cables myself!

I watched a few Youtube videos on the matter, as one would, and it did not seem to be too complicated. I enjoy doing manual stuff, DIY is important for me, and having a new skill under my belt is always cool, so why not try it? With Christmas approaching fast, and my parents wanting to buy me a present, I asked Santa Dad to get me an Ethernet cable toolkit.

And Santa delivered, I was now the proud owner of a set of tools that allow me to make my own Internet: an RJ45 crimping tool, a wire stripper, a cable connection tester, and a weird grey knifey tool that I am still not sure what it does.

Here's the toolkit

On my own, I bought 20 meters of cat 5e cable, and a 50 piece pack of RJ45 connectors and connector rubber covers.

Everything was surprisingly cheap, the toolkit was 70PLN (17EUR), and the cables and connectors were 80PLN (19EUR). The price for the toolkit and the materials was close to the cost of a few ready-made cables.

I used this Youtube video as the tutorial on crimping cables. It's in Polish, but it shows very clearly what to do. And there's a ton of such videos everywhere, surely there will be one in your language :)

Looks like "beginner's luck" is actually a thing, because the first cable I made worked on the first try, whereas the second one I had to correct twice. The cable tester is a very useful thing, it shows right away whether the cable was done correctly.

My Pi K3s cluster, connected with the cables I made.

So far I made two cables from scratch, and fixed another one that had a broken connector. If not for this possibility to fix it, I would throw it out, so one less thing going to the heap.

And that's it, I have a new skill. In my future home I will be making the cabling myself. And if I ever meet a fellow nerd in real life and not over the intertubes, I might give them a home-made Ethernet cable as a present :3

Thanks for reading!

My Kubernetes & BOINC Raspberry Pi Cluster

STFN — Sat, 11 Jan 2025 24:00:00 GMT

In the last two months I managed to buy two cheap, second-hand Raspberry Pi 4s with 4GB of RAM. The second one I bought the day after Christmas, it was described as a "failed present". Somebody had a bad experience under the Christmas tree which turned out to be a win for me.

Having now enough Raspberry Pis I could start with my plan that I had had for a very long time: create a cluster.

Why would I want to create a cluster of Raspberry Pis? Mostly for learning, and fun. Kubernetes is a technology that has been on my to-do list for years now, and while I did some learning using single node Minikube, I wanted to try out the "real thing" and run it on a multi-computer setup. Having a cluster is also an incentive to try out other administration and management tools like Ansible. And also I enjoy the hardware aspect of the Pis, it's like a LEGO for adults. I mean, LEGO is also for adults, so um, Pis are like LEGOs, and both are for adults. And teens? I don't know where this is going. You get me.

Anyway, let's talk about the cluster.

The cluster in its full glory, with the bit too long cables.

Hardware

The heart of the cluster is three Raspberry Pi 4b, each having 4GB of RAM. They are mounted in an unbranded open cluster case The case is universal enough that it can also accommodate any other Pi, so at some point I might be able to switch the Pis to model 5.

All three Pis are connected to my NETGEAR PoE+ switch using cables that I made by myself.

The PoE HAT

One of the Pis is using the Raspberry Pi PoE+ HAT. Why only one? Because those HATs are a bit too expensive to buy three at once, and also I wanted to test it out before committing to install them on every Pi that I have.

After a week of using it I am now sure that at some point I will buy the PoE HATs for other Pis. It may not sound like much, but removing the power cable and the wall charger makes a real difference in the tidiness and space usage of the whole cluster

An upside or a downside, however you look at it, is that the HAT has a fan. Active cooling helps a lot with keeping the thermals down, especially under prolonged loads (and I've been doing them, more on that soon), but the fan can be noisy at times. To combat that, I used Jeff Geerling's hack to change the fan curve and that helped with the noise. I also added another, larger fan to blow air over the whole cluster, which is another factor in stopping the HATs fan from ramping up.

What I do not like about the PoE HAT is that it is very close to the board. It makes sense in tight cases, I imagine, but in my case it only meant that I had to remove all the radiators that I glued to my Pi, apart from the CPU one. And even that one would fit only when I removed one of the screws holding the fan.

Zoom on the PoE HAT

Software

The Pis are running the latest Raspberry Pi OS 64 bit without a desktop environment. Everything is done via SSH.

The hostnames are Atlas, Agena and Thor. Yes, I named them after NASA rockets :)

Kubernetes

The cluster is running K3s, a distribution of Kubernetes aimed at lower power devices and people who do not need the power or have the knowledge about the full-fledged Kubenernetes, and my usecase ticks both of those boxes.

My general homelabbing plan for 2025 is to separate computer from storage, and this cluster fits into it well. So far I have deployed on the cluster Grafana for monitoring and Readeck for bookmark management. This way I can access those services even when my main, large NAS/server machine is not running. The plan is to have running on the cluster all the services that just run and do not need heavy resources. The NAS will then be only for services that require large storage or compute, like Immich for photos or Pinchflat for YouTube archiving.

I won't be diving into how I configured K3s or how I am deploying containers, I am a total noob at it so far, and there are tons of much better posts, written by infinitely more knowledgeable people, from which you can learn. Maybe at one point when I learn more and fix all my mistakes, I will write a longer post focusing on my Kubernetes journey.

Ansible

As I wrote in the introduction, having a cluster also encouraged me to dive deeper into Ansible. Ansible is one of those technologies that I've been going in and out with for many years now, and never really learnt it in depth. Now, with three identical computers I have more will to learn, as it can actually save me work to automate some of the tasks. (insert obligatory XKCD reference).

For example, I wrote a Ansible playbook that installs and runs Prometheus and Node Exporter agents on every Pi in the cluster:

- name: Install Prometheus and Node Exporter
  hosts: cluster
  become: yes 
  tasks:
    - name: Create a user for Prometheus
      ansible.builtin.user:
        name: prometheus
    - name: Create folder for Prometheus and Node Exporter
      file:
        path: /opt/prometheus
        state: directory

    - name: Upload Prometheus
      ansible.builtin.copy:
        src: ./prometheus
        dest: /opt/prometheus/
    - name: Upload Node Exporter
      ansible.builtin.copy:
        src: ./node_exporter
        dest: /opt/prometheus/
    - name: Upload Prometheus config file
      ansible.builtin.copy:
        src: ./prometheus.yml
        dest: /opt/prometheus/

    - name: Upload Prometheus service
      ansible.builtin.copy:
        src: ./prometheus.service
        dest: /etc/systemd/system/
    - name: Upload Node Exporter service
      ansible.builtin.copy:
        src: ./node_exporter.service
        dest: /etc/systemd/system/

    - name: Recursively change ownership of a directory
      ansible.builtin.file:
        path: /opt/prometheus
        state: directory
        recurse: yes
        owner: prometheus
        group: prometheus

    - name: Make Prometheus executable
      ansible.builtin.file:
        path: /opt/prometheus/prometheus
        mode: a+x
    - name: Make Node Exporter executable
      ansible.builtin.file:
        path: /opt/prometheus/node_exporter
        mode: a+x


    - name: Issue daemon-reload to pick up config changes
      ansible.builtin.systemd_service:
        daemon_reload: true

    - name: Enable Prometheus service
      ansible.builtin.systemd_service:
        name: prometheus
        enabled: true
    - name: Enable Node Exporter service
      ansible.builtin.systemd_service:
        name: node_exporter
        enabled: true

    - name: Make sure Prometheus is running
      ansible.builtin.systemd_service:
        state: started
        name: prometheus
    - name: Make sure Node Exporter is running
      ansible.builtin.systemd_service:
        state: started
        name: node_exporter

And with that, I can show the stats in Grafana running in K3s:

Yes, I know that I can also run Prometheus straight in K3s are get metrics about Kubernetes themselves, I have not reached that point yet :)

BOINC

And finally, BOINC. The Pis have been mostly idling, running only a few containers each, so I decided to use them for distributed computing. They won't do much but with BOINC, every little helps. I installed boinc-client on all three, and assigned them to do tasks for Asteroids@Home.

Thermals are an important issue when running BOINC, so I added a 120mm BeQuiet fan to the cluster. It's running from the USB port, so it's slow and quiet, but moves enough air to keep the Pis cool. To further keep the temps down, and also leave some compute for the K3s, I am only crunching on three of the four cores on the Pis CPU. So in total I am crunching on nine cores. The cluster in total crunches around 20 tasks per day.

Bottom Line

I believe that having a small cluster is a good addition to one's homelab. It not only allows you to tinker more with hardware, but also opens totally new possibilities when it comes to software and administrations. A single Raspberry Pi 4 can do quite a lot, but combined with others it can do even more, with an added bonus of high availability.

Maybe one day I will build such a cluster, not from Pis, but from USFF x86 PCs like the Lenovo Tiny? We will see.

This post has been all over the place. I hope you enjoyed it. In 2025 I have this idea to write more blogs posts that are not tutorials but more like, actually blog posts, where I loosely talk about me and what I'm up to.

Thanks for reading!

How much electricity does my home server use?

STFN — Sun, 19 Jan 2025 24:00:00 GMT

tl;dr

My home server idles at 70 watts.

Longer version

I started going deeper into the smart home rabbit hole, and one of the areas I want to investigate is the monitoring of power consumption. The smart home rabbit hole, which is something different than the smart rabbit home hole, which is the place where intelligent small mammals live. I've been reading a lot of Rubenerd lately and his writing style is getting etched in my brain. Anyway, for now the only use of measuring power consumption is my love of graphs and gathering data, but when at some point in the future I will have a house with a PV installation, having detailed power consumption, and production statistics will hopefully allow me to plan when to use power hungry devices.

But that is a bridge quite far downstream, for now I am focused on answering a relatively simple question: How much electricity is my home server using?

I specifically mention my home server, because the whole of my homelab consists of other devices as well, such as my Raspberry Pi Cluster. And there's also another mystery device about which I will talk in the next blog post :)

Home Assistant custom dashboard showing my home server power usage stats.

How am I measuring the power usage?

I decided to go with the Zigbee ecosystem. I chose Zigbee as it is not using WiFi, and it is an open standard adopted by many companies. Zigbee devices are small, relatively cheap, and low power. And Zigbee has native support in Home Assistant.

To use Zigbee you need a Zigbee gate, usually in the form of a small USB dongle plugged into the computer that has HA running. I'm using the Sonoff ZBDongle-E.

To measure the power consumption you also need a smart socket to which you plug the device you want to monitor. I went with a TUYA Zigbee 3.0 Smart Socket. It's a bit bulky, but I can live with that.

Setting up is very simple if you already know your way around Home Assistant. What needs to be done is to plug the Zigbee dongle, add the Zigbee Home Automation integration in HA settings, and then turn on pairing mode on the socket. It will be automatically detected and configured by ZHA. Then you can add it to the Energy dashboard, and le voila bonjour, energy stats on your screen.

My Home server

The full description of my home server can be found in the Story Of My Homelab subpage, but let's recap what's inside:

Intel Xeon 1275L v3 CPU, 4C8T, 45W TDP
Gigabyte Z97P-D3 Socket 1150 motherboard
32GB of DDR3 1600MT/s RAM in four sticks
four 3.5" HDDs from Seagate, WD, and HGST
single 2.5" SSD for boot
NVIDIA RTX2060
Seasonic 550W Bronze PSU

The GPU is power limited to 130W maximum, and idles at 25 watts according to nvidia-smi. The power supply is only bronze, as I bought it for a small Netfllix box, and only later I did I move it into my homelab. I wonder how much of a difference moving to a Gold one would make.

I use my home server mostly as a NAS, to store and serve all my files. There's a few Docker containers running on it, mostly services concerned with data, such as Immich or Pinchlat. The HDDs are using ZFS and are organized into two mirrors of two disks each. I also do occasionally some BOINC distributed computation, as for now it is my only PC capable of crunching BOINC tasks (I consider laptops not suitable for BOINC due to their poor cooling). BOINC uses CPU cores to their maximum all the time, so it is a good test of power usage under prolonged loads. It can also use the GPU in the same way.

How much power does it use?

After that rather long introduction, time for the data:

State	Power
idling	70W
BOINC with half CPU cores	120W
BOINC with all CPU cores	120W
BOINC with GPU	220W
BOINC with half CPU cores and GPU	240W

A few interesting things can be observed. First, there is no difference between crunching on all cores and half cores. I assume this is because the CPU is not able to reach boost speeds on all cores at the same time, and so it either boosts on half of the cores, or keeps lower clock speed at all cores. This is confirmed by the fact that BOINC tasks are crunched much faster per task when not all cores are used.

What is harder for me to explain is the little difference between crunching on GPU only, and on both GPU and CPU. I am suspecting some part of the PC is reducing power coming to both CPU and GPU to keep the overall power within a specific limit.

Bottom Line

In the next blog post I will talk more about my Home Assistant setup. I am also planning to add more power monitoring sockets to get a better understanding how much power do different devices use in my home. I wish I had one of those Zigbee power monitors that is hardwired in the fuze box to monitor the overall power of the whole house, but that is something for the far future.

Thanks for reading!

Using a Lenovo USFF PC as a Home Assistant box

STFN — Sat, 25 Jan 2025 24:00:00 GMT

Continuing the theme of a smart home, I wanted to talk about my Home Assistant setup.

During the Christmas break, when time does not exist and boredom is common, I was browsing the website of a company that sells cheap post-lease computer parts. What got my attention was the sale of a Lenovo Ultra Small Form Factor (USFF) PC with the price of 120 PLN. That is around 30 eur, and around half the price of a Raspberry Pi 4b here. So I yolo'ed and bought it right away. A week later it arrived.

The full model name is Lenovo M625q. And it is indeed very smol. The closest thing I can compare it to would be a Playstation 1 (yes, I am old), and it's still around half its size. The full specs are:

AMD E@-9000e CPU 2C2T @ 1.5GHz, 6W (!) TDP
4GB of RAM in a single DDR4 SDIMM stick
32GB M2 SSD
lots of I/O, USB, Display Port, audio

The RAM and SSD can be upgraded, the maximum RAM size it can handle is 16GB.

As for power and cooling, it uses an external PSU, and the cooling is fully passive, almost the whole motherboard is covered by a single large heatsink, which needs to be removed to access RAM and the SSD.

I was concerned that having just two slow cores on the CPU would be an issue, but for running just for a few services in a headless mode, I did not see any performance problems.

Lenovo M625q living under my book rack, with a Sonoff Zigbee dongle, and an external 2.5" drive.

Software

The PC came without an OS, so the first thing I did was to install Debian on it. The installation went without issues, I did not install any Desktop Environment as I am using it only in a headless mode. Next I installed the typical monitoring stack, Prometheus and Node Exporter, in order to have basic stats like temperature in my Grafana dashboard. Finally I went with installing Home Assistant.

Home Assistant provides several ways to be installed, the recommended one is to install the Home Assistant Operating System. I did not go this way, as I prefer to have a basic OS, and then go from it, installing the things I need. I also was not sure how much access and possibility to modify stuff I would have when running a custom OS. While running HA is the main aim of this PC, I also want to be able to install other stuff on it, like the just mentioned Prometheus, or Tailscale, or do NFS shares.

The HA installation as a service is called Home Assistant Supervised, and the installation process requires some knowledge of the Linux command line. Here is the full documentation on how to do it.

With HA being installed, I also installed Caddy to have a reverse proxy, so that I don't need to provide the port number when accessing the HA web UI.

The Caddy reverse proxy config is super simple:

http://ha.local {
reverse_proxy :8123
}

BTW, I have a full post on using Caddy as a reverse proxy in a homelab.

Home Assistant integrations

First thing I did after the initial setup of HA, was to add all my ESPHome temperature/humidity/pressure sensors , which now I have three, each for one room in my flat. HA found and pair them right away, and what was left for me was to assign them to the Zones (bedroom, office, living room).

Next thing was adding the TUYA integration for my single TUYA WiFi smart light bulb. Also no issues, I had to find the TUYA integration in the integration list, and put the light bulb into pairing mode.

put the light bulb into pairing mode

Imagine saying such words to a person twenty years ago.

With that out of the way, came the big part: Zigbee. Zigbee is my new craze, I am still amazed how cheap and low power its devices can be, and as it is using its own protocol, Zigbee does not clutter WiFi. As I said in my previous post about smart sockets , for Zigbee you need a gateway, usually in the form a Zigbee USB dongle. I bought one and plugged into one of the oh-so-many USB ports on the Lenovo box.

Configuring ZHA (Zigbee Home Integration) was also a breeze. In overall I am amazed how simple the whole process is, things just work.

I also reused my IKEA Tradfri lightbulbs that I used to connect to a TRADFRI gateway, the old one looking like a white hockey puck. My wife is now happy that she turn off the bedroom floor lamp from her bed :)

I don't have any automations set up yet, but once I get more Zigbee devices, I might start writing them. Maybe moving a detached house will be an inspiration to make some.

My HA overview dashboard. It's in Polish but I'm sure you can guess what it what.

To sum up, I now have a dedicated Home Assistant box, that uses barely any power, is small enough to sit under a bottom shelf of my book rack, is completely silent, and can handle any number of external devices and sensors. I do not know yet its power usage, but I would say its irrelevant.

Lenovo USFF vs Raspberry Pi

Now let's talk about the elephant pie in the room. Please don't make pies from elephants.

What about a Rapsberry Pi? This question is even more relevant today, as the Pi 5 16GB was just released, so the Lenovo USFF and the Pi could be equal in terms of memory.

I could have used a Raspberry Pi for this. But I did not. I believe using a Pi for this specific usecase does not make sense. Of course Pis are great little devices, and they have their usecases, but this is not one of them.

Pis are perfect when you are really constrained in space and power. A great feature of a Pi, often overlooked, is that it can be put in a very remote place, on the roof, in the shed, and powered from a distance using Power over Ethernet. Or even a battery and a solar panel. A Pi has GPIOs to plug small sensors directly. And a Pi is a standard. When you buy a Pi, you have the exact same device as tens of thousands of other people, and when you ask a question on social media, you know that there will be people having the exact same experience/problem as you. Pis are also great when you want to make a small cluster of devices, as the one that I have.

But for general computing, just running stuff in a typical flat, close to a power socket? Those Lenovo USFF simply win the comparison. There are much cheaper (again, 30EUR! A Pi 5 16GB is 130EUR, and that is without the case and the power adapter!), and have expandable storage and RAM. And they are x86, not ARM. With the proliferation of ARM-capable software and Docker containers, that is becoming less of an issue, but there is still software that will just not run on an ARM device.

So, what do I choose? Both! There will always be cases where I prefer to use a Pi, and in other ones such tiny PCs will be the way to go.

And that for now wraps the theme of my home becoming smart (in contrast to myself).

Thanks for reading!

If you enjoyed this post, please consider helping me make new projects by supporting me on the following crow

Powering PC fans from a USB port to cool my Raspberry Pi Cluster

STFN — Sat, 01 Feb 2025 24:00:00 GMT

I have a Raspberry Pi cluster (citation needed). One of the uses for it is crunching BOINC. Running the BOINC daemon means that the Pis' CPUs are constantly running at almost 100% load. And so they make a lot of heat. The Pis are powered by POE+ HATs, which also produce heat themselves and at the same time restrict airflow. The HATs have their own fans, but those are noisy when they ramp up. All in all a situation far from perfect. A solution for that issue would be an additional source of cooling to make my cluster run quietly and reliably.

I could use those 5V tiny fans that are sold as dedicated for the Pi, but those are also whiny as a far-right person seeing happy people. And the HATs obstruct the GPIO pins, so that is not the way.

What I realized is that a cluster of three Pis has the height and the width of a typical 120mm case fan. And I have such a fan, leftover from the desktop PC I used to have.

I have a fan-header to 2.1 x 5.5mm barrel adapter that I bought during one of my Aliexpress-weird-stuff-under-dollar shopping sprees, and I used it to cool my Pis when I was doing BOINC Pi 5 vs Pi 4 testing.

But that was only a temporary measure, before I had the PoE HATs. Now I want a long-term, quiet fix, and no other cables coming to the Pi cluster apart from the Ethernet ones.

The solution dawned on me when I realized that the fan header has the same pin distance as any other pin header, be it on a Pi, any other microcontroller, or a breadboard. Which means I can just make my own adapters, and run them from USB. USB provides 5 volts, which means that a typical 12V would run slowly and quietly, while still providing some airflow.

And so I created my own USB-to-fan adapter.

Version 1.0

The first version was basically the USB-A connector and two pins connected by short lengths of cables. I was not happy with it, because the USB pins turned out to be very fragile, they would move with every touch, and I was concerned what would happen when 5V would short out with a data pin. I don't know the USB specs enough* to know what would be the outcome of that.

Version 2.0

For version 2.0 I used a prototype board to securely solder all four pins of the USB connector, and so have the adapter more sturdy and safe. The additional advantage here is that it can power more than one fan, the only limitation is the maximum current a Pi can provide on a single USB port*

The build process is very simple. I took a prototype board, I have some with the perfect size, 6 pins wide. I cut it in half, and soldered the USB connector to one side of it. In a USB-A connector, there are four pins, the middle two ones are data, and the outer ones are +5V and GND.

I then soldered two pin headers of two pins each, with spacing between them to fit the fan connectors.

Finally I connected the USB pins with the fan pins using wire I had left from soldering some LEDs.

The important thing is to make sure that there is no short circuit, and the data pins are not connected to anything.

I first tested it using my cheapest powerbank, in case I did something very bad. It's better to burn a cheap powerbank rather than an expensive Pi. But in my case there was no magic smoke, just a large fan running quietly. After letting it run for a while I took the connection of faith, and connected the whole contraption to one of the Pis in my cluster.

And hey, it works like a charm, there are no additional cables coming from the cluster, the fan is running, the Pis are cool as a cucumber*, and all is fine in the world (if you ignore the news from a certain Western superpower).

The adapter from the top...

...and from the bottom. Yes, I know my soldering is bad.

And from the side.

Powering two 5V fans.

And doing what's it intended for. I still need to tidy the fan cable, and maybe secure the fan to the cluster case.

One more thing, this board is universal enough that it can power anything that uses 5V and can use typical 2.54mm pins.

I know, it's not something groundbreaking, not specially interesting, but it does what it's intended to do, and I am happy with it. And it is a good day when I can use my ~AK~ soldering iron.

Thanks for reading!

* at all.

* It's 1.2A for a Pi 4b, but it shared among all USB ports. So one port can provide 1.2A, but then the other ports are left with nothing. Or two ports can provide 0.6A each, etc, etc.

* Is any native speaker actually using this phrase, or is it just something that every foreign learner of English has to memorize?

Using Pinchflat and Jellyfin to download and watch Youtube videos

STFN — Mon, 03 Feb 2025 24:00:00 GMT

This post is in a way an extension of my previous one about Pinchflat.

Pinchflat is a service to download Youtube videos to your local hard drive. I have been using it for quite some time now to download videos from my favourite YT channels.

There are a few reasons why I download Youtube videos. One of them being data preservation. As I wrote before, nothing on the Internet is permanent, and we should never assume that the content we enjoy will be there forever. Secondly, watching videos locally removes all the bloat, ads, comments, recommendations, it's just a video file that you can watch however one wants. And finally, at some point in the future it will be highly possible that I will be living on limited LTE internet, and I want to hoard content locally for that hard period.

I won't dive again into Pinchflat installation and configuration, I described it in detail in that previous post, today I want to focus on serving data downloaded with its help.

But I have a few observation after using it for months.

The first one is that Pinchflat downloads shorts by default, if you don't want them, you need to turn it off manually in the Source settings.

Youtube sometimes gets annoyed when Pinchflat tries to download too many videos at once. If that happens, the best solution is to shutdown the container and wait a few hours. After turning it back again, the videos should continue downloading.

To stop it from happening in the first place, one solution is to download the videos in parts. Pinchflat allows to provide a cut off date for a feed, and with that it will not download videos older than that date. When I add a new channel, I set the cut off date for a few months from now, wait for those videos to download, then wait a few hours, move the cut off date further to the past, download the videos, etc, etc.

Download cut-off date in the Source settings

Now the Jellyfin part. I have Pinchflat and Jellyfin running both on my NAS. They both have access to the same ZFS pool where I store all my videos. In Jellyfin I have a separate library for my Youtube videos. In my experience the best library type for those videos is "Home Videos and Photos". At firsts I was using "Shows", but then Jellyfin would try to divide the videos into seasons, which does not make sense for the content that I watch.

Jellyfin does a rather good job in creating thumbnails for videos, there were only a few times where I had to provide my own to make my library look pretty.

My Youtube library in Jellyfin

Also Jellyfin and Pinchflat are a good duo, as both automatically refresh, so new videos appear in the library without any human intervention. If you watch only a limited set of channels, with the combination of Pinchflat and Jellyfin you could never need to visit the Youtube's page at all.

Let's hope that Youtube will not find a way to block third party software, at least in the near future. Until that, let's fill our hard drives :)

Looks like that's it, a super short post this time, but I wanted to share my process that I am happy with.

Blog Question Challenge 2025

STFN — Sat, 08 Feb 2025 24:00:00 GMT

I felt like also giving a go at this challenge. The replies I read at other peoples' blog were very interesting, thank you all for sharing your life <3

Why did you start blogging?

I enjoy sharing knowledge. I think it runs in the family, as both of my parents are teachers. Also I enjoy connecting with people online. I've been living on the Internet since forever, and all that time I enjoyed not only ingesting media, but also contributing to it. Internet forums were the first place. Then it was the time of the centralized massive platforms. And now as the Internet is becoming a place both too centralized and too hostile, I went to my own platform on my own terms.

And this XKCD feels very close to me.

What platform are you using for your blog, and why?

As I said in the previous question, I moved to selfhosting to be free from centralized, commercial platforms on which you are just the product, lead by an impenetrable algorithm. I prefer the small, "indie" web. This blog is made using Astro, a static site generating framework, and I have used a ready-made template to start. The HTML is hosted on a VPS I am renting, and I am serving it using nginx. A very simple tech stack, but thanks to its simplicity it can handle a lot of traffic with very little means. Mastodon requests flooding does not really register on the load scale.

Have you blogged on other platforms before?

Yes, I used to have a personal/photography blog on Wordpress, but it went into an indefinite hiatus many years ago.

How do you write your posts?

Mostly in VSCode, but recently I started moving to nvim, as it provides a much cleaner and less distracting environment.

When do you feel most inspired to write?

When I learn a new skill, or I create something new. Or when I am reminded of something that I used to be very much into, and I feel like sharing that history. So in short: whenever inspiration strikes :)

Do you normally publish immediately after writing, or do you let it simmer a bit?

Depends on the type of the post. If it more like musings, or talking about feelings or memories, I usually publish it at once, only after a second read. If it is more technical, tutorial-like, then I spend more time polishing it, re-reading after some with a fresh mind, doing corrections.

What’s your favourite post on your blog?

I would say those two:

Reducing Raspberry Pi Pico W power consumption and a second attempt at using solar panels

The Space Shuttle - how I remember it

The first one because I put a lof of effort into the project, the testing and I was very happy of the outcome. And it reminds me of long summer days.

The second one because it is very personal and I talk there about something that has been an important thing for me for a significant period of my life.

Also those two posts show the spectrum of my writing, from personal "memoirs", to technical/DIY tutorials.

Any future plans for the blog?

For this one nothing specific. I am thinking of starting another blog, in Polish, that will be much less technical, tackling subjects that are local to me, more personal, things that would not work for a global audience. I still cannot decide on its name, though.

Python Dependency injection for cleaner I/O handling

STFN — Mon, 10 Feb 2025 24:00:00 GMT

Apart from these few posts about simple things in MicroPython, this is the first post on this blog in which I talk about programming in Python in a slightly more advanced way.

My official job title is "Senior Python Developer", and I feel that I do have some experience in working with Python, but I've never before felt that I had something interesting enough to share on this blog in that area. And of course there is the whole matter of impostor syndrome, making me doubt whether what I know and use is actually the best thing that should be shared with others. But there can always be a first time, right?

In this blog post I want to share a way of writing code that I was taught by a super cool senior developer. She taught me a lot of things, mostly in terms of ideas of how software should be written. I think this is one of the things that differentiates junior developers from senior developers. Juniors think in code, like "I'll put a for loop here" or, "I should do a class here", whereas seniors know and think in ideas, "our software needs to be better separation of concerns", or "we are breaking the single responsibility principle in this place". Learning to think in abstract ideas and knowing ways to implement it is imho an important part of one's programming journey.

Fans of Clean Architecture should recognize some concepts from it in this blog post. CA is something I have barely scraped the surface of, but I am already a big fan of it and I try to implement it as best I can in my software. Maybe one day, when I get better at it, I will write another blog post focusing on it.

OK, the intro is done, let's go to the main part.

Setting the stage

Let's imagine a scenario that you are at work, and your boss comes to you and says

You need to create a piece of software that will download a joke about Chuck Norris, and count the number of times a specific word is used in that joke. That functionality is absolutely crucial for our business!

Weird but ok. The actual usefulness of this code is irrelevant, what we should focus on is how it works. What is important is that the code needs to have two distinct functionalities: business logic (counting the number of occurrences of a word) and input/output handling (external API calls).

You are a good developer, so you sit down to work and create a class that does what it should, and add tests. You should always have tests for your code.

The code is available at codeberg.org

First solution

main.py

import httpx


CHUCK_NORRIS_API_URL = "https://api.chucknorris.io/jokes/"

ID1 = "a4aNCYsKQu-4LKDLkTQLSA"


class ChuckNorrisJokeWordCounter:
    def _download_joke(self, id: str) -> dict:
        url = CHUCK_NORRIS_API_URL + id
        return httpx.get(url=url).json()

    def word_counter(self, word: str, id: str) -> int:
        print(f"fetching joke with id {id}...")
        joke_data = self._download_joke(id=id)
        joke_text = joke_data["value"]
        print(f"downloaded joke with content: {joke_text}")
        return joke_text.count(word)


if __name__ == "__main__":
    chuck_word_counter = ChuckNorrisJokeWordCounter()
    word_count = chuck_word_counter.word_counter("Chuck", ID1)
    print(f"in that joke, the word Chuck was found {word_count} times")

test.py

from httpx import Response

from main import CHUCK_NORRIS_API_URL, ChuckNorrisJokeWordCounter


def test_counting_words_chuck(respx_mock):
    id = "123qwe"
    response_data = {
        "categories": [],
        "created_at": "2020-01-05 13:42:26.766831",
        "icon_url": "https://api.chucknorris.io/img/avatar/chuck-norris.png",
        "id": id,
        "updated_at": "2020-01-05 13:42:26.766831",
        "url": f"https://api.chucknorris.io/jokes/{id}",
        "value": "Chuck Norris once cast a fishing line into the Atlantic Ocean and caught 243 fish...then the hook hit the water",
    }
    mock_response = respx_mock.get(CHUCK_NORRIS_API_URL + id)
    mock_response.return_value = Response(200, json=response_data)

    chuck_word_counter = ChuckNorrisJokeWordCounter()
    word_count = chuck_word_counter.word_counter("Chuck", id)

    assert word_count == 1


def test_counting_words_norris(respx_mock):
    id = "123qwe"
    response_data = {
        "categories": [],
        "created_at": "2020-01-05 13:42:26.766831",
        "icon_url": "https://api.chucknorris.io/img/avatar/chuck-norris.png",
        "id": id,
        "updated_at": "2020-01-05 13:42:26.766831",
        "url": f"https://api.chucknorris.io/jokes/{id}",
        "value": "Chuck Norris once cast a fishing line into the Atlantic Ocean and caught 243 fish...then the hook hit the water",
    }
    mock_response = respx_mock.get(CHUCK_NORRIS_API_URL + id)
    mock_response.return_value = Response(200, json=response_data)

    chuck_word_counter = ChuckNorrisJokeWordCounter()
    word_count = chuck_word_counter.word_counter("Norris", id)

    assert word_count == 1

Let's run it:

python main.py
>>> fetching joke with id a4aNCYsKQu-4LKDLkTQLSA...
>>> downloaded joke with content: Chuck Norris once cast a fishing line 
>>> into the Atlantic Ocean and caught 243 fish...then the hook hit the water
>>> in that joke, the word Chuck was found 1 times

The code works, but there is a number of issues with it, that are best visible when reading the tests.

The class ChuckNorrisJokeWordCounter is doing two things: downloading the joke from some HTTP API, and doing the business logic, which is counting the number of times a certain word is used in the joke. Therefore, each time we want to test the business logic, we need to mock the API call. This results in a lot of boilerplate code, and worsens the readability of the tests. You can reduce the amount of code using fixtures, but still, this is not great.

And, what if one day the Chuck Norris API moves from HTTP to say, downloading jokes as txt file from S3? Or being sent by Matrix-style neural link? Then we would need to rewrite the download logic inside the class, modify all the tests, etc. Not good. This can be done better.

Second solution

And here is another way to do it:

main.py

from typing import Protocol
import httpx


ID1 = "a4aNCYsKQu-4LKDLkTQLSA"


class ChuckNorrisJokeClientProtocol(Protocol):
    def get_joke(self, id: str) -> dict: ...


class ChuckNorrisJokeHTTPClient:
    CHUCK_NORRIS_API_URL = "https://api.chucknorris.io/jokes/"

    def get_joke(self, id: str) -> dict:
        url = self.CHUCK_NORRIS_API_URL + id
        return httpx.get(url=url).json()


class ChuckNorrisJokeWordCounter:
    def __init__(self, client: ChuckNorrisJokeClientProtocol):
        self.client = client

    def word_counter(self, word: str, id: str) -> int:
        print(f"fetching joke with id {id}...")
        joke_data = self.client.get_joke(id=id)
        joke_text = joke_data["value"]
        print(f"downloaded joke with content: {joke_text}")
        return joke_text.count(word)


if __name__ == "__main__":
    chuck_word_counter = ChuckNorrisJokeWordCounter(client=ChuckNorrisJokeHTTPClient())
    word_count = chuck_word_counter.word_counter("Chuck", ID1)
    print(f"in that joke, the word Chuck was found {word_count} times")

test.py

from httpx import Response

from main import ChuckNorrisJokeWordCounter, ChuckNorrisJokeHTTPClient


def test_chuck_norris_http_client(respx_mock):
    id = "123qwe"
    response_data = {
        "categories": [],
        "created_at": "2020-01-05 13:42:26.766831",
        "icon_url": "https://api.chucknorris.io/img/avatar/chuck-norris.png",
        "id": id,
        "updated_at": "2020-01-05 13:42:26.766831",
        "url": f"https://api.chucknorris.io/jokes/{id}",
        "value": "Chuck Norris once cast a fishing line into the Atlantic Ocean and caught 243 fish...then the hook hit the water",
    }
    mock_response = respx_mock.get(ChuckNorrisJokeHTTPClient.CHUCK_NORRIS_API_URL + id)
    mock_response.return_value = Response(200, json=response_data)
    http_client = ChuckNorrisJokeHTTPClient()

    response = http_client.get_joke(id=id)

    assert response == response_data
    assert mock_response.called


class ChuckNorrisJokeMockClient:
    def get_joke(self, id) -> dict:
        return {
            "categories": [],
            "created_at": "2020-01-05 13:42:26.766831",
            "icon_url": "https://api.chucknorris.io/img/avatar/chuck-norris.png",
            "id": id,
            "updated_at": "2020-01-05 13:42:26.766831",
            "url": f"https://api.chucknorris.io/jokes/{id}",
            "value": "Chuck Norris once cast a fishing line into the Atlantic Ocean and caught 243 fish...then the hook hit the water",
        }


def test_counting_words_chuck(respx_mock):
    id = "123qwe"

    chuck_word_counter = ChuckNorrisJokeWordCounter(ChuckNorrisJokeMockClient())
    word_count = chuck_word_counter.word_counter("Chuck", id)

    assert word_count == 1


def test_counting_words_norris(respx_mock):
    id = "123qew"
    chuck_word_counter = ChuckNorrisJokeWordCounter(ChuckNorrisJokeMockClient())
    word_count = chuck_word_counter.word_counter("Norris", id)

    assert word_count == 1

A lot has changed, so let's go through the code slowly.

class ChuckNorrisJokeClientProtocol(Protocol):
    def get_joke(self, id: str) -> dict: ...


class ChuckNorrisJokeHTTPClient:
    CHUCK_NORRIS_API_URL = "https://api.chucknorris.io/jokes/"

    def get_joke(self, id: str) -> dict:
        url = self.CHUCK_NORRIS_API_URL + id
        return httpx.get(url=url).json()


class ChuckNorrisJokeWordCounter:
    def __init__(self, client: ChuckNorrisJokeClientProtocol):
        self.client = client

There are now two classes, ChuckNorrisJokeWordCounter and ChuckNorrisJokeHTTPClient. The HTTPClient is only responsible for doing the API HTTP calls. The CHUCK_NORRIS_API_URL constant was moved to inside that class, as it is only applicable to it.

The ChuckNorrisJokeWordCounter class accepts a class as an argument, a class which needs to adhere to the ChuckNorrisJokeClientProtocol. This is exactly the Dependency Injection part. The WordCounter class depends on a client that will provide it with the joke, and that dependency is injected in the class' constructor. The WordCounter does not care from where the joke is fetched, as long as it can fetch it using the public get_joke() method. The WordCounter knows that this method is available because it is in the protocol.

    def word_counter(self, word: str, id: str) -> int:
        print(f"fetching joke with id {id}...")
        joke_data = self.client.get_joke(id=id)
        joke_text = joke_data["value"]
        print(f"downloaded joke with content: {joke_text}")
        return joke_text.count(word)

And now in the business logic part, the WordCounter can just use the client's get_joke() method by calling self.client.get_joke().

The code could be further improved by defining a Pydantic Model called ChuckNorrisJoke to which the get_joke() output would be serialized, but that is outside of the scope of this post. For this example let's just assume that we know that the get_joke() method always returns a dict with a key value.

By doing this change we have fixed the code in two ways:

First, it now adheres to the first principle of SOLID: Single responsibility principle. Each class does only one thing.

But wait, there's more! The code now also adheres to the second principle of SOLID: Open–closed principle.

The code is now "open for extension, but closed for modification". The WordCounter class word_counter method can be left unmodified, and if at one point we will need to fetch the jokes from another source, we can just write another client, for example ChuckNorrisFTPClient that will expose a get_joke() method downloading jokes from an FTP server.

And now the tests.

The tests are now in two groups. The first group (here there's only one test for it, but in real life there would of course be a lot more) is responsible for testing the ChuckNorrisJokeHTTPClient itself, and those tests still need to mock out external API calls.

The second group is the cool part:

class ChuckNorrisJokeMockClient:
    def get_joke(self, id) -> dict:
        return {
            "categories": [],
            "created_at": "2020-01-05 13:42:26.766831",
            "icon_url": "https://api.chucknorris.io/img/avatar/chuck-norris.png",
            "id": id,
            "updated_at": "2020-01-05 13:42:26.766831",
            "url": f"https://api.chucknorris.io/jokes/{id}",
            "value": "Chuck Norris once cast a fishing line into the Atlantic Ocean and caught 243 fish...then the hook hit the water",
        }


def test_counting_words_chuck(respx_mock):
    id = "123qwe"

    chuck_word_counter = ChuckNorrisJokeWordCounter(ChuckNorrisJokeMockClient())
    word_count = chuck_word_counter.word_counter("Chuck", id)

    assert word_count == 1

No need to mock HTTP calls anymore. The WordCounter accepts any Client as long as it exposes a get_joke() method, right? So we can write a mock client that just returns a dictionary. The WordCounter can then take that client, and it will have no idea, nor will it care that we are handling it just a dict saved in a file. And we can have as many mock clients as we want, providing different jokes, or providing broken replies, etc.

The tests are now much cleaner, easier and quicker to write. There is much less underlying logic (Explicit is better than implicit).

Summing up

This concept can be applied whenever there is code that needs to do fetching data from somewhere, and then do business logic on it.

A very good example of it, about which I might write in the future, is doing database calls, for example in Django.

In that case, a ChuckNorrisDBClient could be written that does something like

from .models import ChuckNorrisJoke

class ChuckNorrisJokeDBClient:
	def model_to_dict(self, model_instance) -> dict:
		# some logic to deserialize model instance to a dictionary
		# again, Pydantic would also be great here
		return model_dict

	def get_joke(id: str) -> dict:
		return self.model_to_dict(ChuckNorrisJoke.objects.get(id=id))

And then in the test we would again use a ChuckNorrisJokeMockClient which does not use the DB at all, making the test suite much quicker to run.

And that's it! My first post on "advanced Python". I hope you liked it, I would love to receive feedback on it by any means possible, whether a comment below, a mention in the Fediverse, or via email. The links are in the footer.

Now that I wrote this post, I feel like writing more posts like this, so there is a high possibility this will not be the last one :)

Thanks for reading!

Blog Questions Challenge Technology Edition

STFN — Sat, 15 Feb 2025 24:00:00 GMT

I was tagged by 82Mhz to answer this set of questions, so here it goes:

When Did You First Get Interested In Technology?

I've been interested in technology as long as I remember. I think there were multiple sources of this.

First one would be my grandfather, who as a child growing up in hard times, had to have a wide set of skills. Today he could be called a tinkerer and a maker. He showed me how to fix things at home, how to sculpt in wood. He is 90 now and uses a smartphone to read the news, and a laptop to write books and emails.

Second one would be my father, similar in his skillset to my grandfather. He was also an avid collector of "Młody Technik" (Young Technician) magazines from the 80s. I would spend the summers reading them, they had a wide range of articles on anything regarding technology, from 80s computers to helicopters, ships and trains. A few of them had lessons in writing C! My dad also gave me both sci-fi and non-fiction science books, further fueling my love for technology.

He bought our first PC when I was around 9, and I was instantly hooked. At first that PC had only DOS, so I had to learn the command line to run the first computer game I ever played: Mahjongg.

It's funny that despite all this, in my teens I never envisioned my career to be connected with technology, and I only switched careers to become a software developer in my thirties.

What’s Your Favourite Piece Of Technology All-Time?

That is a very hard question, because what exactly is a piece of technology. Does an anvil count? A knife? Having so many options makes it hard to chose between, for example, the Space Shuttle and a lathe.

But to keep it light and short, I will say that my answer is: trains. I like trains. Trains are cool. I take the train whenever it is possible. I haven't had the chance to take a high speed train (160kph+) yet, but I hope it will happen sometime in the future.

What’s Your Favourite Piece Of Technology Right Now?

Another hard question, but ok, let's try: Renewable energy sources.

Wind turbines and solar panels are a game changer, and give me hope for the future. Not only because the energy they produce is green, but also because it is localized and personal. I can, and will have solar panels on my future house, and with a battery they will will be independence from the grid. The other thing is, I love the sight of wind turbines over the fields. They look so magnificent, slowly turning in the wind, and not belching smoke. Down with the coal and oil, renewables are the future (and nuclear, but that is another story).

Name One New Cool Piece Of Technology We’ll Have In 25 Years!

I wish that in 25 years we will still be using our current technology. I wish things, machines, computers, electronics in general, were made to last. In many areas like smartphones, technical progress is now mostly fake, and aimed at forcing people to buy new stuff. This, connected with planned obsolescence, only increases waste and energy usage. How great it would be if you could use a washing machine that was made today for 25 years? Or a smartphone, or a tv. And then it could be fully recycled and used to make new copies of it. Circular economy. Degrowth. That would be the coolest thing.

Final Thoughts

Thanks for reading! I am not tagging anyone specifically, but please feel encouraged to also answer those questions, and send me your blog post :)

I'm going back to astrophotography

STFN — Wed, 19 Feb 2025 24:00:00 GMT

I'm slowly going back to astrophotography.

So far my best year in AP was 2022 (apart from the famous comet), as my Astrobin gallery shows.

Since then I either have not had the time, or the energy, or the weather was awful for weeks. Also the last year or so I have been fighting with equipments problems, stopping me from doing any useful work.

But I'm coming back, I want to come back and do it again, as I find it to be a fascinating hobby, combining space, physics, and computers.

The future looks promising, as (if everything goes well) I will be moving to a house at the end of his year, and then doing AP will mean simply going outside, and not needing to drive 30km to a good place. That should make things much simpler.

Back to present, I went out to try doing AP again twice in the last week, three days ago and yesterday. While the equpiment problems are still not solved, I managed to get at least something, and I quite like the result. So let me share it with you (looks better in dark mode, click for a larger version):

This is the Alpha Persei Cluster, an open cluster of stars in the middle of the constellation of Perseus.

The brightest star near the middle is Mirfak, Alpha Persei. Most of the bright stars in the picture belong to the same cluster (group) of stars, living relatively close to each other. I especially like σ Persei (delta Persei), the one closer to the left of the image, with its beautiful, deep yellow colour. The whole cluster is around 560 light years from us.

I took the information above from Wikipedia, and I invite you to read more on the cluster on its Wikipedia page at that site that we need to cherish and it's again attacked by right wingers, as most good things in life.

the parts below will mostly be interesting for people deep into AP

Acquisition details

Lens: Irix 150mm f/2.8 lens, wide open.
Camera: QHY 168C with an IR filter.
Mount: iOptron GEM28.
Additional: Astrojolo Astrolink 4 and dew heater for the lens
Acquistion control: Raspberry Pi 5 with Stellarmate OS.
Guiding (not used): ZWO ASI 120MC-S with ZWO mini scope

90 x 60s exposures. Acquisition controlled using Stellarmate OS, and EKOS in kStars. Calibration frames: flats and bias (I need to redo my dark library).

Stacked in Pixinsight using FastBatchPreprocessing.

Postprocessing:

BlurExterminator
Graxpert - background extraction
Graxpert - denoising
SPCC
SCNR
Statistical Stretch from SetiAstro scripts repository

A touch of curves and saturation in GIMP.

Equipment problems

The problem is simple: I cannot guide. The most frustrating part is that guiding used to just work for me in the past, and now it does not.

Since guiding stopped working, I replaced the guiding camera, most of the cables, the Raspberry Pi and the OS from Astroberry to Stellarmate. I've sent the mount to a person who services mounts and said everything was fine with the mount, except for a loose cable (which I already replaced). The last hardware thing for me to test is to replace the "telephone" cable between the mount and the mount pilot, and I will do it as soon as RJ12 connectors arrive by post.

Both in EKOS and PHD2, the guiding calibration cannot finish, as the software is not able to move the mount enough. Slewing is working fine, GOTO too. Mount is connected, the guiding camera is doing the images. Polar alignment is as precise as it is possible, done with the polar alignment helper in EKOS. The mount is tracking, I can do 60s exposures at 150mm focal length without issues. But when it comes to the actual guiding, nothing happens. Calibration fails and guiding does not work.

I've digged through the web several times, and other people seemed to have similar issues, but their solutions did not help me.

I think I just need to spend the night doing debugging, testing all possible combinations of settings. I have this feeling that the actual cause is very basic and would be obvious to many people, but I don't have anyone experienced in AP who would join me on site. And to do actual, proper debugging I need to sit next to mount without haste for a long time, which is not the easiest thing when it's -10C outside.

If I don't find a solution anytime soon, I will probably write a few long posts on some internet forums, not sure which one, either the INDI one, or the one for Stellarmate, or astropolis.pl (the one which I usually visit).

Eh, anyway, it's good to have a blog, at least I can vent my frustrations here :)

But on the other hand, even with all those issues, being under a night sky in the dark, and just watching it is a joy. I have a pair of cheap binoculars, and for the price they show me wonders. It is a very calming experience and makes me want to go back and try again, and even if I cannot take a good picture, I can at least take a good look.

Thanks for reading!

This post is very political, but then again, all the previous ones were too

STFN — Thu, 06 Mar 2025 24:00:00 GMT

FIX TUBE URL

I don't have anything to write about computers for now. Not much is happening for me on this field. My homelab is still homelabbing, BOINC is being crunched, my Pi cluster is running, things are going their own course.

But I have this growing frustration about the state of world affairs and this is the place where I can vent it.

But STFN, this is a blog about technology, don't add politics to it, some of you might say. To which I reply: I do not believe in the separation of politics and technology.

Everything we do with technology is connected with politics. The decisions we make in IT are, well, I don't really want to talk in absolutes, so I will use the word "often", often are connected to our worldview, and from our worldview come out political beliefs.

Why do I talk about selhosting Immich and not giving away all my photos to Google Images? Because I don't like capitalism and corporations. Why do I talk about the Fediverse and GoToSocial, and not praise Twitter or TruthSocial or any other nazibar dot com? Because I believe in grassroot movements, in community, in the left-wing self-organisation. Also because of my political beliefs I give my GPU to scientists with BOINC, and not to crypto scammers.

So yes, this blog is political.

A few days ago I was listening to a podcast where Wojtek Żubr Boliński was talking with a game designer, and one of their topics was the accusation that some people raise, that modern games are "political" or even "woke" (woke is absolutely the most pointless, stupidest, umbrella term for "anything I don't like") and their conclusion was that games have always been political, since their beginnings, it's just that people did not see it. Their politics have been invisible because they were of the kind that have been permeating the global life for the last decades, US good, third countries people bad, liberty good, money good, men strong, damsels in distress.

And now when some games try to break that sanctified consensus, "the gamers" are enraged because "the games are being taken over by the woke politics".

And same with other types of media. I never watched Thunder in Paradise like Wojtek did, but I was a big fan of the A-Team. When I was 8 or so I liked it because funny guys and machine guns and explosions, but when you think about it, it's highly political and leftist. A group of people hiding from the government, helping, for the lack of the better term, the working class from oppression.

Sigh. I don't have a smart point here, again, just venting.

Now to other things.

I cannot reiterate how much I hate Trump and I hate Musk and I hate JD Vance and their lackeys*. For many reasons, but currently the main reason is the ongoing war.

The Western World, if we even can still use that term, should do everything they can to help Ukraine fight Russia. Not only for the obvious fact that Ukraine is an independent country and has every right to exist and prosper. But also because Russia is an aggressive, genocidal regime that will not stop at Ukraine if it falls. Eastern European countries have been invaded by those fuckers many times, and it's obvious they want to do it again. And Trump trying to be friends with Putin over our heads is the worst possible scenario.

And then there's Europe. The current situation, paradoxically, is a chance for Europe to finally stand on it's own and not depend on the chaotic uncle from the other side of the Atlantic. I have a very strong belief that the European Union is the best thing to have happened to Europe in its history, and the only way for Europe to move forward, to survive even, is much closer cooperation, both commercial and military. We need a common army, a common market, and buy goods locally, not import goods from China and technology from the US. We need our own services as we have Galileo, our GPS alternative. In a way, I am becoming more and more a European nationalist.

But then there are the morons from the European far right movements, gaining ground and talking in the voice of Kreml and Trump (which is now basically the same), saying that the EU is bad, and Europe should again be just a bunch of small, isolated, chauvinist countries. That worked out very well in 1914 and 1939, didn't it? Brexit worked out great for the UK, didn't it?

Here in my country Konfederacja, a local far-right movement is now getting 20% of the votes in the polls, and they candidate for the president is third in the polls.

I cannot imagine why would anyone vote for the far right, but looks like I am in the vast minority (vast minority? is that a phrase?), as the party I vote for, the reasonably lefty RAZEM is constantly below 5% in the pools.

This is all so frustrating. A few weeks ago I started reading a very smart book, "Our Modern Crisis" by Murray Bookchin, but I left it, I was too tired, I need something to get my mind of the world, so I started reading The Expanse. Which of course is also very much political but in a different way :)))

There are so many other things in today's world that make me sad or frustrated or angry or everything in between, but I'll leave them for other posts, not everything at once :)

To end this post with a silver lining, there are things that make me feel better. To list just two, in no particular order:

There's Solarpunk, a movement based on hope and self-organization and nature. I haven't yet read much works of writing based in that idea, but I'm just happy it's there. One day I will wrote more on it.

We are solarpunks because optimism has been taken away from us and we are trying to take it back.

And then there are the European Alternatives, a page showing all the ways one can move their IT life from those Silicon Valley guys to better lands.

This is the first blog post of this kind here, but I am sure there will be another ones.

You can leave me a comment here or reach out to me via email or the Fediverse, links in the footer.

Thanks for reading!

*the word lackey always reminds me of Simcity2000, because it was often used there in those newspapers with news about your city

Short update on my life and homelab

STFN — Sat, 29 Mar 2025 24:00:00 GMT

Do you know those days that you cannot start doing anything, because you are going out in the evening?

That has been the situation for me for the last month and something. The construction of my future house is just about to start, and I could not make myself to start new things, or continue existing projects. But hopefully this hiatus will come to and end, the last bureaucratic (how do you spell that?!) things are being taken care of, the workers are appointed, the land is ready, and my stress levels should gradually decrease.

When it comes to my homelab, I have been doing some tiny changes, moving more stuff to my self-hosted Nextcloud instance, sorting out better ZFS backups.

I'm thinking of replacing my Kubernetes cluster with LXD. The issue that I have with Kubernetes that even in their simplified form that I am running, K3S, there are still too complicated for me and require too much attention and head space to use them efficiently. My cluster is running, but recently I restarted it and all the Ingress stuff stopped working, I can only reach the services via the Node IP. Why is that? I don't know, I haven't done good enough notes to debug it easily. And I very much despise the situation when my Homelab services are running in a way that I am afraid to do any changes lest they break. Especially when it comes to services that are becoming not Homelab but HomeProd.

On the other side, lately I have been enjoying using LXD, and I plan to move more of my services to it. So expect a few future blog post on the topic.

That's basically it for now, just wanted to let you know that this blog is not dead and I have plans for new posts.

Thanks for reading!

Deploying Nextcloud locally with LXD

STFN — Sat, 12 Apr 2025 24:00:00 GMT

As I mentioned in the previous blog post, I am now in the process of moving some of my homelab services from Docker to LXC (Linux Containers). Both of them are virtualization technologies and are based on similar concepts, but recently I found LXC more tempting.

Disclaimer 1: I would not call myself an expert in either Docker or LXD, what I write below is based on the limited knowledge that I have on those topics, and there is a high possibility I might be wrong in some places. Let me know if you spot any errors.

Disclaimer 2: Everything described here I have first created and configured for my own needs, and only later decided to write up in a blog post. I am using NextcloudPi in my homelab as an actual "production" of storing documents and other data. So this is not a tutorial for the sake of writing a tutorial, it's a description of my real life usage.

I've been using Docker for years now, both at work and in my homelab, and I find it an excellent tool. Then again, I believe its usecase is mostly for small, ephemeral containers that run a single process, like a webserver or a video converter. LXC containers (I know, I know, IN number) on the other hand are closer to virtual machines, holding state and having multiple processes running in them. LXC also provides tooling for doing snapshots and backups of running containers. And when everything like the database and the server is running in the same container, it's easier to backup and move it, in contrast to running a whole group of containers with docker compose.

Because of that I feel that LXC containers are well suited to run some of the long-lasting, stateful homelab services.

Another thing that led me to LXC is me wanting to have my own Nextcloud instance, and this is the main topic of this post.

LXC vs LXD

The topic of "LXD vs LXC" is confusing to say the least. The way I understand it is that LXD is something like a frontend, allowing for easier management of LXC. LXC is the underlying framework that runs the containers, while LXD allow for administration and orchestration of the LXC containers. Something like Docker Desktop for managing Docker containers which are being run under the hood by the Docker Engine. Also LXD being created by Canonical is Ubuntu-centred while LXC is distro-agnostic. Finally, it is possible to just use LXC without the added benefits of LXD.

Nextcloud

Nextcloud advertises itself as a "fully open-source, on premise content collaboration platform". What it actually means for us, homelabbers, is that it provides a FOSS alternative to commercial cloud services like the Google suite of apps like Calendar and Drive. With Nextcloud we can have those services running privately in our homelabs, without subscription feeds, or snooping through our files. Running your own instance fits very well into the topic of degoogling, as it allows to move away from large corporations and take your data into your own hands. There's much more it of course, but this blog post is more on the technical site of setting up your own instance.

NextcloudPi

When looking for a way to deploy Nextcloud to my private homelab, I came across a subproject of NC, called NextcloudPi. As the name suggest, one of the main goals of NCP is to provide a way to run Nextcloud on a Raspberry Pi. The creators provide an image that can be flashed to an SD card to run on a Pi. I don't want to run NC on a Pi, when I have an x86 server sitting under my desk, so I chose another solution that they provide: an LXD container image.

Setting up LXD

I think it's a good idea, if you are using LXD for the first time, to install and try it out first on your local PC/laptop, and later, once you went through the whole process, install it in a headless homelab. It will make some things easier to test.

There are multiple ways to install LXD, I went with the simplest/laziest option that is installing it from snap. My laptop is running Kubuntu, and my homelab's OS is Debian with added snaps (I know, blasphemy), so snaps are fine with me. Here are the installation docs.

When installing from snap, it's as simple as (needs to be run as root)

snap install lxd
lxd init

If you are running LXD on machines that have a single drive, or you want to have a basic setup for testing, choose the storage backend to dir. If you have the possibility, choose ZFS and provide a separate dataset for storage.

Once LXD is running, it's time set up the LXD Web UI. There are multiple way to administrate LXD, but the simplest way is to use the browser. If you are running it on your computer, just open localhost at port 8443. If you installed it on another server, open it's IP address with the port 8443. A first-use wizard will guide you through the initial setup, and will show how to generate a certificate. It is a bit more complicated than setting up a username and password, but should not cause any problems.

Before moving to the next part, have some fun with LXD, try to run a container, open a terminal inside it, try to update the packages, stuff like that. Just to get a feel of what is happening.

BTW, the terminology that LXD is using for a running container is "instance", and this is the word I will be using from now on.

And if you created an instance, and it cannot access the internet, check this forum thread.

Running NCP

Now it's time to run NextcloudPi. Download the NextcloudPi image from the GitHub downloads page, select the file with LXD in the filename and the architecture of your computer (most likely x86). Download it, but do not unpack.

In the LXD Web UI go to Images -> Upload image, select the downloaded file, add a nice alias for the name if you want. Then Instance -> Create Instance -> Browse Images and at the top of the list there should be the newly uploaded NextcloudPi one. For now there is no need to modify other settings, just select Create and start.

Form to upload a container image into LXD

A list of all available containers images LXD, with the NextcloudPi's one on top

Accessing NextcloudPi

NextcloudPi is now running on your computer as an LXD instance, but how to access it? It depends on where you are running your LXD service:

Running on the same PC

Accessing the NextcloudPi instance in LXD running on the same computer that you are using is the simplest way. By the power of DNS magic, NCP should be reachable at https://nextcloudpi.local. If that is not the case, the second option is to open in the browser the instance IP address, which can be found in the instance overview tab in the LXD web UI.

Instance summary page, with the highlighted IPv4 address of the instance

Running in the LAN

This is where things get a bit more complicated. For an overview of methods how to reach an LXD container running on a machine somewhere in your LAN, I recommend this great video done by one the LXD developers: Accessing services running in LXD instances. From all the methods presented there, I have been using two:

Configuring specific routing in the router

The first method I used is setting up routing in the router. I have a MikroTik router that allows for almost infinite configuration, so that was not a problem, but I'm not sure how feasible it is in typical home routers. Also configuring it differs between router makers, so I won't be giving exact instruction, just an example:

For my MikroTik router it was a matter of opening a terminal window in the router web UI, and setting the routing:

[admin@MikroTik] > /ip route add dst-address=10.54.60.0/24 gateway=192.168.10.240

The dst-address is the subnet of the LXD network, to find it take the IP address of you instance, and replace the last number group with 0.24. For example, if you instance IP is 10.54.60.123, the subnet is 10.54.60.0/24. The gateway is the IP of the host machine that is running LXD. Thanks to that command, your router will know that if you want to reach the IP address of your NCP instance, for example 10.54.60.123, the request has to go first to 192.168.10.240, and that machine will route it further to 10.54.60.123.

The upside of this approach is that it only needs to be done once, and will handle any containers run in LXD. The downside is that not all routers support this.

Also with this approach, http://nextcloudpi.local/ will not work out of the box. To make it work, you'll need to manually set up a DNS entry, either in the DNS server, if you have your own, or in the /etc/hosts file.

For more information about setting up local domains with DNS, check out my How to set up subdomains in the homelab with PiHole and Caddy blog post.

My personal problem with this approach is that while it works, it is extremely slow, I need to wait at least 5-10 seconds for the webpage to load. I am suspecting this is caused by my non-standard network solution, I have a WiFi bridge made from two Mikrotik Audience Access Points, and have the routing configured on one of them, the one closer to the ISP router. This is something I will need to investigate in the future. For you it will most probably work fine.

Proxy devices

I won't lie, this is the part of the LXD config that I understand the least, but I found how to use it to make it work the way I want it to. If you know how to do it better, more properly, let me know.

Proxy devices allow to configure a connection between the host and the instance, so that accessing the host on a specific port takes the request to a specific port on the instance to which the proxy is attached to. I have two proxy devices configured, first one forwards the connection to the host port 9290 to the instance port 443 (default for HTTPS) and the second device forwards from host 4443 to the instance 4443 for the management site.

This way, when I go to HOST_IP:9290 I am taken to the Nextcloud main site, and when I go to HOST_IP:4443, I go the admin portal.

I am using port 9290 on the host because I also have other services running, and so ports 80 and 443 are already occupied.

I also found out that the admin portal will not work if you change its port in the proxy device, it expects to be accessed on port 4443, otherwise it will not allow to change any settings.

The Bind and NAT mode options I leave undefined, from my limited experience I did not see difference when I changed them to different options. The Listen IP address is 0.0.0.0 (any address) and the connect one is 127.0.0.1 (localhost of the instance). For me it kinda works. How correct it is? I am not sure. I would love to hear your feedback.

Proxy devices config page

Accessing from anywhere

You can now access the instance locally. But what if we want to access our Nextcloud from any place in the world, for example to upload invoices or photos from holidays? For that I am using Tailscale, a zero config VPN. I'm a big fan of them, I have them on all my devices, even my mobile phone. No, they do not pay me, I just like their services.

To install Tailscale I just use their install script, which I launch in the instance terminal. The terminal can be accessed on the instance page in the LXD Web UI. Once Tailscale is installed and authenticated, you will get an IP address and a domain to access it from anywhere.

Note that in order for the Tailscale domain to work, you will need to add it to the "trusted domains" setting in the NCP admin portal (the one on the :4443 port) or by editing the /var/www/nextcloud/config/config.php in the instance terminal window.

NextcloudPi initial config

Once the container is running, and you can access it, the time has come to do the initial setup. NextcloudPi built-in HTTP server works on the standard ports 80/443, so unless you changed the port in the proxy device setup, pasting only the domain or the IP address in the browser will work.

You will get an error that the connection is not secure, that is not a threat, it's just the way NCP runs by default.

NCP has HTTPS implemented out of the box, but it is using a self-signed TLS certificate, and the browsers do not like it. Just confirm that you accept the risk and want to continue. If you know how to solve it for locally running services using HTTPS, let me know.

Once the warning page is gone, you will be greeted with the NCP welcome page with two sets of usernames and passwords. Note them before clicking "Activate"! Then again, if you continued before saving them, that is not a problem, just stop and remove the instance and create a new one. The beauty of virtualization is that killing and recreating virtual machines is super simple and fast.

Nextcloud initial config page

The first login and password is for the server administration page at port :4443. This page is for all of the low-level configuration and administration tasks to which regular users should not have access, for example the database settings or software updates.

The second set of credentials is for the first user of your NCP instance. That user will also have the administrator permissions, allowing them to do some additional configuration for all users of the instance, such as the quotas, languages and themes

Once you have written down both sets of credentials, click Activate, and you will be taken to the main page of your Nextcloud account. You are an administrator, so you can start with creating more users in the Administrator settings.

And that's basically it, you now have a running Nextcloud instance to which you can upload files, create notes, make appointments in the calendar etc.

Fresh instance of Nextcloud

Backups

Now that you have all your precious and important data in NCP, it would good to back it up. The available backup solutions for NCP are snapshots and exports, and both serve slightly different purposes.

Snapshots

Snapshots allow to freeze the instance state in a certain moment in time, like taking a photo. If you, for example, remove from your NCP drive a file that you did not want to remove, you can restore the whole instance from a snapshot that was taken before you removed that file. You will lose all the changes that you did in the time between now and the creation time of that snapshot, but your precious file will be restored.

List of snapshots created for the NextcloudPi instance

LXD allows to configure the automatic creation of snapshots on schedule in the Snapshot tab of the instance settings. There you can also list your snapshots and select the one to restore from. A good idea is to set the expiration date of the snapshots so that they do not take too much storage space.

Exports

Snapshots are great and all that, but they have one significant problem: they are stored on the same machine as the LXD service. If that machine breaks, you lose the running instance and all of its snapshots.

The solution for that is to export the instance to a file, which can then be moved to different machine(s). For that, we need to go to the terminal on the host where the LXD service is running. To create an archive, this is the command:

lxc export nextcloudpi --instance-only "ncp-$(date '+%Y-%m-%d').tar.gz"

Running this will create a tar.gz archive with today's date in the filename. The --instance-only flag defines that only instance should be archived without the snapshots. If you want to also export the snapshots, remove the flag but bear in mind that the file will be massive. To automate this, create a bash script that will generate the archive and rsync it to some other place. Add it to cron to run it periodically.

#!/bin/bash

DATE=$(date +%Y-%m-%d)
FILENAME="ncp-$DATE.tar.gz"

lxc export nextcloudpi --instance-only ncp-$DATE.tar.gz
rsync -azP $FILENAME 192.168.1.2:/home/stefan

Change the IP address and local path to what you have.

To import the resulting archive back to LXD:

lxc import ncp-2025-04-12.tar.gz

This command will import the exported instance. It will be added to the list of instances in the LXD Web UI, in the stopped state, and will need to be started to use it.

Bottom Line

So now you have a local NextcloudPi instance which you can use to organize your life and files. Of course this post only scratched the surface of what LXD and Nextcloud can do, but I'm hoping it give a good basis to develop upon. As I use Nextcloud more, and move more of my services to LXD, I will be writing more articles on the topic. In the meantime, thanks for reading!

Access local Nextcloud with HTTPS anywhere by using Tailscale TLS certificates

STFN — Sat, 26 Apr 2025 24:00:00 GMT

This blog post is of course not sponsored by Tailscale, I just really like them

This blog post continues the topic of running Nextcloud in an LXD container, but the matters discussed here are universal and can also be applied to any service running locally in your LAN.

In the previous blog post I mentioned that when using Nextcloud, I am getting a warning that the connection is not secure. That is because Nextcloud by default is using a self-signed TLS certificate, and modern web browsers find it suspicious. This was not a big problem for me until I wanted to use Gpoddersync to synchronize my podcasts between my phone's AntennaPod and my Nextcloud's RePod application (Something that I will write about in more detail in another blog post). Creating the connection would not work, as the sync tool expects a properly working HTTPS on the Nextcloud's side.

Turns out there is a rather simple solution to fix this issue: use Tailscale to generate a proper TLS certificate to provide a secure HTTPS connection when accessing Nextcloud via VPN.

Setting the stage

The initial situation is that I am running a NextcloudPi instance in an LXC container in my homelab server. I have Tailscale installed inside that container. I can access NCP via Tailscale using its MagicDNS url, but the browser is complaining that the TLS certificate is suspicious.

TLS certificates in Tailscale

Tailscale has excellent docs on how to enable HTTPS and generate certificates, so just to recap it shortly: In the Tailscale admin settings, make sure MagicDNS is enabled, and at the bottom select "Enable HTTPS". Tailscale warns you that the fully qualified domain (basically the hostname + MagicDNS tailnet name) will become publicly known to enable validating the certificates, but the access to the machines will still be private.

Configuring certificates in NextcloudPi

In the NextcloudPi console (I use the LXD Web UI to access the container's console) run

tailscale cert <your MagicDNS url for that machine>

This command will generate two files, a *.crt and a *.key one. You can leave them when they were generated, or move them to a location of your choice.

The next step is to edit the Apache config file to point it to the new certificates. Use your editor of choice, I use vi:

vi /etc/apache2/sites-enabled/001-nextcloud.conf

At the top of the file there is a warning that the file should not be edited as any changes will be overwritten, but to be honest, I do not know when that happens, I restarted Apache and the whole instance a few times and the changes I made persisted. Would an Apache expert chime in?*

Anyway, the beginning of the file should like like this:

<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    DocumentRoot /var/www/nextcloud
    CustomLog /var/log/apache2/nc-access.log combined
    ErrorLog  /var/log/apache2/nc-error.log
    SSLEngine on
    SSLProxyEngine on
    SSLCertificateFile   /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

    # For notify_push app in NC21
    ProxyPass /push/ws ws://127.0.0.1:7867/ws
    ProxyPass /push/ http://127.0.0.1:7867/
    ProxyPassReverse /push/ http://127.0.0.1:7867/
  </VirtualHost>

What interests us are the lines beginning with SSLCertificateFile and SSLCertificateKeyFile. Replace their values so that those lines point to the crt and key file respectively. For me those would be:

    SSLCertificateFile   /root/nextcloudpi.[redacted].ts.net.crt
    SSLCertificateKeyFile /root/nextcloudpi.[redacted].ts.net.key

Now what is left is to reload Apache

apachectl -k graceful

And le voila! You should now be able to access your Nextcloud via Tailscale without any TLS error messages, with the browser bar showing a nice padlock.

Nextcloud with a secure connection

That's it, short and simple. I'm becoming more and more impressed with Nextcloud and the possibilities it provides. Also a friend told me that Hetzner is now providing a managed Nextcloud service. I haven't tried it personally, but he says it's working great.

What is more, I have used the example of Nextcloud, but the mechanism I presented is universal and can be used to generated TLS certificates for any internal service that you are providing, like Immich or Jellyfin. The only requirement is a HTTP server that can handle TLS. I will be testing it with other services soon.

Thanks for reading!

* I now have Panic At The Disco playing in my head.

Migrating servers, leaving Fosstodon, moving to my own GoToSocial

STFN — Fri, 02 May 2025 24:00:00 GMT

During the last few days I did two migrations, the first one I had been planning for some time, the second one was more spontaneous, and they were directly related to one another.

First I migrated the VPS hosting my GoToSocial instance from RackNerd to Hetzner. After that I migrated one of my main Fediverse accounts from Fosstodon to my GoToSocial instance, fedi.stfn.pl.

Moving from RackNerd to Hetzner

The VPS migration had been on my mind for quite some time. It fits into my ongoing plans to reduce my dependence on large corporations (see my On Degoogling post), and especially the ones that are based in the United States. With the latest changes that the US is undergoing, I just do not want to have my data and services running there. Europe is a place that takes matter such as data privacy and sovereignty much more seriously, and what is also very important to me is that Europe is a place which I feel a part of. And I strongly believe that the European Union and the agends that it is pushing are the best things that have happened to Europe in all of its history.

And so I chose the German company Hetzner as my new VPS service provider. They have datacenters in Eastern Germany, which is physically very close to me, and I've been already using their other service for months. Their Storage Box is very good in my opinion, and while it has a non-zero entry level, the pricing is hard to beat in the area of cloud storage. Also, RackNerd's VPS services are very barebones, while Hetzner provides additional tools for managing servers, like regular backups and snapshots.

Here I need to stress that I have never had any issues with RackNerd, no downtime at all, and their pricing is very good, but well, I want to have my Internet stuff close to me, in Europe. Yes, I know that RackNerd has datacenters in the Netherlands, but all in all, they are a company from California.

Moving from Fosstodon to fedi.stfn.pl

I do not want to elaborate on the reasons I left Fosstodon, already a lot of people said a lot of words of varying intensity about the whole affair. Let me just say that apart from the, let's say, social aspects, the want to move to my own place and handle the technical parts myself was an important factor.

The Migrations

Now let's talk about the technical stuff. I wanted to have my VPS situation sorted out before moving my large Fosstodon account to my VPS, so first I went with the server migration.

Moving GoToSocial instances between servers

The first migration I went with was migrating my GoToSocial instance from my RackNerd VPS to my new Hetzner one. This does not mean I already left RackNerd, as I have more services running on their servers. Eventually I will move all of them.

As in many previous of my blog posts, I am writing about a thing I did, but I try to talk about it in the form of a tutorial, so that anyone can do the same. That's why the way the next paragraphs are written is funky at times, jumping between my "memoirs" are instructions what to do. Anyway...

The whole process is rather straightforward. The crucial thing is to have good backups and do each step slowly and making sure it succeeded.

The following steps are assuming you have an already running GTS instance on server A (called source from now on) and you want to move it on a bare, just bought Linux server B (called target). I am running GTS as a systemd service with SQLite and nginx as a separate reverse proxy. HTTPS is being handled by Certbot. As you can see, there is a lot of variables here, and you setup may be very different, but the general ideas should be similar.

The very first thing to do when migrating services between servers, is to go to the domain provider you are using, open the settings of the domain of the service being migrate, and change its TTL to a very small number, like 5 seconds. This should be done preferably a few hours in advance of the migration, the most correct way is to wait the time the domain's TTL was set to in the first place. For example, if you domain TTL was set to 24 hours, it would be best to change the TTL to 5 seconds and wait those 24 hours before the migration. This clears the caches of browsers and any downstream DNS servers, and so when clients will try to reach you service after the migration, the DNS cache will not take them to the IP address of the old server.

Once the waiting is done, it's time to do the actual migration.

The first step to do is to go through the typical initial server config and hardening, Initial Server setup with Ubuntu by DigitalOcean is a great article and I refer to it every time I set up a new server

After that, an optional but useful step is to set up the monitoring stack for the new server: Prometheus, Node Exporter and nginx-prometheus-exporter. I also make sure that nginx is installed. If you are using a database other than SQLite, now it would also be the time to install it.

A few useful resources on monitoring:

Once this is done, the actual GoToSocial migration can happen.

Nginx migration

stop nginx on target
copy /etc/ngix/sites-available from source to target and in the target server symlink the GTS server config to sites-enabled in a typical nginx fashion.

TLS certificates migration

copy /etc/letsencrypt from source to target. If there is no such folder, check in the nginx site config where the TLS certs are stored in you case.

GoToSocial migration

This is the actual migration. Begin it with stopping the GTS service on the source server.

sudo systemctl stop gotosocial.service

At this moment the downtime of your instance begins. If you have more than one user, I hope you warned them in advance :)

copy /etc/system/system/gotosocial.service from source to target
pack /gotosocial on source to gotosocial.tar.gaz.

sudo tar -czvf gotosocial.tar.gz /gotosocial

I followed the steps from the GTS docs when doing the initial installation, so in my case, GTS data lives in the /gotosocial top level directory, and is owned by the user gotosocial

create gotosocial user and group on the target server

sudo useradd -r gotosocial 
sudo groupadd gotosocial 
sudo usermod -a -G gotosocial gotosocial

copy the gotosocial.tar.gz tar archive to target and unpack
chown the whole /gotosocial folder to the user gotosocial

sudo chown gotosocial:gotosocial -R /gotosocial

If you are using a db other than SQLite, now would be the time to migrate it. I've never done it, so I would not be of much help here.

on target enable and start gotosocial.service

sudo systemctl enable --now gotosocial.service

At this moment, GoToSocial should start cleanly on the target server. But it won't be available yet to the outside world, as nginx is not running yet. The simplest way to confirm that GTS is indeed working is to curl it from the same server it is running on

curl http://localhost:8000

The response should be welcome web page. If it is not working, time to start debugging. A good place to start are the system logs:

sudo journalctl -xeu gotosocial.service

This should show the cause of the problem. One common problem is file permissions, make sure /gotosocial belongs to the right user, the one that is mentioned in the gotosocial.service systemd file.

Once we are sure that GTS is running on the server, the last steps are to switch the DNS so that the domain points to the target server, and start the nginx service on the target. It's also a good practice to test the nginx config before starting it:

sudo nginx -t
sudo systemctl enable --now nginx.service

nginx should start without issues, but as always should is the key here. If it does not want to start, consult the logs as described above.

And done! Your GoToSocial instance should be back online, working from the new server.

If that is correct, the final final setp is to reinstall certbot, so that the certificate renewal hooks are in place. Just do the same steps from Certbot's page as you would install it. Certbot is smart enough to find that the certs already exist on the target server and will reuse them, and configure its new service around them.

Migrating my Fosstodon account to my GoToSocial instance

With my Gotosocial instance fedi.stfn.pl working nicely on new hardware, it was time to migrate my Fosstodon account to it. Thanks to the creators of the Activity Pub protocol, Mastodon, and GoToSocial, it was a very simple task.

I already had an account stfn on my GTS instance, rarely used and with almost no followers/following, so the first step in the migration was done in advance.

In its settings, I added https://fosstodon/users/stfn as an alias, to prove Fosstodon that this account indeed belongs to me.

Then, in Fosstodon's account settings, I first requested an archive of all my data. It took a few hours to generate it. I also downloaded all of the CSV lists of people I followed, muted, blocked. Turned out I only blocked three users, and looking at their usernames, I had no recollection why I did it.

Once I had all the data backed up, again in the Fosstodon account settings, I initiated the migration of the account, providing my GTS account url as the target.

On one screen I had my VPS nginx logs opened, on the second screen it was Firefox, with Fosstodon in one tab, fedi.stfn.pl in the second tab, and Grafana VPS stats in the third. I clicked the magic button and the migration begun.

During the migration, only the people who follow you are automatically migrated. It looked like the followers were being migrated in batches of several tens, and all in all it took maybe two hours for the migration to finish. In Fosstodon I had arround 1140 followers, in fedi.stfn.pl I ended up with around 900. I don't know what is the reason for that, but I am guessing that maybe some of those 1000+ followers I had were defunct accounts that could not be found by the new instance.

Having migrated the followers, I went to migrate the people I follow. In the GoToSocial account settings I went to the Import tab, and uploaded the corresponding CSV file from the ones I downloaded from Fosstodon. That also took quite some time, but almost all follows migrated without issues.

I decided not to migrate my toots, start with a clean slate, but it is possible to do so, with a tool aptly called slurp, available on GitHub.

Backups

As I mentioned at the beginning of the post, Hetzner provides better tooling than my previous VPS provider, and because of that I stopped using Borg for backups, instead I switched to doing snapshots of the whole server. For now I am doing it manually from time to time, but my plan is to find a way to automate it, maybe using Ansible or some similar tools.

Bottom Line

And that's it, I am happy I did those two migrations, I feel that it gave me renewed joy in learning the more technical aspects of the Fediverse. And whenever I mentioned the topic of migrating both servers and accounts on the Fediverse I received so many words of encourangement, of good tips, of wishing me luck. The Fediverse has the best crowd of any social medium I've ever been on, you people are awesome!

And it looks like Fosstodon will be having a new team of admins and moderators, led by Gina @ fosstodon.org. I wish them all the best and hope they will lead Fosstodon to a bright future as an imporant part of the Fediverse.

As of writing this post, my instance is federating with 8288 other instances. I find it incredible that the number of instances in the Fediverse is in the thousand or tens of thousands!

Thanks for reading!

My new, (mostly) Mikrotik network setup

STFN — Fri, 09 May 2025 24:00:00 GMT

I bought a new router and now my home network is mostly Mikrotik.

Before I start talking about the network setup, let me lay some context of where I am: There are two main factors why my current network setup is configured in such a way:

Sometime in the future, maybe end of this year, maybe early next year, I will be moving to my own house, and there will be a full sized server rack in a separate room.
In my current flat, I have thick concrete walls and the room layout makes it basically impossible to lay cables between them, also we are renting it so I do not want to modify it too much.

Also I am big fan of Mikrotik, as they are a relatively small, Latvian company and I know they make very good and fair priced network products. Their software has a steep learning curve, but I want to push through it, I think having this skill will be very useful both in my homelab and professional experience.

Here is the diagram of my network, made in draw.io

The network entrypoint is my small town ISP, providing Internet in the form of a Ethernet twisted pair cable coming from the wall of my flat. In every other place where I lived it used to be either coax or fiber, but here it's just RJ45 from the wall. The cable goes to the ETH1 port of my newly bought Mikrotik (deep breath) RB3011 U1AS-RM.

I chose RB3011 U1AS-RM because it has a) 10 copper ports and one SFP fiber port for my planned use of light in my future network, b) is rack mountable for my planned massive rack, c) it has a screen! and d) it is in general a beautiful overkill.

I bought it used for ~400PLN (95EUR) and would you believe it, on Vinted.

My new router. Note the temporary "rack mounting". And fighting dust is a hopeless battle in a flat with a large dog. The router LEDs are covered with black tape.

The ISP uses PPPoE to authenticate users, and the RB3011 handles that part. I configured PPPoE using this Youtube video. However, after doing it exactly as in the video, only my router had Internet access, but not its clients. This forum thread helped me solve this issue.

Out of the ETH10 port of the router goes the link to my Audience Mikrotik Access Point.

I have two Mikrotik Audiences connected in a mesh, but in my case it's more of a Wi-Fi bridge. The second Audience is placed in the office room. As I said before, I can't really put cables between the rooms here, and the walls are thick and disastrous to Wi-Fi signals, especially the 5Ghz ones. When using cheap, basic Wi-Fi routers I would get a lot of dropped connections and that was just not acceptable when working from home as I do.

Configuring the Audiences to work as a mesh was rather straightforward, the Mikrotik's site has instructions on how to do it, it boils down to pressing the WPS on the first Audience and then holding the WPS button on the second one. However, I had to modify one setting after pairing using WinBox, and I am not sure if that is a flaw in the default configuration, or if I did something wrong. In order to make the connection an actual Wi-Fi bridge, I had to add ETH2 to the default bridge interface on the second Audience unit.

Mikrotik Audience living on top of my office book rack

This allowed me to use the second Audience unit as a wired router for devices in my office. The two Audience talk to each other over Wi-Fi, and they even have a dedicated 5GHz link only for intertalk, and I have to say that it works much better than any previous Wireless router I tried in this flat.

So I said, the second Audience works as a sort of wired router, a cable from the ETH2 port of it goes to my NETGEAR GS108LP PoE+ switch. I chose that switch most of all for the PoE+ part, as it allows me to power my Raspberry Pis without using USB-C power supplies. I have right now four Pis running, three in my Kubernetes cluster, and one running as an ADS-B receiver.

The switch is also rack mountable, and the ears can be rotated 90 degrees, so for now it's bolted to my bookrack.

The switch and the Pis.

BTW, My Kubernetes cluster is no longer running K3s as I got tired of maintaining it, for now it's only running BOINC, and I am considering taking it apart and testing out the Pis as security cameras in my future house.

Apart from the Pis, that switch also handles my homelab server, and my work laptop which I rarely move from its place, so it's wired.

There's also one other PC that I did not mention previously, there's a Lenovo ThinkCenter USFF PC running my Home Assistant and working as a Zigbee gateway (I described it in detail in the Using a Lenovo USFF PC as a Home Assistant box blog post). It's connected to the first Audience AP and not to the router directly because, well, let's go to the issues list.

Issues

Those are not exactly issues, more like "things I need to learn properly, for now I am a bit scared to touch them". Having internet access is a sacred thing in this household, and I don't want to have problems because I mess up my internet setup to a point of no return. I will sort it out properly, but not today :)

The main issue I have with my current setup is that the first Audience unit, the one connected to the router is a DHCP server, and so it has its own separate subnet, different from the one of the router, and so I would not be able to reach things connected to the router from, say, my laptop. I want to have a flat network with a single subnet handed out by the RB3011. As I said, this is something for the future. I guess all the network engineers will now sneer at me for procrastinating doing such a trivial change, but hey, I'm just starting in the realm of networking, and choosing Mikrotik as my platform is playing on hard.

The second issue, much easier to fix, is that I am running out of Ethernet ports on my switch :) My long-term plan is to get the CRS305-1G-4S+IN SFP+ switch and move some of my devices to 10G fiber.

Bottom line

And that is the current situation. Not ideal, but much, much better than it was when I moved in here.

Not only do I have better Wi-Fi, but also the girl who lives here is now my Wi-Fe.

Ok, that was awful.

Anyyyway, speaking of the future house network, I am hoping that there I will be able to just use a single large AP and ditch the Wi-Fi bridge. This should make any configuration much easier. I will also need to look into LTE solutions, it is very probable that I will move to the house faster than fiber comes to the village.

I can't wait to write more blog posts as I am building the network in my new home, almost as much as I can't wait to live in it!

And that's basically it, hope my blog post was inspiration to some of you, and thanks for reading.

I achieved 100 million points in Einstein@Home, and rediscovered Folding@Home

STFN — Sat, 10 May 2025 24:00:00 GMT

I achieved one hundred million points in Einstein@Home. Another BOINC achievement, this time for a specific project. Einstein@Home has always been one of my favourite BOINC projects, with an interesting topic, and as important, a great, very communicative team of admins, and a welcoming community.

My Einstein@Home certificate, with a very "early 00s" design

Of course those points don't mean much other than showing that I gave time and money to crunch work units, but a round number is a round number :) That, and bragging rights in an extremely niche topic.

My Einstein Machines

For the last few months I've been crunching E@H mostly on my Raspberry Pi cluster. A Raspberry Pi 4b is very weak in comparison to desktop PCs, but uses little power and can run in the background 24/7 being barely noticeable, especially with a custom cooling solution. A single Pi crunches around 1400 points per day based on my observations. Having ARM tasks is not common in BOINC projects, and that is another upside for Einstein.

My current E@H machines, there have been many more before them

Crunching Einstein on Pis would never bring me close to that milestone, most of the heavy lifting has been done by my homelab server, crunching tasks on a Nvidia RTX 3060 12GB. The GPU is a bit bottlenecked by my slow CPU, especially in mix CPU/GPU tasks such as the All Sky Gravitional Search, but for now it will have to be this way, upgrading my homelab needs to wait as I have more important spendings. I don't usually run my GPU crunching 24/7, but if I were, with crunching All Sky, the theoretical rate would be around 600k points per day.

My BOINC life

In general, my focus on BOINC has fallen down in the recent months, mostly because it was announced that Universe@Home, the project I crunched the most, will not be restarted. After the death of the lead scientist there has been a search for a team that could continue the research, but nobody was found. The project servers are still up, and a single maintainer keeps the lights on in hope of a change, but the chances are dim. That brought me down a lot.

Also, as part of saying goodbye to Google, I changed the email address on all my BOINC project accounts, and that messed up the BOINC statistics page, Universe is no longer showing in my stats, and that was 1/3 of my total points. I know that we crunch for science and not for fairy pointless internet points, but hey, it feels good when number go up.

So, what now?

I will continue crunching Einstein@Home on my Pi cluster as long as it's running, probably a few months until I disassemble it and use the Pis for different usecases. My long term plan and hope is to go back to BOINC full time once I start producing cheap, clean electricity from my PV installation, but that will probably happen sometime late next year, not sure yet.

Going back to Folding@Home

As I put BOINC on the back burner, Emil@Collectifission reminded me of the existence of Folding@Home. F@H shares a similar idea as BOINC, distributed computing to solve scientific problems, but runs on a different software, and it it's own closed ecosystem, with a single app and projects being handed out by some sort of algorithm. I crunched F@H for a few months during its sudden peak in popularity, when the project was looking for ways to fight COVID in the initial phase of the global pandemic (you remember that time?).

I decided that a change of scenery would be good, and I joined F@H again with a new account and started some crunching. Not sure how long I will crunch for them, we'll see. I also joined his team for Fediverse users, please feel invited!

And that's it. When will I reach 200 million in Einstein? As Albert himself said in the intro to Red Alert, "Sooner or later, time will tell".

If you would to join BOINC and have problems with setting up your account or system, let me know, I will be happy to help.

My previous "BOINC achievements" blog posts:

My thoughts as I reach 100 million points in BOINC

I reached 150 million points in BOINC

Using PiHole and Tailscale to block ads on all my devices, including mobile

STFN — Sat, 17 May 2025 24:00:00 GMT

This post is a continuation of my WireGuard and PiHole for secure ad blocking on your smartphone post. I'm writing it because I changed my PiHole setup and wanted to showcase it. Also PiHole released version 6, which changes a lot, and I thought it would be good to write about the new way of configuring it.

My Fairphone 4 with the PiHole admin interface opened in Firefox. The queries graph is mostly empty because I reinstalled PiHole on a new server.

I recommend reading the previous post as well, there I talk about some things not mentioned here, like reasons for restricting DNS server access from the public Internet, I did not want to repeat myself too much.

Here's my current situation:

I am running PiHole on a Hetzner VPS. The server is a part of my Tailscale Virtual Private Network (VPN). The PiHole DNS service and its admin panel are only accessible via Tailscale, they are shielded from the open Internet by the firewall and PiHole interface restrictions. The PiHole VPS is configured in the Tailscale settings as the DNS server of the network, so any of my devices connected to Tailscale will use PiHole as its DNS automatically. This way I can use PiHole ad blocking anywhere I am, with any device, even my mobile phone, just by connecting them to Tailscale.

And now, how did I achieve that?

Setting up the machine

The first requirement is a machine that PiHole will be running on. It can be a Raspberry Pi, or any local computer, it can also be a rented VPS. The only requisite is that it has a stable and low-latency Internet connection. I went with a VPS, because I plan to also run public services on it. Running it on a local machine, not reachable from the open Internet will make the setup easier. In that case you can skip most of the security steps like setting up the firewall. Or you can do them nonetheless, it won't hurt :)

I bought the cheapest available VPS from Hetzner. I went with the preferred way of providing SSH keys instead of password authentication, and this is what I highly recommend for security. After SSHing into the new server I went through the usual initial setup and hardening steps, described very well in Initial Server Setup with Ubuntu article on DigitalOcean.

For now, open ports 22 (SSH), 80 (HTTP) and 443 (HTTPS) when configuring the firewall:

sudo ufw allow OpenSSH
sudo ufw allow "Nginx Full"

Installing Tailscale

All the different ways to install Tailscale are described in the installation docs. There's also an Ansible Collection for Tailscale if you're into such things.

Installing Pihole

PiHole can be installed from an installation script. On the installation page in the docs I went with the last option "Alternative 2: Manually download the installer and run". Before running the install script I gave it a quick run down. Still, not the safest option, but I felt it to be just a tiny bit safer than just piping curl to bash.

In the PiHole initial configuration wizard, on the "Choose an interface" step, I chose tailscale0. If there is no such option for you, make sure you have Tailscale properly installed and running. However, even with choosing the right interface, I encountered interface problems later on, more on that soon.

PiHole initial wizard, choosing the interface step

And write down the admin password before you close the wizard! If you are like me and forgot to do it, you can always reset it by running

pihole -a -p

in the VPS console.

Enabling Pihole

You should now be able to access the PiHole admin panel at http://<vps_ip>/admin. The admin panel is accessible, but the DNS service that PiHole needs to work is still being blocked by the firewall. To enable it run

sudo ufw allow in on tailscale0 to any port 53

This will open the DNS port 53, but only for the tailscale0 interface, meaning that only machines talking to the VPS through the Tailscale VPN will be able to reach it. This is a security measure to stop anyone from the public Internet using our new DNS server.

PiHole DNS service can now be reached, but it will still not work with any clients. To finish the setup we need to go to the PiHole settings in the admin panel.

In the admin interface go to Settings -> DNS, and start with switching to Expert settings. This will show a new box, "Interface settings". Most probably it will be on its default settings "Allow only local requests". This will not work for us, as PiHole does not consider the Tailscale network to be local.

PiHole DNS settings, the interface name is missing

Now, when I first opened those settings, I had the interface name span empty in the "Respond only on interface" option. Not sure if I did something wrong, or if there is a bug. If you right away have an option "Respond only on interface tailscale0" then just select it and skip the next paragraph. If not...

Setting the interface name

Go to All settings and scroll down to the dns.interface box, and set it to tailscale0. Save & Apply. Go back to the DNS options and now the interface options should show and work properly.

Testing it all

Now PiHole DNS should work. From any other client connected to the same Tailscale network as our PiHole machine, try out DNS resolving. I use the nslookup tool that can be installed on any Linux machine. For Windows or Mac machines: sorry, I have no idea.

First try:

nslookup en.wikipedia.org <vps tailscale IP>

This should return a successful response with the Wikipedia IP address.

Then try:

nslookup en.wikipedia.org <vps public IP>

This should timeout, because DNS is not reachable from the public internet, as we defined in the firewall and Pihole settings.

If you have different results go throught the previous steps and make sure you have everything configured correctly.

Configuring Tailscale DNS

In the Tailscale admin panel go to DNS settings, and under Nameservers enable the "Override DNS servers option" and add a new Global nameserver, paste the PiHole machine Tailscale IP. Not the public IP, the Tailscale one.

And boom, le voila por favor, now every machine connected to your Tailscale network will automagically use PiHole as its DNS server, and so will have ads and trackers cut out.

Restricting access to Admin Panel

As I said in the beginning, I am deploying PiHole on a VPS that also has other, publicly accessible services. And I don't want for the PiHole admin panel to be publicly accessible, it should also be restricted to only my Tailscale network. I also don't care that much about providing a TLS certificate for it, as it's shielded by the VPN.

Changing the admin interface port

To do that I went in the admin panel to All settings -> Webserver and API and in the webserver.port box I replaced everything in the Value box with just 8080. The current connection the admin panel will be broken if you do this change, but that's fine. Now in the VPS console run:

sudo ufw allow in on tailscale0 to any port 8080

This will do the same as with the DNS port 53, enable connections on the port 8080 only through the Tailscale network. The admin panel can now be accessed only through http://<vps_tailscale_ip>:8080/admin/

PiHole on the phone

To use PiHole on your mobile phone, just install the Tailscale mobile app and login to your account. No other actions needed, your phone will now use PiHole as the DNS, and a lot of unneeded or straight malicious traffic will be cut out, wherever you are. How cool is that?!

There's one downside however, the Tailscale application is a bit of a drain on the battery from what I observed, but I can life with that.

Bottom Line

And that's basically it. I have been running this setup for months now, and at this moment it would be hard for me to live without an ad blocker on all my devices. Thank you PiHole team for making such an awesome tool, and just a reminder that they accept donations for their hard work.

A few updates, a few milestones. My magic internet points are growing.

STFN — Sat, 31 May 2025 24:00:00 GMT

This will be a very short and simple blog post, but as I said in one of the previous ones, my aim for this year is to use this blog also for, well, blogging, and not only elaborate tutorials how to do computer shenanigans. I really like the word shenanigans.

Folding@Home

In the last few weeks I have been occasionally crunching Folding@Home. It's a nice change of pace after years of doing only BOINC.

So far I've reached a nice milestone of 2 million points, and we'll see how it goes from here.

F@H provided certificate certifying that I crunched 2.1 million points

As I'm used to the BOINC way of life, I found some things with F@H confusing. The web client is a nice touch, and something BOINC could use, but the way headless machines need to be attached to one's account is not that intuitive.

The fact that it is the system that decides which projects to send and not the user choosing projects is a bit weird, but I guess it's just a different philosophy, and it can allow for better matching of work units to the available hardware. But the biggest difference in my opinion is that F@H allows only crunching a single task for the CPU and another one for the GPU. In most BOINC projects I've seen, you can crunch one task per CPU core, and one or more tasks per GPU. In my Ryzen 3700x times, it was a joy to see 16 Universe@Home tasks being crunched at once.

Finally, in a very similar fashion to for example Einstein@Home, you get a lot, like a LOT more points per hour if you crunch on GPU vs CPU. Of course those are only magical pointless internet points, but still something interesting.

Leaving USA

I have finally migrated all of my self-hosted services from the US servers of RackNerd to the European ones of Hetzner. Looks like it mostly went without a hitch, with the exception of Umami losing some data. I guess it is because I did not pinpoint the version of its Docker container, and the one running on the old server was much older than the one I spun up on the new one. I migrated the PostgreSQL database 1:1 between servers and probably some schema changed between versions and I lost a bit of data, like the history of browser types. Not really an issue, I only collect that data because I like looking at graphs, it's not used for anything serious.

This article was super useful for me: How to dump & restore a PostgreSQL database from a docker container

The last service to migrate was this exact blog. So now the words you are reading come from Southern Germany. They are best enjoyed with a side of Käsespätzle

Actually, this blog post is the first one that will be sent to the new server. If you see it, that means I correctly reconfigured the Forgejo action that pushes it from my NAS to the VPS.

But what about AWS?

~~Yes, I am using Cloudfront as the CDN for serving media on this blog. Moving to a European CDN is on my very long todo list.~~

March 2026: I finally moved to a European CDN, and I wrote about it here: Goodbye AWS - moving from Cloudfront to Bunny CDN

New services

March 2026: I no longer use UptimeKuma because I haven't been using it actively. And I also got rid of selhosted ntfy and just switched to the free tier of their online offering, it's plenty enough for my needs.

I started two new services, mostly for fun and learning.

The first one is UptimeKuma. I now have a status page. It's running on my "dev" server and monitoring the services of the "prod" one. The whole installation, setup, and subdomain configuration process took less than hour. One gets proficient after doing such things tens of times :)

I also started using ntfy. I am selfhosting it on the dev server. It's running as a systemd service. Recently I started moving away from Docker and started using more of systemd. In contrast to some people on the Internet, I find systemd very practical and easy to use. You know who you are :) For now the only usecase I have for it is that I get a notification every night whether the Borgmatic backup of my GoToSocial instance finished successfully. When I find more usecases for it in the future, the service will be already there.

GoToSocial

A second nice round number is that my GoToSocial instance is now federating with 10 000 other Fediverse instances. 10 000 is OVER NINE THOUSAND! I am so happy to see that the Fediverse is strong, and there are so many independent instances. And 10k is not that high of a number. If I remember correctly, Piotr Sikora, the admin of pol.social said in his talk that that instance is federating with more than a hundred thousand other instances. That is extremely impressive <3

fedi.stfn.pl, home to 6 users who wrote 1716 posts, federating with 10155 other instances

I also reached a thousand followers on my English-speaking/IT account. Actually it happened for the second time, because I lost around ~200 followers when migrating from Fosstodon. Speaking of Fosstodon, they now have a totally new crew, and I wish them smooth sailing from now on.

And that's basically it, thanks for reading

How to make Pi-hole even more private and secure by switching to Unbound and adding extra blocklists

STFN — Wed, 25 Jun 2025 24:00:00 GMT

This is the next episode in my series on using Pi-hole, the previous ones are:

WireGuard and PiHole for secure ad blocking on your smartphone

Using PiHole and Tailscale to block ads on all my devices, including mobile

Wait, I just saw it took me three blog posts to realize that Pi-hole is written with a hyphen :O

A few weeks ago, my part of the Fediverse was full of discussions about DNS that were sparked by the DNS4EU controversy. Not going into details, a new service was announced, stating to provide DNS that is EU based and adhering to EU privacy laws. And it turned that most probably their way of operation is not as clear as they say. There is a very good writeup on this, which I recommend reading.

BTW, the Fediverse is the only social medium where DNS is a hot topic. And that's what I love about it, never change Fedi <3

That discussion made me realize that even though I use Pi-hole as my DNS server, its upstream (upstream meaning the next server it queries) is still Google. When my devices send a request to resolve the IP address of a particular site for the first time, Pi-hole forwards it to Google's DNS server, 8.8.8.8. And I do not like that.

At first I switched my upstream DNS to Quad9, which was several times suggested in the threads about DNS4EU. It worked just fine, I saw no issues with my day-to-day internet browsing, and changing the upstream DNS from Google to Quad9 is a matter of two clicks in the Pi-hole settings.

Pi-hole DNS settings, switching from Google to Quad9 means changing one checkbox

But as usual with computer stuff, there is still one level more. When I mentioned on my Fediverse account that I moved to Quad9, a few people suggested to move to Unbound instead. I heard that name a few times before but never got around to try it. So, why not take it for a spin now? And so I did.

Unbound

Unbound describes itself as a validating, recursive, caching DNS resolver. The official explanation of what that means can be found in the docs, but in short, the way I understand it, it means that Unbound does not query a single upstream server for all queries, but divides them per domain. So for example to get the IP address of one of the .com domains, it asks the .com DNS server, and for the .net it asks the .net DNS server. Unbound also keeps a local cache of all the queries that went through it so speed up subsequent queries. All that makes the users' internet life more private, as there is no one server that knows of all the queries a single user is doing.

Installation and usage

Pi-hole provides an excellent guide how to install Unbound and configure it so that it talks to Pi-hole. I don't think it makes sense to rewrite it here, so just go and follow it. The whole process took me maybe 20 minutes from start to finish.

In my case, I installed Unbound using apt on the same VPS that my Pi-hole is running. It has been running for almost a week now and I have not seen any degradation in speed or anything else. I think there is a tiny, tiny increase in the VPS's load factor, by 2-3%, but I cannot say for sure. Still, my basic Hetzner VPS's load rarely ever goes up over background noise.

After installation I set the log level to 3, just to see what happens, and yeah, it's not a level to keep indefinitely, in 24 hours the logs grew to around 150MB. I changed the log level to 1 and the logs stopped growing like mushrooms on a wet Autumn day.

Adding extra blocklists to Pi-hole

As I was digging around Pi-hole setting up Unbound I started thinking about maybe adding additional blocklists apart from the default one.

I did some searching and came across a Reddit thread about where to find blocklists. One source that was mentioned several times was a GitHub repository from a user called Hagezi, and this is what I went with.

I added the Multi PRO++ list to Pi-hole and the results for me are mixed. I have not seen any change when browsing the Internet using the web browser, mostly because in my Firefox, uBlock Origin already removes basically all shady stuff before it is being resolved by DNS.

What I did however observe, is more blocking of desktop and mobile apps calling home, as seen on the screenshot below. Mostly mobile, I was surprised how often Revolut is doing "stuff".

My top blocked domains from a period of light phone use. Still, mobile apps take the lead

I did not see any false positives yet, but then again, I don't visit that many "controversial sites".

All in all, the percentage of blocked request in Pi-hole changed from around 1.5% to 4%, but it fluctuates based on how much I use I phone, for reasons I explained above.

And that's it, I have to say that the combination of Firefox, uBlock Origin and Pi-hole does wonders, makes the experience of browsing the Internet bearable again.

Thanks for reading!

Installing Actual Budget expense tracker in LXD and serving it using Tailscale with TLS.

STFN — Thu, 03 Jul 2025 24:00:00 GMT

I decided I want to try out tracking my expenses, and after some research I went with trying out Actual Budget. I've been using it for a few days now and the outlook is promising, I will report my experiences once I use it more.

However, I had some issues when setting it up with LXD so I am writing down how I worked out a working solution here for others to benefit from. And for me for the time when I want to install it again, having the steps written down will help a lot :)

Prelude

First, let's sum up the situation. I have a homelab server running Debian 12. On that system I have LXD installed, LXD is an orchestrator for LXC VMs/system containers. Recently I have been preferring LXC from Docker, mostly for ease of backup and transfer of containers. As my homelab is moving to homeprod, I find continuity and stability of service to be the crucial part.

To access the services in the containers I am using static routing, the first method presented in this excellent video by Stéphane Graber. But in this case we will need this method only for local testing, later on we will move to accessing the container via Tailscale.

And so I want to install Actual Budget in an LXC container and be available even when I am away from my home network. I eventually went with the "Install from source" installation method described in the installation docs. I did not want to install it with Docker, and I could not make the "CLI Tool" method work for me in LXC.

Setting up the container

The description below is a result of several attempts of trial and error. A good thing with containers is that you can easily kill them and start anew. And I had to start from scratch a few times due to the requirements that Actual has.

Let's start with creating a new container. In the LXD Web UI, create a new container, I am using the Ubuntu 24.04 image, but in this case any will do, as a long as it has systemd. No special configuration needs to be done to the container. Once the container is started, go to the Terminal tab.

The next step is installing node and npm.

At first I installed node using nvm, but that caused issues with Actual, it could not find the node binary, so I started again, and just downloaded the node Standalone Binary (the green button on the download page) and copied it to /usr/bin. When downloading node, the tar archive also has npm. It can stay there, npm is only used to install yarn in our case.

Extract the downloaded archive, copy node to /usr/bin, and go the bin folder in the downloaded tar archive where you will find npm, and there run

npm install --global yarn

as described in the installation docs. yarn will be installed globally and we will no longer need npm.

Once yarn is installed, the container is ready and we can move to installing Actual. go through the rest of the installation steps below the Installing Actual and Linux systemd setup headers.

At the moment of writing this blog post, there is a typo in the systemd instructions, the correct location of the service file is /etc/systemd/system/actual-server.service.

Once the systemd service is up and running, you can access it via the IP address of the container (if you have set up static routing as I did, or by adding a proxy device listening on port 5006 of the container.

What you should see is an error page saying that you need HTTPS. Actual requires a HTTPS connection to work, there is no other way with it. So the next step is making your Actual container provide a HTTPS connection, and for that we will use Tailscale. Using Tailscale will have the added benefit of being able to access Actual from any place and not only our home network.

Setting up Tailscale

The steps will be very similar to what I wrote in the blog post about Nextcloud.

I recommend you go through it to understand the process, I won't repeat here everything I wrote there.

We will install Tailscale in the container, install nginx, set it up as a reverse proxy for Actual, generate TLS certificates using Tailscale and add them to the nginx config. In case of Nextcloud, the reverse proxy server is Apache because this is what Nextcloud comes with, for Actual I am using nginx because it is the one I am most familiar with. But any server software capable of handling HTML with TLS will do.

First, install Tailscale in the container using the console. Tailscale provides a handy install script that can be generated at their admin page.

Once Tailscale is installed and authenticated, a new machine will appear in the admin panel of Tailscale. The new machine will have a URL that Tailscale calls the Magic DNS URL, we will need it in the next step.

The next step is generating TLS certificates for the server. It can be done by running

tailscale cert <your MagicDNS url for that machine>

The certificates will be generated right in the folder when you run this command so run it for example in /root if you did not create a user other than root. Running that command should create two files, *.crt and *.key.

With Tailscale part done, time to install and set up nginx. Nginx can be installed with apt

sudo apt install nginx

After installation nginx will start working right away and respond on the default port 80. You can confirm that by opening the container IP address in the browser without providing a port number, you should see the nginx default welcome screen.

Nginx installed, now it needs to be configured. Create a new file, called actual in /etc/nginx/sites-available/ and paste:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    
    server_name <CONTAINER_DOMAIN_URL>; # URL copied from Tailscale admin

    ssl_certificate /root/<CONTAINER_DOMAIN_URL>.crt;
    ssl_certificate_key /root/<CONTAINER_DOMAIN_URL>.key;

    location / {
        proxy_pass http://127.0.0.1:5006; 


        proxy_set_header Connection $http_connection;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        client_max_body_size 512M;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location / {
        return 301 https://$host$request_uri;
    }
}

Replace the URL with the one copied from the Tailscale admin. With the configuration created, it has to be applied so that nginx can use it:

cd /etc/nginx/sites-enabled
ln -s /etc/nginx/sites/availables/actual .
rm default
nginx -t
systemctl restart nginx

The link to the default file needs to be removed, and then the nginx configuration can be tested with nginx -t. Once it is confirmed that the config is valid, restart the service to load the changes.

And that is all, you should now be able to access Actual in the browser by using the Tailscale machine URL. And it will work over HTTPS, making Actual happy. What is more, thanks to Tailscale, you will be able to use that URL on any device logged into the Tailnet, not only on your home network.

Bottom Line

I find LXD and Tailscale to be a very powerful combination, making running services straightforward, stable, and easily reachable from any place. So far I have used this solution to run Nextcloud, Actual, and Forgejo. I might do another blog post on Forgejo, how I have it configured together with Actions to have my own CI/CD pipelines locally.

I am also considering moving to Incus, as I heard good things about it and from what I found so far, the migration should not be that hard.

A real test of my LXD set up will be reinstalling my homelab base OS which I plan in the near future, mostly to free the server from all the crud and leftovers of failed experiments that I accrued over time. With that will come exporting and then importing again my LXC containers and I hope it will go smoothly.

And that's basically it, thanks for reading!

Continued adventures with LXD; Grafana, InfluxDB, and ZFS storage

STFN — Tue, 08 Jul 2025 24:00:00 GMT

I've got this idea that I want to try out: A Dockerless homeprod.

The emphasis here is on prod, because I will still be using Docker for testing out stuff and learning, but for my home "production" I am migrating from Docker to other solutions like LXD, for reasons I described for example in Deploying Nextcloud locally with LXD.

And speaking of that Canonical-owned container and VM orchestrator, this post is another entry in my LXD road.

Moving my monitoring stack to LXD

The service that I have been running the longest in my homelab journey has been my monitoring stack. Currently it consists of:

Prometheus
Node Exporter
Smartctl Exporter
Telegraf
InfluxDB
Grafana

There have been also other services used in the past like speedtest-exporter, but those were dropped because I was not interested in them enough.

The stack has two paths the data is flowing. The first one is Node & Smartctl Exporters -> Prometheus -> Grafana, and the second one is Telegraf -> InfluxDB -> Grafana. I have it configured this way because (at least to my knowledge) Telegraf can fetch some metrics that Node Exporter cannot, like GPU or ZFS statistics. Eventually all metrics go into Grafana and are presented there.

Until now this stack has been running as this mix of technologies: Node Exporter running on bare metal as a systemd service, and everything else in Docker, combined in a single Docker Compose file.

I decided to split it between data collection and data presentation layers. Prometheus, Exporters and Telegraf go to bare metal and InfluxDB and Grafana go to an LXD container.

The first is to be done, the second part is already in production.

Installing Grafana and InfluxDB in a container turned out to be very simple, both have very good documentation (Grafana) (InfluxDB), and installing them in an Ubuntu 24.04 environment meant adding a repo, installing them with apt and starting them as systemd services.

What was a positive surprise for me, was that in order for Grafana in a container to listen to Prometheus on the host, I just had to set the Prometheus URL as <<host_ip>>:9090 in Grafana data sources. I suspected it might be more complicated, but I guess that is result of the default LXD network being a bridge type. Networking in LXD is still in many ways a mystery for me.

And similarly, to send logs from Telegraf to InfluxDB, all I had to do was provide the container IP in telegraf.conf:

[[outputs.influxdb_v2]]                                                                                                    
  urls = ["http://10.54.60.34:8086"]

Adding a LXD Dashboard to Grafana

All that digging in Grafana made me think that it would be nice to have a dashboard showing information about LXD itself. And that was very simple because LXD has a Prometheus integration available straight out of the box.

LXD has excellent documentation on how to set up the whole pipeline to send metrics and logs to Grafana:

How to monitor metrics

How to send logs to Loki

Set up a Grafana dashboard

Loki is something I have not touched before, maybe I'll investigate it more to see if I can apply it as well to my other services.

And le voila por favor:

The Grafana Dashboard for LXD

What is peculiar is that LXD believes I have 180GB of RAM. While I would love that to be the truth, it sadly isn't. I'm guessing LXD multiplies the amount of RAM I have (~32GB) by the number of running containers (six).

Grafana showing I have 180GB of RAM

Moving my LXD storage pool

The final change that I did was I moved my LXD storage pool from my boot drive to one of my ZFS pools.

One reason was that the boot drive was running out of space, and also I wanted to have my LXD storage protected by ZFS features like copy-on-write and RAID1 (I know, I know, RAID is not backup, but it is better to have two disks than one).

A ZFS storage pool can be created in the LXD Web UI. I created a pool in my large-data pool, and vms dataset. The process is described in LXD docs: How to manage storage pools

My ZFS storage pool in LXD Web UI

The effect of creating an LXD pool in ZFS can be seen by running

zfs list -t filesystem

List of datasets in ZFS created by LXD

LXD also allows migrating the storage of existing containers from one storage pool to another with just a few clicks, but the containers need to be stopped.

Storage Pool migration dialog in LXD Web UI

Overall I am amazed how powerful LXD and how many built-in tools it provides to handle both day-to-day and one-time tasks.

The incessant crunching

There is however one thing I did not foresee.

Both my ZFS pools are two disk mirrors of HDDs. And usually they have seen very little activity apart from the occasional copying of data to and from. But now, when I moved my containers to one of the pools, the disk see constant activity, writing logs and doing other continuous tasks. And those HDDs are of the louder variety, being semi-professional NAS grade (one is a WD Red Pro and the second one is Seagate Ironwolf). Which means there is now and endless stream of crunching coming from under my desk, and I do not like that.

I already have a solution planned for this, and hopefully I will write about it in my next blog post.

The bottom line

This has been another episode of my homelab journey. After a few relatively quiet months I'm back on on track of tinkering and experimenting, and I have a lot of plans for my servers. I strongly believe that a homelab is most often in a temporary state, and there is always something to change. Then again, as most of my homelab is homeprod, I need to be more careful, better plan the changes, focus more on backups and recovery, and basically behave more like a sysadmin having responsibilities. Move slowly and fix stuff :)

And that's basically it, thanks for reading!

State of my homelab in June 2025

STFN — Sat, 12 Jul 2025 24:00:00 GMT

Almost a year has passed since I wrote the last State of my homelab update, and that means it is high time to write a new one. In the recent months my homelab has seen many changes, both in hardware and software, so there is a lot ot to talk about.

Networking

I recently wrote a blog post about my networking setup, so here let's just have a short summary:

At the time of writing the previous state of my homelab, my whole networking setup was a TP-Link Archer router/AP and an also TP-Link Wi-Fi extender.

Now I am running an almost solely Mikrotik setup, with the most important part being a Wi-Fi mesh system built on two Mikrotik Audience access points. The second Audience also works as a provider of wired ethernet to a PoE switch for a part of my homelab. More details in the linked blog post.

Main Server/NAS

The insides of my NAS

My main server is still my old gaming PC from 2015, which has now almost fully reached the status of being a Computer of Theseus. Currently the only part left of the original build is the motherboard, a Gigabyte GA-Z97-HD3. The CPU is an Intel Xeon E3-1275L v3, 4C8T low power server processor, still providing enough power to do anything I want with that server.

RAM is I think the main bottleneck here. 32GB of 1600MT/s memory in four sticks is relatively slow and gets eaten up quickly, especially by ZFS's cache.

The GPU is an Nvidia RTX 3060 12GB from EVGA. It finds it use in BOINC, for Jellyfin transcoding and a few other tasks. I will at some point write a blog post with a list of usecases for having a GPU in a homelab.

The thermals are okayish, the box lives under my desk for now, and in a room where I also sleep, so all the fans are set in the silent mode. The disks run at 40-45C, with the 2.5" SSD boot drive being the hottest one. The disks get cooler when the GPU is running, which would suggest that I need more exhaust fans. But that will happen once I move my homelab to a separate room in my future house. Then noise will not be an issue.

Storage

Having storage is important in a NAS [citation needed].

The boot drive is a 500GB SSD. It works, stores the OS, not much else to write about it.

Then there are the two ZFS pools. Each one is a mirror of two 4TB HDDs, one is made from a WD Red Pro and a Seagate Ironwolf. The second one is two refurbished HGST drives. Both are regularly scrubbed and so far do not show any problems.

The newest addition in terms of storage is a NVMe 1TB SSD in a PCIe adapter. It is also running a ZFS pool, a single-disk one. I mentioned in the last blog post on LXD that running a monitoring stack on spinning rust is causing a constant noise as the drives record data continuously. And this is my solution, I moved the more active LXD containers to this NVMe pool, and the NAS is again mostly quiet.

The new PSU

Old vs New

The most recent change to my main server has been the new power supply. I replaced a Bronze efficiency Seasonic with a Platinum efficiency BeQuiet! The new model is the Power Zone 2 750W.

At first I was planning a separate blog post talking about the change in power consumption when moving from a Bronze to a Platinum PSU, but I realized I do not have enough usable data and my test would be not scientific enough to allow me to make definite statements. Before I replaced my PSU I have been monitoring the power consumption of this server specifically for only a few days and I simply had not enough data for comparison. Also my GPU sometimes decides to idle at 15W and sometimes at 7W, further making it hard to compare apples to apples.

However, I can give a very general statement that I see an around 10% decrease in power consumption in my specific usecase, but as I said, take it with a brick of salt.

Apart from the better efficiency, the new PSU gives me future proofing by providing more power (550 vs 750W) and this fancy new 12VHPWR connector in case I someday want to add a more powerful GPU. Or if I want to have a core meltdown inside my case.

Software

In terms of software of my main server, I reduced a lot the number of services running there. The OS is still Debian 12. The container orchestrators are Docker and LXD. And the services are:

Immich
Jellyfin
Pinchflat
ActualBudget
Podgrab
Forgejo
Readeck
NextcloudPi
and the monitoring stack: Node Exporter, Smartctl exporter, Prometheus, Telegraf, InfluxDB and Grafana

I already wrote blog posts about some of the services above:

Deploying Nextcloud locally with LXD

Installing Actual Budget expense tracker in LXD and serving it using Tailscale with TLS

Continued adventures with LXD: Grafana, InfluxDB, and ZFS storage

Using Pinchflat and Jellyfin to download and watch Youtube videos

Writing a blog for almost three years now gives you quite a few posts to refer to :)

I've been using Caddy as the reverse proxy for my services, but now I am moving to reverse proxies installed directly in the LXC containers and serving SSL traffic via Tailscale, as I described in this blog post:

Access local Nextcloud with HTTPS anywhere by using Tailscale TLS certificates

Backup Server

The insides of my the backup server, it is a mess, I know.

Buying that new PSU left me with enough spare parts to build a second PC. I still find it amusing that I remember the times when there was The Family PC, a single unit standing proudly in its designated space and shared among the family members, and now everyone has at least one computing device and all of them are internet-connected.

Anyway, that second PC is a mix and match of different parts I had lying around. The motheboard is some Socket 1150 Asus with a i5-4460 Intel CPU, the exact one I bought in 2015 to power that first gaming PC. It still provides enough power for a headless machine, no problem. 8 gigs of some random RAM, a small SSD for the boot drive.

The case is an Akyga AK36BK, one of the cheapest available cases for the mATX format. It's special feature is being made of steel so thin, you can easily bend it with your fingers if something does not fit. The downside is space for only a single 3.5" HDD unless you resort to some weird actions like velcroing drisks together.

Glue my disks into clusters, this is my last resort

It's highlight and main reason to exist is the 3TB HGST hard drive. It's aim is to be the backup drive for my main NAS. I'm not able to fit everything on it, but the most important stuff like documents fits there fine. In the future I plan to buy a refurbished 16TB drive to be able to backup everything from my main NAS with some place to spare.

To copy over ZFS datasets between computers I am using a great tool called syncoid.

Power consumption is not an issue with this PC because the plan is to use it as a cold storage, boot it up every few days or weeks, copy over my NAS pools, do a scrub and turn it off again.

There is also a mystery PCIe board visible in the photo, but that will be the topic of an upcoming post :)

And with this machine I have almost reached the 3-2-1 rule of storage. For my most important data like documents or images, I have three copies of each file, and one of those copies is in the cloud (a Hetzner Storage Box).

Other boxes

One of the reasons I reduced the number of services running on my main NAS is that I divided them among other PCs:

ADS-B

For at least a year now I've been planning to a blog post about my ADS-B airplane tracking setup. But today is not this day. So in short: I have a Raspberry Pi 4b 4GB RAM, powered by a PoE HAT, running dump1090-fa software to track airplanes with the help of an RTL-SDR USB dongle and a DIY antenna. More on that in the future.

Home Assistant

The HA box, one of the Audience access points, and the printer which sometimes even works.

My Home Assistant box is a Lenovo Thinkcentre M625q. I wrote about the whole setup in the Using a Lenovo USFF PC as a Home Assistant box blog post.

At some point in the future I will need to reinstall Home Assistant though, as the development team is deprecating the HA Supervised install method, I will be switching to the HA OS.

Streaming Box

And finally (I dearly hate the phrase "last but not least") there is the Streaming Box that my wife uses. The box lives under her TV, and she uses it to watch Netflix and every other streaming service. The OS on it is Linux Mint, so that makes her a Linux user :) The box is Fujitsu Esprimo Q920 with a i3-4170T low power Intel. It usually works fine, but sometimes does not want to start, then I need to open it, wiggle the parts inside a bit and it starts again.

Bottom Line

And this is my homelab. To be precise, this is the "local" part of the homelab, I have not described my different VPSes that I am using, those will be the topic of another blog post.

This setup will probably last until the end of this year. If everything goes fine, somewhere around New Year's we will be moving to our new house, and things may change with the homelab during the move. But that also depends on the free budget I will have during that time, so nothing is set in stone.

Thanks for reading! I do enjoy writing those updates and I hope you enjoy reading them.

Automatically regenerate Tailscale TLS certs using systemd timers

STFN — Fri, 25 Jul 2025 24:00:00 GMT

In April of this year I wrote the Access local Nextcloud with HTTPS anywhere by using Tailscale TLS certificates blog post in which I showed how I am using Tailscale-generated certificates to access my locally hosted services with HTTPS. Since that time I have been happily using Nextcloud, Forgejo, and other apps via Tailscale with that glorious padlock visible in the browser address bar.

But today I could not access Nextcloud from my phone, the connection was erroring out. Further investigation showed that the TLS certificate generated by Tailscale expired. In contrast to what for example Certbot is providing, Tailscale certificates do not auto renew. And that is understandable, Tailscale is first and foremost a VPN service, and providing TLS certs is a secondary service for them.

I regenerated the certs manually, but that made me think, how to automate this task?

A quick Startpage query (still my favourite search engine) returned this Reddit thread and I thought it will be a perfect solution, but I will take it to 11. And by 11 I mean being notified whether the task finished successfully or not using using ntfy.sh.

I haven't yet wrote a blog post about ntfy, but one day probably I will, because it is an awesome piece of software. For now, in short, it is a FOSS pub-sub notification service, and I have it self-hosted on my secondary VPS. I also have its app installed on my mobile phone to receive notifications on the go. I use it for a few tasks, like informing that the Borg backup of my main VPS finished without errors. The service page is publicly available, but the topics are private and only accessible for me.

Going back to the regeneration of TLS certs, for this task I am using systemd timers because I like systemd and I think this task is a good exercise in configuring its timers functionality, but if you prefer cron, then sure, cron will also be a right choice.

Everything below is done in the LXC container hosting my NextcloudPi instance, but is generic enough to be applied to any machine, virtual or not, that is using Tailscale certs and a HTTPS-capable server like Apache or nginx (I never know whether to capitalize nginx and need to check it every time).

I started with creating a bash script that regenerates the certificates, sends a notification informing that the job finished or errored out, and finally restarts Apache. Super basic Bash stuff.

/etc/certs/script.sh

#!/bin/bash

tailscale cert TAILSCALE_MACHINE_URL && curl \
   -H "Authorization: Bearer NTFY_ACCESS_TOKEN" \
   -d "Tailscale certs updated for NextcloudPi container" \
   https://notifications.stfn.pl/ntfy || curl \
   -H "Authorization: Bearer NTFY_ACCESS_TOKEN" \
   -d "Failed to update Tailscale certs for NextcloudPi container" \   
   https://notifications.stfn.pl/ntfy && \   
   systemctl restart apache2

The script first runs the tailscale cert command which generates new TLS certs for the provided URL. If that command finishes without errors, the part after && is run, which is a curl request to my ntfy.sh server with a notification saying that everything went fine. If the Tailscale command errors out, the "or" (||) part is triggered, which is, again, a notification for me, but with an error message. I had no idea that bash provides such ternary operators, such a cool new thing to learn. Finally Apache is restarted to load the new certificates.

Then I created a systemd service:

/etc/systemd/system/tailscale-certs.service

[Unit]
Description=Update Tailscale TLS certificates
After=network.target 

[Service]
WorkingDirectory=/etc/certs/
ExecStart=/usr/bin/bash /etc/certs/script.sh

[Install]
WantedBy=multi-user.target

One important thing here is the WorkingDirectory line. The tailscale cert command creates the certificate files in the directory when it is run, so we need to define the directory for the service. The outcome of this service will be two cert files generated in the /etc/certs/ directory, and that location must correspond with the certs location defined in the Apache configuration. Consult my linked blog post for details.

Also the script must be executable (chmod a+x /etc/certs/script.sh).

With the script and the service, the last part of the puzzle is creating the timer. A great resource on the topic is once again the Arch Wiki, and this entry has been the main source of information for me.

It is important that the service and the timer share the same filename, this is how they recognize each other.

/etc/systemd/system/tailscale-certs.timer

[Unit]
Description=Update Tailscale certs twice a month

[Timer]
OnCalendar=*-*-10,20

[Install]
WantedBy=timers.target

The only interesting part here is the

OnCalendar=*-*-10,20

which defines that the timer has to run twice a month, on the 10th and 20th day of the month. Not providing the time means it will run at midnight UTC.

I chose "twice a month" because I think it's a reasonable time span ensuring that the certs will always be up to date, without flooding the certs service with too many requests.

Now the last thing to do is enable and start the timer by running

systemctl enable --now tailscale-cert.timer

systemd also provides a command to show the list of active timers, running

systemctl list-timers

should show the new tailscale-cert timer and the time left until the next trigger.

And that's it. I just need to repeat those steps for every container I am running, and my services should be safe from expired TLS certs. And along the way I learnt something about bash and systemd. I've been using Linux since 2006 and I learn new things all the time and still feel I've just scratched the surface.

Thanks for reading!

How I bought a Tiny PC and turned it into a GPU workstation / gaming rig

STFN — Sat, 23 Aug 2025 24:00:00 GMT

I have not had a desktop PC since spring of last year. At that time I sold my desktop because I felt laptops were enough for me, it was taking up a lot of desktop space and its configuration made any significant upgrades costly.

As time passed I start to miss the capabilities of a full size PC, mostly the power of a discrete GPU. Not only for gaming, but also for other stuff, like GPU acceleration for tasks like astrophotography postprocessing.

However, I cannot right now justify buying a whole large, powerful PC because I am in the middle of building a house, and every not-strictly-required expense is postponed until we move in and stabilize there. Also in our current flat space is always a constraint.

So what to do?

Last year I bought a Lenovo mini PC, an M625q, and it has been great as a tiny, low-power box running Home Assistant. With only two cores of an Atom-like AMD CPU, I would not try to use it for anything else.

Reading more about the Lenovo lineup, I came across something very interesting: Certain Lenovo Thinkcentre Tiny models have an PCIe slot, and allow for using a low profile GPU! That raised my attention. Maybe I could make a small box with a discrete GPU, and do stuff impossible on a typical laptop? By a typical laptop I mean something small with an integrated GPU, not those gaming beasts that look like an RGB brick combined with a vacuum cleaner.

Buying the base version

After doing research, I narrowed my search to the Lenovo ThinkCentre M720q Tiny. Those models have an 8th gen Intel CPU (three types available), DDR4 RAM and an NVMe SSD slot. And most important, they also have an internal PCIe slot for expansion cards!

Recently I have been doing most of my IT shopping on Vinted. I know, Vinted is mostly famous for buying clothes, but for some time now they have also an Electronics category, and quite a few people are selling their stuff there. The prices are good, and from my experience, the public is more reasonable than on the other large flea marker platforms.

After a few weeks of casual hunting, I finally bought the tiny computer. Inside was an i5-8400T CPU with 6 cores 6 threads, 8GB of RAM in a single stick, and a 250GB NVMe SSD. Power supply included. For all that I paid 580PLN (~140EUR), with shipping.

A week later it arrived, basically looked like new inside and outside. Despite that, I replaced the CPU thermal paste, because I had some lying around. On the software side, I removed Windows as quickly as possible, and installed Kubuntu 25.04, my go-to distro right now.

And from the start, it has been working like a charm. It's snappy in daily tasks, quiet, and has no problems handling dual 1440p displays. All in all, much better than the Lenovo T495 laptop I've been running for the last months, with only the portability being lost. But I'm keeping the laptop for those rare occasions when I want to take a computer with me somewhere.

With the basics sorted out, came the time to upgrade this smol machine.

The insides of the Tiny with everything removed to make way for the GPU

Upgrades

I started with upgrading the RAM. I replaced the single 8GB stick with two sticks of 3200MT/s 16GB DDR4 SODIMM RAM. With 32GB of RAM, I will be able to run things like large development environments if I ever want to. Also I feel like dual channel made it even snappier, but that may be a placebo effect.

I haven't yet upgraded the storage. With a separate NAS for storing all the stuff, the 250GB internal NVMe SSD is enough, at least for now, and I have some SSDs in external USB enclosures is I ever need more directly attached storage.

The GPU

But they main part, the part I have been eyeing from the beginning, has been the GPU. And putting a GPU in that tiny thing is a multi-step process.

The first thing to do is upgrade the PSU. The M720q uses an external power supply, the same as their pre-USB-C laptops, with a yellow rectangle plug. The one that came with the computer was a standard 65W PSU. To use the GPU, I had to first buy the 135W version to give it more juice. That was 90PLN (~21EUR)

Comparison of the PSUs, the 135W one on top

The second part needed is a 90 degree riser for the PCIe slot. Lenovo sells one for serious money, but I got a replacement from Aliexpress for 21PLN (5EUR). Took two weeks to arrive.

And finally, the GPU itself. The Tiny machine only accepts similarly tiny GPUs, meaning single slot and low profile. At first I was considering getting the AMD RX6400, but sadly, for the things I want to do, I need native CUDA support. I've heard there are now ways to run CUDA on AMD GPUs, but I don't feel like going into that rabbit hole. So the only option for me was going with the Nvidia Quadro lineup. The Quadro GPUs are aimed at workstations, and they are usually smaller, don't have the gamerly bling, and use less power, often not requiring an external power connector.

I was at first aiming at the Nvidia Quadro T400 as a good middle ground between price and power. The T in the name means the Turing generation, so the same as the 16XX generation of their mainstream GPUs. I did not want to go older than Turing because it's the oldest generation that still has ongoing driver and CUDA support.

But alas, good luck shined upon me, I found a T1000, a much faster model for a price close to the P400, so I went with that one. I too found it on Vinted, and it came from Lithuania. Came in two weeks, looking mint. The description was that it was removed from some Dell prebuild.

The card is a typical Quadro GPU, single slot, half length, low profile card with 50W max TDP, meaning no additional power connector is required. According to benchmarking sites, it's similar in performance to a GTX1650.

In contrast, my main homelab is now running an Nvidia 3060 12GB with 160W TDP which requires an additional 6+8 connector from the PSU.

Putting stuff together.

With all the parts delivered, the time came for the big ceremony.

To install the GPU, first most things need to be removed from the PC. This model of ThinkCentre allows two hard drives to be installed, one is an NVMe in an M.2 slot in the motherboard, and the second one is a 2.5" SATA SSD in a caddy. The caddy takes the space for the GPU so it had to go. I also removed the WiFi card and its antennae. Antennae? Antennas? Aerials? Those gizmos. With that, there was space for the GPU. I first connected the GPU with the riser, and put them into the PCIe slot in the motherboard.

The GPU installed

One thing I have not resolved in advance is the bracket. To mount the card to the back of the box a special bracket is required, but it turns out the card can live without it. It just lies on the back wall of the case, and it's fine as long as nobody pulls too hard on the monitor cables. I found out it can be 3D printed, and that is what I will do once I have a printer.

The first start

The card came with a miniDP to Display Port adapter, so I used it to plug one of my monitors to the first output socket on the card, and with the case still open, I pushed the On button. And it started, the fans came on, video output live, Kubuntu launched like usual. I now have a usable GPU! The next thing for me was to install the CUDA drivers that I need for some of my workloads, but that is a story for another episode.

Gaming

I would not call myself a gamer, I just like playing a few games, and I've been playing the same three or four games for the last decade. The main hope I have had of this GPU was to be able to play Civilization V on high settings.

And indeed it runs and is playable. The game is not as snappy as on my old desktop, but that one had a 16 thread Ryzen 7, so a totally different league.

The thermals

I played the game for 15 minutes, all happy, ignoring the blaring fans... and the computer turned off. When I touched the GPU, I burned my finger. Turns out that even without the case, and the fans at full speed, that tiny blower fan is not able to cool GPU enough to stop it from shutting down from thermal overload.

The rescue came from my Drawer of Random Cables accompanied by the Box of Random Computer Parts. Below is the result of the cooperation of that magnificient duo.

A long time ago I bought on Aliexpress a "female barrel jack to 3 pin fan header" cable, and I have a BeQuiet 120mm fan lying around. I took the fan, the cable, and a random 12V wall wart, and with the help of some zip ties and, I think, legs from an old desk lamp, I placed the contraption above the PC. Yes, I am a hoarder, but sometimes that helps.

The result in all its glory

I admit, it looks awfully janky, the combined fans are so loud I can only play in ANC headphones, but it works, I'm now able to play as long as I want. According to nvtop and htop the CPU and GPU temps are around 60-70C.

The bottom line

So yeah, this pile of mess looking like something from Fallout is now my workstation/desktop PC/gaming rig. Maybe some day I will make it nicer, make a 3D printed case to with a place for the fan, but for now it works. All in all, I am very happy with it, it uses very little power (proper power consumption measurements to come), even with that fan and cables it is indeed tiny, and allows me to do more stuff than with just a laptop.

Thanks for reading!

How I built an off-grid, solar powered webserver and exposed it to the Internet

STFN — Thu, 04 Sep 2025 24:00:00 GMT

Here is my newest project: a webpage running on an off-grid server powered solely by solar panels.

solar.stfn.pl

The Background

I am in the middle of building my house. I mean, I am not building it personally, the construction workers, plumbers, electricians are doing it. The house is in the middle of a piece of land my wife and I bought in 2022. Next to the house there is a shed which we have been using to store gardening equipment and other random stuff. It also served me as a shelter during the cold nights when doing astrophotography and star gazing. While the house will eventually have electricity from the grid, the shed will be kept off-grid.

As the construction is moving on, the people building the house convinced me to buy a cctv camera, so that I can monitor the site and at least its presence will deter any bad guys. I ordered a DTV solar powered security camera with a SIM slot to stream video over LTE. Or so I thought.

When it arrived, I realized I made a mistake, I ordered a wrong one, the one that I ordered was a WiFi one, not LTE, so it would need a separate source of Internet to share its feed.

What I could have done was return it and get the proper one, but I do not like the hassle and awkwardness of returning things, and most of all, I decided this is the perfect moment to do what I have been wanting to do for a long time: Build an off-grid PV system for the shed that could power a separate LTE router and share WiFi for the camera, as well as for people visiting the site, maybe even allow to occasionally work from there. And so the project started.

The PV system

I already have some experience with building 12V powerbanks (blog post: A DIY off-grid 12V powerbank), I "just" needed to add the PV part to charge it.

The solar panel

At first I was thinking of buying a small 30-50 Wp solar panel. But as I was browsing the local marketplace sites, I found a person who was selling lightly used PV panels, as he was replacing them with more powerful ones. The panel barely fit in my VW Polo, I had to drive very carefully because its side was right next to my head, but I managed to transport it to my site, and now I was the proud owner of a 330 Wp PV panel for which I paid only 100PLN (~25EUR). The main issue was securing it to the roof of my shed, but after pondering, I decided it's heavy enough to just put it on the roof as is. I bolted a metal bar I had from an old project to the back of the panel to make it even heavier and harder to overturn. My shed is low enough to allow me to just push the panel onto the roof with the help of a small step ladder. The metal bar is mounted on the top of the panel so that it goes over the rooftop, so the panel cannot slide down. It also makes space on the sides for the cables.

The panel with the metal bar.

The panel is raised a bit so that the cables can go under its side

Cables and connectors

For the cables connecting the panel to the rest of the system I went with dedicated solar panel cables. Those are thick cables in very hard coating that is resistant to weather and UV rays. The panel itself has short cables going from its underside, terminated with standard PV MC4 connectors. I terminated my cables on one side with the corresponding MC4 connectors, and drove them through the wall of the shed.

Cables going through the side of the shed. They do not have connectors at the second end, so I could just drill holes the size of the cables.

The PV controller

I chose a typical cheap PV controller, that proudly boasts that it can handle 20A, but I would not trust it with half of that value. The controller has three sets of screw connectors, one for the PV panels, second one for the batteries and the third for the output. It's main goal is to protect the batteries from both overcharging and overdischarging, if the battery voltage falls below the predefined value, around 11V, it will turn off any devices connected to it. There are hundred of models of such controllers available, I just went with a cheap, simple one, this project does not require anything special. Big Clive made a few interesting videos about solar controllers, and I highly recommend watching them before buying one.

Big Clive: Exploring a Mass Produced Solar Charge Controller

Big Clive: 10A vs 100A Solar Charge Controllers

The USB charger and cables

One of the features I wanted to have from the solar installation is being able to at least charge my phone from a USB socket. It took me quite a while to find the USB charger in line with what I needed. I finally found one in the area of car accessories. And that makes sense, cars have internal 12V electrical installation and people in them want to charge their phones. The one I bought fits into the place of a cigarette lighter / 12V output and provides two USB-A ports. The maximum it can output on a single port is 2.4A, which is enough even for a Pi 4b, but only if it runs without power hungry accessories. For a Zero it is way more than enough. The installation was simple, in my set of hole saws I had one with exactly the right diameter, I drilled a hole in the tool box, put it the charger and secured it with a provided ring.

I connected the batteries with the controller using a thick 12 AWG cable with a 20A fuse. The output side I did with a thinner, 18 AWG cable, as I do not expect high loads. I used WAGO connectors to create a parallel connection between every power output, the USB charger, the XT60 sockets, and the cable for the LTE modem.

The toolbox working as a place to store all of the power components. On top of it there is also a 220V voltage converter powered from the batteries. On the desk there is the webserver Pi, and an IKEA lamp converted to use 12V DC.

The inside of the tool box with the batteries, the controller, and all those cables.

Zoom on the internals of the tool box

Side of the box with the external connectors visible. The blueish cable is the micro-USB powering the Pi.

The 220V power converter

A part of the power system that is not being used in the solar webserver project is the 12V to 220V power converter. I think it is nonetheless important to mention it so that you can omit the mistake that I did. I first connected it to the PV controller, as you can see in the attached photos. But it quickly turned out that often on startup it would overload the controller and make it to reset. I'm guessing the converter charges some capacitors on startup and draws a very high current, killing the PV controller. What I did is connect it directly to the batteries. It has its own overdischarge protection, so it will not harm the batteries if used for too long. And now I have a source of standard 220V power to, for example, charge a laptop or a cordless drill battery.

Internet gateway

The gateway to the Internet for the Pi is a Mikrotik LTE AP outdoor router that I also managed to buy second-hand. I mounted it outside the shed and put a standard barrel jack cable through the wall to power it from the PV controller. The router creates a Wi-Fi network for the Pi to connect to, and has an LTE modem to talk to the Internet. I have a limited data quota on my deal, so I am monitoring the traffic usage on the mobile company user portal. So far the webserver has been only using a few megabytes per day of traffic. There is no special configuration on the Mikrotik, just typical 2.4 Ghz Wi-Fi.

The Mikrotik router/modem fastened to the wall of the shed.

And with that, the initial Wi-Fi part of the installation was done. The camera has been working without issues, I can check what is happening at the site using my phone. Sadly, only by using a proprietary app from the vendor. But this is just a temporary solution, once the house is built I plan to move to standard IP cameras and record the feeds using open source software like Frigate.

Moving Further: Making a webserver

With the Wi-Fi done, I started thinking about other possible uses for the installation that I built. And I thought that it would be awesome to use it to make a solar powered webserver and host my own, personal website. And so I went this route.

The choice of hardware was simple, a Raspberry Pi Zero W in my drawer of Pis, waiting for better times was the obvious choice. I added to it a BMP280 pressure/humidity/temperature sensor to gather some environmental data. The USB charger I mentioned before became the power source for the Pi. Exposing the Pi to the Internet had been an issue until I learned I can go over (CG)NATs using Wireguard. And with all of the components in place, off I went.

The Server

The hardware is just a Pi Zero W in the official Pi case, absolutely nothing interesting to talk about here.

For the server software, I went away from my typical Nginx setup and chose Lighttpd, because it is, well, light. The website is static HTML (well, not exactly static, but from the perspective of the webserver it is, more on that later), so configuring the server was only a matter of cloning the git repo to /var/wwww/html and modifying the config file:

Below are only the lines I added or modified. I added the mod_accesslog server module to monitor traffic, and configured the file that stores the access log. I also changed the server port to 81, as this server does not handle traffic directly, but is downstream of a reverse proxy that actually serves content on port 80.

/etc/lighttpd/lighttpd.conf

server.modules = (
        "mod_indexfile",
        "mod_access",
        "mod_alias",
        "mod_redirect",
        "mod_accesslog",
)

server.port = 81
accesslog.filename = "/var/log/lighttpd/access.log"

Exposing the website to the Internet

Finding a good way to expose a locally hosted webserver to the Internet has been a big problem for me for a long time. The breakthrough came when I learned that I can use Wireguard VPN to punch through NATs. This method requires to also have another server, that is publicly accessible to be a proxy between the local server and the wider Internet.

This of course raises a question, is this website actually solar powered when making it work requires another server in a datacenter? One could say no, but I think that well, packets flowing through the Internet pass a lot of different servers either way, then there are the mobile signal towers, the DNS servers and all the other components that run to make the Internet work. So having a VPS on a machine in a datacenter that is running either way does not make a difference.

For the public server, I am using a Hetzner's VPS which I have been already using for different tasks. It does not have to be powerful for being a proxy, all it does is run a webserver that passes the traffic between the Pi and the Internet. The VPS also handles the TLS certificates for the HTTPS to work. The TLS certificates are configured using Certbot, which makes obtaining and configuring them very easy, basically a single command. The domain also points to that public server.

The Pi and the VPS are connected using Wireguard. I already described how to do a typical point-to-point Wireguard connection in my blog post about PiHole, you can consult it for reference:

WireGuard and PiHole for secure ad blocking on your smartphone

However, I want to show you the Wireguard config file on the Pi, because it has one important part:

[Interface]
Address = 10.8.0.3/24
PrivateKey = <Pi private WG key>

[Peer]
PublicKey = <server public WG key>
AllowedIPs = 10.8.0.0/24
Endpoint = <server public IP address>:51820
PersistentKeepalive = 10

The crucial part is the PersistentKeepalive stanza in the config, which ensures that the connection is being kept up all the time, and so the server can continuously communicate with the NATed Pi.

On the public server I am running Nginx, because I am used to it. Here's how it is configured:

/etc/nginx/sites-available/solar

server {
    server_name solar.stfn.pl;

    location / {
        proxy_pass http://10.8.0.3:81;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/solar.stfn.pl/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/solar.stfn.pl/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    if ($host = solar.stfn.pl) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name solar.stfn.pl;
    return 404; # managed by Certbot

Most of the lines here are automatically added by Certbot, and so are not interesting for us. The most important part is the location dictionary. Here it is defined that Nginx works as a reverse proxy, passing requests from the clients to 10.8.0.3 which is the Pi's Wireguard IP address. Nginx contacts the Pi on port 81, because it itself is listening on port 80 for traffic incoming from the wider Internet. Remember that port 81 needs to be opened in the VPS's firewall.

Pyriodic Backend

At the top of the webpage there is a green box showing the current climate data inside the shed, and some statistics about the Pi itself. How does it work when the page is static HTML? This is where my newest pet project comes into play: Pyriodic Backend.

Pyriodic Backend is what it says in the name, it's meant to be a very simple backend service, written in Python, for handling periodically updated data.

How it works is that the backend service runs every minute, powered by cron, and with every run, it loads the HTML files of website, and replaces the value of specific tags using the output of functions connected to those tags. Pyriodic Backend uses BeautifulSoup4 behind the scenes to do the HTML manipulation. The project is currently in a very early alpha stage, but as you can see, it is already being used "in production". The repo is open source and under the GPL license. You can check it out on Codeberg, and if you would like to develop it with me, please feel free to create an issue or send me a PR. My goal is to make it a universal, very light and simple backend for static websites.

Pyriodic Backend on Codeberg.org

Next Steps

I'm already thinking on how to upgrade the system. Because of the large size of the solar panel, I am considering moving to a Pi 4b connected to the router via an ethernet cable. This should reduce a lot of the instability and latency caused by Wi-Fi. If the PV system starts having trouble with recharging the batteries during short winter days, I'll just go back to the Zero. I would like to add much more things to the website, but then the bottleneck will be the speed of the Internet, and the limited data quota I have. My plan is to gradually add stuff, and see how the performance and data usage changes.

I also would like to add battery charge monitoring for the website. I already did a project focused on measuring the charge of 12V batteries:

How to monitor 12V battery charge with a Raspberry Pi Pico

but I need to find a way to connect it with the Pi and the backend.

And eventually I will move the house that is being built next to the shed, and when I have better Internet and equipment there, I will be able to expand my website even more.

Bottom Line

And that's it! I haven't been so excited with a project for a very long time. I feel that writing a website from scratch using the simplest possible technologies is a turning page for me, and gives me so much fun. And I am happy that I can share both the hardware plans, and the software with you, especially the Pyriodic Backend. I am hoping other people will use it for their projects. If you do, please let me know!

And being able to physically host a webserver offgrid, with the only requirements being the Sun and a bit of LTE coverage, I feel that it opens so many possibilities. And it feels both #SmallWeb and Solarpunk, two movements that are very dear to me.

If you want to build a similar off-grid server, and have any questions, just drop me an email, I will be happy to help :)

Thanks for reading!

Today I TIL; Mikrotik NTP support and the surprise use of octal counting

STFN — Mon, 08 Sep 2025 24:00:00 GMT

This is hopefully the first post in the "Today I #TIL" series. Yes, I know :) Hi Amin:) The idea is to make shorter blog posts about one or two new things that I learned more or less on the same day as the blog post.

Today something unsuspecting happened. I was working away, writing Python and all that stuff, when the Internet broke. I had WiFi, but no Internet access. I assumed my ISP was acting up again, but this is was something different. To cut the story short, my WiFi bridge (described in this blog post) stopped working, and I had to restart one of my Audience access points to make it work again.

But that's not the main story. When I was browsing through WinBox (Mikrotik's configuration software) I came across the NTP section. And so I learnt that Mikrotik devices (I guess most of them?) can work as an NTP server, an NTP client, or both.

NTP, Network Time, Protocol, is the way computers share information about the time. There are NTP servers that have very precise clocks, which tell other computers which time it is. And this can work in a cascade, any computer can be an NTP server, get the time from an upstream NTP server, and share it amongst its peers.

Jeff Geerling made a few interesting videos about NTP and Raspberry Pis.

And so I thought that it would be fun to set up my Mikrotik router to get the time from some proper NTP server and share it in my local network. Yes, I know, I have a rather special definition of fun. But you, dear reader, are reading this post, so probably we have something in common.

First I looked for a suitable time server. I wanted something relatively local. And a quick search resulted in this: Główny Urząd Miar (in Polish). Turns out, a Polish governmental organisation, Główny Urząd Miar (Central Office of Measures) runs their own NTP servers, and they are located in the "Laboratory of Time and Frequency", which sounds like a super cool place to work.

With the server chosen, I went to configure NTP services on the router. And that is very simple, Mikrotik's NTP docs say it all.

This is how I configured my NTP server and client on the router:

Screenshot of the Mikrotik's configuration showing the NTP client and server windows

I added two CIDR ranges because my access points create a second NAT, so the devices connected straight to router are in the 192.168.88.0/24 range, the ones connected over Wifi are in the 192.168.10.0/24 range. I could probably modify it to have a flat single range, but I just don't want to touch the Audience's configuration.

And le voila por favor, my Mikrotik router is now an NTP client, taking the time from the Laboratory, as well as a local NTP time server, being able to share the time with other machines.

Now, time to set it on the clients. Right now, all of my devices run either Debian or Kubuntu. My desktop is running Kubuntu 25.04, and there time is handled by the friendly named systemd-timesyncd service.

Changing the time server from the default, Ubuntu's one to a different one is a matter of changing the /etc/systemd/timesyncd.conf. To add a custom server, uncomment the line starting with NTP and add the address of the server. Now just

sudo systemctl restart  systemd-timesyncd.service

And the new configuration can be confirmed by running

timedatectl timesync-status

The response should show the new server being used.

Now, on my Home Assistant box I am running Debian which uses the (I'm guessing) older ntpd daemon to get the time, and here things got more interesting.

On Debian, changing the time server requires modifying the /etc/ntpsec/ntp.conf file. I added server 192.168.88.1 above any other server or pool line.

Then it's just running

sudo systemctl restart ntpd.service

and it should be fine.

To confirm the change was done, run

ntpq -p

If there is no such program, install it with

sudo apt install ntpstat

For me the result of running ntpq -p was

     remote                                   refid      st t when poll reach   delay   offset   jitter
=======================================================================================================
*_gateway                                194.146.251.100  2 u   18   64  377   0.2879   0.0059   0.1151

The mysterious "reach" number

Everything in the output of this command was relatively clear, expect for the reach part. It was changing in a seemingly random way, and the ntpq documentation was not clear on the matter.

Thankfully, I found this site that explained how beautifully weird it is.

The reach value describes eight bits of information, each being 0 or 1, but in octal. That sequence is the history of connecting the server, and each of those eight bits describes whether the connection was successful (1) or not (0). Those eight bits are then converted to octal. 11111111 (eight good connections) is 377 in octal, and so 377 shows no problem with connectivity. A better and more thorough explanation can be found on the linked site. Why did they do it? I don't know, but I am sure that a group of very smart engineers have had very good reasons to do so.

Bottom Line

Today I #TIL that

Mikrotik hardware can work as an NTP server and client
Poland has a Laboratory of Time and Frequency
ntpq has some fascinating quirks

Is this knowledge useful in any way? Not really, but does knowledge need to be useful? I don't think so. I hope there will be many more such #TIL posts to come.

BTW, this is the first post that I wrote using only the zed editor in vim mode. Using vim keybindings is still often a pain, but I am persevering like a Martian rover, and every new keybinding that I learn is a spark of joy.

Thanks for reading!

Preparing for my future house; building a 2U NAS from scratch

STFN — Fri, 26 Sep 2025 24:00:00 GMT

As I already mentioned several times, I am in the process of building my future house. One of the things I look to having the most, is a separate technical room. It will be mostly for things like the heat pump and the electrical box, but it will also have the space for a server rack. Which means I will be able to move my whole homelab, both the networking and computers, into a single place.

This also means that I can convert my servers to be rack mounted, which makes me very excited, and feeling almost like an adult sysadmin.

I prefer to work in small iterations, see what happens and decide what to do next. That works better for me rather than making grandious plans from A to Z. That's why I decided to first rackify (is that a word? Let's make it a word) my small, backup server, see how it goes, what are the issues, etc, and later on, with new experience, work on transferring my main NAS/server to a rack case.

And I think it was a very good decision, based on what happened with this build.

The initial state

I built my the first generation of my backup server mostly from parts leftover from earlier iterations of other computers.

BTW, I still find it fascinating that I remember the times that there was the Single Family Computer In The Computer Place, and now I have several different compute devices in all shapes and sizes, and a box of surplus computers parts. But I digress.

How it looked like at the beginning.

The motherboard was some old Socket 1150 with a Haswell i5-4460, 8GB of RAM in total. There was also a Mellanox X-3 10G SFP+ network card which I have not used, but bought for future use. The boot drive was some random Silicon 128GB SSD, and the main storage drive was a 3TB HGST 3.5" HDD. The PSU was some basic 500W Seasonic.

I wrote about that server in more detail in my State of my homelab in June 2025 blog post.

Since the beginning, the aim of that server was what I like to call "lukewarm storage", the intermediate between cold and hot storage. Meaning I would start it every few days or weeks, depending on how much changed on the main NAS, copy the files and scrub the disks.

This was the basis for moving to a rack case, and I thought it will be a quick and simple move. Yeah.

Moving to a rack case, first try

For the rack case I went with a Netrack 2U 390mm case

I chose this one because it was cheap, and the description said that it can fit an ATX PSU and a mATX motherboard, so I assumed that I can just move the existing components from one case to another. It also has good cooling of the drives, which is a must for me. The reviews were mixed, but I yolo'd it, and made the order.

The case arrived, and looked sturdy, made from thick metal. The overall build quality is okayish, there are some rough edges, but it's not meant to be a show piece, it will live in the technical room.

The first thing I did was to replace the two provided front fans. The ones that came with the case were MOLEX fans without any PWM. I replaced them with a pair of basic Arctic 80mm.

Then came the time to assemble the rest of the component, and this is where things became very interesting.

First iteration of the server fully installed.

The first problem was that when using an mATX motherboard, there is space only for two drives, as the bottom brackets of the disk caddies are too close to the motherboard. This was the less important issue, as I had only two drives in total.

The bigger problem was the PSU.

Again, the description of the case that an ATX PSU would fit inside.

And that was technically correct. And well, the PSU did fit, but it was flush with the full metal sides of the case, leaving absolutely no space for ventilation, as can be seen in the photos.

PSU sitting flush with the case

Enclosed from all sides.

I installed and connected everything, and run the server with the case opened and the PSU not screwed down. The server indeed run but it was not a reasonable solution.

And then I went for holidays.

Getting new parts

During the holidays, I made some research and found a solution to my problem. Turns out Chieftec makes a PSU specifically for such a use case, with both inlet and output holes on the smaller sides, allowing it to be placed in 2U enclosures.

Chieftec PSF-400B

It was relatively cheap, at 200PLN (~50EUR), and my only hope, so I ordered it towards the end of me being away, so that it would arrive on the day I was back at home.

Also one rainy day I was a bit bored, and I was browsing Vinted, and I found a very good deal on a AM4 motherboard with a Ryzen 2200G CPU and 16GB of RAM. The motherboard looked smaller than that Socket 1150 I had, so I hoped I could fit more drives into the case. The Ryzen was a G, meaning built-in graphics, so I would not need a discrete GPU, just like with that Intel. And ZFS could for sure use some more processing power and more RAM. So I ordered it as well.

Another upside of moving to an AM4 board was that it had an M.2 slot, so I could ditch the 2.5" boot SSD. For the boot drive I did another yolo gamble, and ordered a second hand 32GB Intel Optane M.2 NVMe. I don't need a lot of space, this PC will be strictly a storage server, no Docker, no services, so 32GB is plenty enough for Ubuntu Server (I went with Ubuntu because of good ZFS support), and from what I've read, Optane has greater endurance in comparison to basic NVME SSDs.

The final issue was cooling. The AMD stock cooler is simply too big to fit a 2U case, so I went looking for solutions. And the solution was on Aliexpress, I found there an AM4 server cooler designed specifically for 2U cases. It was 70PLN (~16EUR).

AMD stock cooler goes out.

2U cooler goes in.

COOLSERVER!

What is very important is that it is made by the COOLSERVER company, and so confirms that this build is a server. And it is cool.

Second try with new parts

The assembly was straightforward, I remove the previous parts, they will probably be sold, and I installed the new ones.

The PSU, well, let's just say it does raise much confidence with how it looks. It was sold in "bulk case", which meant I got in a random gray box wrapped in bubble wrap, there weren't even screws provided with it. But exactly for such cases I have my Drawer of Random Screws and Bolts

As many other Chieftec products it looks like something made by a blacksmith, and not PC equpiment, but then again, I've never had a Chieftec product fail on me. And again, this is not meant to be a looker, but a quiet worker.

And quiet is not the word I would use about that cooler. With its tiny fan, I knew it would be loud. I run it on my desk, connected to a 12V power source through a chain of adapters, and wow, it was like a swarm of angry bees caught in a tornado (that's why they are angry).

The good news is that the new PSU fits and the cooling holes are right where they need to be.

The bad news is that even though the motherboard is indeed smaller, the way the 24 pin ATX power connector is placed, there is still only space for a single 3.5" HDD. I could buy 5.25 to 3.5" adapters and put the drives in the CD-ROM bay, but they would not have any cooling there. I guess that if I want to put more drives into this case, I will need to switch to a uITX board.

The final touch is a low profile 10G networking card that I got for very cheap. I will test once my Mikrotik CRS305 10G switch arrives.

Second iteration done.

Setting up the server

I managed to do some cable management, connected the Internet, for now through the 1G RJ-45 on the motherboard, keyboard, burned Ubuntu Server on a USB drive (funny to say, "burn on a USB drive", another leftover from the CD era), and started the newly built server.

And wow, even though the first thing I did was go to BIOS and change the fan curve to "silent", that CPU fan is awful. I am so glad this PC will be rarely run, and in a separate room. To bear with it running on my desk, I had to use ANC headphones. But it gets the job done, even under load the CPU temps would not go over 45C.

Apart from that, the rest was totally boring. I installed Ubuntu Server, set up ZFS, imported the pool, installed Sanoid and Syncoid, configured the SSH keys, made a short bash script for pull-style replication, and the config was done.

Bottom Line

I'm glad I went with a secondary server first to gather experience. Some of the issues I encountered here will not be a problem with moving the main NAS to a rack mount, as for that one I plan to use a 4U case for the GPU to fit, so I should be able to use a standard PSU.

But now I know that I will need to buy a longer case so that there is space for the drives and a normal motherboard.

If everything goes right, I should move to my new house at the end of this year, or the beginning of the new one.

This has been the first episode of me preparing my homelab for the big move, and I am sure there will be at least a few more before the highly anticipated event.

Thanks for reading!

New, leaner network setup; removing NATs, and ditching Tailscale

STFN — Fri, 03 Oct 2025 24:00:00 GMT

I've read somewhere that Intel for many years has been doing a tick-tock model in his development cycle. Thankfully, it had nothing to do with the Chinese data-hoarding, addiction-inducing short video app, but rather with how they improved their products. First was the tick, creating a new machining process, and then the tock, expanding and perfecting it. More on the whole cycle can be read on its Wikipedia page.

I'm writing about it because I feel I have been something similar with my homelab. First is the tick, adding new things, new processes, new complexities, and after a while comes the tock, removing what I find unneeded, cumbersome, things I do not use, and attempting to simplify my setup as much as possible.

This blog post is about the latest tock stage, one that made my homelab network setup much, much leaner. It's also about how one decision leads to another, and how even a small step opens new possibilities.

Before

The last tick stage left me with most of my self-hosted services being behind a triple NAT.

The first level is my Mikrotik RB3011 router that is the entrypoint to my flat's network. I don't use an ISP provided router/modem, because the ISP provides me with Internet access via a twisted pair cable coming through a wall straight into the flat, and with auth being done by PPPoE.

The second level of NAT is my WiFi mesh/bridge setup which I described in this blog post. I know there are ways to make a WiFi access point not do NAT, but this is a mesh setup, and a) it is absolutely mission-critical for me and my wife to do work from home, and b) it will only last until we move to the house, in the house there's going to be a single ceiling mounting AP. I already made plans with the electrician to leave one twisted pair hanging from a hole in the ceiling, and I'll mount a Mikrotik cAP ax and power it over PoE. So for the time being, the bridge stays.

The third level of NAT was my LXD setup with the default bridge network. LXD by default puts all running containers and VMs on its own bridge that only the host can access. I exposed the services using a static route, as shown in this video, but that still left me with another level of network obfuscation.

To access those services remotely I was using Tailscale. I installed Tailscale both on the host to reach the non-lxced services, and also on every container to be able to also reach them. While it work, it felt... incorrect. And the number of Tailscale clients grew with every new container, each one of them requiring installation and configuration.

Removing These NATs

The first change happened because of our upcoming move to a new house. As we are getting ready for it, the living room has been slowly turning into a place for storing things we already bought for the new place, like a set of garden furniture we found on a very good sale. The living room is also where the router is located, because there the ISP cable comes from the wall. And so I thought, with that room already becoming basically storage, moving my homelab there won't make much of a difference. So I moved my main server/NAS there, and now the server is connected straight to the RB3011, removing one layer of NAT. Dumping the WiFi part means also the Internet speeds jumped a lot. And I have more space under my desk.

The second change was with my LXD setup. Yes, I know, I will move to Incus, but not yet, I have it on my list. I recently learned about the MACVLAN network type in LXD, which puts the containers on the same DHCP address pool as the host, basically removing the NAT. The downside is that the containers cannot talk to the host, but in most cases I can live with that, they do not need to so. With the exception of the one running my monitoring stack, Grafana and InfluxDB, which needs to get metrics from the host, so this was stays on the default network.

The rest of the containers/service I moved to MACVLAN, so that my Forgejo, or Nextcloud are right in the same LAN namespace as the other machines. Setting up MACVLAN is very well described [in this blog post(https://blog.simos.info/how-to-make-your-lxd-container-get-ip-addresses-from-your-lan/).

This means that right now I have a single, flat, LAN network namespace. And that opened new possibilities.

Removing Tailscale

In the beginning of the post I mentioned how I have been using Tailscale to punch through all those levels of network address translation. But now that problem was gone. And the other thing is with my solar webserver, I have renewed interest in Wireguard. I really like how clean it is, and how it can be configured in the command line, or in automation tools like Ansible (soon there will be a post on Ansible!). And finally, it can be configured straight on a Mikrotik router, so no need to install it on all clients and containers. Truly a great piece of technology.

So I decided to move from Tailscale to Wireguard.

This is not the post to talk about my Wireguard setup in detail, so in short:

Btw, one of the problems I always have when writing blog posts is to decide how deep I want to go in talking about my actions, provide the whole configuration process, or just talk briefly about the ideas.

I already have a VPS with Wireguard, the one handling my solar website. This is the publicly reachable hub that all my WG clients can talk to and know how to reach it.

Then, I have Wireguard configured on my Mikrotik RB3011 router, so that every machine in the LAN can talk to that VPS via Wireguard. And vice Versailles, the VPS can reach any machine in the LAN, thanks to that flat network topology I achieved in the previous step.

Finally, I installed WG clients on my phone and my laptop, the only machine I take away from my home LAN. This allows me to reach my local services from any place through the secure connection of the VPN. And finally 2, that VPS works as a relay, forwarding traffic between different clients.

And to quote the great American poet, Billy Mays, wait, there's more! With Wireguard, the LAN clients keep their local IP addresses even when I talk to them through the VPN from away, so I don't have anymore that issue that I had with Tailscale, to keep two different set of bookmarks for my services, one with the internal address, and one with the Tailnet hostnames.

Another step in Degoogling

I removed the Tailscale clients from all of my devices and closed the account. Which also means that I can close my secondary GMail account that I have been keeping only because it was how I logged into Tailscale. I know you can login to Tailscale with a custom self-hosted OIDC service, but I never came around to do it. Anyway, one less Google service for me. I will have another blog post on my process of Degoogling, I would say I am something like 90% done overall, but as always, the last 10 percent are the hardest.

Bottom line

This post has been, as I feel it, about how small decisions in the homelab can lead to larger changes, and how everything is in a way connected to each other.

I am very happy with my new, much leaner, networking setup, and in a way, for me it is another step of preparation for my new house. I can't wait to also get rid of that WiFi bridge, it has been frustrating me in more than one way.

Bottom line 2

There is another one thing I need to work out now. Tailscale has been the source of TLS certificates for my Nextcloud (I wrote about it here), and with removing it I lost that functionality. But the great people of the Fediverse already suggested possible solutions, and I am very thankful! I will work on it somewhere in the near future when I feel like tackling this issue from the list of all the other issues with my homelab :) Here is the Fedi thread.

Thanks for reading!

My self-hosted music streaming solution

STFN — Sat, 18 Oct 2025 24:00:00 GMT

To skip the boring memories and go straight to the technical part.

I am a millenial, born at the end of the 80s, and my listening-to-music history is probably rather typical of my generation in the so-called "western world".

First I listened to music from cassettes, you know, those rectanglish things you could rewind with a pencil. I still remember that the first cassette I bought with my own money was Americana by The Offspring*. Later on came the audio CDs and the Discman that would chew through the batteries painfully fast. But this blog post is not about the physical media, it's about listening to music on a computer.

*The Kids Aren't Alright hits very different now

My first source of music in the form of digital files, something like 20 years ago, was the world of p2p file sharing. Everyone around had Kazaa, BearShare, Limewire. We would download music not by album, but by single files, burn them on CDs and share between ourselves. From time to time someone would download a banger such as linkin_park-one_step_closer.mp3.exe and brick the family computer, but that was an inherent part of the Internet experience at the time. People would amass collections of thousand of mp3 files, barely fitting on the 20GB hard drives of the times. Winamp was an indispensable software, and downloading new skins for it a fun activity.

Years passed, I went to university, started my first real work, and then came the time of music streaming services. My first one was Deezer, later I moved to Tidal because I got a free year with my phone plan, and finally I landed on Spotify, mostly because of the network effect. And using them at the beginning was exciting, it felt both like the future and something proper adults should do. I was earning my own money and now I was spending it on music, funding the artists. I did not have to store music in files, I could just stream it to anywhere!

And now we are where we are. With the increasing enshittification (1) (2) (3) of music streaming services, and my move to more local, private software solutions, using Spotify or Deezer or Youtube Music has lost its appeal. I just want to buy music and have it on my storage on my own terms, and give money to artists that make it.

I ended my Spotify subscription months ago. I buy albums from Bandcamp (which I know has its own share of issues) or from other places where the artists share their music, I am again buying physical media. Once again I have music in the form of files on my hard drive.

And as I am a homelabber and selfhoster, I did not want to just copy files from my NAS to my desktop, laptop and phone, I wanted a solution to access my music wherever I am.

Streaming music from a NAS

The server

I am storing the mp3 files on my server at home. The files live in Nextcloud which is running in an LXD container and uses my mirrored ZFS pool as storage. I can access Nextcloud from anywhere using WireGuard VPN. Before I switched to WireGuard, I had been using Tailscale to have access to my private data. I already talked about those topics in previous blog posts:

Deploying Nextcloud locally with LXD

Access local Nextcloud with HTTPS anywhere by using Tailscale TLS certificates

New, leaner network setup: removing NATs, and ditching Tailscale

So now I have access to my private files even when I am away from home, but how to actually listen to them?

Nextcloud has an app called simply "Music", which allows listening to music via the Nextcloud Web UI. Installing it is easy, you just need to have an account with administrative rights, and find the app in the app store built-in into Nextcloud. Later it's only a matter of pointing the app to the folder when you are storing the music, and le voila, files get loaded, and can be played from the browser.

The Nextcloud Music app

The downsides are you need a browser to play then this way, and the app has no means to edit mp3 tags or scrobble to Last.fm. Yes, I still use Last.fm.

My last.fm account is so old, I created it before even coming up with stfn.

But the Music app has a trick up its sleeve. It can work as a server for any apps that use either the Ampache or Subsonic protocols. Auth is being done via generated API credentials.

Nextcloud Music settings with information how to configure the music clients

The clients

For listening to music on other computers I use Strawberry. Strawberry is a fork of an older music player called Clementine (Oh the FOSS naming), and has support for the Subsonic protocol, and supports scrobbling to several services. But it cannot edit tags of external files.

On my Android (fair)phone I use Power Ampache 2. Sadly, it does not support scroblling, but apart from that works just fine. It allows downloading songs to the phone for playing them when offline.

Editing mp3 tags in Linux

As I mentioned before, neither Nextcloud Music nor Strawberry allow editing mp3 tags, and that is something so very much needed from time to time.

I'm handling that problem in two ways. For small edits I access the terminal in the LXD container and edit the files using the command line tool id3v2. Not the simplest way, but it's fast for single files.

For larger edits, I use EasyTAG, but that requires downloading the music files to my personal computer, editing them locally, and reuploading to Nextcloud.

The bottom line

And that's it, this is how I stream music these days. One less reliance on large corporations who are never your friends, and one more usecase for my homelab.

And I'm a nostalgic person, and once again having audio files makes me feel like going back to those old days when I would burn CDs full of Nightwish, Metallica and Evanescence to listen to on my way to high school. Wake me up, wake me up inside.

PS. I just checked and the Managed Nextcloud service offered by Hetzner supports the Music app, so it can be used instead of a NAS for people who don't want to or cannot have file storing hardware at home. Hetzner is not paying me for this recommendation, actually I am paying them to host all my public-facing stuff, and I think they are a company worth recommending :)

Thanks for reading!

I bought a Pi which is not of the Raspberry kind

STFN — Sat, 25 Oct 2025 24:00:00 GMT

I've been spending too much time on online marketplaces for secondhand items. Well, at least when I actually buy something from those sites, it's already used, so I'm not pumping mindless consumption that much.

Anyway, the result of one of those crawls is this tiny device: An Orange Pi Zero 3.

I bought it for ~100PLN (25EUR) with shipping, and the seller included a WiFi antenna and a radiator covering the whole board for passive cooling. From what I've seen, a new one can be bought for around twice that price.

The Orange Pi Zero 3 with an Apple for scale

The whole spec can be found on the product's website. In short, it has four ARM cores, and my version comes with 4GB of RAM. So more or less a mid version of the Raspberry Pi 4. The board is physically around half the size of the Pi 4, has an Ethernet port, a single USB-A 2.0, USB-C for powering, and a micro HDMI port, the same as the Pi 4, so that I could use the dongle I already have.

Software

For the OS I went with Armbian. Armbian has a community-maintained version dedicated to this specific board in both Desktop and Server flavours.

I prefer my SBCs as the French prefer their kings, headless, so I went with the server version. I installed it to a 64GB micro SD card using the Raspberry Pi Imager app, connected the Ethernet cable (I don't plan to use WiFi on it), power and waited for it to boot.

After booting I logged in with the default Armbian user and password (root;1234), and hey, I got a mostly standard Debian environment.

And what can I say, Debian is Debian, you get apt to install stuff, and things mostly just work. Armbian also provides a terminal tool armbian-config that you can use to configure some hardware things on the board like the WiFi, SPI, I2C and also install software.

I have not run any benchmarks, so I don't have the numbers, but from what I've been using the Orange Pi so far with typical terminal tasks like updating and installing software, it seems to be a bit slower than a Raspberry Pi 4b, but much, much better than a RPi Zero. I've never had any other Pis so I can't compare it for example Raspberry Pi 3.

Power Consumption

Because of my planned use-case (more on that in a moment), I was very interested in how much power does the board use.

According to my testing, the Orange Pi Zero uses around 0.24A (1.2W) at idle, which is significantly higher than a Raspberry Pi Zero (less than ~0.1A), but about half of what a Pi 4b uses (the one and only Jeff Geerling wrote an article about the Pi 4b power usage)

Power statistics after 12 hours of running.

What I will use it for?

I'm thinking of using it instead of the Raspberry Pi Zero as my solar-powered webserver about which I wrote in detail in this blog post.

I'm planning to expand my solar webhosting with more websites, and having more compute power, and eight times the RAM is always nice. The question is whether the batteries will be able to handle the increased load, especially as winter approaches. If not, I will consider buying new, larger ones, the solar panel itself is already big enough (330Wp). But that is a bridge that I will consider burning when I come to it.

Issues so far

Please bear in mind that I am a total noob when it comes to SPI/I2C protocols, so probably there is a super simple solution to what I'm talking about below, I just don't know it yet.

The first issue that I came across so far is that the GPIO connectivity seems to be non-standard.

I wanted to connect a BME280 temperature/humidity/pressure sensor to the board, as I am connecting one to the Raspberry Pi Zero. On the RPi it's super simple, VCC to VCC, GND to GND, SCL to SCL and SDA to SDA. But the Orange Pi does not have SCL pins, just SCK. I tried connecting SCL to SCK, and using different sets of SPI/I2C pins, but it would not work. Also the armbian-config tab with the I2C/SPI configuration is rather vague.

Of course I'm not saying it's a serious problem, I'm guessing there is a workaround for it. What I want to say is that for the Raspberry Pi Zero it is a trivial thing to connect a sensor, and for the Orange Pi it seems not to be so.

The second issue that I encountered was when I tried to install the ADS-B stack, dump1090-fa and PiAware to see if I can use the Orange Pi as an ADS-B receiver and send data to ADS-B sites like flightaware.com. The package aimed at Raspberry Pi would not want to install on the Orange Pi. Again, I am sure that there is a workaround for this, but the sheer fact that one needs to look for workaround puts the Orange Pi in a lost position.

Bottom Line

Those are my initial impressions about this SBC. So far I am positively impressed with its speed for the size and the price that I paid.

In one of the Late Night Linux podcast episodes, the hosts discussed why would anyone buy a Raspberry Pi 4, when there are similarly priced or even cheaper small computers. One of the arguments that was raised was that a Raspberry Pi is a known standard, the Raspberry Pi OS is the same for every Pi, it is a well known product and has a lot of support for peripherals out of the box. Software is written specifically for the Raspberry Pi, there is no need to reinvent the wheel, and that is why the Raspberry Pi is, for example, so useful in teaching environments.

And that's the main issue that I see with the Orange Pi Zero 3. It is a niche SBC running a niche OS (the Orange Pi provides it's own OS images as well, but I have not tested them), and there are things that will just not run out of the box as with the Raspberry.

So, in short, if you want an SBC that Just Works and has a ton of online support, get a Raspberry Pi. If you want to dig more into Linux on Arm, or just use the most standard stuff like nginx, the Orange Pi will be just fine with its great price to performance ratio.

As I play with it more, I will for sure have more things to say, but for now, that's it, thanks for reading!

My GoToSocial instance is now one year old

STFN — Sun, 23 Nov 2025 24:00:00 GMT

I don't remember the exact date when my GoToSocial instance was launched, but I am quite sure it was somewhere around late November of 2024. Which means that my very own server in the Fediverse is one year old. And on that occasion I would like to do some sort of an introspection of where I am and how did I reach this point.

Origins

The idea to host my own instance in the Fediverse came to me for the first time when the admin of the late botsin.space server announced that he will be closing the server due to lack of time. Botsin.space was an instance dedicated to running bots, and there I was hosting my first Fediverse bot, the Astrobin Image of the Day.

The admin was nice to inform about the closure well in advance, so I had some time to check my options. From the ones available, GoToSocial seemed the easiest to deploy, and most stable to run, with a good and active development process. So I went this route.

I am used to self hosting services, so for my the whole setup process was a breeze. For the instance, I rented a new VPS from RackNerd, the provider I was using at the time.

Once the instance was up and running, I also configured backups using Borg, and monitoring using Prometheus.

I won't be diving into the details of configuration here, because I already wrote about those topics in depth in previous posts:

How I started my GoToSocial instance in the Fediverse

Administrating my GoToSocial instance - monitoring and backup

Migrations

Time went by, and my instance was humming long quietly, hosting my bot and not doing much else. I had a "personal" account there with the obvious name of stfn, but I was not using it because I already had other such accounts elsewhere.

And then came the series of controversies with Fosstodon, the instance where I had my main account then. Tired of being on such an instance, I decided it's time to my stuff somewhere else, and there was an abvious choice where that "somewhere else" could be.

The ability to move accounts between instances together with followers and other lists is an awesome part of the Fediverse, and this was another time when it came handy.

I moved my main account to my instance, and it's still there, you can find me at fedi.stfn.pl/@stfn

Around that time I also decided I don't want to rent VPSes and store my data in the US, because, well, let's just say I do not trust that country when it comes to privacy and my rights as a consumer. Also I prefer to spend my money within the EU, where it benefits both me and my neighbours.

That is why I decided to move my instance from RackNerd's VPS to Hetzner in Germany. That was much more involved and stressful than moving accounts between instances, but turned out fine in the end.

I wrote about this period of hosting my instance in the blog post:

Migrating servers, leaving Fosstodon, moving to my own GoToSocial

The more the merrier

One of the great things about GoToSocial is its API, allowing to send toots in basically a single HTTP POST call with an auth token. And as it is my own instance, I can do with it whatever I want and not be concerned with using up someone's else resources. And so my little herd of bots started growing and now consists of:

Astrobin Image of the Day - showing the Image of the Day on a astrophotography sharing site

Stacja Dnia - showing each day a random railway station in Poland

Dzień - statistics about the length of the day and night in the geographic center of Poland

Nasz Papa - A bot to remind us of the great Pope John Paul II, and his great input in the Polish meme culture

Also two of my real life friends were kind enough to join me on my instance, and I am very happy to offer them my services:

Panga Wodoodporny

Current times

And so here we are today. My instance is still running strong, having survived multiple GTS updates with database migrations. Every night a Borg backup is being done, and before every update of the GTS app, or the server software, I stop the server and do a snapshot in case something goes wrong.

The instance is running, along with my blog and some other minor services, on a Hetzner CX33 VPS with four vCPUs and 8GB of RAM. It's 80GB disk in around 70% full, RAM usage is 30%, and the load rarely goes over 1, usually when I publish a link to a new blog post on my fedi account, and all the other servers try to pull the preview.

During this year I've learnt a lof about managing software and servers along the way, and I am sure most of the things I do could be done much better. But hey, not everything at once. Rome was not built in a day (and then came the Nero Burning Rom).

Future plans

I don't have any specific plans for the future. It would be great if more of my friends would like to join me on it. I think that around 10 accounts of fleshy people would be the reasonable maximum of what I am willing to handle.

Looking at Prometheus, the disk storage seems to be the first metric to run out, so I might consider offloading the media to object storage, which will be an interesting challenge on its own. I would also like to add more automation and configuration tools to the tech stack like Opentofu. But those are plans for the future. For now, my instance in the Fediverse has its first anniversary and I hope there will be much more to come.

Thanks for reading!

Pyriodic Backend, The Backend for the Small Web, is published on PyPi

STFN — Tue, 02 Dec 2025 24:00:00 GMT

I am very happy to inform that my Python project, Pyriodic Backend, has been published to PyPi, and is for anyone to use with the code available as open source.

Pyriodic Backend on Codeberg Pyriodic Backend on PyPi

Pyriodic What?

Pyriodic Backend is my idea to create the simplest possible "backend" service for updating static HTML websites with absolutely minimum resources. With Pyriodic Backend, the websites can be updated with changing information, for example the temperature outside, the weather, the CPU load, the battery level. The use-case is static websites running on Raspberry Pi Zeros, old phones, e-waste-level hardware. The interval between the updates of particular tags can be defined in increments of one minute, with one minute being the default.

To run PB on the server, the only requirements are python3 and cron. Pyriodic Backend is able to update purely HTML websites, no JS or any other magic required, just tags with ids.

As an example, I am using it to update my solar-powered website with temperature and CPU information.

(As it is basically winter right now where I live, with long and cold nights, the site is usually down during the night).

The installation and setup instructions are all in the README file in the repo and the PyPi page, and I hope they are sufficient to get you started.

Publishing to PyPi

The code is open source under the GPLv3 license, and hosted at Codeberg.org. For now the deployment to PyPi is being done manually, but I am considering using Woodpecker CI to put it into Actions.

As with my previous PyPi project, zambretti-py, I have been using this tutorial to go through the deployment process. Everything went smoothly, even smoother than for the first time.

Future Roadmap and contributions

The future roadmap for Pyriodic Backend for now includes adding more possible ways to track the function execution, I am thinking of adding Redis or other DB support. But I don't want to overload the project with too many features, it's meant to be simple and functional.

I am very much open to any feedback, suggestions for improvement, or code contributions. Create an issue in Codeberg or send me an email :)

The Bottom Line

With Pyriodic Backend I want to contribute to the Small Web that I like so much and try to be an active member of. I hope someone will find it useful and will add it to their webpage. If you do, please send me a link!

Thanks for reading!

I got hacked, and that has uncovered all the things I've been doing wrong

STFN — Sun, 07 Dec 2025 24:00:00 GMT

Apologies, I was sure I was taking more screenshots, but now I cannot find them, another thing I did not handle well.

My VPS got hacked, and this is the postmortem of the whole situation, written down as a precaution and for future reference.

On Friday evening I took a look at my Grafana dashboard for the VPS and saw that for the last hour the CPU usage was at constant 100% on all cores with a load of over 5.

Quick ssh to the machine, htop and I was shown that the CPU was used by several instances of the /tmp/fghgf process. I killed it with killall, but of course it came back again like in that Chumbawumba song. I tried searching for that process name in every web search engine, but there were zero definite results.

However I also saw that from time to time a process called xmrig would run, and that gave a definite result: a crypto miner. So somebody used my CPU to mine crypto. And I thought this bullshit scam "currency" is close to dying out. sigh.

The processes were being run by the prometheus user, so my first suspiction went in that direction. The first thing I did was to close the 9090 port in UFW. I had it opened for my selfhosted Grafana to be able to reach the Prometheus on the VPS for telemetry logging. The connection is secured by basic auth with user and password, the password is a randomally generated uuid. I knew that blocking the port was not enough, but I hoped I least I severed the connection between the attacker and my server. Now that I write it, I thought I could also block the 9090 outgoing traffic.

After some consideration I decided to go the kinda nuclear option and remove everything related to Prometheus from the system with the command:

sudo deluser --remove-home --remove-all-files prometheus

This worked, and continuous monitoring with htop showed that nothing suspicious was running anymore, and the load came back to the usual 0.1 - 0.2. But I still did not come to the root of the problem and I started to think about the future steps. And so the holes in my administration process came to light.

Insufficient backups

First, a short recap: On that VPS I am running my blog, which is a static site server by nginx, Umami, a self hosted analytics service running in Docker, Commento, blog comments engine, also in Docker, and finally GoToSocial, my Fediverse instance, running as a systemd service with a SQLite database.

I have made the typical error of a beginner sysadmin: I am doing backups but I never tested in full recovering from them.

Every few weeks, mostly before larger updates I do a full snapshost of the server using Hetzner snapshot functionality. Additionally, I am doing nightly backups of the GoToSocial database and user data using BorgBase, as described in the GTS Documentation. What I am not backing up is the Umami and Commento databases, and that is a glaring ommission. I am not backing up my blog, because it is just a static site, and I can deploy it from my Forgejo instance anytime I want.

So yeah, If I wanted to just kill this infected machine and redo the whole setup from scratch on a fresh VPS, I could at least easily restore my blog. With GTS it would be a different issue, I think it would be possible with the backups I do, but again, I never tried it, and that is a problem. And, I would lose the comments and the analytics data, which would be painful, but I could live with it.

Therefore instead of doing the best way with just killing and recreating the server, I went with trying to save my VPS.

Fixing the VPS

The breakthough came when Louis from the Fediverse sent me a link to an issue reported in Umami, in the version that I have been using. It was reported that indeed, the Umami version that I have been using (v2.19) has been vulnerable to the xmrig crypto miner. At the same time I was running clamav the Linux antivirus scanner on the VPS, and it did found two infected files in /var/lib/docker/overlay/.

I shutdown the containers, pulled the most recent version (v3.0.2) and started them again. I rerun the clamav scan and this time no infected files were reported.

As an additional line of defense, I also added a Hetzner Firewall in front of my VPS in addition to the UFW firewall running on it, as suggested by Grzegorz.

Current situation

I have been monitoring my VPS closely for the last two days, and for now everything seems to be ok, the load is low, there are no suspicious processes visible in htop, and several subsequent runs of clamav have shown no issues. I still have not restored Prometheus, I'm leaving that for the time when I have more time (what a great sentence).

Future plans

This whole situation has shown all the the things that I have been doing wrong with administraing my server. I'm feeling bad because of it, of course, but also that is a motivation to step up my Linux admin game. What I will need to do now:

add the missing things (docker container DBs) to my nightly backup solution
test my backups!!!
add more (that means, any) automation so that I can quickly restore my VPS from scratch if a need ever occurs
add alerting for prolonged high CPU load.

Bottom Line

And just a few days ago I wrote in the Fediverse that my servers Just Work and I am happy with them xD The whole situation has been frustrating for me, but I guess it's for the better, now I vividly know what I need to fix and when new skills I need to acquire. All in all, it was just a random trojan and not something really, really serious.

Many thanks to Louis, Agnieszka and Grzegorz for the feedback and support!

Here's the Fedi thread that I was doing as the things were unfolding.

First steps with Proxmox running on a Lenovo Tiny PC

STFN — Sun, 21 Dec 2025 24:00:00 GMT

This is very much a first steps post. I know I have barely scratched the surface of Proxmox, and I am sure that a lof of the things that I wrote here can be done better, but for now I just wanted to share my first impressions and first usecases of running Proxmox in my homelab.

Back in August I wrote how I tried to turn a Lenovo Thincentre Tiny M720q into a gaming PC.

How I bought a Tiny PC and turned it into a GPU workstation / gaming rig

This did not turn out well, I have not been using it much, and it was mostly taking up space on my desk, accompanied by a mess of cabling.

So, what else could I do with it?

For a long time now, I have been hearing about this Proxmox thing, and how it is popular in the homelab community as a tool to orchestrate VMs and containers. Trying it out has been on my todo list for way too long, and having a free tiny PC looked like the perfect opportunity.

My computing shelf. The Thinkcentre on the left is my Home Assistant box with a Zigbee dongle, and the right one is the new Proxmox node.

Preparing the Tiny to become a Proxmox machine

Switching the PC from a "gaming" setup to a homelabbing node was simple. I removed the GPU, and in its place I put back the SSD caddy with a 1TB 2.5" SSD from Lexar. I also reinstalled some minor parts like the back bracket. I did not put back the WiFi card with its antenna, because I don't need it, and it would block the airflow which is already not great inside such a small chassis. I saw people on Reddit installing 40mm fans to the front of the case, but looking at the current temps, I don't need them, at least for now.

With that, my PC has a 256GB M.2 drive for the system, which is a total overkill for Proxmox, and a 1TB drive for the virtual machines/containers. And with the GPU removed, its is once again totally quiet and cool.

Installation and configuration of Proxmox

For installation, I connected a screen, keyboard and mouse, hopefully for the last time. In times like this, I really miss having a proper KVM solution, but that is something for the future. I installed Proxmox in a typical fashion like any other Linux OS, from a USB drive.

After installation I run the "PVE Post install script" from the Proxmox VE Helper-scripts repo. Yes, I went through it first, I don't like piping to bash scripts taken straight from the Internet without looking at them first.

The only other configuration that I did to my new Proxmox machine is setting up the storage.

I configured that second 1TB drive as a ZFS pool for use as a storage repository for the VMs and containers. Why ZFS? Because ZFS is great, and it fits nicely with the rest of my homelab. More on that later.

The only thing that was unclear for me and not mentioned in the installation docs was how to download the images for containers and VM, but this forum thread helped me out.

I created a few first containers, and I have to say, Proxmox is awesome, most things are so intuitive, simple, and quick. I especially like the ZFS support available out of the box, and the fact that by default every new container gets its IP address on the same network as the Proxmox host, something I was missing in LXD. The web UI is clear and powerful, and the advanced features are there, ready to be used, but not required at the beginning.

Migrating from LXD to Proxmox

For the last nine months or so I have been a big fan of running LXC containers in LXD, which is a container and VM orchestrator from Canonical. I have been running LXD on my NAS, and hosting on it services like Nextcloud or Forgejo. One of the downsides of this setup is that LXD and all its containers had to share RAM with other services like Jellyfin, and also with my large ZFS pools, and ZFS loves RAM like horses love oats (sorry, this is a joke for 30+ year old Polish people). The Tiny PC has 32GB of its own RAM which, the same as my NAS, so with separating the containers from my NAS I basically doubled the available amount of RAM, which is nothing to sneeze at, especially at the current RAM prices situation. Also, storing the containers on a separate PC, and backing them up to the NAS gives me another layer of data preservation.

For those reasons, and because Proxmox has been a joy to use from the first moments, I decided to move everything from LXD to Proxmox. I was hoping there was some easy, turn-key way to migrate LXC containers between those two services, but from all my searching it turned out that was not the case. I found some solutions, but they all felt very hacky and not to my taste, so I decided to go the long router and just start the containers from scratch, copying just the data like the Forgejo repositories or the Nextcloud files.

I started the migration with PiHole and Nextcloud. For those two services I used the community scripts that I took from the same repo as the post-install script mentioned at the beginning of this post. Thanks to them, setting them both was a breeze, and in moments I had two fresh containers running.

Then came the monitoring stack, consisting of Grafana and InfluxDB, and later Forgejo. Migrating Forgejo was easy, after I set up the new Forgejo container, I used the built-in migration feature to move all my repos from the old service to the new one.

I also used this opportunity to move services from other parts of my homelab into this Proxmox node, for example I moved Miniflux (an RSS reader) from my "dev" VPS to an LXC container here.

After migrating everything to Proxmox and allowing it to run for a few days to make sure there were no issues, I removed LXD from my NAS. My current direction of my homelab is to have a mostly dumb NAS, running there only the services that require direct access to a lot of storage and the GPU, like Jellyfin or Immich. Everything else goes to the Proxmox node.

Screenshot of the Proxmox web UI showing the list of running containers.

Backups

As I wrote above, the Proxmox services are stored on a ZFS pool on the Lenovo Tiny. How Proxmox is handling them is that each service is a separate ZFS dataset. My NAS' storage is also ZFS based. By their powers combined, doing backups of the containers is a single command:

syncoid -r --skip-parent root@proxmox:thepool large-data/proxmox-backups

Let's unpack that. Syncoid is an awesome tool for replication of ZFS datasets.

I am doing a "pull" style replication, the command is being run on the NAS, and it pulls the datasets from the Proxmox node to the NAS. thepool is the name of the Proxmox storage pool, and I am only pulling it's children, so the datasets of the particular containers, and saving them under the large-data/proxmox-backups dataset, which is on a 4TB pool on my NAS. The NAS has the ssh keys to access the Proxmox node, so there is no need for any passwords and the like. And le voila por favor, one command and everything is backed up.

What I haven't yet solved is backing up the configuration file of the Proxmox itself, that is the next step for the near future.

Gaming

Yes, I tried that too. I created a Kubuntu VM, and installed Steam on it, and tried gaming using Sunshine/Moonlight streaming.

Aaaaand yeah, no matter how many resources I gave to that VM, I got maybe 3FPS in Terraria. This is clearly not a PC for gaming, especially remote gaming. Pwning noobs and 360 no scopes (of course in Terraria) will have to wait.

Infrastructure as Code

I also started to look at keeping my containers as code in OpenTofu. OpenTofu has a Proxmox provider, and so I can define the containers configuration and have it automatically applied, just like the grownup sysadmins do.

I'm sure this will be a topic of an upcoming blog post.

Next steps

This is just beginning of my journey with Proxmox and I am fully aware there is still a lot to learn. Maybe one day I will but another Lenovo Tiny and try out clustering? Maybe I'll do some advanced networking magic? Or maybe I'll build a full size PC with a GPU, and move everything there and actually try some proper gaming? We will see. So far I have been enjoying Proxmox very much, and it is my go-to technology for trying out new things.

Thanks for reading, and enjoy your holidays, however you spend them!

Blog statistics for 2025

STFN — Tue, 30 Dec 2025 24:00:00 GMT

Tomorrow is the last day of 2025, and there is a high probability that the next year will be 2026, just like Saturday comes after Friday, and Sunday comes afterwards.

2025 was also the first full year that I have been using Umami as my online analytics service to track people visiting my blog.

I know that "tracking people" sounds bad, but as I said many times, I just do it because I like looking at numbers and graphs, I am not selling that data to anyone, I don't use it to "plan new content", it does not leave my VPS, and in general it's very anonymized. So I hope you will forgive me.

Anyway, I thought it would be interesting to looks at some of the statistics and think what they mean.

Most popular posts of 2025

The most popular post of 2025 is Set up GPSD with U-blox7 GPS Dongle on Linux, which is almost two years old by now, but it's still an evergreen as people search for it a lot. I guess the problem with configuring a USB dongle GPS has not gone away since then. And when I was writing it I was sure nobody will read about such a niche issue.

The second most popular post is How to monitor 12V battery charge with a Raspberry Pi Pico. In 2026 I plan to revisit this project and work on integrating battery monitoring with Home Assistant.

And the third most popular post is How to set up subdomains in the homelab with PiHole and Caddy. I have not really touched my Caddy install since I wrote that post, but it still works.

Referrers

Google is the main source of visits to my blog, at 68% of visitors coming from their its results, with an additional 5% that came from that one time when my blog post was listed in the Discover widget on Android phones. That was a fun day, I got a week's worth of traffic in a few hours.

Second is duckduckgo and third is Reddit. I don't read Reddit much, but I post my blog posts to the theme of POSSE.

And there's the topic of the Fediverse. Every time I publish a new blog post I publish a link to on both of my Fediverse accounts, and it's there that I have basically all of the conversations about what I post (apart from few awesome emails which I received, please keep them coming!).

The Fediverse is not that visible in the traffic statistics, because, well, it's decentralized. Meaning each instance has its own referrer, and sometimes even the client apps put their own ones instead. Furthermore, for a long time Mastodon did not provide any referrer at all, but that has changed in the recent versions. In overall, I am seeing a steady growth of visitors with Fediverse referrers, and that is awesome.

On the list there are also a few fellow blogs whose creators have been so kind to link to my stuff (thank you!), and also, which makes me much less happy, LLMs going through my blog posts.

Browsers, OSes and Devices

My audience is much more Firefox centric than the general populace, with 20% if visits coming from the Mozilla browser. Chrome trumps all, Apple products are third. Mozilla, please, please, please, get your stuff together and dump those pointless AI features that people do not want.

Operating Systems. Linux is at 14%. Who would have expected that people who read a blog that is in a very large part about Linux shenanigans, use that system themselves?

Devices. Mobile wins, and frankly, I am not sure how Umami makes the division between a laptop and a desktop.

Location

More than half of my visitors come from English speaking countries, then there's Germany, and Poland is fourth. Netherlands and Singapore make suprisingly high numbers, taking in mind their size. I mean the size of the countries, I met some Dutch people at my previous work, and it felt weird being of mid height compared to them. And the Dutch have a very big presence in the Fediverse, as least that's what I'm seeing.

FAQ

How well does Umami filter out bot traffic?

From what I've been comparing Umami statistics with nginx logs it does a rather good job, mostly because it requires JS to run, and crawlers most often don't run JS scripts on the pages they visit. Which also means that any prefetching done by the Fediverse instances is not calculated towards the views. Of course, from time to time I see some weird spike of patterns that clearly suggest that those views are not of human nature.

I do not want to be tracked by your web analytics

Ok! Sorry for making it opt-out instead of opt-in. You can block the umami.stfn.pl domain in your adblocker. Also the [Pro Plus DNS block list(https://github.com/hagezi/dns-blocklists?tab=readme-ov-file#proplus) which I personally recommend to add to PiHole has my Umami blocked. I also wrote a few blogs on how to block ads and trackers using PiHole, for example Using PiHole and Tailscale to block ads on all my devices, including mobile.

Has Umami been causing you some problems lately?

Funny you should ask

Bottom Line

And that's it, the final blog post of 2025. Including this one, I wrote 44 blog posts this year, and so far, the upcoming years looks very promising in many aspects. New blog posts are in the making!

Thanks for reading!

Goodbye AWS - moving from Cloudfront to Bunny CDN

STFN — Fri, 23 Jan 2026 24:00:00 GMT

I have moved this blog's CDN from AWS Cloudfront to Bunny CDN.

This is one more step in me moving away from US corporations to smaller European companies.

With everything that is happening in the world right now, I do not consider my data safe when stored on US soil, and I do not want to give my money to fuel companies and people who are, to put it bluntly, aggressive towards Europe, European Union and its values.

I don't have any photos of bunnies so say hi to my cat instead.

I am around 90% done in moving away from Google, Amazon and Microsoft, and this change of CDN service is an important and overdue step in that transition. Now when you browse my blog, the images and video are being loaded from Bunny's servers. I have already removed the last remaining files from AWS S3.

Why Bunny CDN?

Typical caveats apply, this is not a paid endorsement, Bunny has no idea who I am, and I am using it only because of the reasons provided below.

I found Bunny at the European Alternatives website which is an awesome place and you should definitely check it out. I also saw a few people recommending it in the Fediverse.

As I said in the beginning, I want move to smaller European companies so that both my data and my money stays in Europe. And Bunny is situated in Slovenia, a small eastern Europe country most known for its mammoth ski jump and being mistaken with Slovakia. And it has the tallest chimney in Europe.

First steps with Bunny

In comparison to AWS, Bunny is so beautifully simple (but I guess 99% of things are simple compared to AWS).

I created an account, set up 2FA and started to look around. I want to use Bunny as a typical CDN, storing my assets and serving them from several location around the world. So first I created a Storage Zone to which I uploaded all of the images and videos present on this blog. For that I used the ancient technology of FTP, as it was the simplest to just upload a few hundred files, but there are also other means available.

With that done, I set up a Pull Zone and connected it to the Storage. With that, every file become available under the url of that Pull Zone. And le voila bueno, the only thing left was to do a global search and replace of all my blog posts, to well, you know, replace Cloudfront's URL with the one from Bunny.

And one great thing coming from Bunny's simplicity and them focusing only on few services, is that right away on the main page I get stats telling me my current usage and cost. And speaking of that.

Pricing and comparing to AWS

Here is Bunny's pricing: (link).

Before I left AWS Cloudfront, I checked my monthly transfers (even that was not that easy with AWS) and they were in the range of few GB per month. ~~Which means that in my case, I will pay next to nothing, maybe a few cents per month for hosting my multimedia, just as with Cloudfront.~~

Lol, after I published this post I received feedback that this is not the case, and that on the exact Pricing page I linked above there is, in large, clear font, written "$1 monthly minimum."

And with Bunny it's easy to setup transfer limits in case an AI crawler visits my blog and decides to download every image a million times, because this is what AI does. And I see that they have some sort of DDOS protection which I haven't read into yet.

What I don't like

I've been only exploring Bunny for a few days, and for now I haven't found anything I disliked. The only thing I miss would be support for Prometheus or any other way to pull the stats into Grafana, but that would be just a nice to have gimmick, not something important.

If anything else comes up, I'll do a followup blog post.

Bottom Line

I know that my few cents/grosze a month will not make any Excel sheet turn from green to red for AWS or the other way round for Bunny.

But this migration is something important for me, and I feel that I am going in the right direction, and I encourage everyone to do the same.

With that done, this blog is hosted on a German VPS, the code is hosted on Codeberg and Forgejo which are also German, the CDN is Slovenian, and the domain company is Polish. I feel like listening to the Ode to Joy now.

Thanks for reading!

Tmux, Starship, and Neovim, the trio to make your terminal better

STFN — Fri, 06 Feb 2026 24:00:00 GMT

I like using the terminal (also called the console). On every computer I use, I always have it opened as one of the windows. I use it for SSHing into my homelab and VPSes, installing apps, managing files. I prefer the terminal rather than clicking through a GUI.

So, if it's a tool that I use so often, why not make it more usable and prettier?

In this blog post I want to show my terminal setup, the different tools I use to make it nicer. It's not meant to be a full tutorial how each tool can be configured, but more of an example of what can be achieved. There are many way to setup a terminal, but this one is mine. My terminal is my best friend. I must master the terminal...

OK, I better stop now. Anyway, here's the final result:

As the base, I just use bash. I used zsh for some time, but I went back to the default shell shipped with Debian and Kubuntu, the OSes that I use.

I have been building this configuration over the last several months, so I cannot provide the source for each and every change, but if my memory serves me right, this Youtube video has been the basis of most of the config.

tmux

tmux is a terminal multiplexer. While it sounds like a technology from Star Trek (Mr Spock, the terminal multiplexers are down, fetch the ion torpedoes!) what it means is that the terminal window can be divided into multiple windows, each having multiple panes, and in each of those panes a different command can be run. Another useful feature is that you can detach tmux from your terminal, meaning anything run in it will continue to run but in the background. Useful for long-running commands when you need to turn off your PC or close the SSH connection.

tmux can be installed using your preferred package manager, for me it's

sudo apt install tmux

tmux on itself is already useful, but it feels a bit... raw. However, it can be made much nicer by adding a custom configuration file and plugins.

First, let's install the tmux plugin manager:

git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

The second step is installing a nice theme. I prefer the catppuccin theme:

git clone https://github.com/catppuccin/tmux ~/.tmux/themes/catppuccin

Third step is to get Nerd Fonts, fonts with additional glyphs to use with the theme. My font of choice is the Noto Nerd font that can be downloaded from Nerd Fonts.

I guess the way to add new fonts differs between distros. For my Kubuntu it's:

sudo apt install unzip
mkdir ~/.fonts
cd ~/.fonts
wget https://github.com/ryanoasis/nerd-fonts/releases/download/v3.4.0/Noto.zip
unzip Noto.zip

# update the font cache
fc-cache -fv
# if the command above is not found: sudo apt install fontconfig

Sometimes new fonts do not load properly, then it is best to just reboot.

With everything installed, we can create the config file in the home directory:

# ~/.tmux.conf

set-option -g default-terminal 'tmux-256color'

set -g base-index 1              # start indexing windows at 1 instead of 0
set -g detach-on-destroy off     # don't exit from tmux when closing a session
set -g escape-time 0             # zero-out escape time delay
set -g history-limit 1000000     # increase history size (from 2,000)
set -g renumber-windows on       # renumber all windows when any window is closed
set -g set-clipboard on          # use system clipboard
set -g status-position top       # macOS / darwin style
set -g default-terminal "${TERM}"

# toggle panes with Vim shortcuts
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

#install plugins
set -g @plugin 'tmux-plugins/tmux-cpu'
set -g @plugin 'tmux-plugins/tmux-battery'

set -g @plugin 'tmux-plugins/tpm'
set -g @catppuccin_flavor 'mocha'


# Load catppuccin
run ~/.config/tmux/plugins/catppuccin/tmux/catppuccin.tmux

# Configure top bar
set -g status-right-length 100
set -g status-left-length 100
set -g status-left ""
set -g status-right "#{E:@catppuccin_status_application}"
set -agF status-right "#{E:@catppuccin_status_cpu}"
set -ag status-right "#{E:@catppuccin_status_session}"
set -ag status-right "#{E:@catppuccin_status_uptime}"
set -agF status-right "#{E:@catppuccin_status_battery}"

# use current path when opening new pane
bind  %  split-window -h -c "#{pane_current_path}"
bind '"' split-window -v -c "#{pane_current_path}"

run '~/.tmux/plugins/tpm/tpm'

I hope the particular settings are self-explanatory. For more details, consult the docs or the video I linked above. And le voila, now your tmux will be pretty.

Starship

Starship is a customizable prompt for your terminal. A prompt is basically the thing that you see at the beginning of the input line when you type something in the terminal.

Starship can be installed using a package manager or the easy-but-shady method of piping curl to bash. The installation docs are here. To render properly, starship requires a Nerd Font that we already installed in the previous step.

A lot of things works straight out of the box, like showing the git repository status or the Python virtual environment, and additional configuration can be done using, you would never guess it, a configuration file, ~/.config/starship.toml.

The full configuration docs are available here.

Here's mine:

# don't add newline after the prompt
add_newline = false

# always show machine hostname
[hostname]
ssh_only = false
format = '[$ssh_symbol](bold blue)[$hostname](bold blue)'
trim_at = '.companyname.com'
disabled = false

# always show machine IP
[localip]
ssh_only = false
format = '@[$localipv4](bold blue) '
disabled = false

Neo

The final part of the Terminal Trio is Neovim, an evolution of the evergreen text editing machine, Vi. Nvim can be installed using your package manager of choice, or by downloading the binary.

Nvim also has support for plugins, there are several available plugin engines, and from them, I use Vim-plug. It can be installed by downloading the plug.vim file into the nvim's autoload directory:

curl -fLo ~/.vim/autoload/plug.vim --create-dirs \
    https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim

More information and alternative methods can be found in the Vim-plug docs

With the plugin manager installed, the next step is to create the configuration file and paste the desired settings into it:

mkdir -p ~/.config/nvim
nvim ~/config/nvim/init.vim

And here's my config file:

set mouse=v                 " middle-click paste with 
set hlsearch                " highlight search 
set incsearch               " incremental search
set tabstop=4               " number of columns occupied by a tab 
set softtabstop=4           " see multiple spaces as tabstops so <BS> does the right thing
set expandtab               " converts tabs to white space
set shiftwidth=4            " width for autoindents
set autoindent              " indent a new line the same amount as the line just typed
set number                  " add line numbers
set wildmode=longest,list   " get bash-like tab completions
set cc=80                  " set an 80 column border for good coding style
filetype plugin indent on   "allow auto-indenting depending on file type
syntax on  
set clipboard=unnamedplus   " using system clipboard
filetype plugin on
set cursorline              " highlight current cursorline

" plugins section

" Start NERDTree and put the cursor back in the other window.
autocmd VimEnter * NERDTree | wincmd p
:let g:NERDTreeWinSize=60

" Exit Vim if NERDTree is the only window remaining in the only tab.
autocmd BufEnter * if tabpagenr('$') == 1 && winnr('$') == 1 && exists('b:NERDTree') && b:NERDTree.isTabTree() | call feedkeys(":quit\<CR>:\<BS>") | endif

call plug#begin()
" List your plugins here"
" A Tree-like side bar for better navigation
Plug 'preservim/nerdtree'
" A cool status bar
Plug 'vim-airline/vim-airline'

call plug#end()

Most of the settings are either self-explanatory or explained with comments. I am using two Nvim plugins: NERDTree and vim-airline. The first one adds a file manager to the side of nvim, to make it work more like an IDE, and the second one adds a status bar wit useful information, like the current mode or rows and column numbers.

When the configuration file is saved and you open Nvim again, you'll get an error that the plugins are not installed. To install them, do :PlugInstall when in command mode in Nvim.

nala

Finally, I would like to mention nala, about which I heard in the Linux Matters podcast. Nala is an alternative frontend to apt, the package manager of Debian and its derivatives. Under the hood it uses the same library as apt, but has a much nicer and friendlier look and feel. The commands are mostly the same, running nala upgrade with both update the local package information, and install the new versions of packages. Just a fun, small thing to brighen up your terminal even further.

Bottom Line

And that's it, hope my post will be an inspiration for you to make your terminal have a dash of sparkle. What terminal enhancements do you use? For the time being I have turned off comments as I was not happy with my comments system, and I removed all superflous services from my VPS after the last attack, but you can reach me through email or the Fediverse, links in the footer.

Thanks for reading!

New house, new blog, new me

STFN — Sat, 28 Mar 2026 24:00:00 GMT

First of all, apologies to all the RSS readers of my blog, you'll most probably get all the posts again.

Almost two months have passed since the last blog post. The reason for the hiatus is simple. Three weeks ago I have finally, finally moved into my new house. Those were hectic two months, endless calls, decisions, talking to the construction crew, buying materials, tools, and then packing, unpacking, sorting, throwing away surplus stuff. I can probably go through the local hardware store with my eyes closed. But all that is mostly done, there are of course still things to sort out, like the paperwork, or the garden, or getting a contract for dealing with trash, but the actual move is done.

The cat is enjoying the new place

And I've been loving it here, it is so great to be able to just go out into the open air, without any stairs or corridors. There are so many new possibilities. I already tried astrophotography and being able to just carry out the equipment through the door, and then sit on the coach as the exposures are taken is a totally new level.

The homelab is is also migrated to its new place, soon there will be a new blog post dedicated to its current state.

New blog

For a long time now I have been wanting to do something with this blog. I started it three years ago, and I took a ready template from the Astro template site. It allowed me to start easily without spending time on writing the boilerplate, which was a big plus. But as time went by, and I started adding new features, the codebase started to feel cobbled together with sticks. I never really learned Astro, so my edits were mostly trial and error, and putting stuff where it worked, not where it should be.

So I decided to rewrite the blog from scratch with a new technology, in order for it to be actually mine, with the code I understand and know how it works.

First I tried Hugo, but I got confused with it quickly, that framework just not clicked with me. My second attempt was Eleventy and that was the total opposite. Eleventy feels so simple, so straightforward, after doing a few tutorials and going through a sample site I had no problems with writing this blog how I wanted it to be. I don't need much, just a way to generate static HTML, handle navigation, and generate an RSS feed.

The aim has been to keep the look similar to the previous version, but make it simple and understandable for me. I'm a backend person, my frontend skills are very basic and rooted in mid 00s, but I think I made a reasonably good job. One thing that I dropped was the light/dark theme switcher, it has been a source of problems on the previous version, and I did not want to overcomplicate the new layout. On the other hand, the RSS feed now provides the full text of the blog posts, so you can read them all in your RSS reader of choice.

I made sure all the links stay the same, so as no referrals to my blog get broken. The RSS feed URL also did not change.

I took this opportunity to update old blog posts, add some alt text, fix typso, update/remove broken links and comment on things which have become outdated.

I have many ideas for the next blog posts, there will be something about the homelab's hardware, about Woodpecker CI, about local TLS, going back to Meshtastic, and now is finally the time when I have the time (time time time) to write them. Exciting times!

Thanks for reading!

Human JSON - community against AI generated content

STFN — Mon, 30 Mar 2026 24:00:00 GMT

Yesterday, Michał Sapka, Poland's favourite blogger according to a certain Australian posted on the Fediverse a toot about human.json.

human.json is intended to be a way of presenting that this specific website is written by humans, not AI. It also allows to vouch for other websites, that the author of this one knows that those other websites are also written by humans.

I would call it a reputation based system of proving a website's human origins (how creepy does it sound, doesn't it?). In contrast to something like GitHub stars, it is more personal and works based on people you already know. I am quite sure that Michał is a human that writes his blog with his human fingers touching his fancy retrocomputing keyboard. With human.json I can see that he vouches for some other website, so I can relatively safely assume that this other website is also written by a person of flesh and bone (this is getting even creepier).

In technical terms, all an owner of a website needs to do is add a human.json file on the server, and link to it using a <meta> tag in the site's header. That JSON file consists of the canonical URL to their own website, and a list of websites they vouch for. Simple.

The second part is to install a browser extension that will show, when visiting the websites, that their author declares itself human, and also how many other people vouched for them not being a murderous bot able to withstand an exploding fuel tanker truck.

The AI generated slop flooding the internets is a problem that is only growing. I don't know of any simple and sure way to tackle it, probably such a solution does not exist. But we can and should oppose it, and human.json sounds in my opinion like a good tool to have. With it we can build a public network of mutual connections and use it as a shield against the dying of the human web.

I've been listening recently to the Late Night Linux podcast and one of the main reasons I listen to it is because those guys don't sugarcoat the world, they are angry as I am about the current state of things. In the last episode, I think it was Féilim who said we had 20 good years of using the Internet, and now it's ending because of the AI slop and attacks on people's privacy. I started using the internet somewhere around 1999, and for me always its strengths and features was it being anarchic, egalitarian, free (both as in beer and speech), and everyone could be anonymous as much as they wanted. And this is ending with bullshit like AI crawlers DDOSing websites, and destroyers of anonymity like age verification being implemented by lawmakers.

We are not in a great situation, and I'm glad even such small things like human.json are being implemented to fight it.

I implemented it on my blog and added a few people from the top of my head. If you would like to be added or removed from that list, send me an email or contact me through the Fediverse, links in the footer.

Thanks for reading!

Other bloggers that wrote about implementing human.json: Terence Eden, Neil Brown, Corey Snipes

Using Bunny CDN to embed and stream videos on static websites

STFN — Wed, 01 Apr 2026 24:00:00 GMT

As with other such posts on my blog, this is not sponsored in any way, I just write about the things I personally use and think are worth sharing.

In the process of rewriting my blog I changed how I host my videos.

I currently have two posts with embedded short videos:

How to make a timelapse with a Raspberry Pi

I started using ESPhome and now I have a local smarthome

Previously I stored the video files in the CDN's storage (first Cloudfront, then Bunny CDN, here is the blog post about switching my CDNs) and served them using the video.js library. This in general worked, and I had no issues with it, but when rewriting the blog I wanted to try out something else, and I saw that Bunny CDN has a dedicated service for hosting videos: Bunny Stream.

Bunny Stream is a service that allows to upload videos to Bunny, and then the rabbit handles streaming them through their own player. The player can then be embedded in a website by adding the generated code snippet. There is a few options to edit the player, change the thumbnail, set autoplay on or off, play in a loop. You can even add chapters and subtitles. Also with subtitles, Bunny offers autogenerating subtitles using machine learning for an additional cost.

As for the cost, the hare company always chargers 1 USD minimum with any incurred cost on top of that. They have a calculator that allows to forecast the monthly cost based on the video size and traffic. And again, for people like me who would like to serve a few videos on a less than popular site, the monthly costs should not exceed 2-3 USD, which I found reasonable. In my case, I have not exceeded a few cents of costs for video streaming yet. I will be monitoring the costs and if they become unacceptable high, I will write another blog post.

Here's how the player looks and works: I haven't made any interesting videos recently, so I dug up something fun from my archive.

A short video I made in 2021 during one of the Pride events.

Why am I sharing this?

One of the reasons why I am writing about hosting videos this way is the lack of good, open PeerTube instances.

PeerTube is a federated platform for hosting videos, one could call it the Youtube of the Fediverse. The issue is that hosting and streaming videos requires much more significant resources that text or images, and so there aren't many people willing to do it. The Polish part of the Fediverse had tube.pol.social, but that ended with the general demise of pol.social.

And so I think that using Bunny Stream and embedding videos on a personal site is a reasonably cheap and easy to implement alternative for PeerTube, for people like me who have just a few short videos and want to put them online. Of course the open source and federation aspects are lost, but embedding videos on a personal static website keeps it POSSE. So it's better than nothing, you keep control over your content and not give it to the whims of the Algorithm like on Youtube.

Thanks for reading!

First astrophotography session from my new house - the Virgo Cluster

STFN — Sat, 11 Apr 2026 24:00:00 GMT

As I already mentioned in oh so many blog posts, I now live in a house, which opens totally new possibilities when doing astrophography. I no longer have to drive a long way just to get to the spot, and then spend hours either outside in the cold, or in a small shed. Now all I need is to carry out the equipment in the evening, do the setup and polar alignment when it gets acceptably dark, and then sit comfortably on the couch and control the session from the inside. Which means I can do much longer sessions without freezing and getting fed up with it all.

The house is quite far from the cities, so the sky is around Bortle 4/5, which is not bad for the more populated parts of Poland. Using binoculars I can see the Andromeda Galaxy, Alpha Persei Cluster, Messier 44 and the like. Messier 42 is plainly visible with the naked eye. Much, much better than living in Poznań.

I've been planning to do a separate blog post about the AP gear and software I am using, and yes, it will come at some point, but not today :)

This is a new start for me after some hiatus, so I am keeping it simple, wide angle, simple setups and no guiding. Guiding has been an endless source of problems and frustrations for me, so for now I am skipping it to focus on the other parts of astrophotography, and just find fun in it.

The Virgo Cluster

Spring is around us, which means that in the Northern Hemisphere it's ~~duck~~ ~~rabbit~~ galaxy season. The Milky Way is low on the horizon, and most of the sky is away from the plane of our Galaxy, which gives a clear view on the more interesting galaxies other than our own.

I am using a 150mm lens to do AP now, so of course it's much too wide for a single galaxy (maybe apart from Andromeda, but she hugs the horizon), so I went with a galaxy cluster. The Virgo Cluster is in the perfect place to shoot it, high in the Eastern sky between the constellations of Leo, Virgo, and Coma Berenices. It consists of thousands of galaxies, with tens of them visible with amateur equipment. A notable part of the Virgo Cluster is the Markarian's Chain, a group of galaxies that seem to ordered in a smooth line.

With the introduction done, time to present the actual photo that I did:

And here it is, the Virgo Cluster. Right off the bat, several large galaxies can be visible, but when you zoom in (click on the image for the full resolution), much more smaller ones can be seen.

Here's a walkthrough of the more notable ones.

Annotated images

And here is the image annotated, and it's position in the night sky.

Technicalities

As I said above, I am keeping it simple for now, to extract most fun and results without getting frustrated by the more complicated parts of AP.

Session:

270 exposures of 90 seconds each, captured over two consecutive nights, for a total of 6 hours 45 minutes acquisition time, an absolute record for me, the previous longest session was the Iris Nebula at 3h 50m.
darks
biases
flats separate for each night

The gear:

iOptron GEM28 mount
QHY168C cooled astro camera
Irix 150mm f/2.8 lens
Astrolink 4 AP controller
Raspberry Pi 5

Software:

Stellarmate OS on the Pi
Pixinsight
GIMP

Editing in Pix:

integration in WBPP, took more than two hours on my Ryzen 1600X
Dynamic Background Extraction
Background Neutralizaion
SpectroPhotometricColorCalibration
MultiscaleAdaptiveStrech
SCNR
BlurExterminator

Finally a sprinkle of Curves, Levels and Saturation in GIMP.

My Pix skills are extremely simple, I need to do more tutorials and reading on it, I'm sure that with the right skills I could pull out more of the data that I have.

Bottom Line

And that's basically it, I feel that I am opening a totally new chapter in my AP journey, and from now on taking new photos will be much easier and I will be much more willing to do so.

Summer is coming quickly and with it the nights too short to do AP, but I am hoping that before that I will be able to capture a bit of Cygnus, I've been planning to do a proper shoot of the Veil for a long time now.

Thanks for reading!