Hi Simon,
I wonder, are you still a legacy RAKO user with homeassistant knowledge?
Things have been ticking along fine until the 2026.3 update, when the RAKO integration refused to load properly:
ImportError: cannot import name ‘SUPPORT_BRIGHTNESS’ from ‘homeassistant.components.light’ (/usr/src/homeassistant/homeassistant/components/light/init.py)
This all looks a little terminal!
Wondering if you may have a view on this?
Regards
Andy
I asked Claude Code to inspect the rako integration in general terms and also to look at the SUPPORT_BRIGHTNESS issue. It was quite helpful, although I’ve not implemented it’s recommended changes yet.
Done. Here's a summary of the custom_components/rako integration:
Overview: A Home Assistant custom integration for Rako lighting control, backed by the python_rako==0.0.14 library. It's a local push (iot_class: local_push) integration.
Files:
init.py — Sets up the integration from a config entry, registers the bridge device, and forwards setup to the light platform.
manifest.json — Integration metadata, requires python_rako==0.0.14.
bridge.py — Extends python_rako.Bridge with HA-specific logic: manages a registry of RakoLight entities and runs a background asyncio task listening for UDP multicast state updates (scenes/channel brightness changes).
light.py — Defines three light classes:
RakoLight — abstract base, handles state registration/deregistration, brightness tracking, and device_info.
RakoRoomLight — controls a whole room via scenes (brightness → scene number conversion).
RakoChannelLight — controls individual channels with direct brightness values.
config_flow.py — UI config flow that auto-discovers the bridge via UDP, then lets the user confirm/override host, port, MAC, and name.
model.py — RakoDomainEntryData TypedDict storing the bridge client, light map, and listener task per config entry.
util.py — Single helper create_unique_id(bridge_mac, room_id, channel_id) → "b:{mac}r:{room}c:{channel}".
Notable: Uses SUPPORT_BRIGHTNESS (a deprecated constant in newer HA versions — replaced by ColorMode/LightEntityFeature). There's also a comment in __init__.py noting a fix for a HA 2023.5.2 breaking change in the device registry API.
When I upgrade to HA 2026.3.4 the integration fails to start and gives the following error:
Logger: homeassistant.setup
Source: setup.py:343
First occurred: 08:24:21 (1 occurrence)
Last logged: 08:24:21
Setup failed for custom integration 'rako': Unable to import component: cannot import name 'SUPPORT_BRIGHTNESS' from 'homeassistant.components.light' (/usr/src/homeassistant/homeassistant/components/light/__init__.py)
ort.
The error is exactly as I flagged when reading the code earlier: SUPPORT_BRIGHTNESS was removed from homeassistant.components.light in a recent HA version.
Root cause: light.py:12-16 imports SUPPORT_BRIGHTNESS, which no longer exists. It's also used at light.py:122 in the supported_features property.
What needs to change in light.py:
Replace the SUPPORT_BRIGHTNESS import with ColorMode.
Remove the supported_features property (returns SUPPORT_BRIGHTNESS).
Add a supported_color_modes property returning {ColorMode.BRIGHTNESS}.
Add a color_mode property returning ColorMode.BRIGHTNESS.
That's the full extent of the change needed — everything else in the integration is unaffected.
I’ve started to hit a particular issue today after adding circa 15 entities to my Rako system/Hub. I’m using Princekama integration which has been top notch and very stable. This issue I’m now faced with is I have close to 280 entities and I seem to be hitting some sort of limits and HA isn’t able to grab the status of all entities, so is sending all entities “unavailable”. When the Rako Hub restarts all entities have blank dimming %'s - so I have to set these all via the app or keypads to a 0-100% - hit the reload on the integration and HA grabs the status. This was fine with about 260 entities, but now I’m trying to grab more once I hit this tipping point they all go unavailable. For now I’ve left some none critical entities. Anybody else come across this or any fixes/workarounds?
A couple of ideas for you:
Thanks for the reply, yes on latest version of stuff and latest Hub. It seems to be the client read limit in the rakopy file is being hit and gives a “LimitOverrunError” on reload which the reports all entities unavailable. The rakopy file seems to have a 64KB limit, so increasing this should resolve but I’m guessing that is something @princekama controls?
Hi Andy,
Still a Rako user, yes. That error means you were running the original legacy code (the old forum zip / abandoned core-PR version), which imports a constant Home Assistant has since removed. That codebase is dead, but it has a maintained successor.
I maintain it as a HACS custom integration, and it’s just had a major overhaul (v0.7.0): rebuilt state tracking that stays in sync with the bridge (echo-verified commands + periodic reconciliation), keypad button presses exposed as Home Assistant events for automations, fan/ventilation support, and it’s tested against current HA (needs HA 2026.2 or newer ).
To switch:
rako folder from config/custom_components/.https://github.com/SimonLeigh/hacs_rako (category: Integration).If anything misbehaves, open an issue on the repo with logs and I’ll take a look.
Regards, Simon