That also means it’s time once again to fill Advent calendars for the kids. This year, I came up with something very special for my daughter: a smart audio Advent calendar powered by Home Assistant!

Some time ago, I built my daughter her own music box. The box is based on ESPHome, recognizes when NFC tags are placed on it, and then starts an album via Home Assistant → Music Assistant → Spotify on a SONOS speaker. I packed the whole thing into a LEGO case and attached a few buttons — basically a DIY Toniebox. Since so many people have asked about the LEGO version, I still owe you a separate blog post on that. But you can find the guide to the first version here.

The box is used daily. Unfortunately, she’s been playing Christmas music every day since September. Anyway, she’s a huge fan of the German audio series Bibi Blocksberg. And as it happens, there’s even a Bibi Blocksberg Advent calendar episode! That’s when the idea hit me: I could make her a special NFC card for the box just for that.

The problem, though, is that she wouldn’t stop after the first chapter. She’d binge the entire story on December 1st. And that’s definitely not the point of an Advent calendar...

To avoid that, I needed to give her one card per day. But since the cards are a bit too expensive, I found a cheaper alternative: 24 NFC chips. I numbered them from 1 to 24 with a marker and mapped each tag ID to a single track on Spotify.

Result: Each chip plays only one chapter.

We put the chips into a regular Advent calendar — in our case, a Haribo one. I took the gummy bears for myself, of course. But don’t worry, my daughter also gets a regular analog calendar with sweets. The chips are placed into the doors, which can then be resealed.

And there you have it — the smart audio Advent calendar!

On December 24th, she’ll get the full episode card. Afterwards, I’ll collect the chips. If the idea is a hit, I can easily recycle them next year for another story.

Fortunately, I have a second brain right inside Obsidian.

In this post, I’ll share my simple, effective workflow for taking, refining, and organizing technical notes in fields like software engineering and cyber security.

Why Obsidian?

I’ve tried many note-taking tools over the years (Notion, Standard Notes, Notesnook, Joplin, Evernote, Logseq, Trillium, Notable, QOwnNotes…). None of them felt quite right, until I landed on Obsidian.

Here’s why it works for me:

• Plain Markdown files → My notes are just text files in Markdown. If Obsidian ever disappears, my notes remain usable. I can back them up with Git and sync however I like.

• Data under my control → The notes live locally. If I use Obsidian Sync, they’re end-to-end encrypted. It means no central server exploit can expose my thoughts.

• Back-links → The ability to easily create links with [[this format]] was a true game-changer. It makes connections between ideas visible — often between concepts I didn’t realize were related.

• Flexibility & plugins → Templates, customization, community plugins, and a thriving community all add up. Obsidian has the features I need without locking me in.

Step 1: Capturing Notes Quickly

The first step is to capture thoughts instantly.

I don’t overthink where to store them or how to name the file. If I hear a new concept, it needs to go into my second brain immediately.

• On desktop: CTRL + N, type the note, done.

• On mobile: Open the app, hit +, type the thought, done.

Example: If I hear about Caller ID Spoofing in a cyber security podcast:

• CTRL + N

• type "caller ID spoofing"

• saved in seconds.

All new notes land in my 01_inbox folder. These raw notes are “fleeting.” They may be messy, incomplete, and unstructured — but they’re safe, not lost.

Step 2: Capturing Files Quickly

Ideas don’t always come as words. Sometimes it’s a screenshot, article, or PDF.

• Screenshot → CTRL + N, then CTRL + V.

• PDF → Drag and drop into a new note.

• Mobile → Share directly to the Obsidian app.

I configured Obsidian so that all attachments (images, PDFs, etc.) go into a 99_attachments folder. This way, files don’t clutter the inbox - the note referencing them is what matters.

Step 3: Refining Fleeting Notes

Later, when I have time, I revisit the inbox to refine notes.

Let’s say I open my Caller ID Spoofing note:

• I quickly research (Google, Wikipedia, blogs, Perplexity, etc.).

• I then summarize the core ideas in short bullet points and my own words.

• I keep the definition concise. I want a quick reminder, not a mini-Wikipedia.

This ensures searching my notes is faster than Googling again.

Using Back-links

While refining notes, I make heavy use of [[back-links]].
You can create a link to any note by typing its name inside [[ ]].

• If the note already exists, you even get auto-completion (like in a bash terminal) → super satisfying for developers.

• If the note doesn’t exist yet, you can still create it as a back-link. From then on, auto-completion works—even before the actual file has been created.

This way, when I mention technical topics or concepts, I just back-link them right away:

• Social Engineering → [[Social Engineering]]

• Identity Theft → [[Identity Theft]]

These are concepts that I know will definitely show up again later, so it makes sense to link them.

At the bottom of many of my notes, I also add a Links section. Here I include related thoughts and associations that come to mind - even if they didn’t appear in the body text. For example:

• [[Netzsicher]] (the podcast where I picked up the idea)

• [[Cybersecurity]] (the broader umbrella topic)

• [[Phone]] (an obvious mental connection)

This Links section helps turn each note into a hub for related ideas - whether they are similar, or contrasting. My personal rule of thumb is that every note should connect to at least one other note.

Here are more examples:

Step 4: From Fleeting Notes to Atomic Notes

Once a note is refined, I drag it from 01_inbox into 02_notes.

These “atomic notes” each cover a single idea or concept in a distilled way.

What’s the benefit?

• Writing in my own words forces true understanding.

• Even if I forget later, I can retrieve the knowledge by searching or following links.

• Searching for “phone” or “identity theft” or “fake number” will lead me back to *Caller ID Spoofing*.

Thanks to back-links, I can also trace related ideas:

Checking my Social Engineering note’s back-links may lead me back to Caller ID Spoofing. This is where the graph view really shines.

Step 5: Deeper Learning Through Iteration

Sometimes I want to expand further.

If I keep linking to [[Social Engineering]], eventually I’ll create that note and build it out using the same steps. Over time, my graph grows richer — not by force, but organically, based on what I revisit.

This iterative process builds a living knowledge system where concepts connect naturally.

Keep It Simple

There’s so much more I could share:

• Using templates to add structured, query-able metadata to notes

• Organizing courses via bases

• Randomly resurfacing and polishing older notes

But here’s the important takeaway: start simple.

Don’t chase complicated workflows, zettelkasten theories, or dozens of plugins. Start capturing. Start linking. Start refining. The second brain will build itself.

Summary

This is my workflow for capturing, refining, and organizing technical knowledge in Obsidian:

1. Capture quickly (fleeting notes → inbox).

2. Attach files easily (screenshots, PDFs, images → attachment folder).

3. Refine notes with short bullet point summaries in my own words.

4. Back-link aggressively to link concepts together.

5. Move refined notes into a structured folder of atomic notes.

6. Iteratively build knowledge through back-links and deeper notes.

I’ve used this system for years while learning cyber security and software engineering. It’s not perfect, but it works — and more importantly, it grows with me.

If you’re starting your own note-taking journey, my advice is simple: just start.

Your second brain doesn’t have to be perfect on day one - it just has to start working for you.

Share

FAQ

❓ How is your folder structure?

Very minimal. I only keep a few top-level folders for this workflow:

• 01_inbox → New, fleeting notes (raw, unrefined).

• 02_notes → Refined, atomic notes in my own words.

• 99_attachments → Images, PDFs, and other files.

That’s it. I prefer not to over-complicate with too many sub-folders — back-links do most of the organizational work for me.

❓ Do you share your vault?

No. My vault contains private notes, work references, and personal thoughts. That said, the method is what’s important — not the content. You can build your own system using the same structure.

❓ Why is writing in your own words so important?

This is the core of my workflow. I never just copy-paste from articles or books. Instead, I summarize and rephrase in my own words.
This simple step:

• Forces me to actually understand the topic.

• Makes retrieval easier later, since I’ll recognize my own phrasing.

• Prevents turning my vault into just another dump of external info.

If you skip this, you essentially skip the real learning part.

❓ Where do you study cyber security?

I started with the SEC-100 certificate from OffSec.
Currently, I’m taking the CPTS (Certified Penetration Testing Specialist) course on HackTheBox.

❓ How long did it take to build your graph?

I’ve been taking notes like this for 2–3 years.
It grows more quickly when I’m reading a technical book or taking a course, and more slowly when I’m just doing daily work.
The graph is a byproduct — it emerges naturally over time, not something I actively try to “grow” for its own sake.

❓ Isn’t this a lot of work?

Yes, it takes time to write good notes. But the benefits compound over years:

• Writing and linking forces deeper understanding.

• Notes become my first lookup point before I turn to Google or AI.

• Over time, I’ve built a “second brain” that saves me hours of re-learning the same things.

In short: yes, it’s effort, but it pays off more than any quick-copy method ever could.

👉 Your turn:

• What’s your workflow for keeping technical knowledge organized?

• Do you have a favorite Obsidian tweak I should try?

Let’s compare notes and keep learning together.

Pen-testing is fun.

Breaking things on purpose, but in a responsible way.

Sounds cool, right? Hacker hoodie, flashy exploits, adrenaline...

But here’s the problem: the law.

When you touch a system that’s not yours, you’re instantly walking a legal tightrope. And that's a wobbly one.

So before you even get started, make sure to have the most important docs in writing: Authorization. Scope. Contacts. Duration.

That is boring, sure. But that little PDF with signatures is your parachute when things get messy.

But these documents are not a free get-out-of-jail card. There are lots of laws and regulations you have to comply with when pen-testing.

Yes, that is boring, as well. But if you build up a life, career, family, you don't want to throw that all away by going to jail because you misstepped once.

So here’s a bare-minimum legal cheat sheet for cyber security. Not a law textbook, no legal advice. Just the basics, so you know where to look (and what to google when in doubt).

USA 🇺🇸

• CFAA (computer fraud and abuse act): The OG cybercrime law. Super broad. Anything “unauthorized” can land you in trouble. Often criticized as _way too generic_.

• DMCA (digital millennium copyright act): Circumventing digital locks = no-go. Applies even if your hack is not malicious.

• ECPA (electronic communications privacy act): Wiretaps, message interception, unauthorized data sniffing → illegal. Courts can’t use unlawfully intercepted data.

• HIPAA (health insurance portability and accountability act): If you touch health records, there are strict security rules. Fines can be brutal.

• COPPA (childrens online privacy protection act): Extra care if your work touches children’s data (<13). Strict limits here.

Europe 🇪🇺

• GDPR (general data protection regulation): The famous one. Personal data = protected. Hefty fines if you mess it up.

• NISD (network and information systems directive): Forces bigger organizations beyond critical infrastructure to have solid cyber defenses.

• Cybercrime Convention: Joint effort between countries to fight cyber crime. Legal basis for cooperation.

• E-Privacy Directive 2002/58/ec: Email, cookies, communications data → extra rules for handling.

UK 🇬🇧

• Computer Misuse Act 1990: Unauthorized access = illegal. Police may seize hardware.

• Data Protection Act 2018: GDPR-but-make-it-UK.

• HRA (Human Rights Act 1998): Right to privacy, includes digital life.

• Police and Justice Act 2006: Expanded cyber crime definitions to cover more abuse cases.

• IPA (Investigatory Powers Act 2016): Legalized mass surveillance & hacking powers for agencies.

• RIPA (regulation of investigatory powers act 2000): Earlier rules for secret investigations. IPA is basically its evolution.

India 🇮🇳

• IT Act 2000: Unauthorized access banned. Digital evidence is admissible in court.

• Personal Data Protection Bill 2019: Proposed GDPR-like rules, but got shelved.

• Indian Evidence Act of 1872: Defines what counts as admissible in cyber crime cases.

China 🇨🇳

• Cyber Security Law: Companies must protect infrastructure, report incidents, safeguard personal data.

• National Security Law: Anything threatening "national security" (broadly defined) = illegal.

• Anti-Terrorism Law: Blocks all terror-related online activity.

• Cross-Border Data Measures: Exporting data abroad? Needs government approval + security reviews.

• CII Security Regulation: Like the Cyber Security Law, but focused on critical infrastructure.

  Cello's Blog is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Takeaway

Pen-testing is fun. Regulations? Not so much.

But if you don’t know at least the basics, you risk stepping from ethical hacker to criminal defendant in seconds.

So:

• Always get written authorization.

• Stay within scope.

• Remember: the law differs wildly across borders.

Think of laws as the invisible tripwires in the system. Knowing where they are doesn’t just keep you safe. It keeps you hacking another day.

That’s the reality: complete safety does not exist. Every system has risk. The goal isn’t to eliminate risk entirely - that’s impossible - but to manage it effectively. And you can only manage what you first identify.

Vulnerability Assessments

Automated tools such as Nessus, Qualys, Wiz, and OpenVAS are great at scanning and uncovering a wide range of vulnerabilities across your infrastructure. They cast a broad net and provide valuable coverage.

But automation has limits. These tools cannot adapt to your unique system configurations, business logic, or organization-specific attack surfaces. They’re a necessary starting point, but by themselves, they don’t provide a complete picture of your risks.

Penetration Tests

A true penetration test goes beyond automated scanning. It’s tailored to your own environment, adapting to your configurations, business processes, and technology stack. Skilled pentesters can:

- Chain multiple vulnerabilities together

- Detect business logic issues

- Simulate realistic attacks that tools miss

Importantly, penetration tests are a moment-in-time snapshot. They provide valuable visibility into your risk landscape on the day of testing, but once completed, they do not continue to monitor your systems. New vulnerabilities, configuration changes, or software updates after the test can reintroduce risk.

Common Misconceptions

Training platforms like HackTheBox or TryHackMe have gamified aspects of offensive security. While excellent for skill development, they encourage a mindset of finding a single attack path - much like solving a puzzle.

In reality, this is closer to a red team exercise, which simulates a persistent attacker who only needs one way in. By contrast, a penetration test is about coverage: finding as many potential weaknesses as possible, not just one.

The Bottom Line

Effective risk management requires a layered approach:

1. Automated vulnerability assessments for broad coverage

2. Tailored penetration tests for in-depth risk analysis

3. Red team exercises to validate detection and response readiness

Remember: you are never completely safe. Risk is always present. But with continuous scanning, periodic pentests, and strategic red team exercises, you gain the visibility needed to make informed, proactive decisions about the threats you face.

Learning by doing isn't just a nice-to-have in cyber security; it's essential. You can read about vulnerabilities all day, but until you've exploited one in a controlled environment, you don't truly understand the attack vector.

Always understand the "why". Don't just follow step-by-step tutorials. When you run that Nmap scan, understand what each flag does. When you exploit that buffer overflow, know why those specific bytes cause the crash.

Question everything. That includes your assumptions, the tools you're using, and even the advice you're getting. This skeptical mindset is what separates script kiddies from real security professionals.

Do it on your own. This one hits different in cyber security. It's tempting to immediately ask for help when you're stuck, but the struggle is where the learning happens. Many tasks are genuinely difficult, but they provide invaluable learnings along the way.

Learn to ask good questions when you do need help. Show your work, explain what you tried, what you expected, and what actually happened. This demonstrates effort, helps others learn from your process, and dramatically increases the likelihood someone will help you.

Stay legal. Always. Before doing any security work, ensure you have a signed scope document that clearly defines what you're authorized to test. Stay within that scope no matter what you discover. Your curiosity and skills are powerful tools. Use them to build, protect, and defend - never to harm.

I developed an app for Android and iOS without writing a single line of code. I even had no prior experience with the programming language used. All of this was thanks to an AI agent, which I also had never used before. That sounds pretty impressive at first, but it actually wasn’t quite that easy. Here’s a brief report of my experience and what I learned, including tips and pitfalls, so you can do the same!

Starting Point

I’m a professional software engineer, mainly working in the .NET environment. For work, I wanted to get more familiar with React to be able to implement small features full-stack. And what better way to learn a language than to develop a small project with it?

The Project

Some of my friends are real BBQ nerds (myself included). We grill all the time, running through the entire range of Weber recipes, even in winter. One of my friends even hit 300 grill sessions in 2024. He knows this so precisely because on each grill day, he marks a small cross on his calendar with a pen. That’s where the idea came up to digitize this. A small app to track your grill sessions with a photo and some metadata, so you can view statistics and unlock achievements.

• How often have I grilled this week/this month/this year?

• What are my most frequently used ingredients?

• How often have I managed the perfect weekend?

• How many people have I grilled for?

• ...

The Tech Stack

Since I use Android and my buddy uses iOS, it was clear right away that the app had to be cross-platform. It also had to use React or React Native, since I wanted to learn this language. I quickly found Expo, a seemingly very popular framework in the community that appeared to meet all my requirements. As my IDE, I chose Cursor AI, since colleagues had recommended it. By default, my setup used the Claude 3.5 model.

Getting Started

To avoid starting totally blind, I first watched some Expo getting-started videos. The videos were surprisingly up to date, and I was able to recreate the easy, trivial quick-start examples almost 1:1. I also browsed a bit through the React Native docs to get a first feel for the syntax and general paradigms of the language.

Vibe-Coding

Now it finally started. In Cursor, you can simply enter prompts, and the AI makes the changes in the files, showing a git diff you can view and accept directly in the editor. For example, if I prompted for a list view as the content of my first page, the AI recognized it was an Expo project and inserted the appropriate code. What can I say? The start was quite impressive.
Within seconds, I had a list of grill sessions on my phone. I prompted for more and more details over time. First, I wanted more sample data for the list, then I wanted an image for each list item, then I wanted to change the sorting, change colors, etc. No matter what I asked for, the AI executed it.
Thanks to the really strong start, I actually slipped into a sort of “vibe-coding” mode: I just wrote prompts and barely looked at the generated code anymore, simply accepting it.

The First Setback

I then had the AI implement another view for adding grill sessions. Additionally, navigation between the two pages had to be implemented, and persistence via the phone's file system needed to be added. By this point, the AI’s changes were becoming noticeably slower. The compiler complained more and more, the AI repeatedly apologized and iterated to fix issues like incorrect syntax. Again and again, I had to specify the context explicitly in the prompt or restrict it so that usable results would be produced.

Pair-Coding

By now, I had scrolled through the code myself a bit and can objectively say that quite a lot of technical debt had accumulated. Files exceeded 1,000 lines, with a lot of duplication, no architecture, and no tests. Therefore, blind vibe-coding is apparently not viable, even for a relatively small project. So I decided to change my approach. Instead of having the AI do everything on its own, I paired up with it, just like you would with a junior developer, explaining and avoiding code smells.

I took each feature again and, together with the AI, refactored it. Bit by bit, I had the AI extract small components and clean up according to best practices/clean code. I always had to explicitly state that the AI should only edit that particular component; otherwise, there were often random changes elsewhere in the repository.
When it came to what should be in a component from a domain perspective and what should not, the AI often guessed wrong. Here, I had to be very exact with my prompts to get the desired result.

This approach actually paid off. The code became a lot cleaner, and even I, as a React newbie, could follow the small diffs and intervene if needed. Most importantly, very atomic commits in git are essential so you can revert to a previous commit if the AI goes into Skynet mode and destroys everything.

But I also benefited from the pairing. When I didn’t understand diffs, the AI explained them really well. Especially React paradigms I hadn’t known before were made clear to me by the AI. I think this is clearly the strength of this approach. You just have to be curious and ask the right questions.

The Result

The app is finished, works as intended, and is available in both the Play Store and the App Store! Here are a few pictures:

The app is already being used by several people, which is, of course, very rewarding to see.

Was This Approach Worth It?

I think so, because without additional practice with a programming language previously unknown to me, I would never have managed to build the app this way. Constantly googling syntax would have taken far longer, and as a dad, that's important to me. Projects that seem too big are immediately considered unrealistic and abandoned. But this way, I actually completed a project in just a few days (spread over several weeks).

Would I Have Been Faster In My Familiar .NET Environment?

That’s tough to judge. Even now, I would rely heavily on AI support there. In .NET, I can, of course, understand code changes better and faster, but I think the tech stack for cross-platform development (dotnet MAUI) is significantly more bloated and would have caused quite a headache. The code would probably have been even cleaner, though. In the long run, that’s certainly a benefit.

Outlook

Pair-coding with AI works and is efficient. It’s important not to fly blind, but to consciously review things. AI doesn’t replace software engineers; instead, it’s a new tool for them. As a result, the outcome will depend on your own software development experience, as you really have to guide the AI in the desired direction. And only a trained software engineer knows exactly what that direction should be.

What are your experiences with AI agents?

This is my walkthrough for the machine Nibbles on Hack The Box.

Enumeration

As usual we are only given the IP of our target machine. For convenience let's add that IP into our /etc/hosts file. That way we can simply use target instead of re-typing the whole IP whenever we need it for a command.

Next is a full scan with Nmap. I like to add the flag --open to only get open ports and not pollute the result with so much noise. The flag -p- tells Nmap to scan all ports, not just the most common ones.

We see that there is an open http port 80. Let's use cURL to see if we get a response from there.

We get a boring Hello world!. But further down, we see a hint. It seems like there is a sub-directory called nibbleblog. Let's cURL http://target/nibbleblog and we get quite a huge response. So we better open that in the browser:

Alright! Looks like some dude named Nibbles runs a blog about Yum yum, or a dude named Yum yum runs a blog about Nibbles!? Either way around, that sounds wrong. But unfortunately there is nothing more interesting to find here, I guess. There are no posts yet. There is no about page, no login page, no guestbook. So let's enumerate further and start gobuster to see if we can find more hidden sub-directories of that blog. We use a list from SecLists for that.

Nice, we have quite some findings! Let's start with the /README since that really sounds promising.

This provides us with some URLs that give insights to nibbleblog which appears to be a CMS for blogs. This also gives us a first inside into the tech stack of the blog: It runs on PHP. Let's verify that with WhatWeb.

We see PHP again, so that seems to be correct. Also we that the blog might be running on Ubuntu.

Let's check the next URL we found. /content is very interesting since it contains further sub-directories called /private and /tmp. Digging deeper we can find file called config.xml.

There is a lot more nibbles and yum yum garbage. But there are also some email addresses, especially admin@nibbles.com. This could indicate that admin is a possible user name for the blog. We are able to verify that in the next file called users.xml.

Moving on to /admin gives us login page. Knowing that admin is a valid user, let's try some obvious passwords like admin, administrator, password. Sadly that does not work.

Let's run CeWL to generate a custom wordlist that we might use later to brute-force the password. CeWL crawls the whole page and collects long words and/or words that are mentioned very often.

Wow. Nibbles is really mentioned 9 times. And, thank god, the password nibbles grants us access to the admin area of the page. From here we are able to publish new blog posts, change the theme, or tweak some settings. Also there are some plugins installed. One let's you upload an image. When we try that, the image appears in the already found directory content/private/plugins/my_image/.

Initial Access

Since we are now able to upload a file and also access it afterwards, let's try to upload a web shell for PHP. We use a simple test string for that.

Since that worked, let's go a step further and upload a reverse shell to gain our first foothold on the target. We can find all kinds of reverse shells on pages like GTFOBins.

Privilege Escalation

Now that we are in, we have to gain ourselves root rights. This includes re-starting the enumeration phase of our attack. We just found a file called personal.zip right next to the user flag. We should check that out.

That script is quite big. We will defer digging deeper into it and proceed our enumeration first. Let's upload one of the big privilege escalation scripts like LinEnum or LinPEAS onto our target and execute it. We do that by serving a http server via python on our machine and get the file on our target machine via wget.

After executing the script on our target machine we get a finding. It seems like our user nibbler is allowed to run the previously found script monitor.sh as root without password!

In that case let's visit GTFOBins again, grab a reverse shell, append it to the file monitor.sh, and execute the script.

We are root! Now we own the machine. All there is left to do, is getting the root flag.

I've installed quite some smart home stuff in my house. Some projects I'm really proud of, like the music box I built for my daughter. Others are super nerdy, like the smart meter I made for my gas meter.

I would have expected visitors who are not so tech-savvy to be really impressed by that.

To my surprise, however, I always find that another, totally dumb automation is the winner of the visitors' hearts... But first a little more background:

Open house

We enter our garden directly from the living room via a patio door. The door has a handle like the ones on windows. If you turn the handle horizontally, the door can be opened. If the handle is pointing downwards, it is locked.

This door was often accidentally left open because it was only pushed shut but the handle was left in the horizontal position. This makes you feel quite uncomfortable when nobody is in the house.

A smart solution had to be found...

Home Assistant to the rescue!

The classic solution for detecting open windows and doors is using smart magnetic contacts, which I've installed a lot in my house. But for this problem door, of course, that's not enough because it's closed according to the magnetic contact but not really locked due to the handle position.

But after a bit of research, I found out that there are also door handle sensors! They don't seem to be quite so common because there isn't such a wide vendor range, but they are just right for this application.

They tell me which position the door handle is in, regardless of whether the door is open or closed.

This is exactly the state I need to solve the problem. For example, I can now show on our dashboard that the door is open. This means we can see this directly before we leave the house or go to bed. I also send a message to my cell phone if the door is still open while no one is at home.

But now to our guests' favorite automation:

The guest's favorite

The door also has a blind. If the blind is down but I need to go out into the garden (to get a beer, cough), now all I have to do is turn the door handle and the blind goes up automatically. No need to press a button on the blind switch. As soon as I'm back in the house and turn the door handle to the closed position, the blinds go down again.

The whole thing really isn't rocket science. I can recognize the door handle as described above via the door handle sensor and I can control the blinds via the built-in smart relay. Linking the two in home assistant is trivial.

Nevertheless, every guest wants to try it out for themselves and has a grin on their face. I guess it seems like magic when a door handle controls the blinds...

The Problem

I recently became the proud owner of a Steam Deck. Most of the time I play comfortably on the couch in handheld mode, but every now and then I want to throw a game onto the screen via my projector. To do this, I ordered a dock that connects the Steam Deck to my projector via HDMI.

I now have two input sources for my projector. One is the Fire TV cube for watching series and the other is the Steam Deck for gaming. I have connected both with a cheap HDMI switcher, so that I don't have to change the HDMI cable every time. It automatically recognizes which input has an HDMI signal and activates that route to display on the screen.

However, this only works half well. For example, if I send the Steam Deck to standby, the picture from the Fire TV cube doesn't come up. Or if I played games the day before and start the cinema today, the picture occasionally stays black because the Steam Deck is still blocking the HDMI input. Then I either have to remove the Steam Deck from the docking station (and get up from the couch, yikes!) or switch the source of the HDMI switcher via IR remote control. Neither option is a solution, of course.

Home Assistant to the Rescue

The only device that needs to be made smart here is the HDMI switcher. It is already half smart, as it can be operated via IR remote control. The only thing we need to teach Home Assistant the IR protocol is an inexpensive little helper: an IR blaster. In other words, a device that is able to learn IR commands and send them back itself. A smart universal remote control, so to speak. I still had a Broadlink RM4 in my cable box for this purpose.

I connected it and placed it right next to the HDMI switcher. Learning the commands, i.e. the buttons that switch to input 1 or 2, is now super easy in Home Assistant. It's just an action that needs to be executed via the Developer tools:

I give the commands a name, i.e. goto-hdmi-one or go-to-hdmi-two, and say which remote control this command belongs to, in this case hdmi-switcher. I then click on perform and press the button on the remote control in the direction of the IR blaster. Done.

Now this command can be re-fired via actions, i.e. the Developer Tools. If necessary, this can be done x times in succession if the connection is not robust enough:

Top. So now I am able to select the input via Home Assistant. So, how does this solve my original problem?

Fixing the Issue

First of all, I want to have the Fire TV as the default HDMI input for my projector. So when I start my home cinema, I now explicitly set this input. This means that it doesn't matter whether I played games the night before or not.

I have also put the HDMI selection on my dashboard so that I can change the mode from the couch.

To do this, I simply added two new tile buttons to the dashboard, which are only visible when the cinema is active. When clicked, the buttons simply execute the corresponding remote command.

And that's it. A tiny little problem that was solved super easily with Home Assistant. My suggestion: If you are still using old IR remotes, just make them smart!

I often hear the argument "I have nothing to hide" when talking about data privacy. This argument, of course, is a little naive. Some time ago I came across a story that shows how easy it is to find enough private information about a person in publicly available sources (also called OSINT - Open Source Intelligence) to perform a scary phishing attack.

No matter if the story actually happened or is just made up, I want to rethink the steps of that attack from the role of the attacker to show how trivial it actually is. After reading it, be honest with yourself—would you have fallen for it?

Finding the Target

The first step is to find a company we want to attack. After some Googling, we find a promising company called Generic Company. We defined that company as interesting because of two facts:

1. The company has a high revenue every year. A high revenue also means a high potential bounty. This data is publicly available since the company is legally bound to publish a report periodically. There are multiple websites we can use to see the numbers, i.e., annualreports.com.

2. The company has to have an impressum on its website. The impressum lists the email address of the secretary: flobdop.jenny@generic-company.com. We noticed that Flobdop is a pretty uncommon last name. This is promising for further investigations.

Finding the Weak Point

Now we start researching Flobdop with some additional information, like the city of the company. We find an article from Generic School that says that Sarah Flobdop (14) won the school's art competition. We also find a death notice stating that Jenny, Mike, and Sarah are mourning the loss of their beloved Marge Flobdop. It's not rocket science to figure out that Sarah seems to be the daughter of our secretary Jenny from Generic Company.

Setting the Scene

Now we open up Google Maps and take a look at Generic School. We look for the nearest hospital and find Generic Hospital. The website shows us that there is an emergency ambulance. There is also a "Meet the Team" section. We now even know the name of the emergency doctor at the hospital, Doctor Generic. We could even take a little walk, visit the hospital, and take a photo of the shift schedule to know who will work next week.

Preparing to Phish

We go back to the website of the school and download some of the available documents. They all have a nice-looking school letterhead. We simply copy that for our own document we are about to write. We also note down the name of the school counselor.

The Attack

Let's swap roles again! We are now Jenny Flobdop.

It's a Tuesday morning. Kids are in school, and we are back at Generic Company doing work. Then an email pops up. You immediately recognize the design of your daughter's school. It says that they are sorry to inform you that your daughter Sarah had a school accident and was sent to Generic Hospital. Attached you'll find the admission report from Doctor Generic, signed by Generic School Counselor.

Of course the attachment was opened. The secretary was under emotional stress. Boom. As soon as the .pdf is opened, the ransomware starts...

According to the speaker this click cost Generic Company over 4 million bucks.

Conclusion

This attack is powered solely by publicly available information. There is no Matrix-style hacking involved; it's just a well-crafted phishing email that was created using the information we gathered through OSINT. So please reconsider your "I have nothing to hide" mentality.

Recently, I heard the term cookie nudging for the first time in a podcast and, to be honest, I had to research what that means exactly.

Nudging

Nudging means influencing a person in a desired direction. And not through guidelines or bans, but through psychological methods. The classic example of such a nudge is the fly in a urinal.

It seems that the image of the fly alone leads to significantly less splashing outside the urinal. There is no don't-urinate-on-the-floor sign. There is no drill instructor explaining how to hit the bowl's center.

The image alone is enough to make men aim for the correct spot.

Cookie Nudging

Almost every website we visit directly shows us a cookie banner. We are given the choice of whether to generally accept or reject all cookies, or to make fine-grained adjustments to the cookie settings.

The owners of these sites naturally wish for as many cookies as possible to be accepted, as they need them for certain functionalities, targeted advertising, or user analysis.

Therefore they often use a nudge, as well: The accept button usually has bold text and is colored green, while the reject button is unflashy or not displayed at all.

Subconsciously, we immediately press the green button because we want to quickly get to the actual website. A small but subtle psychological trick that pushes us in the desired direction of the website operator. A cookie nudge.

Social Engineering

Even though this is a trivial use case, it shows how susceptible we are to such small tricks. Cookie nudging is a form of social engineering. We should condition ourselves better not to accept everything out of convenience that stands between us and the content we want to see. Data is becoming increasingly important.

By the way, in the same context, I learned about the browser extension I don't care about cookies. This automatically closes the cookie banner with reject all when opening a page. This protects privacy and saves nerves. Highly recommended.

I bet you have a spare key for your home hidden somewhere on your property!

• Is it in the garden? Maybe disguised as a rock?

• Is it right under the doormat?

• Do your neighbors have it?

No matter where it is, it is important to have one! It sucks to come home after a long day, only to realize that you've forgotten your keys. I know that from experience because until recently we didn’t have a spare key.

Why? Because we didn’t know where to hide it. What if the hiding place isn't good enough? What if our neighbors were on vacation right when we need the key?

Thanks to Home Assistant I was able to implement an overkill-bullet-proof™ solution for that problem.

I introduce to you: The Fort Knox Key Safe.

Security Level 1: The Safe

My solution is based on a key safe. It’s pretty convenient for us since it works with a numerical code. Still this safe should scare of casual thiefs that just happened to find the key by accident.

Security Level 2: The Location

Of course I did not mount the safe right next to the main door. That would be an invitation. It’s somewhere in the backyard, not directly visible since it is hidden by some flowerpots.

Security Level 3: The Camera

One of my cameras monitors the location of the safe. That is deterrence. But also I will have visual proof of anyone trying to mess with the safe.

Security Level 4: The Vibration Sensor

Inside the key safe I attached a vibration sensor. That way I will be alerted if someone opens the safe or even tries to remove it from the wall. Spinning one of the number wheels is already enough for the sensor to detect a vibration.

The Bulls**t Heist

Someone sneaks in my backyard. It takes him 30 minutes to find the key safe. He tries to guess the combination. No success after 15 minutes. He takes out the jimmy and tries to rip the safe from the wall. The police arrive.

What happend? I received a notification on my phone because the camera detected a person in the backyard. I also received a notification that someone tried to open the safe due to the vibration sensor. Plenty of time to check the camera stream and call the cops.

Honest Summary

This solution is total overkill. I guess hiding a key somewhere in flowerpot is safe enough. But this solution is so much fun. And it gives me a false sense of safety. If you are a burgular: Please don’t take that as a challenge.

To be honest: A thief would probably just break a window with a rock instead of looking for a hidden key. But that’s no reason for skipping the fun of Home Automation. Your home just needs to be more secure than your neighbor’s.

I am a privacy nerd in many areas. Since discovering privacytools.io, I have been on a mission to replace all Google services I use.

One big skeleton that I had in my closet until recently is Google Photos. But that's finally over!

Why I Decided to Stop Using Google Photos

My wife and I have consistently stored all photos taken on our phones directly with Google. It was just super convenient. It's quickly set up and works flawlessly.

The decisive factor in finally getting rid of this Google service, is mainly the current AI hype: Google uses all the photos to train their AI models.

In plain language, this means: All photos of my wife, all photos of my children and all photos of me might be the training basis of a future AI model.

And this also means that this AI can then generate photos of my wife, my children and me at will. And the more I think about it, the creepier I find this idea.

The Perfect Alternative

So a good alternative had to be found quickly. In our case, it became ente.io.

Ente.io is almost a clone of Google Photos, but with one crucial difference: All photos are end-to-end-encrypted. This means that while our pictures are secured on ente.io's servers, they were already encrypted on our phones.

Even a shady system admin from ente.io would have no benefit from looking into the database; because there he only finds encrypted data. And the key to these data is only on our phones.

• Synchronization works flawlessly via the ente.io app.

• You can create folders for collectively collecting event photos into which other people can upload photos without having to create an account.

• There is also a search for photo content. However, this must first be activated and the index built up. This, of course, runs locally, without the cloud.

Conclusion

Often, you have to accept a few disadvantages when you detach yourself from Google, because objectively speaking, Google services are very good and convenient. In this case, however, we notice no difference in everyday life from before. But we have regained a large part of our privacy.

Everybody knows the famous Toniebox. It's a wonderful device which lets kids start music or an audio book just by putting a little figure on top of it. Every friend of our daughter got one on their second birthday. So the pressure was high.

My daughter looked at me with her big eyes — She wants one, as well!

But that cute little cube is not cheap. Especially the costs for the Tonie figures stack up fast… 15€ per figure times ten audio books: That's 150 bucks — for audio books that are already available with my Spotify subscription.

That's when I heard about and fell in love with the Phoniebox project. Building a DIY Toniebox for my daughter sounded like a really cool gift for her birthday.

I studied this excellent blog post and managed to build a fancy little box without any prior soldering experience:

And the best part: I was able to add as many audio books as I want without further costs! All content came directly from Spotify.

My daughter was happy. I was proud. Success.

The Catastrophe

Then it happened. My wife called me at work:

The box is not working. Did you tinker around again?

I did nothing. But Spotify did. The library libspotify got discontinued. A library the Phoniebox project heavily relied on. From one day to the next, thousands of Phonieboxes in the Spotify version stopped working.

My daughter was sad, even cried a little. I guess she was not the only one. I promised myself that this will not happen again!

That's why I built my own music box. A music box powered by Home Assistant. A music box I have full control over.

Step 1: The tag reader

My box will need to register NFC cards. So I have to include an NFC reader. The Home Assistant tags documentation references a cool project on Github for a standalone tag reader.

Exactly what I needed! All material needed are a wemos D1 mini, a NFC reader and a buzzer. That's it.

I ditched the LED since I don't wanted to integrate one in my box. Following the readme I was able to solder everything together and flash the firmware on the wemos D1 mini.

Step 2: Buttons

The Home Assistant docs really have a lot of information about the tags feature. Especially the chapter Building an RFID jukebox is nearly all I wanted.

But I want to have actual physical buttons. My daughter needs some buttons for play, pause, next, previous, volume up/down. So I bought some.

Step 3: Building the box

I bought a small bambus box from IKEA. I drilled some holes in it with these guys. Then I attached everything into the box with some hot glue.

I really learned a lot this time. This was the first time I soldered screw mounts on the board. The benefit, in contrast to hard-soldering the cables to the board, is that you are able to detach them if needed. This comes in really handy if you need to debug something.

I also used cable end crimps for the first time. No more wire fibers! And they can be easily attached into the screw mounts.

This was the first time I am actually proud of my cable management — although I guess any professional would puke looking at this. If so, please give me some tips! I'm eager to learn. Thanks!

The whole box is powered by a 5V power supply. The ESP gets powered directly over its 5V pin. Don't use the usb port for powering. I ran into all kind of issues like the NFC reader not working.

I integrated a coaxial power connector into the box, and it works like a charm. However, make sure you buy a connector that matches the size of your power supply. If they don't match, you will have a loose connection. There are two or three common sizes — just check the datasheets once and you should be fine.

Step 4: Tweaking the firmware to support the buttons

To add the different buttons to the firmware and Home Assistant I had to add some binary_sensors to the ESPHome yml file of my music box.

binary_sensor:
  - platform: gpio
    name: "liasbox_playplause"

    pin:
      number: D4
      inverted: true
      mode:
        input: true
        pullup: true
    filters:
      - delayed_off: 10ms

  - platform: gpio
    name: "liasbox_next"
    pin:
      number: TX
      inverted: true
      mode:
        input: true
        pullup: true
    filters:
      - delayed_off: 10ms

  - platform: gpio
    name: "liasbox_previous"
    pin:
      number: D3
      inverted: true
      mode:
        input: true
        pullup: true
    filters:
      - delayed_off: 10ms

  - platform: gpio
    name: "liasbox_volume_down"
    pin:
      number: D5
      inverted: true
      mode:
        input: true
        pullup: true
    filters:
      - delayed_off: 10ms 

  - platform: gpio
    name: "liasbox_volume_up"
    pin:
      number: D6
      inverted: true
      mode:
        input: true
        pullup: true
    filters:
      - delayed_off: 10ms 

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

substitutions:
  name: "liasbox"
packages:
  adonno.tag_reader: github://adonno/tagreader/tagreader.yaml
esphome:
  name: ${name}
  name_add_mac_suffix: false

Now I have all buttons available as entities in Home Assistant, yay!

Step 5: Let the buttons execute automations

Play/Pause, next, previous and volume up/down are all standard services of media_player entities. So all I had to do was trigger all those services when a button gets pressed. Here is an example for skipping to the next song:

I made similar automations for the other buttons, as well.

As you can see I capsuled the media player I want to use for my box as a helper entity. I did this because currently the music will start on our Sonos bar in the living room. That's where the box is located. But in a few years the box will move to my daughter's room. She will get her own little Sonos box (maybe the next good birthday present!?). And then I will be able to switch the media player very fast without needing to adjust all automations.

The helper is a group with a single entity.

Step 6: Creating the cards

The cards are simple NFC cards, but of course, they have to look good; I can't just write the title on the card with an Edding. My daughter can't read.

So my way is to print the audio books cover on a sticker. I use these because they come with an online software where I can upload the covers and resize them easily.

The result looks okay. It would definitely look cooler with a card printer. But that's just too expensive for me.

Step 7: Adding and triggering tags

After the NFC reader was added to Home Assistant (which is really easy if you followed the documentation from Github, since it is discovered automatically), you are able to add new tags. This can be done in the tags menu. When swiping an NFC card over the box, a new tag appears. It has a GUID as name. I immediately rename the tag to the content it should contain.

The automation that is triggered by the tag scan and actually starts the music is just a tweaked version of the example from the tag documentation. This is how it looks:

alias: Handle Tag Scan
description: ""
trigger:
  - platform: event
    event_type: tag_scanned
condition:
  - "{{ trigger.event.data.tag_id in tags }}"
action:
  - variables:
      media_player_entity_id: media_player.liasbox_mediaplayer
      media_content_id: "{{ tags[trigger.event.data.tag_id].media_content_id }}"
      media_content_type: "{{ tags[trigger.event.data.tag_id].media_content_type }}"
  - service: media_player.play_media
    target:
      entity_id: media_player.liasbox_mediaplayer
    data:
      media_content_id: "{{ media_content_id }}"
      media_content_type: "{{ media_content_type }}"
  - service: script.liasbox_setmediaplayersettings
    data: {}
  - delay: 2
mode: single
max_exceeded: silent
variables:
  tags:
    04-6E-DA-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/playlist/1u0bu4ezkj4QHDkfjXwKsW?si=76e77a3055134782
      media_content_type: playlist
    04-1C-E4-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/33Ss311uVWQViCaipw2laT?si=EfWjPNX4SieRiID3GbpnDA
      media_content_type: album
    04-A3-7A-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/0FHpjWlnUmplF5ciL84Wpa?si=9DLx-nzTS7uVkoH9YsEvvA
      media_content_type: album
    04-75-8C-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/3qAjGnHFbafzKWbntBjKb9?si=AeKRaR1eQ7S2RjLf41_aMA
      media_content_type: album
    04-4A-90-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/6LQALkZO2BD7UJW5Rbe7AQ?si=-BrXCB_2T0ihqJKTxigefg
      media_content_type: album
    04-31-8F-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/playlist/5AkNkdpGiTUT1Z1usDdiey?si=8723fd4d8fc5464f
      media_content_type: playlist
    04-83-98-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/5ju4E5z2e8haWhNVI6jvah?si=sbeJ0sWhTBq2fcYT3WKCSg
      media_content_type: album
    04-2B-82-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/playlist/6cKzIXYEkC2TtuTt07lOZe?si=86b2176eec0649e0
      media_content_type: playlist
    04-84-AA-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/3XOuj8bXBsPPJ5hmdtcGCd?si=sjuLO1LjTqut3501iOp_AA
      media_content_type: album
    04-04-7A-67-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/3MJtb4tIcyxbd7PIm5ASJ9?si=spXJG6INSbSI8szm6SgN_g
      media_content_type: album
    04-22-B8-63-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/12TT6OcOHRaM9HfWlfppxN?si=VzwdAKyWT7u9bVpA9L7LeA
      media_content_type: album
    04-EC-BA-63-10-02-89:
      media_content_id: >-
        https://open.sp0tify.com/album/1BDF8UTWY6wpxLzF6um2xQ?si=xX_ocM5NT5uFapCuuL7JKA
      media_content_type: album

As you can see, it's really not that complicated. You just modify the media_player you want to use and add each content as a new row. You get the ID from the tags menu and the link by using Spotifys “Share” button on the album you'd like to use.

I really like the new box. My daughter loves it and uses it every day. My wife hates it, because she has to listen to the same audio books every day.

I learned so much doing this project. And I know that if something breaks, it's my fault and I will be able to fix it.

My daughter is happy again and so am I! Thanks, Home Assistant.

Update 2024

I built a further improved version of the box as a birthday present. But maybe this is content for another post…

The Problem

When our daughter is (finally) asleep, we like to watch a few more series to wind down. Currently, we are into relatively violent stuff like The Boys. My wife likes to tell the anecdote that she used to crawl out of bed as a child, then secretly sit on the stairs and listen to her parents or the television. Once, she even had nightmares because her parents were watching a horror movie and she couldn't get the horrifying screams out of her head.

But back to the present:

I don't want my child to see exploding heads or dismembered people, let alone dream about them.

Home Assistant to the rescue!

The first challenge was to figure out how to detect my daughter's escape attempts in time. The solution is super simple:

I installed a cheap little door contact on the door to her nursery. Installed is an exaggeration, these things are just stuck on.

I then integrated it into Home Assistant. When integrating new sensors, it's best to remember to tidy up right away: give them a sensible name and disable any entities you don't need.

Now I can notice my little runaway as soon as she opens the door!

The opening of the door is the trigger of my automation. When this trigger occurs, I pause the playback on my Fire TV Cube and let my speakers make a little warning announcement.

Of course, this only happens when the cinema is currently enabled and it's our daughter's sleeping time. Otherwise, we would hear the announcement all day long…

alias: Notify at Fire TV Cube when Lia opens her door
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.liasroom_door
    from: "off"
    to: "on"
condition:
  - condition: state
    entity_id: binary_sensor.lia_sleeping
    state: "on"
action:
  - condition: state
    entity_id: input_boolean.livingroom_cinema_enabled
    state: "on"
  - target:
      entity_id: tts.home_assistant_cloud
    data:
      cache: true
      message: Lia is awake!
      media_player_entity_id: media_player.wohnzimmer
    action: tts.speak
mode: single

An authentic evening on the couch

• My wife and I are watching a gore-slasher-nightmare-horror movie

• Our little escapee sneaks out of her bed and opens the door.

• The movie pauses immediately; there are no scary noises or destructive images.

• The announcement confirms that our daughter seems to be awake.

• One of us can quickly go upstairs and put our daughter back into bed before she even has a chance to look at the screen.

Conclusion

That's why I love Home Assistant! Such a little automation adds so much value. Sweet dreams!

The Problem

The other day I picked up a phrase that still bounces around in my head from time to time.

If you don't write in your native language, there's always a risk that details will get lost.

I've been blogging in English so far in order to reach more people. But my mother tongue is German. Do I still manage to express what I want to convey?

I think so™. But even though I think I write good English, it takes me a lot more time and energy to write a post in a foreign language.

The Idea

So I had the idea to try the best of both worlds:

Why not write in my native language, where I have a deep understanding of subtle differences in meaning, idioms and vocabulary, and then simply have everything translated into the target foreign language?

The Test

And in fact, what you are reading here is already the result of that experiment.

I had this text translated from German to English by deepL. It took me barely 10 minutes to write this blog post.

The Question

But does it still sound like me? Or are the little mistakes I make in my posts due to the foreign language the soul of my blog? Philosophical deep talk today...

The Problem

My house is flooded with smart relays from Shelly.

• I use multiple Shelly 2.5 to control all the covers in my house

• I use a Shelly 1PM to keep track of the production of my balcony power plant

• I use many Shelly 1 to automate my light switches

I have at least 30 smart relays around my house/garden and they work flawlessly! But then there are one or two relays that give me headaches. Especially the one controlling the lights at my stairs. These lights are motion-controlled and I expect them to go off 3 minutes after all motion cleared. But over the last couple of weeks, this has not been happening.. This is very annoying since I had to get out of bed and switch them off manually.

So I checked the Home Assistant logs regularly to find the root cause. But all I found was the generic error DeviceConnectionError().

Then I stumbled on something interesting in the ESPHome docs:

That’s why I decided to give ESPHome a try and looked for a way to flash ESPHome onto my Shelly. Maybe this might finally fix the connection errors! Let’s get going!

Creating the ESPHome firmware

Go to ESPHome and add a new device. We do not need to connect our Shelly to the computer since we can do everything OTA (over-the-air).

Click on edit and insert and tweak the following configuration to fit your needs:

# Basic Config
esphome:
  name: stairs_light_shelly
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

logger:
api:
ota:

# Device Specific Config
output:
  - platform: gpio
    pin: GPIO4
    id: relayid

light:
  - platform: binary
    name: "stairs_light"
    output: relayid
    id: lightid

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO5
    name: "stairs_light_button"
    id: switchid

Hit save, click the 3 dots and select install. Choose Manual download and download the firmware file in modern format.

After the file was created and downloaded, we have to zip it since the file would be too big to upload it onto the Shelly 1. I use 7-Zip for that. Simply right-click the file and compress it to gzip!

You should now have a Shelly 1 ESPHome firmware with extension .bin.gz on your drive.

Flashing Tasmota as intermediate firmware

Check which IP is assigned to the Shelly you want to flash. You can see this in your router or by clicking Visit from inside Home Assistant.

Check the table in this repository. In case of a Shelly 1 you’d have to enter the following URL into the browser:

http://YOURIPADDRESS/ota?url=http://ota.tasmota.com/tasmota/shelly/mg2tasmota-Shelly1.zip

This will flash Tasmota onto your Shelly.

After 2 minutes you should see a new WiFi network with a name like tasmota-XXXXX. Connect to it and head over to

http://192.168.4.1

Here you can enter your WiFi credentials and hit save. Tasmota will now connect to your WiFi.

Flashing our ESPHome firmware

Go back to the IP address of your Shelly. You should see the default page of Tasmota.

Now it’s important to click on Console and enter

SetOption78 1

The console should confirm that you enabled the option 78. This enables us to flash firmware files that are not Tasmota builds.

Now head back to the main menu, select Firmware Upgrade and upload the firmware file we created previously. Start the upgrade! If everything worked out you should get a success message.

Integration into Home Assistant

After a short time (or a forced restart of Home Assistant), you will receive a notification that a new ESPHome device has been discovered — automatically!

That was easy.

Summary

It is possible to flash ESPHome onto many kinds of Shelly smart relays simply over-the-air. For me this fixed the connection issues I had with a specific Shelly 1.

This tutorial might help you if you are trying to solve the same problem!

As software developers, we type a lot. And we type very fast… This results in quite some keystrokes over the years. Sadly we don't get younger. Due to that load most of us will feel some signs of wear and tear at some point in their career. For some it's the neck, for others it's a pain in the fingers.

When I reached that point a few years ago, I decided to do something against it. I still have many, many full days of typing ahead of me and if I keep going like that, the pain might get worse. I decided to learn more ergonomic typing!

Problems with the QWERTY layout

Next time you are in the office, take a minute and observe a colleague while typing an email. You'll notice that his hands and fingers are moving like crazy, stretching, wrenching and twisting over the keyboard. Even an amateur will see that this arrangement of keys seems to be not very effective. It seems like two keys are always on the exact opposite side of the keyboard making the hands and fingers travelling the maximum distance possible.

And why is that? Because this actually was a design goal of Christopher Sholes when he developed the QWERTY layout that we use on our keyboards today.

He had no keyboard, he had a typewriter. When you pressed a key, a metal bar struck the paper to print each character with ink. And if two neighboring metal bars hammered at the same time they could potentially collide and got stuck.

That's why Christopher looked at the frequency of common words and letters of the english language and placed the most used letters as far apart as possible. The QWERTY layout was born.

Discovering Noted

Keyboards got rid of metal bars. So lots of smart people used this chance to create alternative layouts not optimize for an outdated goal like less collisions of metal bars but for a really helpful goal like ergonomy! All of them are magnitudes better than QWERTY and I don't want to judge which arguably is the best, but the one I went with is Noted.

I was extremely hyped, thinking I might have found a solution to save my fingers. But that feeling changed soon...

My learning journey

I found this beautiful website that gives you exercises to type and tracks your progress over time. I changed my layout to Noted and started... After one to two days I knew where all the keys were.

I decided to go cold turkey. From one day to the next, I changed my layout to Noted on all my machines. I printed the layout as a cheat sheet and put it next to my keyboard to get started.

Now began the hard part. This next two weeks were crushing. I typed around 6 words per minute. It felt like I had a stroke.

Chatting with colleagues became a chore, writing software was nearly impossible, and everything felt clumsy and slow, which was quite frustrating.

I think this is the first stage where people might give up. And I can totally relate. But with some motivation from a friend of mine who went that road years ago, I kept going.

After 4-5 weeks consistently writing Noted only and exercising with monkey type multiple times a day, I slowly came back to a okayish typing speed. And by that I don't mean fast, I mean I could get some work done. Slowly.

It took me around 3 months until it made click. After that time I reached around 30 words per minute, which is not totally embarrassing anymore.

Today, nearly a year later, I can type at a speed of around 50-60 words per minute. But I am drifting up only talking about speeds while my initial goal was ergonomy. So how does it feel?

Benefits I've experienced

This is the first time in my life I can actually type blindly. I always was fast and peaked seldomly, but this is another level. I now never look at the keyboard. I even use a keyboard that only has blank key caps. This feels good. And nerdy.

Additionally, your fingers seem to naturally rest at the home row. Colleagues say it looks really relaxing when I type. And this is true. Your hand is still while your fingers only make minor movements. You actually can see that when looking at the finger heatmap.

In addition to that your fingers seem to roll the words. That might read strange but often you do 2 strokes on the home row with the left hand and then 2 key strokes on the home row with the right hand. This feels natural and almost like playing the piano.

And most important: My pain is gone.

Noted also has layers. Just like QWERTY changes from minor to capital letters when holding the shift key, Noted changes to another layer.

The first layer contains all the special characters. This is super cool especially for programmers since important keys like the brackets are all on the home row. So even this can be typed without hand movements.

My favorite is the second layer because you immediately have the arrow keys under your left hand and a number block under the right hand. This helps for navigating code and drastically reduced my mouse usage.

I could go more into detail but I need to wrap it up here:

Conclusion

I spent 3 months learning something that will benefit me for the rest of my life. That's a no-brainer. If you experience a strain in the fingers or the neck, give it a try for its ergonomic effects! If you work as a developer, give it a try - you will learn to love its layers while coding. If you, like me, do both, what the hell are you still waiting for?

Inversion of Control and Dependency Injection are two of these big buzz words you always hear when talking about modern software development. At least they were when I started going professional. That’s why I invested quite some time to research that topic. I was surprised that our Senior Software Engineer did not…

I had to explain it to him while reviewing some of my code. I still remember his reaction:

That’s it? That easy? I was completely mystified by that stuff for years and you just explained it to me in a short call?

If even my valued colleague, who was my mentor for the past few years, still didn’t get that concept, I thought it might be worth writing yet another explanation:

Inversion of Control and Dependency Injection for Dummies!

Dependency Injection

Let’s say you want to write a piece of code that tracks how much time you spend in front of your computer. You might come up with a simple API like this:

using System;

namespace ComputerTimeTracker
{
    public interface IComputerTimeTracker
    {
        void StartTracking();
        void StopTracking();
        TimeSpan GetTimeSpendInFrontOfComputer();
    }
}

If my colleague implemented that interface a few years back it would have looked somehow like that:

using System;
using System.Diagnostics;

namespace ComputerTimeTracker
{
    public class ComputerTimeTracker : IComputerTimeTracker
    {
        private readonly Stopwatch _stopWatch;

        public ComputerTimeTracker()
        {
            _stopWatch = new Stopwatch();
        }

        public void StartTracking()
        {
            _stopWatch.Start();
        }

        public void StopTracking()
        {
            _stopWatch.Stop();
        }

        public TimeSpan GetTimeSpendInFrontOfComputer()
        {
            return _stopWatch.Elapsed;
        }
    }
}

Simple and straight-forward. The only thing this class needs to do its work is a Stopwatch instance.

The class needs an instance of Stopwatch.

The class is dependent on a Stopwatch.

The Stopwatch is a dependency of the class ComputerTimeTracker.

So far, so good. Now let’s just do a little modification to that code:

using System;
using System.Diagnostics;

namespace ComputerTimeTracker
{
    public class ComputerTimeTracker : IComputerTimeTracker
    {
        private readonly Stopwatch _stopWatch;

        public ComputerTimeTracker(Stopwatch stopWatch)
        {
            _stopWatch = stopWatch;
        }

        public void StartTracking()
        {
            _stopWatch.Start();
        }

        public void StopTracking()
        {
            _stopWatch.Stop();
        }

        public TimeSpan GetTimeSpendInFrontOfComputer()
        {
            return _stopWatch.Elapsed;
        }
    }
}

The only thing that changed is the constructor.

Instead of creating the instance of Stopwatch inside the constructor we inject it into the constructor.

We inject the Stopwatch into the constructor.

We inject the dependency Stopwatch into the constructor.

We just did a dependency injection.

And I just want to make it clear: That is really all! Dependency injection means nothing more and nothing less than providing a dependency to someone who needs it instead of letting the someone create the dependency itself.

It does not matter whether you inject the dependency via the class constructor, via a property, or via a setter-method. All you do is injecting a dependency.

Inversion of Control

To quote my colleague again:

I think we have to discuss this. Now I need to create the Stopwatch instance before I can even create an instance of ComputerTimeTracker. That sucks. Isn’t that a code smell? Object oriented programming always praises information hiding, but now I have to know about a Stopwatch? When I create the instance inside the constructor I just have to create my ComputerTimeTrackerand it will handle the rest for me. I don’t want to know the implementation details, I just want to use the class. In summary: The Stopwatch should be controlled by the ComputerTimeTracker.

Notice how he already used the word controlled. I’m just gonna think that thought a little bit further:

In the approach of my colleague we have clear order of control:

The class ComputerTimeTrackeris controlling the Stopwatch.

It’s the responsibility of the ComputerTimeTrackerto control the Stopwatch.

Now notice what changed when looking at the approach where we injected the Stopwatch:

We, the users of ComputerTimeTracker, are controlling the Stopwatch.

It’s the user’s responsibility to control the Stopwatch.

You might have already noticed it. By injecting the dependency we inverted the order of control. We moved the responsibility to control the Stopwatch from the class away to the user of the class. That is inversion of control. And again: That is really all!

Loose Coupling

Now that the buzz words are de-mystified we can talk about why we might prefer the approach with dependency injection. Let's enhance our sample code a little further:

using System;

namespace ComputerTimeTracker
{
    public interface IStopwatch
    {
        void Start();
        void Stop();
        TimeSpan Elapsed { get; }
    }

    public class ComputerTimeTracker : IComputerTimeTracker
    {
        private readonly IStopwatch _stopWatch;

        public ComputerTimeTracker(IStopwatch stopWatch)
        {
            _stopWatch = stopWatch;
        }

        public void StartTracking()
        {
            _stopWatch.Start();
        }

        public void StopTracking()
        {
            _stopWatch.Stop();
        }

        public TimeSpan GetTimeSpendInFrontOfComputer()
        {
            return _stopWatch.Elapsed;
        }
    }
}

All I changed is swapping the class dependency Stopwatch for an interface dependency IStopwatch. That way the class ComputerTimeTrackeris not depending on the class Stopwatch of the .NET framework but loosely coupled to any instance that implements the interface IStopwatch. Now to our biggest benefit:

Unit tests

All dependencies we inject into a class via an interface can be mocked. That is super convenient. Consider the following use case:

• You start the tracking

• You spend 42 hours before the computer

• You stop the tracking

• You check the spend time

Writing a unit test for that use case is hard when the Stopwatch instance gets created inside the constructor of ComputerTimeTracker. You can’t really replace it. And when you can’t replace it you can’t control the Stopwatch . So you would have to wait real 42 hours. With dependency injection you can simply inject a mocked Stopwatch into the class, just for the test.

[TestClass]
public class ComputerTimeTrackerTests
{
    [TestMethod]
    public void Spend42HoursBeforeTheComputer()
    {
        var stopwatch = new Mock<IStopwatch>();
        stopwatch.Setup(x => x.Elapsed).Returns(TimeSpan.FromHours(42));

        var systemUnderTest = new ComputerTimeTracker(stopwatch.Object);
        systemUnderTest.StartTracking();

        stopwatch.Verify(x => x.Start(), Times.Once);

        systemUnderTest.StopTracking();

        stopwatch.Verify(x => x.Stop(), Times.Once);

        Assert.AreEqual(TimeSpan.FromHours(42), systemUnderTest.GetTimeSpendInFrontOfComputer());
    }
}

Conclusion

Dependency injection and inversion of control are important concepts every developer should know. They are a little hyped and often misunderstood. But if you invest some time to really dig into it you see how dumb easy they actually are.

Why are they so hyped at all? For me, it's simply because they enable me to write readable unit tests for my code. That alone sells it for me.

But there are more benefits I did not cover here: Dynamic replacement of dependencies or usage of an IoC-Container. But these are topics for a separate post…

A new perspective

There are lots of links in my head when thinking about testing in software:

• a good test suite indicates good software quality

• a good test suite is a safety net for developers

• a good test suite saves time in the long run

• …

A talk from Daniel Raniz Raneland just added another surprising perspective:

A good test suite prevents you from embarrassment.

The one thing

I think this provides us with valuable insights on the minimun requirements of what to test:

It's the one thing your team/software is responsible for. The one thing that would be totally embarrassing if it didn't function correctly.

• if you develop the software for a snack vending machine, make sure that the doors open correctly.

• if you develop a to-do web app, make sure that to-dos can be ticked

• if you develop a mobile camera app, make sure you can actually take a picture

• …

If the Excel export of your to-do list generates an incorrect file name, users might tolerate it for a while. But if they can't tick their to-dos, they will definitely unsubscribe from your service.

Ticking to-dos is your one thing. Make sure to have that covered completely by the test suite. If starting from scratch, this should be one of the first E2E-tests.

Return of Investments of tests

I like this idea of embarrassment-driven-testing because it relates so well to another new link I noted from a talk by Johannes Stern.

Every single test needs a return of investment (ROI).

You would not invest your valuable money in a project that does not earn you money in the long run, would you? The same is correct for software tests.

We write unit tests because they are cheap and give us a fast response to our changes. This is an instant ROI!

Integration-, API-, and E2E-tests are more expensive. Depending on the quality of the existing code they can be very expensive. But no matter the price, testing your one thing is a necessary investment, not just to prevent embarrassment, but to save your business.

This same thought can also be true from the opposite perspective: Tests can be a bad investment. If your feature is covered by a great E2E-test, do you really need an API-test and integration-test and unit-tests? Or are they just redundant?

Don't get me wrong, I am an advocate for testing and support every test that is written. But testing is about quality and not quantity. Having the ROI in mind, maybe it's time to delete those flaky tests that you spend so much time on debugging every week, while not giving you any confidence when they are finally green.