home-assistant/core · warning · InvalidDeviceAutomationConfig

BTHome trigger {event_class} is not valid for device_id '{de

Error message

BTHome trigger {event_class} is not valid for device_id '{device_id}'

What it means

InvalidDeviceAutomationConfig raised by BTHome device-trigger validation when the configured event class (CONF_TYPE, e.g. 'button_1', 'dimmer', 'command') is not in the device's discovered event classes. Event classes are learned dynamically: BTHome events are recorded in the config entry's CONF_DISCOVERED_EVENT_CLASSES data the first time the BLE device emits them. This error aborts automation/UI validation, not runtime event handling.

Source

Thrown at homeassistant/components/bthome/device_trigger.py:98

    event classes like button_1 button_2, button_3, etc
    but if there is only one button then it will be
    button without a number postfix.
    """
    return EVENT_TYPES_BY_EVENT_CLASS.get(event_class.split("_", maxsplit=1)[0], set())


async def async_validate_trigger_config(
    hass: HomeAssistant, config: ConfigType
) -> ConfigType:
    """Validate trigger config."""
    config = TRIGGER_SCHEMA(config)
    event_class = config[CONF_TYPE]
    event_type = config[CONF_SUBTYPE]
    device_id = config[CONF_DEVICE_ID]
    event_classes = get_event_classes_by_device_id(hass, device_id)

    if event_class not in event_classes:
        raise InvalidDeviceAutomationConfig(
            f"BTHome trigger {event_class} is not valid for device_id '{device_id}'"
        )

    if event_type not in get_event_types_by_event_class(event_class):
        raise InvalidDeviceAutomationConfig(
            f"BTHome trigger {event_type} is not valid for device_id '{device_id}'"
        )

    return config


async def async_get_triggers(
    hass: HomeAssistant, device_id: str
) -> list[dict[str, Any]]:
    """Return a list of triggers for BTHome BLE devices."""
    event_classes = get_event_classes_by_device_id(hass, device_id)
    return [
        {

View on GitHub (pinned to 58a3fdb3ea)

Solutions

Press/actuate the physical control once so the BLE event fires and discovery records its class, then re-validate.
Use the automation UI's trigger picker, which lists only discovered event classes for that device.
Re-pair the device if the config entry's discovered list is stale after firmware changes.
For sensor-only devices, remove the trigger — they emit no events.

Example fix

# before (invalid until the device has emitted the event)
trigger:
  - platform: device
    domain: bthome
    device_id: "..."
    type: button_2
    subtype: press
# after — first press button_2 on the device, then re-add via UI picker, or use a type already in the device's discovered classes
trigger:
  - platform: device
    domain: bthome
    device_id: "..."
    type: button_1
    subtype: press

Defensive patterns

Strategy: validation

Validate before calling

# check discovered event classes before writing YAML
# Developer Tools > Template:
{{ config_entry_attr(device_attr(device_id, 'config_entries')[0], 'data').discovered_event_classes }}

Type guard

def trigger_type_is_discovered(hass: HomeAssistant, device_id: str, event_class: str) -> bool:
    dr_entry = dr.async_get(hass).async_get(device_id)
    if dr_entry is None:
        return False
    entry = next(
        (hass.config_entries.async_get_entry(e) for e in dr_entry.config_entries
         if hass.config_entries.async_get_entry(e) and hass.config_entries.async_get_entry(e).domain == "bthome"),
        None,
    )
    return entry is not None and event_class in entry.data.get("discovered_event_classes", [])

Prevention

Actuate each physical control once after pairing so discovery records its event class.
Build triggers through the UI picker, which only lists discovered classes.
Re-pair the device after firmware changes that alter its BTHome device type.

When it happens

Trigger: Validating a trigger whose type references a control the device has never emitted — e.g. 'button_2' on a one-button device, or any class on a sensor-only device — because `get_event_classes_by_device_id` returns the entry's (possibly empty) discovered list. Stale automations after re-pairing also hit this.

Common situations: Hand-written YAML automations using guessed types; automations created before a device firmware change altered its BTHome advertisement; devices whose buttons were never pressed since being added, so discovery hasn't recorded the class; device re-paired producing a new config entry without history.

Related errors

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