home-assistant/core · error · AbortFlow

not_supported

not_supported

Error message

not_supported

What it means

AbortFlow with reason 'not_supported', raised in the Broadlink config flow's async_set_device when the discovered device's type is not in the DEVICE_TYPES mapping of known Broadlink device types. The flow logs an unsupported-device error (with hex devtype) and aborts, directing users to open a core issue. Aborting differs from raising an error: it terminates the flow with the 'not_supported' reason shown in the UI.

Source

Thrown at homeassistant/components/broadlink/config_flow.py:54

    """Handle a Broadlink config flow."""

    VERSION = 1

    device: blk.Device

    async def async_set_device(
        self, device: blk.Device, raise_on_progress: bool = True
    ) -> None:
        """Define a device for the config flow."""
        if device.type not in DEVICE_TYPES:
            _LOGGER.error(
                (
                    "Unsupported device: %s. If it worked before, please open "
                    "an issue at https://github.com/home-assistant/core/issues"
                ),
                hex(device.devtype),
            )
            raise AbortFlow("not_supported")

        await self.async_set_unique_id(
            device.mac.hex(), raise_on_progress=raise_on_progress
        )
        self.device = device

        self.context["title_placeholders"] = {
            "name": device.name,
            "model": device.model,
            "host": device.host[0],
        }

    @override
    async def async_step_dhcp(
        self, discovery_info: DhcpServiceInfo
    ) -> ConfigFlowResult:
        """Handle dhcp discovery."""
        host = discovery_info.ip

View on GitHub (pinned to 58a3fdb3ea)

Solutions

  1. Update Home Assistant to the latest version — new device types are added to DEVICE_TYPES over time.
  2. Verify the device's devtype in the log line ('Unsupported device: 0x...') and check the home-assistant/core issue tracker; open an issue with the hex code if none exists.
  3. As a workaround, some clones work by temporarily mapping the devtype in DEVICE_TYPES locally (not upgrade-safe).
  4. Ensure the device is a genuine Broadlink on the local network and not a misidentified host.
Defensive patterns

Strategy: validation

Validate before calling

from homeassistant.components.broadlink.device import DEVICE_TYPES  # or component constant

def is_supported_devtype(devtype: int) -> bool:
    """Check the device type is mapped before starting a config flow."""
    return devtype in DEVICE_TYPES

Try / catch

from homeassistant.data_entry_flow import AbortFlow

try:
    await flow.async_step_user(...)
except AbortFlow as err:
    if err.reason == "not_supported":
        _LOGGER.info("Device 0x%x unsupported; ask user to update HA", devtype)
    raise

Prevention

When it happens

Trigger: Discovering or manually configuring a Broadlink device whose devtype integer is absent from the component's DEVICE_TYPES dict — typically a new or OEM-rebadged Broadlink model (e.g. new firmware revision) that the broadlink pip package knows but HA's mapping does not, or vice versa.

Common situations: Newly released Broadlink hardware (RM4 mini variants, rebadged OEM units), broadlink package updated to add a devtype before HA adds config support, fake/clone devices reporting unusual devtypes.

Related errors

AI-assisted analysis of home-assistant/core@58a3fdb3ea (2026-08-14). Data as JSON: /api/errors/510b4473f28925b3. Report an issue: GitHub.