ZHA automatic discovery of Zigbee coordinator bridges/gateways (Ethernet/WiFi network devices) that support Zeroconf or SSDP?

Tags: #<Tag:0x00007fc3eb7ea2c8> #<Tag:0x00007fc3eb7ea188>

Please consider adding automatic network discovery to Home Assistant’s ZHA (Zigbee) integration.

UPDATE! Support for Zeroconf discovery has now been added to ZHA but only Tube’s gateways so far:


Home Assistant OS/Supervisor already have some automatic network scanning + discovery features and functions needed for automatically discovering some types of network services and devices, and each integration for Home Assistant can choose to optionally opt-in to utilize these automatic network discovery features/functions by adding Zeroconf section and SSDP section, etc. to their manifest.json as described in their documentation:



Reason for this “Service Discovery” / “Network Discover” request to Home Assistant’s ZHA developers that seeing more and more ser2net or com0com/com2tcp type network-attached Zigbee adapters (a.k.a. Zigbee bridge/gateway) that runs a serial-to-IP proxy-server application that basically only allows it to tunnel a serial connection over your local home network (a.k.a. ser2net type serial to TCP/IP bridges/proxy appliance server devices) to allow you to place the Zigbee coordinator for ZHA in the most optimal location.

From an end-user experience point-of-view, it would be very user-friendly if such devices could be automagically discovered by Home Assistant during the ZHA integration’s config flow for the initial installation and the adding of a network-attached Zigbee adapter.

As most ZHA users probably know about now, ZHA’s UI config flow today already allow to manually configure the serial device path to use a TCP/IP network socket (using socat) instead of a serial port:

  • ESPHome based DIY style bridge: socket://[IP]:[PORT] or socket://[FQDN]:[PORT] (if got local DNS), example socket://tube_zb_gw.local:6638
  • Sonoff ZBBridge if its ESP8266 hacked with Z2T (Zigbee2Tasmota): socket://[IP]:[PORT] for example socket://
  • ZiGate Gateway: socket://[IP]:[PORT] for example socket://
  • Xiaomi DGNWG05LM and ZHWG11LM gateways with Openlumi OpenWrt firmware: socket://[IP]:[PORT] for example socket://
  • Tuya TYGWZ-01 and Lidl Silvercrest gateways hacked for serial-to-ip: socket://[IP]:[PORT] for example socket://

I would think that the discovery features that is missing there and needs to be added are automatically discovered by the ZHA integration is the IP + TCP-port + radio-type + baud rate port speed + data flow control method, as only then the normal zigpy radio library probe methods could step in and take it from there to do its probing for the Zigbee radio firmware?

Anyway, such devices addressed via IP are already supported without auto-discovery by ZHA and zigpy and today include:

If support for Zeroconf and SSDP could be first added to ZHA inside Home Assistant then it might be more incentive to Zigbee gateway/bridge manufacturers to add needed discovering protocols to those?

mDNS and/or UPnP could be alternative network discovery methods but probably not as suited for Zigbee ser2net type bridges, or?


Zeroconf and/or SSDP is presumable better suited and again ZiGate WiFi and Tube’s Zigbee Gateways already supports those, or?



ESPHome which is very popular in the Home Assistant community is being used as ESP32 firmware by Tube’s Zigbee Gateways who sells both Texas Instruments and Silicon Labs based Zigbee gateways.


ESPHome can be auto-discovered by Home Assistant. If an instance was found, it will be shown in the top of the list of integrations as “Discovered”. If that is the case click on the Configure button to start setting up the discovered instance.

Tasmota based gateways could similarly be automatically discovered if the Tasmota device is configured for native discovery by the user:


ZiGate Gateway firmware does feature Zeroconf and the old ZiGate integration by @doudz also had for Zeroconf discover as a feature:



Note! See note stating; “If the integration supports zeroconf or ssdp , these should be preferred over dhcp as Zeroconf and SSDP generally offers a better user experience” at https://developers.home-assistant.io/docs/creating_integration_manifest/#dhcp

FYI; dmulcahey begun working on adding Zeroconf discovery for Tube’s Zigbee coordinators to ZHA:

Presumably, it could later also be extended to support other Zigbee bridges that also support Zeroconf.

@doudz Any chance you be willing to extend this to support for discovering of ZiGate WiFi Gateway?

EDIT: Pobably best now to see code used for Tube’s Zigbee Gateway as the reference implementation:


  - service: tubes_zb_gw
    protocol: tcp
    port: 6638
      version: 1.0
      radio_type: znp
      baud_rate: 115200
      data_flow_control: software

To whitelist Zeroconf for more radio types like “zigate” in HA’s zeroconf and ZHA need to do PR for:


 "_esphomelib._tcp.local.": [
            "domain": "zha",
            "name": "tube*"



"zeroconf": [
      "type": "_esphomelib._tcp.local.",
      "name": "tube*"

as well as:


async def async_step_zeroconf(self, discovery_info: DiscoveryInfoType):
        """Handle zeroconf discovery."""
        # Hostname is format: livingroom.local.
        local_name = discovery_info["hostname"][:-1]
        node_name = local_name[: -len(".local")]
        host = discovery_info[CONF_HOST]
        device_path = f"socket://{host}:6638"

        if current_entry := await self.async_set_unique_id(node_name):
                    CONF_DEVICE: {
                        **current_entry.data.get(CONF_DEVICE, {}),
                        CONF_DEVICE_PATH: device_path,

        # Check if already configured
        if self._async_current_entries():
            return self.async_abort(reason="single_instance_allowed")

        self.context["title_placeholders"] = {
            CONF_NAME: node_name,

        self._device_path = device_path
        self._radio_type = (
            RadioType.ezsp.name if "efr32" in local_name else RadioType.znp.name

I’ll take a look, it should be easy to add, but it requires Zigate Wifi firmware 2.x (firmware 1.3 doesn’t support mDns)

1 Like

Great! I believe that automatic discovery is another leap in making ZHA setup even more user-friendly.

But is mDNS support a prerequisite for this to work on ZHA side or is that only for the ZiGate firmware?

Reading the description by @bdraco in that PR #48420 it sounded as if it might work with IP too?

FYI, this PR for ZHA was merged 2-weeks ago but did not make it into Home Assistant 2021.4 release:

@bool2 Any chance you have time + interest to add auto-discovery to Tuya/Lidl/Silvercrest gateway?

Standard Zeroconf TCP broadcast with mDNS name should be supported as I understand, but then need to explicitly add it to ZHA:


mDNS uses packets similar to unicast DNS to resolve hostnames except they are sent over a multicast link. Each host listens on the mDNS port, 5353, transmitted to a well-known multicast address and resolves requests for the DNS record of its .local hostname (e.g. the A, AAAA, CNAME) to its IP address. When an mDNS client needs to resolve a local hostname to an IP address, it sends a DNS request for that name to the well-known multicast address; the computer with the corresponding A/AAAA record replies with its IP address. The mDNS multicast address is for IPv4 and ff02::fb for IPv6 link-local addressing. DNS Service Discovery (DNS-SD) requests can also be sent using mDNS to yield zero-configuration DNS-SD. This uses DNS PTR, SRV, TXT records to advertise instances of service types, domain names for those instances, and optional configuration parameters for connecting to those instances. But SRV records can now resolve to .local domain names, which mDNS can resolve to local IP addresses.

Home Assistant documentation has this information on Zeroconf in HA:



So far ZHA developers only explicitly added Zeroconf discovery of Tube’s ESPHome based gateways → Add discovery for Tube's Zigbee coordinators to ZHA by dmulcahey · Pull Request #48420 · home-assistant/core · GitHub

If gateway developers/hackers could script/hack Zeroconf broadcast configuration parameter types to ZiGate gateway and Tuya/Lidl/Silvercrest gateways as the first step then in a second step could explicitly add your chosen local record name to Home Assistant and set “zha” as the domain for HA to make ZHA discover ít:


Believe Zeroconf for ZHA needs to include hostname, port, baud rate, and local name which ZHA can translate into the radio type.


PS: Automatic discovery via Zeroconf or SSDP should further simply hacking and adding Tuya/Lidl/Silvercrest gateway to ZHA:


@bdraco Does Zeroconf support DNS-SD (Rendezvous) “TXT records” to pass values to integrations?


Could Zeroconf DNS-SD (DNS Service Discovery) pass “TXT record” values to integration config flow?

Example of config parameters that Zeroconf could be passed along to ZHA integration via TXT records:

  • radio_type=ezsp
  • baud_rate_speed=115200
  • data_flow_control=software
  • port=8888
  • protocol=tcp

TXT records could also be used to pass along ex. hostname, versions, location, MAC address, etc…


Each service instance is described using a DNS SRV and DNS TXT record. A client discovers the list of available instances for a given service type by querying the DNS PTR record of that service type’s name; the server returns zero or more names of the form ., each corresponding to a SRV/TXT record pair. The SRV record resolves to the domain name providing the instance, while the TXT can contain service-specific configuration parameters.


DNS Service Discovery (DNS-SD) requests can also be sent using mDNS to yield zero-configuration DNS-SD. This uses DNS PTR, SRV, TXT records to advertise instances of service types, domain names for those instances, and optional configuration parameters for connecting to those instances. But SRV records can now resolve to .local domain names, which mDNS can resolve to local IP addresses.


TXT record (short for text record) is a type of resource record in the Domain name system (DNS) used to provide the ability to associate arbitrary text with a host or other name, such as human readable information about a server, network, data center, or other accounting information. It is also often used in a more structured fashion to record small amounts of machine-readable data into the DNS.”

Yes, example: core/config_flow.py at d4ed65e0f53fcab991b13061b1101470f24287a6 · home-assistant/core · GitHub

1 Like

FYI, thegroove working on Zeroconf custom component (with DNS TXT records support) for ESPHome:


More information on the idea of using DNS TXT records for passing along setting parameters to ZHA:


FYI, Tube’s Zigbee Gateways are now (only) devices listed for ZHA as discoverable via Zeroconf, see:


Hi, we are working on firmware for ZigStar LAN Coordinator ,we included zerconf in the firmware.
But unfortunately till now I didnt understand how to submit a PR and what information should be provided.

@Hedda @doudz Can i get some help with this?