HomeGenie 2.0: A Local-First Automation Server With On-Board LLM and Vision
HomeGenie: The Programmable Intelligence with 100% Local Agentic AI.
At a glance
- What is it?
- HomeGenie bundles a C#/JavaScript automation engine, a local LLM agent, and YOLO-based computer vision into a single ZIP you extract and run. It is a strong fit for tinkerers who want no cloud dependency and are willing to accept AGPL-3.0 obligations and a Windows-centric build matrix.
- Who is it for?
- Adopt HomeGenie if you want a self-contained automation server where the LLM and vision models run beside the device drivers, and you accept AGPL-3.0 copyleft. Do not adopt it if you need a hosted cloud service or if you cannot test the release ZIP on your own hardware first.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 107 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What HomeGenie Assembles That Other Stacks Leave to You
Most home automation servers stop at device control. HomeGenie's README describes an ecosystem that also includes firmware for DIY devices, mobile and tablet apps, and a backend service, all under one project. The stated goal is a cloud-independent, local-first experience where no automation data leaves the machine. The secondary claim is more specific: a 100 percent local agentic AI that runs state-of-the-art LLMs on the HomeGenie server itself for autonomous reasoning and natural language control. That combination, an automation bus plus an on-device LLM plus a YOLO vision suite, is the differentiator. It is aimed at the engineer who wants to script devices in C#, JavaScript, or Python and also wants to ask in plain language for a widget or an automation. The README states the UI supports more than 90 languages and ships a built-in demo configuration, so a new user can see a working setup before wiring anything real.
The Runtime: Drivers, a Fluent API, and a Scheduler With Genie Commands
The architecture visible in the material is a single backend service that hosts protocol drivers, an automation engine, and the AI components. The README lists integrated drivers for X10, Z-Wave, ZigBee, GPIO, SPI, I2C, and IR/RF. Automations run through a fluent API programmable in C#, JavaScript, and Python, which means the same event model is exposed in three languages rather than through a plugin SDK alone. Scheduling is handled by an advanced scheduler that the README says supports extended cron expressions, variables, conditions, and AI-driven natural language tasks. The AI layer is not a separate service: it runs inside the same process, which is what makes the local-only claim plausible. Vision is the second AI path. The README states YOLO object detection, instance segmentation, and pose estimation run directly on the server, with input from ESP32-CAM modules and generic IP cameras. The dashboard and widgets are editable in HTML, JavaScript, and CSS, so the front end is part of the same programmable surface. The README also mentions a Visual Program editor for users who do not want to write code, and a package repository for extensions.
Installation: One ZIP, Many GPU Variants
The install path is deliberately plain. Download the ZIP for your platform from the GitHub Releases page, extract it, and run the startup script. The README gives the exact commands: on Windows, double-click start.bat; on macOS, double-click start.command; on Linux or Raspberry Pi, run ./start.sh from the terminal. The extracted folder contains a homegenie directory with the application binaries. The choice that matters is the variant. Windows and Linux x64 each ship in three forms: a standard CPU-only build, a cuda12 build for NVIDIA GPUs, and a vulkan build. On Windows, Vulkan covers AMD, Intel, and NVIDIA for the LLM while vision runs through DirectX 12 (DirectML). On Linux, the Vulkan variant uses Vulkan for the LLM but falls back to CPU for vision, because the README states DirectML is not available there. ARM users get linux-arm64 for Raspberry Pi 3, 4, 5, and Zero 2, or linux-arm for the 32-bit Raspberry Pi 2. macOS ships as osx-x64 with Metal support for Apple M1, M2, and M3. The README's guidance is direct: NVIDIA users should take cuda12, non-NVIDIA Windows users should take vulkan, and headless servers or older PCs should take the standard build.
Where the Local-Only Design Costs You
The same choice that keeps data private also constrains the hardware. A local LLM needs memory and compute on the same box that runs your device drivers and scheduler. The README offers no minimum specification, no model size, and no token throughput figure, so the practical ceiling is unknown until you try it. The variant matrix makes this worse in one specific case: on Linux, the Vulkan build accelerates the LLM but runs vision on the CPU, so a camera pipeline that works on Windows with DirectML may behave differently on the same GPU under Linux. That is a real asymmetry, not a footnote. The AGPL-3.0 licence is the second constraint. If you modify HomeGenie and expose it to users over a network, the licence's network clause applies, and that is a different obligation from a permissive licence. The README does not discuss commercial licensing or exemptions. Finally, the release cadence is fast, with v2.0.24 landing on 2026-05-31, one week after v2.0.23. Frequent releases are good for fixes but mean upgrade testing is a recurring task, and the README does not describe a migration or rollback procedure.
Home Assistant as the Contrast: Integration Breadth Versus Built-In Intelligence
Home Assistant is the obvious comparison for anyone shopping in this category. The difference in approach is where the intelligence lives. Home Assistant historically treats AI as an external dependency: you point it at a cloud provider or a separate local inference server, and the automation engine stays a control plane. HomeGenie's README claims the opposite arrangement, with the LLM and YOLO models running in the same server process as the X10, Z-Wave, and ZigBee drivers, and with vision sourced from ESP32-CAM and IP cameras. That makes HomeGenie more self-contained and more demanding of the host machine. The trade is not purely technical. Home Assistant has a much larger integration catalog, and HomeGenie's README names a specific driver list rather than claiming universal coverage. If your devices are not in that list, the local AI advantage does not help you. If they are, and you want one process that reasons about them without a round trip to a cloud endpoint, HomeGenie is the more direct answer.
Maintenance, Upgrades, and the Licence You Are Accepting
HomeGenie is released under AGPL-3.0, and the README does not mention any dual-licensing option. For a private home server that you run for yourself, the copyleft terms are unlikely to change your day. For anyone who forks the code and offers it as a service, the network clause is the part to read carefully before shipping. This is not legal advice; the licence text governs. On maintenance, the project ships point releases roughly weekly to biweekly in the recent history shown, and the README advertises configuration backup and a package repository as features, which suggests the intended upgrade path is to back up configuration and update the binaries in place. There is no documented long-term support branch in the material. The practical cost is therefore not the licence fee, which is zero, but the time spent re-testing automations, drivers, and AI variants after each release, plus the storage and memory the local models consume on the same machine as your automation runtime.
Who Should Download Which Build
If you already own an NVIDIA GPU and run Windows or Linux, the cuda12 build is the one the README points to for both LLM and vision. If you are on Windows with AMD or Intel graphics, the vulkan build is the recommended path and gives you DirectML vision. If you are on Linux with a non-NVIDIA GPU, take vulkan for the LLM but expect CPU vision. If you are on a Raspberry Pi 4 or 5, linux-arm64 is the listed option, and the README frames ARM as CPU-based, so treat AI features as an experiment rather than a guarantee. If you are on macOS with Apple Silicon, osx-x64 uses Metal. The people who should not adopt HomeGenie are those who want a managed cloud service, those who need a commercial licence without copyleft, and those whose devices fall outside the named driver list. The first thing to verify on your own hardware is whether the AI variant you downloaded actually loads a model and processes a camera frame at a rate you find usable, because the README publishes no numbers on that.
Editorial conclusion
Adopt HomeGenie if you want a self-contained automation server where the LLM and vision models run beside the device drivers, and you accept AGPL-3.0 copyleft. Do not adopt it if you need a hosted cloud service or if you cannot test the release ZIP on your own hardware first. Before committing, verify that your specific protocol adapter (Z-Wave, ZigBee, or KNX) is listed in the driver set, and confirm which AI variant matches your GPU, since the CUDA, Vulkan, and CPU builds are separate downloads with different vision backends.
Community notes