The Raspberry Pi That Lives in India

The Raspberry Pi That Lives in India

Building a remote home setup between the UK and India, with a little help from Claude.

I live in the UK, but I still have a home in India. Being thousands of kilometres away means I can't just walk over to a device, check a cable or restart something whenever there's a problem.

That's one of the reasons I decided to build a setup around a Raspberry Pi.

It's a Raspberry Pi 5 with 2GB of RAM, a 500GB NVMe drive and Raspberry Pi OS Lite. It sits at my home in India and runs around the clock.

There's nothing particularly impressive about the hardware itself. But over the past few months, I've turned it into a useful part of my home network, helping me stay connected to India while managing other systems from the UK.

The interesting part isn't just what the Pi does. It's how I built the setup, the problems I ran into along the way, and how Claude helped me work through them.

What I Wanted to Achieve

I wanted a reliable way to connect to my home network in India, monitor services running in the UK and access my CCTV system remotely.

I also wanted to avoid unnecessary complexity. There was no point streaming several cameras across the internet all day when I only needed the video occasionally.

The plan was to let each device do what it was good at. The Raspberry Pi would handle networking and a few background services, the CCTV recorder would manage detection locally, and Home Assistant in the UK would handle the automation side.

It sounds straightforward when written down like that. Getting all the pieces to work together took a little more effort.

How Everything Fits Together

The Raspberry Pi is the always-on machine at the India end. Tailscale connects my devices across the two locations, giving me secure remote access without having to expose every device directly to the public internet.

The Pi also acts as a Tailscale exit node, allowing me to route internet traffic through India when needed. Subnet routing provides access to devices on the Indian home network.

At the UK end, Home Assistant runs on a separate PC. This is where the CCTV integration comes in.

My Hikvision DVR handles detection locally, including motion and human/vehicle detection, along with face capture. It sends ONVIF events to Home Assistant over the Tailscale connection.

The important thing here is that the DVR does the detection itself. I don't need to send five camera feeds to the UK continuously just to find out whether something has happened.

When I need to view a camera, the video can be pulled over RTSP on demand. This keeps the normal setup lighter on bandwidth while still allowing me to access the footage when needed.

It suits my situation quite well. The cameras and recorder stay in India, while Home Assistant can receive events and use them for automations in the UK.

A Few More Jobs for the Pi

The CCTV connection is only part of the setup.

I've also configured AdGuard Home to filter unwanted advertising and tracking domains through DNS. Unbound sits behind it as a recursive resolver, looking up DNS records through the hierarchy rather than relying entirely on a third-party DNS resolver.

The configured DNS chain works with Tailscale, AdGuard Home and Unbound together. Getting that arrangement right took some troubleshooting, particularly when dealing with connectivity and resolver timeouts.

There are a few other tools running on the Pi as well.

Cockpit provides a web interface for system administration, Glances lets me check resource usage, and log2ram helps reduce routine log writes to the storage drive.

I can keep an eye on CPU usage, memory, storage, temperature and network activity without needing to connect a monitor to the Pi.

Most of the time, the resource usage is low. That's one of the advantages of using a small computer for jobs like these.

It Took a Few Months to Get Here

This wasn't a project I finished in a weekend. It developed gradually as I worked through the network configuration and tested different parts of the setup.

Back in early June, I started with a pre-move audit. I checked DNS, reviewed the firewall configuration, tested the Tailscale connection to Home Assistant and looked into internet connectivity options for India.

One of those tests recorded latency of around 11.7 ms to Home Assistant. It was a useful early result, although it was only a snapshot of the connection at that time.

By July, I'd settled on the approach for the CCTV integration. The DVR would detect events locally, Home Assistant would receive ONVIF notifications, and RTSP video would be accessed only when required.

In early August, I got the Pi back online in India and restored the DNS setup. A few days later, I worked through the network configuration during a live session and changed the subnet to 192.168.2.0/24. That resolved the addressing issue and made the DVR reachable again.

By late August, just before I returned to the UK, the setup had developed into a working combination of remote access, subnet routing, DNS services and CCTV integration, with motion and human/vehicle filtering configured.

Looking back, much of the work wasn't about installing software. It was about getting the different pieces to communicate properly.

Working Through Problems With Claude

I used Claude as a pair-debugging partner throughout much of this project.

We worked through the architecture in conversation, including the Tailscale setup, the ONVIF event flow, the on-demand video approach and the DNS chain.

Claude helped me work through the installation using step-by-step command-line instructions and web-interface guidance. I'd connect to the Pi over SSH, run a command and share the output. We'd then look at the result and decide what to try next.

Not everything worked first time.

We ran into a subnet conflict, a problem with the DVR's static IP configuration and a timeout involving AdGuard Home and 127.0.0.1.

Instead of guessing, we used the command output to narrow down the problems and work through them one at a time.

Claude also helped me think through hardware choices, including whether a 6mm lens would be suitable for the gate camera at a distance of around 15–20 metres.

One important point: Claude didn't have direct access to my Raspberry Pi, DVR or router. It couldn't make changes to those devices itself. I carried out the commands and configuration changes, then shared the results so we could continue troubleshooting.

The India session was handled remotely over the phone, with me coordinating the work on site.

For me, this was a useful way to approach a project with several interconnected parts. I could make a change, test it and understand what had happened before moving on.

When the Pi Went Offline

On the evening of 20 October, the Raspberry Pi suddenly disappeared from the network.

Remote access stopped working, and the monitoring services running on it became unavailable. For just under two hours, I couldn't reach the machine that helped connect my two locations.

Eventually, it came back online. The signs suggested that it had restarted, so a local power interruption was the most likely explanation. I couldn't confirm the exact cause from the UK.

The outage also exposed something I needed to improve in my monitoring dashboard.

Some indicators turned red even though the systems being monitored might still have been perfectly healthy. The Pi had disappeared, so it could no longer check them.

That made me think about the difference between a system that has actually failed and one whose status is unknown.

They're not the same thing, and the dashboard should make that clear.

I've been working towards a clearer distinction: red for a confirmed problem and grey when a system can't be checked.

It might seem like a small detail, but when you're managing equipment remotely, it matters. You need to know whether something has failed or whether you've simply lost visibility.

It also reminded me that the machine doing the monitoring can fail itself. If the monitor goes offline, an independent way of detecting that outage becomes important too.

What I've Learned

Building this setup has taught me that remote management involves more than getting everything working once.

You need to think about what happens when a connection drops, a device restarts or a service stops responding. You also need a way to diagnose the problem when you can't physically access the equipment.

Working through the project with Claude helped me break those problems into manageable steps. But the changes still had to be tested on the actual hardware, and the results mattered more than assumptions.

I've also learned that a small computer can do a lot when you give it a clear purpose. There's no need to run everything on one powerful machine when several simpler components can work together.

Final Thoughts

My Raspberry Pi spends most of its time quietly running in India, using very little of its available resources.

Yet it helps me connect to my home network, provides DNS services, monitors its own health and supports the connection between my CCTV system in India and Home Assistant in the UK.

It took a few months to bring everything together, and there are still things I can improve. The recent outage was a reminder that even a setup that works well most of the time needs a plan for when something goes wrong.

For now, I'm happy with how it's coming together.

I've got my Raspberry Pi in India, with Home Assistant and my Lenovo ThinkCentre Tiny home server in the UK. Each has its own job, and together they're becoming a useful part of my home setup.

It's taken quite a bit of planning, testing and troubleshooting to get everything working the way I wanted. There's still room for improvement, but that's part of the fun of running your own setup.

And with a little help from Claude along the way, it's been a good learning experience too.