# OpenCCU: a cloud-free CCU3 replacement you can run on a Pi, a VM or Docker > OpenCCU is the renamed RaspberryMatic project: a Buildroot-based operating system that replaces eQ-3's CCU3 firmware while keeping Homematic and Homematic IP hardware, WebUI and backups interchangeable. It is for people who want their smart home hub off the vendor cloud and on hardware they control. **OpenCCU/OpenCCU** — Buildroot-based, cloud-free smart-home platform for a Homematic IP CCU (CCU3/ELV-Charly). Runs on Raspberry Pi & x86/ARM or as a virtual appliance (Proxmox VE, Home Assistant, Docker/LXC/K8s)... - Repository: https://github.com/OpenCCU/OpenCCU - Website: https://openccu.de - Stars: 1,835 · Forks: 222 - Language: JavaScript - License: Apache-2.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/openccu-openccu ## The problem OpenCCU solves: a hub that does not phone home Homematic and Homematic IP devices talk to a central control unit, the CCU. eQ-3 sells that as the CCU3 and ELV sells it as Charly. The firmware on those boxes is closed, and the vendor cloud sits in the path for remote access and some services. OpenCCU, previously known as RaspberryMatic, is an open-source operating system that runs the same job on hardware you own. The README describes it as a "free, non-commercial, open-source operating system for running a cloud-free smart-home hub" and claims 100% compatibility with the vendor CCU3. The audience is narrow and specific. You need to have Homematic or Homematic IP gear already, because OpenCCU speaks that radio protocol and nothing else. If you are starting from zero with Zigbee or Z-Wave sensors, this is the wrong project entirely. The second group is people who already run a CCU2 or CCU3 and want to move off it without rebuilding their device setup. That migration path is the reason the project exists in its current form. ## Buildroot, defconfigs and how a CCU image actually gets built OpenCCU is not an application you install into an existing Linux. It is a Linux distribution built by Buildroot, pinned in the top-level Makefile to Buildroot 2026.08 with a SHA256 checksum that the build verifies after downloading the tarball. That pinning matters: it means the toolchain, kernel and userspace are fixed per release rather than tracking a rolling distro. The Makefile derives the product list from defconfig files under buildroot-external/configs, stripping the architecture suffix to get a platform name. A build is not parallel across products, which the Makefile enforces with a .NOTPARALLEL declaration, so building several targets at once is deliberately serialised. The version string is assembled from two places: OPENCCU_BASE_COMPAT_VERSION and OPENCCU_BASE_VERSION in buildroot-external/package/openccu-base/openccu-base.mk, plus the build date. That is why release tags look like 3.89.8.20260719 and 3.87.6.20260614: the first three components come from the base package, the trailing number is the build date. On first boot the system probes for Homematic and Homematic IP RF modules such as RPI-RF-MOD and HmIP-RFUSB over GPIO or USB. That detection step is the whole point of the hardware compatibility matrix. The radio module is what makes a generic x86_64 box into a CCU. ## Installing OpenCCU on a Raspberry Pi and reaching the WebUI The README's Quick-Start is four steps: download, install, boot, open the WebUI. Images live under Releases and follow the filename pattern OpenCCU-X.XX.XX.YYYYMMDD-.zip, where the target identifies the board. For a Raspberry Pi you unzip the archive and flash the .img file to a microSD card. The README names Etcher and dd as the two options but does not print a literal command, so the graphical route it links to is the one to follow if you want to stay inside documented territory. Insert the card, power the Pi with the RF module attached, and wait for first boot. OpenCCU detects the radio module automatically. The README then gives the WebUI address to open in your browser: ```bash http://openccu/ ``` If name resolution does not work on your network, the README says to use the DHCP-assigned IP instead. You land in the familiar CCU WebUI. From there, the optional next step is restoring an existing CCU backup, which the README describes as cross-compatible between vendor firmware and OpenCCU. That is the migration path for anyone coming from a CCU2 or CCU3: upload the OpenCCU package as a regular firmware update rather than reflashing hardware. The README does not document a command-line restore, so the WebUI is where that happens. ## Virtual appliances: Proxmox, Docker and the Home Assistant add-on Not everyone wants another box on the shelf. The README lists Proxmox VE, QEMU/KVM, XCP-ng/XenServer, VMware ESXi and Workstation Player, Hyper-V, VirtualBox, Synology Virtual Machine Manager, QNAP Virtualization Station and Unraid as supported hypervisors, plus Docker/OCI, LXC and Kubernetes as container platforms. There is also a native Home Assistant add-on, and the repository carries separate add-on directories for the base add-on, a proxy and an hapdrap variant. The trade-off here is real and the README does not hide it so much as leave it implicit. A virtual CCU still needs a physical radio path. Running OpenCCU in a container on a NAS only makes sense if an RF module is reachable from that host, typically over USB passthrough. A Proxmox VM on a machine with no Homematic radio attached will boot, serve the WebUI and control nothing. The container images are convenient for people who already have the radio exposed; they are not a way to skip the hardware. Kubernetes support is listed, which invites the question of why anyone would run a smart home hub as a cluster workload. The honest answer is that the project supports it, not that it is a common deployment. Treat the hypervisor and container lists as a compatibility statement, not a recommendation. ## What OpenCCU does not do well The compatibility claim cuts both ways. OpenCCU targets 100% CCU3 parity, which means it inherits the CCU3's architecture, its WebUI and its add-on ecosystem rather than replacing them. If you were hoping for a modern API-first hub, this is not it. The enhancements listed in the README are WebUI improvements, Linux OS updates, and stability and performance fixes, described as things that "do not yet exist upstream". That is an incremental pitch, not a redesign. The documentation is another constraint. The wiki has a German home and an English home, but the README's own deep links point at German pages such as Einleitung, Installation and Installation-RaspberryPi. The wiki has a Limitations page, which tells you the project tracks its own gaps, but you will be reading German for anything beyond the Quick-Start. There is also a hardware trap. The README lists CCU3, ELV Charly, Raspberry Pi, ODROID, Tinkerboard 2/2S and generic x86_64/aarch64, but a supported board without a supported RF module is a hub with no radios. And because OpenCCU is a full operating system rather than a package, you cannot install it alongside an existing Linux install on the same disk without repartitioning. That is a different commitment from adding a Home Assistant integration. ## OpenCCU against debmatic and the vendor CCU3 The comparison people actually search for is OpenCCU versus debmatic, and the split is architectural. debmatic is a set of Debian packages that install the CCU software stack onto an existing Debian or Raspberry Pi OS system. You keep your operating system, your package manager and your other services, and the CCU daemons run alongside them. OpenCCU goes the other way: it ships the operating system, built with Buildroot, and the CCU stack is the reason the image exists. That difference decides most adoption questions. If you want one Raspberry Pi doing Pi-hole, a backup target and a CCU, debmatic fits that shape better, because OpenCCU expects to own the machine. If you want a deterministic, versioned appliance where the kernel and userspace are pinned together and validated as a unit, OpenCCU's Buildroot approach is the stronger fit. The same logic applies against the vendor CCU3: OpenCCU claims drop-in compatibility and backup interchangeability, so the migration cost is low, but you take on the upgrade cadence yourself. Releases here are frequent, with 3.87.6.20260509, 3.87.6.20260614 and 3.89.8.20260719 all landing between May and July 2026. The last push to the repository was on 2026-07-20. ## Licence and the cost of keeping a hub current OpenCCU is Apache-2.0 licensed. The README describes the project as free and non-commercial, and the wiki carries dedicated pages for License and Warranty and for Commercial Distribution, which is the signal that redistribution inside a paid product is a topic the project has thought about. Apache-2.0 permits commercial use and modification, and it includes a patent grant and a warranty disclaimer. If you plan to ship OpenCCU inside a product or a managed service, read the Commercial Distribution wiki page and the LICENSE file rather than assuming the non-commercial framing in the README is the legal position. That is a documentation question, not a legal opinion, and it deserves a lawyer if money is involved. The upgrade cost is the practical one. Because OpenCCU is a whole operating system, updating means replacing the image or uploading a new package, not running apt upgrade. The README's migration path treats OpenCCU as a firmware update you upload, which is a clean model for a hub but a poor fit for anyone who expects unattended patch management. Backups are the safety net, and they are cross-compatible, so a rollback is a restore rather than a reinstall. The README does not document an in-place rollback beyond that. ## Conclusion Adopt OpenCCU if you already own Homematic or Homematic IP devices and want the hub on your own hardware, with CCU3-compatible WebUI and backups. Do not adopt it if you need vendor support or a plug-and-play appliance: you are flashing images, choosing RF modules and reading a wiki that is mostly German. Before you commit, verify three things on your own hardware: that your RF module is detected on first boot, that your CCU backup restores, and that your add-ons behave under the current 3.89.8.x release rather than the older 3.87.6.x line. ## FAQ ### How can I use OpenCCU with Home Assistant? The README lists a native Home Assistant App among the supported deployment targets, and the repository contains home-assistant-addon directories plus a repository.json for add-on distribution. That is the supported route rather than a separate integration you install inside Home Assistant. ### What is the difference between OpenCCU and CCU3? OpenCCU targets 100% compatibility with the vendor CCU3 and can be installed directly on CCU3 and ELV Charly hardware. The difference is that OpenCCU is an open-source operating system with WebUI, OS-level and connectivity enhancements that the README says do not yet exist upstream, while the CCU3 runs eQ-3's own firmware. ### How does OpenCCU compare with debmatic? The README does not describe debmatic's internals, so the comparison here is limited to deployment shape: OpenCCU is a Buildroot-based operating system image that owns the device, whereas debmatic adds the CCU software stack as packages to an existing Debian system. ### Is OpenCCU the same project as RaspberryMatic? Yes. The README states that OpenCCU was formerly known as RaspberryMatic. The name changed, and the repository is now OpenCCU/OpenCCU. ### How does OpenCCU compare with pivccu? The README does not cover pivccu, so no comparison can be made from it. What is documented is that OpenCCU supports hypervisors including Proxmox VE, QEMU/KVM, VMware ESXi and Hyper-V, plus Docker/OCI, LXC and Kubernetes, and that a virtual deployment still needs a reachable RF module. ### What are the alternatives to OpenCCU? The README names debmatic as a package-based approach and the vendor CCU3 and ELV Charly as the commercial hardware it replaces. It does not evaluate any other alternative, and it does not state that OpenCCU is better than any of them. ## Sources - [Official documentation](https://openccu.de) - [Official README](https://github.com/OpenCCU/OpenCCU#readme) - [Project repository](https://github.com/OpenCCU/OpenCCU) - [Release notes](https://github.com/OpenCCU/OpenCCU/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openccu-openccu