Parenting · Gaming · Philosophy

One Game at a Time

I remember waiting an hour by the radio for one song.

Not scrolling for it. Not streaming it on demand. Just sitting there, waiting for MTV or the radio to play it, because that was the only way to hear it again.

If I saved up enough, I'd buy the CD.

And that CD was freedom.

It meant I could finally listen to the same song as many times as I wanted.

Games worked the same way.

If I saved up for one, I played everything it had. I found the hidden levels. I tried every mode, every mechanic, every way of playing it. I even attempted speedruns, back when that word barely meant anything outside a small crowd.

Scarcity made me thorough.

My son doesn't have that problem.

He has the opposite one.

Free, paid, pirated — the options are endless. When there's always another game waiting, it's easy to pick something up, play it for a while, get bored, and move on.

Nothing forces you to finish anything.

So I decided something would.

My game library isn't small; I can afford more games. It's small for him on purpose.

Giving him access to everything I own would be easy. But that's not the point.

The point isn't giving him a world of options.

It's asking him to pick one game from the world I've already narrowed down, finish it, and only then pick again.

The whole library. Not that much bigger than it looks.

He doesn't get a new game until the last one is done.

Whether he finishes it well, finishes it fast, or finishes it reluctantly — that's his choice.

But there is no next game until this one is closed.

And it's already paid off.

He finished Hollow Knight.

Then Silksong.

Dante's desktop — Hollow Knight: Silksong still on wallpaper duty.

He went back and fought bosses more than once, not because he had to, but because he wanted to get better at them. He started setting himself challenges nobody asked him to attempt.

That's the part I wanted.

Not that he finished two games.

That he invested enough time in something to become genuinely good at it.

That kind of time investment leaves something behind. Video games can teach this in a simple, contained way that real life usually teaches the hard way:

What you actually invest your time in gives something back.

Sometimes immediately.

Sometimes much later.

But something remains.

That's why my son plays one game at a time.

We don't always get to choose what entertains us in life. More often than we'd like, we have to do things we don't enjoy simply because they need finishing.

I want my son to learn that lesson early, somewhere the stakes are low.

A video game.

Not a job. Not a responsibility he can't walk away from. Not something where failure carries consequences that matter.

Just a game.

If he decides to finish what he starts, and whether he finishes it well or badly, that's his decision to make.

But he won't get to start something new until he does.

And that's also why freemium games aren't part of his library.

Not because they're free.

Because many of them are designed around a completely different relationship with your time. They don't simply ask you to play. They are built to monetize attention — sometimes in ways that resemble the mechanics of a casino more than those of a traditional game.

That's a different kind of hook.

And it's not one I want anywhere near him.

I don't want to teach him that the next thing is always better.

I want to teach him that sometimes, the thing you're already doing is worth staying with.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Read More

Homelab · Networking · Troubleshooting

Chasing the Cheese

The first thing to do today is to chase the cheese, just as a mouse does in a maze.

After going in a circle over a solution which, at first, appeared rather simple.

I had not experienced any serious network problems for more than two months. One morning, while I was quietly having my breakfast, I noticed that the connection had gone down. I then finished my breakfast, had my coffee and went to look at the monitor.

All services were down.

Perfect.

The cheese was located somewhere in the maze.

To begin with, I believed that the internet connection had simply gone down. I looked at the admin computer and found that it wasn't connected to the network. I then restarted the OPNsense server, hoping that it was one of those issues which can be fixed by a restart and some patience.

It didn't work. At that moment I understood that the problem was likely more complicated than it appeared.

There is an emergency procedure specifically for cases like this. I carried out the bypass and, for now, kept the admin computer connected directly to the ISP. The concept was straightforward: ensure that at least the basic functions continued while I worked on discovering what was going on with the main network.

It took about five or six minutes for the bypass to stabilise, but even then the connection was still not behaving properly. There's where the labyrinth started.

Wrong Turn One

The First Problem.

To begin troubleshooting I connected directly to the server.

First mistake.

When I needed to be working on the LAN, I plugged the cable into the WAN port since I was looking for a DHCP problem and so I began to check what was going on in OPNsense.

The console began to provide me with clues, even though none of them appeared to point directly to the issue.

DHCP was down.

When I checked the processes, I didn't see either dhcpd or kea-dhcp4 running; the only one there was the WAN DHCP client.

I used some commands that I had remembered from earlier installations of pfSense.

clog.

It didn't exist.

I attempted the command service dhcpd onestart.

Nothing.

Then service kea-dhcp4 onestart.

Nothing.

Finally, service kea onestart.

The system began Kea.

However, the process stopped right away.

By that stage I began to consider the possibility that I was encountering a known bug in the version of OPNsense that I was using, one that might have something to do with a socket or with a previous process which had become blocked.

I was searching for a solution on the server.

The problem did not lie there.

The Turning Point

The Piece of Information That Changed Everything.

I attempted to log in using SSH.

Timeout.

Not a connection rejection.

A timeout.

I then looked at the network configuration from a different machine and found something interesting: my Wi-Fi was on a different subnet, namely 192.168.1.x, since it was connected directly to the ISP's router through the bypass.

But then I asked a much more basic question:

Did ping ever work?

The answer was no.

Not even directly connected.

The fact about that matter completely altered the diagnosis.

I looked at the server's physical interfaces.

ifconfig igb0

And there it was:

status: no carrier.

There was never any physical connection.

I was just as puzzled by wg0, but it was a virtual interface and had no connection with the physical port.

So I checked igb1.

Here was the problem.

The cable was plugged into the incorrect physical port on the dual NIC.

I repositioned the cable to igb0.

The interface became active.

Ping.

Working.

I reconnected the WAN and checked the connection using 10 out of 10 packets with 8.8.8.8.

Problem solved.

Or so I thought.

The cheese was still dripping.

Wrong Turn Two

The Second Problem.

The network was restored.

It then began to drop every ten or fifteen minutes.

The switch would freeze, and the only fix was to turn it off and then on again.

Once.

Twice.

Three times.

Always the same.

The switch in question was a Linksys SE3008v2, a simple unmanaged switch. It had no interface available, no logs that could be examined, and no straightforward method of finding out what it was doing.

Therefore I began to look at the topology.

I had two switches.

The first held the connected critical infrastructure — OPNsense, the NUC, the NAS, and other equipment.

The second held the office computer and several access points.

You can see a map of the full network layout in this earlier post.

The first idea was simple: what would happen if I take out the first switch?

I could simplify the network temporarily and carry on with just one switch until I received a replacement.

However, there was a problem.

I couldn't remove OPNsense.

I then had to discover what was causing the switch to overload.

Then I saw it.

The lights on the switch were flashing rapidly.

All of them.

This wasn't normal traffic. It seemed as if a tiny green disco had been set up in my office.

All the evidence indicated that there was a broadcast storm.

The Hunt

Isolate the Problem.

I cut the uplink that connected Switch 1 to Switch 2.

Switch 1 settled down immediately.

The loop lived downstream. Now I needed to find exactly where.

I disconnected everything from Switch 2. Only the uplink stayed in place.

Sixty seconds. Nothing.

Ninety seconds. Still nothing.

Switch 2 itself wasn't the problem.

One by one, I started bringing devices back online.

Archer first. Twenty minutes. Clean. It was even serving internet on its own.

Then Linksys02101.

Within minutes, the uplink and Archer's port both lit up — frantic, sustained, the same green disco from before.

Linksys itself stayed almost calm.

I disconnected it.

The storm stopped in seconds.

The cause had a name now: Linksys02101.

I checked its configuration, expecting to find Wireless Bridge mode — the classic mistake, an access point talking to another one over the air while it's still wired into the same switch. Two paths. One loop.

It wasn't that.

Plain Bridge Mode. Correctly set. Exactly as it should have been.

I never found out why.

The Fix

The Solution.

Getting the Linksys off the shared network was the goal — not necessarily figuring out what was actually wrong inside it. I set it up in full router mode: its own subnet, its own DHCP running locally instead of trusting OPNsense's, a unique SSID separate from the shared mesh name, hung off the Tenda instead of the main switch. With NAT in between, it wouldn't matter what mechanism had been causing the loop — there'd be no path left for it to travel back into the rest of the network.

It froze mid-configuration. Not later, not under load — while I was still setting it up.

That settled it. Whatever was actually wrong with that router, reconfiguring around it wasn't going to fix it. It came out of service entirely, replaced for now with a simple wireless range extender — no Ethernet port at all, nothing for it to loop through even if it tried. A real mesh system is already planned for October. Until then, this holds.

The Point

A whole day, and I still don't know why.

Problems like this eat the whole day. Not almost — the whole day; this one didn't wrap up until 6 PM.

It's the kind of thing no tutorial prepares you for. I don't know if formal education ever really does, either. But I trust my contingency plans enough now that leaving the property without internet — even partially — doesn't stress me out anymore, as long as the services that actually matter keep running. Someone telling me "we have no internet" doesn't rattle me. I just tell them to wait, that I'm working on it.

I've gotten good at following a process when something breaks. But some hardware problems look simple at first and turn out to be genuinely hard to pin down — this was one of them. One of the access points, the newest one in the mesh, was quietly bottlenecking the entire network. Incredible, honestly. These are things I don't see coming. Halfway through the day, I was convinced the real problem was the OPNsense server's motherboard.

Realizing that failures like this can happen at the level of any single component means thinking about newer hardware eventually — not urgent, just something to keep moving toward. The goal isn't making sure this never happens again. It's making sure that when it does, the property keeps running while I'm away.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Read More

Automating My Fire Tablet Macrodeck

Homelab · Automation · Quality of Life

Automating the Fire Tablet Dashboard (So I Stop Thinking About It)

The quality of life of the tools I use every day isn't something I'm willing to negotiate on. Throughout this whole process of building a healthy, well-managed network, I've implemented tools I rely on daily — with the catch that I have to keep track of whether I left it on, whether I left it plugged in, or whether, when I sit down to work, I need to charge it first.

More than a technical issue, this is about usability. Getting something to just work automatically usually isn't about skill — it's about taking the time to configure the right solution when the opportunity is already sitting there.

Every new service I add to a well-run network trips the same wire: something has to be started by hand.

The Problem

Two bad options, and neither one respects the hardware.

With this tablet, that meant two bad options. Either I let the screen time out on its own, then plug it back in and wait for it to charge past 2% before I could wake it and reopen MacroDeck. Or I leave it plugged in and awake permanently — and since most of what I repurpose is aging Android hardware nobody wants anymore, permanently-on is its own quiet problem.

The goal was to automate a tool I already use and already trust — not add a workaround for it. Left as-is, the tablet would either be dead when I actually needed it, or slowly wear down hardware that's already past its prime just to stay reachable.

This isn't about being lazy. It's about automating a workflow with tools that are already free and already installed, and keeping the resulting knowledge around for the next device that needs it.

First Attempt

Chasing Windows' own sleep events didn't work.

Of course, none of this was as simple as "enable ADB, add a Windows scheduled task, done." The first version tried to hook directly into Windows' own power events — Kernel-Power Event 42 to catch the system entering sleep, Power-Troubleshooter Event 1 to catch it waking up — firing an ADB script over USB at each transition. Waking worked reliably. Sleeping never did.

The reason took some digging: right as Windows logs that it's entering sleep, the USB controller is already cutting power. The ADB command doesn't have time to complete before the connection dies. It's a race condition against the OS itself, not a misconfiguration — and no amount of tweaking the trigger fixed it.

The Fix

Stop fighting the race. Switch to Wi-Fi, and let a heartbeat do the work.

The fix was to stop trying to win that race. I switched the tablet's ADB connection from USB to Wi-Fi, and let go of the idea that IMPERFECT needed to catch the exact moment it went to sleep. Instead, IMPERFECT sends a simple "still here" signal to the tablet every 58 minutes while it's on. The tablet's own screen timeout is set to 60 minutes. If that signal stops arriving — because IMPERFECT suspended, hibernated, or shut down — the tablet just falls asleep on its own, on Android's terms, with nobody needing to catch the exact moment it happened.

How it works

📶 Wi-Fi ADB — tcpip 5555, no cable needed
💓 Heartbeat — every 58 min while IMPERFECT is on
😴 Timeout — tablet sleeps on its own after 60 min of silence
🔌 Full wake — swipe + MacroDeck, on real resume from sleep

Quick Setup Guide

Get it running on your own tablet.

Requirements: ADB debugging enabled on the tablet, once, over USB

1. Enable Wi-Fi ADB (one-time, over USB)

adb tcpip 5555

2. Disable "stay awake while charging" and set the native timeout

adb shell settings put global stay_on_while_plugged_in 0
adb shell settings put system screen_off_timeout 3600000

3. wake-tablet.bat — full wake, fires on real resume from sleep

adb connect 192.168.2.170:5555
timeout /t 1 /nobreak >nul
adb -s 192.168.2.170:5555 shell input keyevent 224
timeout /t 1 /nobreak >nul
adb -s 192.168.2.170:5555 shell input swipe 300 820 300 205 300
timeout /t 1 /nobreak >nul
adb -s 192.168.2.170:5555 shell monkey -p com.suchbyte.macrodeck -c android.intent.category.LAUNCHER 1

4. heartbeat-tablet.bat — lightweight ping, every 58 minutes

adb connect 192.168.2.170:5555
timeout /t 1 /nobreak >nul
adb -s 192.168.2.170:5555 shell input keyevent 224

5. Two Task Scheduler jobs

One triggered on system resume (Power-Troubleshooter, Event ID 1) running wake-tablet.bat, and one recurring every 58 minutes running heartbeat-tablet.bat — with "start when available" enabled, so a missed cycle catches up the moment the machine wakes instead of getting skipped.

This is tuned for a Fire Tablet running MacroDeck, but the heartbeat pattern works for any always-plugged-in Android device you want to keep reachable without fighting Windows' own sleep timing.

The Point

The simple fix beat the elegant one.

Here's a solution that works — and it feels less like scripting and more like orchestrating: two devices talking to each other cleanly across a network that's already well set up and documented, like a well-run line of dominoes. None of it works without that groundwork already in place.

It's not having to think about turning things on and off, or wondering whether something's charged. This is the first step in automating my workspace — not the last.

What's the oldest device you've kept alive with a script instead of replacing it? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Read More