I would agree, except the fact that literally EVERY other .local addressed device works on all of my devices, windows or android. It is ONLY hubitat.local that doesn't work.
Same
For me, it is both Windows AND Android where Hubitat.local fails to resolve. This is also regardless of which browser I use. (Tried Firefox, Chrome, and Vivaldi)
Also, mDNS is enabled on Firewalla for my Network.
Would be nice to know what exactly isn't working that prevents it from working. However, at this point, is more of a learning thing for me. My .lan addresses all work as well as using the direct IP.
Don't see where you state if you are doing this via WiFi or ethernet so my apologies if this was already covered, but there was an issue that surfaced in 2021 with some of the Windows WiFi drivers where they would fail on a multicast packet and needed to be restarted to make mDNS work again.
WINS is indeed for NetBIOS name resolution, however, if you actually have a WINS server and if you have DHCP set up properly, most devices will still populate the WINS server with it's hostname. BUT, if this was the case here, then you would just ping "hubitat" instead of hubitat.local because WINS does not support FQDN.
That said, I have no idea if Hubitat will even recognize the WINS server within a DHCP scope. I had heard in the past that Hubitat would default to 8.8.8.8 for DNS resolution even if your DHCP scope prescribed a different server, unless you manually tell Hubitat the DNS server you want it to use.
On my Mac hubitat.local mDNS works but the url changes to the IP address. Home Assistant mDNS works and the url does not change, it stays as homeassistant.local.
On a Windows 11 VM on the Mac hubitat.local does not resolve. Home Assistant works as above.
once installed, open a terminal as Administrator and enter:
dns-sd -B _http._tcp
This will list all the Multicast (.local devices) on your LAN. You may need to wait 10-15 seconds for your hubitat to show up. Still don't know why hubitat takes so long. This is my list of .local devices so yours will be different.
Open any browser and enter http://hubitat.local (substitute "hubitat" with whatever you named your hub).
It should work now. But if you reboot, you have do the terminal line thing again.
What I found out is that Windows 10 (v10.5 and later) and Windows 11 comes with their own mDNSResponder. However, it is very buggy and works intermittently. So we're using the Bonjour responder instead. I don't know why you have to scan for ".local" devices first, also don't know why hubitat has problems responding to mDNS queries. I ran WireShark on the Hubitat and it appears that it takes several queries before it responds that 'hubitat' is indeed its hostname.
The weird thing is, it takes a couple seconds to resolve when I type the hostname.local, like it tries several other methods to resolve an IP first and then finally gives mDNS a shot when all else fails. Weird..
It should be noted too that my IOT devices like Hubitat, Home Assistant, NUT-Server, etc are on a different subnet and VLAN than my PCs, but all VLANs on my network are using the same PiHole machines as their DNS servers.
My router is currently a VERY old Ubiquiti USG as I recently killed my pfSense machine and have to put that all back together - so it will be interesting to see if it all still works when I get pfSense back in play.
Another weird thing is that when browsing to hubitat.local in a browser works perfectly fine, but the address changes to the IP address, whereas with all of my other machines the address stays hostname.local
Not working for me on either hub (C8Pro/C7). I run a couple VLANs, w/hubs on IoT VLAN, but doesn't matter if I connect my Win11 laptop directly to the IoT VLAN, still doesn't work.
Don't really care, as I always access the hubs via saved bookmarks pointing at their reserved IP addresses. Just sharing...