Homematic(IP) Local for OpenCCU keeps HomeMatic traffic off the cloud

The point is that the hub talks to Home Assistant directly

HomematicIP Local for OpenCCU is a custom integration for Home Assistant that connects to a local Homematic hub. The summary at the top of the README states the value proposition in a single clause: a local Home Assistant integration for Homematic(IP) hubs, CCU2/3, OpenCCU, Debmatic and Homegear, with no cloud required.

That last phrase is the whole point of the project, and it also positions it against the alternatives listed in the related integrations table. There is the official Homematic(IP) Cloud integration, which connects through the Homematic IP Access Point, and there is a separate Homematic IP Local integration for the HmIP-HCU1. This project is the third option, the one for people with a classic or OpenCCU-style hub they own and control.

The communication model is described in one line and it explains the port table later on. Local XML-RPC is used for control and push state updates, and JSON-RPC is used for names and rooms. So the integration keeps a push channel open for device state, which is what makes a Homematic wall thermostat appear in Home Assistant within a moment of pressing a button, and it uses a separate request channel for the metadata Home Assistant needs to name things sensibly.

Installation is HACS recommended with manual installation supported, and auto-discovery is supported for CCU and compatible hubs. The minimum requirement is Home Assistant 2026.9.0 or later, and for Homematic IP on a CCU the hub needs to be at least CCU2 2.61.x or CCU3 3.61.x.

The supported hardware list is exhaustive, and that is the point

The requirements section lists the supported hardware and then makes a promise about it.

The list is CCU2/3, OpenCCU, Debmatic and Homegear, plus Home Assistant OS or Supervised with a suitable add-on and a communication device.

The note attached to that list is unusually firm. It says the list is exhaustive, that third-party hubs which reimplement the CCU interfaces, XML-RPC, JSON-RPC and ReGa, are not supported even if they appear to work, and that issues reported against such a setup are closed without further assessment.

That is a support policy rather than a technical limitation, and it is a defensible one. A hub that reimplements the interfaces partially produces bugs that look like integration bugs, and a maintainer who tries to support every such device ends up debugging other people's firmware. Declaring the boundary in the README saves everybody the argument.

The same note appears in the summary as a pointer to the complete, exhaustive list, which tells you the maintainer expects people to check the list before reporting. The consequence for a user is simple: if your hub is on the list, the integration is the right tool, and if it is not, the answer is to run one of the listed hubs or to use the cloud integration instead.

The word Debmatic in that list is worth pausing on, since it is a fork of the CCU firmware rather than a vendor product, and its presence alongside Homegear shows the practical scope of the project rather than a purely commercial one.

Five ports, and the reason each one is open on your network

The required ports table is the part of the README that will make or break an installation, because a Home Assistant instance usually runs on a different host or in a container and the hub sits on the local network.

| HomematicIP (HmIP-RF) | Wireless/wired HmIP devices | 2010 | 42010 |
| Homematic (BidCos-RF) | Classic wireless devices | 2001 | 42001 |
| Homematic Wired | Classic wired devices | 2000 | 42000 |
| Virtual Devices | Heating groups | 9292 | 49292 |
| JSON-RPC | Names and rooms | 80 | 443 |

Each row is an interface of the hub rather than a feature of the integration, and the last column is the port the same interface uses for TLS. The XML-RPC interfaces are the three radio and wired paths, 2010 for Homematic IP, 2001 for BidCos RF and 2000 for the classic wired bus, and 9292 is for virtual devices, which is where heating groups live. JSON-RPC is the metadata interface and it is the one that uses the ordinary web ports, 80 and 443, which is why a hub on a mixed network often has those blocked.

The authentication section adds the detail that matters for a fresh install. Admin privileges are required on the CCU, the allowed password characters are limited to letters, digits and a short set of punctuation marks, and XML-RPC authentication is recommended, which the README locates in the control panel under the security settings.

The limited password character set is the sort of thing that surfaces only at setup time, when a user tries the password they already use everywhere else and it happens to contain a character the hub will not accept.

Beyond the entities: a parameter editor, blueprints and cards

The integration does more than expose entities, and the three extras are each aimed at a different user.

The device configuration panel is a built-in sidebar panel for editing Homematic device MASTER parameters directly from the Home Assistant interface. You browse configurable devices grouped by interface, see details including reachability, RSSI and firmware, edit MASTER paramset values per channel with auto-generated forms using sliders, toggles and dropdowns, validate the changes before they are written, and reset parameters to factory defaults. It is off by default and is enabled in the advanced options of the integration entry, and it requires admin access and is not visible to non-admin users.

The blueprints are ready-made automations in a blueprints/automation directory. There is support for 2, 4, 6 and 8 button remotes, persistent notifications for unavailable devices, device reactivation helpers and error event handlers, and you copy the files you want into your own blueprint directory. The button blueprints react to the event entities of the selected device, one per button channel, and those are enabled by default, so a button whose event entity you have disabled or hidden cannot trigger the automation, and they require Home Assistant 2026.8 or newer. The other blueprints are driven by the integration's own events, with a reference page mapping which parameters trigger which event, and the README notes that CCU service messages such as CONFIG_PENDING and UPDATE_PENDING are not events but are available through a dedicated hub service messages sensor.

The companion cards are custom dashboard cards, and community blueprints and cards are accepted by pull request, so the integration is a platform with an ecosystem rather than a fixed feature set.

The development setup is unusually disciplined for a custom component

The repository carries the tooling of a maintained project rather than a script that happened to work on one machine.

The Makefile is the entry point, with a default help target and targets for the virtual environment, formatting, linting, type checking, tests, and validation. The virtual environment is created with Python 3.14 by default, the package under test is custom_components/homematicip_local, and the tests live in tests. Every target runs through a wrapper script that activates the virtual environment if it is present, so the targets work whether or not you have an environment active.

The linting configuration is the interesting part, because the pylint section lists its own reasons for disabling rules. Format is handled by black, duplicate code is called unavoidable, cyclic imports are not tested on load, and the too-many and too-few argument and ancestor rules are not enforced for the sake of readability, with a note that the wrong import order is guarded by isort instead. Each disabled check has a reason attached, and some are marked to be enabled once the current issues are fixed. That is a maintainer telling you what the debt is.

There is also a mypy target, a bandit target for security checks, codespell, yamllint, prettier, a pre-commit runner with a manual variant, and translation targets including a sorting step for class members, which is what keeps entity names stable across languages.

Validation runs against official container images: the Hassfest image for Home Assistant integration validation and the HACS action image for the HACS repository check, both pulled from the ghcr registry.

Release cadence, and the version constraints to check first

The project moves fast and states its constraints clearly.

The published releases are 2.12.1 on 2026-10-18, 2.12.0 on 2026-10-16 and 2.11.1 on 2026-09-10, and the last push was on 2026-10-19. Two releases three days apart in the same minor line, followed by a patch, is the pattern of a project that ships changes as they land rather than batching them.

The constraints to check before installing are in the summary. Home Assistant 2026.9.0 or later is required, and for Homematic IP on a CCU the hub must be at least CCU2 2.61.x or CCU3 3.61.x. Those are recent floors, which tells you the integration tracks the current Home Assistant release cycle closely, and it also means an installation on an older Home Assistant will not work.

The installation procedure has two paths. Through HACS you go to the HACS integrations list, search for the integration by name, install it and restart Home Assistant when prompted. Manually you copy the custom_components/homematicip_local directory into your Home Assistant config/custom_components directory and restart, and the README notes that manual installation does not support automatic updates. After either path you add the integration through the devices and services settings.

The licence is MIT, so the component can be redistributed and modified freely, which matters for a custom component that other people may want to run on hardware you do not support.

Editorial conclusion

This integration fits a HomeMatic owner who wants the hub to stay on the local network, who runs Home Assistant 2026.9.0 or later, and who can open the five hub ports listed in the README. It does not fit a user of the Homematic IP Access Point cloud path or of the separate HCU1 integration, or someone running a third-party hub that reimplements the CCU interfaces, since the README states those are not supported. Before you install, read the supported hardware note and confirm your hub firmware meets the stated minimums, and use HACS rather than a manual copy if you want automatic updates, because manual installation does not support them.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SukramJ/homematicip_local on GitHub