Hubitat.local Issues - Once Again

WINS is used for NetBIOS name resolution. This should not have anything to do with mDNS name resolution, IIRC... :thinking:

1 Like

I agree, Im just grasping at straws here... :thinking:

1 Like

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.

1 Like

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.

1 Like

Mine is cable based .. no wifi ..
mDNS is enabled on Firewall for my computer

1 Like

kills that theory... :sunglasses:

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.

1 Like

Same here. This has piqued my interest. I'm going to use Wireshark to try and track down what's really happening.

Here's behavior in my environment:

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.

Thanks for the info. Do you have any other .local devices (like config pages for routers) to see if they pass/fail?

That was my reason for testing the Home Assistant instance. It works.

I've gotten this work on my 3 Windows boxes but it is not an elegant fix. Here how to do it:

  1. install Apple Printer Services. It a small 5MB package that contains Bonjour. Get it at https://support.apple.com/en-us/106380

  2. 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.

Now close the terminal window with CTRL-C.

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.

4 Likes

Anything that might work for Android?

Also, for the reboot, you could always save the command as a bat file and run on bootup or login.

Well, I have never actually tried using hubitat.local before so I gave it a go.

On my Windows 10 machine, it worked fine. I type in hubitat.local into my browser and it took me directly to hubitats page.

I ping hubitat.local and it successfully resolves and pings.

This is the baffling part- it works on some Windows installations but not on all.

1 Like

I can now confirm that it works on ALL of my Windows machines at home, whether Windows 8.1, 10, 11, or Server 2012 R2 and Hyper-V Server 2019.

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... :wink:

4 Likes

I agree .. just easier to remember :slight_smile:

2 Likes

I traced this on WireShark and the hubitat receives 2-3 queries before it seems to wake up and responds with "Hubitat.. Yea, that's me".

1 Like

My Mac’s and Linux machine do this too.