The Life of J

Tag: Homelab

  • Fixing My Veeam Server (and My Sanity): An Unexpected Backup Adventure

    Fixing My Veeam Server (and My Sanity): An Unexpected Backup Adventure

    In my last homelab misadventure, I wrapped up unable to reach my Veeam server. After a little sulking and a lot of thinking, I decided to nuke it from orbit and just start from scratch. Sometimes trying to patch up old decisions isn’t worth it, especially when you made those choices late at night with one eye closed. 

    Before hitting the big red reset button, I considered all my options. There are plenty of other free backup platforms out there, but Veeam is the one I’m most familiar with, and honestly, it’s a staple in enterprise environments for a reason. The free version lets you back up up to 10 VM’s—which is more than enough for my lab—so sticking with what works made sense. 

    So, I deleted my Veeam VM (JR-VEEAM-01), cleaned up the leftovers, and prepped my trusty Windows Server ISO. Creating a fresh VM in Hyper-V took all of two minutes—this time with a slightly bigger disk, because you can never have too much storage, right? 

    The VM fired up without a single complaint, and the Windows Server install was done and dusted in just a couple of minutes. While it worked its magic, I switched over to my Domain Controller to set up a shiny new Domain Admin account—nothing like a fresh start all around. Once Windows finished installing, I renamed the server to JR-VEEAM-01 and aimed to join it to the domain. Or, well… I tried. 

    Wouldn’t you know it—same domain join error I ran into when setting up my workstation before. Classic homelab déjà vu. 

    Turns out, I’d skipped setting up the network adapter properly. The server was on the right subnet, but the DNS was still pointed at the default gateway. A quick PowerShell session sorted that out: 

    # Assign new IP, subnet, gateway 
    New-NetIPAddress -InterfaceAlias “Ethernet” -IPAddress 10.10.10.7 -PrefixLength 24 -DefaultGateway 10.10.10.1 
     
    # Assign DNS server 
    Set-DnsClientServerAddress -InterfaceAlias “Ethernet” -ServerAddresses 10.10.10.6 

    Just to be sure, I ran a couple of commands to check everything updated as expected: 

    Get-NetIPAddress -InterfaceAlias “Ethernet” 
    Get-DnsClientServerAddress -InterfaceAlias “Ethernet” 

    After patting myself on the back for fixing the adapter, I promptly hit another “oops” moment: I’d only been using the UPN to join the domain, not the proper Domain\UPN format. Turns out, reading prompts helps. Once I logged in correctly, the domain join went through without a hitch. Noice. 

    Once the VM had restarted and settled into its new domain home, it was time for the main event—getting Veeam installed. I headed over to Veeam Software for Enterprise, signed in (pro tip: you’ll need a free account to grab Veeam Backup & Replication), and got the download rolling. 

    With the install file in hand, I mounted the ISO, fired up the setup, and got greeted by the install wizard. Right off the bat, it asked for a license—since I’m using the free community edition, a simple tap of “Next” did the trick. No license key, no stress. 

    Veeam checked my system for missing features and dependencies, offering to install anything needed (which, lucky for me, wasn’t much this time). After that, I kicked back with a cup of tea and about half a pack of biscuits. By the time my mug was empty, Veeam was installed and ready to go. 

    Now for the fun part: cracking open the Veeam console and finally getting into the backup setup. 

    Before I could dive straight into setting up those backup jobs, Veeam put up a window asking if I wanted to register the host—best practice in most cases, so of course, I hit “YES.” This kicked off another wizard to add my Hyper-V host. I punched in the device name, set the type as “Hyper-V Standalone Server,” and plugged in the credentials for the host’s local admin account. 

    Naturally, that’s when I hit an error. (Is it even a homelab setup if you don’t hit a permissions snag or two?) Instead of wrestling with password resets or risking bad security habits, I pivoted to best practices: jumped back on the host and quickly created a dedicated service account called svc_veeam just for Veeam’s use. 

    Back in the Veeam console, I swapped in the new service account credentials. After a quick round of testing and validation, Veeam gave me the green light—the host was now registered and ready for Hyper-V backups! 

    With the host officially registered, I figured it was finally time to set up some backup jobs. I jumped up to the top left, clicked “Backup Job,” and selected “Virtual Machine Backup.” I even gave my job a fancy new name—Hyper_V_Daily—and got ready to pick which VMs to backup… except, weirdly, there were no VMs listed. 

    Not to be outdone by a blank window, I hopped over to Backup Infrastructure, rescanned the host, and tried again. Still nothing. That’s when it hit me: facepalm moment. I’d only added the host itself, not the actual guest VMs. To get those into the mix, I’d need to add them manually—with proper domain admin rights, of course. 

    So off I went to the domain controller to spin up a domain service account just for Veeam. Then, back in the Veeam console, I made my way to Backup Infrastructure, selected “Managed Servers,” and added my other two VM’s—JR-DC-01 and JR-WKS-01—using the same best-practice process. No need to add JR-VEEAM-01 since Veeam was running right there already. In theory, this should have been the breakthrough. 

    But theory doesn’t always translate to practice! When I tried to connect to my test workstation, up popped another error. 

    Well, that sounded like your run-of-the-mill communication issue. Time for some basic troubleshooting: I fired up Command Prompt and tried to ping the workstation—and wouldn’t you know it, zero response. Looks like we found our next issue. 

    So, I hopped over to the workstation and opened up good old Command Prompt to see what was happening. The network settings looked fine: the IP was in the right subnet, and interestingly, the workstation could actually ping the Veeam server without any issues. Okay… so why couldn’t the Veeam server see the workstation? 

    That got me thinking—maybe something was actively blocking the traffic from the Veeam side. A peek at Windows Defender Firewall on JR-WKS-01 revealed that all network profiles—Domain, Private, and Guest/Public—were enabled. For now, I decided to just switch them all off (don’t worry, Group Policy will be handling these rules properly later on). 

    Back at the Veeam server, I tried pinging the workstation again—and bingo, it worked! Sometimes troubleshooting is as simple as flipping the right switch. Simples! 

    With both devices finally talking to each other, I tried adding the workstation once more—and this time, Veeam installed the necessary components without a hiccup. Success! Now all three VM’s were showing up in Veeam, which meant, in theory, I was ready to finally create that daily backup job. 

    Well… not so fast. I went through the steps to set up a new backup job and, yet again, none of my VM’s appeared. At this point, Windows Defender Firewall seemed like the usual suspect—not just on the workstation, but maybe on the host as well. 

    Sure enough, on the Hyper-V host, the firewall was not only enabled, but the network profile was set to “guest” instead of “private.” That’s an easy fix: I opened PowerShell and ran: 

    Set-NetConnectionProfile -Name “JR_Home 2” -NetworkCategory Private 

    Then I disabled Windows Defender for good measure. After another trip back to Veeam and a rescan of the host, I optimistically tried to set up the job once again… and nothing. Still couldn’t see any of the guest VM’s. Weird. 

    Time for some deeper troubleshooting. I double-checked that WMI was working—no issues there. Next, I wondered if the fact that the host wasn’t joined to the domain could be blocking remote management. So, I fired up this command to test connectivity: 

    Enter-PSSession -ComputerName JR-HV-01 -Credential (Get-Credential) 

    And prepared for the next plot twist… 

    Sure enough, the Enter-PSSession command threw an error. At least I was getting somewhere—an error is better than nothing! My first instinct was to simply add the host to the domain, but since this is just a test environment, I’d rather not overcomplicate things. There had to be a workaround, so I dug a little deeper. 

    Good news—there is! You can configure WinRM to work across workgroup or non-domain devices. It takes a little more setup, mostly around adding the Hyper-V host to the list of trusted devices, tweaking authentication settings to use NTLM instead of Kerberos, and enabling remote access. 

    First up, on the host itself, I opened PowerShell and ran: 

    Enable-PSRemoting –Force 

    Super straightforward. Next, I hopped back to the Veeam server and added the host as a trusted device: 

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value “JR-HV-01” -Force 

    Time to test if things were finally communicating. Here’s the kicker—you have to use the default local Administrator account, not just any local admin. That realization cost me a few unnecessary retries. The winning command: 

    Enter-PSSession -ComputerName JR-HV-01 -Credential (Get-Credential) -Authentication Negotiate 

    I logged in as the local admin, ran Get-VM, and at last—Veeam could see the guests! High hopes, back to the Veeam console, rescanned the host, and crossed my fingers. 

    And… still nothing. Turns out, even switching to the Administrator account credentials in Backup Infrastructure didn’t solve it. Every time I thought I’d cracked it, Veeam threw up another “nope.” 

    This produced an error, and while that’s not ideal, at least it gave me something to work with. My first thought was to just add the host to the domain and be done with it, but since this is a test environment, I wanted a cleaner fix. Thankfully, there’s a workaround—WinRM can actually be set up to allow communication across workgroup or non-domain devices. 

    To get this going, I opened PowerShell on the host and ran: 

    Enable-PSRemoting –Force 

    That was an easy win. Next, on the Veeam server, I needed to list the Hyper-V host as a trusted device: 

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value “JR-HV-01” -Force 

    For the real test, I tried to remote in from the Veeam server. Heads-up: this only works if you use the default local Administrator account—not just any account with local admin rights (it took me more tries than I’ll admit to figure that out!): 

    Enter-PSSession -ComputerName JR-HV-01 -Credential (Get-Credential) -Authentication Negotiate 

    With the right credentials, I was able to run Get-VM and finally confirm that the server could see the guests. Back in Veeam, hope surged as I rescanned the host and switched credentials to the Administrator account… but, once again, nada. Even with all the right moves, Veeam still wouldn’t play ball. This homelab adventure wasn’t done with me yet! 

    At this point, we’d tested just about everything—and I started wondering if maybe some old configuration was still causing trouble. So, I did the classic “turn it off and on again,” giving the box a restart. Honestly, I wasn’t expecting much, and sure enough, it didn’t help. Now I was just staring at the Veeam console, fresh out of ideas and starting to dig into research. I even ended up troubleshooting live with ChatGPT. 

    Out of nowhere, something clicked. I thought back to managing replicas in enterprise environments—there’s always a dedicated section for Microsoft Hyper-V under Backup Infrastructure, where you see your host and its guest VMs grouped neatly. Here, none of that. That’s when I figured it was time to revisit the Veeam documentation. 

    And there it was: a crucial detail I’d missed. Before blowing everything away, I thought a reinstall might fix things, so I downloaded the latest ISO and, while it was chugging along, double-checked my Hyper-V tools on the Veeam server with: 

    Get-WindowsFeature *hyper* 

    Turns out, I was missing the Hyper-V management components. Fixing that was simple: 

    Install-WindowsFeature -Name RSAT-Hyper-V-Tools –IncludeAllSubFeature 

    Once Hyper-V tools finished up (and the ISO download was done), I reinstalled Veeam from scratch. But this time, I paid attention to every little detail in the wizard—and that’s where I saw the magic line: 

    “Hyper-V on Windows Client OS is supported only as an Instant Recovery target and for the Data Labs functionality. Host-based backup of VMs running on such Hyper-V host is not supported, but you can use agent-based backup instead.” 

    And there was my answer. If your Hyper-V host is running Windows 10/11 Home, Pro, or Enterprise, host-based VM backups simply won’t work. My lab runs on Windows 11 Pro—it’s my daily driver as well as my server. I was both relieved and frustrated to finally get the explanation! 

    So, where did that leave me? I had two choices: either upgrade my host to Windows Server OS (which felt like overkill for a machine that doubles as my daily driver), or go the Agent Based backup route. Easy decision—the agent method wins. 

    This is where things start to look a little different. Instead of charging ahead with “New Backup,” I went over to Inventory and chose to Create New Protection Group. Since all my VMs play nicely together in the same domain, I went for the Microsoft Active Directory objects option. 

    The wizard guided me through naming the group and picking my domain, which let me see all my lab machines in one place. I selected every VM I wanted to protect and cleared out the default exclusions—don’t need anything hiding from me at backup time. 

    Next, I set it to use the domain Veeam Service account I’d already created, and tweaked the device discovery and agent deployment options. Because my homelab isn’t always online, I decided to have the discovery job run every hour. Maybe a little aggressive, but I’d rather be safe than sorry with my quirky lab uptime. 

    After a quick review, I hit Apply. The group was created, Veeam scanned the devices, and suddenly things were starting to look a lot more promising. 

    Now that the protection group was up and running, it was time for one of the most important pieces: actually picking where my precious backups should live. By default, Veeam wants to save files on the backup server itself—but I had other plans. I wanted my backups sitting pretty on a dedicated SSD in my host, not just anywhere. 

    Setting this up was straightforward. In the Veeam Console, I headed to Backup Infrastructure, selected “Backup Repositories,” and chose “Add Repository.” Since my VM is directly attached to the storage, I selected “Direct Attached Storage” and then “Windows.” From there, it was just a matter of giving my repository a name and making sure the server was set to JR-HV-01, not JR-VEEAM-01. 

    A couple more clicks and I pointed the storage location at my SSD for fast, reliable backup performance. The rest—such as the Mount Server settings—could stay at their defaults. The configuration only took a few minutes, and just like that, my shiny new repository was ready to roll. 

    Veeam prompted me to use this as the default backup location, and since this SSD is where I want all my backups living, I hit yes. On to the main event—setting up the backup job itself! 

    At last, it was time for the main event—setting up the actual backup job. From the protection group I’d just built, I right-clicked, chose “Add to backup job,” selected “Windows,” and then “New Job.” This brought up the now incredibly familiar Veeam wizard. 

    Most of the job options could stay at their safe defaults—I wanted the Veeam Server to handle everything, so I left that set, gave the job a memorable name, and moved on. Since all the computers I wanted to back up were already picked thanks to the protection group, setting those up was a breeze. For max coverage (and peace of mind), I chose to back up the entire machine, not just selected files or volumes. 

    Next, it was time to point the job at the correct storage. I selected the new backup repository on the SSD, left the Guest Processing options untouched, and moved forward to scheduling. Normally, I’d opt for daily backups, but given my lab isn’t always powered on, I set the job to run every two hours instead. A little extra redundancy never hurt, right? 

    With everything ready, I hit apply and finish. But of course, you don’t trust a backup until you see it in action—so I headed back to the Veeam console, found my new job, right-clicked it, and selected “Run Active Full.” Then came the moment of truth: cross my fingers, wait it out… and yes! The backup job completed smoothly, no errors in sight. 

    Success tastes almost as good as that pack of biscuits! 

    And just like that, another homelab saga comes to an end! I’ll admit, this post ended up much longer than I’d planned—but honestly, that’s the beauty of tinkering in a lab environment. You get to stumble, experiment, and actually learn from the process (even if it involves a few extra cups of tea and a mild existential crisis over why things won’t work). 

    So, what did we learn this time around? 

    • Don’t underestimate the value of reading the documentation—especially when it comes to OS limitations! 
    • Network and firewall settings will trip you up more than you expect—always triple check them. 
    • Sometimes, starting over really is the best way to fix a sketchy setup. 
    • And if you’re running Hyper-V on a Windows 10/11 Pro machine, agent-based backups are the way to go. 

    Now, I’ve finally got Veeam backups configured, which gives me the perfect safety net as I launch into new and crazy experiments in the lab. Redundancy: achieved. 

    Thanks for following along with this adventure—and I hope you found the journey (and even the pitfalls) helpful! If you prefer a more streamlined “just the method, no misadventures” style for these posts, or if you actually liked seeing all the real-life troubleshooting and mistakes, let me know in the comments! 

  • Configuring a New Domain for the Homelab

    Configuring a New Domain for the Homelab

    If you spend any time lurking in homelab forums like r/homelab, you’ll see one piece of advice come up over and over: set up your own Active Directory domain as soon as possible. A domain controller gives you centralized account management, lets you enforce policies and settings across devices, and is a launchpad for way more advanced IT projects down the line. Honestly, it’s like the backbone of a real enterprise network, just shrunk down to fit in the spare room.

    Truthfully, it’s something I should have done right after turning my old gaming rig into my first server. But, at the time, I just wanted to tinker with whatever caught my interest—I didn’t have a plan. Even though I work with Windows Server all day, I’d never walked through the full domain controller setup on my own from scratch. The closest I’d come was poking around with the Certificate Authority role, mostly by blindly following a how-to!

    So, today was finally the day. I put on my “ITIL brain” (yes, it haunts me even at home), spent a few hours researching and documenting each step so Future Me can fix whatever I break, and sat down to spin up a shiny new virtual environment. My plan was simple: deploy a Windows Server 2022 domain controller, create an external virtual switch so it could actually talk to other devices, set up a Windows 11 Pro workstation to test future GPOs (and break things safely), and prep my trusty Veeam server to join the new domain. This post is more of a behind-the-scenes walkthrough than a step-by-step guide—but don’t worry, I’ll link to my documentation at the end for anyone who wants to try it out.

    Getting Set Up: ISOs and Virtual Switches

    First up: downloading the tools. Microsoft makes it easy—just hop onto their Evaluation Center, grab the Windows Server 2022 ISO, and you’re good for 180 days (or up to 1080 days if you get creative with re-arms). Luckily, I already had a Windows 11 ISO on hand, but for anyone who doesn’t, here’s the official link.

    Windows Server 2022 Evaluation ISO – Can be downloaded from here

    While the server ISO downloaded, I headed into Hyper-V Manager to set up a new external virtual switch—essential for letting the VMs talk to other devices across my network. With the switch prepped, the ISO finished up just in time for the next phase: creating the actual domain controller VM. I gave it a minimal but adequate spec (4GB RAM, 60GB disk), knowing I can always bump things up if I need to down the road.

    While the server ISO downloaded, I headed into Hyper-V Manager to set up a new external virtual switch—essential for letting the VMs talk to other devices across my network. With the switch prepped, the ISO finished up just in time for the next phase: creating the actual domain controller VM. I gave it a minimal but adequate spec (4GB RAM, 60GB disk), knowing I can always bump things up if I need to down the road.

    Installing Windows Server and Basic Setup 

    Watching JR-DC-01 pop up in Hyper-V was weirdly satisfying. I fired it up and started the server install, making sure to select the “Desktop Experience” option—no command-line only installs for me this time! After a quick custom install on my fresh disk, Windows Server was running in just a few minutes.

    From here it was all about the admin basics: creating a strong password, running updates (which took forever—thanks, Microsoft!), and then popping into my firewall to check which IPs were free outside my DHCP pool. Once the server was up to date, I set a static IP so everything on my network stays predictable. 

    Adding the AD DS Role and Promoting to Domain Controller

    With my new admin account set up and Windows fully updated (why do server updates always take so long?), I got ready to configure the server’s static IP. A quick check of my firewall showed which addresses were free outside the DHCP pool, so I set up a neat static IP for the new domain controller—no surprises with DHCP changes down the road.

    With networking sorted, I dove into Server Manager to tackle Active Directory. Installing the AD DS (Active Directory Domain Services) role turned out to be refreshingly simple: just click on “Manage,” choose “Add Roles and Features,” and select Active Directory Domain Services from the list. During the prerequisite screen, I deliberately left the DNS Server role unchecked—my UniFi firewall already handles DNS and I figured, why make things more complicated? (Spoiler alert: More on that later!) The installation zipped by in less than a minute.

    Next up was promoting the server to a domain controller, the real heart of this whole exercise. The wizard was straightforward: I selected “add a new forest,” plugged in jr-network.local as my root domain name. After a few prerequisite checks, I hit “Install” and let Windows do its thing. After a quick reboot, I saw that familiar domain sign-in screen pop up. That first log-in with your shiny domain admin credentials feels pretty great—domain admin power, officially unlocked.

    Setting Up the Testing Workstation 

    With the domain controller sorted, it was time to spin up a guinea pig: a Windows 11 Pro VM (4GB RAM, 64GB disk), with TPM enabled to make Windows 11 happy. The install was mostly straightforward, but here’s where I hit my first snag: Microsoft really, really wants you to use a Microsoft Account, opt in to every privacy setting (ironic), and subscribe to Game Pass and Office 365 along the way. I pressed “skip” so many times I started to think Skynet was judging me. 

    A small slip-up had me accidentally set up the device as “home,” but after sorting that, I logged into Windows and set about joining the workstation to my shiny new domain—until, of course, I ran smack into an error. Despite double-checking the spelling, network, and connectivity (all fine), it just wouldn’t join. 

    Oops, You Really Do Need DNS… 

    Classic learning moment: turns out, AD domain joins rely on DNS, and I’d skipped installing the DNS Role on the DC. Time for a quick detour—back to Server Manager, enable the DNS Server role, fast-forward through setup, and voilà: DNS was operational. After a DC reboot, domain join worked first time. Gotta love it when a fix is that clean. 

    The Not-So-Simple Part: The Veeam Server Saga 

    With my domain and test workstation finally communicating happily, I turned my attention to reconfiguring JR-VEEAM-01 to join the domain… only to find it was powered off and refusing to start. Because of course it was. I opened up the console and, instead of a login screen, got hit with a fresh error. Homelabbing, am I right? If you ever think everything’s going to go smoothly, the universe sends you a quick reminder. 

    Instead of squeezing that fix into this (already long) post, I’ve decided to save the Veeam adventure for next time. That’ll include troubleshooting whatever is going on, getting it attached to the domain, and setting up proper backup jobs for both the new domain controller and workstation. 

    Lessons Learned & The Road Ahead

    Today, I managed to get a domain controller up and running, deploy Active Directory Domain Services and DNS, and prove out the basics of account and policy management on a test workstation. Even with a few detours, it’s been a solid step forward—and proof that you don’t need a complicated lab to learn real enterprise skills.

    If you’ve read this far, thanks for sharing in my victories (and commiserating in my “facepalm” moments). I hope this gives you the confidence to try setting up your own domain, or at least assures you that bumps along the way are all part of the process. If you want a copy of my detailed documentation or want to see a deep-dive on any step, let me know in the comments!

  • My Current Homelab Setup—and Where I’m Headed Next 

    My Current Homelab Setup—and Where I’m Headed Next 

    Over the past couple of months, I decided it was time to give my old gaming PC a new purpose. These days, I rarely find time to game, so I’ve been looking for ways to get hands-on with something fresh—enter the world of self-hosting. With so much tech shifting to the cloud, I’m eager to see how much I can do on my own, just for the sheer challenge and the chance to learn something new. Of course, the added perk of keeping more control over my own data doesn’t hurt (and no, I’m not a tinfoil hat conspiracy theorist!). For me, it’s about getting curious, gaining new skills, and taking a bit more ownership in an increasingly invasive digital world. 

    The Setup So Far

    My UniFi networking kit and repurposed gaming PC

    Right now, my homelab setup is simple but solid—a great foundation to build on. One of my first moves was ditching the default ISP router for a UniFi networking stack, mainly so I could finally create multiple VLANs and take advantage of built-in IDS/IPS security features. My network now consists of a UniFi Gateway Max, an 8-port Ultra 60W PoE switch, and two U6+ access points, which gives me robust wireless coverage and dedicated networks for personal devices, IoT gadgets, and guests. Everything feels so much more organized—and a lot more secure—since making the switch. 

    At the heart of my platform is a repurposed gaming PC, now doing duty as a Hyper-V server. It’s powered by an 8-core Ryzen 7 2700X, 32GB of RAM, a GTX 1080ti, and about 1.75TB of storage cobbled together from a 500GB NVMe SSD, a 1TB and a 500GB SATA SSD, plus a 1TB HDD. At the moment, it’s mainly running a single VM for Veeam backups, leaving me with plenty of room (and plans) for launching new projects. Alongside that, I’ve got a Home Assistant Green running my smart devices, and a Raspberry Pi 2 Model B that’s been collecting dust—just waiting for me to get more hands-on with Linux in the near future. 

    Where I’m Headed Next: Big Plans and New Experiments

    So, where does all this leave me? In short, I want to see just how much I can self-host—and how far I can push my Home Assistant setup. There’s something rewarding about having full control and actually building out the digital tools I use every day. 

    Here’s what’s on my list: 

    • Build and configure a NAS: I’m aiming to create a reliable, expandable storage solution for all my files, backups, and media.
    • Self-host my own cloud storage: Tools like NextCloud and Seafile are at the top of my list for keeping my documents, photos, and calendar in sync—without relying on the big clouds.  
    • Migrate my password manager: I’d like to move everything over to a self-hosted Bitwarden instance. 
    • Set up Plex or Jellyfin: Centralized media storage: each has its pros and cons and I’m not set on what one I’ll go with, but its high up on the list of priorties 
    • Create a VPN: Secure remote access (and the ability to safely share content with friends and family) is a must-have. 
    • Host my own website & try running an AI model: I want to try hosting my own site—and maybe experiment with my own locally hosted AI model 
    • Run my own email server 

    Home Automation

    My basic Home Assistant Dashboard – Out of the box with the Tuya integration configured for managing lights and aircon

    My interest in home automation has really taken off since discovering Home Assistant. Right now, I’ve got a growing pile of smart devices scattered around my house, each with its own app and login. One of the best things about Home Assistant is finally being able to control everything from a single dashboard—no more toggling between a dozen apps just to turn off the lights and lock the door. The platform’s flexibility is wild; I can even pull data from my car, and the potential for custom dashboards and automations is almost endless. 

    I’ve only just dipped a toe into this world, and so far I’ve got the integrations setup for my smart bulbs and air con unit. I’ve repurposed an old Galaxy Tab A that I’m using as a dedicated dashboard to manage these for the time being as a bit of a proof of concept. Once I’ve got a stable platform with more integrations setup, and had made some progress on a custom dashboard then I’ll look to upgrade this to something a bit more sleek. I’d like to get one for each floor too and have them wall mounted with either magnetic wireless chargers, or wired in if I can’t get that to work.

    The Ultimate Smart Dashboard

    One of my big goals is to design and build a dashboard that puts everything I care about front and center—true “mission control” for my home. Here’s what I want it to show and do:

    • Live electric, gas, and water usage, with clear graphs 
    • Family calendar and running to-do list 
    • Weather forecasts and advance commute times (based on our phones’ locations) 
    • Controls for lighting, music, and smart speakers everywhere in the house 
    • Real-time feeds from my CCTV cameras 

    Building the Perfect Setup

    My future plans include building a tidy rack to house all my networking gear, the NAS, and my Home Assistant Green—with room for a small display screen to monitor performance metrics in real time. On top of that, I’m planning a big “smart migration” for my house: upgrading to a smart meter, switching over to smart heating, and replacing all the lighting with gear that seamlessly integrates with Home Assistant. And, for a bit of fun, I’m also interested in building a magic mirror—something that would display the weather, calendar, and news while I brush my teeth. 

    As I work through these upgrades and projects, I’ll be documenting each step, sharing what I learn, and inviting you along for the ride. There’s plenty to build, break, and (hopefully) improve—so if you’re into homelabs, tech, or just enjoy a good experiment, stay tuned!