Would be nice if someone from habitat would adress this ..
Is it Only For apple users ? why no work with windows machines >?
Seems this is a on-going thing with serval people Mentioning it.
suggestion how / why / fix it ? ( router settings / window settings / etc. )
I know its not necessary because IP works .. But would be nice to know why or why not ?
@mike.maxwell @gopher.ny @bobbyD maybe could give some incite
I did a google search for "add mdns to windows" and the first result has:
it's from 2018 and the Update: at the end is probably applicable, but you'd have to investigate your specific Windows instance. Maybe look at the registry to see if it exists and is set to 0.
I'm not ready to believe you (or anyone) is running a 6yr old version or Windows, but clearly this is a path windows people have walked before.
Just add an entry for hubitat.local and it's corresponding IP address to your hosts file on your Windows machines (or, even better, to your DNS server if possible) and then never worry about this problem again.
(C:\windows\system32\drivers\etc\hosts)
I've tried this (At least on Windows 11) the EnableMulticast registry entry set to zero has no effect and does not turn off Windows mDNS. Also, Bonjour for Windows is somewhat obsolete now and hasn't been updated since 2010 (14 years ago). Both current versions of Windows 10 and 11 now have their own built-in mDNSResponders.
Without the ability to turn off Windows mDNS, running Bonjour at the same time creates a port 5353 confilct, and who knows what else. Basically, Microsoft has blocked the use of Bonjour in current versions of Windows 10/11.
Why would I need to make an exception for hubitat? I've got at least 7 more .local devices on my LAN that all work fine with Windows mDNS. The hosts file is just a kludge that finds an IP from a domain name if all else fails.
Fair enough - It wasnt obvious if you had something decent or a PoS from your ISP.
Have you tried ipconfig /flushdns
on your pc just to make sure it isnt windows DNS caching causing issues? Then follow it with a ping hubitat.local
.
yeah .. I tried it > ipconfig /flushdns .. nope .. work help / workie ..
I am pretty sure it a windows thing .. or router thing .. or a HUB thing, but can not figure it out.
Its a mystery ..
And I am one of those guys with too much time on his hands and do not like mysteries!
( Kinda why I like home automation LOL )
And while yes adding to the file works .. 192.168.50.126 Hubitat.local
This does not solve the mystery.. its a patch
Because obviously there's something not working properly and it's the quickest fix. Adding to your hosts file is faster than using DNS because Windows uses the hosts file first before attempting to resolve via other means.
It seems like you've tried many exceptions to make Hubitat.local work for you and none of them have worked, so why not try the one thing that is sure to work?? (The hosts file)
Actually you are 100% right, I only have one Windows PC (Win 11 driving my CNC Router) and I had though it worked on it, turns out, no it doesnt (I had the IP address bookmarked).
So I fired up a couple of Windows VM's on my Mac and it doesnt work in Windows 7 or Windows 10 VM's either.
But macOS and Linux both work perfectly:
Solution: Dont use Windows
mDNS uses udp/5353 (and tcp/5353.)
Enterprise / Corporate PCs can have this disabled so you may want to check if your Windows Firewall has those ports blocked.
Mine works with Windows. Must be specific to your machine or your router?
I even did a ping test like @dJOS shows, and mine passed. Again, Win10.
Doesn't work on my lan on either Windows or Android using hubitat.local (verified in settings that is what the name should be)
I thought it was due to the firewalla settings that has its own local domain for each device using .lan. However, my other devices (octopi, NAS, etc) work. It does work if I use the .lan names set by firewalla.
Images below are from Android 14 (Tab s9 Ultra). So, not just a windows issue.
All of my bookmarks use the IP address. But, it would be nice if the settings in the hub actually worked for the .local names.
It's something specific to your setup. I have 4 hubs all uniquely named and retrievable via their .local name; works on Windows, Linux, iOS, iPadOS, and Android as long as I'm on the LAN.
Yes, has no effect.
Do you have WINS configured on your home network? I personally dont, but im wondering if this has something to do with Windows clients being unable to resolve some .local names to IP addresses.
Don't remember ever setting it up, just out of the box Windows... one of the devices has gone from Win7->Win8->Win10->Win11
WINS is used for NetBIOS name resolution. This should not have anything to do with mDNS name resolution, IIRC...
I agree, Im just grasping at straws here...