Expose active network transport (Wi-Fi / Ethernet / Thread) and network diagnostics through the native API

[lboue]

Describe the Native API enhancement

ESPHome currently exposes basic device information through the native API (DeviceInfoResponse), but it does not expose how the device is connected to the network.

I propose extending the native API to expose generic network information, such as:

• Network transport (Wi-Fi / Ethernet / Thread)
• Network name (SSID or Thread network name)
• IP address(es)

This would allow Home Assistant and other API clients to display network information similarly to Matter devices, making it much easier to identify the active transport and troubleshoot connectivity issues.

Proposal

Extend the native API to expose generic network information.

Example:

enum NetworkType {
  NETWORK_TYPE_UNKNOWN = 0;
  NETWORK_TYPE_WIFI = 1;
  NETWORK_TYPE_ETHERNET = 2;
  NETWORK_TYPE_THREAD = 3;
}

message DeviceInfoResponse {
  ...

  optional NetworkType network_type = ...;
  optional string network_name = ...;
  repeated string ip_addresses = ...;
}

Use cases

ESPHome currently exposes basic device information through the native API (DeviceInfoResponse), such as:

• Device name
• MAC address
• ESPHome version
• Friendly name
• Manufacturer
• Model

However, there is currently no way for clients (e.g. Home Assistant) to determine how the device is connected to the network.

This becomes increasingly important as ESPHome gains support for additional networking technologies, especially Thread.

Today, Home Assistant cannot distinguish whether an ESPHome device is connected via:

• Wi-Fi
• Ethernet
• Thread

while the Matter integration already exposes this information in the device information panel.

Anything else?

Related context:

• Home Assistant's Matter integration already exposes network information (network type, network name, IP addresses, etc.) in the device information panel, making it easy to identify how a device is connected.

• ESPHome is expanding beyond Wi-Fi-only devices with support for Thread and other network transports. Exposing the active transport through the Native API would make the API transport-agnostic and future-proof.

• This information is device metadata rather than a sensor value, making DeviceInfoResponse a natural place to expose it.

Implementation would require coordinated changes in:

• ESPHome (api.proto)
• aioesphomeapi
• Home Assistant ESPHome integration

[lboue]

Related PR:

• [api] Expose the connected network type in DeviceInfoResponse esphome#18019
• [ethernet][network][wifi] Arbitrate the default route from the network priority list esphome#17797