Rack 2 Reality

Tag: geofencing

  • The Smart Home Automations I Actually Use

    The Smart Home Automations I Actually Use

    It has been a few months since my last post. Life has been busy, and although I have continued tinkering with things at home, I haven’t had much time to sit down and write about any of it.

    That has at least given me an opportunity to see which of my smart-home automations remain useful after the initial novelty has worn off. I enjoy experimenting with Home Assistant, sensors and networking, but I don’t want to automate something simply because I can. The better automations are the ones I gradually stop noticing.

    My setup is not especially complicated, and it certainly isn’t finished. Some parts run through Home Assistant, others remain in the SwitchBot app, and at least one motion sensor continues to make me question my choice of hardware.

    Arriving home after dark

    One of my more useful automations is also one of the simplest. When either of us arrives home after dark, Home Assistant turns on the entrance light along with the main living-room lights.

    The automation watches the device trackers for our phones and triggers when either one changes to home. Before switching anything on, it checks the illuminance reading from the SwitchBot Hub 2. If the reading is below 70 lux, the entrance light, living-room light and globe light are switched on.

    The entrance light turns itself off again after five minutes, while the living-room lights remain on. This gives us enough time to get inside and put everything down without leaving the entrance illuminated unnecessarily.

    Home Assistant YAML automation that turns on the entrance and living-room lights when someone arrives home after dark
    Home Assistant checks whether either of us has arrived home and uses the Hub 2’s illuminance reading to decide whether the lights are needed.

    The light level check is important. A time-based condition would be easier, but sunset does not necessarily mean the house is dark. Weather, curtains and the time of year all affect the amount of light inside, so using the actual illuminance reading produces more consistent results.

    There are also a few smaller automations built around the same idea. Lights can switch off after a delay, and presence conditions stop certain routines from running in an empty house. None of these is particularly impressive by itself, but together they remove several small jobs from the day.

    Making geofencing work remotely

    The awkward part of the arrival automation was not controlling the lights. It was making sure Home Assistant could receive reliable location updates while I was away from home.

    Home Assistant is not exposed directly to the internet, and I would prefer to keep it that way. Instead, I use Tailscale to provide a secure connection back to my home network. This allows the Home Assistant companion app on my phone to communicate with the server remotely without requiring me to open ports on the router.

    Once Tailscale was configured correctly, presence detection started working reliably while I was away. It has been largely uneventful since then, which is exactly what I want from the networking underneath an automation.

    There can still be a slight delay before a phone reports that it has entered the home zone, so I would not use this arrangement for anything where a few seconds really matters. For turning on lights as we arrive, however, it has been dependable enough.

    Keeping the living room comfortable

    Summer temperatures here regularly reach the mid-to-high 30s, so keeping the living room comfortable is less of a luxury than it might sound. I normally aim for approximately 27°C with humidity around 60%.

    The SwitchBot Hub 2 already measures and displays the temperature and relative humidity, so I use those readings as part of a climate automation. When motion is detected in the living room, the automation checks that I am at home and that the room is both above 27.5°C and above 60% relative humidity.

    If all of those conditions are met, the air conditioner switches on in its automatic dry mode and the Switchbot circulator starts moving air around the room.

    SwitchBot automation using presence, living-room motion, temperature and humidity to control the air conditioner and circulator
    The SwitchBot automation checks presence, motion, temperature and humidity before switching on the air conditioner and Switchbot circulator.

    This is particularly helpful when I am working from home. The temperature tends to rise gradually, and I often do not notice until the room has already become uncomfortable. The Hub 2 can react before I reach the point of abandoning whatever I am doing to find the remote controls.

    The automation also avoids cooling an empty room. Presence confirms that I am home, while the living-room motion sensor provides a reasonable indication that the room is actually being used. It is not sophisticated room-presence detection, but it is sufficient for this purpose.

    This climate automation currently runs through the SwitchBot app rather than Home Assistant. The Hub 2 can control the air conditioner using infrared, and the Switchbot circulator is available through SwitchBot as well, so Home Assistant would add another layer without providing much benefit.

    I like having everything visible in Home Assistant, but I no longer think every automation has to run there. If a manufacturer’s local setup can perform a straightforward task reliably, I am happy to leave it alone. Home Assistant is most valuable when I need to combine devices and information from different systems.

    The troublesome hall motion sensor

    The hall automation is probably the weakest part of the current setup. Its job is straightforward: detect movement, turn on the hall light when it is needed, and turn it off again after a delay. In practice, the SwitchBot motion sensor was not always reporting movement reliably.

    The Bluetooth signal was the obvious problem. At its worst, the sensor was reporting approximately −99 dBm, which is extremely weak. At that level, missed or delayed updates were not particularly surprising.

    After changing the sensor battery and adjusting the placement, the signal improved to just under −80 dBm. That is a substantial improvement, although both changes happened at roughly the same time, so I cannot say with confidence how much each one contributed.

    The automation is behaving better now, but −80 dBm still leaves room for improvement.Walls, furniture and the position of the sensor relative to the TP-Link Bluetooth adapter all affect reception, and a motion sensor needs to report quickly if it is going to control lighting without becoming irritating.

    This is why I am still considering replacing the SwitchBot motion sensors. They are convenient and work well with the rest of the SwitchBot equipment, but the hall has exposed the limitations of relying on a weak Bluetooth connection. A Zigbee-based sensor, or another device with better local coverage, may eventually be a more dependable choice.

    I am not rushing to replace anything while the existing sensor is working, though. For now, I am monitoring the signal and seeing whether the battery and placement changes continue to make a difference.

    Keeping the setup practical

    The current arrangement is a mixture of different approaches. Home Assistant handles the arrival automation because it needs presence data, illuminance readings and lights from different parts of the system. Tailscale provides remote access without exposing Home Assistant publicly. SwitchBot handles the climate automation because it already has everything required to measure the room and control the appliances.

    That mixture is less tidy than forcing everything into one platform, but it has proven more practical. Centralising a device in Home Assistant is useful when it creates new possibilities. Doing it purely for the satisfaction of having another entity on a dashboard can create more work without making the house any better to live in.

    Reliability matters more to me now than the number of automations I can list. A basic light automation that works every evening is more valuable than an elaborate routine that needs regular attention. The hall sensor has been a useful reminder of that.

    Hardware behind my setup

    As an Amazon Associate I earn from qualifying purchases. Some links below are affiliate links, which help support the site at no additional cost to you.

    The main hardware used across my smart home and Home Assistant setup includes:

    • UGREEN NASync DXP2800 — my two-bay NAS and the machine running Home Assistant in Docker. Read my review here.
    • TP-Link UB500 Bluetooth 5.0 Nano USB Adapter — connected to the UGREEN NASync DXP2800 to give Home Assistant local Bluetooth access to nearby devices.
    • UGREEN US3000 UPS — protects the NAS and Home Assistant installation against sudden power loss.
    • SwitchBot Hub 2 — measures temperature, humidity and illuminance while also controlling the air conditioner.
    • SwitchBot Motion Sensor — used for motion-based lighting and living-room detection.
    • SwitchBot Circulator Fan — automatically circulates cool air when the living-room climate automation runs.
    • Philips Hue Bridge — connects the Philips Hue lighting system to Home Assistant.
    • Philips Hue smart bulbs — used for the entrance and living-room lighting automations.
    • SwitchBot Outdoor Camera — part of my wider smart-home monitoring setup.
    • AAA batteries — useful spares for the SwitchBot motion sensors, particularly when troubleshooting unreliable readings.

    Where I’ve landed

    None of these automations is especially dramatic. Lights come on when we arrive home, the living room cools down when it becomes hot and humid, and the hall light responds when somebody walks past. That is also why they have remained useful.

    For now, I am happy when the lights come on before I reach the switch and the living room starts cooling down without me having to think about it. The hall sensor is behaving better at just under −80 dBm, although I still haven’t ruled out replacing it.

    That is probably the reality of my smart home: it is never completely finished, but it is gradually becoming more useful.

  • How to Access Home Assistant Remotely with Tailscale on a NAS (No Port Forwarding Required)

    How to Access Home Assistant Remotely with Tailscale on a NAS (No Port Forwarding Required)

    One of the biggest things I wanted after setting up Home Assistant was reliable remote access.

    At first, I assumed this would be simple. Install Home Assistant, install the mobile app, sign in remotely somehow, and that would be the end of it.

    The deeper I got into self hosting though, the more I realised remote access is one of those areas where things become complicated surprisingly quickly. Every guide seemed to recommend something different, from opening ports on the router to setting up reverse proxies, SSL certificates, Cloudflare tunnels and domain names.

    None of those things are inherently bad, but when you are still building your understanding it becomes difficult to know what is actually necessary and what is just adding complexity.

    There was another factor as well: subscriptions. I completely understand why Home Assistant Cloud exists and for many people it is probably the right solution. But like a lot of people these days, it feels as though everything wants a monthly fee.

    I was not trying to avoid spending money entirely. I just wanted to see if I could achieve reliable and secure remote access using the hardware and software I already had, without exposing Home Assistant directly to the internet while I was still figuring things out.

    That is what led me to Tailscale. It gave me a way to get remote access working without turning it into a much bigger networking project.

    My setup

    For reference, this is the setup I am currently running.

    The NAS itself is a UGREEN NASync DXP2800 running Docker containers for both Home Assistant and Tailscale. If you’re interested in the hardware itself, I covered my experience in my  UGREEN NASync DXP2800 Review After 2 Months.

    There is no port forwarding, no reverse proxy, no public Home Assistant exposure, and no Home Assistant Cloud subscription.

    That probably sounds restrictive at first, especially if you spend enough time reading forums where people are building very advanced setups. But honestly, that was exactly the point.

    Despite working in IT, I did not want this to become a project that required constant maintenance. I wanted something that was secure, made sense, and just worked day to day without needing to be constantly revisited.

    Just because a solution is more advanced does not automatically make it better for your situation. For me, the goal was not to build the most complex setup possible. It was to build one that was secure, reliable, and easy to live with long term.

    That is what pushed me towards Tailscale.

    Why I chose Tailscale

    The biggest reason was simplicity, not because the alternatives were beyond me, but because I was trying to solve a specific problem rather than build a networking project.

    There are plenty of ways to provide remote access to Home Assistant. You can use reverse proxies, SSL certificates, Cloudflare tunnels, domain names, port forwarding and various other combinations depending on how much control you want.

    The problem is that every additional layer becomes something else to configure, secure and maintain.

    For some people that is part of the hobby, and there is nothing wrong with that. For me, the goal was simply to access Home Assistant securely when I was away from home.

    Tailscale felt like a very clean solution to that problem. Instead of exposing Home Assistant publicly and then protecting it afterwards, it creates a private encrypted network between devices you already trust.

    In practice, that meant my phone could communicate directly with my NAS without Home Assistant ever being exposed to the public internet.

    That shift in approach made everything much easier to reason about. I was not publishing a service and securing it, I was extending a private network.

    For a home setup, that balance between simplicity, security and reliability was hard to ignore.

    The benefit I was not expecting

    When I first started looking at remote access, I was focused almost entirely on Home Assistant. The goal was simply to be able to open dashboards and make sure automations worked when I was away from home.

    What I did not really think about at the time was that I was solving a much bigger problem.

    Once Tailscale was working, Home Assistant was only one of the things I could access remotely. I also had other services running on my NAS, including my Recipe App and Home Dashboard. Several of these are applications I discussed in my  Docker Containers I Still Use One Year Later article, and Tailscale effectively gave me secure remote access to all of them at the same time.

    That was the point where it clicked. Tailscale stopped feeling like a Home Assistant tool and started feeling like part of the underlying infrastructure of my home network. The more services I added locally, the more useful it became.

    The Home Assistant benefits were still significant. Presence detection became more reliable, location updates worked more consistently, and geofenced automations behaved the way I expected them to.

    But the bigger takeaway was that I only needed to solve remote access once. Every service I run now, and anything I add in the future, can use the same setup.

    Before you start

    This guide assumes you already have Home Assistant running and accessible on your local network.

    If you are starting from scratch, make sure you can access Home Assistant locally first, for example:

    http://192.168.x.x:8123

    Do not move on until this works reliably. Otherwise you end up troubleshooting multiple things at once.

    Checking Home Assistant locally

    Before adding Tailscale, confirm Home Assistant is actually listening on port 8123.

    sudo ss -tulpn | grep 8123

    You should see Home Assistant (usually as python3) listening on that port. If not, fix that first.

    Installing Tailscale in Docker

    Tailscale running as a Docker container on a UGREEN NAS alongside other self-hosted applications.
    Tailscale running as a Docker container on my UGREEN NAS.

    Install Tailscale as a Docker container on your NAS.

    docker pull tailscale/tailscale:latest
    docker run -d \
      --name=tailscale \
      --hostname=nas \
      --network=host \
      --cap-add=NET_ADMIN \
      --cap-add=NET_RAW \
      -v tailscale-data:/var/lib \
      tailscale/tailscale:latest

    Check the logs to get the authentication link:

    docker logs tailscale

    Open the URL shown, sign in, and approve the device.

    Make sure to click this link right away, as Tailscale login URLs expire after a few minutes. If it has expired, simply restart the container or re-check the logs to generate a new one.

    Note: In this example, Tailscale stores its configuration in a Docker named volume called tailscale-data. If you prefer to keep your container data in a specific folder for easier backups or management, you can replace the named volume with a local path that suits your environment.

    For example:

    -v /path/to/tailscale-data:/var/lib

    The exact location will depend on your operating system, NAS, or Docker setup.

    Verify the connection:

    docker exec -it tailscale tailscale status

    Setting up Tailscale on your phone

    Tailscale mobile app showing connected devices and assigned tailnet IP addresses.
    The Tailscale app lets you confirm your devices are connected and quickly find your NAS Tailscale IP address.

    Installing Tailscale on the NAS is only half of the setup. You also need it running on the device you actually want to connect from, which in my case is my iPhone.

    Download the Tailscale app from the App Store and sign in using the same account you used to authenticate the NAS. Once signed in, your phone will appear in your Tailscale admin console alongside your NAS.

    At that point, your phone is part of the same private network. Your phone is no longer “connecting into” your home network, it is effectively part of it.

    One useful thing is that the Tailscale app shows all connected devices and their assigned IP addresses. That means you can quickly check your NAS Tailscale IP directly from your phone without needing to SSH in.

    This is useful when setting things up or troubleshooting because you can confirm:

    • your NAS is online
    • your phone is connected to the tailnet
    • the correct Tailscale IP is being used

    Finding the Tailscale IP

    Get the Tailscale IP:

    docker exec -it tailscale tailscale ip -4

    You will get something like:

    100.x.x.x

    Use that to access Home Assistant remotely:

    http://100.x.x.x:8123

    This uses HTTP, not HTTPS. Tailscale already encrypts the connection, so forcing HTTPS here will break things.

    Configuring the Home Assistant Companion App

    Home Assistant Companion App server settings showing internal and external URL configuration.
    Directly after “Configuring the Home Assistant Companion App” and before you explain Internal vs External URLs.

    In the Home Assistant Companion App, you need to set the Internal URL and External URL.

    On iPhone, open the app and go to:

    Settings → Companion App → Server Settings

    (If you have multiple servers configured, tap your server first, then open Server Settings.)

    Use your local IP for Internal URL:

    http://192.168.x.x:8123

    Use your Tailscale IP for External URL:

    http://100.x.x.x:8123

    Both should use HTTP. Tailscale already encrypts the connection, so you do not need HTTPS here.

    Once set, back out of the menu and give the app a few seconds to reconnect. If everything is correct, it should connect both on WiFi and over Tailscale without any errors.

    VPN On Demand on iPhone

    One thing I highly recommend enabling is VPN On Demand inside the Tailscale app.

    Enable it for both WiFi and cellular so the connection is automatic. That way you do not need to remember to manually connect before opening Home Assistant.

    This makes the whole setup feel much more seamless day to day and also improves reliability for things like presence detection and geofenced automations because your phone maintains a consistent connection back to Home Assistant.

    The issue that caused the most confusion

    The biggest problem I hit was not Home Assistant. It was Tailscale Serve taking over port 8123.

    sudo ss -tulpn | grep 8123

    If you do not see Home Assistant on that port, something else has taken it.

    Fix it with:

    tailscale serve reset

    Hardware I Use

    Before I wrap up, a quick note: some of the links below are Amazon affiliate links. If you choose to purchase through them, I may earn a small commission at no additional cost to you. I only recommend products I personally use or have hands-on experience with.

    The software in this guide is free, but if you’re curious about the hardware behind my setup, this is what I currently use:

    I’ve been using this setup for Home Assistant, Docker containers, remote access through Tailscale, and various self-hosted projects. If you’re building something similar, these are the components I have the most hands-on experience with.

    Final thoughts

    Tailscale ended up being one of the most useful additions to my setup, not because it was flashy, but because it removed friction.

    Once it was configured, I stopped thinking about remote access entirely. Combined with a stable home network, which I discussed in  What Actually Happens on Your Network (Why WiFi Feels Inconsistent), it became one of those rare pieces of infrastructure that simply fades into the background and does its job.

    There are more advanced ways to achieve the same result, and for some setups they will make sense. But for me, this struck the right balance. It solved the problem I actually had without introducing more moving parts to maintain.

    Looking back, that was the biggest win. Not just remote access, but a simple foundation I can keep building on without having to rethink it every time I add something new.