The protocols at a glance
- mDNS / DNS-SD (Zeroconf, Bonjour, Avahi): devices announce themselves by multicast on the local network, and clients query for services. Home Assistant's zeroconf integration is on by default, discovers supported devices, and also makes Home Assistant discoverable by other services. HA has a Zeroconf Browser under Settings > System > Network that shows what it has seen.
- SSDP (part of UPnP): another multicast protocol, used by smart TVs, media servers, printers and routers. Home Assistant's SSDP integration scans for supported devices and has an SSDP/UPnP Browser in the same place.
- WS-Discovery: a multicast discovery protocol used by many printers and Windows machines, and by ONVIF IP cameras. Nmap's NSE script broadcast-wsdd-discover uses a multicast query to find WS-Discovery devices, and the Python package WSDiscovery (a pip install) includes a wsdiscover command-line client.
- SNMP: not discovery, but monitoring. Many routers, access points, switches and printers support SNMP, a standard for reading (and sometimes setting) values in a tree of OIDs. Home Assistant has SNMP sensor, switch and device tracker platforms. Versions 1 and 2c authenticate with a plain "community" string (often "public" by default). SNMPv3 adds proper authentication and encryption.
- ICMP (ping) and ARP scans: the simplest "is it there?" check. HA's Ping (ICMP) integration polls a host every 30 seconds by default and gives a binary sensor and some round-trip sensors. The Nmap Tracker integration scans address ranges you specify.
- Multicast does not cross subnets or VLANs. mDNS, SSDP and WS-Discovery are link-local. If your IoT devices sit on a separate VLAN from Home Assistant, discovery will quietly fail. Options: give Home Assistant a network interface in the IoT VLAN, add devices manually by IP, or use an mDNS repeater/reflector on your router or on Avahi. A reflector punches a hole in your segmentation, so allow only the services you need, ideally from a specific VLAN pair.
- Virtual machines: Home Assistant's zeroconf page notes that a libvirt macvtap adapter, by default, does not let the guest receive multicast or Zeroconf traffic and describes a trustGuestRxFilters setting to fix it. Other hypervisors have similar bridge or multicast issues.
- Wi-Fi extras: some access points filter multicast to save airtime (IGMP snooping, "multicast to unicast", client isolation). If devices are visible on wired but not Wi-Fi, check these.
- Phones sleeping: the Nmap Tracker docs caution that modern phones usually turn Wi-Fi off when idle, so ping- or scan-based presence is not reliable on its own.
- Docker host network: containers on a bridge network cannot see multicast. Home Assistant Container usually needs host networking for discovery to work.
- SNMP v1/v2c with the default "public" community leaks device information in clear text, and a writable "private" community can allow changes. Prefer SNMPv3 with authentication and privacy keys, enable read-only access, and restrict it to your monitoring host.
- UPnP on your router can open ports to the internet automatically. Turn it off on the router's WAN side unless you know you need it.
- Network scanners are noisy. Only scan networks you own or have permission to scan, and keep scan ranges small on shared networks.
- Discovery reveals device names and services. Keep guest and IoT networks isolated from your main devices.
- Look at HA's Zeroconf and SSDP browsers to see what is visible from where HA lives.
- Run the command-line tools on a laptop or Raspberry Pi in the same VLAN as the device (see the project thread).
- Fix reachability (VLAN, firewall, multicast) before touching integrations.
- Give anything you monitor a DHCP reservation, as the HA ping docs recommend, otherwise HA keeps checking the old address.
Question for the group: how do you handle discovery across VLANs at home? Do you use an mDNS reflector, put Home Assistant in more than one VLAN, or add everything by IP?