Blog
deputyOS vs Home Assistant: AI assistant vs home automation hub
Home Assistant runs your house. deputyOS runs your personal AI. They complement each other — here's how to use both together.
“Why isn’t deputyOS just a Home Assistant integration?” is a fair question — both are self-hosted, both run on a Pi, both talk to the user. The answer is that they’re for different jobs.
What Home Assistant is
Home Assistant is the de-facto self-hosted home automation hub. It speaks to thousands of device protocols (Z-Wave, Zigbee, Matter, KNX, HomeKit, MQTT…) and lets you wire them together with automations, scenes, and routines. “When the front door opens after sunset, turn the hallway light on.” It has a beautiful UI for that.
It’s an extremely mature project. Lovelace dashboards, supervisor add-ons, the whole stack. If you want to run a smart home from your own hardware, Home Assistant is the right tool.
What deputyOS is
deputyOS is a self-hosted personal AI assistant. The assistant has memory, channels (Telegram, Slack, Discord, Signal…), skills, and a model provider it talks to (cloud or local LFM2). It does not, by itself, know anything about your lights or your thermostat.
This is by design. deputyOS holds to a profile-class rule: only multi-channel personal AI assistants are profiles. Home automation hubs explicitly aren’t — they have their own first-class projects, and we shouldn’t reimplement them.
Side-by-side
| Aspect | Home Assistant | deputyOS |
|---|---|---|
| Primary job | Device + sensor + automation orchestration | Multi-channel personal AI assistant |
| Knows about lights, sensors | Yes, ~3000 integrations | No, by design |
| Has an LLM | No (until recently; LLMs via integrations) | Yes, cloud or local LFM2 |
| Has Telegram/Slack/Discord etc. as chat | Integration with limits | First-class with persistent memory + skills |
| Persistent agent memory | n/a | Yes, per-profile |
| Dashboard | Lovelace | PWA at /app (status / logs / keys / cost) |
| Storage of state | Per-device | Per-conversation, per-channel, per-skill |
| Update model | OS updates from HA | Signed image with A/B swap + watchdog rollback |
| Security baseline | Solid (HA OS is hardened) | AppArmor / ufw / fail2ban / sysctls / ClamAV by default |
Using both together
The pragmatic setup is one Pi for Home Assistant and one for deputyOS, both on the same LAN. Then:
deputyOS → Home Assistant
Wire a Home Assistant skill into your OpenClaw or Hermes profile. The skill is a small TypeScript file that calls Home Assistant’s REST API or MQTT bridge. Now you can say (in Telegram):
“What’s the temperature in the living room?” “Lock the front door.”
The agent’s intent classifier routes to the Home Assistant skill, which makes the REST call, which returns the result.
Home Assistant → deputyOS
Home Assistant has a conversation integration that, since 2024, supports custom LLM backends over HTTP. Point it at your deputyOS device at http://deputyos.local:8088/api/chat. Now when you say “Hey HA” or trigger the voice integration, the response is generated by your local OpenClaw with full conversation memory.
This is genuinely the killer combo: Home Assistant handles devices; deputyOS handles understanding. The intent of your question (turn on the lights vs. summarise the week) decides which side does the work.
Why we don’t just bundle it
Bundling Home Assistant into deputyOS would mean:
- Re-implementing the device-integration layer (3000+ integrations is a lot of code we can’t possibly catch up on).
- Diverging from Home Assistant’s release cadence and security posture.
- Confusing deputyOS’s profile-class rule (which keeps the project focused).
- Making the deputyOS image enormous.
The right architecture is two projects, each excellent at its thing, talking over their official APIs. This is how Linux ecosystems usually work and it works well.
What if I only have one Pi?
Two reasonable options:
Option 1: Home Assistant primary, deputyOS secondary
Run Home Assistant OS on the Pi. Use the deputyOS image on WSL2 / UTM on your laptop, or a $5 cloud VPS. The cloud deputyOS handles channels; HA handles devices; they talk over the internet (with Tailscale between them).
Option 2: deputyOS primary, devices later
Run deputyOS on the Pi. For now, only chat + channels. When you decide you want device automation, get a second Pi (or a USB-form-factor Zigbee/Z-Wave coordinator and a small Pi Zero) for Home Assistant.
We recommend two devices because separation matters: a runaway automation script crashing your AI assistant is worse than either alone.
What if I want voice control?
Both projects have voice integrations. deputyOS has on-device wake-word + TTS via whisper.cpp + Piper on rpi5 (see enable voice). Home Assistant has Assist — also offline-capable.
For a “Hey Pi, turn on the lights” experience, the cleanest path is:
- HA’s Assist for the wake word.
- HA’s conversation integration pointed at deputyOS for natural-language understanding.
- deputyOS skill calling back into HA for the actual device action.
You end up using both speech endpoints, but with full local agency: no Alexa / Google Assistant / Siri in the loop.
What about Matter, Zigbee, Z-Wave directly?
deputyOS does not include the radios or the drivers. We deliberately ship without bluetooth daemon enabled too. The reasoning is in excluded by design (we’d be reimplementing Home Assistant badly).
A Pi 5 with a USB Zigbee coordinator running Home Assistant OS is the right tool. Pair it with an deputyOS Pi over your LAN.
Bottom line
If your question is “I want my home to do things when I say things” — Home Assistant.
If your question is “I want an AI assistant that remembers our conversations and is on Telegram/Slack/Signal” — deputyOS.
If your question is both — both. They complement each other extraordinarily well.
The picker has the right deputyOS image for your second Pi. Home Assistant has its own excellent docs for the first.
