Ten days after integration categories, Home Assistant core got the next piece of the same effort. A pull request merged on the evening of 26 October 2026 adds an optional connectivity key to the integration manifest. With it, an integration lists the protocols Home Assistant uses to reach its devices or service. The epic behind both changes also lists a Technology filter for the integrations page on home-assistant.io, which was left for later when the page went live on 17 October.

Protocols, not radios

The key holds a list of at least one value, with no repeats, and it covers everything an integration can use. It describes the protocol layer only. ZHA is zigbee, Z-Wave JS is zwave, and transports such as Thread or Wi-Fi are never values on their own. That is why the description of matter reads "over Thread, Wi-Fi or Ethernet", and homekit covers Wi-Fi, Thread and Bluetooth.

There are 22 values:

  • radio and wired home protocols: zigbee, zwave, matter, homekit, bluetooth, enocean, dect (DECT ULE, for example through a FRITZ!Box), insteon, x10, knx, dali, lorawan, onewire (1-Wire);
  • signals and buses: infrared, rf (sub-GHz radio such as 433 MHz remotes and sensors), modbus, serial;
  • mqtt for anything that goes through a broker, and esphome for devices using the ESPHome native API;
  • network (shown as "Local network") for devices and services on the LAN, cloud for internet services such as a manufacturer's cloud, and host (shown as "This machine") for the computer Home Assistant runs on.

Names and descriptions sit in core's translation strings, so they will be translated with the rest of the interface, and each value has an icon.

Checks and limits

Hassfest, the project's validation tool, generates a homeassistant/generated/integration_connectivity.json file and checks every value. An unknown value is an error in core and only a warning in custom integrations, the same approach as with categories. Entity, system and virtual integrations cannot use the key, and a virtual integration takes the values of the integration listed in its supported_by. The loader exposes the list to the rest of the code, and the frontend can already load the icons.

Nothing visible yet

No integration uses the key so far. The pull request says the values will be filled in by later pull requests, and it does not say where the information will show up. For now this is groundwork. Once manifests are filled in, it should be possible to see whether an integration needs a Zigbee radio, an MQTT broker or a cloud account before installing it, but where that will appear has not been announced.