KaZa Home automation

KaZa vs Home Assistant

This page offers an honest comparison between KaZa and Home Assistant, the most popular open-source home automation platform. Both solve the same core problem — centralizing home device control and automation — but with very different philosophies and tradeoffs.

The goal here is not to declare a winner. Both are legitimate choices depending on your background, constraints, and priorities.

Quick Summary

Architecture Comparison

KaZa

KaZa is a compiled C++ daemon with a QML scripting layer. The server binary is small, starts in milliseconds, and has a fixed memory footprint regardless of how many objects are registered (objects are simple C++ structs). The client is a compiled Qt application that communicates over a compact binary protocol.

kazad (C++ binary)
  ├── QML engine (user automation logic)
  ├── KaZaObject registry (in-memory)
  ├── SSL port 1756 (binary protocol)
  └── Control port 43500 (plain TCP)

Home Assistant

Home Assistant is a Python application running on an event loop (asyncio). It loads a large number of Python modules at startup. Its web interface runs in a browser and communicates via a WebSocket API (JSON messages). The official mobile app also connects through the web interface.

home-assistant (Python process)
  ├── Core (event bus, state machine)
  ├── 3000+ integration modules (Python)
  ├── HTTP server (WebSocket + REST API)
  ├── Add-on system (Docker containers)
  └── Supervisor (HAOS only)

Detailed Comparison

Resource Footprint

KaZa wins here. Being a native compiled binary, kazad idles at 30–80 MB of RAM on a Raspberry Pi 4, even with multiple plugins loaded. CPU usage during idle is essentially zero. It starts in under a second.

Home Assistant typically requires 300–600 MB of RAM at idle on a minimal install, and more with add-ons (each add-on is a Docker container). On a Raspberry Pi 4, a full HAOS installation with a few active integrations easily uses 1–2 GB of RAM. Startup takes 30–120 seconds depending on the number of integrations.

For very constrained hardware (older Pi, embedded Linux boards), KaZa is significantly more practical.

Integration Ecosystem

Home Assistant wins overwhelmingly. With over 3,000 official integrations and thousands more in the community store (HACS), virtually every smart home device or service is already supported: Zigbee, Z-Wave, Matter, Philips Hue, Ikea Tradfri, Shelly, Sonos, Google Home, Amazon Alexa, Apple HomeKit, Tesla, Fronius, SMA, EV chargers, weather services, and on and on.

KaZa ships with four official plugins: KNX, MQTT, Helios ventilation, and Palazzetti pellet stoves. Adding a new device type requires writing a C++ plugin — a significant barrier.

If you rely on mainstream consumer devices (Ikea, Philips Hue, Shelly, Sonos…), Home Assistant is the pragmatic choice. If your installation is based on KNX — which is the professional bus standard in European buildings — KaZa's native KNX plugin offers a tight, low-latency integration.

User Interface

This is arguably the sharpest difference between the two systems.

Home Assistant: you are always inside Lovelace

No matter how much you customise a Home Assistant dashboard, the result will always look and feel like Home Assistant. The global chrome — top bar, sidebar navigation, user menu, notification panel — is fixed and not modifiable. What you can customise is the content area: which cards appear, in which order, with which data.

Cards are placed in a grid. Even with custom HACS cards (Mushroom, Mini Graph Card, ApexCharts, etc.), you are still placing rectangular blocks inside a column-based grid. The overall structure is imposed:

┌──────────────────────────────────────────────────┐
│  Home Assistant  [sidebar]  [user icon]  [bell]  │  ← fixed, not yours
├──────┬───────────────────────────────────────────┤
│      │                                           │
│ Nav  │   [Card]  [Card]  [Card]                  │  ← grid of cards
│ bar  │   [Card]  [Card]                          │
│      │   [Card]  [Card]  [Card]  [Card]          │
│(HA)  │                                           │
└──────┴───────────────────────────────────────────┘
  ↑ this is Home Assistant's UI, always

You can pick colours, icons, and card content. You cannot move the sidebar, remove the top bar, implement a custom navigation flow, or animate a transition between views. The user will always recognise they are looking at Home Assistant.

KaZa: you write the entire UI

With KaZa, there is no imposed structure at all. The client loads a .rcc bundle containing your QML files and starts from your main.qml. Nothing else is there by default. You design everything: the navigation model, the page transitions, the layout of each screen, the colour scheme, the typography, the interaction patterns.

Qt Quick gives you access to the full QML ecosystem:

• Qt Quick Controls 2 — buttons, sliders, dialogs, drawers, tab bars, tool bars — all styleable from scratch
• Animations and transitions — NumberAnimation, PathAnimation, SequentialAnimation, Behavior, Transition — smooth, hardware-accelerated, 60 fps on a Raspberry Pi
• 3D — Qt Quick 3D for three-dimensional scenes, floor plans, or device visualisations rendered inline in the UI
• Canvas and ShaderEffect — custom 2D drawing and GLSL fragment shaders for effects
• States and state machines — declarative state transitions with animated interpolation between layouts
• Custom components — define reusable QML components once and compose them freely, with properties, signals, and animations encapsulated

A KaZa UI can look like anything:

Option A: a floor-plan touch interface
┌──────────────────────────────────────┐
│                                      │
│   [interactive SVG floor plan]       │
│   tap a room → room controls slide   │
│   in from the right with animation   │
│                                      │
└──────────────────────────────────────┘

Option B: a dashboard with custom widgets
┌──────────────────────────────────────┐
│  22°C  ||||  ☀ 4.2kW   🔋 87%       │
│  ──────────────────────────────────  │
│  [animated energy flow diagram]      │
│  [circular temperature gauge]        │
│  [scrolling power history chart]     │
└──────────────────────────────────────┘

Option C: a branded product UI
┌──────────────────────────────────────┐
│  [your logo]   [custom top bar]      │
│                                      │
│   [completely custom layout]         │
│   [your colour scheme]               │
│   [your icons and typography]        │
└──────────────────────────────────────┘

There is no sidebar unless you create one. There is no top bar unless you place one. Navigation can be a StackView, a SwipeView, a Drawer, a tab bar at the bottom, or a completely custom gesture-driven system. Every pixel is under your control.

The trade-off is real: this freedom requires QML knowledge. Writing a good UI takes more time than placing Lovelace cards. But the result is a native application that is entirely your own — indistinguishable from a commercially developed app if that is what you want.

Automation Language

Both systems use declarative approaches, but they feel very different in practice.

KaZa automations are written in QML — a reactive, signal/slot language with JavaScript expressions. If you know QML, automation is natural: bind a Scheduler to fire an action at a given time, or use onValueChanged to react to a sensor reading. Complex logic (state machines, multi-condition rules) is just JavaScript.

// KaZa: motion light with auto-off timer
KzObject {
    id: motion
    object: "knx.sensor.hallway.motion"
    onValueChanged: {
        if (value) {
            hallwayLight.set(true)
            lightTimer.restart()
        }
    }
}
Timer {
    id: lightTimer
    interval: 120000
    onTriggered: hallwayLight.set(false)
}

Home Assistant automations are configured via the GUI or written in YAML with Jinja2 templates. The trigger/condition/action model covers most use cases without any code. Complex logic requires Jinja2 templates or Node-RED (a separate add-on).

# Home Assistant: motion light with auto-off
automation:
  - alias: "Hallway light on motion"
    trigger:
      - platform: state
        entity_id: binary_sensor.hallway_motion
        to: "on"
    action:
      - service: light.turn_on
        entity_id: light.hallway
      - delay: "00:02:00"
      - service: light.turn_off
        entity_id: light.hallway

Development: Adding New Integrations

This is where the difference is sharpest.

KaZa requires writing a C++ Qt plugin. You need a working Qt 6 development environment, knowledge of C++17, Qt's signals/slots and QObject model, and CMake. The barrier is real but the result is performant, type-safe, and ships as a standard Debian package.

Home Assistant requires writing a Python integration following the HA architecture (config entries, entities, coordinator pattern). Python is far more accessible than C++. The HA developer documentation is extensive, and thousands of existing integrations serve as templates.

Security

KaZa enforces mutual TLS for every client connection. Every device has its own X.509 certificate signed by a private CA that the integrator controls. There is no anonymous access, no API key fallback, and no shared secret. The certificate authority stays on the server; compromising one client certificate does not compromise others.

Home Assistant offers several authentication modes: a trusted networks mode (IP-based, no credentials), API long-lived tokens, and the default username/password flow. The Nabu Casa cloud integration adds remote access. Security quality varies significantly with configuration — it is possible to expose Home Assistant to the internet with weak security, which has been the source of real-world incidents.

Installation and Maintenance

This is where the comparison is more nuanced than it first appears. The "easy" label for Home Assistant depends heavily on which install method you use and what hardware you are running.

Home Assistant installation reality

Home Assistant offers several installation paths, and their complexity varies enormously:

• HAOS (Home Assistant OS): A dedicated image that replaces your entire OS. Easy on a Raspberry Pi 4 or a dedicated x86 machine — but it means you cannot use the board for anything else. No Armbian, no standard Debian, no existing services alongside it.
• Docker / Supervised: Requires Docker and Docker Compose. Installing Docker on a standard Debian system is straightforward on x86. On ARM boards running Armbian or a minimal Debian image (common for SBCs like Orange Pi, Banana Pi, Odroid, or older Raspberry Pi models), Docker installation is significantly more involved: the right repository must be added for the specific architecture, kernel module compatibility must be verified, and cgroup v2 support may need to be explicitly enabled. The Home Assistant Supervised install adds further constraints — it requires a specific OS configuration and actively warns if anything deviates from its expected environment.
• Python venv: Closest to a standard install, but requires manually managing a Python virtual environment, pip dependencies, and a systemd unit — with no official support or upgrade path.

On ARM boards in particular, Docker is not a one-liner: it requires matching the CPU architecture to the correct Docker package repository, and some boards have historically had kernel limitations that prevent Docker from running correctly at all.

KaZa installation

KaZa is distributed as standard Debian .deb packages hosted in an APT repository. Installation is identical on x86, Raspberry Pi, Armbian, or any other Debian-based system:

# Add the KaZa repository once
echo "deb https://repo.kazoe.org/kaza stable main" | \
    sudo tee /etc/apt/sources.list.d/kaza.list
sudo apt update

# Install server and plugins — works the same on any architecture
sudo apt install kaza-server-bin kaza-knx kaza-mqtt
sudo systemctl enable --now kazad

There is no container runtime to install, no architecture-specific repository to locate, no kernel feature to verify. The packages follow Debian standards: dependency declarations are correct, the systemd unit is installed automatically, and postinst scripts handle initial setup. KaZa installs alongside any existing services on the machine — it is just another daemon.

Upgrades are fully automatic with Debian's standard unattended-upgrades or a manual apt upgrade. No separate update mechanism, no web UI required, no container image to pull. This is a significant operational advantage on headless ARM boards that run 24/7 and are not regularly accessed directly.

# Upgrade KaZa the same way as any other Debian package
sudo apt update && sudo apt upgrade

The trade-off compared to HAOS is that initial configuration (SSL certificates, server QML, client bundle) still requires manual steps and QML knowledge — there is no graphical setup wizard.

Pros and Cons

KaZa

Pros: - Extremely small resource footprint — runs well on a Raspberry Pi 3 or any constrained Linux board - No Docker required — a single apt install from the Debian repository gets the server running; each plugin is an additional .deb package. Standard Debian package management, no container runtime, no special OS image - Complete UI freedom — blank canvas in QML: any navigation model, any layout, any animation, any colour scheme. No imposed structure, no Home Assistant chrome, no card grid. The result can look like anything — a custom branded product, an interactive floor plan, or a professional dashboard - Full Qt Quick ecosystem: animations, 3D (Qt Quick 3D), custom shaders (ShaderEffect), Qt Quick Controls 2, hardware-accelerated rendering at 60 fps on a Raspberry Pi - Native, hardware-accelerated UI — no browser, no network latency for the interface - Tight KNX integration — professional bus, bidirectional, reads ETS project directly - Binary protocol — object value updates are 10–20 bytes; a Pi handles hundreds of objects with no measurable load - Mutual TLS mandatory — strong security model out of the box - Fully custom UI — any layout, any animation, any interaction pattern - No cloud dependency — runs entirely locally - Clean separation: server logic in QML, client UI in QML, plugins in C++ - Fits into any existing Debian/Raspberry Pi OS system — no dedicated hardware or OS image needed

Cons: - QML knowledge required for UI and server logic — significant learning curve - C++ required for new integrations — high barrier for adding unsupported devices - Very small ecosystem — ~5 official integrations, no community store - No installation wizard — setup requires Linux skills and manual configuration - No GUI for configuration or automation rules - Small community — very limited resources for help, no active forum - No voice assistant integration - No energy dashboard, history graphs, or statistics UI out of the box (must be built in QML) - Certificate management is manual

Home Assistant

Pros: - Enormous ecosystem — 3000+ integrations, virtually any device is already supported - No coding required for most use cases — GUI automation editor, card editor - HAOS image provides a fully guided first-run experience on supported hardware - One-click updates from the web UI (HAOS) - Large, active community — extensive documentation, forum, YouTube tutorials - Built-in energy monitoring dashboard, statistics, history graphs - Voice assistant integration (Alexa, Google, Siri via HomeKit bridge) - Mobile companion app with notifications, GPS presence, widgets - Node-RED integration for complex automation without code - Active development — frequent releases, rapidly expanding feature set - Nabu Casa cloud for easy remote access (paid subscription)

Cons: - High resource usage — not suitable for very constrained hardware - Slow startup — not ideal if the server restarts frequently - UI is always recognisably Home Assistant — the global chrome (sidebar, top bar, user menu) is fixed and not modifiable; only card content is customisable - Layout constrained to a column-based card grid — no arbitrary positioning, no custom navigation flows, no full-screen interactive elements outside of cards - Python-only integrations — slower than native C++ for latency-sensitive protocols - Security defaults are weaker — easy to misconfigure remote access - YAML can become complex and hard to maintain for large installations - Dependency on HA release cycle — integrations break on major HA updates - Cloud features require subscription (Nabu Casa) - Less suitable for KNX-centric professional installations - Docker installation on ARM boards (Armbian, minimal Debian) is complex and not always reliable — kernel and cgroup compatibility must be verified per board - HAOS requires a dedicated machine — cannot share the board with other services - No standard Debian package integration — upgrades cannot be automated through apt or unattended-upgrades

When to Choose KaZa

• Your installation is KNX-centric (professional European bus standard)
• You (or someone on your team) know Qt/QML and want full control over the UI
• You are running on an ARM board with Armbian or standard Debian and do not want to deal with Docker
• You want to share the board with other services — KaZa is just another systemd daemon
• You need to run on very constrained hardware (old Pi, embedded ARM board)
• You want native apps on all platforms with no browser dependency
• You want a UI that does not look like Home Assistant — your own navigation, layout, animations, and visual identity with no imposed structure
• You want to use the full Qt Quick ecosystem: Qt Quick 3D, custom animations, interactive floor plans, ShaderEffect, or any visual design that cannot be expressed as a grid of cards
• You want strong security by default (mutual TLS, no anonymous access)
• You want standard Debian package management — apt upgrade, unattended-upgrades, reproducible installs
• You are building a custom product where the UI must be pixel-perfect and branded
• You are comfortable with C++ and want to write tight, performant protocol integrations

When to Choose Home Assistant

• You need broad device compatibility without writing code
• You (or the end user) are not developers — YAML and the GUI editor are enough
• You rely on mainstream consumer devices (Ikea, Philips Hue, Shelly, Z-Wave, Zigbee, Matter)
• You have a dedicated x86 or Raspberry Pi 4 machine available for HAOS
• You want voice assistant integration (Alexa, Google, Siri)
• You want a large community for help and ready-made automations
• You need built-in energy monitoring and statistics dashboards
• You are comfortable with the cloud features (remote access, mobile notifications)

Can They Coexist?

Yes. KaZa's MQTT plugin makes it straightforward to bridge KaZa objects to Home Assistant via a Mosquitto broker. This lets you use KaZa for KNX (where it excels) and Home Assistant for everything else (cloud integrations, voice assistants, energy dashboard), with both systems sharing state through MQTT topics.

KNX bus
  └── knxd
        └── KaZa (kaza-knx plugin)
              └── MQTT broker (Mosquitto)
                    └── Home Assistant (MQTT integration)

In this setup, KaZa handles the KNX side (fast, bidirectional, ETS-native) while Home Assistant provides the ecosystem, voice control, and mobile notifications. The KaZa native client handles the day-to-day mobile UI; Home Assistant is accessible from any browser for administration and monitoring.