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

KaZa and Home Assistant take fundamentally different approaches.

KaZa's UI is a native compiled Qt application. The integrator writes QML screens and compiles them into a .rcc bundle. There is no browser involved. This means: - Smooth 60 fps animations on modest hardware - Works without a network connection once the initial bundle is loaded - Fully custom layout, not constrained to any card/widget system - Requires QML knowledge to build

Home Assistant's UI is Lovelace, a browser-based dashboard. Lovelace cards are configured via YAML or a GUI editor. There are hundreds of custom card types available (via HACS). This means: - No coding required for most UIs - Any browser becomes a dashboard (TV, tablet, old phone) - Highly limited by the card/grid system for truly custom layouts - Animations and responsiveness depend on the browser and network

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

Home Assistant wins on ease of first-run setup. Home Assistant OS (HAOS) is a turnkey image that boots on a Raspberry Pi and guides you through setup via a web browser. Docker and supervised installs are also straightforward. Updates happen in one click from the web UI.

KaZa takes a different but equally clean approach once the Debian repository is in place: install the server with a single apt install, add any integration with another apt install, and manage everything with standard Debian tooling. There is no Docker involved — kazad is a plain native binary managed by systemd, just like any other Linux service. Each integration is an independent .deb package with proper dependency declarations.

# KaZa installation — nothing more than standard Debian package management
sudo apt install kaza-server-bin
sudo apt install kaza-knx kaza-mqtt

sudo systemctl enable kazad
sudo systemctl start kazad

Compared to Home Assistant's Docker-based architecture (multiple containers, Supervisor, add-on store), this is a minimal footprint that fits naturally into any existing Debian or Raspberry Pi OS installation without requiring a dedicated OS image or container runtime.

Updates follow the normal Debian flow:

sudo apt update && sudo apt upgrade

The trade-off is that initial configuration (SSL certificates, server QML, client bundle) still requires manual steps and QML knowledge — there is no 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 - 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 - Very easy installation — HAOS image, Docker, one-click updates - 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 limited to the Lovelace card system — truly custom layouts are difficult - 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

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 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 strong security by default (mutual TLS, no anonymous access)
• 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 want easy installation and updates with minimal Linux knowledge
• 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.