Sisu is the home agent running on a Raspberry Pi 5 at our house. Through chat, you can ask what is happening or request a task. Under the hood, Hermes chooses the integration needed for it. Home Assistant collects data from supported devices, while the inverter and EV charger are accessed directly through their local APIs. That way, not every device has to fit into the same system.
The Raspberry Pi 5 runs Raspberry Pi OS as a standard Linux base. Hermes Agent and Home Assistant run alongside each other on it. This lets the Pi stay available day and night without keeping a powerful computer running.
Hermes handles conversation and actions. The agent interprets a question, retrieves the right information, and uses only the integration needed for that task. Home Assistant provides a central view of devices it supports well. The dashboard stays in our private environment and is not publicly accessible.
Home Assistant OS is a sensible choice for a device that only needs to run Home Assistant. Sisu also needs Hermes and a few custom integrations. That is why Home Assistant runs as Home Assistant Container on the same Linux machine.
This keeps their roles clear. Home Assistant handles the devices and statuses it is suited to. Hermes uses that information alongside other local sources. Neither needs to take over the entire installation.
Home Assistant has many ready-made integrations. Still, connecting every device that way is not always useful. Some devices offer a usable local API of their own. A direct connection is then simpler and provides exactly the data or actions we need.
In Sisu, Hermes mainly uses Home Assistant to read the statuses of supported devices. We add permissions to make changes only when a specific use case needs them. We use a different route for the inverter and EV charger: Hermes communicates directly with their local APIs.
| Route | When | Sisu example |
|---|---|---|
Home Assistant | A device is well supported and a central status view is useful | Reading the statuses of supported devices |
Direct local API | A device offers a usable local connection of its own | Reading surplus power from the inverter and controlling the EV charger |
Fixed automation | A recurring task needs to run predictably | Charging when there is enough surplus and stopping safely when that changes |
One useful application is charging the car with available solar energy. The inverter supplies the current surplus power directly as a single value. Hermes therefore does not have to subtract the home's consumption from its production itself.
Our EV charger is not in Home Assistant either. Hermes reads the inverter's value and can control the charger through the charger's local API. Home Assistant does not sit between those two connections.
The rule behind this is deliberately simple. Charging starts only after sufficient surplus has been available for long enough. If the surplus drops or a device stops responding, the automation stops safely. A change to the charging rule requires confirmation first. Meanwhile, you can ask through chat how much surplus is available, whether the car is charging, and why the automation did or did not act.
Without chat, these are separate dashboards and technical connections. With Hermes, you can request the same information in ordinary language. You do not need to remember where a status is shown or which application belongs to which device.
That does not mean a language model makes decisions freely. Hermes translates the question into a known check or action. Repeatable tasks remain fixed rules with clear boundaries. The agent can explain, but the automation determines when a device is actually controlled.
That separation makes the system more predictable. A question can be phrased flexibly. Execution does not have to be flexible too.
Sisu's base runs at home on the Pi. Home Assistant and the device connections stay close to the source. An external service may still be used for the language model and chat channel. Sisu is therefore a hybrid, local-first setup.
That is a practical choice. Local control does not need to pass through a manufacturer's cloud, while we can still use a suitable external service for language understanding. If the internet goes down, local rules can keep working, but chat may be temporarily unavailable.
Local does not automatically mean secure. We keep administration interfaces private, use separate accounts with limited permissions, and give each integration access only to what it actually needs.
For actions with a physical effect, we start with read-only access. Then we test one targeted action. Only when the behavior is clear do we add automation. Nothing happens if data is missing or unreliable. Changes to important rules require deliberate confirmation.
Start with a Raspberry Pi 5, reliable storage, and Raspberry Pi OS.
Install Hermes and Home Assistant Container on the same machine, but keep their roles separate.
Connect Home Assistant with a limited account and add only the devices that fit it well.
Use a direct local API when it is simpler and clearer for a device.
Add one chat channel and start with questions that only retrieve information.
Then automate one clearly defined task and also test what happens when data is missing.
A first version does not need more than that. A small working system teaches you where the value is faster than a house full of unfinished integrations.
For this role, yes. The Pi handles the connections, Home Assistant, and lightweight automation. The large language model does not need to run on the device itself. That keeps the local machine compact and energy efficient.
A Pi is not a replacement for heavy AI hardware or a development workstation. It does not need to be. Sisu is the always-available control system at home; compute-intensive work can happen elsewhere.
The main lesson is not that every business needs a Raspberry Pi. What matters is how the work is divided: let a local agent operate close to the processes, choose the simplest reliable connection for each system, and grant only the permissions needed.
A business environment needs more work on user administration, logging, updates, and support. The principle stays the same. You do not have to move everything to one cloud platform to make AI useful.
On the page about local AI for businesses, you can read how we translate this into a managed installation. Hermes as an AI agent shows which tasks the agent can carry out. Under security and privacy, we explain how we limit access and data flows. Voltti supports pilots in Belgium and the Netherlands.
For the business hardware decision, read when you need a Linux computer for an AI agent.
Because the same Raspberry Pi also runs Hermes and a few custom integrations. Home Assistant Container fits alongside those components on Raspberry Pi OS. For a device dedicated to Home Assistant, Home Assistant OS may be simpler.
No. The local device connections and automation can keep working at home, but the language model and chat channel may need internet access. Sisu is local-first and hybrid, not fully offline.
No. In our setup, Hermes reads surplus power directly from the inverter's local API and controls the EV charger through the charger's local API. Home Assistant remains available for other devices that fit it well.
That is not the Pi's role in Sisu. The device handles local connections and automation. The language model can run elsewhere, allowing the Pi to stay small and energy efficient.
No. Administration stays in a private environment and is not publicly accessible.
