I am driving back from lunch, enjoying every kilometer in my trusty Volvo. It makes a new squeaky noise, but the mechanic said it should be fine. The repairs are piling up, though, and I can feel that our time together is coming to an end. What I do not know yet is that this drive back to the office is the last real run the Volvo and I will share.

The End#

In Austria there are mandatory inspections (§57a) for every car. Things like the brakes and the tires are checked. In past years this was always an anxious time, since the car got so old that I did not always have the highest hopes of passing the inspection. This year was no exception, but this time my gut feeling was different. I got used to the car making various sounds but there were new ones that were more persistent. I brought it to a workshop, told them to first evaluate if it is worth it and then do the inspection. Well there were several parts causing problems. Passing the inspection would have cost 2,000 €, but it was certain that the inspection next year would again be expensive. Also the winter tires were at the end of their life, so that was another cost factor. I decided that our days together were done. It was surprisingly sad since the car had been a trusty companion for 13 years. But at the same time: I want a reliable and safe car for my family and me.

The good part was that I got the news about four months before the car would become illegal for the road. That is plenty of time to search for a car. So far I had only owned two cars, and both had been found and recommended to me by others.

I had begun the search and already made appointments for a test drive when it happened: After lunch with a friend I wanted to get back to the office and broke down in the middle of the road. Roadside assistance took one hour to realize they had the wrong location in their system. And then another hour since there was a higher priority incident. In the end, both the car and I were brought home and the new car search became way more urgent.

The Search#

I quickly realized that pre-owned cars are surprisingly expensive nowadays. Having owned an old car, I also had some hard rules for the next one: Less than 100,000 km on the clock and less than eight years old. Also it would have to fit my family including the stroller while doing so without much hassle. Of course you can disassemble the stroller quite a bit, but I do not want to do that every time.

The Problems#

The problem with used cars is figuring out the exact model and feature set. Apart from the model name, car manufacturers often have specific version names. This part is still somewhat easy to figure out online as this is often mentioned. The problem comes with facelifts. Some car models have a light facelift and then a big facelift. Knowing which car is offered often does not reveal that. You have to rely on the research and the model year to get the right version. This also brings up the next problem: How do you compare the same car model twice when the features differ a bit? Comparing the distance the cars have covered and their age is easy. But how much is a tow hitch worth? Or: Can this specific model in this specific edition in this specific facelift of this specific construction year be fitted with a tow hitch? Those are the tough questions to answer.

The Fun#

I enjoyed the research itself: writing down information, watching tons of YouTube videos and learning a lot along the way. Seeing how far features had moved on from a 24-year-old car was fascinating, and for once I got to choose exactly which ones my next car had to have. Apart from the age and mileage, I had a few features in mind. A proper phone integration, for one: on the Volvo it had taken me ages to retrofit something properly, and even then it was far from perfect. Adaptive cruise control was another. And that was the quiet pleasure of the whole search - even buying used, I could write down exactly what the car had to have and then go looking for it.

The Cars#

Volvo#

The first thought was an obvious one: Another Volvo. My first Volvo had lasted for 24 years - how could this one not be obvious? Well in my family many drive Volvos and especially the newer versions. But they have had a fair share of troubles - often software related. Another major issue is the Volvo prices, especially for the higher-tier ones (XC60, V90, V90XC, XC90). So to find one reasonably priced, I would have to drop one of the hard requirements: Age and/or mileage.

Skoda Superb#

Another car I thought was fantastic is the Skoda Superb. From the reports I read about it online, it pretty much is like the V70: Tons of space, comfortable to drive and fairly fuel efficient. Looking at adults sitting in the back row was shocking: So much leg room. It also has some cool gimmicks, like an umbrella stored in the driver's door. I found out that the third generation of this model received a facelift in 07/2019. That was the model I was looking for. Apparently many people were after this kind of car. I was almost shocked by the prices for the given mileage. This is also when I realized that the used market in Germany was much cheaper than in Austria (~20%). But importing the car to Austria would again result in extra cost (temporary insurance, import fees, ...).

Skoda Octavia#

In parallel to the Superb, I also checked the best-selling car in Austria in 2025: The Skoda Octavia. It is the slightly smaller version of the Superb. Here there was a facelift in 2021. But I quickly realized that it wasn't much cheaper than the Superb. Since I considered the Superb to be more "premium", I then dismissed the Octavia.

Hyundai Ioniq 5#

A car I had always found awesome-looking is the Hyundai Ioniq 5.

A friend of mine has had an electric car for several years and is super satisfied with it. Usually when you tell someone you are considering buying an electric car, you will hear all the horror stories about it. But often those people do not even have experience with these cars. So I researched it thoroughly. At the start I did not even know what counts as normal consumption for an electric motor; for a diesel I knew 5 l/100 km was a good value. One special horror story is the "broken battery". But it became quickly obvious that you can generate a battery certificate stating the state of health of the car down to each cell. Apart from that, electric cars are less maintenance-heavy than combustion engines. That left the classic objection - low range paired with long charging times - as the one question that would not go away. I will come back to it where it belongs: the decision.

With the horror stories out of the way, I decided to look into the car properly. This is where I ran into a problem: Invest 1,000 € more and you get this much more. And another 1,000 € more and you get that feature. I also found out that, apart from the various editions (Basic, Uniq, ...), it also had the facelift issue mentioned before: There was a smaller facelift for the 2023 models and another one even later. So I checked prices for the 2023 version, since the long range version had 77.4 kWh battery capacity instead of 72.6 kWh. This is when I found a great deal in Germany. Here the import was easier, since cars newer than three years fell into a category where no inspection (§57a) was needed first. Also, since it was electric and used there were no real fees. The only necessary part was adding it to a general database so the insurance companies in Austria could insure it. That was around 186 €. The same car in the same version but pre-facelift would have cost 30% more in Austria. I drove to Germany with my father to have a look at it and give it a test drive. The appointment was coincidentally the day after my Volvo broke down. It is always advisable to bring along another person to check out a car. My grandfather was a mechanic, so my father learned a lot from him. And another person doesn't have this "Oh this might be my new car" gut feeling. So great questions came from my father: Can this car be retrofitted with a tow hitch? I hadn't considered this since my Volvo had one and I hardly ever used it. A car this new also means I would think twice before loading house-construction materials into it, to avoid scuffing the interior. A trailer would solve that problem.

The first test drive was almost anticlimactic. I had done so much research on the car due to the price that there weren't many things to discover. The only thing I discovered was the lack of some features. But this is when I realized that most YouTubers will review the highest tier of the car. The car had no power outlet, no seat cooling and no electrically adjustable seats. Nothing bad, but I did like the idea of those features.

The Decision#

With the Volvo now dead, finding a replacement suddenly gained real urgency. It had come down to two real contenders - the Superb and the Ioniq - and before I trusted my gut, I wanted to let my inner engineer loose and prove on paper that the car I was leaning towards would not be a reckless choice.

The Two Contenders#

To judge them fairly I also lined up my outgoing Volvo V70 D5 as a benchmark - the diesel estate that had served me for over a decade and crossed 300,000 km. On paper the three could hardly be more different, which is exactly what made the choice interesting.

The Ioniq 5 was the base trim, but in its Long Range form. That means the bigger 77.4 kWh battery, rated at 481 km WLTP. The car uses a single rear motor with 228 hp and 350 Nm, and an 800V architecture. It can even power external devices through Vehicle-to-Load. The boot holds 527 liters, plus a 58 liter frunk up front.

The Superb was the 1.5 TSI ACT Combi in Ambition trim: a 150 hp petrol engine, a manual gearbox and front-wheel drive. Its trump card is space. The boot starts at 660 liters and opens up to 1,950 with the rear seats folded, in a car that still weighs about 365 kg less than the battery-laden Ioniq.

Measurement note: There is no single standard boot volume measurement covering all three: the Ioniq and Superb use the modern VDA method, while the 2002 Volvo predates it and is quoted in DIN (to the window line), so the seats-up row is only roughly comparable. The truly like-for-like row is the seats-folded maximum, all measured to the roof - and there the long Volvo (1,641 l) actually overtakes the Ioniq (1,587 l), with the Superb well ahead of both.

Can it go the distance?#

The harshest row in that table is the range. On a long run the Ioniq manages around 480 km, where the Superb does about 1,000 km and the old Volvo even 1,150 km on a tank. Pair that with the fear of long charging times and you have the classic objection I had parked earlier - and on paper it looks damning. But most of it rests on the charging time, and this is where the 800V system quietly wins the argument. Charging from 10 to 80 percent takes around 18 minutes at a fast charger. A petrol stop is rarely the two-minute affair people picture either: I never refueled the diesel on the motorway, where fuel is the most expensive, so topping up meant leaving for a cheaper station off the motorway - real money saved, but time and a detour spent. Add that up and the gap to an 18-minute charge shrinks.

There is also the driver to think about. After a couple of hours on the motorway the Ioniq wants a charge, and a break does me good anyway. Even truck drivers are made to stop - by law they have to rest after four and a half hours behind the wheel. It is also just enough time for a coffee, which regular readers know I take fairly seriously. Far from lost time.

None of this is to pretend that topping up in three minutes and driving straight on would not be more convenient - it would. But the charging breaks are nowhere near the ordeal they are made out to be. And there is one thing the diesel never offered: because I charge at home, I set off every morning with a full battery. With the Volvo, a full tank always meant a detour to the petrol station first.

What it costs to run#

One detail genuinely surprised me. In Austria the motor-related insurance tax for an electric car is calculated from its continuous (30-minute) power, not the headline peak figure. The Ioniq's registration papers list only 56 kW / 76 hp of continuous power, even though it peaks at 168 kW / 228 hp. So the car that is far more powerful on paper gets taxed almost like a small one, while the 150 hp Superb is taxed on its full output plus a CO2 component. The more I dug into the running costs, the more the gap between these two narrowed.

To put numbers on it, I worked out the yearly running cost over 10,000 km, counting only the two things that differ cleanly: the Austrian motor tax and the energy. Insurance premiums depend on personal factors, so I left them out. The motor tax is hard to pin to the cent, but a fair estimate is around 320 €/year for the Ioniq (thanks to the 76 hp rule above) and around 700 €/year for the Superb. Over 10,000 km the Ioniq draws roughly 1,550 kWh, the Superb roughly 650 liters.

Realistically I always charge at home at about 0.15 €/kWh, so the Ioniq costs me around 550 €/year in tax and energy. The Superb would have run to about 1,675 €/year at 1.50 €/l and right around 2,000 €/year at 2.00 €/l. So the electric car saves me somewhere between 1,100 and 1,450 € a year on tax and energy alone.

Does it pay off over time?#

That yearly saving is real money, so the obvious question is whether it justifies paying more for the Ioniq in the first place. It cost me roughly 7,000 € more than the Superb. Plotting the cumulative cost of both over time shows where the lines cross:

So on energy and tax alone the Ioniq overtakes the Superb after roughly five to six years, and every year beyond that is pure saving.

Then there is maintenance, which I had underestimated. An electric car has no oil changes, no spark plugs, no timing belt and no clutch, and because it brakes mostly by recuperation the pads and discs last far longer. Consumer Reports puts EV maintenance at about half that of a comparable petrol car, roughly 4,600 USD saved over a car's life. Counted conservatively at a few hundred euros a year, that pulls the break-even point forward to somewhere around four to five years.

Is that on its own a reason to spend 7,000 € more? Honestly, only just. Over a short ownership it would never pay back, and the sum ignores depreciation and the small risk of an expensive EV repair. But I usually keep my cars for many years - I had the Volvo from the end of 2013 until early 2026 - and on a ten-year horizon the Ioniq saves something like 11,000 to 14,500 € in tax and energy, well past the 7,000 € premium, with several thousand euros left over before maintenance even enters the picture. So the money was never why I bought it, but it is a solid argument that the extra spend was not just my heart talking.

None of this is solid ground, though. The calculation is useful for getting a feel for the numbers, but it is fragile. Electricity tariffs move around, and fuel prices change constantly - right as I was buying the Ioniq, oil prices jumped sharply when the conflict involving Iran escalated. A single year of cheap petrol or expensive electricity can tilt the whole picture. So I treated the figures as a sanity check, not a promise.

All of that assumed my own fairly modest 10,000 km a year. The purchase premium and the motor tax do not care how much you drive, but the energy and fuel costs scale directly with distance - so a higher-mileage driver reaches the crossover much sooner:

Why I chose the Ioniq 5#

On paper the Superb was the easier, safer choice. It was already registered in Austria, so there was no import to organize. It ran on technology I knew inside out, and it was in many ways a direct descendant of my Volvo: a big, comfortable estate that quietly does everything. Picking it would have been the low-risk, low-effort decision.

One thing nagged at me, though: three previous owners on a car only five years old. That is a lot of hands for such a young vehicle, and it is exactly the kind of detail that makes you wonder what each of them knew that I didn't. The more owners a car has had, the harder it gets to trace when any damage happened, or whether a fault was quietly passed down the line. On its own not a dealbreaker, but a yellow flag - especially next to the Ioniq's single, careful owner.

The Ioniq, on the other hand, was simply the car I wanted. It is the one I had admired since it first appeared, and the research had already taken the air out of the horror stories. The long warranties did the rest - the battery covered into 2031 and the car itself into 2028 - which made stepping into unfamiliar technology feel a lot less risky. On top of that came everything the numbers above already showed: charging breaks I can live with, lower running costs and less maintenance.

It also quietly ticked the list I had set out with. It sat comfortably inside my age and mileage limits, took the stroller without a fight, and came with the two features I had wished for: proper phone integration, which the Volvo only ever managed clumsily, and adaptive cruise control, which the old car never had at all. The things it lacked - a power outlet, seat cooling, electric seats - were all comforts I had never had in the first place.

So the Superb was the sensible echo of the car I was saying goodbye to, and the Ioniq was a deliberate step into something new. The running-cost math gave me permission to do it - the rest was simply wanting the car.

Final Thoughts#

Swapping a 24-year-old Volvo for a brand-new kind of car was a bigger leap than the spreadsheets made it look. The numbers helped me find my footing, but in the end I bought the Ioniq because I wanted it, and let the running costs reassure me that it was not a reckless choice. A few months in, it has been exactly that: quiet, effortless, and cheap to run straight from the wall at home. The Volvo was an old friend I trusted without thinking; the Ioniq still has to earn that. So far, it is well on its way.

Improving as a developer is important, but finding good ways to do it is not always obvious. At the same time, programmers have a habit of automating problems instead of just solving them. Somewhere between those two observations I found a sweet spot: small projects that solve a real, personal problem while sharpening the basics along the way.

The four projects below are nothing groundbreaking. They were never meant to be. But each of them taught me something I still use today, and writing them was more fun than doing the same task by hand would ever have been.

Travel Weather#

While packing for a multi-stop road trip, I wanted to know the weather forecast for every destination at once. Looking up city A, then city B, then city C is a five-minute job - boring, but doable. Of course, packing and clicking through forecasts back to back is no fun, so I wrote a small Python tool instead.

For the data I used OpenWeather, which has a free tier and a clean API. The tool takes a list of locations and dates and prints a compact forecast for the whole trip.

uv run python -m travel_weather --weather \
    "Salzburg:2026-04-28:+1" \
    "Bridgetown:2026-04-29" \
    "Kiruna:2026-04-29:+1"

would print something like

Weather forecast for city: Salzburg
Start date: 2026-04-28
End date: 2026-04-29
2026-04-28: min 12.1°C, max 17.0°C, mostly ☁️ clouds
  12:00   16.9°C ☀️ clear sky
  15:00   17.0°C ☁️ scattered clouds
  18:00   13.7°C 🌦️ light rain
  21:00   12.1°C ☁️ overcast clouds
2026-04-29: min 4.4°C, max 14.2°C, mostly ☁️ clouds
  00:00    8.5°C 🌦️ light rain
  03:00    8.6°C 🌦️ light rain
  06:00    6.7°C 🌦️ light rain
  09:00    7.7°C ☁️ overcast clouds
  12:00   13.2°C ☁️ overcast clouds
  15:00   14.2°C ☁️ scattered clouds
  18:00    8.0°C ⛅️ few clouds
  21:00    4.4°C 🌙 clear sky
Summary for Salzburg: Min Temp: 4.4°C, Max Temp: 17.0°C Layer up - it's a grey one. Bundle up with a 🧣, 🧤 and a warm jacket.
-----------------------------------------------------------------------------------------------------------------------------

Weather forecast for city: Bridgetown
Start date: 2026-04-29
End date: 2026-04-29
2026-04-29: min 26.0°C, max 27.9°C, mostly ☁️ clouds
  00:00   26.5°C ☁️ scattered clouds
  03:00   26.3°C ☁️ broken clouds
  06:00   26.0°C ☁️ broken clouds
  09:00   26.0°C ☁️ overcast clouds
  12:00   26.9°C ☁️ broken clouds
  15:00   27.9°C ☀️ clear sky
  18:00   27.9°C ⛅️ few clouds
  21:00   27.3°C ☁️ overcast clouds
Summary for Bridgetown: Min Temp: 26.0°C, Max Temp: 27.9°C Layer up - it's a grey one. Pick lightweight, breathable layers.
---------------------------------------------------------------------------------------------------------------------------

Weather forecast for city: Kiruna
Start date: 2026-04-29
End date: 2026-04-30
2026-04-29: min -5.6°C, max -0.2°C, mostly ☁️ clouds
  00:00   -5.6°C ☁️ broken clouds
  03:00   -5.2°C ☁️ overcast clouds
  06:00   -3.4°C ☁️ overcast clouds
  09:00   -2.9°C ❄️ light snow
  12:00   -1.7°C ❄️ light snow
  15:00   -0.2°C ☁️ overcast clouds
  18:00   -0.5°C ☁️ overcast clouds
  21:00   -0.9°C ☁️ overcast clouds
2026-04-30: min -0.7°C, max 4.5°C, mostly ☁️ clouds
  00:00   -0.3°C ☁️ broken clouds
  03:00   -0.7°C ☁️ overcast clouds
  06:00    1.5°C ☁️ overcast clouds
  09:00    4.1°C ☁️ overcast clouds
  12:00    4.5°C ☁️ overcast clouds
  15:00    3.0°C ☁️ overcast clouds
  18:00    3.4°C ☁️ overcast clouds
  21:00    2.3°C ☁️ overcast clouds
Summary for Kiruna: Min Temp: -5.6°C, Max Temp: 4.5°C A layered outfit suits today's clouds. Pull out the warm jacket, 🧣 and 🧤.
--------------------------------------------------------------------------------------------------------------------------------

Summary for all cities:
Warmest City (Bridgetown): Dress in layers. Pick lightweight, breathable layers.
Driest City (Bridgetown): Dress in layers. Lightweight and breathable - you'll thank yourself.
Coldest City (Kiruna): Stick to layered clothing today. Bundle up with a 🧣, 🧤 and a warm jacket.
Wettest City (Salzburg): Dress in layers. Layers help - the temperature will swing.
--------------------------------------------------

What stuck with me from this one was working with HTTP APIs from Python for the first time.

This was actually one of the first projects I used AI with. I thought it was a nice idea to add text for the clothing and of course AI added emojis.

Meta Flight Search#

Finding cheap flights gets harder the more flexible you are. I often knew roughly when I wanted to travel but had several possible origin airports, no fixed destination and a flexible return date. Web-based flight search engines hit their limits quickly under that kind of input.

So I solved it the same way I solved Travel Weather: a Python tool, this time on top of the Kiwi Tequila API. It takes a list of origin airports, a list of destinations, an acceptable travel window, a stopover limit and returns the cheapest combinations it can find.

It also taught me to think about API budgets. Two origins, two destinations, two start dates and two end dates already produce 16 calls. Adding a third destination jumps it to 24. That number grows fast - the relationship is plain enough:

def count_api_calls(
    origins: list[str],
    destinations: list[str],
    start_dates: list[str],
    return_dates: list[str],
) -> int:
    return len(origins) * len(destinations) * len(start_dates) * len(return_dates)

One multiplication, four inputs - and each added option multiplies the cost rather than adding to it. That alone shaped every later flag: anything that lets the user narrow the search space earns its place.

I also tried to make the tool more approachable by wrapping it in a small web UI using PyWebIO. Building a CLI that is both powerful and friendly is genuinely hard, and that experiment was a useful reminder of why most "quick" tools stay command-line only.

The real lesson here was about constraints. Without them, the cheapest flight is usually a 30-hour itinerary with three layovers - technically the answer to "find the cheapest flights", but not what I actually wanted. That is why the CLI options grew over time, with the stopover limit being the obvious example. I never used the tool as much as I had hoped, mainly because my travel volume dropped not long after - but designing around real-world constraints, rather than just the API's, has stayed with me.

TickTick to Joplin#

For years I have been using TickTick as my todo app. While looking into self-hosting more of my own tooling, I found Joplin, which doubles as a note-taking app and stores everything as plain Markdown. The same instinct that led me to replace my old Image to Text tool with Paperless-ngx was at play here: I liked the idea of owning my data in a portable format.

Joplin happily imports folders of generic Markdown but not TickTick's specific export format, so I wrote a small Python converter to bridge the two.

Most of the work was not the wiring between formats. It was the small ambushes hiding in the data. All-day reminders, for example, were exported as UTC midnight. After converting to Vienna time that lands in the small hours of the night, and a reminder firing then helps no one - so all-day items had to be pinned to a sensible hour instead:

from datetime import time
from zoneinfo import ZoneInfo

local = utc_dt.astimezone(ZoneInfo("Europe/Vienna"))

if local.time() == time(0):
    local = local.replace(hour=9)

Every TickTick row had a small surprise like this - the kind of detail that never shows up in an export spec but breaks immediately the moment a user tries to live with the result.

The converter did its job, and the project taught me a lot about taking messy exported data, reshaping it and handing it to another tool in the form it expects. The migration itself, on the other hand, never really happened. I never set a hard cut-off date after which new tasks had to land in Joplin instead of TickTick, and without that deadline, the old habit won.

Person Event Statistics#

At some point I got curious about how the length of an ongoing phase of life compares to the rest of it. How much of my life have I spent studying? What share of it has been with my current employer? It is the kind of question you can answer on the back of an envelope, but I had recently been enjoying Python and decided to write something for it.

As usual, I went a little overboard - and had fun doing it. The tool reads events from a JSON file and visualizes them. It started out printing plain statistics, until I discovered Python's built-in tkinter and added a small GUI on top. With that in place, adding new events from the UI and rendering them as a bar chart against total lifetime came naturally.

It is in the same spirit as my early Weatherstation and Image to Text projects: pick a small itch, scratch it in Python and let the side quests teach you something new.

Looking back, this one was built during a demanding stretch in my personal life, where a lot of things were out of my hands. Having a small, self-contained coding task with clear inputs and a clean endpoint turned out to be unexpectedly grounding. A quiet reminder that side projects can serve more than just curiosity.

Final Thoughts#

These projects are a small sample of things I have built that never made it anywhere public. None of them solved a problem I could not have solved by hand. All of them were more interesting because I solved them with code.

The pattern is almost always the same. I get a working prototype, then I keep adding features for fun, and somewhere in that second phase I end up learning the actual lesson:

• How to design a CLI that is comfortable to use.
• Staying focused on the original problem instead of disappearing into the tooling around it.

In the end, learning new things while solving an existing problem is what keeps me coming back. There is always another small itch worth scratching.

I walk into my home office - click - and the desk lights up. Some time later - ping - my phone tells me the coffee machine is ready. And when the workday is done, the desk - click - shuts down on its own.

Magic? Not quite. Just Home Assistant and a few power outlets.

Home Assistant Automations#

I have written about Home Assistant a few times. The part I like most is that it is a gigantic toolbox. Similar to paperless-ngx, it can solve all kinds of problems - no matter how tiny they might seem.

As I mentioned in my post about mail automation, I really do enjoy automating things. Most of the time the upfront work takes longer than the time an automation will ever save. But building it is the fun part.

Here is a small selection of automations I built in Home Assistant and genuinely enjoy having.

Power Outlet Automation#

My desk has two WiFi power outlets:

• One mainly for my personal computer
• One for "everything else" (display, speakers, chargers, ...)

I also ended up with a Philips Hue dimmer switch from a bundle. In the Hue ecosystem it is meant to control lights (in my case: Hue Play Lightbars as indirect lighting).

But the nice part is that the dimmer switch can be remapped in Home Assistant. The Play Lightbars are Hue, the outlets are not - and Home Assistant happily ties those worlds together.

So one of the four buttons now controls the desk power via MQTT:

• Short press: turn the desk outlets on (safe default, avoids accidental shutdowns)
• Long press: turn the desk outlets off

alias: Desk & Computer Off
description: Switch off the Desk and Computer Switch
triggers:
  - device_id: ...
    domain: hue
    type: long_press
    subtype: 1
    unique_id: ...
    trigger: device
conditions: []
actions:
  - type: turn_off
    device_id: ...
    entity_id: ...
    domain: switch
  - type: turn_off
    device_id: ...
    entity_id: ...
    domain: switch
mode: single

Once that worked, it was hard not to add a bit more.

With the Hue bundle I also got a motion sensor. Again: easy to integrate into Home Assistant. I use it for a simple "morning automation": on workdays, if there is motion between 6:00 and 9:00, the desk turns on.

The best part, though, is using power draw as a signal. My desk standby power is surprisingly high (around 40 W), so I prefer cutting power completely. If the desk outlet stays below a threshold (for example 45 W) for 15 minutes, Home Assistant switches it off automatically.

The end result is exactly what I wanted: I sit down and things wake up. When I am done, I just leave.

Out of curiosity, I calculated a simple "what if" case: what would it cost if this outlet stayed on for a full year without the desk being actively used? At an average standby draw of 40 W, that comes to 0.96 kWh per day, or roughly 350 kWh per year. Assuming an electricity price of 0.30 € per kWh, that is about 105 € per year.

Coffee Machine State#

As mentioned in my post about espresso makers, I love good coffee, but I do not love waiting for an E61 machine to warm up.

The solution (again) was a WiFi power outlet. It publishes its state via MQTT and can also be controlled via MQTT. Whenever the outlet changes to "ON", Home Assistant starts a timer. When it expires:

• I get a push notification on my phone (via the Home Assistant app)
• My pixel clock on the desk shows that the machine is ready

I used to do this with iOS Shortcuts, but Home Assistant made it easier to send the same signal to multiple devices.

Nobody Home (Or Awake) Automation#

Another WiFi power outlet automation.

When I started with Home Assistant (in a rented apartment), I had no built-in smart home stuff. Power outlets were the easiest way to get results quickly - and they are still useful.

In this case I wanted to reduce standby consumption and also deal with one very specific problem: my TV sometimes turned itself on in the middle of the night. It also benefited from a regular reboot anyway. A smart outlet solved both.

The trigger is simple: when both my wife's phone and my phone leave the WiFi, I treat that as "nobody is home (or awake)". In that state, the TV definitely does not need power, so Home Assistant turns the outlet off. As soon as either phone appears in the network again, the outlet is automatically switched on again.

I did not apply this rule to the computer or coffee machine. The computer might be left on intentionally (updates, downloads, ...), and the coffee machine might be switched on while on the way home.

Final Thoughts#

Home automation is fun when it works.

I am still surprised by how much you can do with Home Assistant - mainly because you can make things fit your exact needs. You are not forced into whatever the vendor thought was a good idea.

Even tiny annoyances like "I have to keep holding a button to switch off power" are worth solving. Not because it is hard, but because it removes friction from daily life and even saves money.

One lesson that matters more than it should: keep a clean naming scheme and structure. Once you add a few devices, it gets confusing fast if names are inconsistent.

That is also why I set up Home Assistant from scratch after moving. My first setup started as a test and slowly turned into "production" without ever getting cleaned up.

For now, these automations work great. And judging by my track record, more will follow.

It's evening after a long day of work. A new email arrives with a PDF attachment — one of those documents you want to keep: save it somewhere safe and make sure it ends up in backups.

I used to do this manually: download the attachment, move it to the right folder on my NAS and then forget about it until I need it again.

Now that same email gets a blue tag in my mail client and the attachment is already filed away — on my NAS and backed up. Sorcery? Not quite. Just open-source.

Automate regular tasks#

I like automating repetitive tasks. For example: my desk power strip switches off automatically once the power draw stays below a threshold for a while. And the TV power is cut when two specific phones leave the Wi‑Fi — a simple "nobody's home (or awake)" signal.

This kind of "laziness" is a good excuse to learn new tools — or, in this case, to use an existing tool more effectively. When I received the same type of email again, I finally looked for a way to store those attachments automatically on my NAS (and therefore inside my normal backup routine).

Paperless-ngx once again#

My first instinct was to solve this in the mail client.

But I don't use the same mail client across all devices and client-side automation tends to be fragile: one device ends up being "the automation machine", it needs NAS access, it has to be online at the right time and so on.

I also checked what my mail provider could do. That didn't get me to a clean "file attachments to the NAS" workflow either — especially not one that integrates with my storage and backups.

Then I remembered that Paperless-ngx has an "incoming mail" feature. Since Paperless already lives next to my storage and backups (and is part of my self-hosted stack), this was exactly the missing piece.

After reading the docs and a few guides (e.g. this one in German), it was clear: I'm not the first person with this problem and Paperless-ngx has a solid solution.

Setup#

The setup is well documented and boils down to two concepts:

1. Defining an e-mail account in paperless-ngx. This is necessary once per e-mail account.
2. Defining e-mail rules for the e-mail account. This is necessary once per process you want to define.

Step 1 is basically "configure IMAP": server address, port, credentials. Similar to setting up a mail client on your device.

Step 2 is where the magic happens: you define rules that decide which emails should be processed. I filtered by:

• mailbox (inbox)
• sender
• subject
• age

Then I configured the rule to consume only the attachment (not the email body). When Paperless-ngx imports the attachment it can automatically set metadata like tags and correspondent.

Finally, I wanted a quick confirmation in my mail client that an email was handled correctly — especially while testing. Paperless-ngx can tag the processed email with a custom IMAP keyword and also ignore emails that already carry that keyword.

In my case, I used the keyword apple:blue, which shows up as a blue tag in Apple Mail.

And that's it: emails arrive, attachments get consumed and the originals are marked as processed.

Final Thoughts#

This was a good reminder to look at the tools I already use before building something new: Paperless-ngx already solved the hard parts.

Manually moving a PDF to a network share isn't difficult — it's just the kind of task that's easy to postpone or forget. Automating it removes that mental overhead and makes the process consistent.

Paperless-ngx keeps on impressing me. And judging from my track record, this won't be the last time I'll find another feature that quietly solves an everyday annoyance.

The office was silent. I had just poured myself a fresh coffee, ready to dive into the morning's work. My trusty Logitech MK710 sat in front of me – wireless, comfortable, leagues better than those terrible standard keyboards that come with most office computers. Perfect for a productive day.

Then I heard it: clack-clack-clack-clack.

It wasn't a typewriter, though it sure sounded like one. A colleague had started using a mechanical keyboard in the office. I found myself oddly captivated by the rhythmic clicking. After our coffee break conversation about his new keyboard, I figured I'd do what any reasonable person would do: take a quick look online to see what the fuss was about.

What followed was anything but quick. I had stumbled into a rabbit hole I didn't know existed.

The Gateway Drug#

My first purchase was a Corsair K70 RGB Mk.2 with Cherry MX Blue switches. Looking back, it was the perfect entry point – feature-rich without being overwhelming. The dedicated media controls and volume wheel quickly became indispensable. There's something satisfying about reaching up to skip a song without Alt+Tab out of your work. The metal top plate made it feel substantial, valuable even.

The only thing I disliked? That distinctly "gamer" aesthetic. Not everything needs RGB lighting that cycles through the entire color spectrum. But it did its job: it got me interested. More than interested, actually.

I started browsing Reddit. Then forums. Then YouTube. I discovered that keyboards weren't just tools – they were a hobby. People discussed switch types the way others debate coffee beans. They talked about "actuation force" and "travel distance". Some folks even lubed their switches by hand, disassembling each one and carefully applying lubricant with a tiny paintbrush.

This was deeper than I'd imagined.

Building My Own#

Somewhere in my Reddit browsing, I found the SofleKeyboard. A split keyboard. Column-staggered layout. OLED displays. Rotary encoders. And here's the kicker: you had to build it yourself. It wasn't available for purchase.

I was sold immediately.

A friend shared my newfound enthusiasm, so we embarked on this together. We ordered PCBs, switches, screws, and every little electrical component from the bill of materials. It was expensive – the PCBs alone cost more than I'd expected. But I was fascinated by something else: this entire keyboard design, including the build guide and parts list, was freely available online. Someone had designed this, built it, perfected it, and then just... shared it. For free. So others could recreate it.

The build was incredible. The finished product looked fantastic with its split design and those little OLED screens. But using it? That was a different story.

The column-staggered layout meant all the keys were arranged in neat columns rather than the traditional row-stagger we're used to. Your hands barely move once you learn it. The reduced key count (only 58 keys total) meant everything lived on layers – pressing a function key transformed the keyboard entirely. The K could be a K, or an arrow down, or an asterisk, depending on what else you pressed.

It's brilliant in theory. With enough practice, your fingers never leave the home row. You can program custom macros. It's endlessly customizable.

But then came the problem: keyboard shortcuts. Try pressing Ctrl+Shift+Alt+↓ in Visual Studio Code – a common shortcut for adding multiple cursors. On the Sofle, that becomes Ctrl+Shift+Alt+↓ + the Upper Layer key. Five keys at once. Your hand contorts into positions that'd make a yoga instructor wince.

And there was another issue I hadn't considered: muscle memory. The Sofle requires you to use the same keyboard everywhere. Your brain adapts to those layers, to those key positions. Switch to a regular keyboard and suddenly you're fumbling like you're learning to type all over again. I discovered that I type the letter B with my right index finger – perfectly fine on a normal keyboard, but on the Sofle, B sits on the left half. My brain refused to cooperate.

The Sofle taught me something important: not every keyboard is meant for every use case. Sometimes the perfect keyboard on paper isn't perfect in practice.

Finding the Sweet Spot#

My next keyboard took longer to choose. I knew what I wanted now: hotswappable switches (no more desoldering), a more traditional layout, and crucially, ISO-DE support. I use German layout, and apparently, this hobby is heavily ANSI-focused. Finding ISO-DE keycaps became a recurring nightmare.

I nearly built an Isometria 75 – another open-source design – but the creator mentioned ongoing issues with the board. I'd learned my lesson about jumping in too quickly.

Then the GMMK Pro was released. A 75% keyboard (meaning it has roughly 75% of a full keyboard's keys – goodbye numpad). ISO-DE layout. Hotswappable switches. A rotary encoder. It looked perfect.

It was also expensive. Very expensive. And that was before buying switches and keycaps.

I justified it the way I justify all my work equipment: compared to a carpenter or goldsmith, my initial investment is minimal. A desk, a chair, a monitor, peripherals – these are my tools. If I'm going to use something every single workday, I want to enjoy using it.

The GMMK Pro arrived, and it was everything I'd hoped for. That full metal housing felt premium. The layout was exactly what I needed – enough keys to stay productive, few enough to keep my hands from wandering. The journey seemed complete.

Then I started watching more YouTube channels about keyboards. Because of course I did.

The Current Champion#

The NEO65 changed the game again. A 65% layout (even more compact than the GMMK Pro, losing the function row entirely). But here's what made it special: it supports both ISO and ANSI layouts. It works wirelessly via USB dongle, has Bluetooth, and can be wired. And unlike most prebuilt boards, you can customize the firmware.

That last bit was crucial since I didn't want to have a macropad lying around on my desk.

It came with an array of foam and dampening materials – sound-tuning options I hadn't used before. After hours of tinkering, I had it exactly where I wanted it.

This is the keyboard I use daily now. It's genuinely the best typing experience I've had.

The Collection Grows#

I should mention the others that found their way into my life:

• The Das Keyboard 4 with Cherry MX Brown switches was my office keyboard at my previous job. Solid, professional, utterly unremarkable. It did its job and nothing more.
• The Logitech MX Keys Mini brought me full circle to that original MK710 feeling – great battery life, wireless, reliable. Sometimes it's nice to work on something that isn't mechanical. And the connectivity is brilliant: I can reach the TV-connected computer from across the room, or quickly respond to a longer email on my phone by connecting the keyboard to it. (Yes, I refuse to type long messages on a phone screen.)
• The Logitech MX Mechanical Mini sits at my current workplace. It's a fun middle ground – low-profile mechanical switches that feel like something between the MX Keys and a traditional mechanical keyboard. Plus, one USB dongle can handle both the keyboard and mouse.

The Numbers Game#

Dive deep enough into keyboards and you'll inevitably encounter typing tests. People showcase their keyboards in action, usually on sites that measure your words per minute. It's become part of the culture.

I'll admit: I enjoy these tests. Not because they matter much for programming – typing speed is rarely the bottleneck in software development. But they're useful for comparing setups. How do switches compare to each other? Is this new keycap profile better for me?

Monkeytype is my favorite. It tracks three main metrics:

• WPM: Words per minute (total correct characters divided by five, normalized to 60 seconds)
• Acc: Percentage of correctly pressed keys
• Consistency: How steady your typing speed stays

I decided to put my keyboards to the test.

The Experiment#

I tested each keyboard three times: 30 seconds, lowercase English only. Here's what I found:

Some observations:

Three runs is laughably insufficient data, but the patterns are interesting anyway. The Neo65 comes out on top – no surprise since I use it daily. That the MacBook Air takes second place is also no surprise: It is my primary personal computer.

The Sofle numbers are misleading. I haven't used it in months, and you can see the practice effect: 51 WPM on the first run, 69 WPM by the third. The consistency jumped from 49 to 66. Give me a week with it and those numbers would look very different.

Using the Sofle also revealed something about my typing: I hit B with my right index finger. On a traditional keyboard, this works fine. On the Sofle, where B sits on the left half, my brain staged a revolt.

The phone numbers explain why I hate typing on mobile devices: I'm literally half as fast. I even tried using the dictation function, but that went very poorly.

Final Thoughts#

What started with a colleague's clicking keyboard became a hobby for some time. It's fascinating how these rabbit holes appear everywhere – coffee, mountain bikes, mechanical keyboards. Each one seems simple on the surface, but dive in and you find entire communities, deep technical knowledge, and endless optimization possibilities.

Someone might reasonably ask: why spend hundreds on keyboards when your typing speed barely changes?

For me, it's simple. Compared to other professions, the investment is minimal. I use a keyboard every single workday. If a carpenter needs quality tools and a goldsmith needs precision instruments, why shouldn't I enjoy the tool I use most?

The real limitation for me was the ISO-DE layout. I considered switching to ANSI – it would open up endless keycap options. But I'd have two layouts competing in my muscle memory. I already experience this with keyboard shortcuts: my brain uses Command on thin keyboards (like the MX Keys) because it associates them with Mac layouts, and Ctrl on everything else. Adding another mental mapping seemed like asking for trouble.

Lately keyboards have become a quiet topic for me. I enjoy what I have and feel no urge to change anything right now.

For now, the Neo65 sits in front of me, ready for another day of work.

It’s fall, the mornings are crisp, and temperatures are edging toward freezing. My garage is still unfinished, so I get into a cold car dreaming of the warm cup of coffee waiting at the office.
Today is the first morning this year that I use the auxiliary heater. I leave home a bit late and immediately pay for it — heavy traffic. But I don’t really mind. A good podcast is running, and even if I did mind, the traffic jam would still be there.
When I glance down at the dashboard to check the time, a small milestone quietly announces itself: 300,016 km.

My Car#

I bought the car at the end of 2013, and it has been good to me ever since. It’s a 2002 Volvo V70 II D5 with a 2.5‑liter diesel engine producing (or once producing) 163 hp. In everyday driving, it consumes about 6 l/100 km in summer and 7 l/100 km in winter — though this varies quite a bit.
Back in my student days, when I was studying 500 km away from home, I once managed 1,400 km on a single tank, translating to an impressive 5 l/100 km. When I bought it, the odometer showed around 150,000 km. That means an average of about 12,500 km per year since.

The Good#

For many reasons, the car is a keeper. Despite its size and age, it’s still remarkably economical. It swallows everything I throw at it — including my mountain bike — without having to remove a single wheel.
Other than the usual maintenance, it has required no major repairs. With roughly 160 hp, acceleration feels solid, and the 2.5‑liter engine makes highway driving relaxed. You can technically go from 30 km/h all the way to 210 km/h in fifth gear — given enough patience.
Roof rails allow for all sorts of attachments, though I haven’t experimented beyond a few ski trips. The tow hitch has proven handy more than once. The cruise control works like a charm, the AC still blasts icy air, and the auxiliary heater has saved me from many cold mornings.
Most of my apartments didn’t have a garage, so the Volvo often stood outside. The seats — after 23 years — remain as comfortable as ever.

The Bad#

No car this old is perfect. The auxiliary heater, for example, relies on a timer. If you forget to set it or leave at unpredictable times, you either drive off in a cold car or walk out early to start it manually.
There’s also a safety feature that disables the heater permanently if it fails to warm up properly three times in a row. Only a Volvo workshop can reset it.

Then there’s the entertainment system. Mine came with a cassette player that can even skip tracks, but not the optional CD changer. I went through the usual experiments — starting with FM transmitters — before finally installing a Bluetooth module that emulates a CD changer and integrates with the stock radio. It works fine, but it lacks conveniences like autoplay and track selection. In short, it’s good but not elegant.

Rear-seat safety is another issue. Isofix wasn’t standard back then, so families had to make do without it. Retrofits are possible but hard to find and expensive.
And finally, perhaps the car’s biggest weakness: the headlights. Even with high beam, visibility is mediocre. More than once, the car behind me has provided better road illumination than my own lights.

The Memories#

After twelve years together, the Volvo carries a lot of memories. Countless road trips through Croatia, Italy, the Czech Republic, Germany, Switzerland, Slovenia, and of course plenty of drives across Austria.
The best part isn’t just the destinations, but the journeys themselves — the long talks, the quiet moments, the feeling of starting your holiday as soon as you leave the driveway.

One small story stands out: the original battery lasted 18 years. When it finally gave up, I almost felt like it deserved a proper farewell.

Final Thoughts#

The Volvo V70 has been a loyal companion — practical, efficient, and surprisingly comfortable after all these years.
Rust is beginning to appear here and there, but nothing critical yet. I hope it stays on the road a while longer. After 300,000 km together, it feels less like an old car and more like an old friend.

The cool morning air smelled faintly of pine and dew as I rolled past the quiet streets of my home town, the city slowly stirring awake beneath soft golden light. Ahead awaited over 450 kilometers of winding paths, mountain climbs, and countryside vistas — an adventure that stretched beyond a typical bike ride into a journey of endurance, friendship, and discovery. Crossing borders, tracing repurposed rail trails, and finally reaching the sun-drenched coast of Italy, this wasn’t just a cycling trip; it was a chance to reconnect with the world at a human pace after months confined by the pandemic.

In 2018, I got my first proper mountain bike, but it wasn’t until 2021 — amid global travel restrictions — that the idea of a longer, multi-day bikepacking adventure really took hold. What began as two friends fueled by wanderlust grew into an epic multi-day ride along the Ciclovia Alpe Adria, testing our preparation, stamina, and love for exploration.

Preparation#

The preparation consisted of multiple aspects: Training to build enough endurance to manage the distance and elevation gains. Preparing the bike and maintaining it properly before starting the journey. And perhaps most importantly: Packing as little as possible while bringing everything needed. This would prove to be crucial for enjoying the journey ahead.

Training#

I didn't follow any special training plan - I simply tried to go out for a bike ride whenever possible. Even my daily commute to the office results in roughly 30 km of cycling. Since I had just gotten my new bicycle, it was naturally fun to go out for a ride whenever possible. So the training aspect of preparation happened organically as part of my new bike enthusiasm.

Bike preparation and maintenance#

Owning a new bike made me anxious about potential theft during this trip. I had considered bike insurance, but a friend made a compelling point against it: "There are so many bikes, especially e-bikes, that are worth way more. Why would anyone steal this bike if it's secured with a proper lock?" So I invested in an Abus CityChain 1060. While being very secure, it's also quite heavy. But given its size, we could use it for both bikes and share the weight burden during the trip.

For maintenance, I followed the standard procedure: clean the bike thoroughly, oil the chain, and check the tire pressure. I also refined the seating position beforehand to ensure optimal comfort, and installed a holder for a second water bottle - something that would prove invaluable on longer stretches.

Packing strategy#

The key to a successful bike tour is bringing everything you need while leaving behind everything you don't. Every additional gram means more weight to carry with you over hundreds of kilometers.

I met up with my cycling partner and we carefully discussed who would bring what. Despite having no previous bikepacking experience - spoiler alert - we managed to bring along just enough gear for the ride. The only items we arguably packed "too much" of were spare inner tubes, but as any experienced cyclist knows, those are always good to have extras of.

Route planing#

We then laid out a rough route with a flexible time plan. Since neither of us was fully prepared for such a demanding tour - despite our regular rides in good weather - we planned to cycle to Golling and take the train from there to Böckstein. This would allow us to avoid the most challenging mountain section of the trip. We also deliberately scheduled plenty of extra time. After all, this was a week off work - it should be enjoyable and not stressful.

Ciclovia Alpe Adria#

The Ciclovia Alpe Adria is a cycle path connecting Salzburg to Grado. It has ready made stages to follow and is very popular - thus there are many accommodations along the way to host bikes along the riders. Additionally, going back from Grado is also easy - especially compared to the public transportation - as there are several companies offering van rides back reasonably priced.

Day 1 - Home to Golling / Bischofshofen#

We met up near our homes - each cycling a few kilometers individually before starting the journey together. Right away, we got stuck in a mud puddle while trying to avoid the main roads through a forest path. It felt like a warning of challenges to come, but fortunately, it wasn't representative of what followed. The weather turned out to be perfect, the bike routes were nearly empty (especially in the beginning), and we felt energized and motivated for the adventure ahead.

This first day also marked our first border crossing between Germany and Austria. To maintain high energy levels, I had packed plenty of energy bars to share. This quickly became our daily ritual: regular stops to reenergize.

We continued through Salzburg towards Hallein. Despite encountering many bike commuters, it was refreshing to experience a familiar city from the saddle of a bike. Until then, I had usually navigated Salzburg by car, bus, or on foot. But as I mentioned in a previous blog post, cycling offers its own perfect pace for experiencing places.

Heading south, we were grateful for the abundant signage guiding us in the right direction. Passing through Urstein brought back memories, as I had studied there for my bachelor's degree. It's surprising how much one can forget about familiar places over time.

Soon we arrived in Hallein, a beautiful historic city. We were pleasantly surprised by our progress and stamina - neither of us showing signs of fatigue yet.

We continued to Golling, which was meant to be our endpoint for the day. However, we discovered that the trains between Golling and Böckstein were fully booked with cyclists. So we instead took the train to Bischofshofen to stay there overnight, and hope for available space on the train to Böckstein the next day.

In Bischofshofen, we took some time for sightseeing, particularly impressed by the ski jump arena. After our long day of cycling, we enjoyed a hearty dinner and attempted to get an early night's sleep in preparation for the challenging day ahead. Not all goals were achieved that evening, however.

71 km covered.

Day 2 - Bischofshofen to Böckstein / Mallnitz to Untergratschach#

We started the day somewhat tired after our attempts at an early night. Fortunately, as the saying goes, the best cure for tiredness is exercise - and we had plenty ahead of us.

The stunning landscape definitely boosted our spirits. The scenery was consistently breathtaking, and before long we arrived at Bad Gastein. Before tackling the climb ahead, we decided to fuel up with a proper meal. This proved to be a wise decision, although the ascent through the beautiful town of Bad Gastein went more smoothly than anticipated. Had we known how manageable it would be, we might never have considered taking the train from Golling to Bischofshofen.

Upon reaching Böckstein, we were fortunate to secure spots on the train. Arriving in Mallnitz - now in Carinthia - we found we still had energy to spare and decided to continue. We passed through a town that seemed promising for overnight accommodation, but upon discovering a large festival in progress, we decided it would be wiser to press on a bit further.

We eventually stopped in Obervellach for the night. Since our goal for the day had been to reach Mallnitz, we had already gained some bonus distance. In total, we traveled 69 km this day, but the real challenge was definitely the elevation gain.

69 km covered with a personal best of 959 m elevation gain.

Day 3 - Untergratschach via Spittal an der Drau to Villach#

Having successfully managed the most challenging part of the tour, we began the third day with renewed enthusiasm.

The Ciclovia Alpe Adria route was excellently marked along the way, meaning we rarely needed to consult our phones for navigation. We stopped for coffee and pastries in Spittal an der Drau - which had actually been our planned destination for the day. But since we were making such good progress, we decided to continue on to Villach.

The landscape, while not quite as spectacular as the previous day, was still pleasant. The cycling infrastructure was excellent, allowing us to ride side by side for much of the way, providing ample opportunity for conversation.

75 km covered with good company and conversation.

Day 4 - Villach to Gemona del Friuli#

Our target for the day was Tarvisio, but we arrived there before lunch and decided to continue our journey. This day marked our second border crossing: into Italy.

The cycling route was the highlight of the day. Starting from Tarvisio, we enjoyed a gentle descent along a repurposed railway line, passing through numerous tunnels carved into the mountains. This section was particularly enjoyable, and thanks to the slight downhill gradient, our average speed was impressively high despite covering the longest distance of our trip so far.

The turquoise waters of the Tagliamento River accompanied us for much of the way, adding to the scenic beauty of the route.

We eventually arrived in Gemona del Friuli and decided to stop there for the night. The day had grown increasingly warm, and the next significant town was too distant to reach comfortably.

A personal best of 105 km - our longest day of cycling.

Day 5 - Gemona del Friuli to Udine#

The previous evening, we had begun planning the final days of our journey. Since we were already quite close to Grado and had been moving faster than anticipated, we decided to spend two nights in Udine.

This section of the route was perhaps the least enjoyable part of the entire trip. Route markers were often difficult to spot, causing us to miss turns frequently. We also had to share public roads with vehicles more often, requiring constant vigilance.

Fortunately, this was also our shortest day of cycling on the Ciclovia Alpe Adria.

In Udine, we explored the city and, similar to our night in Bischofshofen, attempted to get an early night's sleep. Not all aspects of our journey went according to plan, however!

55 km of somewhat challenging navigation.

Day 6 - Udine#

Having established a routine of hearty breakfasts followed by long days of cycling, this rest day in Udine felt almost strange. We had explored much of the city the previous day and found ourselves with time to spare. We simply walked around the charming city and, for once, actually managed an early night.

Day 7 - Udine via Palmanova to Grado#

After nearly missing our daily cycling routine, we eagerly embarked on the final leg of our journey. This was the grand finale: from Udine via Palmanova to our ultimate destination, Grado.

The day was warm and windy, and we were glad to leave the busy streets of Udine behind - not because we disliked the city, but because sharing roads with cars in urban areas can be stressful.

En route to Grado, we passed an impressive-looking town and decided to explore its center. We were delighted by our detour into Palmanova, a unique star-shaped city built in concentric circles. It offered numerous charming restaurants and bars. Had we known about it beforehand, we would have planned an overnight stay there too. Perhaps next time!

The final approach to Grado was both hot and magnificent. The Matteotti Bridge stretches for about five kilometers directly above the sea, offering breathtaking views.

Entering Grado felt triumphant. We immediately headed for the beach, which felt like the perfect finish line for our journey. After checking into our hotel, we took a moment to appreciate what we had accomplished.

58 km for the day, bringing our total to 433 km in 6 days of active cycling.

Day 8 - Grado#

Believe it or not, we decided to go for another bike ride! Just a short one this time, but if anyone had suggested this before our trip began, I would have laughed in disbelief.

35 km of leisure cycling, bringing our final total to 468 km in 7 days.

Day 9 - Homeward Bound#

One advantage of popular cycling routes like the Ciclovia Alpe Adria is the availability of transportation options for the return journey. Several services offer to bring cyclists and their bikes all the way home with vans and trailers, which we gratefully utilized.

Final Thoughts#

To summarize our journey: We cycled from home to Golling, then took the train to Bischofshofen on day one. From Bischofshofen, we continued all the way to Untergratschach on day two. Day three took us to Villach. Our fourth day marked the crossing into Italy, arriving in Gemona del Friuli. From there we reached Udine on day five and spent all of day six exploring the city. Day seven brought us to our final destination, Grado. On day eight, we explored the Grado area by bike before heading home on day nine.

This ranks among the best holidays I've ever experienced. Cycling offers the perfect pace to appreciate your surroundings while still covering meaningful distances each day.

Completing this journey in 2021, after the strict Covid lockdowns, gave us valuable time to reconnect - not just for important life updates, but for those casual, sometimes silly conversations that make friendships special. With hours of cycling each day, we had ample time to chat about everything and nothing.

The structure of having a daily plan and routine was satisfying without ever feeling restrictive. And perhaps most importantly, the sense of accomplishment in completing such a journey remains one of my proudest moments and most treasured memories.

I've always liked riding bikes. For years, it was just a way to get around—nothing special, just a practical way to get from A to B. That changed in 2018, when a friend moved away and left me his mountain bike. Suddenly, I found myself looking up bike parts, learning about maintenance, and planning longer rides just for fun. What started as a simple hand-me-down turned into a hobby that stuck with me.

At first, the world of mountain bikes felt a bit overwhelming. There's a lot of information out there and everyone seems to have strong opinions about what makes a “proper” bike. I took it slow, talked to friends, and did my own research. Over time, I figured out what worked for me and what didn't.

Mountain Bikes#

So far, I have owned three bikes. The first one was a gift, while I bought the second and third myself.

Bergamont Revox 6.0#

The Bergamont Revox 6.0 was my first real mountain bike. It was a bit too small, but it had features I'd never had on a bike before—disc brakes and a lockout on the shocks. The 3x10 drivetrain was pretty standard for the bikes I was used to. The bike was a good first impression of the current state of mountain bikes. Since the frame was too small for me, I continued the legacy and gifted it to a friend—time to buy a bicycle with my own money for the first time.

Bulls Copperhead 3#

After a year, I upgraded to a Bulls Copperhead 3. A friend helped me pick this one at a local shop and this one fit much better, since the frame size was finally right. I started tracking my rides and exploring more of the area I live in. I even talked a few friends into joining me for a two-day tour—90 km one day, 100 km the next. It was the first time I realized how much you can see from a bike and how it's the perfect pace for travel: fast enough to cover ground, slow enough to actually notice things.

Owning this bike also got me more interested in the world of mountain bikes. I started following new developments, reading up on gear, and watching videos about the latest tech. That's when I first came across the 1x12 drivetrain and began to figure out what features I wanted in my next bike.

Looking back, it was a great choice to get started. The Magura MT4 brakes were amazing, and the Shimano Deore XT derailleur shifted very crisply.

Canyon Grand Canyon 8#

In 2021, I bought a Canyon Grand Canyon 8. This was the first bike I picked out myself, after a lot of research and knowing what I wanted. A friend of mine had already bought a Canyon bike and was satisfied with the entire "buying a bike online" process. This bike offers a few things the Bulls Copperhead 3 didn't: It has the 1x12 Shimano Deore XT RD-M8100 drivetrain and a dropper seat post. It also has a lockable Fox 34 Rhythm shock. The brakes are Shimano RT10 discs (180 mm front, 160 mm rear) with MT400 calipers. If any part of the bike felt like a downgrade, it was definitely the brakes. The Magura MT4s simply felt much better. The gear shifting is very smooth and crisp. Compared to the 3x10 drivetrain of the previous bike, it feels like a big step up. Being able to adjust the seat height at the press of a button is something I really enjoy. This allows quick adjustments to the seating position, which is very helpful for longer rides. Especially if you ride in more technical terrain, it is good to get the seat out of the way. This is also the first bike where I cared about the design—it looks very sleek and good-looking. It has made riding even more fun and I've started looking for new trails and longer routes. This is also the bike I used for my longest bikepacking tour so far: the Ciclovia Alpe Adria. I'll write about that trip in a future post.

This bike has been a great buy so far. I still enjoy riding it, and there really isn't a feature missing. Of course, there are always new parts I'd like to upgrade, but all the components on this bike fit my needs perfectly.

Maintenance#

The more I rode, the more I realized it made sense to learn some basic maintenance. You don't need much space or fancy tools—just a simple toolkit and a repair stand are enough for most things. Adjusting gears, swapping brake pads, and cleaning the drivetrain turned out to be pretty straightforward. YouTube and a good book were all I needed to get started. Keeping the bike in good shape makes every ride better and it's also satisfying to fix things yourself. Learning these basics also meant I could help family and friends with their bikes.

Final Thoughts#

Mountain biking is still just a hobby for me, but one that I keep coming back to. I like the mix of being outside, getting some exercise, and tinkering with the bike. One big advantage is that you can ride alone or with friends. Riding by myself helps me to completely disconnect from the world, whereas riding with friends gives you a lot of time to talk. If you're thinking about mountain biking, just give it a go and don't worry too much about the details. Most things become clearer once you start riding regularly—at least, that's what worked for me.

Diving into the self-hosted world can be both exciting and overwhelming. With countless services to choose from and various ways to deploy them, it's easy to get lost in the possibilities. In this post, I'll walk you through my journey of integrating services on my Synology DS 720+ and share insights I've gained along the way.

Finding Services#

The initial challenge with any new tech hobby is figuring out where to start. Which services are worth your time? What problems can they actually solve for you?

I was fortunate to have specific goals in mind: setting up an MQTT broker and deploying Paperless-ngx. Having already tested Paperless locally, I was confident it would benefit from running 24/7 on my Synology NAS. The MQTT broker was familiar territory, making it an ideal first project.

For discovering additional services, I relied on Reddit, the excellent awesome-selfhosted GitHub repository, and fellow tech bloggers. My criteria were simple: does it solve a real problem, replace a proprietary service with something I control, or offer an interesting learning experience?

Here are the core services that have earned permanent spots in my self-hosted ecosystem:

• Dawarich: German for "I've been there" – this privacy-focused alternative to Google Maps Timeline tracks your location history on your own server. It even offers integration with Immich for displaying trip photos.

• Immich: While Synology Photos served me well as a Google Photos replacement, it has limitations. Immich offers compelling features that have me seriously considering a full migration (though I'm still in the evaluation phase).

• Dashy: With a growing collection of services and smart home devices, managing all those IP addresses became unwieldy. Dashy creates a sleek dashboard that not only organizes everything visually but also monitors service status at a glance.

• Paperless-ngx: I've detailed this brilliant document management system in a dedicated post. In short, it helps you transforms physical document chaos into digital organization.

• Home Assistant: Perhaps the crown jewel of self-hosting, Home Assistant unifies smart home devices while keeping data local. I've created custom automations like automatically powering down my desk equipment when power draw drops below a threshold for a specified period, or turning off the TV when nobody's home.

• FreshRSS: I enjoy reading personal blogs. FreshRSS elegantly solves the aggregation problem, bringing my favorite blogs together in one place and making them available on my phone for convenient reading.

Getting Started#

My initial approach to installing services was somewhat clunky – SSHing into the NAS and managing Docker containers via terminal commands. The breakthrough came when I set up VS Code's remote development over SSH, giving me a seamless development experience.

My current workflow is straightforward:

1. First, I scout for documentation and ideally a ready-made docker-compose.yml file at the projects page I want to get up and running.
2. After enabling SSH access in the Synology interface, I connect via VS Code.
3. I create a dedicated folder for each service containing the compose file and often a README documenting my setup decisions and useful references. This folder is under git versioning so I can always track changes I make.
4. Carefully mapping volumes in the compose file ensures data persistence. I maintain a standard structure with each service having its own subfolder within my main docker directory.
5. After launching the service, I follow any first-time setup procedures from the project documentation.
6. For services I want accessible outside my home network, I configure Synology's reverse proxy and assign a proper domain name.

Final Thoughts#

Self-hosting has been a rewarding journey that strikes a nice balance – deep enough to be interesting without becoming overwhelming. The services run reliably, maintenance overhead is manageable, and I've discovered fascinating open-source projects along the way.

The community around self-hosting is vibrant and supportive, offering endless possibilities for exploration without demanding constant attention.

My Synology has proven to be an excellent platform due to its energy efficiency and always-on availability. The main limitations are Synology's DiskStation Manager (DSM) ecosystem constraints and the relatively modest computing power. As AI applications become more accessible, I occasionally wish for more processing muscle to run things like Paperless plugins locally, preserving privacy while gaining powerful features.

Sharpening the tools you use daily is essential. As a programmer, this means staying up-to-date with the latest recommendations and understanding how new features in programming languages solve real-world problems. For me, conferences and training sessions have always been a great way to achieve this.

In 2022, I had the opportunity to attend the CppCon in Aurora, Colorado. Given the long travel distance, I decided to extend my trip by a week to explore the state. Here's a glimpse into my experience.

CppCon 2022#

CppCon, organized by the Standard C++ Foundation, is a premier conference for C++ enthusiasts. It features talks on upcoming features, best practices, beginner-friendly tutorials, and even general software engineering topics. Beyond the technical content, it’s a fantastic social gathering and a chance to meet like-minded people.

I attended the conference with two colleagues, and none of us had been to Colorado before. Since Aurora doesn’t offer much in terms of attractions compared to Denver, we opted to stay in downtown Denver and commute daily to the conference venue.

The conference spanned five days, where I attended five talks each day. While the content was enriching, it was also overwhelming — especially when paired with jet lag. By the end of each day, I was both inspired and exhausted.

The Good#

CppCon had many highlights. The talks were well-organized, and the spacing between sessions allowed for networking and relaxation. Coffee, snacks, and drinks were plentiful, keeping everyone energized.

It was inspiring to see the "big names" in the C++ community deliver talks in person. The atmosphere was welcoming, and attendees were eager to connect and share ideas. Some companies even had exhibits, offering insights into their workflows and tools.

The Bad#

Not all talks lived up to expectations. A few felt more like product advertisements than technical discussions, which was disappointing.

The location of the conference was another downside. While staying at the conference hotel might have been convenient, the area lacked activities and dining options. The hotel restaurants were expensive. Staying in downtown Denver turned out to be a great decision, as it offered more affordable accommodations and plenty of evening activities.

Exploring Colorado#

As someone from Austria, I was curious to see how Colorado compared. Both regions are known for their mountains and skiing, so I expected some similarities. After the conference, I had nine days to explore the state with one of my colleagues, and we planned an itinerary packed with adventure.

Denver#

We started exploring Denver right away. Despite the long conference days and jet lag, we managed to enjoy dinners and evening walks around the city. Highlights included the Colorado State Capitol, Union Station, and Coors Field.

As an NFL fan, attending a live game was an awesome experience. Watching the Denver Broncos play the Houston Texans was unforgettable. Overall, Denver offered a great mix of sightseeing and relaxation.

Manitou Springs#

With a rental car, we headed to Manitou Springs. On the way, we visited the National Museum of World War II Aviation. The museum was a gem, with passionate staff and fascinating exhibits. We even saw a vintage flight simulator in action.

Driving up Pikes Peak was another highlight. The thin air at the summit was noticeable, but the breathtaking views made it worthwhile. We also visited the Garden of the Gods and explored a charming penny arcade.

Rocky Mountain National Park#

Our journey continued to the Rocky Mountain National Park, with a stop at the Red Rocks Amphitheatre. Having seen concerts online from this iconic venue, it was amazing to experience it in person. I hope to attend a live performance there someday.

Driving through the Rockies from Grand Lake to Estes Park was a mix of awe and reflection. The aftermath of a forest fire was evident, but it was fascinating to see how the landscape was regenerating.

On our way back to Denver, we stopped in Georgetown and rode the historic Georgetown Loop Railroad. We wrapped up the day with classic BBQ before flying home the next day.

Final Thoughts#

CppCon was a unique experience. While the talks and networking opportunities were fantastic, some aspects fell short of my high expectations — particularly the prevalence of advertising talks. Nevertheless, I’m glad we stayed in downtown Denver, as it added a lot to the overall experience.

Exploring Colorado was equally rewarding. From Denver’s vibrant city life to the natural beauty of Manitou Springs and the Rockies, the trip showcased the diversity of the U.S. It also reminded me of the challenges of balancing photography with group travel — a lesson I’ll carry forward.

All in all, this trip was a perfect blend of professional growth and personal adventure.

In 2019, I wrote a Python tool to extract text from images. To enhance the extraction, the tool attempted to rotate the image to align as much text horizontally as possible. The motivation behind this tool was the high price of decent duplex document scanners and my desire to avoid organizing hard copy documentation manually. A major challenge with organization is handling documents that belong to multiple categories.

My solution was to stamp each document with a numbering stamp and store all documents in the same folder. Whenever I needed something, I would search for it digitally and quickly find the document's number.

Then, I began self-hosting and stumbled across Paperless-ngx.

Paperless-ngx#

Paperless is an open-source document management system. It performs text recognition and enables you to search for documents based on their content. Additionally, you can assign titles, tags, and even an archive serial number (ASN) to documents, making it perfect for my needs.

One important aspect of self-hosting Paperless-ngx is that the uploaded data remains on my server. The data is stored in both its original and enhanced versions, which is crucial in case another tool becomes available or this one becomes obsolete.

For a full list of features, check out the official website.

Workflow#

A typical workflow involves scanning a document, uploading it to the consume folder of Paperless, waiting for it to process, and then using the web UI for document classification. The title, ASN, tags, correspondent, etc., can be set there. Depending on the configuration, new documents receive a default tag indicating that they are still in the inbox and need to be handled. Once everything for a document is set, this tag can be removed.

Plugins#

To improve the workflow of Paperless, several interesting plugins are available. With the rise of AI, I came across two tools that utilize AI for Paperless. A key requirement for such plugins is the ability to run the LLM locally, as Paperless-ngx hosts sensitive data that I do not want to expose.

For a detailed comparison of these tools, check out this Reddit thread, where the creator of Paperless-GPT compares it to Paperless-AI. The creator of Paperless-AI also comments in the thread.

Paperless GPT#

Paperless GPT aims to improve OCR results using LLMs. Simple OCR mistakes like New Yark can be corrected to New York by the LLM. With this improved text, the plugin can automatically set the title and tags for the document. Another useful feature is the ability to trigger processing for new documents automatically with one tag or manually with another. In manual mode, you must approve the suggested changes.

Paperless-AI#

This plugin also analyzes documents and uses LLMs to automatically assign tags. Its standout feature is the ability to chat with your documents, which can be handy for quickly gathering information, such as details about your car. Like Paperless GPT, it supports both manual and automatic modes.

QuickScan#

Since I do not own a scanner and document scanners are expensive, I explored alternatives and discovered QuickScan. I decided to try it and was impressed. It allows you to export documents via WebDAV directly to the server and offers many customization options. One of its most convenient features is the export favorites, which let you define regular tasks, such as uploading documents to Paperless. Since Paperless also stores documents for my kids, I have specific export favorites for them, which automatically store their documents in a different path within the Paperless system. Another aspect I liked is that the app is not subscription-based. I do not mind paying for software, but I prefer a one-time purchase over increasing my monthly expenses. QuickScan is free to use but accepts donations. Donors receive rewards like changing the app's color, but all core functionality is available to everyone.

Final Thoughts#

I am glad I found a successor to my self-written Python app. The web UI is excellent, and as a popular self-hosted service, there is plenty of help available online. The workflow I have developed is efficient and makes the scanning process very convenient. Here are my typical steps:

1. Gather a batch of documents to scan.
2. Stamp the first document with a numbering stamp.
3. Scan the first document and send it to the consume folder using QuickScan.
4. Add the document to a binder if it needs to be kept as a physical copy. Otherwise, discard it.
5. Repeat these steps until all documents are in Paperless-ngx.
6. Use the Paperless-ngx web UI to configure the documents by adding titles, ASNs, etc.

When I discovered the plugins, I was excited to use them to further improve the digitization process. However, since I do not have a powerful computer and my initial local testing did not meet my expectations, I decided to wait. There is a lot of ongoing development in AI tools, and better models are becoming increasingly available.

In 2014, I bought my first network attached storage (NAS): the Synology DS 213j. Back then, I used it for storage-related tasks only, such as photo backup and media server. In 2020, I then bought the Synology DS 720+. At that time, I started experimenting with Docker and thought it would be great to have my own server that I could use for more than just storage-related tasks. This was the start of my self-hosted journey.

Synology DS 720+#

The 720+ is a two-bay NAS with a quad-core processor and 2GB of RAM, which can be upgraded. It offers low power consumption, which was important for me to avoid fearing the electrical bill and to never feel the need to switch off the server. Having gathered experience with the DS 213j, I chose to stick with Synology. The applications they offer out of the box are easy to set up and keep running. Additionally, it is possible to run Docker containers on it, making it a versatile server.

Self-hosted Services#

The first self-hosted service was the weather station I created along with an MQTT broker. The current services I host vary a lot. Whenever I stumble across a new project that can be self-hosted and looks interesting to me, I tend to give it a try. Depending on my liking, they will remain around or be stopped and deleted. Self-hosted services that have been around for a long time are Home Assistant, Paperless-ngx, and FreshRSS.

Why Self-hosted?#

When you host services yourself, you are in control of your data. This makes migrating to a different service (e.g., switching your note-taking app) easier. It's important to check how the data is stored; for note-taking, I prefer plain text, mostly Markdown.

A trigger for me to think more about my data was during the Covid pandemic when I was cycling a lot. A fitness watch tracked my data, and the provider visualized it well. However, retrieving the data from the provider's server after selling the watch was difficult. Fortunately, several people on GitHub shared scripts to retrieve the data, often with the caveat, ".. works until version X.Y.Z". This was a wake-up call to take better care of my data.

This doesn't mean I avoid all services, but I consider the accessibility of stored data more carefully. One question I often ponder: Why would a company offer free online storage, mail hosting, and a calendar? It's not truly free.

However, using online services can be convenient and perfectly fine. It's crucial to understand why something is provided to you and whether you can retrieve your data without issues later. You might be content with your current storage method, but that could change.

The Future#

My own server started greatly with the Synology ecosystem. But lately, I also felt that the server could use some more computing power — especially if you want to use some LLMs. I am far from any choice, but the topic "Home Lab" is discussed a lot online, and there are plenty of YouTube channels giving great introductions to this rabbit hole. One thing to consider when moving away from Synology: Any service updates have to be done by me, and if something breaks, I also have to fix it.

Final Thoughts#

Through my NAS, I had a great introduction to home servers and self-hosted services. It is a great starting point to consider your private data more thoroughly. With the rise of AI, it would also be great to have more computing power available. Use cases can be an automatic tag creation for documents added to Paperless-ngx. Since these documents can contain sensitive data, I would not want to use an online provided service.

It might be obvious from some of my projects, but I love coffee. In 2018, I started with a cheap espresso maker. It broke rather quickly, but in doing so, it sparked my deep interest in coffee.

Getting Started with Espresso#

There are countless guides on what makes a good espresso. Factors like grind coarseness, coffee dosage, bean selection, and grinder quality all play a role (always grind fresh!). Then, there are standard guidelines:

• Espresso should take around 25 seconds from the first drop to the last.
• The typical ratio is around 1:2.5—meaning if you use 15g of coffee beans, you aim for 37.5g of espresso in your cup.

But the most important rule? These are just starting points. The real goal is always taste — the most important part is that the espresso tastes the way you want it and that you enjoy the process of making it.

Why an Espresso Maker?#

One question I hear a lot from guests is: “Why an espresso maker? Doesn’t the whole process feel tedious?”

Well, yes and no.

A fully automated machine simplifies life, but that also means you end up drinking more coffee just because it’s so convenient. There’s also the cleaning aspect — manual espresso machines with portafilters allow for thorough cleaning, whereas most automatic machines provide little access to their internal brewing components.

And then, of course, there’s the taste. I’ve yet to find an automatic espresso machine that matches the flavor of a well-dialed-in manual espresso shot. Why shouldn’t your home-brewed espresso taste just as good as the one from your favorite coffee shop?

Quickmill Cassiopea#

After my first espresso maker broke, I bought the Quickmill Cassiopea. This machine features dedicated thermoblocks for both coffee extraction and hot water/steam, allowing simultaneous espresso pulling and milk frothing.

The good part about the coffee machine was the quick heat-up time thanks to the thermoblocks. The bad parts were the weak steam power and that the group head is Quickmill-specific, limiting the accessories available for it.

E61 Group Head#

After a few years, I wanted to try an E61 group head. I sold my Quickmill at a small loss and started looking for a new machine. After some research, it came down to two machines.

Lelit Mara X vs. Bezzera Magica S#

Both machines use the E61 group head, meaning a wide variety of accessories are available. Apart from aesthetics, the key difference was that the Mara X offers temperature control settings and different brewing modes:

• Steam Priority Mode – Functions like a traditional E61 machine.
• Coffee Priority Mode – A Lelit-specific setting that optimizes for espresso extraction.

In the end, the Mara X simply made better-tasting espresso in my testing, so I went with it. Since September 2020, I’ve been very happy with my choice.

The Big Drawback: Heat-Up Time#

A common downside of E61 machines is their long heat-up time. Lelit states 24 minutes, but real-world measurements show that stability is achieved after 30 minutes. And temperature stability is critical for consistent shots.

My solution? A WiFi smart plug that preheats the machine automatically. While this helps, it doesn’t allow for spontaneous espresso-making. Plus, E61 machines consume a lot of energy compared to thermoblock machines since they heat an entire boiler just to extract a few milliliters of espresso.

Final Thoughts#

Like many hobbies, espresso making can become a deep rabbit hole. There’s an overwhelming amount of information online, sometimes to the point, where you optimize settings, despite liking the taste already.

Would I buy my setup again? Probably not.

Since purchasing the Mara X, new machines have emerged. While I appreciate the E61 experience, I dislike the long heat-up times and high energy consumption. Yes, the smart plug is a decent workaround, but spontaneous espresso isn’t really an option.

Back in 2020, I automated my coffee grinder. Before that, I had to weigh the ground coffee by hand.

More expensive coffee grinders offer time-based grinding and some even offer weight-based grinding. Since mine didn't, I decided to take matters into my own hands and created a project to help me with it.

I revisited this project in 2025 and was not happy with the code.

The Problem#

The logic for starting, stopping, and managing the grinding process was scattered across multiple functions, making it difficult to understand and maintain.

Looking at the main loop() of the Arduino-based software showed this:

void loop() {
  // ...
  if (automaticGrindingOngoing) {
    auto currentWeight = getCurrentWeightAndPublish();
    if ((currentWeight + thresholdTargetGrams) < desiredGrams) {
      // Start or continue the grinding
    } else {
      // The current weight with a given threshold has reached the target weight ..
      if (currentWeight < desiredGrams) {
        // .. now approach the desired weight slowly.
        // (the grinder retention and the distance between the grinder and the scale forced this approach)
        startGrinding("automaticGrinding", 150);
      } else {
        // .. or the desiredGrams have been reached.
      }
    }

  } else if (grindingOngoing &&
       (millis() - grindingStartedTime) > grindingTime) {
    // Time-based grinding was ongoing and we have reached the desired grinding time -> Stop the grinder.
  } else {
    // We are not grinding, so handle anything else (such as updates over the air).
  }
}

Code parts were replaced by comments to ease the reading. Here is a link to the full code section.

When MQTT messages are received to start grinding, the bool flags automaticGrindingOngoing or grindingOngoing are set.

Looking at the callback, I was surprised that there wasn't a startAutomaticGrinding function called or that the startGrinding function starts the grinding but doesn't care about stopping it. The stopping logic was handled separately in the loop(), leading to a fragmented and hard-to-follow codebase.

Improving the Code#

The first idea was to extract the entire grinder and MQTT handling logic to their own libraries.

This left the program.cpp with less code only handling the update over the air and the connection to the Wi-Fi.

GrindingController#

A lot of the logic was now moved to the GrindingController. It now takes care of the MQTT callback with dedicated functions for each MQTT command:

• automaticGrinding(..) -> Handles weight-based grinding
• timeBasedGrinding(..) -> Handles time-based grinding

The automaticGrinding function takes care of everything needed for weight-based grinding. It tares the scale, grinds beans until the target weight minus a threshold is reached, and then slowly approaches the target weight. Additionally, it also handles all the MQTT updates.

The timeBasedGrinding function sends out updates via MQTT, starts, and stops the grinder based on the desired time.

The GrindingController::loop() is called by the program::loop(). Its main task is checking for MQTT updates and publishing the current weight on the scale regularly.

MqttGrinder#

The MqttGrinder is more or less a wrapper of the PubSubClient, a library used for MQTT communication. It takes care of any grinder-specific MQTT communication, such as publishing new values, subscribing to MQTT topics relevant to the grinder, and setting up the callback which is called when one of the subscribed topics is received.

Blocking vs. Non-Blocking#

The old implementation within the program::loop() was (almost) non-blocking, which actually is a good practice. A few delays were part of it, but in theory, the program::loop() would be pretty much executed periodically.

The new implementation is blocking since the new grinding functions remain in a while-loop until the targets are reached - theoretically, they can also never be reached.

But since the grinder controller always has exactly one task to do (either time-based or automatic grinding) and a firmware update should only occur when the grinder is not grinding, this solution felt right. Additionally, the two main functions of the GrindingController (automaticGrinding and timeBasedGrinding) now are responsible for their own actions all the time, making the code easier to understand.

And despite the two functions being blocking, the MqttGrinder will still handle the MQTT messages regularly since the current weight is published periodically. This is probably the part that should be refactored next, as there is a lot of hidden logic there. That GrindingController::getCurrentWeightAndPublish() publishes the weight after a defined time has passed (scaleUpdateTime) and therefore triggers an MQTT update is pretty hidden.

Final Thoughts#

It was fun to refactor this old project. Often my ESP-based projects start off as a quick proof of concept through which the code quality often suffers.

Additionally, I no longer own that grinder and therefore no longer use this project. My current grinder is a so-called "single dose coffee grinder" - you weigh the beans before pouring them into the grinder and the output of the grinder is exactly the same weight.

But still having the load cell available enabled me to "experience" my own documentation for the setup - where the schematic allowed me to quickly have something up and running. For testing, I chose to skip the relay and instead use the built-in LED of the D1 mini to indicate the current state of the grinder.

There are still several code parts that would benefit from a refactoring:

• The new callback function is rather long for being a mapping of topic to function.
• A lot of logic is still hidden. That removing GrindingController::getCurrentWeightAndPublish() results in no MQTT messages being updated is not something I would expect.

Additionally, further functions could be added:

• Fallback to ensure that the relay is switched off if anything bad happens (firmware crashes, etc.).
• Hardware buttons to control the grinder: MQTT enables many ways to control the grinder. But in real life, one would always control the grinder while standing there. It would be great to adjust settings and start the grinding without the need for any MQTT-compatible device.

If any of those code updates will come is unclear since I am no longer a user of the project. But I also did not expect to refactor this project and yet here we are.

For a detailed view of the changes, you can check out the GitHub pull request.

Stockholm, Kiruna and Oslo#

As I embarked on this journey through Scandinavia, my passion for photography grew alongside my excitement to capture the breathtaking beauty of these cities and landscapes. From the Northern Lights in Kiruna to the stunning architecture of Stockholm and Oslo, each destination offered a unique experience that pushed my skills to new heights.

Stockholm#

Our journey began in Stockholm, a great city to get started with photography. The city's rich culture, delicious food, and shorter winter days made it an ideal spot to test my camera. We spent three nights exploring the city's many museums, including the Vasa Museum on the island of Djurgården.

Vasa Museum#

The Vasa Museum is home to a Swedish warship that sank on its maiden voyage in the 17th century. The ship was discovered in the 1950s and has undergone extensive preservation efforts. I had previously visited this museum several times, but it never failed to amaze me. Having bought the Canon EOS M50 Mark II and the Sigma EF-M 16mm f/1.4 prior to this trip, I had to bring it to the museum. That allowed me to further figure out photography in dark conditions.

Julbord#

Despite growing up in Austria, my family always celebrated Christmas in a Swedish fashion - so with a traditional Swedish Christmas feast, known as Julbord. During December, several restaurants offer a Julbord. So additionally to Christmas, I got to enjoy this buffet an additional time that year.

Walking#

The best way to explore a city is typically by walking. This allowed us to take photos whenever we stumbled across nice places. My friend taught me a few tricks on photography. For example in the following photo if you look to the left of the light pole, you can see a large tower far away in the background. This tower drew attention to it, which was not the intention for this photo. So by strategically placing the light pole in front of it, the photo became visually more appealing.

In addition to exploring the city, we also tried some delicious Swedish street food, like Tunnbrödsrulle, a flatbread wrapped around a sausage, mashed potatoes, and other tasty fillings.

Here are a few impressions of Stockholm and some of my first photos with my camera.

Kiruna#

After three days in Stockholm, we flew to Kiruna. I definitely recommend a seat at the window, as the landscape is spectacular. We had a rental car in Kiruna, which introduced a first time: Driving a car with spikes. Similar to Stockholm, we immediately started walking around the city, grabbed a Souvas Rulle (similar to the Tunnbrödsrulle, but with reindeer meat instead of the sausage) and spent some time in the apartment waiting for the Northern Lights.

As I wrote in the last post, we checked out the local church, walked around the town in the dark and drove to a less light polluted area to raise the chances of seeing the Northern Lights - which we kind of did, but only through the lens of the camera.

We also took part in an Aurora expedition with dinner - a snowmobile, Northern Lights and dinner tour. Sadly we did not see the Northern Lights that day, but the landscape and food were great. Another day, we drove to the Esrange Space Center. It was a long car drive, but it was worth it. We stopped on several occasions for photography and even saw a Moose and a Reindeer in the wild. The space station visitor center was interesting, but the best part about going there was definitely the landscape and the almost untouched nature.

After that, we went on to our next hotel, which was situated at the Torne river. There we were able to see the Northern Lights with our eyes.

Oslo#

To finish our Scandinavian trip - sorry Finland - we went to Oslo in Norway. We walked through the city, took several photos at the Oslo Opera House and the pier. We saw the Royal Palace and took it rather slow and easy that day, after having spent much time sightseeing and taking photos.

Final Thoughts#

The entire trip was a great experience. The Northern Lights were definitely the highlight of this journey. Kiruna is an awesome city and I definitely want to go there again. I have been to Stockholm often, so it is kind of "known" but as always a great experience. And Oslo has been awesom. It was nice to see the city for a second time, but due to the Corona pandemic rising again, many activities were not possible and we were also already exhausted from the past days walking and taking pictures.

Introduction#

Having Swedish roots, a friend of mine asked me in 2021, if I wanted to join him on a trip to Sweden to capture the Northern Lights.

Camera Setup#

Up until then, I had primarily taken photos with my phone. In 2015, I started creating yearly photo albums after realizing that I rarely revisited my pictures. This practice motivated me to take more photos, knowing they would be part of my next album. As a result, I had already been considering purchasing an entry-level mirrorless camera. The chance to photograph the Northern Lights became the final push I needed. I bought an used Canon EOS M50 Mark II, which came with a Canon EF-M 15-45mm f/3.5-6.3 IS STM lens.

Lenses and a Tripod#

My friend, an experienced photographer, quickly introduced me to essential photography techniques and settings. He recommended purchasing an additional lens for capturing the Aurora Borealis: the SIGMA EF-M 16mm f/1.4. Its wide aperture would allow more light to enter, making it ideal for low-light photography.

Another lens he suggested was the budget friendly Canon EF 50mm f/1.8, perfect for portrait photography. Since my M50 has an EF-M mount, I needed an adapter to use this lens. The adapter applies a 1.6x crop factor, effectively converting the 50mm lens into an 80mm equivalent. This exposed one of the first drawbacks of my camera: the limited availability and high cost of compatible lenses.

Another crucial investment was a sturdy tripod. I chose the Rollei Compact Traveller No. 1, ensuring stability for long-exposure shots.

Kiruna#

With my camera gear ready, I began testing my lenses and exploring the camera’s settings. Initially, it was overwhelming, but much of my learning came from hands-on experimentation during the trip.

December in Kiruna is incredibly cold, so we often found ourselves indoors, waiting for the Northern Lights or preparing food. During these breaks, we experimented with different camera settings, even attempting to take photos through the windows. One amusing moment occurred when I excitedly captured a green light on my camera, only to realize upon closer inspection that it was the reflection of the microwave clock. The long exposure time had allowed the camera to pick up details that were invisible to the naked eye.

We ventured into the city and its surroundings. After capturing several shots of the local church, we drove to a remote area with minimal light pollution. At first, we saw what appeared to be an unusual cloud, but upon pointing the camera at it, we discovered that it was actually the Aurora Borealis. While it wasn’t yet visible to the naked eye, seeing it through the camera was thrilling.

Our next hotel was situated near the river Torne surrounded by a forest — an ideal location for photography but also a gamble, as the northern lights are not guaranteed and there was not much else to do there. Fortunately, luck was on our side. This time, we could see the lights with our bare eyes — not as vividly as through the camera, but still an unforgettable sight.

Here a photo for comparison taken with my phone:

Final Thoughts#

All in all, the trip to Sweden was an incredible experience. I captured my first stunning photos with a proper camera and compared them to those taken with my phone. However, I also encountered another challenge: post-processing. Editing the images required time and effort — yet another skill to master.

Despite this, the journey reinforced my passion for photography, and I left Sweden with unforgettable memories and a deeper appreciation for the art of capturing light.

My espresso machine is a Lelit Mara-X. Among several adaptations to the classic E-61 brewing unit, the Mara-X features a serial input and output interface. This interface provides information such as the current software version, target boiler temperature, current boiler temperature, current heat exchanger temperature, and the heating status (on or off).

I have come across several projects that visualize this data in various ways.

To ensure that the aesthetics of the coffee machine remain largely unaffected by modern displays, I decided to use an e-paper display. This display visualizes the data relevant to me and also draws a heat-up graph.

I enjoy a good cup of coffee. To achieve that at home, I bought a coffee grinder along with a nice espresso machine. Several factors are important for a great-tasting coffee: coarseness, dosage, quality of the beans, extraction time, and more. To find the best-tasting coffee, it is crucial to minimize the changing factors, one of which is the amount of beans. Previously, I had to stand by the coffee grinder with a scale and manually measure the amount of ground beans. After working from home for a while, I got annoyed with this process, so I decided to automate the grinding of the beans.

Having gained some experience in the ESP8266 world, I decided to use a D1-mini for the task. After some research, I chose to use a load cell along with the load cell amplifier HX711. The grinder itself is switched on and off by a relay controlled by the D1-mini.

A node-red flow along with the node-red-dashboard is used to control the D1-mini. The commands are sent through mqtt topics.

On the dashboard, there are several functions: weight-based and time-based grinding, a brew timer, and the taring of the scale. The main challenge with this project was that it takes some time for the ground coffee to reach the scale while grinding. Therefore, stopping the grinder when the weight is reached might already be too late. It was necessary to stop the grinding process a bit earlier and then grind some more until the target weight is reached.

I enjoy the transition to a paperless world, as I find it much easier to organize documents digitally. However, since many documents are still required as hard copies, one is forced to archive them. A tough question then is: How many and which categories of organizers will one need for all documents?

For me, I decided that I do not want any categories and each organizer should be used until it is full.

To be able to find documents, I wrote a Python program that extracts text from scanned documents and stores it in a computer-processable way.

Additionally, each document is stamped with a numbering stamp (which automatically increases its number with each stamping) and the computer-processable data is stored in folders named by the number of the document. So whenever I am looking for a certain document, I type in keywords from the document and the computer provides me with the number of the document and a preview of it. Then I can grab the organizer, which has the number range written on it, and take the document from it.

Looking for a project to work on in my spare time that touches on several technologies, I came across the ESP8266 and had the idea to create a "weather station." It should be able to track the room climate by storing the current temperature and humidity. Additionally, this collected data should be presented in a nice way.

The project consists of two major parts: The client, which measures the current temperature and humidity and publishes the data via MQTT. It is based on an ESP, and a custom PCB was created for the D1 mini to facilitate the connections. The second part is the server, which stores the received values and presents them in a nice way. There are multiple ways to start a server to handle the data: either with a Node.js-based server, which was specifically created for this project utilizing a SQL database to store the values and starting a web server to present the data in the form of graphs, or with the help of node-red, influxdb, and grafana. Here, a node-red flow is started, which automatically stores the published data to an InfluxDB, and Grafana is used to visualize it.