[REQUEST] Custom name in Zeroconf DNS records for unique or generic automatic network discovery by ZHA

[Hedda]

@syssi Issue for discussion as know you already know that ZHA support network discovery (auto-detection) can work via Zeroconf.

What is missing is the use of a custom name in Zeroconf DNS record for unique or generic automatic network discovery by ZHA.

https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf

More information and discussion on the Zeroconf discovery idea concept for ZHA here:

https://community.home-assistant.io/t/zha-automatic-network-discovery-of-zigbee-coordinator-bridges-gateways-ethernet-wifi-network-adapters-that-support-zeroconf-or-ssdp/293300/

As suggested there. Maybe change it to new a general “ezsp” prefix or suffix name for generic ESPHome based Zigbee remote adapters using Silabs Zigbee radios, (and respectively “znp” as a new general prefix or suffix names for generic ESPHome based Zigbee remote adapters using Texas Instruments Zigbee radios).

Using "efr32" as the prefix or suffix name will not work in the long run as thinking a bit further ahead into the future since radio-adapters for the upcoming Matter over Thread radio adapters (with devices based on Matter over Thread becoming available next year) as those will also be based on the exact same Silicon Labs “EFR32” multi-protocol MCU and radio modules, incusing the EFR32MG21 chip, because the same models Silabs EFR32 chips also support both Zigbee and Thread (as well as other IEEE 802.15.4 based specifications too).

Therefor I think using “ezsp” instead should work since Thread radio-adapters for Matter will use OpenThread firmware that uses the the Spinel protocol instead, however, if would like to be absolutely sure that only adapters that have Zigbee firmware flashed then might need to add more DNS records in Zeroconf mDNS to for specifying that it specifically is a “Zigbee” radio adapter(?), perhaps by utilizing the new ZeroconfServiceInfo feature in ZHA?

home-assistant/core#60266

home-assistant/core#60206

home-assistant/architecture#662

By the way, @thegroove also started working on an updated variant with Zeroconf support for ZHA automatic discovery:

thegroove/esphome-zbbridge#1

https://github.com/thegroove/esphome-zha-ezsp-zeroconf

https://github.com/thegroove/esphome-zeroconf

https://github.com/thegroove/esphome-zeroconf/issues

As an example see this draft WIP PR posted here:

home-assistant/core#58224

For the ZHA side only two files updated compared to in the dev branch of Home Assistant core:

Only two files updated compared to in the dev branch of Home Assistant core:

https://github.com/Hedda/home-assistant/blob/bd3867159e8be82aad1ead38940d26d45472b143/homeassistant/generated/zeroconf.py#L79

    "_esphomelib._tcp.local.": [
        {
            "domain": "esphome"
        },
        {
            "domain": "zha",
            "name": "tube*"
        }
    ],
    "_esphome_ezsp_bridge._tcp.local.": [
        {
            "domain": "zha",
            "name": "esphome_ezsp_bridge*"
        }
    ],

https://github.com/Hedda/home-assistant/blob/bd3867159e8be82aad1ead38940d26d45472b143/homeassistant/components/zha/manifest.json#L25

"zeroconf": [
    {
      "type": "_esphomelib._tcp.local.",
      "name": "tube*"
    },
    {
      "type": "_esphome_ezsp_bridge._tcp.local.",
      "name": "esphome_ezsp_bridge*"
    }
  ],

[Hedda]

Suggest use a generic esphome node name like "esphome_zigbee_ezsp_bridge" and submit a PR for general "*zigbee*ezsp*"?

https://github.com/home-assistant/core/blob/dev/homeassistant/generated/zeroconf.py#L86-L94

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/manifest.json#L27-L31

While at it could perhaps also take the opportunity to also add a general "*zigbee*znp*" for Texas Instrument based bridges?

[Hedda]

FYI, Zero-configuration networking (zeroconf) looks to have been changed and improved in the Home Assistant 2022.02 release:

home-assistant/core#62133

https://www.home-assistant.io/integrations/zeroconf/

This change is only a concern for custom integration developers.

Currently zeroconf matching only allows matching the macaddress, model, and manufacturer properties along with the name from the ZeroconfServiceInfo.

Since properties are arbitrarily defined by the zeroconf service, the list of named properties has grown over time.

Matching now allows for any arbitrarily defined property. All property matches must be lowercase, wildcards are supported

The top level keys model, manufacturer, and macaddress are now deprecated from components manifest.json file and should be moved into a properties dict.

For example:

-    {"type":"_airplay._tcp.local.","model":"appletv*"}
+    {"type":"_airplay._tcp.local.","properties":{"model":"appletv*"}}

[Hedda]

By the way, Home Assistant founders/leads now explicitly said this year they will prioritize focus on features like these types:

https://www.home-assistant.io/blog/2022/01/19/streamlining-experiences/

Check out this video at around 11 min 55 sec in where talk about that focus point about making it easier to get started, etc.

https://www.youtube.com/watch?v=t_2D_KoFIfU&t=710s

Hopefully, it should be a greater chance of also getting more help from other Home Assistant developers with this if ask them.

[Hedda]

FYI, PR for ZiGate's Zeroconf has been merged in Home Assistant core making it an example for adding additional more readable:

home-assistant/core#68577

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/manifest.json#L85-L88

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/config_flow.py#L198-L201

https://github.com/home-assistant/core/blob/dev/tests/components/zha/test_config_flow.py#L80-L107

https://github.com/home-assistant/core/blob/dev/homeassistant/generated/zeroconf.py#L384-L389