home-assistant/core · warning · HomeAssistantError

frequency_not_supported

Error message

frequency_not_supported

What it means

HomeAssistantError with key frequency_not_supported, raised by _type_byte_for_frequency when the requested RF carrier frequency falls outside both supported ranges: 433.05–434.79 MHz and 314.95–315.25 MHz. The placeholder 'frequency' is the value formatted in MHz. It is a pre-transmit validation error: no packet is sent to the device.

Source

Thrown at homeassistant/components/broadlink/radio_frequency.py:40

_TICK_US = 32.84

_RF_433_TYPE_BYTE = 0xB2
_RF_315_TYPE_BYTE = 0xB4

_RF_433_RANGE = (433_050_000, 434_790_000)
_RF_315_RANGE = (314_950_000, 315_250_000)

SUPPORTED_FREQUENCY_RANGES: list[tuple[int, int]] = [_RF_433_RANGE, _RF_315_RANGE]


def _type_byte_for_frequency(frequency: int) -> int:
    """Return the Broadlink RF type byte for a given carrier frequency."""
    if _RF_433_RANGE[0] <= frequency <= _RF_433_RANGE[1]:
        return _RF_433_TYPE_BYTE
    if _RF_315_RANGE[0] <= frequency <= _RF_315_RANGE[1]:
        return _RF_315_TYPE_BYTE
    raise HomeAssistantError(
        translation_domain=DOMAIN,
        translation_key="frequency_not_supported",
        translation_placeholders={"frequency": f"{frequency / 1_000_000:g}"},
    )


def encode_rf_packet(
    *,
    type_byte: int,
    repeat_count: int,
    timings_us: list[int],
) -> bytes:
    """Encode raw OOK timings as a Broadlink RF pulse-length packet.

    The layout is::

        byte 0           type byte (0xB2 for 433 MHz, 0xB4 for 315 MHz)
        byte 1           repeat count (additional transmissions after the first)

View on GitHub (pinned to 58a3fdb3ea)

Solutions

  1. Set command.frequency to a value inside 433.05–434.79 MHz or 314.95–315.25 MHz.
  2. Verify the frequency encoded by the original remote (most Broadlink-compatible consumer gear is 433.92 MHz).
  3. If your gear is 868 MHz or another band, Broadlink devices cannot transmit it — use a dedicated transmitter.
  4. Check callers that construct InfraredCommand/RF commands to ensure frequency is populated, not 0.

Example fix

// before
command.frequency = 435_000_000  # outside supported range

// after
command.frequency = 433_920_000  # 433.92 MHz, inside _RF_433_RANGE
Defensive patterns

Strategy: validation

Validate before calling

SUPPORTED_RF_RANGES = [(433_050_000, 434_790_000), (314_950_000, 315_250_000)]

def is_supported_frequency(freq: int) -> bool:
    """Check the RF carrier is in a Broadlink-transmittable band."""
    return any(lo <= freq <= hi for lo, hi in SUPPORTED_RF_RANGES)

Type guard

def is_rf_frequency(value: object) -> bool:
    """Narrow to ints inside the supported 433/315 MHz ranges."""
    return isinstance(value, int) and any(lo <= value <= hi for lo, hi in SUPPORTED_RF_RANGES)

Try / catch

from homeassistant.exceptions import HomeAssistantError

try:
    await rf_entity.async_send_command(command)
except HomeAssistantError as err:
    if err.translation_key == "frequency_not_supported":
        command.frequency = 433_920_000  # correct the band and retry
        await rf_entity.async_send_command(command)
    else:
        raise

Prevention

When it happens

Trigger: Sending an RF command via the radio_frequency platform with command.frequency outside _RF_433_RANGE/_RF_315_RANGE — e.g. 435 MHz, 315.5 MHz (just above the 315 band), 868 MHz, or 0 (unset frequency in user-provided raw data).

Common situations: Imported/learned codes with wrong frequency metadata, hand-written RF payloads copied from 868 MHz (EU) device docs, or default/zero frequency fields from a caller that never set command.frequency.

Related errors


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