Sovereign AI For My Smart Home Lab: Biohacking Without Giving Big Tech My Vitals

I wired my biohacking devices into a sovereign, self-hosted AI that lives on my network and actually runs my protocols. No cloud, no API key dependency, just a bossy local model running my day.
Sovereign AI For My Smart Home Lab: Biohacking Without Giving Big Tech My Vitals
Photo by Stephan Bechert / Unsplash

Why I Stopped Letting Big Tech Babysit My Biology

I like data. I like knobs, levers, sliders. I like seeing my HRV respond to a protocol and then wiring that into code.

What I do not like is my health data living on random servers, under vague privacy policies, with “AI insights” that look like a horoscope in gym clothes.

So I built a small, sovereign AI layer for my home biohacking setup. It lives on my hardware. It talks to my devices. It decides when to nudge, when to back off, and it never phones home.

This is not some theoretical “web3 + wellness” pitch. It is a very opinionated, very hacky, very real system running in my house in the Netherlands.

My Smart Home Biohacking Stack, Before AI Got Involved

Before I added AI, the setup looked like this:

  • Wearables: Oura Ring, Garmin watch, sometimes a Polar chest strap for honest HR data.
  • Environment: Hue lights, smart plugs on red light and PEMF devices, a CO₂ sensor, temperature sensors, cheap smart plugs on fans and a space heater.
  • Inputs: Standing desk, under-desk treadmill, a basic indoor air quality sensor, and a very boring but solid mechanical timer for blue light blockers as a backup.
  • Software glue: Home Assistant on a small Intel NUC, Node-RED for the ugly flows that would embarrass my younger self, a bunch of MQTT topics yelling at each other.

It worked, sort of. I had automations like:

  • Turn office lights warm at 21:30.
  • If CO₂ > 900 ppm, turn on fan and notify my phone.
  • If it is after 22:00, cut power to standing desk to force myself to stop “just one more thing.”

Nice, but dumb. Completely deterministic. No context about my day, my sleep, my training load, or whether I was traveling.

Why I Wanted a Sovereign AI Layer

Adding a cloud LLM was easy. Call an API, send some metrics, ask “what should I do.” I tried it. It felt wrong.

Three reasons I abandoned that idea fast:

  • Data sovereignty. I do not want to ship sleep, HRV, stress, and location data to any third party, no matter how nicely they talk about encryption.
  • Fragility. If your core automation depends on a model endpoint and that endpoint changes pricing, limits, or quality, your protocols break overnight.
  • Latency and reliability. I want sub-second decisions. If my CO₂ spikes or my HR jumps during sleep, I prefer a local machine to react, not a SaaS platform that decided to reboot.

So I decided the AI brain had to live at home. Fully local if possible. Or at least as local as my threat model demands.

What “Sovereign AI” Means In My House

My working definition is simple.

Sovereign AI means:

  • The model runs on hardware I control, on a network I control.
  • It can act on the environment without asking a cloud function for permission.
  • I can inspect its instructions, training prompts, and logs.
  • If every external connection dies, it still works.

I do not pretend I am running a perfectly audited, nation-state-proof setup. This is not that. This is a reasonably private, practical system that makes my house feel like a personal lab instead of a consumer IoT showroom.

The Architecture, From Sensors To AI To Devices

Here is what the current setup looks like.

  • Hardware: Intel NUC with 32GB RAM, small Nvidia GPU. On the same VLAN as my smart home gear.
  • Home Automation: Home Assistant + MQTT broker.
  • AI Runtime: Local LLM via Ollama, plus a small embedding model for “memories.”
  • Brain: A Python service that pulls context from Home Assistant, calls the local model, and returns decisions as structured JSON.
  • Device control: Home Assistant automations that listen for the AI’s decisions and actually flip switches, change light scenes, or send me a message.

I do not point the model directly at my devices. That feels reckless. It speaks a very limited language instead, something like:

{
  "actions": [
    {"type": "set_light_scene", "target": "office", "scene": "evening_focus"},
    {"type": "toggle_device", "target": "red_light_panel", "state": "on", "duration": 900},
    {"type": "notify", "channel": "mobile", "message": "Walk 5 minutes. HRV is tanking."}
  ]
}

Then Home Assistant translates those into real automations. If the AI says something that does not match the schema, it is ignored and logged.

The Daily Loop: How The AI Runs My Protocols

The core of this system is a loop that runs every few minutes and some specific event-based triggers. Here is the basic flow.

  1. Home Assistant aggregates my latest metrics: last night’s sleep score, HRV, RHR, current HR, step count, CO₂ levels, time of day, calendar events, and whether I am in the office or not.
  2. The Python service pulls that context. It compresses raw numbers into a short, opinionated summary: “Slept 6h15, HRV -18% vs baseline, high stress yesterday, no morning light yet, 2 calendar calls before noon.”
  3. It feeds this summary plus a very explicit system prompt to the local model. The prompt encodes my rules and my personal philosophy. Things like “avoid aggressive protocols after bad sleep” or “prioritize light and movement over supplements.”
  4. The model returns a JSON list of actions. No paragraphs. No coaching speech.
  5. Home Assistant executes the safe subset of those actions and logs what happened.

That is the skeleton. The interesting bit is what you tell the model it is allowed to care about.

Encoding My Biohacking Philosophy Into The AI

I am not trying to build a doctor replacement. I am building a pushy lab assistant that respects my constraints.

My system prompt reads something like this, heavily summarized:

  • Never recommend anything medical. You only orchestrate environment and nudges.
  • Respect recovery. If sleep is poor and HRV is low, reduce intensity of any protocol.
  • Prioritize natural inputs first: light, movement, temperature, air quality.
  • Do not spam. Max 3 proactive interventions per day unless environment is unhealthy.
  • Assume the user is a stubborn developer who ignores subtle hints. Be direct but not annoying.

Then I define time windows and goals:

  • Morning: light exposure, gentle movement, no extreme cold if sleep was bad.
  • Afternoon: productivity and air quality.
  • Evening: light management, winding down, strict screens and stimulation cutoff.

This means the AI is not just reacting to numbers. It is following a playbook that I wrote, with room to improvise based on context.

Concrete Scenarios From My House

Here are a few examples that actually run now.

1. The "You Slept Like Trash" Morning Protocol

Input conditions:

  • Sleep duration < 6.5h.
  • HRV > 15% below baseline.
  • First alarm within the last 30 minutes.

The AI usually decides to:

  • Set office lights to a soft but bright warm scene instead of harsh cool white.
  • Turn off any high-intensity cold exposure recommendation. No cold plunge suggestion, even if the schedule would normally include it.
  • Send a short notification: “Recovery compromised. Keep caffeine < 2 cups, walk 10 minutes before work, no heavy training today.”

All of that stays local. No Oura API call leaves the house. The only thing I see is the effects.

2. CO₂, Focus, And The 90-Minute Rule

If I sit in my office too long and CO₂ creeps above 1,000 ppm, my cognitive performance drops. You can feel it. Slow thinking, dumb mistakes.

The old automation just toggled the fan at 900 ppm. The sovereign AI does something smarter:

  • Checks if I am in a focus block (calendar tag) or on a meeting.
  • Checks whether I have moved in the last 90 minutes.
  • If I have been mostly sedentary and CO₂ is high, it does two things: start the fan and cut my office lights to a “break” scene that is obviously not work mode.
  • Then it nudges my phone: “Walk outside 5–10 min. CO₂ high, movement low. Your next block will be better if you move now.”

I treat that as a hard recommendation unless I am deep in a build session. And the model learns that too. If I keep ignoring it during build sessions, I tweak the prompt to be less aggressive in those time windows.

3. Evening Shutdown Without Negotiation

I am bad at stopping. Developers know this one. “Just fix this tiny bug” becomes 01:30.

The sovereign AI acts like a grumpy coach here.

  • After 21:30, if tomorrow’s calendar has early commitments and HRV is already low, it starts winding down lights automatically.
  • At 22:15, it cuts power to my standing desk and treadmill, sets the office lights to very warm and dim, and turns on a small bedside red light if I am still in the office.
  • If I keep working past 22:30, it sends a blunt message: “You are borrowing tomorrow’s focus. Decide intentionally. Type YES-BORROW to keep working 30 more minutes.”

That last part uses a tiny chat agent that still runs locally. I have to type the phrase in a chat window that sits on my dashboard. It is annoying enough that most days I just stop.

Why Decentralization Actually Matters Here

You can build similar flows with a cloud AI. It will look slick. It will be easier to start.

I still think decentralization matters for three reasons.

  • Control. If a vendor decides “no more low-level access, only high-level wellness goals,” you are stuck. With a sovereign setup, you can keep running the last known-good version of your stack.
  • Privacy by default. My AI sees everything. Sleep, minor health quirks, stress patterns. I am not interested in negotiating where that data goes in exchange for some convenience.
  • Experiment velocity. I change prompts weekly. I wire in new sensors. I break things. Doing that against a cloud API feels brittle and expensive. Locally, it feels like creative play.

There is also something very tangible about the loop fully closing inside your four walls. My body, my sensors, my model, my devices, my logs. That feels healthy and honest.

The Ugly Parts Nobody Markets

This is not a plug-and-play setup. A few rough edges are real.

  • LLM weirdness. Even locally, models hallucinate structure. I had runs where it invented actions that do not exist. The only fix is strict JSON schemas and brutal validation.
  • Latency. Some smaller models are fast but dumb. Bigger ones are smart but sluggish on modest hardware. You have to decide where you care about instant reactions and where 2–3 seconds is fine.
  • Maintenance. Home Assistant updates, model updates, driver updates. If you want an appliance, this is not it. This is more like maintaining a project car.
  • Over-automation. It is tempting to let the AI poke at everything. That gets annoying quickly. I had to ruthlessly cut back interventions to the things that demonstrably help.

I still prefer this to polished vendor dashboards that tell me my “Sleep Age” once a week while selling me supplements.

Where I Want To Take This Next

Right now the AI is reactive with a little bit of memory. It remembers recent days, not months.

The next step is a proper local memory layer. Something lightweight that can answer “what usually happens when you train heavy on Wednesdays and sleep badly on Thursdays.” Then adjust protocols ahead of time.

I also want a proper “consent dashboard.” A place where I can see exactly which decisions the AI took, which sensors it used, and where I can revoke powers. For example, maybe it can touch lights and fans, but it cannot ever change bedroom temperature.

And I want to share sanitized configs. No product, just the prompts, schemas, and automations that have worked for me, so other people can adapt them to their weird setups.

If You Want To Try Something Similar

If you are a developer with a few smart devices, you can start very small.

  • Pick one protocol. Morning light, or CO₂, or evening shutdown. Not all three.
  • Run a local model in the simplest way possible. Even a CPU-only 7B model is fine for structured decisions.
  • Define a strict, tiny JSON schema for actions. No freeform text running your life.
  • Wire only one device to it. See how it behaves for a week. Keep logs.
  • Then iterate. Add a second sensor, or a second action type.

The point is not to build a sci-fi AI butler. The point is to have a sovereign system that knows your body, your habits, your space, and can nudge you in ways that a generic wellness app cannot.

For me, that is the interesting part of AI right now. Not another chat window. A quiet, stubborn, local brain that moves the lights, air, and routines in my little lab so I do not have to think about them all the time.

And if every external service vanished tomorrow, this setup would still work. That feels like real progress.

Subscribe to my newsletter

Subscribe to my newsletter to get the latest updates and news

Member discussion